< draft-many-ip-optical-framework-02.txt   draft-many-ip-optical-framework-03.txt >
Bala Rajagopalan Bala Rajagopalan
Internet Draft Tellium, Inc. Internet Draft Tellium, Inc.
draft-many-ip-optical-framework-02.txt James Luciani draft-many-ip-optical-framework-03.txt James Luciani
Expires on: 5/14/2001 Tollbridge Technologies Expires on: 9/3/2001 Tollbridge Technologies
Daniel Awduche Daniel Awduche
UUNET (MCI Worldcom) UUNET (MCI Worldcom)
Brad Cain, Bilel Jamoussi Brad Cain, 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
Status of this Memo Status of this Memo
skipping to change at line 49 skipping to change at page 2, line 5
high-speed routers interconnected by optical core networks. A high-speed routers interconnected by optical core networks. A
consensus has emerged in the industry on utilizing IP-based consensus has emerged in the industry on utilizing IP-based
protocols for the optical control plane. At the same time, there is protocols for the optical control plane. At the same time, there is
ongoing activity in defining architectural models for IP transport ongoing activity in defining architectural models for IP transport
over optical networks, specifically, the routing and signaling over optical networks, specifically, the routing and signaling
aspects. This draft defines a framework for IP over Optical aspects. This draft defines a framework for IP over Optical
networks, considering both the IP-based control plane for optical networks, considering both the IP-based control plane for optical
networks as well as IP transport over optical networks (together networks as well as IP transport over optical networks (together
referred to as "IP over optical networks"). referred to as "IP over optical networks").
Expires on 5/24/2001 Page 1 of 36
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 ----------------------------------------- 7 5. The Network Model..........................................8
5.1 Network Interconnection -------------------------------- 7 5.1 Network Interconnection................................8
5.2 Control Structure -------------------------------------- 9 5.2 Control Structure.....................................10
6. IP over Optical Service Models ---------------------------- 9 6. IP over Optical Service Models and Requirements...........11
6.1 Domain Services Model ---------------------------------- 10 6.1 Domain Services Model.................................11
6.2 Unified Services Model --------------------------------- 12 6.2 Unified Service Model.................................13
6.3 Which Service Model? ----------------------------------- 13 6.3 Which Service Model?..................................14
6.4 What are the Possible Services? ------------------------ 13 6.4 What are the Possible Services?........................14
7. IP Transport over Optical Networks ----------------------- 14 7. IP transport over Optical Networks........................14
7.1 Interconnection Models --------------------------------- 14 7.1 Interconnection Models.................................15
7.2 Routing Approaches ------------------------------------- 15 7.2 Routing Approaches.....................................16
7.3 Signaling Related ------------------------------------- 18 7.3 Signaling-Related......................................19
7.4 End-to-End Protection Models --------------------------- 19 7.4 End-to-End Protection Models..........................20
8. IP-Based Optical Control Plane Issues -------------------- 20 8. IP-based Optical Control Plane Issues.....................22
8.1 Addressing -------------------------------------------- 21 8.1 Addressing............................................22
8.2 Neighbor Discovery ------------------------------------- 22 8.2 Neighbor Discovery....................................23
8.3 Topology Discovery --------------------------------------23 8.3 Topology Discovery....................................24
8.4 Restoration Models ------------------------------------- 24 8.4 Restoration Models....................................25
8.5 Route Computation ------------------------------------- 25 8.5 Route Computation.....................................26
8.6 Signaling Issues -------------------------------------- 27 8.6 Signaling Issues......................................28
8.7 Optical Internetworking ------------------------------- 29 8.7 Optical Internetworking..............................30
9. Other Issues --------------------------------------------- 30 9. Other Issues..............................................31
9.1 WDM and TDM in the Same Network ------------------------ 30 9.1 WDM and TDM in the Same Network......................31
9.2 Wavelength Conversion ---------------------------------- 30 9.2 Wavelength Conversion................................31
9.3 Service Provider Peering Points ------------------------ 31 9.3 Service Provider Peering Points......................32
9.4 Rate of Lightpath Set-Up ------------------------------- 31 9.4 Rate of Lightpath Set-Up.............................32
9.5 Distributed vs Centralized Provisioning --------------- 32 9.5 Distributed vs. Centralized Provisioning.............33
10. Evolution Path for IP over Optical Architecture --------- 33 10. Evolution Path for IP over Optical Architecture.........34
11. Security Considerations --------------------------------- 33 11. Security Considerations..................................34
12. Summary and Conclusions --------------------------------- 34 12. Summary and Conclusions..................................35
13. References ---------------------------------------------- 34 13. References...............................................35
14. Acknowledgements ---------------------------------------- 35 14. Acknowledgments..........................................36
15. Author's Addresses.......................................37
Expires on 5/24/01 Page 2 of 36
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
functions and capabilities. The increasing importance of optical functions and capabilities. The increasing importance of optical
skipping to change at line 144 skipping to change at page 4, line 7
of their pros and cons. of their pros and cons.
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
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.
Expires on 5/24/01 Page 3 of 36
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
depend on the services expected at the IP-optical interface as well depend on the services expected at the IP-optical interface as well
as the optical sub-network interfaces. Depending on the specific as the optical sub-network interfaces. Depending on the specific
operational requirements, a progression of capabilities is possible, operational requirements, a progression of capabilities is possible,
reflecting increasingly sophisticated interactions at these reflecting increasingly sophisticated interactions at these
interfaces. This draft therefore advocates the definition of interfaces. This draft therefore advocates the definition of
skipping to change at line 184 skipping to change at page 4, line 46
relation to IP over optical networks. The approaches described in relation to IP over optical networks. The approaches described in
Section 7 and 8 range from the relatively simple to the Section 7 and 8 range from the relatively simple to the
sophisticated. Section 10 describes a possible evolution path for IP sophisticated. Section 10 describes a possible evolution path for IP
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 some terminology for describing common This section introduces the terminology pertinent to this framework
concepts in IP over optical networks pertinent to this framework. and some related concepts.
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,
Expires on 5/24/01 Page 4 of 36
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,
Ethernet, ATM, etc.) Ethernet, ATM, etc.) For example, there are many commercial WDM
networks in existence today that support a mix of SONET signals
operating at OC-48c (approximately 2.5 Gbps) and OC-192
(approximately 10 Gbps) over a single optical fiber. An optical
system with WDM capability can achieve parallel transmission of
multiple wavelengths gracefully while maintaining high system
performance and reliability. In the near future, commercial WDM
systems are expected to concurrently carry more than 160
wavelengths at data rates of OC-192c and above, for a total of 1.6
Tbps or more. The term WDM will be used in this document to refer
to both WDM and DWDM (Dense WDM).
In general, it is worth noting that WDM links are affected by the
following factors, which may introduce impairments into the optical
signal path:
1. The number of wavelengths on a single fiber.
2. The serial bit rate per wavelength.
3. The type of fiber.
4. The amplification mechanism.
5. The number of nodes through which the signal passes before
it reaches the egress node or before regeneration.
All these factors and others not mentioned here constitute domain
specific features of optical transport networks. As noted in [1],
these features should be taken into account in developing standards
based solutions for IP over optical networks.
Optical cross-connect (OXC) Optical cross-connect (OXC)
--------------------------- ---------------------------
An OXC is a space-division switch that can switch an optical data An OXC is a space-division switch that can switch an optical data
stream on an input port to a output port. Such a switch may have stream on an input port to a output port. Such a switch may have
optical-electrical conversion at the input port and electrical- optical-electrical conversion at the input port and electrical-
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
skipping to change at line 249 skipping to change at page 6, line 35
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.
Optical mesh network Optical mesh network
-------------------- --------------------
An optical mesh network, as considered in draft, is a mesh-connected An optical mesh network, as considered in draft, is a mesh-connected
collection of optical sub-networks. collection of optical sub-networks.
Expires on 5/24/01 Page 5 of 36
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.
Wavelength path
---------------
A lightpath that satisfies the wavelength continuity property is
called a wavelength path.
Opaque vs. transparent optical networks
---------------------------------------
A transparent optical network is an optical network in which each
transit node along a path passes optical transmission without
transducing the optical signal into an electrical signal and back
to an optical signal. More generally, all intermediate nodes in a
transparent optical network will pass optical signals without
performing retiming and reshaping and thus such nodes are unaware of
many characteristics of the carried signals. One could, for
example, carry analog signals together with digital signals
(potentially of varying bit rate) on different wavelengths over such
a network.
Note that re-powering of signals at transit nodes is potentially
permitted in transparent optical networks. This is a result of the
availability of all optical amplification devices such as Erbium
Doped Fiber Amplifiers (EDFAs).
In opaque optical networks, by comparison, transit nodes will
perform manipulation of the optical signals which they are carrying.
An example of such manipulation would be 3R (reshaping, retiming,
regeneration/amplification).
Trust domain Trust domain
------------ ------------
A trust domain is a network under a single technical administration A trust domain is a network under a single technical administration
in which most nodes in the network are considered to be secure or in which most nodes in the network are considered to be secure or
trusted in some fashion. An example of a trust domain is a campus trusted in some fashion. An example of a trust domain is a campus
or corporate network in which all routing protocol packets are or corporate network in which all routing protocol packets are
considered to be authentic, without the need for additional security considered to be authentic, without the need for additional security
schemes to prevent unauthorized access to the network schemes to prevent unauthorized access to the network
infrastructure. Generally, the "single" administrative control rule infrastructure. Generally, the "single" administrative control rule
skipping to change at line 295 skipping to change at page 8, line 5
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
------------- -------------
A abstraction of traffic flow that follows the same path between two A abstraction of traffic flow that follows the same path between two
access points which allows some characteristics and attributes of access points which allows some characteristics and attributes of
the traffic to be parameterized. the traffic to be parameterized.
Expires on 5/24/01 Page 6 of 36
5. The Network Model 5. The Network Model
5.1 Network Interconnection 5.1 Network Interconnection
The network model considered in this draft consists of IP routers The network model considered in this draft consists of IP routers
attached to an optical core network, and connected to their peers attached to an optical core network, and connected to their peers
over dynamically established switched lightpaths. The optical core over dynamically established switched lightpaths. The optical core
itself is assumed to be incapable of processing individual IP itself is assumed to be incapable of processing individual IP
packets. packets.
skipping to change at line 348 skipping to change at page 9, line 4
same set of intermediate ports as the forward path. same set of intermediate ports as the forward path.
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 latter 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
Expires on 5/24/01 Page 7 of 36
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.
Optical Network Optical Network
+---------------------------------------+ +---------------------------------------+
| | | |
+--------------+ | | +--------------+ | |
| | | +------------+ +------------+ | | | | +------------+ +------------+ |
| IP | | | | | | | | IP | | | | | | |
skipping to change at line 397 skipping to change at page 10, line 5
between a pair of IP routers before they can communicate. This between a pair of IP routers before they can communicate. This
lightpath might traverse multiple optical sub-networks and be lightpath might traverse multiple optical sub-networks and be
subject to different provisioning and restoration procedures in each subject to different provisioning and restoration procedures in each
sub-network. The IP-based control plane issue is that of designing sub-network. The IP-based control plane issue is that of designing
standard signaling and routing protocols for coherent end-to-end standard signaling and routing protocols for coherent end-to-end
provisioning and restoration of lightpaths across multiple optical provisioning and restoration of lightpaths across multiple optical
sub-networks. Similarly, IP transport over such an optical network sub-networks. Similarly, IP transport over such an optical network
involves determining IP reachability and seamless establishment of involves determining IP reachability and seamless establishment of
paths from one IP endpoint to another over an optical core. paths from one IP endpoint to another over an optical core.
Expires on 5/24/01 Page 8 of 36
5.2 Control Structure 5.2 Control Structure
There are two logical control interfaces identified in Figure 1. There are two logical control interfaces identified in Figure 1.
These are the client-optical network interface, and the optical sub- These are the client-optical network interface, and the optical sub-
network interface. These interfaces are also referred to as the network interface. These interfaces are also referred to as the
User-Network Interface (UNI) and the Network-Network Interface(NNI). User-Network Interface (UNI) and the Network-Network Interface(NNI).
The distinction between these interfaces arises out of the type and The distinction between these interfaces arises out of the type and
amount of control flow across them. The UNI represents a technology amount of control flow across them. The UNI represents a technology
boundary between the client and optical networks. Thus, the control boundary between the client and optical networks. Thus, the control
flow across the UNI is dependent of the set of services defined flow across the UNI is dependent of the set of services defined
skipping to change at line 432 skipping to change at page 10, line 39
then routing information is not exchanged across it, or such then routing information is not exchanged across it, or such
information may be exchanged across it with very explicit information may be exchanged across it with very explicit
restrictions (including for example abstraction, filtration, etc). restrictions (including for example abstraction, filtration, etc).
Thus, different relationships (e.g., peer or over-lay, Section 7) Thus, different relationships (e.g., peer or over-lay, Section 7)
may occur across private and public logical interfaces. may occur across private and public logical interfaces.
The physical control structure used to realize these logical The physical control structure used to realize these logical
interfaces may vary. For instance, for the UNI, some of the interfaces may vary. For instance, for the UNI, some of the
possibilities are: possibilities are:
1.Direct interface: An in-band or out-of-band IP control channel 1. Direct interface: An in-band or out-of-band IP control channel
(IPCC) may be implemented between an edge router and each OXC (IPCC) may be implemented between an edge router and each OXC
that it connects to. This control channel is used for exchanging that it connects to. This control channel is used for exchanging
signaling and routing messages between the router and the OXC. signaling and routing messages between the router and the OXC.
With a direct interface, the edge router and the OXC it connects With a direct interface, the edge router and the OXC it connects
to are peers in the control plane. This is shown in Figure 2. The to are peers in the control plane. This is shown in Figure 2. The
type of routing and signaling information exchanged across the type of routing and signaling information exchanged across the
direct interface would vary depending on the service definition. direct interface would vary depending on the service definition.
This issue is dealt with in the next section. Some choices for This issue is dealt with in the next section. Some choices for
the routing protocol are OSPF/ISIS (with traffic engineering the routing protocol are OSPF/ISIS (with traffic engineering
extensions) or BGP. Other directory-based routing information extensions) or BGP. Other directory-based routing information
exchanges are also possible. Some of the signaling protocol exchanges are also possible. Some of the signaling protocol
choices are adaptations of RSVP-TE or CR-LDP. The details of how choices are adaptations of RSVP-TE or CR-LDP. The details of how
the IP control channel is realized is outside the scope of this the IP control channel is realized is outside the scope of this
draft. draft.
2.Indirect interface: An out-of-band IP control channel may be 2. Indirect interface: An out-of-band IP control channel may be
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
Expires on 5/24/01 Page 9 of 36
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.
3. Provisioned interface: In this case, the optical network services 3. Provisioned interface: In this case, the optical network services
are manually provisioned and there is no control interactions are manually provisioned and there is no control interactions
skipping to change at line 505 skipping to change at page 12, line 5
interface (which can also be applied at the optical sub-network interface (which can also be applied at the optical sub-network
interface). These models are as follows. interface). These models are as follows.
6.1 Domain Services Model 6.1 Domain Services Model
Under this model, the optical network primarily offers high Under this model, the optical network primarily offers high
bandwidth connectivity in the form of lightpaths [2]. Standardized bandwidth connectivity in the form of lightpaths [2]. Standardized
signaling across the UNI (Figure 1) is used to invoke the following signaling across the UNI (Figure 1) is used to invoke the following
services: services:
Expires on 5/24/01 Page 10 of 36 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.
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.
Additionally, the following address resolution procedures may be Additionally, the following address resolution procedures may be
made available over the UNI (more sophisticated routing information made available over the UNI (more sophisticated routing information
exchange over the UNI is also possible, as described later and exchange over the UNI is also possible, as described later and
covered in more detail in [3]): covered in more detail in [3]):
1. Client Registration: This allows a client to register its 1. Client Registration: This allows a client to register its
address(es) and user group identifier(s) with the optical address(es) and user group identifier(s) with the optical
network. The registered address may be of different types, IP, network. The registered address may be of different types, IP,
ATM NSAP, E.164, etc. The optical network associates the client ATM NSAP, E.164, etc. The optical network associates the client
skipping to change at line 558 skipping to change at page 13, line 5
determine the static parameters of the interconnection with the determine the static parameters of the interconnection with the
optical network, including the UNI signaling protocols supported. optical network, including the UNI signaling protocols supported.
The protocols for neighbor and service discovery are different from The protocols for neighbor and service discovery are different from
the UNI signaling protocol itself (for example, see LMP [4]). the UNI signaling protocol itself (for example, see LMP [4]).
With regard to address resolution, the registration and de- With regard to address resolution, the registration and de-
registration procedures may be implemented using service discovery registration procedures may be implemented using service discovery
mechanisms. The query mechanism may be implemented as an additional mechanisms. The query mechanism may be implemented as an additional
UNI signaling procedure. UNI signaling procedure.
Expires on 5/24/01 Page 11 of 36
Because a small set of well-defined services is offered across UNI, Because a small set of well-defined services is offered across UNI,
the signaling protocol requirements are minimal. Specifically, the the signaling protocol requirements are minimal. Specifically, the
signaling protocol is required to convey a few messages with certain signaling protocol is required to convey a few messages with certain
attributes point-to-point between the router and the optical attributes point-to-point between the router and the optical
network. Such a protocol may be based on RSVP-TE or LDP, or even a network. Such a protocol may be based on RSVP-TE or LDP, or even a
messaging application over a TCP connection. messaging application over a TCP connection.
The optical domain services model does not deal with the type and The optical domain services model does not deal with the type and
nature of routing protocols within the optical network. Furthermore, nature of routing protocols within the optical network. Furthermore,
the integration of multiple, optical sub-networks across NNI will the integration of multiple, optical sub-networks across NNI will
skipping to change at line 611 skipping to change at page 14, line 5
optical networks in routing protocols such as OSPF [6]. In essence, optical networks in routing protocols such as OSPF [6]. In essence,
once a lightpath is established across an optical network between once a lightpath is established across an optical network between
two edge routers, it can be advertised as a forwarding adjacency (a two edge routers, it can be advertised as a forwarding adjacency (a
virtual link) between these routers. Thus, from a data plane point virtual link) between these routers. Thus, from a data plane point
of view, the lightpaths result in a overlay between edge routers. of view, the lightpaths result in a overlay between edge routers.
The decisions as to when to create such lightpaths, and the The decisions as to when to create such lightpaths, and the
bandwidth management for these lightpaths is identical in both the bandwidth management for these lightpaths is identical in both the
domain services model and the unified service model. The routing and domain services model and the unified service model. The routing and
signaling models for unified services is described in Section 7. signaling models for unified services is described in Section 7.
Expires on 5/24/01 Page 12 of 36
6.3 Which Service Model? 6.3 Which Service Model?
The pros and cons of the above service models can be debated at The pros and cons of the above service models can be debated at
length, but the approach recommended in this framework is to define length, but the approach recommended in this framework is to define
routing and signaling mechanisms in support of both. As pointed out routing and signaling mechanisms in support of both. As pointed out
above, signaling for service request can be unified to cover both above, signaling for service request can be unified to cover both
models. The developments in GMPLS signaling [7] for the unified models. The developments in GMPLS signaling [7] for the unified
service model and its adoption for UNI signaling under the domain service model and its adoption for UNI signaling under the domain
services model [8] essentially supports this view. The significant services model [8] essentially supports this view. The significant
difference between the service models, however, is in routing difference between the service models, however, is in routing
skipping to change at line 665 skipping to change at page 15, line 5
based control plane [1] is used. Depending on the service based control plane [1] is used. Depending on the service
model(Section 6), however, the control planes in the IP and optical model(Section 6), however, the control planes in the IP and optical
networks can be loosely or tightly coupled. This coupling determines networks can be loosely or tightly coupled. This coupling determines
o the details of the topology and routing information advertised by o the details of the topology and routing information advertised by
the optical network across UNI; the optical network across UNI;
o Level of control that IP routers can exercise in selecting o Level of control that IP routers can exercise in selecting
specific paths for connections across the optical network; and specific paths for connections across the optical network; and
Expires on 5/24/01 Page 13 of 36
o Policies regarding the dynamic provisioning of optical paths o Policies regarding the dynamic provisioning of optical paths
between routers. This includes access control, accounting and between routers. This includes access control, accounting and
security issues. security issues.
The following interconnection models are then possible: The following interconnection models are then possible:
7.1 Interconnection Models 7.1 Interconnection Models
7.1.1 The Peer Model 7.1.1 The Peer Model
skipping to change at line 715 skipping to change at page 16, line 5
Under the augmented model, there are actually separate routing Under the augmented model, there are actually separate routing
instances in the IP and optical domains, but information from one instances in the IP and optical domains, but information from one
routing instance is passed through the other routing instance. For routing instance is passed through the other routing instance. For
example, external IP addresses could be carried within the optical example, external IP addresses could be carried within the optical
routing protocols to allow reachability information to be passed to routing protocols to allow reachability information to be passed to
IP clients. IP clients.
The routing approaches corresponding to these interconnection models The routing approaches corresponding to these interconnection models
are described below. are described below.
Expires on 5/24/01 Page 14 of 36
7.2 Routing Approaches 7.2 Routing Approaches
7.2.1 Integrated Routing 7.2.1 Integrated Routing
This routing approach supports the peer model described above. Under This routing approach supports the peer model described above. Under
this approach, the IP and optical networks are assumed to run the this approach, the IP and optical networks are assumed to run the
same instance of an IP routing protocol, e.g., OSPF with suitable same instance of an IP routing protocol, e.g., OSPF with suitable
"optical" extensions. These extensions must capture optical link "optical" extensions. These extensions must capture optical link
parameters, and any constraints that are specific to optical parameters, and any constraints that are specific to optical
networks. The topology and link state information maintained by all networks. The topology and link state information maintained by all
skipping to change at line 770 skipping to change at page 17, line 5
port is no longer available for creating a lightpath. Thus, as FAs port is no longer available for creating a lightpath. Thus, as FAs
are created, an overlaid set of virtual links is introduced into the are created, an overlaid set of virtual links is introduced into the
link state representation, replacing the links previously advertised link state representation, replacing the links previously advertised
at the IP-Optical interface. Finally, the details of the optical at the IP-Optical interface. Finally, the details of the optical
network captured in the link state representation is replaced by a network captured in the link state representation is replaced by a
network of FAs. In this regard, there is a great deal of similarity network of FAs. In this regard, there is a great deal of similarity
between integrated routing and domain-specific routing (described between integrated routing and domain-specific routing (described
next). Both ultimately deal with the creation of the overlaid next). Both ultimately deal with the creation of the overlaid
lightpath topology to meet the traffic engineering objectives. lightpath topology to meet the traffic engineering objectives.
Expires on 5/24/01 Page 15 of 36
7.2.2 Domain-Specific Routing 7.2.2 Domain-Specific Routing
This routing approach supports the augmented interconnection model. This routing approach supports the augmented interconnection model.
Under this approach, routing within the optical and IP domains are Under this approach, routing within the optical and IP domains are
separated, with a standard routing protocol running between domains. separated, with a standard routing protocol running between domains.
This is similar to the IP inter-domain routing model. Two choices This is similar to the IP inter-domain routing model. Two choices
for this are considered. for this are considered.
7.2.2.1 Domain-Specific Routing using BGP 7.2.2.1 Domain-Specific Routing using BGP
skipping to change at line 824 skipping to change at page 18, line 5
advertised by the border OXCs must be accompanied by some VPN advertised by the border OXCs must be accompanied by some VPN
identification (for example, VPN IPv4 addresses, as defined in [10], identification (for example, VPN IPv4 addresses, as defined in [10],
may be used). may be used).
7.2.2.2 Domain Specific Routing using OSPF/ISIS 7.2.2.2 Domain Specific Routing using OSPF/ISIS
The routing information exchanged across the IP-optical UNI could be The routing information exchanged across the IP-optical UNI could be
summarized using a hierarchical routing protocol such as OSPF/ISIS. summarized using a hierarchical routing protocol such as OSPF/ISIS.
The following description is based on OSPF. The following description is based on OSPF.
Expires on 5/24/01 Page 16 of 36
OSPF supports a two-level hierarchical routing scheme through the OSPF supports a two-level hierarchical routing scheme through the
use of OSPF areas. Routing within each area is flat, while detailed use of OSPF areas. Routing within each area is flat, while detailed
knowledge of an areaÆs topology is hidden from all other areas. knowledge of an areaÆs topology is hidden from all other areas.
Routers attached to two or more areas are called Area Border Routers Routers attached to two or more areas are called Area Border Routers
(ABRs). ABRs propagate IP addressing information from one area to (ABRs). ABRs propagate IP addressing information from one area to
another using summary LSAs. Within an OSPF routing domain, all areas another using summary LSAs. Within an OSPF routing domain, all areas
are attached directly to a special area called the OSPF backbone are attached directly to a special area called the OSPF backbone
area. The exchange of information between areas can be controlled area. The exchange of information between areas can be controlled
to implement domain specific routing in each area. For instance, the to implement domain specific routing in each area. For instance, the
optical network can be a collection of one or more areas in which optical network can be a collection of one or more areas in which
skipping to change at line 875 skipping to change at page 19, line 5
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.
Routing approaches in optical networks are further described in [3]. Routing approaches in optical networks are further described in [3].
Expires on 5/24/01 Page 17 of 36
7.3 Signaling-Related 7.3 Signaling-Related
7.3.1 The Role of MPLS 7.3.1 The Role of MPLS
It is possible to model wavelengths, and potentially TDM channels It is possible to model wavelengths, and potentially TDM channels
within a wavelength as "labels". This concept was proposed in [1], within a wavelength as "labels". This concept was proposed in [1],
and ôgeneralizedö MPLS (GMPLS) mechanisms for realizing this are and "Generalized" MPLS (GMPLS) mechanisms for realizing this are
described in [7]. MPLS signaling protocols with traffic engineering described in [7]. MPLS signaling protocols with traffic engineering
extensions, such as RSVP-TE and CR-LDP can be used for signaling extensions, such as RSVP-TE and CR-LDP can be used for signaling
lightpath requests. In the case of the domain services model, these lightpath requests. In the case of the domain services model, these
protocols can be adapted for UNI signaling [11, 12]. In the case of protocols can be adapted for UNI signaling [11, 12]. In the case of
the unified services model, lightpath establishment occurs to the unified services model, lightpath establishment occurs to
support end-to-end LSP establishment using these protocols (with support end-to-end LSP establishment using these protocols (with
suitable GMPLS enhancements [13, 14]). suitable GMPLS enhancements [13, 14]).
7.3.2 Signaling Models 7.3.2 Signaling Models
skipping to change at line 928 skipping to change at page 20, line 4
Figure 3: Domain Services Signaling Model Figure 3: Domain Services Signaling Model
With the unified services model, the addressing is common in the IP With the unified services model, the addressing is common in the IP
and optical networks and the respective signaling control are and optical networks and the respective signaling control are
related, as shown in Figure 4. It is understood that GMPLS signaling related, as shown in Figure 4. It is understood that GMPLS signaling
is implemented in the IP and optical networks, using suitably is implemented in the IP and optical networks, using suitably
enhanced RSVP-TE and CR-LDP protocols. But the semantics of services enhanced RSVP-TE and CR-LDP protocols. But the semantics of services
within the optical network may be different from that in the IP within the optical network may be different from that in the IP
network. As an example, the protection services offered in the network. As an example, the protection services offered in the
optical network may be different from that end-to-end protection optical network may be different from that end-to-end protection
Expires on 5/24/01 Page 18 of 36
services offered by the IP network. Another example is with regard services offered by the IP network. Another example is with regard
to bandwidth. While the IP network may offer a continuum of to bandwidth. While the IP network may offer a continuum of
bandwidths, the optical network will offer only discrete bandwidths. bandwidths, the optical network will offer only discrete bandwidths.
Thus, the signaling attributes and services are defined Thus, the signaling attributes and services are defined
independently for IP and optical networks. The routers at the edge independently for IP and optical networks. The routers at the edge
of the optical network must therefore identify service boundaries of the optical network must therefore identify service boundaries
and perform suitable translations in the signaling messages crossing and perform suitable translations in the signaling messages crossing
the IP-optical boundary. This must occur even though the signaling the IP-optical boundary. This must occur even though the signaling
control plane in both networks are GMPLS-based and there is tighter control plane in both networks are GMPLS-based and there is tighter
coupling of the control plane as compared to the domain services coupling of the control plane as compared to the domain services
skipping to change at line 960 skipping to change at page 20, line 34
+-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+ +-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+
Common Address Space, Service Translation Common Address Space, Service Translation
Figure 4: Unified Services Signaling Model Figure 4: Unified Services Signaling Model
Thus, as illustrated in Figure 4, the signaling in the case of Thus, as illustrated in Figure 4, the signaling in the case of
unified services is actually multi-layered. The layering is based on unified services is actually multi-layered. The layering is based on
the technology and functionality. As an example, the specific the technology and functionality. As an example, the specific
adaptations of GMPLS signaling for SONET layer (whose functionality adaptations of GMPLS signaling for SONET layer (whose functionality
is transport) are described in [15]. is transport) are described in [7].
7.4 End-to-End Protection Models 7.4 End-to-End Protection Models
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 network and router across an ingress IP network, a transit optical network and
an egress IP network. If this LSP is to be afforded protection in 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 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:
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
network. Thus, the end-to-end LSP would be treated as a network. 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
Expires on 5/24/01 Page 19 of 36
network and a segment in the egress IP network. The protection network 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
suitable protection services offered by the optical network. Suppose suitable protection services offered by the optical network. Suppose
that 1+1 protection is offered to LSPs at the IP layer, i.e., each that 1+1 protection is offered to LSPs at the IP layer, i.e., each
protected LSP has a pre-established hot stand-by. In case of a protected LSP has a pre-established hot stand-by. In case of a
failure of the primary LSP, traffic can be immediately switched to failure of the primary LSP, traffic can be immediately switched to
the stand-by. This type of protection can be realized end-to-end as the stand-by. This type of protection can be realized end-to-end as
follows. With reference to Figure 5, let an LSP originate at follows. With reference to Figure 5, let an LSP originate at
(ingress) router interface A and terminate at (egress) router (ingress) router interface A and terminate at (egress) router
interface F. Under the first protection option, a primary path for interface F. Under the first protection option, a primary path for
skipping to change at line 1033 skipping to change at page 22, line 4
protection, whereas under the second choice, any protection service protection, whereas under the second choice, any protection service
offered in the optical network is not utilized. Also, under the offered in the optical network is not utilized. Also, under the
first choice, the protection in the optical network may apply first choice, the protection in the optical network may apply
collectively to a number of IP LSPs. That is, with reference to collectively to a number of IP LSPs. That is, with reference to
Figure 5, many LSPs may be aggregated into a single lightpath Figure 5, many LSPs may be aggregated into a single lightpath
between C and D. The optical network protection may then be applied between C and D. The optical network protection may then be applied
to all of them at once leading to some scalability. Under the second to all of them at once leading to some scalability. Under the second
choice, each IP LSP must be separately protected. Finally, the first choice, each IP LSP must be separately protected. Finally, the first
choice allows different restoration signaling to be implemented in choice allows different restoration signaling to be implemented in
the IP and optical network. These restoration protocols are "patched the IP and optical network. These restoration protocols are "patched
Expires on 5/24/01 Page 20 of 36
up" at the service boundaries to realize end-to-end protection. A up" at the service boundaries to realize end-to-end protection. A
further advantage of this is that restoration is entirely contained further advantage of this is that restoration is entirely contained
within the network where the failure occurs, thereby improving the within the network where the failure occurs, thereby improving the
restoration latency. For instance, if there is a failure in the restoration latency. For instance, if there is a failure in the
optical network, optical network protocols restore the segment optical network, optical network protocols restore the segment
within. Under the second choice, restoration signaling is always within. Under the second choice, restoration signaling is always
end-to-end between IP routers, essentially by-passing the optical end-to-end between IP routers, essentially by-passing the optical
network. A result of this is that restoration latency could be network. A result of this is that restoration latency could be
higher. In addition, restoration protocol in the IP layer must run higher. In addition, restoration protocol in the IP layer must run
transparently over the optical network in the overlay mode. transparently over the optical network in the overlay mode.
skipping to change at line 1087 skipping to change at page 23, line 4
adequate granularity when establishing optical trails. For instance, adequate granularity when establishing optical trails. For instance,
an OXC could have many ports, each of which may in turn terminate an OXC could have many ports, each of which may in turn terminate
many optical channels, each of which contain many subchannels etc. many optical channels, each of which contain many subchannels etc.
It is perhaps not reasonable to assume that every sub-channel or It is perhaps not reasonable to assume that every sub-channel or
channel termination, or even OXC ports could be assigned a unique IP channel termination, or even OXC ports could be assigned a unique IP
address. Also, the routing of an optical trail within the network address. Also, the routing of an optical trail within the network
does not depend on the precise termination point information, but does not depend on the precise termination point information, but
rather only on the terminating OXC. Thus, finer granularity rather only on the terminating OXC. Thus, finer granularity
identification of termination points is of relevance only to the identification of termination points is of relevance only to the
terminating OXC and not to intermediate OXCs (of course, resource terminating OXC and not to intermediate OXCs (of course, resource
Expires on 5/24/01 Page 21 of 36
allocation at each intermediate point would depend on the allocation at each intermediate point would depend on the
granularity of resources requested). This suggests an identification granularity of resources requested). This suggests an identification
scheme whereby OXCs are identified by a unique IP address and a scheme whereby OXCs are identified by a unique IP address and a
"selector" identifies further fine-grain information of relevance at "selector" identifies further fine-grain information of relevance at
an OXC. This, of course, does not preclude the identification of an OXC. This, of course, does not preclude the identification of
these termination points directly with IP addresses(with a null these termination points directly with IP addresses(with a null
selector). The selector can be formatted to have adequate number of selector). The selector can be formatted to have adequate number of
bits and a structure that expresses port, channel, sub-channel, etc, bits and a structure that expresses port, channel, sub-channel, etc,
identification. identification.
Within the optical network, the establishment of trail segments Within the optical network, the establishment of trail segments
between adjacent OXCs require the identification of specific port, between adjacent OXCs require the identification of specific port,
channel, sub-channel, etc. With an MPLS-based control plane, a label channel, sub-channel, etc. With an MPLS-based control plane, a label
serves this function. The structure of the "optical label" must be serves this function. The structure of the "optical label" must be
such that it can encode the required information [7]. such that it can encode the required information [7].
Another entity that must be identified is the SRLG [16]. An Another entity that must be identified is the SRLG [15]. 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
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
identified with a flat identifier (e.g., 32 bit integer). identified with a flat identifier (e.g., 32 bit integer).
Finally, optical links between adjacent OXCs may be bundled for Finally, optical links between adjacent OXCs may be bundled for
advertisementinto a link state protocol [16]. A bundled interface advertisementinto a link state protocol [15]. A bundled interface
may be numbered or unnumbered. In either case, the component links may be numbered or unnumbered. In either case, the component links
within the bundle must be identifiable. In concert with SRLG within the bundle must be identifiable. In concert with SRLG
identification, this information is necessary for correct path identification, this information is necessary for correct path
computation [16]. computation [15].
8.2 Neighbor Discovery 8.2 Neighbor Discovery
Routing within the optical network relies on knowledge of network Routing within the optical network relies on knowledge of network
topology and resource availability. This information may be gathered topology and resource availability. This information may be gathered
and used by a centralized system, or by a distributed link state and used by a centralized system, or by a distributed link state
routing protocol. In either case, the first step towards network- routing protocol. In either case, the first step towards network-
wide link state determination is the discovery of the status of wide link state determination is the discovery of the status of
local links to all neighbors by each OXC. Specifically, each OXC local links to all neighbors by each OXC. Specifically, each OXC
must determine the up/down status of each optical link, the must determine the up/down status of each optical link, the
Expires on 5/24/01 Page 22 of 36
bandwidth and other parameters of the link, and the identity of the bandwidth and other parameters of the link, and the identity of the
remote end of the link (e.g., remote port number). The last piece of remote end of the link (e.g., remote port number). The last piece of
information is used to specify an appropriate label when signaling information is used to specify an appropriate label when signaling
for lightpath provisioning. The determination of these parameters for lightpath provisioning. The determination of these parameters
could be based on a combination of manual configuration and an could be based on a combination of manual configuration and an
automated protocol running between adjacent OXCs. The automated protocol running between adjacent OXCs. The
characteristics of such a protocol would depend on the type of OXCs characteristics of such a protocol would depend on the type of OXCs
that are adjacent (e.g., transparent or opaque). Generically, the that are adjacent (e.g., transparent or opaque). Generically, the
protocol may be refered to as the "Neighbor Discovery Protocol protocol may be refered to as the "Neighbor Discovery Protocol
(NDP)" although other functions such as link management and fault (NDP)" although other functions such as link management and fault
skipping to change at line 1192 skipping to change at page 25, line 4
+------+-----+ +------+-----+ +------+-----+ +------+-----+
Figure 6: Mesh Optical Network with SRLGs Figure 6: Mesh Optical Network with SRLGs
8.3 Topology Discovery 8.3 Topology Discovery
Topology discovery is the procedure by which the topology and Topology discovery is the procedure by which the topology and
resource state of all the links in a sub-network are determined. resource state of all the links in a sub-network are determined.
Topology discovery may be done using a link state routing protocol Topology discovery may be done using a link state routing protocol
(e.g., OSPF, ISIS), or it can be through a management protocol (in (e.g., OSPF, ISIS), or it can be through a management protocol (in
Expires on 5/24/01 Page 23 of 36
the case of centralized path computation). The focus in this the case of centralized path computation). The focus in this
framework is on fully distributed route computation using an IP link framework is on fully distributed route computation using an IP link
state protocol. state protocol.
In general, most of the link state routing functionality is In general, most of the link state routing functionality is
maintained when applied to optical networks. However, the maintained when applied to optical networks. However, the
representation of optical links, as well as some link parameters, representation of optical links, as well as some link parameters,
are changed in this setting. Specifically, are changed in this setting. Specifically,
o The link state information may consist of link bundles [16]. o The link state information may consist of link bundles [15].
Each link bundle is represented as an abstract link in the network Each link bundle is represented as an abstract link in the network
topology. Different bundling representations are possible. For topology. Different bundling representations are possible. For
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 [16]. Also, the SRLGs corresponding to each underlying link bundle [15]. 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.
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
skipping to change at line 1246 skipping to change at page 26, line 4
networks. There could be local and end-to-end mechanisms for networks. There could be local and end-to-end mechanisms for
restoration of lightpaths within a sub-network. Local mechanisms are restoration of lightpaths within a sub-network. Local mechanisms are
used to select an alternate link between two adjacent OXCs when a used to select an alternate link between two adjacent OXCs when a
failure affects the primary link over which the (protected) failure affects the primary link over which the (protected)
lightpath is being routed. Local restoration does not affect the lightpath is being routed. Local restoration does not affect the
end-to-end route of the lightpath. When local restoration is not end-to-end route of the lightpath. When local restoration is not
possible (e.g., no alternate link is available between the adjacent possible (e.g., no alternate link is available between the adjacent
OXCs in question), end-to-end restoration may be performed. With OXCs in question), end-to-end restoration may be performed. With
this, the affected lightpath may be rerouted over an alternate path this, the affected lightpath may be rerouted over an alternate path
that completely avoids the OXCs or the link segment where the that completely avoids the OXCs or the link segment where the
Expires on 5/24/01 Page 24 of 36
failure occurred. For end-to-end restoration, alternate paths are failure occurred. For end-to-end restoration, alternate paths are
typically pre-computed. Such back-up paths may have to be physically typically pre-computed. Such back-up paths may have to be physically
diverse from the corresponding primary paths. diverse from the corresponding primary paths.
End-to-end restoration may be based on two types of protection End-to-end restoration may be based on two types of protection
schemes; "1 + 1" protection or shared protection. Under 1 + 1 schemes; "1 + 1" protection or shared protection. Under 1 + 1
protection, a back-up path is established for the protected primary protection, a back-up path is established for the protected primary
path along a physically diverse route. Both paths are active and the path along a physically diverse route. Both paths are active and the
failure along the primary path results in an immediate switch-over failure along the primary path results in an immediate switch-over
to the back-up path. Under shared protection, back-up paths to the back-up path. Under shared protection, back-up paths
skipping to change at line 1270 skipping to change at page 26, line 26
assumed that the same failure will not affect the other primary assumed that the same failure will not affect the other primary
paths whose back-ups share resources. paths whose back-ups share resources.
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
sub-network is essentially a constraint-based routing problem. The sub-network is essentially a constraint-based routing problem. The
constraint is typically the bandwidth required for the lightpath, constraint is typically the bandwidth required for the lightpath,
perhaps along with administrative and policy constraints. The perhaps along with administrative and policy constraints. The
objective of path computation could be to minimize the total objective of path computation could be to minimize the total
capacity required for routing lightpaths [17]. capacity required for routing lightpaths [16].
Route computation with constraints may be accomplished using a Route computation with constraints may be accomplished using a
number of algorithms [18]. When 1+1 protection is used, a back-up number of algorithms [17]. When 1+1 protection is used, a back-up
path that does not traverse on any link which is part of the same path that does not traverse on any link which is part of the same
SRLG as links in the primary path must be computed. Thus, it is SRLG as links in the primary path must be computed. Thus, it is
essential that the SRLGs in the primary path be known during essential that the SRLGs in the primary path be known during
alternate path computation, along with the availability of alternate path computation, along with the availability of
resources in links that belong to other SRLGs. This requirement has resources in links that belong to other SRLGs. This requirement has
certain implications on optical link bundling. Specifically, a certain implications on optical link bundling. Specifically, a
bundled LSA must include adequate information such that a remote OXC bundled LSA must include adequate information such that a remote OXC
can determine the resource availability under each SRLG that the can determine the resource availability under each SRLG that the
bundled link refers to, and the relationship between links bundled link refers to, and the relationship between links
belonging to different SRLGs in the bundle. For example, belonging to different SRLGs in the bundle. For example,
skipping to change at line 1298 skipping to change at page 27, line 5
It is somewhat complex to encode the SRLG relationships in a link It is somewhat complex to encode the SRLG relationships in a link
bundle LSA. This information, however, is naturally captured if the bundle LSA. This information, however, is naturally captured if the
link bundle is encoded as a set of "link groups", each specifying link bundle is encoded as a set of "link groups", each specifying
the links that belong to exactly the same set of SRLGs. Within the the links that belong to exactly the same set of SRLGs. Within the
link group, it is possible to specify the number of links of a link group, it is possible to specify the number of links of a
particular type, for example, OC-48. With reference to Figure 3, particular type, for example, OC-48. With reference to Figure 3,
for example, a bundle LSA can be advertised for the entire set of for example, a bundle LSA can be advertised for the entire set of
links between OXC1 and OXC2, with the following information: links between OXC1 and OXC2, with the following information:
Expires on 5/24/01 Page 25 of 36
Link Group ID SRLGs Link Type Number Other Info Link Group ID SRLGs Link Type Number Other Info
------------- ----- --------- ------ ---------- ------------- ----- --------- ------ ----------
1 1,2 OC-48 3 --- 1 1,2 OC-48 3 ---
2 1,3 OC-192 1 --- 2 1,3 OC-192 1 ---
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
skipping to change at line 1333 skipping to change at page 27, line 39
groups in a bundle) rather than specific link group level groups in a bundle) rather than specific link group level
information. In this case, the primary path computation information. In this case, the primary path computation
procedure would output a series of bundles the path traverses. procedure would output a series of bundles the path traverses.
Each OXC in the path would have the freedom to choose the Each OXC in the path would have the freedom to choose the
particular link group to route that segment of the primary particular link group to route that segment of the primary
path. This procedure would increase the chances of successfully path. This procedure would increase the chances of successfully
setting up the primary path when link state information is not setting up the primary path when link state information is not
up to date everywhere. But the specific link group chosen, and up to date everywhere. But the specific link group chosen, and
hence the SRLGs in the primary path, must be captured during hence the SRLGs in the primary path, must be captured during
primary path set-up, for example, using the RSVP-TE Route primary path set-up, for example, using the RSVP-TE Route
Record Object [19]. This SRLG information is then used for Record Object [18]. This SRLG information is then used for
computing the back-up path. The back-up path may also be computing the back-up path. The back-up path may also be
established specifying only which SRLGs to AVOID in a given established specifying only which SRLGs to AVOID in a given
segment, rather than which link groups to use. This would segment, rather than which link groups to use. This would
maximize the chances of establishing the back-up. maximize the chances of establishing the back-up.
2. The primary path and the back-up path are comptuted together in 2. The primary path and the back-up path are comptuted together in
one step, for example, using Suurbaale's algorithm [20]. In this one step, for example, using Suurbaale's algorithm [19]. In this
case, the paths must be computed using specific link group case, the paths must be computed using specific link group
information. information.
To summarize, it is essential to capture sufficient information in To summarize, it is essential to capture sufficient information in
link bundle LSAs to accommodate different path computation link bundle LSAs to accommodate different path computation
procedures and to maximize the chances of successful path procedures and to maximize the chances of successful path
establishment. Depending on the path computation procedure used, establishment. Depending on the path computation procedure used,
the type of support needed during path establishment (e.g., the the type of support needed during path establishment (e.g., the
recording of link group or SRLG information during path recording of link group or SRLG information during path
establishment) may differ. establishment) may differ.
Expires on 5/24/01 Page 26 of 36
When shared protection is used, the route computation algorithm must When shared protection is used, the route computation algorithm must
take into account the possibility of sharing links among multiple take into account the possibility of sharing links among multiple
back-up paths. Under shared protection, the back-up paths back-up paths. Under shared protection, the back-up paths
corresponding to SRLG-disjoint primary paths can be assigned the corresponding to SRLG-disjoint primary paths can be assigned the
same links. The assumption here is that since the primary paths same links. The assumption here is that since the primary paths
are not routed over links that have the same SRLG, a given failure are not routed over links that have the same SRLG, a given failure
will affect only one of them. Furthermore, it is assumed that will affect only one of them. Furthermore, it is assumed that
multiple failure events affecting links belonging to more than one multiple failure events affecting links belonging to more than one
SRLG will not occur concurrently. Unlike the case of 1+1 SRLG will not occur concurrently. Unlike the case of 1+1
protection, the back-up paths are not established apriori. Rather, a protection, the back-up paths are not established apriori. Rather, a
skipping to change at line 1374 skipping to change at page 28, line 26
corresponding to the affected primary path. corresponding to 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
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 [17, 21]. further described in [16, 20].
8.6 Signaling Issues 8.6 Signaling Issues
Signaling within an optical sub-network for lightpath provisioning Signaling within an optical sub-network for lightpath provisioning
is a relatively simple operation. After a route is determined for a is a relatively simple operation. After a route is determined for a
lightpath, each OXC in the path must establish appropriate cross- lightpath, each OXC in the path must establish appropriate cross-
connects in a coordinated fashion. This coordination is akin to connects in a coordinated fashion. This coordination is akin to
selecting incoming and outgoing labels in a label-switched selecting incoming and outgoing labels in a label-switched
environment. Thus, protocols like RSVP-TE [14] and CR-LDP [13] can environment. Thus, protocols like RSVP-TE [14] and CR-LDP [13] can
be used for this. A few new concerns, however, must be addressed. be used for this. A few new concerns, however, must be addressed.
skipping to change at line 1404 skipping to change at page 29, line 5
select output port i which is connected to input port j of the select output port i which is connected to input port j of the
"next" OXC B. Concurrently, OXC B may select output port j for "next" OXC B. Concurrently, OXC B may select output port j for
setting up a different optical path, where the "next" OXC is A. This setting up a different optical path, where the "next" OXC is A. This
results in a "collision". Similarly, when WDM functionality is built results in a "collision". Similarly, when WDM functionality is built
into OXCs, a collision occurs when adjacent OXCs choose directly into OXCs, a collision occurs when adjacent OXCs choose directly
connected output ports and the same wavelength for two different connected output ports and the same wavelength for two different
optical paths. There are two ways to deal with such collisions. optical paths. There are two ways to deal with such collisions.
First, collisions may be detected and the involved paths may be torn First, collisions may be detected and the involved paths may be torn
down and re-established. Or, collisions may be avoided altogether. down and re-established. Or, collisions may be avoided altogether.
Expires on 5/24/01 Page 27 of 36
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
skipping to change at line 1458 skipping to change at page 30, line 4
point of failure, and activation of the back-up path. The signaling point of failure, and activation of the back-up path. The signaling
for these two phases must be very fast in order to realize response for these two phases must be very fast in order to realize response
times in the order of tens of milliseconds. When optical links are times in the order of tens of milliseconds. When optical links are
SONET-based, in-band signals may be used, resulting in quick SONET-based, in-band signals may be used, resulting in quick
response. With out-of-band control, it is necessary to consider response. With out-of-band control, it is necessary to consider
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
Expires on 5/24/01 Page 28 of 36
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. exclusively for activating protection paths during restoration.
8.7 Optical Internetworking 8.7 Optical Internetworking
Ideally, a set of interconnected optical sub-networks must be Ideally, a set of interconnected optical sub-networks must be
skipping to change at line 1512 skipping to change at page 31, line 4
and across sub-networks. and across sub-networks.
8.7.2 Addressing and Routing Model 8.7.2 Addressing and Routing Model
The addressing mechanisms described in Section 8.1 can be used to The addressing mechanisms described in Section 8.1 can be used to
identify OXCs, ports, channels and sub-channels in each sub-network. identify OXCs, ports, channels and sub-channels in each sub-network.
It is essential that the OXC IP addresses are unique network-wide. It is essential that the OXC IP addresses are unique network-wide.
Provisioning an end-to-end lightpath across multiple sub-networks Provisioning an end-to-end lightpath across multiple sub-networks
involves the establishment of path segments in each sub-network involves the establishment of path segments in each sub-network
Expires on 5/24/01 Page 29 of 36
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 sub-network. From this border OXC, OXC to a border OXC in the source sub-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 sub-network. Provisioning then continues in the next OXC in the next sub-network. Provisioning then continues in the next
sub-network and so on until the destination OXC is reached. sub-network and so on until the destination OXC is reached.
A version of BGP may be used to determine the routes to destinations A version of BGP may be used to determine the routes to destinations
across sub-networks. Using exterior BGP, adjacent border OXCs in across sub-networks. Using exterior BGP, adjacent border OXCs in
different sub-networks can exchange reachability of OXCs and other different sub-networks can exchange reachability of OXCs and other
external IP endpoints (border routers). Using interior BGP, the same external IP endpoints (border routers). Using interior BGP, the same
skipping to change at line 1567 skipping to change at page 32, line 4
decisions. This would be somewhat akin to using VPI (e.g., decisions. This would be somewhat akin to using VPI (e.g.,
wavelength) and VCI (e.g., TDM sub-channel) in ATM networks. More wavelength) and VCI (e.g., TDM sub-channel) in ATM networks. More
generally, this will be akin to label stacking and to LSP nesting generally, this will be akin to label stacking and to LSP nesting
within the context of Multi-Protocol Lambda Switching [1]. GMPLS within the context of Multi-Protocol Lambda Switching [1]. GMPLS
signaling [7] supports this type of multiplexing. signaling [7] supports this type of multiplexing.
9.2 Wavelength Conversion 9.2 Wavelength Conversion
Some form of wavelength conversion may exist at some switching Some form of wavelength conversion may exist at some switching
elements. This however may not be case in some pure optical elements. This however may not be case in some pure optical
Expires on 5/24/01 Page 30 of 36
switching elements. A switching element is essentially anything switching elements. A switching element is essentially anything
more sophisticated than a simple repeater, that is capable of more sophisticated than a simple repeater, that is capable of
switching and converting a wavelength Lambda(k) from an input port switching and converting a wavelength Lambda(k) from an input port
to a wavelength Lambda(l) on an output port. In this display, it to a wavelength Lambda(l) on an output port. In this display, it
is not necessarily the case that Lambda(k) = Lambda(l), nor is it is not necessarily the case that Lambda(k) = Lambda(l), nor is it
necessarily the case that the data carried on Lambda(k) is switched necessarily the case that the data carried on Lambda(k) is switched
through the device without being examined or modified. through the device without being examined or modified.
It is not necessary to have a wavelength converter at every It is not necessary to have a wavelength converter at every
switching element. A number of studies have attempted to address switching element. A number of studies have attempted to address
skipping to change at line 1623 skipping to change at page 33, line 5
core networks has not been widely adopted by carriers and ISPs for a core networks has not been widely adopted by carriers and ISPs for a
number of reasons: possible CPU overhead in core network elements, number of reasons: possible CPU overhead in core network elements,
complexity of proposed solutions, stability concerns, and lack of complexity of proposed solutions, stability concerns, and lack of
true economic drivers for this type of service. This draft assumes true economic drivers for this type of service. This draft assumes
that this paradigm will not change and that highly dynamic, data- that this paradigm will not change and that highly dynamic, data-
driven shortcut lightpath setups are for future investigation. driven shortcut lightpath setups are for future investigation.
Instead, the optical channel trails and lightpaths that are expected Instead, the optical channel trails and lightpaths that are expected
to be widely used at the initial phases in the evolution of IP over to be widely used at the initial phases in the evolution of IP over
optical networks will include the following: optical networks will include the following:
Expires on 5/24/01 Page 31 of 36
o Dynamic connections for control plane traffic and default path o Dynamic connections for control plane traffic and default path
routed data traffic, routed data traffic,
o Establishment and re-arrangement of arbitrary virtual topologies o Establishment and re-arrangement of arbitrary virtual topologies
over rings and other physical layer topologies. over rings and other physical layer topologies.
o Use of stable traffic engineering control systems to engineer o Use of stable traffic engineering control systems to engineer
lightpath connections to enhance network performance, either for lightpath connections to enhance network performance, either for
explicit demand based QoS reasons or for load balancing). explicit demand based QoS reasons or for load balancing).
skipping to change at line 1674 skipping to change at page 34, line 4
Another provisioning model is to have a centralized server which has Another provisioning model is to have a centralized server which has
complete knowledge of the physical topology, the available complete knowledge of the physical topology, the available
wavelengths, and where applicable, relevant time domain information. wavelengths, and where applicable, relevant time domain information.
A corresponding client will reside on each network element that can A corresponding client will reside on each network element that can
source or sink a lightpath. The source client would query the source or sink a lightpath. The source client would query the
server in order to set up a lightpath from the source to the server in order to set up a lightpath from the source to the
destination. The server would then check to see if such a lightpath destination. The server would then check to see if such a lightpath
can be established based on prevailing conditions. Furthermore, can be established based on prevailing conditions. Furthermore,
depending on the specifics of the model, the server may either setup depending on the specifics of the model, the server may either setup
the lightpath on behalf of the client or provide the necessary the lightpath on behalf of the client or provide the necessary
Expires on 5/24/01 Page 32 of 36
information to the client or to some other entity to allow the information to the client or to some other entity to allow the
lightpath to be instantiated. lightpath to be instantiated.
Centralization aids in implementing complex capacity optimization Centralization aids in implementing complex capacity optimization
schemes, and may be the near-term provisioning solution in optical schemes, and may be the near-term provisioning solution in optical
networks with interconnected multi-vendor optical sub-networks. In networks with interconnected multi-vendor optical sub-networks. In
the long term, however, the distributed solution with centralization the long term, however, the distributed solution with centralization
of some control procedures (e.g., traffic engineering) is likely to of some control procedures (e.g., traffic engineering) is likely to
be the approach followed. be the approach followed.
skipping to change at line 1727 skipping to change at page 35, line 5
optical boundary would become more sophisticated, but the basic optical boundary would become more sophisticated, but the basic
structure of signaling would remain. This would allow incremental structure of signaling would remain. This would allow incremental
developments as the interconnection model becomes more developments as the interconnection model becomes more
sophisticated, rather than complete re-development of signaling sophisticated, rather than complete re-development of signaling
capabilities. capabilities.
11. Security Considerations 11. Security Considerations
TBD. TBD.
Expires on 5/24/01 Page 33 of 36
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
routing mechanisms that would support these. An evolution scenario, routing mechanisms that would support these. An evolution scenario,
skipping to change at line 1756 skipping to change at page 35, line 33
1. D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol 1. D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering Control Lambda Switching: Combining MPLS Traffic Engineering Control
With Optical Crossconnects," draft-awduche-mpls-te-optical- With Optical Crossconnects," draft-awduche-mpls-te-optical-
02.txt, Work in Progress, July, 2000. 02.txt, Work in Progress, July, 2000.
2. K. Arvind, et. al, "Optical Domain Services Interconnect (ODSI) 2. K. Arvind, et. al, "Optical Domain Services Interconnect (ODSI)
Signaling Control Specification, Version 1.4.5" www.odsi- Signaling Control Specification, Version 1.4.5" www.odsi-
coalition.com, March, 2000. coalition.com, March, 2000.
3. D. Pendarakis, B. Rajagopalan and D. Saha, "Routing Information 3. D. Pendarakis, B. Rajagopalan and D. Saha, "Routing Information
Exchange in Optical Networks," draft-prs-optical-routing-01.ps, Exchange in Optical Networks," draft-prs-optical-routing-02.ps,
Internet Draft, Work in Progress, November, 2000. Internet Draft, Work in Progress, March, 2001.
4. J. P. Lang, et. al., "Link Management Protocol," draft-ietf-mpls- 4. J. P. Lang, et. al., "Link Management Protocol," draft-ietf-mpls-
lmp-01.txt, Internet Draft, Work in progress, November, 2000. lmp-02.txt, Internet Draft, Work in progress, March, 2001.
5. K. Kompella et al, "OSPF Extensions in Support of Generalized 5. K. Kompella et al, "OSPF Extensions in Support of Generalized
MPLS," draft-kompella-ospf-gmpls-extensions-00.txt, Work in MPLS," draft-kompella-ospf-gmpls-extensions-00.txt, Work in
Progress, November, 2000. Progress, November, 2000.
6. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE," draft- 6. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE," draft-
ietf-mpls-lsp-hierarchy-01.txt, Work in Progress, November, 2000. ietf-mpls-lsp-hierarchy-01.txt, Work in Progress, November, 2000.
7. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling Functional 7. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling Functional
Description", draft-ietf-mpls-generalized-signaling-00.txt, Description", draft-ietf-mpls-generalized-signaling-02.txt,
Internet Draft, Work in Progress, November, 2000. Internet Draft, Work in Progress, March, 2001.
8. O. Abul-Magd, et. al., "Signaling Requirements at the Optical 8. O. Abul-Magd, et. al., "Signaling Requirements at the Optical
UNI," draft-bala-mpls-optical-uni-signaling-01.txt, Internet UNI," draft-bala-mpls-optical-uni-signaling-01.txt, Internet
Draft, Work in Progress, November, 2000. Draft, Work in Progress, November, 2000.
9. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC 9. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC
1771, March, 1995. 1771, March, 1995.
Expires on 5/24/01 Page 34 of 36
10. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 10. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March,
1999. 1999.
11. E. Gray, et. al., "RSVP Extensions in Support of OIF Optical 11. E. Gray, et. al., "RSVP Extensions in Support of OIF Optical
UNI Signaling," draft-gray-mpls-rsvp-oif-uni-ext-00.txt, Internet UNI Signaling," draft-gray-mpls-rsvp-oif-uni-ext-00.txt, Internet
Draft, Work in Progress, October, 2000. Draft, Work in Progress, October, 2000.
12. O. Abul-Magd, et. al., "LDP Extensions for Optical UNI 12. O. Abul-Magd, et. al., "LDP Extensions for Optical UNI
Signaling," draft-ietf-mpls-ldp-optical-uni-00.txt, Internet Signaling," draft-ietf-mpls-ldp-optical-uni-00.txt, Internet
Draft, Work in Progress, October, 2000. Draft, Work in Progress, October, 2000.
13. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling 13. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling
Functional Description," draft-ietf-mpls-generalized-cr-ldp- Functional Description," draft-ietf-mpls-generalized-cr-ldp-
00.txt, Internet Draft, Work in Progress, November, 2000. 00.txt, Internet Draft, Work in Progress, November, 2000.
14. P. Ashwood-Smith, et. al., "Generalized MPLS - RSVP-TE 14. P. Ashwood-Smith, et. al., "Generalized MPLS - RSVP-TE
Signaling Functional Description," draft-ietf-mpls-generalized- Signaling Functional Description," draft-ietf-mpls-generalized-
rsvp-te-00.txt, Internet Draft, Work in Progress, November, 2000. rsvp-te-00.txt, Internet Draft, Work in Progress, November, 2000.
15. B. Mack-Crane, et. al., "Enhancements to GMPLS Signaling for 15. B. Rajagopalan and D. Saha, "Link Bundling in Optical
Optical Technologies," draft-mack-crane-gmpls-signaling-
enchancements-00.txt, Internet Draft, Work in Progress, November,
2000.
16. B. Rajagopalan and D. Saha, "Link Bundling in Optical
Networks," draft-rs-optical-bundling-01.txt, Internet Draft, Work Networks," draft-rs-optical-bundling-01.txt, Internet Draft, Work
in Progress, October, 2000. in Progress, October, 2000.
17. B. Doshi, S. Dravida, P. Harshavardhana, et. al, "Optical 16. 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.
18. E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, "A 17. 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.
19. D. Awduche, L. Berger, Der-Hwa Gan, T. Li, G. Swallow, V. 18. 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,"draft-
ietf-mpls-rsvp-lsp-tunnel-07.txt, Internet Draft, Work in ietf-mpls-rsvp-lsp-tunnel-08.txt, Internet Draft, Work in
progress, October, 2000. progress, March, 2001.
20. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4, 19. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4,
1974. 1974.
21. S. Ramamurthy, Z. Bogdanowicz, S. Samieian, et al., "Capacity 20. S. Ramamurthy, Z. Bogdanowicz, S. Samieian, et al., "Capacity
Performance of Dynamic Provisioning in Optical Networks", to Performance of Dynamic Provisioning in Optical Networks", to
appear in J. of Lightwave Technology. appear in J. of Lightwave Technology.
14. Acknowledgments 14. Acknowledgments
We would like to thank Zouheir Mansourati and Ian Duncan of Nortel We would like to thank Zouheir Mansourati and Ian Duncan of Nortel
Networks for their comments on this draft. Networks for their comments on this draft.
Expires on 5/24/01 Page 35 of 36
15. Author's Addresses 15. Author's Addresses
Bala Rajagopalan James V. Luciani Bala Rajagopalan James V. Luciani
Debanjan Saha TollBridge Technologies Debanjan Saha TollBridge Technologies
Tellium, Inc. P,O. Box 1010 Tellium, Inc. P,O. Box 1010
2 Crescent Place Concord, MA 01742 2 Crescent Place Concord, MA 01742
P.O. Box 901 Email: james_luciani@mindspring.com P.O. Box 901 Email: james_luciani@mindspring.com
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Email: {braja, dsaha}@tellium.com Email: {braja, dsaha}@tellium.com
Daniel O. Awduche Brad Cain, Bilel Jamoussi Daniel O. Awduche Brad Cain, Bilel Jamoussi
UUNET (MCI Worldcom) Nortel Networks UUNET (MCI Worldcom) Nortel Networks
Loudoun County Parkway 600 Tech Park Loudoun County Parkway 600 Tech Park
Ashburn, VA 20247 Billerica, MA 01821 Ashburn, VA 20247 Billerica, MA 01821
Phone: 703-886-5277 Phone: 978-288-4734 Phone: 703-886-5277 Phone: 978-288-4734
Email: awduche@uu.net Email: bcain@nortelnetworks.com Email: awduche@uu.net Email: bcain@nortelnetworks.com
jamoussi@nortelnetworks.com jamoussi@nortelnetworks.com
******** This draft expires on May, 24, 2001 ***********
Expires on 5/24/01 Page 36 of 36
 End of changes. 68 change blocks. 
134 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/