draft-ietf-ipo-framework-00.txt   draft-ietf-ipo-framework-01.txt 
Bala Rajagopalan Bala Rajagopalan
Internet Draft Tellium, Inc. Internet Draft Tellium, Inc.
draft-ietf-ipo-framework-00.txt James Luciani draft-ietf-ipo-framework-01.txt James Luciani
Expires on: 1/13/2002 Crescent Networks Expires on: 8/22/2002 Crescent Networks
Daniel Awduche Daniel Awduche
Movaz Networks Movaz Networks
Brad Cain Brad Cain
Cereva Networks Cereva Networks
Bilel Jamoussi Bilel Jamoussi
Nortel Networks Nortel Networks
Debanjan Saha Debanjan Saha
Tellium, Inc. Tellium, Inc.
IP over Optical Networks: A Framework IP over Optical Networks: A Framework
skipping to change at line 50 skipping to change at line 50
high-speed routers interconnected by optical core networks. The high-speed routers interconnected by optical core networks. The
architectural choices for the interaction between IP and optical architectural choices for the interaction between IP and optical
network layers, specifically, the routing and signaling aspects, are network layers, specifically, the routing and signaling aspects, are
maturing. At the same time, a consensus has emerged in the industry maturing. At the same time, a consensus has emerged in the industry
on utilizing IP-based protocols for the optical control plane. This on utilizing IP-based protocols for the optical control plane. This
draft defines a framework for IP over Optical networks, considering draft defines a framework for IP over Optical networks, considering
both the IP-based control plane for optical networks as well as IP- both the IP-based control plane for optical networks as well as IP-
optical network interactions (together referred to as "IP over optical network interactions (together referred to as "IP over
optical networks"). optical networks").
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
Table of Contents Table of Contents
----------------- -----------------
1. Abstract........................................................1 1. Abstract...........................................................1
2. Conventions used in this document...............................3 2. Conventions used in this document..................................3
3. Introduction....................................................3 3. Introduction.......................................................3
4. Terminology and Concepts........................................4 4. Terminology and Concepts...........................................4
5. The Network Model...............................................8 5. The Network Model..................................................8
5.1 Network Interconnection.....................................8 5.1 Network Interconnection........................................8
5.2 Control Structure..........................................10 5.2 Control Structure.............................................10
6. IP over Optical Service Models and Requirements................12 6. IP over Optical Service Models and Requirements...................12
6.1 Domain Services Model......................................12 6.1 Domain Services Model.........................................12
6.2 Unified Service Model......................................13 6.2 Unified Service Model.........................................13
6.3 Which Service Model?.......................................14 6.3 Which Service Model?..........................................14
6.4 What are the Possible Services?.............................14 6.4 What are the Possible Services?................................14
7. IP transport over Optical Networks.............................15 7. IP transport over Optical Networks................................15
7.1 Interconnection Models......................................15 7.1 Interconnection Models.........................................15
7.2 Routing Approaches..........................................16 7.2 Routing Approaches.............................................16
7.3 Signaling-Related...........................................19 7.3 Signaling-Related..............................................19
8. IP-based Optical Control Plane Issues..........................22 7.4 End-to-End Protection Models..................................20
8.1 Addressing.................................................23 8. IP-based Optical Control Plane Issues.............................22
8.2 Neighbor Discovery.........................................24 8.1 Addressing....................................................23
8.3 Topology Discovery.........................................25 8.2 Neighbor Discovery............................................24
8.4 Restoration Models.........................................26 8.3 Topology Discovery............................................25
8.5 Route Computation..........................................27 8.4 Restoration Models............................................26
8.6 Signaling Issues...........................................29 8.5 Route Computation.............................................27
8.7 Optical Internetworking...................................31 8.6 Signaling Issues..............................................29
9. Other Issues...................................................32 8.7 Optical Internetworking......................................31
9.1 WDM and TDM in the Same Network...........................32 9. Other Issues......................................................32
9.2 Wavelength Conversion.....................................32 9.1 WDM and TDM in the Same Network..............................32
9.3 Service Provider Peering Points...........................32 9.2 Wavelength Conversion........................................32
9.4 Rate of Lightpath Set-Up..................................33 9.3 Service Provider Peering Points..............................32
9.5 Distributed vs. Centralized Provisioning..................34 9.4 Rate of Lightpath Set-Up.....................................33
9.6 Optical Networks with Additional Configurable Components..34 9.5 Distributed vs. Centralized Provisioning.....................34
9.7 Optical Networks with Limited Wavelength Conversion 9.6 Optical Networks with Additional Configurable Components.....34
Capability......................................................34 9.7 Optical Networks with Limited Wavelength Conversion Capability34
10. Evolution Path for IP over Optical Architecture..............35 10. Evolution Path for IP over Optical Architecture.................35
11. Security Considerations.......................................36 11. Security Considerations..........................................37
12. Summary and Conclusions.......................................36 12. Summary and Conclusions..........................................37
13. References....................................................36 13. References.......................................................37
14. Acknowledgments...............................................38 14. Acknowledgments..................................................39
15. Author's Addresses............................................38 15. Author's Addresses...............................................39
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
3. Introduction 3. Introduction
Optical network technologies are evolving rapidly in terms of Optical network technologies are evolving rapidly in terms of
skipping to change at line 144 skipping to change at line 144
routing mechanisms developed for IP traffic engineering applications routing mechanisms developed for IP traffic engineering applications
could be re-used in optical networks. Nevertheless, the issues and could be re-used in optical networks. Nevertheless, the issues and
requirements that are specific to optical networking must be requirements that are specific to optical networking must be
understood to suitably adopt the IP-based protocols. This is understood to suitably adopt the IP-based protocols. This is
especially the case for restoration. Also, there are different especially the case for restoration. Also, there are different
views on the model for interaction between the optical network and views on the model for interaction between the optical network and
client networks, such as IP networks. Reasonable architectural client networks, such as IP networks. Reasonable architectural
alternatives in this regard must be supported, with an understanding alternatives in this regard must be supported, with an understanding
of their pros and cons. of their pros and cons.
draft-ietf-ipo-framework-00.txt
Thus, there are two fundamental issues related to IP over optical Thus, there are two fundamental issues related to IP over optical
networks. The first is the adaptation and reuse of IP control plane networks. The first is the adaptation and reuse of IP control plane
protocols within the optical network control plane, irrespective of protocols within the optical network control plane, irrespective of
draft-ietf-ipo-framework-01.txt
the types of digital clients that utilize the optical network. The the types of digital clients that utilize the optical network. The
second is the transport of IP traffic through an optical network second is the transport of IP traffic through an optical network
together with the control and coordination issues that arise together with the control and coordination issues that arise
therefrom. therefrom.
This draft defines a framework for IP over optical networks covering This draft defines a framework for IP over optical networks covering
the requirements and mechanisms for establishing an IP-centric the requirements and mechanisms for establishing an IP-centric
optical control plane, and the architectural aspects of IP transport optical control plane, and the architectural aspects of IP transport
over optical networks. In this regard, it is recognized that the over optical networks. In this regard, it is recognized that the
specific capabilities required for IP over optical networks would specific capabilities required for IP over optical networks would
skipping to change at line 196 skipping to change at line 196
over optical networking capabilities in terms of increasingly over optical networking capabilities in terms of increasingly
sophisticated functionality supported. Section 11 considers security sophisticated functionality supported. Section 11 considers security
aspects. Finally, summary and conclusion are presented in Section aspects. Finally, summary and conclusion are presented in Section
12. 12.
4. Terminology and Concepts 4. Terminology and Concepts
This section introduces the terminology pertinent to this framework This section introduces the terminology pertinent to this framework
and some related concepts. and some related concepts.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
WDM WDM
--- ---
Wavelength Division Multiplexing (WDM) is a technology that allows Wavelength Division Multiplexing (WDM) is a technology that allows
multiple optical signals operating at different wavelengths to be multiple optical signals operating at different wavelengths to be
multiplexed onto a single fiber so that they can be transported in multiplexed onto a single fiber so that they can be transported in
parallel through the fiber. In general, each optical wavelength may parallel through the fiber. In general, each optical wavelength may
carry digital client payloads at a different data rate (e.g., OC-3c, carry digital client payloads at a different data rate (e.g., OC-3c,
OC-12c, OC- 48c, OC-192c, etc.) and in a different format (SONET, OC-12c, OC- 48c, OC-192c, etc.) and in a different format (SONET,
skipping to change at line 251 skipping to change at line 251
optical conversion at the output port, or it can be all-optical. An optical conversion at the output port, or it can be all-optical. An
OXC is assumed to have a control-plane processor that implements OXC is assumed to have a control-plane processor that implements
signaling and routing protocols necessary for realizing an optical signaling and routing protocols necessary for realizing an optical
network. network.
Optical channel trail or Lightpath Optical channel trail or Lightpath
---------------------------------- ----------------------------------
An optical channel trail is a point-to-point optical layer An optical channel trail is a point-to-point optical layer
connection between two access points in an optical network. In this connection between two access points in an optical network. In this
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
draft, the term "lightpath" is used interchangeably with optical draft, the term "lightpath" is used interchangeably with optical
channel trail. channel trail.
Optical mesh sub-network Optical mesh sub-network
------------------------ ------------------------
An optical sub-network, as discussed in this framework, is a network An optical sub-network, as discussed in this framework, is a network
of OXCs that supports end-to-end networking of optical channel of OXCs that supports end-to-end networking of optical channel
trails providing functionality like routing, monitoring, grooming, trails providing functionality like routing, monitoring, grooming,
and protection and restoration of optical channels. The and protection and restoration of optical channels. The
interconnection of OXCs in this network can be based on a general interconnection of OXCs in this network can be based on a general
topology (also called "mesh" topology) Underlying this network could topology (also called "mesh" topology) Underlying this network could
be the following: be the following:
(a) An optical multiplex section (OMS) layer network : The optical (a) An optical multiplex section (OMS) layer network : The optical
multiplex section layer provides the transport of the optical multiplex section layer provides the transport of the optical
channels. The information contained in this layer is a data channels. The information contained in this layer is a data
stream comprising a set of n optical channels, which have a stream comprising a set of optical channels, which have a
defined aggregate bandwidth. defined aggregate bandwidth.
(b) An optical transmission section (OTS) layer network : This (b) An optical transmission section (OTS) layer network : This
provides functionality for transmission of the optical signal on provides functionality for transmission of the optical signal on
optical media of different types. optical media of different types.
This framework does not address the interaction between the optical This framework does not address the interaction between the optical
sub-network and the OMS, or between the OMS and OTS layer networks. sub-network and the OMS, or between the OMS and OTS layer networks.
Mesh optical network (or simply, "optical network") Mesh optical network (or simply, "optical network")
skipping to change at line 307 skipping to change at line 307
administration. administration.
Wavelength continuity property Wavelength continuity property
------------------------------ ------------------------------
A lightpath is said to satisfy the wavelength continuity property if A lightpath is said to satisfy the wavelength continuity property if
it is transported over the same wavelength end-to-end. Wavelength it is transported over the same wavelength end-to-end. Wavelength
continuity is required in optical networks with no wavelength continuity is required in optical networks with no wavelength
conversion feature. conversion feature.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
Wavelength path Wavelength path
--------------- ---------------
A lightpath that satisfies the wavelength continuity property is A lightpath that satisfies the wavelength continuity property is
called a wavelength path. called a wavelength path.
Opaque vs. transparent optical networks Opaque vs. transparent optical networks
--------------------------------------- ---------------------------------------
skipping to change at line 362 skipping to change at line 362
assumed, without loss of generality, that the term trust domain assumed, without loss of generality, that the term trust domain
applies to a single administrative entity. applies to a single administrative entity.
Flow Flow
---- ----
For the purpose of this document, the term flow will be used to For the purpose of this document, the term flow will be used to
represent the smallest non-separable stream of data, as seen by an represent the smallest non-separable stream of data, as seen by an
endpoint (source or destination node). It is to be noted that the endpoint (source or destination node). It is to be noted that the
term flow is heavily overloaded in the networking literature. Within term flow is heavily overloaded in the networking literature. Within
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
the context of this document, it may be convenient to consider a the context of this document, it may be convenient to consider a
wavelength as a flow under certain circumstances. However, if there wavelength as a flow under certain circumstances. However, if there
is a method to partition the bandwidth of the wavelength, then each is a method to partition the bandwidth of the wavelength, then each
partition may be considered a flow, for example by quantizing time partition may be considered a flow, for example by quantizing time
into some nicely manageable intervals, it may be feasible to into some nicely manageable intervals, it may be feasible to
consider each quanta of time within a given wavelength as a flow. consider each quanta of time within a given wavelength as a flow.
Traffic Trunk Traffic Trunk
------------- -------------
skipping to change at line 417 skipping to change at line 417
conversions where necessary. The routers that have direct physical conversions where necessary. The routers that have direct physical
connectivity with the optical network are referred to as "edge connectivity with the optical network are referred to as "edge
routers". As shown in the figure, other client networks (e.g., ATM) routers". As shown in the figure, other client networks (e.g., ATM)
may connect to the optical network. may connect to the optical network.
The switching function in an OXC is controlled by appropriately The switching function in an OXC is controlled by appropriately
configuring the cross-connect fabric. Conceptually, this may be configuring the cross-connect fabric. Conceptually, this may be
viewed as setting up a cross-connect table whose entries are of the viewed as setting up a cross-connect table whose entries are of the
form <input port i, output port j>, indicating that the data stream form <input port i, output port j>, indicating that the data stream
entering input port i will be switched to output port j. In the entering input port i will be switched to output port j. In the
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
context of a wavelength selective cross-connect (generally referred context of a wavelength selective cross-connect (generally referred
to as a WXC), the cross-connect tables may also indicate the input to as a WXC), the cross-connect tables may also indicate the input
and output wavelengths along with the input and output ports. A and output wavelengths along with the input and output ports. A
lightpath from an ingress port in an OXC to an egress port in a lightpath from an ingress port in an OXC to an egress port in a
remote OXC is established by setting up suitable cross-connects in remote OXC is established by setting up suitable cross-connects in
the ingress, the egress and a set of intermediate OXCs such that a the ingress, the egress and a set of intermediate OXCs such that a
continuous physical path exists from the ingress to the egress port. continuous physical path exists from the ingress to the egress port.
Optical paths tend to be bi-directional, i.e., the return path from Optical paths tend to be bi-directional, i.e., the return path from
the egress port to the ingress port is typically routed along the the egress port to the ingress port is typically routed along the
skipping to change at line 472 skipping to change at line 472
UNI UNI UNI UNI
| | | |
+------+-------+ +------+-----+ +------+-------+ +------+-----+
| | | | | | | |
| Other Client | |Other Client| | Other Client | |Other Client|
| Network | | Network | | Network | | Network |
| (e.g., ATM) | | | | (e.g., ATM) | | |
+--------------+ +------------+ +--------------+ +------------+
Figure 1: Optical Internetwork Model Figure 1: Optical Internetwork Model
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
Multiple data streams output from an OXC may be multiplexed onto an Multiple data streams output from an OXC may be multiplexed onto an
optical link using WDM technology. The WDM functionality may exist optical link using WDM technology. The WDM functionality may exist
outside of the OXC, and be transparent to the OXC. Or, this function outside of the OXC, and be transparent to the OXC. Or, this function
may be built into the OXC. In the latter case, the cross-connect may be built into the OXC. In the later case, the cross-connect
table (conceptually) consists of pairs of the form, <{input port table (conceptually) consists of pairs of the form, <{input port
i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that the i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that the
data stream received on wavelength Lambda(j) over input port i is data stream received on wavelength Lambda(j) over input port i is
switched to output port k on Lambda(l). Automated establishment of switched to output port k on Lambda(l). Automated establishment of
lightpaths involves setting up the cross-connect table entries in lightpaths involves setting up the cross-connect table entries in
the appropriate OXCs in a coordinated manner such that the desired the appropriate OXCs in a coordinated manner such that the desired
physical path is realized. physical path is realized.
Under this network model, a switched lightpath must be established Under this network model, a switched lightpath must be established
between a pair of IP routers before they can communicate. This between a pair of IP routers before they can communicate. This
skipping to change at line 526 skipping to change at line 526
described in Section 7. The NNIs represent vendor-independent described in Section 7. The NNIs represent vendor-independent
standardized control flow between nodes. The distinction between the standardized control flow between nodes. The distinction between the
INNI and the ENNI is that the former is an interface within a given INNI and the ENNI is that the former is an interface within a given
network under a single technical administration, while the later network under a single technical administration, while the later
indicates an interface at the administrative boundary between indicates an interface at the administrative boundary between
networks. The INNI and ENNI may thus differ in the policies that networks. The INNI and ENNI may thus differ in the policies that
restrict control flow between nodes. Security, scalability, restrict control flow between nodes. Security, scalability,
stability, and information hiding are important considerations in stability, and information hiding are important considerations in
the specification of the ENNI. It is possible in principle to the specification of the ENNI. It is possible in principle to
harmonize the control flow across the UNI and the NNI and eliminate harmonize the control flow across the UNI and the NNI and eliminate
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
the distinction between them. On the other hand, it may be required the distinction between them. On the other hand, it may be required
to minimize control flow information, especially routing-related to minimize control flow information, especially routing-related
information, over the UNI; and even over the ENNI. In this case, information, over the UNI; and even over the ENNI. In this case,
UNI and NNIs may look different in some respects. In this draft, UNI and NNIs may look different in some respects. In this draft,
these interfaces are treated as distinct. these interfaces are treated as distinct.
The UNI can be categorized as public or private depending upon The UNI can be categorized as public or private depending upon
context and service models. Routing information (ie, topology state context and service models. Routing information (ie, topology state
information) can be exchanged across a private UNI. On the other information) can be exchanged across a private UNI. On the other
skipping to change at line 576 skipping to change at line 576
implemented between the client and a device in the optical network implemented between the client and a device in the optical network
to signal service requests and responses. For instance, a to signal service requests and responses. For instance, a
management system or a server in the optical network may receive management system or a server in the optical network may receive
service requests from clients. Similarly, out-of-band signaling service requests from clients. Similarly, out-of-band signaling
may be used between management systems in client and optical may be used between management systems in client and optical
networks to signal service requests. In these cases, there is no networks to signal service requests. In these cases, there is no
direct control interaction between clients and respective direct control interaction between clients and respective
OXCs. One reason to have an indirect interface would be that the OXCs. One reason to have an indirect interface would be that the
OXCs and/or clients do not support a direct signaling interface. OXCs and/or clients do not support a direct signaling interface.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
+-----------------------------+ +-----------------------------+ +-----------------------------+ +-----------------------------+
| | | | | | | |
| +---------+ +---------+ | | +---------+ +---------+ | | +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | | | | | | | | | | | | | | | | | |
| | Routing | |Signaling| | | | Routing | |Signaling| | | | Routing | |Signaling| | | | Routing | |Signaling| |
| | Protocol| |Protocol | | | | Protocol| |Protocol | | | | Protocol| |Protocol | | | | Protocol| |Protocol | |
| | | | | | | | | | | | | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ |
| | | | | | | | | | | | | | | |
skipping to change at line 628 skipping to change at line 628
Standardized signaling across the UNI (Figure 1) is used to invoke Standardized signaling across the UNI (Figure 1) is used to invoke
the following the following
services: services:
1. Lightpath creation: This service allows a lightpath with the 1. Lightpath creation: This service allows a lightpath with the
specified attributes to be created between a pair of termination specified attributes to be created between a pair of termination
points in the optical network. Lightpath creation may be subject points in the optical network. Lightpath creation may be subject
to network-defined policies (e.g., connectivity restrictions) and to network-defined policies (e.g., connectivity restrictions) and
security procedures. security procedures.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
2. Lightpath deletion: This service allows an existing lightpath to 2. Lightpath deletion: This service allows an existing lightpath to
be deleted. be deleted.
3. Lightpath modification: This service allows certain parameters of 3. Lightpath modification: This service allows certain parameters of
the lightpath to be modified. the lightpath to be modified.
4. Lightpath status enquiry: This service allows the status of 4. Lightpath status enquiry: This service allows the status of
certain parameters of the lightpath (referenced by its ID) to be certain parameters of the lightpath (referenced by its ID) to be
queried by the router that created the lightpath. queried by the router that created the lightpath.
skipping to change at line 683 skipping to change at line 683
that this control plane is MPLS-based, as described in [1]. The that this control plane is MPLS-based, as described in [1]. The
unified service model has so far been discussed only in the context unified service model has so far been discussed only in the context
of a single administrative domain. A unified control plane is of a single administrative domain. A unified control plane is
possible even when there are administrative boundaries within an possible even when there are administrative boundaries within an
optical internetwork, but some of the integrated routing optical internetwork, but some of the integrated routing
capabilities may not be practically attractive or even feasible in capabilities may not be practically attractive or even feasible in
this case (see Section 7). this case (see Section 7).
Under the unified service model, optical network services are Under the unified service model, optical network services are
obtained implicitly during end-to-end MPLS signaling. Specifically, obtained implicitly during end-to-end MPLS signaling. Specifically,
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
an edge router can create a lightpath with specified attributes, or an edge router can create a lightpath with specified attributes, or
delete and modify lightpaths as it creates MPLS label-switched paths delete and modify lightpaths as it creates MPLS label-switched paths
(LSPs). In this regard, the services obtained from the optical (LSPs). In this regard, the services obtained from the optical
network are similar to the domain services model. These services, network are similar to the domain services model. These services,
however, may be invoked in a more seamless manner as compared to the however, may be invoked in a more seamless manner as compared to the
domain services model. For instance, when routers are attached to a domain services model. For instance, when routers are attached to a
single optical network (i.e., there are no ENNIs), a remote router single optical network (i.e., there are no ENNIs), a remote router
could compute an end-to-end path across the optical internetwork. It could compute an end-to-end path across the optical internetwork. It
can then establish an LSP across the optical internetwork. But the can then establish an LSP across the optical internetwork. But the
skipping to change at line 736 skipping to change at line 736
Given that the data plane between IP routers over an optical network Given that the data plane between IP routers over an optical network
amounts to a virtual topology which is an overlay over the optical amounts to a virtual topology which is an overlay over the optical
network, it is easy to imagine a virtual private network of network, it is easy to imagine a virtual private network of
lightpaths that interconnect routers (or any other set of clients). lightpaths that interconnect routers (or any other set of clients).
Indeed, in the case where the optical network provides connectivity Indeed, in the case where the optical network provides connectivity
for multiple sets of external client networks, there has to be a for multiple sets of external client networks, there has to be a
way to enforce routing policies that ensure routing separation way to enforce routing policies that ensure routing separation
between different sets of clients (i.e., VPN service). between different sets of clients (i.e., VPN service).
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
7. IP transport over Optical Networks 7. IP transport over Optical Networks
To examine the architectural alternatives for IP over optical To examine the architectural alternatives for IP over optical
networks, it is important to distinguish between the data and networks, it is important to distinguish between the data and
control planes over the UNI. As described in Section 6, the optical control planes over the UNI. As described in Section 6, the optical
network provides a service to external entities in the form of fixed network provides a service to external entities in the form of fixed
bandwidth transport pipes (optical paths). IP routers at the edge of bandwidth transport pipes (optical paths). IP routers at the edge of
the optical networks must necessarily have such paths established the optical networks must necessarily have such paths established
between them before communication at the IP layer can commence. between them before communication at the IP layer can commence.
skipping to change at line 791 skipping to change at line 791
network. In the case of OSPF, opaque LSAs can be used to advertise network. In the case of OSPF, opaque LSAs can be used to advertise
topology state information. In the case of IS-IS, extended TLVs will topology state information. In the case of IS-IS, extended TLVs will
have to be defined to propagate topology state information. When an have to be defined to propagate topology state information. When an
optical internetwork with multiple optical networks is involved optical internetwork with multiple optical networks is involved
(that spans different administrative boundaries), a single instance (that spans different administrative boundaries), a single instance
of an intra-domain routing protocol is not practically attractive or of an intra-domain routing protocol is not practically attractive or
even feasible. In this case, inter-domain routing and signaling are even feasible. In this case, inter-domain routing and signaling are
needed. In either case, a tacit assumption is that a common needed. In either case, a tacit assumption is that a common
addressing scheme will be used for the optical and IP networks. A addressing scheme will be used for the optical and IP networks. A
common address space can be trivially realized by using IP addresses common address space can be trivially realized by using IP addresses
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
in both IP and optical domains. Thus, the optical network elements in both IP and optical domains. Thus, the optical network elements
become IP addressable entities as noted in [1]. become IP addressable entities as noted in [1].
7.1.2 The Overlay Model 7.1.2 The Overlay Model
Under the overlay model, the IP/MPLS routing, topology distribution, Under the overlay model, the IP/MPLS routing, topology distribution,
and signaling protocols are independent of the routing, topology and signaling protocols are independent of the routing, topology
distribution, and signaling protocols at the optical layer. This distribution, and signaling protocols at the optical layer. This
model is conceptually similar to the classical IP over ATM or MPOA model is conceptually similar to the classical IP over ATM or MPOA
skipping to change at line 846 skipping to change at line 846
router across the optical network. Suppose the path computation is router across the optical network. Suppose the path computation is
triggered by the need to route a label switched path (LSP). Such an triggered by the need to route a label switched path (LSP). Such an
LSP can be established using MPLS signaling, e.g., RSVP-TE or CR- LSP can be established using MPLS signaling, e.g., RSVP-TE or CR-
LDP. When the LSP is routed over the optical network, a lightpath LDP. When the LSP is routed over the optical network, a lightpath
must be established between two edge routers. This lightpath is in must be established between two edge routers. This lightpath is in
essence a tunnel across the optical network, and may have capacity essence a tunnel across the optical network, and may have capacity
much larger than that required to route the first LSP. Thus, it is much larger than that required to route the first LSP. Thus, it is
essential that other routers in the network realize the availability essential that other routers in the network realize the availability
of resources in the lightpath for other LSPs to be routed over it. of resources in the lightpath for other LSPs to be routed over it.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
The lightpath may therefore be advertised as a virtual link in the The lightpath may therefore be advertised as a virtual link in the
topology. topology.
The notion of "forwarding adjacency" (FA) described in [3] is The notion of "forwarding adjacency" (FA) described in [3] is
essential in propagating existing lightpath information to other essential in propagating existing lightpath information to other
routers. An FA is essentially a virtual link advertised into a link routers. An FA is essentially a virtual link advertised into a link
state routing protocol. Thus, an FA could be described by the same state routing protocol. Thus, an FA could be described by the same
parameters that define resources in any regular link. While it is parameters that define resources in any regular link. While it is
necessary to specify the mechanism for creating an FA, it is not necessary to specify the mechanism for creating an FA, it is not
skipping to change at line 900 skipping to change at line 900
interconnection model. Under this approach, routing within the interconnection model. Under this approach, routing within the
optical and IP domains are separated, with a standard routing optical and IP domains are separated, with a standard routing
protocol running between domains. This is similar to the IP inter- protocol running between domains. This is similar to the IP inter-
domain routing model. A specific approach for this is considered domain routing model. A specific approach for this is considered
next. It is to be noted that other approaches are equally possible. next. It is to be noted that other approaches are equally possible.
7.2.2.1 Domain-Specific Routing using BGP 7.2.2.1 Domain-Specific Routing using BGP
The inter-domain IP routing protocol, BGP [8], may be adapted for The inter-domain IP routing protocol, BGP [8], may be adapted for
exchanging routing information between IP and optical domains. This exchanging routing information between IP and optical domains. This
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
would allow the routers to advertise IP address prefixes within would allow the routers to advertise IP address prefixes within
their network to the optical internetwork and to receive external their network to the optical internetwork and to receive external
IP address prefixes from the optical internetwork. The optical IP address prefixes from the optical internetwork. The optical
internetwork transports the reachability information from one IP internetwork transports the reachability information from one IP
network to others. For instance, edge routers and OXCs can run network to others. For instance, edge routers and OXCs can run
exterior BGP (EBGP). Within the optical internetwork, interior BGP exterior BGP (EBGP). Within the optical internetwork, interior BGP
(IBGP) is used between border OXCs within the same network, and EBGP (IBGP) is used between border OXCs within the same network, and EBGP
is used between networks (over ENNI, Figure 1). is used between networks (over ENNI, Figure 1).
skipping to change at line 954 skipping to change at line 954
implement a registry that allows edge routers to register IP implement a registry that allows edge routers to register IP
addresses and VPN identifiers. An edge router may be allowed to addresses and VPN identifiers. An edge router may be allowed to
query for external addresses belonging to the same set of VPNs it query for external addresses belonging to the same set of VPNs it
belongs to. A successful query would return the address of the belongs to. A successful query would return the address of the
egress optical port through which the external destination can be egress optical port through which the external destination can be
reached. reached.
Because IP-optical interface connectivity is limited, the Because IP-optical interface connectivity is limited, the
determination of how many lightpaths must be established and to what determination of how many lightpaths must be established and to what
endpoints are traffic engineering decisions. Furthermore, after an endpoints are traffic engineering decisions. Furthermore, after an
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
initial set of such lightpaths are established, these may be used as initial set of such lightpaths are established, these may be used as
adjacencies within VPNs for a VPN-wide routing scheme, for example, adjacencies within VPNs for a VPN-wide routing scheme, for example,
OSPF. With this approach, an edge router could first determine other OSPF. With this approach, an edge router could first determine other
edge routers of interest by querying the registry. After it obtains edge routers of interest by querying the registry. After it obtains
the appropriate addresses, an initial overlay lightpath topology may the appropriate addresses, an initial overlay lightpath topology may
be formed. Routing adjacencies may then be established across the be formed. Routing adjacencies may then be established across the
lightpaths and further routing information may be exchanged to lightpaths and further routing information may be exchanged to
establish VPN-wide routing. establish VPN-wide routing.
skipping to change at line 1008 skipping to change at line 1008
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | Router +---+ Router +-----+------+ OXC +---+ OXC | | | | Router +---+ Router +-----+------+ OXC +---+ OXC | |
| | | | | | | | | | | | | | | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ |
+-----------------------------+ | +-----------------------------+ +-----------------------------+ | +-----------------------------+
| |
| |
Completely Separated Addressing and Control Planes Completely Separated Addressing and Control Planes
Figure 3: Domain Services Signaling Model Figure 3: Domain Services Signaling Model
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
With the unified services model, the addressing is common in the IP With the unified services model, the addressing is common in the IP
network and optical internetwork and the respective signaling network and optical internetwork and the respective signaling
control are related, as shown in Figure 4. It is understood that control are related, as shown in Figure 4. It is understood that
GMPLS signaling is implemented in the IP and optical domains, using GMPLS signaling is implemented in the IP and optical domains, using
suitably enhanced RSVP-TE or CR-LDP protocols. But the semantics of suitably enhanced RSVP-TE or CR-LDP protocols. But the semantics of
services within the optical internetwork may be different from that services within the optical internetwork may be different from that
in the IP network. As an example, the protection services offered in in the IP network. As an example, the protection services offered in
the optical internetwork may be different from the end-to-end the optical internetwork may be different from the end-to-end
protection services offered by the IP network. Another example is protection services offered by the IP network. Another example is
skipping to change at line 1061 skipping to change at line 1061
Suppose an LSP is established from an ingress IP router to an egress Suppose an LSP is established from an ingress IP router to an egress
router across an ingress IP network, a transit optical internetwork router across an ingress IP network, a transit optical internetwork
and an egress IP network. If this LSP is to be afforded protection and an egress IP network. If this LSP is to be afforded protection
in the IP layer, how is the service coordinated between the IP and in the IP layer, how is the service coordinated between the IP and
optical layers? optical layers?
Under this scenario, there are two approaches to end-to-end Under this scenario, there are two approaches to end-to-end
protection: protection:
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
7.4.1 Segment-Wise Protection 7.4.1 Segment-Wise Protection
The protection services in the IP layer could utilize optical layer The protection services in the IP layer could utilize optical layer
protection services for the LSP segment that traverses the optical protection services for the LSP segment that traverses the optical
internetwork. Thus, the end-to-end LSP would be treated as a internetwork. Thus, the end-to-end LSP would be treated as a
concatenation of three LSP segments from the protection point of concatenation of three LSP segments from the protection point of
view: a segment in the ingress IP network, a segment in the optical view: a segment in the ingress IP network, a segment in the optical
internetwork and a segment in the egress IP network. The protection internetwork and a segment in the egress IP network. The protection
services at the IP layer for an end-to-end LSP must be mapped onto services at the IP layer for an end-to-end LSP must be mapped onto
skipping to change at line 1109 skipping to change at line 1109
7.4.2 Single-Layer Protection 7.4.2 Single-Layer Protection
Under this model, the protection services in the IP layer do not Under this model, the protection services in the IP layer do not
rely on any protection services offered in the optical internetwork. rely on any protection services offered in the optical internetwork.
Thus, with reference to Figure 5, two SRLG-disjoint LSPs are Thus, with reference to Figure 5, two SRLG-disjoint LSPs are
established between A and F. The corresponding segments in the established between A and F. The corresponding segments in the
optical internetwork are treated as independent lightpaths in the optical internetwork are treated as independent lightpaths in the
optical internetwork. These lightpaths may be unprotected in the optical internetwork. These lightpaths may be unprotected in the
optical internetwork. optical internetwork.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
7.4.3 Differences 7.4.3 Differences
A distinction between these two choices is as follows. Under the A distinction between these two choices is as follows. Under the
first choice, the optical internetwork is actively involved in end- first choice, the optical internetwork is actively involved in end-
to-end protection, whereas under the second choice, any protection to-end protection, whereas under the second choice, any protection
service offered in the optical internetwork is not utilized directly service offered in the optical internetwork is not utilized directly
by client IP network. Also, under the first choice, the protection by client IP network. Also, under the first choice, the protection
in the optical internetwork may apply collectively to a number of IP in the optical internetwork may apply collectively to a number of IP
LSPs. That is, with reference to Figure 5, many LSPs may be LSPs. That is, with reference to Figure 5, many LSPs may be
skipping to change at line 1162 skipping to change at line 1162
between sub-networks, and between networks. The general guideline between sub-networks, and between networks. The general guideline
followed in this framework is to separate these cases, and allow the followed in this framework is to separate these cases, and allow the
possibility that different control procedures are followed inside possibility that different control procedures are followed inside
different sub-networks, while a common set of procedures are different sub-networks, while a common set of procedures are
followed across sub-networks and networks. followed across sub-networks and networks.
The control plane procedures within a single vendor sub-network need The control plane procedures within a single vendor sub-network need
not be defined since these can be proprietary. Clearly, it is not be defined since these can be proprietary. Clearly, it is
possible to follow the same control procedures inside a sub-network possible to follow the same control procedures inside a sub-network
as defined for control across sub-networks. But this is left as a as defined for control across sub-networks. But this is left as a
recommendation even choice within this framework document, recommendation - even choice - within this framework document,
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
rather than as an imperative requirement. Thus, in the following, rather than as an imperative requirement. Thus, in the following,
signaling and routing across sub-networks is considered first, signaling and routing across sub-networks is considered first,
followed by a discussion of similar issues across networks. followed by a discussion of similar issues across networks.
8.1 Addressing 8.1 Addressing
For interoperability across optical sub-networks using an IP-centric For interoperability across optical sub-networks using an IP-centric
control plane, the fundamental issue is that of addressing. What control plane, the fundamental issue is that of addressing. What
entities should be identifiable from a signaling and routing point entities should be identifiable from a signaling and routing point
skipping to change at line 1218 skipping to change at line 1218
Another entity that must be identified is the SRLG [13]. An Another entity that must be identified is the SRLG [13]. An
SRLG is an identifier assigned to a group of optical links that SRLG is an identifier assigned to a group of optical links that
share a physical resource. For instance, all optical channels routed share a physical resource. For instance, all optical channels routed
over the same fiber could belong to the same SRLG. Similarly, all over the same fiber could belong to the same SRLG. Similarly, all
fibers routed over a conduit could belong to the same SRLG. The fibers routed over a conduit could belong to the same SRLG. The
notable characteristic of SRLGs is that a given link could belong to notable characteristic of SRLGs is that a given link could belong to
more than one SRLG, and two links belonging to a given SRLG may more than one SRLG, and two links belonging to a given SRLG may
individually belong to two other SRLGs. This is illustrated in individually belong to two other SRLGs. This is illustrated in
Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3. 1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3.
Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8 Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8
could belong to SRLG 4. (In this example, the same SRLG, i.e., 1, could belong to SRLG 4. (In this example, the same SRLG, i.e., 1,
contains links from two different adjacencies). contains links from two different adjacencies).
While the classification of physical resources into SRLGs is a While the classification of physical resources into SRLGs is a
manual operation, the assignment of unique identifiers to these manual operation, the assignment of unique identifiers to these
SRLGs within an optical network is essential to ensure correct SRLGs within an optical network is essential to ensure correct
SRLG-disjoint path computation for protection. SRLGs could be SRLG-disjoint path computation for protection. SRLGs could be
skipping to change at line 1268 skipping to change at line 1268
In the case of opaque OXCs with SONET termination, one instance of a In the case of opaque OXCs with SONET termination, one instance of a
neighbor discovery protocol (e.g., LMP [2]) would run on each OXC neighbor discovery protocol (e.g., LMP [2]) would run on each OXC
port, communicating with the corresponding protocol instance at the port, communicating with the corresponding protocol instance at the
neighboring OXC. The protocol would utilize the SONET overhead bytes neighboring OXC. The protocol would utilize the SONET overhead bytes
to transmit the (configured) local attributes periodically to the to transmit the (configured) local attributes periodically to the
neighbor. Thus, two neighboring switches can automatically determine neighbor. Thus, two neighboring switches can automatically determine
the identities of each other and the local connectivity, and also the identities of each other and the local connectivity, and also
keep track of the up/down status of local links. Neighbor discovery keep track of the up/down status of local links. Neighbor discovery
with transparent OXCs is described in [2]. with transparent OXCs is described in [2].
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
+--------------+ +------------+ +------------+ +--------------+ +------------+ +------------+
| +-1:OC48---+ +-5:OC192-+ | | +-1:OC48---+ +-5:OC192-+ |
| +-2:OC48---+ +-6:OC192-+ | | +-2:OC48---+ +-6:OC192-+ |
| OXC1 +-3:OC48---+ OXC2 +-7:OC48--+ OXC3 | | OXC1 +-3:OC48---+ OXC2 +-7:OC48--+ OXC3 |
| +-4:OC192--+ +-8:OC48--+ | | +-4:OC192--+ +-8:OC48--+ |
| | | | +------+ | | | | | +------+ |
+--------------+ +----+-+-----+ | +----+------+-----+ +--------------+ +----+-+-----+ | +----+------+-----+
| | | | | | | | | |
| | | | | | | | | |
skipping to change at line 1322 skipping to change at line 1322
instance, the parameters of the abstract link may include the instance, the parameters of the abstract link may include the
number, bandwidth and the type of optical links contained in the number, bandwidth and the type of optical links contained in the
underlying link bundle [14]. Also, the SRLGs corresponding to each underlying link bundle [14]. Also, the SRLGs corresponding to each
optical link in the bundle may be included as a parameter. optical link in the bundle may be included as a parameter.
o The link state information should capture restoration-related o The link state information should capture restoration-related
parameters for optical links. Specifically, with shared protection parameters for optical links. Specifically, with shared protection
(Section 8.5), the link state updates must have information that (Section 8.5), the link state updates must have information that
allows the computation of shared protection paths. allows the computation of shared protection paths.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
o A single routing adjacency could be maintained between neighbors o A single routing adjacency could be maintained between neighbors
which may have multiple optical links (or even multiple link which may have multiple optical links (or even multiple link
bundles) between them. This reduces the protocol messaging bundles) between them. This reduces the protocol messaging
overhead. overhead.
o Since link availability information changes dynamically, a o Since link availability information changes dynamically, a
flexible policy for triggering link state updates based on flexible policy for triggering link state updates based on
availability thresholds may be implemented. For instance, changes availability thresholds may be implemented. For instance, changes
in availability of links of a given bandwidth (e.g., OC-48) may in availability of links of a given bandwidth (e.g., OC-48) may
skipping to change at line 1377 skipping to change at line 1377
paths whose back-ups share resources. paths whose back-ups share resources.
It is possible that different restoration schemes may be implemented It is possible that different restoration schemes may be implemented
within optical sub-networks. It is therefore necessary to consider a within optical sub-networks. It is therefore necessary to consider a
two-level restoration mechanism. Path failures within an optical two-level restoration mechanism. Path failures within an optical
sub-network could be handled using procedures specific to the sub-network could be handled using procedures specific to the
sub-network. If this fails, end-to-end restoration across sub- sub-network. If this fails, end-to-end restoration across sub-
networks could be invoked. The border OXC that is the ingress to a networks could be invoked. The border OXC that is the ingress to a
sub-network can act as the source for restoration procedures within sub-network can act as the source for restoration procedures within
a sub-network. The signaling for invoking end-to-end restoration a sub-network. The signaling for invoking end-to-end restoration
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
across the INNI is described in Section 8.6.3. The computation of across the INNI is described in Section 8.6.3. The computation of
the back-up path for end-to-end restoration may be based on various the back-up path for end-to-end restoration may be based on various
criteria. It is assumed that the back-up path is computed by the criteria. It is assumed that the back-up path is computed by the
source OXC, and signaled using standard methods. source OXC, and signaled using standard methods.
8.5 Route Computation 8.5 Route Computation
The computation of a primary route for a lightpath within an optical The computation of a primary route for a lightpath within an optical
network is essentially a constraint-based routing problem. The network is essentially a constraint-based routing problem. The
skipping to change at line 1431 skipping to change at line 1431
Assuming that the above information is available for each bundle at Assuming that the above information is available for each bundle at
every node, there are several approaches possible for path every node, there are several approaches possible for path
computation. For instance, computation. For instance,
1. The primary path can be computed first, and the (exclusive 1. The primary path can be computed first, and the (exclusive
or shared) back-up is computed next based on the SRLGs chosen or shared) back-up is computed next based on the SRLGs chosen
for the primary path. In this regard, for the primary path. In this regard,
o The primary path computation procedure can output a series of o The primary path computation procedure can output a series of
bundles the path is routed over. Since a bundle is uniquely bundles the path is routed over. Since a bundle is uniquely
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
identified with a set of SRLGs, the alternate path can be identified with a set of SRLGs, the alternate path can be
computed right away based on this knowledge. In this case, if computed right away based on this knowledge. In this case, if
the primary path set up does not succeed for lack of resources the primary path set up does not succeed for lack of resources
in a chosen bundle, the primary and backup paths must be in a chosen bundle, the primary and backup paths must be
recomputed. recomputed.
o It might be desirable to compute primary paths without choosing o It might be desirable to compute primary paths without choosing
a specific bundle apriori. That is, resource availability over a specific bundle apriori. That is, resource availability over
all bundles between a node pair is taken into account rather all bundles between a node pair is taken into account rather
skipping to change at line 1486 skipping to change at line 1486
affect only one of them. Furthermore, it is assumed that multiple affect only one of them. Furthermore, it is assumed that multiple
failure events affecting links belonging to more than one SRLG will failure events affecting links belonging to more than one SRLG will
not occur concurrently. Unlike the case of 1+1 protection, the not occur concurrently. Unlike the case of 1+1 protection, the
back-up paths are not established apriori. Rather, a failure event back-up paths are not established apriori. Rather, a failure event
triggers the establishment of a single back-up path corresponding to triggers the establishment of a single back-up path corresponding to
the affected primary path. the affected primary path.
The distributed implementation of route computation for shared back- The distributed implementation of route computation for shared back-
up paths require knowledge about the routing of all primary and up paths require knowledge about the routing of all primary and
back-up paths at every node. This raises scalability concerns. For back-up paths at every node. This raises scalability concerns. For
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
this reason, it may be practical to consider the centralization of this reason, it may be practical to consider the centralization of
the route computation algorithm in a route server that has complete the route computation algorithm in a route server that has complete
knowledge of the link state and path routes. Heuristics for fully knowledge of the link state and path routes. Heuristics for fully
distributed route computation without complete knowledge of path distributed route computation without complete knowledge of path
routes are to be determined. Path computation for restoration is routes are to be determined. Path computation for restoration is
further described in [13]. further described in [13].
8.6 Signaling Issues 8.6 Signaling Issues
skipping to change at line 1540 skipping to change at line 1540
8.6.2 Failure Recovery 8.6.2 Failure Recovery
The impact of transient partial failures must be minimized in an The impact of transient partial failures must be minimized in an
optical network. Specifically, optical paths that are not directly optical network. Specifically, optical paths that are not directly
affected by a failure must not be torn down due to the failure. For affected by a failure must not be torn down due to the failure. For
example, the control processor in an OXC may fail, affecting example, the control processor in an OXC may fail, affecting
signaling and other internodal control communication. Similarly, signaling and other internodal control communication. Similarly,
the control channel between OXCs may be affected temporarily by a the control channel between OXCs may be affected temporarily by a
failure. These failure may not affect already established optical failure. These failure may not affect already established optical
paths passing through the OXC fabric. The detection of such failures paths passing through the OXC fabric. The detection of such failures
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
by adjacent nodes, for example, through a keepalive mechanism by adjacent nodes, for example, through a keepalive mechanism
between signaling peers, must not result in these optical paths between signaling peers, must not result in these optical paths
being torn down. being torn down.
It is likely that when the above failures occur, a backup processor It is likely that when the above failures occur, a backup processor
or a backup control channel will be activated. The signaling or a backup control channel will be activated. The signaling
protocol must be designed such that it is resilient to transient protocol must be designed such that it is resilient to transient
failures. During failure recovery, it is desirable to recover local failures. During failure recovery, it is desirable to recover local
state at the concerned OXC with least disruption to existing optical state at the concerned OXC with least disruption to existing optical
skipping to change at line 1590 skipping to change at line 1590
fast signaling over the control channel using very short IP packets fast signaling over the control channel using very short IP packets
and prioritized processing. While it is possible to use RSVP or CR- and prioritized processing. While it is possible to use RSVP or CR-
LDP for activating protection paths, these protocols do not provide LDP for activating protection paths, these protocols do not provide
any means to give priority to restoration signaling as opposed to any means to give priority to restoration signaling as opposed to
signaling for provisioning. For instance, it is possible for a signaling for provisioning. For instance, it is possible for a
restoration-related RSVP message to be queued behind a number of restoration-related RSVP message to be queued behind a number of
provisioning messages thereby delaying restoration. It is therefore provisioning messages thereby delaying restoration. It is therefore
necessary to develop a definition of QoS for restoration signaling necessary to develop a definition of QoS for restoration signaling
and incorporate mechanisms in existing signaling protocols to and incorporate mechanisms in existing signaling protocols to
achieve this. Or, a new signaling protocol may be developed achieve this. Or, a new signaling protocol may be developed
exclusively for activating protection paths during restoration [19]. exclusively for activating protection paths during restoration.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
8.7 Optical Internetworking 8.7 Optical Internetworking
Within an optical internetwork, it must be possible to dynamically Within an optical internetwork, it must be possible to dynamically
provision and restore lightpaths across optical networks. Therefore: provision and restore lightpaths across optical networks. Therefore:
o A standard scheme for uniquely identifying lightpath end-points in o A standard scheme for uniquely identifying lightpath end-points in
different networks is required. different networks is required.
o A protocol is required for determining reachability of end-points o A protocol is required for determining reachability of end-points
skipping to change at line 1642 skipping to change at line 1642
Provisioning an end-to-end lightpath across multiple networks Provisioning an end-to-end lightpath across multiple networks
involves the establishment of path segments in each network involves the establishment of path segments in each network
sequentially. Thus, a path segment is established from the source sequentially. Thus, a path segment is established from the source
OXC to a border OXC in the source network. From this border OXC, OXC to a border OXC in the source network. From this border OXC,
signaling across NNI is used to establish a path segment to a border signaling across NNI is used to establish a path segment to a border
OXC in the next network. Provisioning then continues in the next OXC in the next network. Provisioning then continues in the next
network and so on until the destination OXC is reached. The usage of network and so on until the destination OXC is reached. The usage of
protocols like BGP for this purpose need to be explored. protocols like BGP for this purpose need to be explored.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
8.7.3 Restoration 8.7.3 Restoration
Local restoration across the ENNI is similar to that across INNI Local restoration across the ENNI is similar to that across INNI
described in Section 8.6.3. End-to-end restoration across networks described in Section 8.6.3. End-to-end restoration across networks
is likely to be either of the 1+1 type, or segmented within each is likely to be either of the 1+1 type, or segmented within each
network, as described in Section 8.4. network, as described in Section 8.4.
9. Other Issues 9. Other Issues
skipping to change at line 1697 skipping to change at line 1697
capable of wavelength conversion and others incapable of this. The capable of wavelength conversion and others incapable of this. The
GMPLS "label set" mechanism [4] supports the selection of the same GMPLS "label set" mechanism [4] supports the selection of the same
label (i.e., wavelength) across an NNI. label (i.e., wavelength) across an NNI.
9.3 Service Provider Peering Points 9.3 Service Provider Peering Points
There are proposed inter-network interconnect models which allow There are proposed inter-network interconnect models which allow
certain types of peering relationships to occur at the optical certain types of peering relationships to occur at the optical
layer. This is consistent with the need to support optical layer layer. This is consistent with the need to support optical layer
services independent of higher layers payloads. In the context of IP services independent of higher layers payloads. In the context of IP
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
over optical networks, peering relationships between different trust over optical networks, peering relationships between different trust
domains will eventually have to occur at the IP layer, on IP routing domains will eventually have to occur at the IP layer, on IP routing
elements, even though non-IP paths may exist between the peering elements, even though non-IP paths may exist between the peering
routers. routers.
9.4 Rate of Lightpath Set-Up 9.4 Rate of Lightpath Set-Up
Dynamic establishment of optical channel trails and lightpaths is Dynamic establishment of optical channel trails and lightpaths is
quite desirable in IP over optical networks, especially when such quite desirable in IP over optical networks, especially when such
skipping to change at line 1752 skipping to change at line 1752
number of flows (e.g., lightpaths) that can be processed number of flows (e.g., lightpaths) that can be processed
concurrently. concurrently.
Another possible short term reason for dynamic shortcut lightpath Another possible short term reason for dynamic shortcut lightpath
setup would be to quickly pre-provisioned paths based on some setup would be to quickly pre-provisioned paths based on some
criteria (TOD, CEO wants a high BW reliable connection, etc.). In criteria (TOD, CEO wants a high BW reliable connection, etc.). In
this scenario, a set of paths is pre-provisioned, but not actually this scenario, a set of paths is pre-provisioned, but not actually
instantiated until the customer initiates an authenticated and instantiated until the customer initiates an authenticated and
authorized setup requests, which is consistent with existing authorized setup requests, which is consistent with existing
agreements between the provider and the customer. In a sense, the agreements between the provider and the customer. In a sense, the
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
provider may have already agreed to supply this service, but will provider may have already agreed to supply this service, but will
only instantiate it by setting up a lightpath when the customer only instantiate it by setting up a lightpath when the customer
submits an explicit request. submits an explicit request.
9.5 Distributed vs. Centralized Provisioning 9.5 Distributed vs. Centralized Provisioning
This draft has mainly dealt with a distributed model for lightpath This draft has mainly dealt with a distributed model for lightpath
provisioning, in which all nodes maintain a synchronized topology provisioning, in which all nodes maintain a synchronized topology
database, and advertise topology state information to maintain and database, and advertise topology state information to maintain and
skipping to change at line 1806 skipping to change at line 1806
filters, etc. Under certain circumstances, it may be necessary to filters, etc. Under certain circumstances, it may be necessary to
parameterize the characteristics of these components and advertise parameterize the characteristics of these components and advertise
them within the control plane. This aspect is left for further them within the control plane. This aspect is left for further
study. study.
9.7 Optical Networks with Limited Wavelength Conversion Capability 9.7 Optical Networks with Limited Wavelength Conversion Capability
At the time of the writing of this document, the majority of optical At the time of the writing of this document, the majority of optical
networks being deployed are "opaque". In this context the term networks being deployed are "opaque". In this context the term
opaque means that each link is optically isolated by transponders opaque means that each link is optically isolated by transponders
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
doing optical-electrical-optical conversions. Such conversions have doing optical-electrical-optical conversions. Such conversions have
the added benefit of permitting 3R regeneration. The 3Rs refer to the added benefit of permitting 3R regeneration. The 3Rs refer to
re-power, signal retiming and reshaping. Unfortunately, this re-power, signal retiming and reshaping. Unfortunately, this
regeneration requires that the underlying optical equipment be aware regeneration requires that the underlying optical equipment be aware
of both the bit rate and frame format of the carried signal. These of both the bit rate and frame format of the carried signal. These
transponders are quite expensive and their lack of transparency transponders are quite expensive and their lack of transparency
constrains the rapid introduction of new services [20]. Thus there constrains the rapid introduction of new services [19]. Thus there
are strong motivators to introduce "domains of transparency" wherein are strong motivators to introduce "domains of transparency" wherein
all-optical networking equipment would transport data unfettered by all-optical networking equipment would transport data unfettered by
these drawbacks. these drawbacks.
Thus, the issue of IP over optical networking in all optical sub- Thus, the issue of IP over optical networking in all optical sub-
networks, and sub-networks with limited wavelength conversion networks, and sub-networks with limited wavelength conversion
capability merits special attention. In such networks, transmission capability merits special attention. In such networks, transmission
impairments resulting from the peculiar characteristics of optical impairments resulting from the peculiar characteristics of optical
communications complicate the process of path selection. These communications complicate the process of path selection. These
transmission impairments include loss, noise (due primarily to transmission impairments include loss, noise (due primarily to
amplifier spontaneous emission - ASE), dispersion (chromatic and amplifier spontaneous emission - ASE), dispersion (chromatic and
PMD), cross-talk, and non-linear effects. In such networks, the PMD), cross-talk, and non-linear effects. In such networks, the
feasibility of a path between two nodes is no longer simply a feasibility of a path between two nodes is no longer simply a
function of topology and resource availability but will also depend function of topology and resource availability but will also depend
on the accumulation of impairments along the path. If the impairment on the accumulation of impairments along the path. If the impairment
accumulation is excessive, the optical signal to noise ratio (OSNR) accumulation is excessive, the optical signal to noise ratio (OSNR)
and hence the electrical bit error rate (BER) at the destination and hence the electrical bit error rate (BER) at the destination
node may exceed prescribed thresholds, making the resultant optical node may exceed prescribed thresholds, making the resultant optical
channel unusable for data communication. The challenge in the channel unusable for data communication. The challenge in the
development of IP-based control plane for optical networks is to development of IP-based control plane for optical networks is to
abstract these peculiar characteristics of the optical layer [20] in abstract these peculiar characteristics of the optical layer [19] in
a generic fashion, so that they can be used for path computation. a generic fashion, so that they can be used for path computation.
10. Evolution Path for IP over Optical Architecture 10. Evolution Path for IP over Optical Architecture
The architectural models described in Section 7 imply a certain The architectural models described in Section 7 imply a certain
degree of implementation complexity. Specifically, the overlay degree of implementation complexity. Specifically, the overlay
model was described as the least complex for near term deployment model was described as the least complex for near term deployment
and the peer model the most complex. Nevertheless, each model has and the peer model the most complex. Nevertheless, each model has
certain advantages and this raises the question as to the evolution certain advantages and this raises the question as to the evolution
path for IP over optical network architectures. path for IP over optical network architectures.
skipping to change at line 1862 skipping to change at line 1862
interconnection), with no routing exchange between the IP and interconnection), with no routing exchange between the IP and
optical domains. Under this model, direct signaling between IP optical domains. Under this model, direct signaling between IP
routers and optical networks is likely to be triggered by offline routers and optical networks is likely to be triggered by offline
traffic engineering decisions. The next step in the evolution of IP- traffic engineering decisions. The next step in the evolution of IP-
optical interaction is the introduction of reachability information optical interaction is the introduction of reachability information
exchange between the two domains. This would potentially allow exchange between the two domains. This would potentially allow
lightpaths to be established as part of end-to-end LSP set-up. The lightpaths to be established as part of end-to-end LSP set-up. The
final phase is the support for the full peer model with more final phase is the support for the full peer model with more
sophisticated routing interaction between IP and optical domains. sophisticated routing interaction between IP and optical domains.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
Using a common signaling framework (based on GMPLS) from the Using a common signaling framework (based on GMPLS) from the
beginning facilitates this type of evolution. For the domain beginning facilitates this type of evolution. For the domain
services model, implementation agreement based on GMPLS UNI services model, implementation agreement based on GMPLS UNI
signaling is being developed in the Optical Interworking Forum (OIF) signaling is being developed in the Optical Interworking Forum (OIF)
[5, 6]. This agreement is aimed at near term deployment and this [5, 6]. This agreement is aimed at near term deployment and this
could be the precursor to a future peer model architecture. In this could be the precursor to a future peer model architecture. In this
evolution, the signaling capability and semantics at the IP-optical evolution, the signaling capability and semantics at the IP-optical
boundary would become more sophisticated, but the basic structure of boundary would become more sophisticated, but the basic structure of
signaling would remain. This would allow incremental developments as signaling would remain. This would allow incremental developments as
the interconnection model becomes more sophisticated, rather than the interconnection model becomes more sophisticated, rather than
complete re-development of signaling capabilities. complete re-development of signaling capabilities.
From a routing point of view, the use of Network Management Systems
(NMS) for static connection management is prevelant in legacy
optical networks. Going forward, it can be expected that connection
routing using the control plane will be gradually introduced and
integrated into operational infrastructures. The introduction of
routing capabilities can be expected to occur in a phased approach.
It is likely that in the first phase, service providers will either
upgrade existing local element management (EMS) software with
additional control plane capabilities (and perhaps the hardware as
well), or updrade the NMS software in order to introduce some degree
of automation within each optical subnetwork. For this reason, it
may be desirable to partition the network into subnetworks and
introduce IGP interoperability within each subnetwork (i.e. at the
I-NNI level), and employ either static or signaled interoperability
between subnetworks. Consequently, it can be envisioned that the
first phase in the evolution towards network level control plane
interoperability in IP over Optical networks will be organized
around a system of optical subnetworks which are interconnected
statically (or dynamically in a signaled configuration). During this
phase, an overlay interconnection model will be used between the
optical network itself and external IP and MPLS routers (as
described in Section 7.2.3).
Progressing with this phased approach to IPO routing
interoperabibility evolution, the next level of integration will be
achieved when a single carrier provides dynamic optical routing
interoperability between subnetworks and between domains. In order
to become completely independent of the network switching capability
within subnetworks and across domains, routing information exchange
may need to be enabled at the UNI level. This would constitute a
significant evolution: even if the routing instances are kept
separate and independent, it would still be possible to dynamicallhy
exchange reachability and other types of routing information.
Another more sophisticated step during this phase is to introduce
dynamic routing at the E-NNI level. This means that any neighboring
networks (independent of internal switching capability) would be
capable of exchanging routing information with peers across the E-
NNI.
draft-ietf-ipo-framework-01.txt
Another alternative would be for private networks to bypass these
intermediate steps and directly consider an integrated routing model
from the onset. This direct evolution strategy is realistic, but is
more likely to occur in operational contexts where both the IP (or
MPLS) and optical networks are built simultaneously, using equipment
from a single source or from multiple sources that are closely
affiliated. In any case, due the current lack of operational
experience in managing this degree of control plane interaction in a
heterogenous network (these issues may exist even if the hardware
and software originate from the same vendor), an augmented model is
likely to be the most viable initial option. Alternatively, a very
modular or hierarchical peer model may be contemplated. There may be
other challenges (not just of a technical, but also administrative
and even political issues) that may be need to be resolved in order
to achieve full a peer model at the routing level in a multi-
technology and multi-vendor environment. Ultimately, the main
technical improvement would likely arise from efficiencies derived
from the integration of traffic-engineering capabilities in the
dynamic inter-domain routing environments.
11. Security Considerations 11. Security Considerations
TBD. This draft introduces no new security considerations for any IETF
protocol.
12. Summary and Conclusions 12. Summary and Conclusions
The objective of this draft was to define a framework for IP over The objective of this draft was to define a framework for IP over
optical networks, considering the service models, routing and optical networks, considering the service models, routing and
signaling issues. There are a diversity of choices, as described signaling issues. There are a diversity of choices, as described
in this draft, for IP-optical interconnection, service models in this draft, for IP-optical interconnection, service models
and protocol mechanisms. The approach advocated in this draft and protocol mechanisms. The approach advocated in this draft
was to allow different service models and proprietary enhancements was to allow different service models and proprietary enhancements
in optical networks, and define complementary signaling and in optical networks, and define complementary signaling and
skipping to change at line 1902 skipping to change at line 1964
IP-optical interaction is first based on the domain services model IP-optical interaction is first based on the domain services model
with overlay interconnection that eventually evolves to support full with overlay interconnection that eventually evolves to support full
peer interaction. peer interaction.
13. References 13. References
1. D. Awduche and Y. Rekhter, , "Multi-Protocol 1. D. Awduche and Y. Rekhter, , "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering Control With Lambda Switching: Combining MPLS Traffic Engineering Control With
Optical Crossconnects," IEEE Communications Magazine, March 2001. Optical Crossconnects," IEEE Communications Magazine, March 2001.
2. J. P. Lang, et. al., "Link Management Protocol," draft-ietf-mpls- 2. J. P. Lang, et. al., "Link Management Protocol," Internet Draft,
lmp-03.txt, Internet Draft, Work in progress. Work in progress.
3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE," draft- draft-ietf-ipo-framework-01.txt
ietf-mpls-lsp-hierarchy-01.txt, Work in Progress, November, 2000.
4. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling Functional 3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE,"
Description", draft-ietf-mpls-generalized-signaling-04.txt, Internet Draft, Work in progress.
Internet Draft, Work in Progress.
draft-ietf-ipo-framework-00.txt 4. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling Functional
Description", Internet Draft, Work in Progress.
5. E. Gray, et. al., "RSVP Extensions in Support of OIF Optical UNI 5. B. Rajagopalan, "LMP, LDP and RSVP Extensions for Optical UNI
Signaling," draft-gray-mpls-rsvp-oif-uni-ext-00.txt, Internet Signaling," Internet Draft, Work in Progress.
Draft, Work in Progress, October, 2000.
6. O. Abul-Magd, et. al., "LDP Extensions for Optical UNI 6. The Optical Interworking Forum, "UNI 1.0 Signaling
Signaling," draft-ietf-mpls-ldp-optical-uni-00.txt, Internet Specification," December, 2001.
Draft, Work in Progress, October, 2000.
7. K. Kompella et al, "OSPF Extensions in Support of Generalized 7. K. Kompella et al, "OSPF Extensions in Support of Generalized
MPLS," draft-kompella-ospf-gmpls-extensions-00.txt, Work in MPLS," Internet Draft, Work in Progress.
Progress, November, 2000.
8. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC 8. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC
1771, March, 1995. 1771, March, 1995.
9. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999. 9. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999.
10. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling 10. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling
Functional Description," draft-ietf-mpls-generalized-cr-ldp- Functional Description," Internet Draft, Work in Progress.
03.txt, Internet Draft, Work in Progress.
11. P. Ashwood-Smith, et. al., "Generalized MPLS - RSVP-TE 11. P. Ashwood-Smith, et. al., "Generalized MPLS - RSVP-TE
Signaling Functional Description," draft-ietf-mpls-generalized- Signaling Functional Description", Internet Draft, Work in
rsvp-te-03.txt, Internet Draft, Work in Progress. Progress.
12. , et. al., "Enhancements to GMPLS Signaling for Optical 12. E. Mannie, et. al., "GMPLS Extensions for SONET/SDH Control,"
Technologies," draft-mack-crane-gmpls-signaling-enchancements- Internet Draft, Work in Progress.
00.txt, Internet Draft, Work in Progress, November, 2000.
13. B. Doshi, S. Dravida, P. Harshavardhana, et. al, "Optical 13. B. Doshi, S. Dravida, P. Harshavardhana, et. al, "Optical
Network Design and Restoration," Bell Labs Technical Journal, Network Design and Restoration," Bell Labs Technical Journal,
Jan-March, 1999. Jan-March, 1999.
14. K. Kompella, et al., "Link Bundling in MPLS Traffic 14. K. Kompella, et al., "Link Bundling in MPLS Traffic
Engineering," draft-kompella-mpls-bundle-05.txt, Internet Draft, Engineering," Internet Draft, Work in Progress.
Work in Progress.
15. S. Ramamurthy, Z. Bogdanowicz, S. Samieian, et al., "Capacity 15. S. Ramamurthy, Z. Bogdanowicz, S. Samieian, et al., "Capacity
Performance of Dynamic Provisioning in Optical Networks", to Performance of Dynamic Provisioning in Optical Networks", J. of
appear in J. of Lightwave Technology. Lightwave Technology, January, 2001.
16. E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, "A 16. E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, "A
Framework for QoS-based Routing in the Internet," RFC 2386, Framework for QoS-based Routing in the Internet," RFC 2386,
August, 1998. August, 1998.
17. D. Awduche, L. Berger, Der-Hwa Gan, T. Li, G. Swallow, V. 17. D. Awduche, L. Berger, Der-Hwa Gan, T. Li, G. Swallow, V.
Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels,"draft- Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC
ietf-mpls-rsvp-lsp-tunnel-08.txt, Internet Draft, Work in 3209.
progress.
18. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4, 18. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4,
1974. 1974.
draft-ietf-ipo-framework-00.txt draft-ietf-ipo-framework-01.txt
19. B. Rajagopalan, D. Saha, G. Bernstein and V. Sharma, "Signaling
for fast restoration in optical mesh networks," draft-bala-
restoration-signaling-00.txt, Internet Draft, Work in Progress.
20. A. Chie et al., "Impairments And Other Constraints On Optical 19. A. Chie et al., "Impairments And Other Constraints On Optical
Layer Routing", draft-ietf-ipo-impairments-00.txt, Internet Layer Routing", Internet Draft, Work in Progress.
Draft, Work in Progress.
14. Acknowledgments 14. Acknowledgments
We would like to thank Zouheir Mansourati of Movaz Networks and Ian We would like to thank Zouheir Mansourati of Movaz Networks, Ian
Duncan of Nortel Networks for their comments on this draft. Duncan of Nortel Networks, and Dimitri Papadimitriou of Alcatel for
their comments on this draft.
15. Author's Addresses 15. Author's Addresses
Bala Rajagopalan James V. Luciani Bala Rajagopalan James V. Luciani
Debanjan Saha Crescent Networks Debanjan Saha Crescent Networks
Tellium, Inc. 900 Chelmsford St. Tellium, Inc. 900 Chelmsford St.
2 Crescent Place Lowell, MA 01851 2 Crescent Place Lowell, MA 01851
P.O. Box 901 Email: jluciani@CrescentNetworks.com P.O. Box 901 Email: jluciani@CrescentNetworks.com
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Email: {braja, dsaha}@tellium.com Email: {braja, dsaha}@tellium.com
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/