draft-ietf-ipo-framework-01.txt   draft-ietf-ipo-framework-02.txt 
Bala Rajagopalan Bala Rajagopalan
Internet Draft Tellium, Inc. Internet Draft Tellium, Inc.
draft-ietf-ipo-framework-01.txt James Luciani
Expires on: 8/22/2002 Crescent Networks draft-ietf-ipo-framework-02.txt James Luciani
Expires on: 12/10/2002 Crescent Networks
Daniel Awduche Daniel Awduche
Movaz Networks Movaz Networks
Brad Cain Brad Cain
Cereva Networks Cereva Networks
Bilel Jamoussi Bilel Jamoussi
Nortel Networks Nortel Networks
Debanjan Saha Debanjan Saha
Tellium, Inc. Tellium, Inc.
IP over Optical Networks: A Framework IP over Optical Networks: A Framework
skipping to change at line 45 skipping to change at line 46
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
1. Abstract 1. Abstract
The Internet transport infrastructure is moving towards a model of The Internet transport infrastructure is moving towards a model of
high-speed routers interconnected by optical core networks. The high-speed routers interconnected by optical core networks. The
architectural choices for the interaction between IP and optical architectural choices for the interaction between IP and optical
network layers, specifically, the routing and signaling aspects, are network layers, specifically, the routing and signaling aspects, are
maturing. At the same time, a consensus has emerged in the industry maturing. At the same time, a consensus has emerged in the industry
on utilizing IP-based protocols for the optical control plane. This on utilizing IP-based protocols for the optical control plane. This
draft defines a framework for IP over Optical networks, considering document defines a framework for IP over Optical networks,
both the IP-based control plane for optical networks as well as IP- considering both the IP-based control plane for optical networks as
optical network interactions (together referred to as "IP over well as IP-optical network interactions (together referred to as "IP
optical networks"). over optical networks").
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
Table of Contents Table of Contents
----------------- -----------------
1. Abstract...........................................................1 1. Abstract...........................................................1
2. Conventions used in this document..................................3 2. Introduction.......................................................3
3. Introduction.......................................................3 3. Terminology and Concepts...........................................4
4. Terminology and Concepts...........................................4 4. The Network Model..................................................8
5. The Network Model..................................................8 4.1 Network Interconnection........................................8
5.1 Network Interconnection........................................8 4.2 Control Structure.............................................10
5.2 Control Structure.............................................10 5. IP over Optical Service Models and Requirements...................12
6. IP over Optical Service Models and Requirements...................12 5.1 Domain Services Model.........................................12
6.1 Domain Services Model.........................................12 5.2 Unified Service Model.........................................13
6.2 Unified Service Model.........................................13 5.3 Which Service Model?..........................................14
6.3 Which Service Model?..........................................14 5.4 What are the Possible Services?................................14
6.4 What are the Possible Services?................................14 6. IP transport over Optical Networks................................15
7. IP transport over Optical Networks................................15 6.1 Interconnection Models.........................................15
7.1 Interconnection Models.........................................15 6.2 Routing Approaches.............................................16
7.2 Routing Approaches.............................................16 6.3 Signaling-Related..............................................19
7.3 Signaling-Related..............................................19 6.4 End-to-End Protection Models..................................20
7.4 End-to-End Protection Models..................................20 7. IP-based Optical Control Plane Issues.............................22
8. IP-based Optical Control Plane Issues.............................22 7.1 Addressing....................................................23
8.1 Addressing....................................................23 7.2 Neighbor Discovery............................................24
8.2 Neighbor Discovery............................................24 7.3 Topology Discovery............................................25
8.3 Topology Discovery............................................25 7.4 Restoration Models............................................26
8.4 Restoration Models............................................26 7.5 Route Computation.............................................27
8.5 Route Computation.............................................27 7.6 Signaling Issues..............................................29
8.6 Signaling Issues..............................................29 7.7 Optical Internetworking.......................................31
8.7 Optical Internetworking......................................31 8. Other Issues......................................................32
9. Other Issues......................................................32 8.1 WDM and TDM in the Same Network..............................32
9.1 WDM and TDM in the Same Network..............................32 8.2 Wavelength Conversion........................................32
9.2 Wavelength Conversion........................................32 8.3 Service Provider Peering Points..............................32
9.3 Service Provider Peering Points..............................32 8.4 Rate of Lightpath Set-Up.....................................33
9.4 Rate of Lightpath Set-Up.....................................33 8.5 Distributed vs. Centralized Provisioning.....................34
9.5 Distributed vs. Centralized Provisioning.....................34 8.6 Optical Networks with Additional Configurable Components.....34
9.6 Optical Networks with Additional Configurable Components.....34 8.7 Optical Networks with Limited Wavelength Conversion Capability35
9.7 Optical Networks with Limited Wavelength Conversion Capability34 9. Evolution Path for IP over Optical Architecture..................35
10. Evolution Path for IP over Optical Architecture.................35 10. Security Considerations..........................................37
11. Security Considerations..........................................37 10.1 General security aspects......................................38
12. Summary and Conclusions..........................................37 10.2 Protocol Mechanisms...........................................39
13. References.......................................................37 11. Summary and Conclusions..........................................39
14. Acknowledgments..................................................39 12. References.......................................................39
15. Author's Addresses...............................................39 13. Acknowledgments..................................................40
draft-ietf-ipo-framework-01.txt 14. Author's Addresses...............................................41
draft-ietf-ipo-framework-02.txt
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
3. Introduction 2. 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
networks is evidenced by the copious amount of attention focused on networks is evidenced by the copious amount of attention focused on
IP over optical networks and related photonic and electronic IP over optical networks and related photonic and electronic
interworking issues by all the major network service providers, interworking issues by all the major network service providers,
telecommunications equipment vendors, and standards organizations. telecommunications equipment vendors, and standards organizations.
In this regard, the term "optical network" is used generically in In this regard, the term "optical network" is used generically in
practice to refer to both SONET/SDH-based transport networks, as practice to refer to both SONET/SDH-based transport networks, as
well as transparent all-optical networks. well as transparent all-optical networks.
skipping to change at line 147 skipping to change at line 143
understood to suitably adopt the IP-based protocols. This is understood to suitably adopt the IP-based protocols. This is
especially the case for restoration. Also, there are different especially the case for restoration. Also, there are different
views on the model for interaction between the optical network and views on the model for interaction between the optical network and
client networks, such as IP networks. Reasonable architectural client networks, such as IP networks. Reasonable architectural
alternatives in this regard must be supported, with an understanding alternatives in this regard must be supported, with an understanding
of their pros and cons. of their pros and cons.
Thus, there are two fundamental issues related to IP over optical Thus, there are two fundamental issues related to IP over optical
networks. The first is the adaptation and reuse of IP control plane networks. The first is the adaptation and reuse of IP control plane
protocols within the optical network control plane, irrespective of protocols within the optical network control plane, irrespective of
draft-ietf-ipo-framework-01.txt
the types of digital clients that utilize the optical network. The the types of digital clients that utilize the optical network. The
second is the transport of IP traffic through an optical network second is the transport of IP traffic through an optical network
together with the control and coordination issues that arise together with the control and coordination issues that arise
therefrom. therefrom.
This draft defines a framework for IP over optical networks covering draft-ietf-ipo-framework-02.txt
the requirements and mechanisms for establishing an IP-centric
optical control plane, and the architectural aspects of IP transport
over optical networks. In this regard, it is recognized that the
specific capabilities required for IP over optical networks would
depend on the services expected at the IP-optical interface as well
as the optical sub-network interfaces. Depending on the specific
operational requirements, a progression of capabilities is possible,
reflecting increasingly sophisticated interactions at these
interfaces. This draft therefore advocates the definition of
"capability sets" that define the evolution of functionality at the
interfaces as more sophisticated operational requirements arise.
This draft is organized as follows. In the next section, terminology This document defines a framework for IP over optical networks
covering certain concepts related to this framework are described. covering the requirements and mechanisms for establishing an IP-
In Section 5, the network model pertinent to this framework is centric optical control plane, and the architectural aspects of IP
described. The service model and requirements for IP-optical, and transport over optical networks. In this regard, it is recognized
multi-vendor optical internetworking are described in Section 6. that the specific capabilities required for IP over optical networks
This section presently considers certain general requirements. would depend on the services expected at the IP-optical interface as
Specific operational requirements may be accommodated in this well as the optical sub-network interfaces. Depending on the
section as they arise. Section 7 considers the architectural models specific operational requirements, a progression of capabilities is
for IP-optical interworking, describing the pros and cons of each possible, reflecting increasingly sophisticated interactions at
model. It should be noted that it is not the intent of this draft to these interfaces. This document therefore advocates the definition
promote any particular model over the others. However, particular of "capability sets" that define the evolution of functionality at
aspects of the models that may make one approach more appropriate the interfaces as more sophisticated operational requirements arise.
than another in certain circumstances are described. Section 8
describes IP-centric control plane mechanisms for optical networks,
covering signaling and routing issues in support of provisioning and
restoration. Section 9 describes certain specialized issues in
relation to IP over optical networks. The approaches described in
Section 7 and 8 range from the relatively simple to the
sophisticated. Section 10 describes a possible evolution path for IP
over optical networking capabilities in terms of increasingly
sophisticated functionality supported. Section 11 considers security
aspects. Finally, summary and conclusion are presented in Section
12.
4. Terminology and Concepts This document is organized as follows. In the next section,
terminology covering certain concepts related to this framework are
described. In Section 4, the network model pertinent to this
framework is described. The service model and requirements for IP-
optical, and multi-vendor optical internetworking are described in
Section 5. This section presently considers certain general
requirements. Specific operational requirements may be accommodated
in this section as they arise. Section 6 considers the
architectural models for IP-optical interworking, describing the
pros and cons of each model. It should be noted that it is not the
intent of this document to promote any particular model over the
others. However, particular aspects of the models that may make one
approach more appropriate than another in certain circumstances are
described. Section 7 describes IP-centric control plane mechanisms
for optical networks, covering signaling and routing issues in
support of provisioning and restoration. Section 8 describes certain
specialized issues in relation to IP over optical networks. The
approaches described in Section 7 and 8 range from the relatively
simple to the sophisticated. Section 9 describes a possible
evolution path for IP over optical networking capabilities in terms
of increasingly sophisticated functionality supported. Section 10
considers security aspects. Finally, summary and conclusion are
presented in Section 11.
3. Terminology and Concepts
This section introduces the terminology pertinent to this framework This section introduces the terminology pertinent to this framework
and some related concepts. and some related concepts.
draft-ietf-ipo-framework-01.txt
WDM WDM
--- ---
Wavelength Division Multiplexing (WDM) is a technology that allows Wavelength Division Multiplexing (WDM) is a technology that allows
multiple optical signals operating at different wavelengths to be multiple optical signals operating at different wavelengths to be
multiplexed onto a single fiber so that they can be transported in multiplexed onto a single fiber so that they can be transported in
parallel through the fiber. In general, each optical wavelength may parallel through the fiber. In general, each optical wavelength may
carry digital client payloads at a different data rate (e.g., OC-3c, carry digital client payloads at a different data rate (e.g., OC-3c,
OC-12c, OC- 48c, OC-192c, etc.) and in a different format (SONET, OC-12c, OC- 48c, OC-192c, etc.) and in a different format (SONET,
draft-ietf-ipo-framework-02.txt
Ethernet, ATM, etc.) For example, there are many commercial WDM Ethernet, ATM, etc.) For example, there are many commercial WDM
networks in existence today that support a mix of SONET signals networks in existence today that support a mix of SONET signals
operating at OC-48c (approximately 2.5 Gbps) and OC-192 operating at OC-48c (approximately 2.5 Gbps) and OC-192
(approximately 10 Gbps) over a single optical fiber. An optical (approximately 10 Gbps) over a single optical fiber. An optical
system with WDM capability can achieve parallel transmission of system with WDM capability can achieve parallel transmission of
multiple wavelengths gracefully while maintaining high system multiple wavelengths gracefully while maintaining high system
performance and reliability. In the near future, commercial WDM performance and reliability. In the near future, commercial WDM
systems are expected to concurrently carry more than 160 systems are expected to concurrently carry more than 160
wavelengths at data rates of OC-192c and above, for a total of 1.6 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 Tbps or more. The term WDM will be used in this document to refer
skipping to change at line 251 skipping to change at line 247
optical conversion at the output port, or it can be all-optical. An optical conversion at the output port, or it can be all-optical. An
OXC is assumed to have a control-plane processor that implements OXC is assumed to have a control-plane processor that implements
signaling and routing protocols necessary for realizing an optical signaling and routing protocols necessary for realizing an optical
network. network.
Optical channel trail or Lightpath Optical channel trail or Lightpath
---------------------------------- ----------------------------------
An optical channel trail is a point-to-point optical layer An optical channel trail is a point-to-point optical layer
connection between two access points in an optical network. In this connection between two access points in an optical network. In this
draft-ietf-ipo-framework-01.txt document, the term "lightpath" is used interchangeably with optical
draft, the term "lightpath" is used interchangeably with optical
channel trail. channel trail.
Optical mesh sub-network Optical mesh sub-network
------------------------ ------------------------
An optical sub-network, as discussed in this framework, is a network An optical sub-network, as discussed in this framework, is a network
of OXCs that supports end-to-end networking of optical channel of OXCs that supports end-to-end networking of optical channel
trails providing functionality like routing, monitoring, grooming, trails providing functionality like routing, monitoring, grooming,
draft-ietf-ipo-framework-02.txt
and protection and restoration of optical channels. The and protection and restoration of optical channels. The
interconnection of OXCs in this network can be based on a general interconnection of OXCs in this network can be based on a general
topology (also called "mesh" topology) Underlying this network could topology (also called "mesh" topology) Underlying this network could
be the following: be the following:
(a) An optical multiplex section (OMS) layer network : The optical (a) An optical multiplex section (OMS) layer network : The optical
multiplex section layer provides the transport of the optical multiplex section layer provides the transport of the optical
channels. The information contained in this layer is a data channels. The information contained in this layer is a data
stream comprising a set of optical channels, which have a stream comprising a set of optical channels, which have a
defined aggregate bandwidth. defined aggregate bandwidth.
skipping to change at line 283 skipping to change at line 279
(b) An optical transmission section (OTS) layer network : This (b) An optical transmission section (OTS) layer network : This
provides functionality for transmission of the optical signal on provides functionality for transmission of the optical signal on
optical media of different types. optical media of different types.
This framework does not address the interaction between the optical This framework does not address the interaction between the optical
sub-network and the OMS, or between the OMS and OTS layer networks. sub-network and the OMS, or between the OMS and OTS layer networks.
Mesh optical network (or simply, "optical network") Mesh optical network (or simply, "optical network")
--------------------------------------------------- ---------------------------------------------------
A mesh optical network, as considered in draft, is a mesh-connected A mesh optical network, as considered in document, is a mesh-
connected
collection of optical sub-networks. Such an optical network is collection of optical sub-networks. Such an optical network is
assumed to be under a single administration. It is also possible to assumed to be under a single administration. It is also possible to
conceive of a large scale global mesh optical network consisting of conceive of a large scale global mesh optical network consisting of
the voluntary interconnection of autonomous optical networks, each the voluntary interconnection of autonomous optical networks, each
of which is owned and administered by an independent entity. In this of which is owned and administered by an independent entity. In this
circumstance, abstraction can be used to hide the internal details circumstance, abstraction can be used to hide the internal details
of each autonomous optical cloud from the remainder of the network. of each autonomous optical cloud from the remainder of the network.
Optical internetwork Optical internetwork
-------------------- --------------------
skipping to change at line 306 skipping to change at line 303
networks. Each of these networks may be under different networks. Each of these networks may be under different
administration. administration.
Wavelength continuity property Wavelength continuity property
------------------------------ ------------------------------
A lightpath is said to satisfy the wavelength continuity property if A lightpath is said to satisfy the wavelength continuity property if
it is transported over the same wavelength end-to-end. Wavelength it is transported over the same wavelength end-to-end. Wavelength
continuity is required in optical networks with no wavelength continuity is required in optical networks with no wavelength
conversion feature. conversion feature.
draft-ietf-ipo-framework-01.txt
Wavelength path Wavelength path
--------------- ---------------
A lightpath that satisfies the wavelength continuity property is A lightpath that satisfies the wavelength continuity property is
called a wavelength path. called a wavelength path.
draft-ietf-ipo-framework-02.txt
Opaque vs. transparent optical networks Opaque vs. transparent optical networks
--------------------------------------- ---------------------------------------
A transparent optical network is an optical network in which each A transparent optical network is an optical network in which each
transit node along a path passes optical transmission without using transit node along a path passes optical transmission without using
transducers to convert the optical signal into an electrical signal transducers to convert the optical signal into an electrical signal
and back again to an optical signal. More generally, all and back again to an optical signal. More generally, all
intermediate nodes in a transparent optical network will pass intermediate nodes in a transparent optical network will pass
optical signals without performing retiming and reshaping and thus optical signals without performing retiming and reshaping and thus
such nodes are unaware of many characteristics of the carried such nodes are unaware of many characteristics of the carried
skipping to change at line 351 skipping to change at line 347
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
may be relaxed in practice if a set of administrative entities agree may be relaxed in practice if a set of administrative entities agree
to trust one another to form an enlarged heterogeneous trust domain. to trust one another to form an enlarged heterogeneous trust domain.
However, to simplify the discussions in this draft, it will be However, to simplify the discussions in this document, it will be
assumed, without loss of generality, that the term trust domain assumed, without loss of generality, that the term trust domain
applies to a single administrative entity. applies to a single administrative entity.
Flow Flow
---- ----
For the purpose of this document, the term flow will be used to For the purpose of this document, the term flow will be used to
represent the smallest non-separable stream of data, as seen by an represent the smallest non-separable stream of data, as seen by an
endpoint (source or destination node). It is to be noted that the endpoint (source or destination node). It is to be noted that the
term flow is heavily overloaded in the networking literature. Within term flow is heavily overloaded in the networking literature. Within
draft-ietf-ipo-framework-01.txt
the context of this document, it may be convenient to consider a the context of this document, it may be convenient to consider a
wavelength as a flow under certain circumstances. However, if there wavelength as a flow under certain circumstances. However, if there
is a method to partition the bandwidth of the wavelength, then each is a method to partition the bandwidth of the wavelength, then each
partition may be considered a flow, for example by quantizing time partition may be considered a flow, for example by quantizing time
into some nicely manageable intervals, it may be feasible to into some nicely manageable intervals, it may be feasible to
consider each quanta of time within a given wavelength as a flow. consider each quanta of time within a given wavelength as a flow.
draft-ietf-ipo-framework-02.txt
Traffic Trunk Traffic Trunk
------------- -------------
A traffic trunk is an abstraction of traffic flow that follows the A traffic trunk is an abstraction of traffic flow that follows the
same path between two access points which allows some same path between two access points which allows some
characteristics and attributes of the traffic to be parameterized. characteristics and attributes of the traffic to be parameterized.
5. The Network Model 4. The Network Model
5.1 Network Interconnection 4.1 Network Interconnection
The network model considered in this memo consists of IP routers The network model considered in this memo consists of IP routers
attached to an optical core internetwork, and connected to their attached to an optical core internetwork, and connected to their
peers over dynamically established switched lightpaths. The optical peers over dynamically established switched lightpaths. The optical
core itself is assumed to be incapable of processing individual IP core itself is assumed to be incapable of processing individual IP
packets in the data plane. packets in the data plane.
The optical internetwork is assumed to consist of multiple optical The optical internetwork is assumed to consist of multiple optical
networks, each may possibly be administered by a different entity. networks, each may possibly be administered by a different entity.
Each optical network consists of sub-networks interconnected by Each optical network consists of sub-networks interconnected by
skipping to change at line 417 skipping to change at line 413
conversions where necessary. The routers that have direct physical conversions where necessary. The routers that have direct physical
connectivity with the optical network are referred to as "edge connectivity with the optical network are referred to as "edge
routers". As shown in the figure, other client networks (e.g., ATM) routers". As shown in the figure, other client networks (e.g., ATM)
may connect to the optical network. may connect to the optical network.
The switching function in an OXC is controlled by appropriately The switching function in an OXC is controlled by appropriately
configuring the cross-connect fabric. Conceptually, this may be configuring the cross-connect fabric. Conceptually, this may be
viewed as setting up a cross-connect table whose entries are of the viewed as setting up a cross-connect table whose entries are of the
form <input port i, output port j>, indicating that the data stream form <input port i, output port j>, indicating that the data stream
entering input port i will be switched to output port j. In the entering input port i will be switched to output port j. In the
draft-ietf-ipo-framework-01.txt
context of a wavelength selective cross-connect (generally referred context of a wavelength selective cross-connect (generally referred
to as a WXC), the cross-connect tables may also indicate the input to as a WXC), the cross-connect tables may also indicate the input
and output wavelengths along with the input and output ports. A and output wavelengths along with the input and output ports. A
lightpath from an ingress port in an OXC to an egress port in a lightpath from an ingress port in an OXC to an egress port in a
remote OXC is established by setting up suitable cross-connects in remote OXC is established by setting up suitable cross-connects in
the ingress, the egress and a set of intermediate OXCs such that a the ingress, the egress and a set of intermediate OXCs such that a
draft-ietf-ipo-framework-02.txt
continuous physical path exists from the ingress to the egress port. continuous physical path exists from the ingress to the egress port.
Optical paths tend to be bi-directional, i.e., the return path from Optical paths tend to be bi-directional, i.e., the return path from
the egress port to the ingress port is typically routed along the the egress port to the ingress port is typically routed along the
same set of intermediate ports as the forward path, but this may not same set of intermediate ports as the forward path, but this may not
be the case under all circumstances. be the case under all circumstances.
Optical Network Optical Network
+----------------------------------------+ +----------------------------------------+
| | | |
| Optical Subnetwork | | Optical Subnetwork |
skipping to change at line 472 skipping to change at line 468
UNI UNI UNI UNI
| | | |
+------+-------+ +------+-----+ +------+-------+ +------+-----+
| | | | | | | |
| Other Client | |Other Client| | Other Client | |Other Client|
| Network | | Network | | Network | | Network |
| (e.g., ATM) | | | | (e.g., ATM) | | |
+--------------+ +------------+ +--------------+ +------------+
Figure 1: Optical Internetwork Model Figure 1: Optical Internetwork Model
draft-ietf-ipo-framework-01.txt
Multiple data streams output from an OXC may be multiplexed onto an Multiple data streams output from an OXC may be multiplexed onto an
optical link using WDM technology. The WDM functionality may exist optical link using WDM technology. The WDM functionality may exist
outside of the OXC, and be transparent to the OXC. Or, this function outside of the OXC, and be transparent to the OXC. Or, this function
may be built into the OXC. In the later case, the cross-connect may be built into the OXC. In the later case, the cross-connect
table (conceptually) consists of pairs of the form, <{input port table (conceptually) consists of pairs of the form, <{input port
draft-ietf-ipo-framework-02.txt
i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that the i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that the
data stream received on wavelength Lambda(j) over input port i is data stream received on wavelength Lambda(j) over input port i is
switched to output port k on Lambda(l). Automated establishment of switched to output port k on Lambda(l). Automated establishment of
lightpaths involves setting up the cross-connect table entries in lightpaths involves setting up the cross-connect table entries in
the appropriate OXCs in a coordinated manner such that the desired the appropriate OXCs in a coordinated manner such that the desired
physical path is realized. physical path is realized.
Under this network model, a switched lightpath must be established Under this network model, a switched lightpath must be established
between a pair of IP routers before they can communicate. This between a pair of IP routers before they can communicate. This
lightpath might traverse multiple optical networks and be subject to lightpath might traverse multiple optical networks and be subject to
different provisioning and restoration procedures in each different provisioning and restoration procedures in each
network. The IP-based control plane issue is that of designing 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
networks. Similarly, IP transport over such an optical network 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
internetwork. internetwork.
5.2 Control Structure 4.2 Control Structure
There are three logical control interfaces identified in Figure 1. There are three logical control interfaces identified in Figure 1.
These are the client-optical internetwork interface, the internal These are the client-optical internetwork interface, the internal
node-to-node interface within a network (between OXCs in different node-to-node interface within a network (between OXCs in different
sub-networks), and the external node-to-node interface between nodes sub-networks), and the external node-to-node interface between nodes
in different networks. These interfaces are also referred to as the in different networks. These interfaces are also referred to as the
User-Network Interface (UNI), the internal NNI (INNI), and the User-Network Interface (UNI), the internal NNI (INNI), and the
external NNI, respectively. The distinction between these interfaces external NNI, respectively. The distinction between these interfaces
arises out of the type and amount of control information flow across arises out of the type and amount of control information flow across
them. The UNI represents a service boundary between the client and them. The UNI represents a service boundary between the client and
skipping to change at line 526 skipping to change at line 523
described in Section 7. The NNIs represent vendor-independent described in Section 7. The NNIs represent vendor-independent
standardized control flow between nodes. The distinction between the standardized control flow between nodes. The distinction between the
INNI and the ENNI is that the former is an interface within a given INNI and the ENNI is that the former is an interface within a given
network under a single technical administration, while the later network under a single technical administration, while the later
indicates an interface at the administrative boundary between indicates an interface at the administrative boundary between
networks. The INNI and ENNI may thus differ in the policies that networks. The INNI and ENNI may thus differ in the policies that
restrict control flow between nodes. Security, scalability, restrict control flow between nodes. Security, scalability,
stability, and information hiding are important considerations in stability, and information hiding are important considerations in
the specification of the ENNI. It is possible in principle to the specification of the ENNI. It is possible in principle to
harmonize the control flow across the UNI and the NNI and eliminate harmonize the control flow across the UNI and the NNI and eliminate
draft-ietf-ipo-framework-01.txt
the distinction between them. On the other hand, it may be required the distinction between them. On the other hand, it may be required
to minimize control flow information, especially routing-related to minimize control flow information, especially routing-related
information, over the UNI; and even over the ENNI. In this case, information, over the UNI; and even over the ENNI. In this case,
UNI and NNIs may look different in some respects. In this draft, UNI and NNIs may look different in some respects. In this document,
these interfaces are treated as distinct. these interfaces are treated as distinct.
draft-ietf-ipo-framework-02.txt
The UNI can be categorized as public or private depending upon The UNI can be categorized as public or private depending upon
context and service models. Routing information (ie, topology state context and service models. Routing information (ie, topology state
information) can be exchanged across a private UNI. On the other information) can be exchanged across a private UNI. On the other
hand, such information is not exchanged across a public UNI, or such hand, such information is not exchanged across a public UNI, or such
information may be exchanged with very explicit restrictions information may be exchanged with very explicit restrictions
(including for example abstraction, filtration, etc). Thus, (including for example abstraction, filtration, etc). Thus,
different relationships (e.g., peer or over-lay, Section 7) may different relationships (e.g., peer or over-lay, Section 7) may
occur across private and public logical interfaces. 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
skipping to change at line 563 skipping to change at line 560
Figure 2. The type of routing and signaling information exchanged Figure 2. The type of routing and signaling information exchanged
across the direct interface would vary depending on the service across the direct interface would vary depending on the service
definition. This issue is dealt with in the next section. Some definition. This issue is dealt with in the next section. Some
choices for the routing protocol are OSPF/ISIS (with traffic choices for the routing protocol are OSPF/ISIS (with traffic
engineering Extensions and additional extensions to deal with the engineering Extensions and additional extensions to deal with the
peculiar characteristics of optical networks) or BGP, or some peculiar characteristics of optical networks) or BGP, or some
other protocol. Other directory-based routing information other protocol. 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. document.
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
management system or a server in the optical network may receive management system or a server in the optical network may receive
service requests from clients. Similarly, out-of-band signaling service requests from clients. Similarly, out-of-band signaling
may be used between management systems in client and optical may be used between management systems in client and optical
networks to signal service requests. In these cases, there is no networks to signal service requests. In these cases, there is no
direct control interaction between clients and respective direct control interaction between clients and respective
OXCs. One reason to have an indirect interface would be that the OXCs. One reason to have an indirect interface would be that the
OXCs and/or clients do not support a direct signaling interface. OXCs and/or clients do not support a direct signaling interface.
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
+-----------------------------+ +-----------------------------+ +-----------------------------+ +-----------------------------+
| | | | | | | |
| +---------+ +---------+ | | +---------+ +---------+ | | +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | | | | | | | | | | | | | | | | | |
| | Routing | |Signaling| | | | Routing | |Signaling| | | | Routing | |Signaling| | | | Routing | |Signaling| |
| | Protocol| |Protocol | | | | Protocol| |Protocol | | | | Protocol| |Protocol | | | | Protocol| |Protocol | |
| | | | | | | | | | | | | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ |
| | | | | | | | | | | | | | | |
skipping to change at line 607 skipping to change at line 604
Figure 2: Direct Interface Figure 2: Direct 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
between the client and the optical network. between the client and the optical network.
Although different control structures are possible, further Although different control structures are possible, further
descriptions in this framework assume direct interfaces for IP- descriptions in this framework assume direct interfaces for IP-
optical and optical sub-network control interactions. optical and optical sub-network control interactions.
6. IP over Optical Service Models and Requirements 5. IP over Optical Service Models and Requirements
In this section, the service models and requirements at the UNI and In this section, the service models and requirements at the UNI and
the NNIs are considered. Two general models have emerged for the the NNIs are considered. Two general models have emerged for the
services at the UNI (which can also be applied at the NNIs). These services at the UNI (which can also be applied at the NNIs). These
models are as follows. models are as follows.
6.1 Domain Services Model 5.1 Domain Services Model
Under the domain services model, the optical network primarily Under the domain services model, the optical network primarily
offers high bandwidth connectivity in the form of lightpaths. offers high bandwidth connectivity in the form of lightpaths.
Standardized signaling across the UNI (Figure 1) is used to invoke Standardized signaling across the UNI (Figure 1) is used to invoke
the following the following
services: services:
1. Lightpath creation: This service allows a lightpath with the 1. Lightpath creation: This service allows a lightpath with the
specified attributes to be created between a pair of termination specified attributes to be created between a pair of termination
points in the optical network. Lightpath creation may be subject points in the optical network. Lightpath creation may be subject
to network-defined policies (e.g., connectivity restrictions) and to network-defined policies (e.g., connectivity restrictions) and
security procedures. security procedures.
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
2. Lightpath deletion: This service allows an existing lightpath to 2. Lightpath deletion: This service allows an existing lightpath to
be deleted. be deleted.
3. Lightpath modification: This service allows certain parameters of 3. Lightpath modification: This service allows certain parameters of
the lightpath to be modified. the lightpath to be modified.
4. Lightpath status enquiry: This service allows the status of 4. Lightpath status enquiry: This service allows the status of
certain parameters of the lightpath (referenced by its ID) to be certain parameters of the lightpath (referenced by its ID) to be
queried by the router that created the lightpath. queried by the router that created the lightpath.
skipping to change at line 665 skipping to change at line 662
for example. for example.
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 and across optical networks. nature of routing protocols within and across optical networks.
The optical domain services model would result in the establishment The optical domain services model would result in the establishment
of a lightpath topology between routers at the edge of the optical of a lightpath topology between routers at the edge of the optical
network. The resulting overlay model for IP over optical networks network. The resulting overlay model for IP over optical networks
is discussed in Section 7. is discussed in Section 7.
6.2 Unified Service Model 5.2 Unified Service Model
Under this model, the IP and optical networks are treated together Under this model, the IP and optical networks are treated together
as a single integrated network from a control plane point of view. as a single integrated network from a control plane point of view.
In this regard, the OXCs are treated just like any other router as In this regard, the OXCs are treated just like any other router as
far as the control plane is considered. Thus, in principle, there is far as the control plane is considered. Thus, in principle, there is
no distinction between the UNI, NNIs and any other router-to-router no distinction between the UNI, NNIs and any other router-to-router
interface from a routing and signaling point of view. It is assumed interface from a routing and signaling point of view. It is assumed
that this control plane is MPLS-based, as described in [1]. The that this control plane is MPLS-based, as described in [1]. The
unified service model has so far been discussed only in the context unified service model has so far been discussed only in the context
of a single administrative domain. A unified control plane is of a single administrative domain. A unified control plane is
possible even when there are administrative boundaries within an possible even when there are administrative boundaries within an
optical internetwork, but some of the integrated routing optical internetwork, but some of the integrated routing
capabilities may not be practically attractive or even feasible in capabilities may not be practically attractive or even feasible in
this case (see Section 7). this case (see Section 7).
Under the unified service model, optical network services are Under the unified service model, optical network services are
obtained implicitly during end-to-end MPLS signaling. Specifically, obtained implicitly during end-to-end MPLS signaling. Specifically,
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
an edge router can create a lightpath with specified attributes, or an edge router can create a lightpath with specified attributes, or
delete and modify lightpaths as it creates MPLS label-switched paths delete and modify lightpaths as it creates MPLS label-switched paths
(LSPs). In this regard, the services obtained from the optical (LSPs). In this regard, the services obtained from the optical
network are similar to the domain services model. These services, network are similar to the domain services model. These services,
however, may be invoked in a more seamless manner as compared to the however, may be invoked in a more seamless manner as compared to the
domain services model. For instance, when routers are attached to a domain services model. For instance, when routers are attached to a
single optical network (i.e., there are no ENNIs), a remote router single optical network (i.e., there are no ENNIs), a remote router
could compute an end-to-end path across the optical internetwork. It could compute an end-to-end path across the optical internetwork. It
can then establish an LSP across the optical internetwork. But the can then establish an LSP across the optical internetwork. But the
skipping to change at line 708 skipping to change at line 705
[3]. In essence, once a lightpath is established across an optical [3]. In essence, once a lightpath is established across an optical
internetwork between two edge routers, it can be advertised as a internetwork between two edge routers, it can be advertised as a
forwarding adjacency (a virtual link) between these routers. Thus, forwarding adjacency (a virtual link) between these routers. Thus,
from a data plane point of view, the lightpaths result in a virtual from a data plane point of view, the lightpaths result in a virtual
overlay between edge routers. The decisions as to when to create overlay between edge routers. The decisions as to when to create
such lightpaths, and the bandwidth management for these lightpaths such lightpaths, and the bandwidth management for these lightpaths
is identical in both the domain services model and the unified is identical in both the domain services model and the unified
service model. The routing and signaling models for unified services service model. The routing and signaling models for unified services
is described in Section 7. is described in Section 7.
6.3 Which Service Model? 5.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 [4] for the unified models. The developments in GMPLS signaling [4] for the unified
service model and its adoption for UNI signaling [5, 6] under the service model and its adoption for UNI signaling [5, 6] under the
domain services model essentially supports this view. The domain services model essentially supports this view. The
significant difference between the service models, however, is in significant difference between the service models, however, is in
routing protocols, as described in Section 7. routing protocols, as described in Section 7.
6.4 What are the Possible Services? 5.4 What are the Possible Services?
Specialized services may be built atop the point-to-point Specialized services may be built atop the point-to-point
connectivity service offered by the optical network. For example, connectivity service offered by the optical network. For example,
6.4.1 Virtual Private Networks (VPNs) 5.4.1 Virtual Private Networks (VPNs)
Given that the data plane between IP routers over an optical network Given that the data plane between IP routers over an optical network
amounts to a virtual topology which is an overlay over the optical amounts to a virtual topology which is an overlay over the optical
network, it is easy to imagine a virtual private network of network, it is easy to imagine a virtual private network of
lightpaths that interconnect routers (or any other set of clients). lightpaths that interconnect routers (or any other set of clients).
Indeed, in the case where the optical network provides connectivity Indeed, in the case where the optical network provides connectivity
for multiple sets of external client networks, there has to be a for multiple sets of external client networks, there has to be a
way to enforce routing policies that ensure routing separation way to enforce routing policies that ensure routing separation
between different sets of clients (i.e., VPN service). between different sets of clients (i.e., VPN service).
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
7. IP transport over Optical Networks 6. IP transport over Optical Networks
To examine the architectural alternatives for IP over optical To examine the architectural alternatives for IP over optical
networks, it is important to distinguish between the data and networks, it is important to distinguish between the data and
control planes over the UNI. As described in Section 6, the optical control planes over the UNI. As described in Section 6, the optical
network provides a service to external entities in the form of fixed network provides a service to external entities in the form of fixed
bandwidth transport pipes (optical paths). IP routers at the edge of bandwidth transport pipes (optical paths). IP routers at the edge of
the optical networks must necessarily have such paths established the optical networks must necessarily have such paths established
between them before communication at the IP layer can commence. between them before communication at the IP layer can commence.
Thus, the IP data plane over optical networks is realized over a Thus, the IP data plane over optical networks is realized over a
virtual topology of optical paths. On the other hand, IP routers and virtual topology of optical paths. On the other hand, IP routers and
skipping to change at line 771 skipping to change at line 768
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
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 6.1 Interconnection Models
7.1.1 The Peer Model 6.1.1 The Peer Model
Under the peer model, the IP/MPLS layers act as peers of the optical Under the peer model, the IP/MPLS layers act as peers of the optical
transport network, such that a single control plane runs transport network, such that a single control plane runs
over both the IP/MPLS and optical domains. When there is a single over both the IP/MPLS and optical domains. When there is a single
optical network involved, presumably a common IGP optical network involved, presumably a common IGP
such as OSPF or IS-IS, with appropriate extensions, can be used to such as OSPF or IS-IS, with appropriate extensions, can be used to
distribute topology information [7] over the integrated IP-optical distribute topology information [7] over the integrated IP-optical
network. In the case of OSPF, opaque LSAs can be used to advertise network. In the case of OSPF, opaque LSAs can be used to advertise
topology state information. In the case of IS-IS, extended TLVs will topology state information. In the case of IS-IS, extended TLVs will
have to be defined to propagate topology state information. When an have to be defined to propagate topology state information. When an
optical internetwork with multiple optical networks is involved optical internetwork with multiple optical networks is involved
(that spans different administrative boundaries), a single instance (that spans different administrative boundaries), a single instance
of an intra-domain routing protocol is not practically attractive or of an intra-domain routing protocol is not practically attractive or
even feasible. In this case, inter-domain routing and signaling are even feasible. In this case, inter-domain routing and signaling are
needed. In either case, a tacit assumption is that a common needed. In either case, a tacit assumption is that a common
addressing scheme will be used for the optical and IP networks. A addressing scheme will be used for the optical and IP networks. A
common address space can be trivially realized by using IP addresses draft-ietf-ipo-framework-02.txt
draft-ietf-ipo-framework-01.txt
common address space can be trivially realized by using IP addresses
in both IP and optical domains. Thus, the optical network elements in both IP and optical domains. Thus, the optical network elements
become IP addressable entities as noted in [1]. become IP addressable entities as noted in [1].
7.1.2 The Overlay Model 6.1.2 The Overlay Model
Under the overlay model, the IP/MPLS routing, topology distribution, Under the overlay model, the IP/MPLS routing, topology distribution,
and signaling protocols are independent of the routing, topology and signaling protocols are independent of the routing, topology
distribution, and signaling protocols at the optical layer. This distribution, and signaling protocols at the optical layer. This
model is conceptually similar to the classical IP over ATM or MPOA model is conceptually similar to the classical IP over ATM or MPOA
models, but applied to an optical internetwork directly. In the models, but applied to an optical internetwork directly. In the
overlay model, topology distribution, path computation and signaling overlay model, topology distribution, path computation and signaling
protocols would have to be defined for the optical domain. In protocols would have to be defined for the optical domain. In
certain circumstances, it may also be feasible to statically certain circumstances, it may also be feasible to statically
configure the optical channels that provide connectivity in the configure the optical channels that provide connectivity in the
overlay model through network management. Static configuration is, overlay model through network management. Static configuration is,
however, unlikely to scale in very large networks, nor support the however, unlikely to scale in very large networks, nor support the
rapid connection provisioning required in today∆s competitive rapid connection provisioning required in today∆s competitive
networking environment. networking environment.
7.1.3 The Augmented Model 6.1.3 The Augmented Model
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.
7.2 Routing Approaches 6.2 Routing Approaches
7.2.1 Integrated Routing 6.2.1 Integrated Routing
This routing approach supports the peer model within an This routing approach supports the peer model within an
administrative domain. Under this approach, the IP and optical administrative domain. Under this approach, the IP and optical
networks are assumed to run the same instance of an IP routing networks are assumed to run the same instance of an IP routing
protocol, e.g., OSPF with suitable "optical" extensions. These protocol, e.g., OSPF with suitable "optical" extensions. These
extensions must capture optical link parameters, and any constraints extensions must capture optical link parameters, and any constraints
that are specific to optical networks. The topology and link state that are specific to optical networks. The topology and link state
information maintained by all nodes (OXCs and routers) is identical. information maintained by all nodes (OXCs and routers) is identical.
This permits a router to compute an end-to-end path to another This permits a router to compute an end-to-end path to another
router across the optical network. Suppose the path computation is router across the optical network. Suppose the path computation is
triggered by the need to route a label switched path (LSP). Such an triggered by the need to route a label switched path (LSP). Such an
LSP can be established using MPLS signaling, e.g., RSVP-TE or CR- LSP can be established using MPLS signaling, e.g., RSVP-TE or CR-
LDP. When the LSP is routed over the optical network, a lightpath LDP. When the LSP is routed over the optical network, a lightpath
must be established between two edge routers. This lightpath is in must be established between two edge routers. This lightpath is in
essence a tunnel across the optical network, and may have capacity essence a tunnel across the optical network, and may have capacity
much larger than that required to route the first LSP. Thus, it is much larger than that required to route the first LSP. Thus, it is
essential that other routers in the network realize the availability essential that other routers in the network realize the availability
of resources in the lightpath for other LSPs to be routed over it. of resources in the lightpath for other LSPs to be routed over it.
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
The lightpath may therefore be advertised as a virtual link in the The lightpath may therefore be advertised as a virtual link in the
topology. topology.
The notion of "forwarding adjacency" (FA) described in [3] is The notion of "forwarding adjacency" (FA) described in [3] is
essential in propagating existing lightpath information to other essential in propagating existing lightpath information to other
routers. An FA is essentially a virtual link advertised into a link routers. An FA is essentially a virtual link advertised into a link
state routing protocol. Thus, an FA could be described by the same state routing protocol. Thus, an FA could be described by the same
parameters that define resources in any regular link. While it is parameters that define resources in any regular link. While it is
necessary to specify the mechanism for creating an FA, it is not necessary to specify the mechanism for creating an FA, it is not
skipping to change at line 887 skipping to change at line 884
network of FAs. The above scheme is one way to tackle the problem. network of FAs. The above scheme is one way to tackle the problem.
Another approach is to associate appropriate dynamic attributes with Another approach is to associate appropriate dynamic attributes with
link state information, so that a link that cannot be used to link state information, so that a link that cannot be used to
establish a particular type of connection will be appropriately establish a particular type of connection will be appropriately
tagged. Generally, however, there is a great deal of similarity tagged. Generally, however, 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 a virtual next). Both ultimately deal with the creation of a virtual
lightpath topology (which is overlaid over the optical network) to lightpath topology (which is overlaid over the optical network) to
meet certain traffic engineering objectives. meet certain traffic engineering objectives.
7.2.2 Domain-Specific Routing 6.2.2 Domain-Specific Routing
The domain-specific routing approach supports the augmented The domain-specific routing approach supports the augmented
interconnection model. Under this approach, routing within the interconnection model. Under this approach, routing within the
optical and IP domains are separated, with a standard routing optical and IP domains are separated, with a standard routing
protocol running between domains. This is similar to the IP inter- protocol running between domains. This is similar to the IP inter-
domain routing model. A specific approach for this is considered domain routing model. A specific approach for this is considered
next. It is to be noted that other approaches are equally possible. next. It is to be noted that other approaches are equally possible.
7.2.2.1 Domain-Specific Routing using BGP 6.2.2.1 Domain-Specific Routing using BGP
The inter-domain IP routing protocol, BGP [8], may be adapted for The inter-domain IP routing protocol, BGP [8], may be adapted for
exchanging routing information between IP and optical domains. This exchanging routing information between IP and optical domains. This
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
would allow the routers to advertise IP address prefixes within would allow the routers to advertise IP address prefixes within
their network to the optical internetwork and to receive external their network to the optical internetwork and to receive external
IP address prefixes from the optical internetwork. The optical IP address prefixes from the optical internetwork. The optical
internetwork transports the reachability information from one IP internetwork transports the reachability information from one IP
network to others. For instance, edge routers and OXCs can run network to others. For instance, edge routers and OXCs can run
exterior BGP (EBGP). Within the optical internetwork, interior BGP exterior BGP (EBGP). Within the optical internetwork, interior BGP
(IBGP) is used between border OXCs within the same network, and EBGP (IBGP) is used between border OXCs within the same network, and EBGP
is used between networks (over ENNI, Figure 1). is used between networks (over ENNI, Figure 1).
skipping to change at line 937 skipping to change at line 934
other border OXCs or edge routers. An edge router receiving this other border OXCs or edge routers. An edge router receiving this
information need not propagate the egress address further, but it information need not propagate the egress address further, but it
must keep the association between external IP addresses and egress must keep the association between external IP addresses and egress
OXC addresses. Specific BGP mechanisms for propagating egress OXC OXC addresses. Specific BGP mechanisms for propagating egress OXC
addresses are to be determined, considering prior examples addresses are to be determined, considering prior examples
described in [9]. When VPNs are implemented, the address prefixes described in [9]. When VPNs are implemented, the address prefixes
advertised by the border OXCs may be accompanied by some VPN advertised by the border OXCs may be accompanied by some VPN
identification (for example, VPN IPv4 addresses, as defined in [9], identification (for example, VPN IPv4 addresses, as defined in [9],
may be used). may be used).
7.2.3 Overlay Routing 6.2.3 Overlay Routing
The overlay routing approach supports the overlay interconnection The overlay routing approach supports the overlay interconnection
model.Under this approach, an overlay mechanism that allows edge model.Under this approach, an overlay mechanism that allows edge
routers toregister and query for external addresses is implemented. routers toregister and query for external addresses is implemented.
This is conceptually similar to the address resolution mechanism This is conceptually similar to the address resolution mechanism
used for IP over ATM. Under this approach, the optical network could used for IP over ATM. Under this approach, the optical network could
implement a registry that allows edge routers to register IP implement a registry that allows edge routers to register IP
addresses and VPN identifiers. An edge router may be allowed to addresses and VPN identifiers. An edge router may be allowed to
query for external addresses belonging to the same set of VPNs it query for external addresses belonging to the same set of VPNs it
belongs to. A successful query would return the address of the belongs to. A successful query would return the address of the
egress optical port through which the external destination can be egress optical port through which the external destination can be
reached. reached.
Because IP-optical interface connectivity is limited, the Because IP-optical interface connectivity is limited, the
determination of how many lightpaths must be established and to what determination of how many lightpaths must be established and to what
endpoints are traffic engineering decisions. Furthermore, after an endpoints are traffic engineering decisions. Furthermore, after an
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
initial set of such lightpaths are established, these may be used as initial set of such lightpaths are established, these may be used as
adjacencies within VPNs for a VPN-wide routing scheme, for example, adjacencies within VPNs for a VPN-wide routing scheme, for example,
OSPF. With this approach, an edge router could first determine other OSPF. With this approach, an edge router could first determine other
edge routers of interest by querying the registry. After it obtains edge routers of interest by querying the registry. After it obtains
the appropriate addresses, an initial overlay lightpath topology may the appropriate addresses, an initial overlay lightpath topology may
be formed. Routing adjacencies may then be established across the be formed. Routing adjacencies may then be established across the
lightpaths and further routing information may be exchanged to lightpaths and further routing information may be exchanged to
establish VPN-wide routing. establish VPN-wide routing.
7.3 Signaling-Related 6.3 Signaling-Related
7.3.1 The Role of MPLS 6.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 [4]. MPLS signaling protocols with traffic engineering described in [4]. 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 as well [5, 6]. In the protocols can be adapted for UNI signaling as well [5, 6]. In the
case of the unified services model, lightpath establishment occurs case of the unified services model, lightpath establishment occurs
to support end-to-end LSP establishment using these protocols (with to support end-to-end LSP establishment using these protocols (with
suitable GMPLS enhancements [10, 11]). suitable GMPLS enhancements [10, 11]).
7.3.2 Signaling Models 6.3.2 Signaling Models
With the domain-services model, the signaling control plane in the With the domain-services model, the signaling control plane in the
IP and optical network are completely separate as shown in Figure 3 IP and optical network are completely separate as shown in Figure 3
below. This separation also implies the separation of IP and optical below. This separation also implies the separation of IP and optical
address spaces (even though the optical network would be using address spaces (even though the optical network would be using
internal IP addressing). While RSVP-TE and LDP can be adapted for internal IP addressing). While RSVP-TE and LDP can be adapted for
UNI signaling, the full functionality of these protocols will not be UNI signaling, the full functionality of these protocols will not be
used. For example, UNI signaling does not require the specification used. For example, UNI signaling does not require the specification
of explicit routes. On the other hand, based on the service of explicit routes. On the other hand, based on the service
attributes, new objects need to be signaled using these protocols as attributes, new objects need to be signaled using these protocols as
skipping to change at line 1008 skipping to change at line 1005
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | Router +---+ Router +-----+------+ OXC +---+ OXC | | | | Router +---+ Router +-----+------+ OXC +---+ OXC | |
| | | | | | | | | | | | | | | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ |
+-----------------------------+ | +-----------------------------+ +-----------------------------+ | +-----------------------------+
| |
| |
Completely Separated Addressing and Control Planes Completely Separated Addressing and Control Planes
Figure 3: Domain Services Signaling Model Figure 3: Domain Services Signaling Model
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
With the unified services model, the addressing is common in the IP With the unified services model, the addressing is common in the IP
network and optical internetwork and the respective signaling network and optical internetwork and the respective signaling
control are related, as shown in Figure 4. It is understood that control are related, as shown in Figure 4. It is understood that
GMPLS signaling is implemented in the IP and optical domains, using GMPLS signaling is implemented in the IP and optical domains, using
suitably enhanced RSVP-TE or CR-LDP protocols. But the semantics of suitably enhanced RSVP-TE or CR-LDP protocols. But the semantics of
services within the optical internetwork may be different from that services within the optical internetwork may be different from that
in the IP network. As an example, the protection services offered in in the IP network. As an example, the protection services offered in
the optical internetwork may be different from the end-to-end the optical internetwork may be different from the end-to-end
protection services offered by the IP network. Another example is protection services offered by the IP network. Another example is
skipping to change at line 1050 skipping to change at line 1047
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 [12]. is transport) are described in [12].
7.4 End-to-End Protection Models 6.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 internetwork router across an ingress IP network, a transit optical internetwork
and an egress IP network. If this LSP is to be afforded protection and an egress IP network. If this LSP is to be afforded protection
in the IP layer, how is the service coordinated between the IP and in the IP layer, how is the service coordinated between the IP and
optical layers? optical layers?
Under this scenario, there are two approaches to end-to-end Under this scenario, there are two approaches to end-to-end
protection: protection:
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
7.4.1 Segment-Wise Protection 6.4.1 Segment-Wise Protection
The protection services in the IP layer could utilize optical layer The protection services in the IP layer could utilize optical layer
protection services for the LSP segment that traverses the optical protection services for the LSP segment that traverses the optical
internetwork. Thus, the end-to-end LSP would be treated as a internetwork. Thus, the end-to-end LSP would be treated as a
concatenation of three LSP segments from the protection point of concatenation of three LSP segments from the protection point of
view: a segment in the ingress IP network, a segment in the optical view: a segment in the ingress IP network, a segment in the optical
internetwork and a segment in the egress IP network. The protection internetwork and a segment in the egress IP network. The protection
services at the IP layer for an end-to-end LSP must be mapped onto services at the IP layer for an end-to-end LSP must be mapped onto
suitable protection services offered by the optical internetwork. suitable protection services offered by the optical internetwork.
Suppose that 1+1 protection is offered to LSPs at the IP layer, Suppose that 1+1 protection is offered to LSPs at the IP layer,
skipping to change at line 1099 skipping to change at line 1096
IP networks. IP networks.
+----------------+ +------------------+ +---------------+ +----------------+ +------------------+ +---------------+
| | | | | | | | | | | |
A Ingress IP Net B----C Optical Internet D----E Egress IP Net F A Ingress IP Net B----C Optical Internet D----E Egress IP Net F
| | | | | | | | | | | |
+----------------+ +------------------+ +---------------+ +----------------+ +------------------+ +---------------+
Figure 5: End-to-End Protection Example Figure 5: End-to-End Protection Example
7.4.2 Single-Layer Protection 6.4.2 Single-Layer Protection
Under this model, the protection services in the IP layer do not Under this model, the protection services in the IP layer do not
rely on any protection services offered in the optical internetwork. rely on any protection services offered in the optical internetwork.
Thus, with reference to Figure 5, two SRLG-disjoint LSPs are Thus, with reference to Figure 5, two SRLG-disjoint LSPs are
established between A and F. The corresponding segments in the established between A and F. The corresponding segments in the
optical internetwork are treated as independent lightpaths in the optical internetwork are treated as independent lightpaths in the
optical internetwork. These lightpaths may be unprotected in the optical internetwork. These lightpaths may be unprotected in the
optical internetwork. optical internetwork.
draft-ietf-ipo-framework-01.txt 6.4.3 Differences
7.4.3 Differences
A distinction between these two choices is as follows. Under the A distinction between these two choices is as follows. Under the
first choice, the optical internetwork is actively involved in end- first choice, the optical internetwork is actively involved in end-
to-end protection, whereas under the second choice, any protection to-end protection, whereas under the second choice, any protection
draft-ietf-ipo-framework-02.txt
service offered in the optical internetwork is not utilized directly service offered in the optical internetwork is not utilized directly
by client IP network. Also, under the first choice, the protection by client IP network. Also, under the first choice, the protection
in the optical internetwork may apply collectively to a number of IP in the optical internetwork may apply collectively to a number of IP
LSPs. That is, with reference to Figure 5, many LSPs may be LSPs. That is, with reference to Figure 5, many LSPs may be
aggregated into a single lightpath between C and D. The optical aggregated into a single lightpath between C and D. The optical
internetwork protection may then be applied to all of them at once internetwork protection may then be applied to all of them at once
leading to some gain in scalability. Under the second choice, each leading to some gain in scalability. Under the second choice, each
IP LSP must be separately protected. Finally, the first choice IP LSP must be separately protected. Finally, the first choice
allows different restoration signaling to be implemented in the IP allows different restoration signaling to be implemented in the IP
and optical internetwork. These restoration protocols are "patched and optical internetwork. These restoration protocols are "patched
skipping to change at line 1146 skipping to change at line 1143
restoration protocols in the IP layer must run transparently over restoration protocols in the IP layer must run transparently over
the optical internetwork in the overlay mode. IP based recovery the optical internetwork in the overlay mode. IP based recovery
techniques may however be more resource efficient, as it may be techniques may however be more resource efficient, as it may be
possible to convey traffic through the redundant capacity under possible to convey traffic through the redundant capacity under
fault-free scenarios. In particular, it may be possible to utilize fault-free scenarios. In particular, it may be possible to utilize
classification, scheduling, and concepts of forwarding equivalence classification, scheduling, and concepts of forwarding equivalence
class to route lower class traffic over protect facilities and then class to route lower class traffic over protect facilities and then
possibly preempt them to make way for high priority traffic when possibly preempt them to make way for high priority traffic when
faults occur. faults occur.
8. IP-based Optical Control Plane Issues 7. IP-based Optical Control Plane Issues
Provisioning and restoring lightpaths end-to-end between IP networks Provisioning and restoring lightpaths end-to-end between IP networks
requires protocol and signaling support within optical sub-networks, requires protocol and signaling support within optical sub-networks,
and across the INNI and ENNI. In this regard, a distinction is made and across the INNI and ENNI. In this regard, a distinction is made
between control procedures within an optical sub-network (Figure 1), between control procedures within an optical sub-network (Figure 1),
between sub-networks, and between networks. The general guideline between sub-networks, and between networks. The general guideline
followed in this framework is to separate these cases, and allow the followed in this framework is to separate these cases, and allow the
possibility that different control procedures are followed inside possibility that different control procedures are followed inside
different sub-networks, while a common set of procedures are different sub-networks, while a common set of procedures are
followed across sub-networks and networks. followed across sub-networks and networks.
The control plane procedures within a single vendor sub-network need The control plane procedures within a single vendor sub-network need
not be defined since these can be proprietary. Clearly, it is not be defined since these can be proprietary. Clearly, it is
possible to follow the same control procedures inside a sub-network possible to follow the same control procedures inside a sub-network
as defined for control across sub-networks. But this is left as a as defined for control across sub-networks. But this is left as a
recommendation - even choice - within this framework document, recommendation Ż even choice Ż within this framework document,
draft-ietf-ipo-framework-01.txt
rather than as an imperative requirement. Thus, in the following, rather than as an imperative requirement. Thus, in the following,
signaling and routing across sub-networks is considered first, signaling and routing across sub-networks is considered first,
followed by a discussion of similar issues across networks. followed by a discussion of similar issues across networks.
8.1 Addressing draft-ietf-ipo-framework-02.txt
7.1 Addressing
For interoperability across optical sub-networks using an IP-centric For interoperability across optical sub-networks using an IP-centric
control plane, the fundamental issue is that of addressing. What control plane, the fundamental issue is that of addressing. What
entities should be identifiable from a signaling and routing point entities should be identifiable from a signaling and routing point
of view? How should they be addressed? This section presents some of view? How should they be addressed? This section presents some
guidelines on this issue. guidelines on this issue.
Identifiable entities in optical networks includes OXCs, optical Identifiable entities in optical networks includes OXCs, optical
links, optical channels and sub-channels, Shared Risk Link Groups links, optical channels and sub-channels, Shared Risk Link Groups
(SRLGs), etc. An issue here is how granular the identification (SRLGs), etc. An issue here is how granular the identification
skipping to change at line 1218 skipping to change at line 1215
Another entity that must be identified is the SRLG [13]. An Another entity that must be identified is the SRLG [13]. An
SRLG is an identifier assigned to a group of optical links that SRLG is an identifier assigned to a group of optical links that
share a physical resource. For instance, all optical channels routed share a physical resource. For instance, all optical channels routed
over the same fiber could belong to the same SRLG. Similarly, all over the same fiber could belong to the same SRLG. Similarly, all
fibers routed over a conduit could belong to the same SRLG. The fibers routed over a conduit could belong to the same SRLG. The
notable characteristic of SRLGs is that a given link could belong to notable characteristic of SRLGs is that a given link could belong to
more than one SRLG, and two links belonging to a given SRLG may more than one SRLG, and two links belonging to a given SRLG may
individually belong to two other SRLGs. This is illustrated in individually belong to two other SRLGs. This is illustrated in
Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links
draft-ietf-ipo-framework-01.txt
1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3. 1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3.
Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8 Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8
could belong to SRLG 4. (In this example, the same SRLG, i.e., 1, could belong to SRLG 4. (In this example, the same SRLG, i.e., 1,
contains links from two different adjacencies). contains links from two different adjacencies).
draft-ietf-ipo-framework-02.txt
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
advertisement into a link state protocol [14]. A bundled interface advertisement into a link state protocol [14]. 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. computation.
8.2 Neighbor Discovery 7.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
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
skipping to change at line 1268 skipping to change at line 1265
In the case of opaque OXCs with SONET termination, one instance of a In the case of opaque OXCs with SONET termination, one instance of a
neighbor discovery protocol (e.g., LMP [2]) would run on each OXC neighbor discovery protocol (e.g., LMP [2]) would run on each OXC
port, communicating with the corresponding protocol instance at the port, communicating with the corresponding protocol instance at the
neighboring OXC. The protocol would utilize the SONET overhead bytes neighboring OXC. The protocol would utilize the SONET overhead bytes
to transmit the (configured) local attributes periodically to the to transmit the (configured) local attributes periodically to the
neighbor. Thus, two neighboring switches can automatically determine neighbor. Thus, two neighboring switches can automatically determine
the identities of each other and the local connectivity, and also the identities of each other and the local connectivity, and also
keep track of the up/down status of local links. Neighbor discovery keep track of the up/down status of local links. Neighbor discovery
with transparent OXCs is described in [2]. with transparent OXCs is described in [2].
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
+--------------+ +------------+ +------------+ +--------------+ +------------+ +------------+
| +-1:OC48---+ +-5:OC192-+ | | +-1:OC48---+ +-5:OC192-+ |
| +-2:OC48---+ +-6:OC192-+ | | +-2:OC48---+ +-6:OC192-+ |
| OXC1 +-3:OC48---+ OXC2 +-7:OC48--+ OXC3 | | OXC1 +-3:OC48---+ OXC2 +-7:OC48--+ OXC3 |
| +-4:OC192--+ +-8:OC48--+ | | +-4:OC192--+ +-8:OC48--+ |
| | | | +------+ | | | | | +------+ |
+--------------+ +----+-+-----+ | +----+------+-----+ +--------------+ +----+-+-----+ | +----+------+-----+
| | | | | | | | | |
| | | | | | | | | |
skipping to change at line 1290 skipping to change at line 1287
| | +----+-+-----+ | | +------+-----+ | | +----+-+-----+ | | +------+-----+
| +----------+ +--+ | | | | +----------+ +--+ | | |
| OXC4 +----------+ +----+ | | | OXC4 +----------+ +----+ | |
| +----------+ OXC5 +--------+ OXC6 | | +----------+ OXC5 +--------+ OXC6 |
| | | +--------+ | | | | +--------+ |
+--------------+ | | | | +--------------+ | | | |
+------+-----+ +------+-----+ +------+-----+ +------+-----+
Figure 6: Mesh Optical Network with SRLGs Figure 6: Mesh Optical Network with SRLGs
8.3 Topology Discovery 7.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 network are determined. This resource state of all the links in a network are determined. This
procedure may be done as part of a link state routing protocol procedure may be done as part of a link state routing protocol
(e.g., OSPF, ISIS), or it can be done via the management plane (in (e.g., OSPF, ISIS), or it can be done via the management plane (in
the case of centralized path computation). The implementation of a the case of centralized path computation). The implementation of a
link state protocol within a network (i.e., across sub-network link state protocol within a network (i.e., across sub-network
boundaries) means that the same protocol runs in OXCs in every sub- boundaries) means that the same protocol runs in OXCs in every sub-
network. If this assumption does not hold then interworking of network. If this assumption does not hold then interworking of
routing between sub-networks is required. This is similar to inter- routing between sub-networks is required. This is similar to inter-
skipping to change at line 1322 skipping to change at line 1319
instance, the parameters of the abstract link may include the instance, the parameters of the abstract link may include the
number, bandwidth and the type of optical links contained in the number, bandwidth and the type of optical links contained in the
underlying link bundle [14]. Also, the SRLGs corresponding to each underlying link bundle [14]. Also, the SRLGs corresponding to each
optical link in the bundle may be included as a parameter. optical link in the bundle may be included as a parameter.
o The link state information should capture restoration-related o The link state information should capture restoration-related
parameters for optical links. Specifically, with shared protection parameters for optical links. Specifically, with shared protection
(Section 8.5), the link state updates must have information that (Section 8.5), the link state updates must have information that
allows the computation of shared protection paths. allows the computation of shared protection paths.
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
o A single routing adjacency could be maintained between neighbors o A single routing adjacency could be maintained between neighbors
which may have multiple optical links (or even multiple link which may have multiple optical links (or even multiple link
bundles) between them. This reduces the protocol messaging bundles) between them. This reduces the protocol messaging
overhead. overhead.
o Since link availability information changes dynamically, a o Since link availability information changes dynamically, a
flexible policy for triggering link state updates based on flexible policy for triggering link state updates based on
availability thresholds may be implemented. For instance, changes availability thresholds may be implemented. For instance, changes
in availability of links of a given bandwidth (e.g., OC-48) may in availability of links of a given bandwidth (e.g., OC-48) may
trigger updates only after the availability figure changes by a trigger updates only after the availability figure changes by a
certain percentage. certain percentage.
These concepts are relatively well-understood. On the other hand, These concepts are relatively well-understood. On the other hand,
the resource representation models and the topology discovery the resource representation models and the topology discovery
process for hierarchical routing (e.g., OSPF with multiple areas) process for hierarchical routing (e.g., OSPF with multiple areas)
are areas that need further work. are areas that need further work.
8.4 Restoration Models 7.4 Restoration Models
Automatic restoration of lightpaths is a service offered by optical Automatic restoration of lightpaths is a service offered by optical
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 network (across the INNI). Local restoration of lightpaths within a network (across the INNI). Local
mechanisms are used to select an alternate link between two adjacent mechanisms are used to select an alternate link between two adjacent
OXCs across the INNI when a failure affects the primary link over OXCs across the INNI when a failure affects the primary link over
which the (protected) lightpath is being routed. Local restoration which the (protected) lightpath is being routed. Local restoration
does not affect the end-to-end route of the lightpath. When local does not affect the end-to-end route of the lightpath. When local
restoration is not possible (e.g., no alternate link is available restoration is not possible (e.g., no alternate link is available
between the adjacent OXCs in question), end-to-end restoration may between the adjacent OXCs in question), end-to-end restoration may
skipping to change at line 1376 skipping to change at line 1373
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.
It is possible that different restoration schemes may be implemented It is possible that different restoration schemes may be implemented
within optical sub-networks. It is therefore necessary to consider a within optical sub-networks. It is therefore necessary to consider a
two-level restoration mechanism. Path failures within an optical two-level restoration mechanism. Path failures within an optical
sub-network could be handled using procedures specific to the sub-network could be handled using procedures specific to the
sub-network. If this fails, end-to-end restoration across sub- sub-network. If this fails, end-to-end restoration across sub-
networks could be invoked. The border OXC that is the ingress to a networks could be invoked. The border OXC that is the ingress to a
sub-network can act as the source for restoration procedures within sub-network can act as the source for restoration procedures within
a sub-network. The signaling for invoking end-to-end restoration draft-ietf-ipo-framework-02.txt
draft-ietf-ipo-framework-01.txt
a sub-network. The signaling for invoking end-to-end restoration
across the INNI is described in Section 8.6.3. The computation of across the INNI is described in Section 8.6.3. The computation of
the back-up path for end-to-end restoration may be based on various the back-up path for end-to-end restoration may be based on various
criteria. It is assumed that the back-up path is computed by the criteria. It is assumed that the back-up path is computed by the
source OXC, and signaled using standard methods. source OXC, and signaled using standard methods.
8.5 Route Computation 7.5 Route Computation
The computation of a primary route for a lightpath within an optical The computation of a primary route for a lightpath within an optical
network is essentially a constraint-based routing problem. The network is essentially a constraint-based routing problem. The
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 [15]. capacity required for routing lightpaths [15].
Route computation with constraints may be accomplished using a Route computation with constraints may be accomplished using a
number of algorithms [16]. When 1+1 protection is used, a back-up number of algorithms [16]. When 1+1 protection is used, a back-up
skipping to change at line 1428 skipping to change at line 1425
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
or shared) back-up is computed next based on the SRLGs chosen or shared) back-up is computed next based on the SRLGs chosen
for the primary path. In this regard, for the primary path. In this regard,
draft-ietf-ipo-framework-02.txt
o The primary path computation procedure can output a series of o The primary path computation procedure can output a series of
bundles the path is routed over. Since a bundle is uniquely bundles the path is routed over. Since a bundle is uniquely
draft-ietf-ipo-framework-01.txt
identified with a set of SRLGs, the alternate path can be identified with a set of SRLGs, the alternate path can be
computed right away based on this knowledge. In this case, if computed right away based on this knowledge. In this case, if
the primary path set up does not succeed for lack of resources the primary path set up does not succeed for lack of resources
in a chosen bundle, the primary and backup paths must be in a chosen bundle, the primary and backup paths must be
recomputed. recomputed.
o It might be desirable to compute primary paths without choosing o It might be desirable to compute primary paths without choosing
a specific bundle apriori. That is, resource availability over a specific bundle apriori. That is, resource availability over
all bundles between a node pair is taken into account rather all bundles between a node pair is taken into account rather
than specific bundle information. In this case, the primary than specific bundle information. In this case, the primary
skipping to change at line 1483 skipping to change at line 1479
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 are same links. The assumption here is that since the primary paths are
not routed over links that have the same SRLG, a given failure will not routed over links that have the same SRLG, a given failure will
affect only one of them. Furthermore, it is assumed that multiple affect only one of them. Furthermore, it is assumed that multiple
failure events affecting links belonging to more than one SRLG will failure events affecting links belonging to more than one SRLG will
not occur concurrently. Unlike the case of 1+1 protection, the not occur concurrently. Unlike the case of 1+1 protection, the
back-up paths are not established apriori. Rather, a failure event back-up paths are not established apriori. Rather, a failure event
triggers the establishment of a single back-up path corresponding to triggers the establishment of a single back-up path corresponding to
the affected primary path. the affected primary path.
draft-ietf-ipo-framework-02.txt
The distributed implementation of route computation for shared back- The distributed implementation of route computation for shared back-
up paths require knowledge about the routing of all primary and up paths require knowledge about the routing of all primary and
back-up paths at every node. This raises scalability concerns. For back-up paths at every node. This raises scalability concerns. For
draft-ietf-ipo-framework-01.txt
this reason, it may be practical to consider the centralization of this reason, it may be practical to consider the centralization of
the route computation algorithm in a route server that has complete the route computation algorithm in a route server that has complete
knowledge of the link state and path routes. Heuristics for fully knowledge of the link state and path routes. Heuristics for fully
distributed route computation without complete knowledge of path distributed route computation without complete knowledge of path
routes are to be determined. Path computation for restoration is routes are to be determined. Path computation for restoration is
further described in [13]. further described in [13].
8.6 Signaling Issues 7.6 Signaling Issues
Signaling within an optical network for lightpath provisioning Signaling within an optical network for lightpath provisioning
is a relatively simple operation if a standard procedure is is a relatively simple operation if a standard procedure is
implemented within all sub-networks. Otherwise, proprietary implemented within all sub-networks. Otherwise, proprietary
signaling may be implemented within sub-networks, but converted back signaling may be implemented within sub-networks, but converted back
to standard signaling across the INNI. This is similar to signaling to standard signaling across the INNI. This is similar to signaling
across the ENNI, as described in Section 8.7. In the former case, across the ENNI, as described in Section 8.7. In the former case,
signaling messages could carry a strict explicit route in signaling signaling messages could carry a strict explicit route in signaling
messages, while in the latter case the route should be loose, at the messages, while in the latter case the route should be loose, at the
level of sub-networks. Once a route is determined for a lightpath, level of sub-networks. Once a route is determined for a lightpath,
each OXC in the path must establish appropriate cross-connects in a each OXC in the path must establish appropriate cross-connects in a
coordinated fashion. This coordination is akin to selecting incoming coordinated fashion. This coordination is akin to selecting incoming
and outgoing labels in a label-switched environment. Thus, protocols and outgoing labels in a label-switched environment. Thus, protocols
like RSVP-TE [11] and CR-LDP [10] can be used across the INNI for like RSVP-TE [11] and CR-LDP [10] can be used across the INNI for
this. A few new concerns, however, must be addressed. this. A few new concerns, however, must be addressed.
8.6.1 Bi-Directional Lightpath Establishment 7.6.1 Bi-Directional Lightpath Establishment
Lightpaths are typically bi-directional. That is, the output port Lightpaths are typically bi-directional. That is, the output port
selected at an OXC for the forward direction is also the input port selected at an OXC for the forward direction is also the input port
for the reverse direction of the path. Since signaling for optical for the reverse direction of the path. Since signaling for optical
paths may be autonomously initiated by different nodes, it is paths may be autonomously initiated by different nodes, it is
possible that two path set-up attempts are in progress at the same possible that two path set-up attempts are in progress at the same
time. Specifically, while setting up an optical path, an OXC A may time. Specifically, while setting up an optical path, an OXC A may
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.
8.6.2 Failure Recovery 7.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,
draft-ietf-ipo-framework-02.txt
the control channel between OXCs may be affected temporarily by a the control channel between OXCs may be affected temporarily by a
failure. These failure may not affect already established optical failure. These failure may not affect already established optical
paths passing through the OXC fabric. The detection of such failures paths passing through the OXC fabric. The detection of such failures
draft-ietf-ipo-framework-01.txt
by adjacent nodes, for example, through a keepalive mechanism by adjacent nodes, for example, through a keepalive mechanism
between signaling peers, must not result in these optical paths between signaling peers, must not result in these optical paths
being torn down. being torn down.
It is likely that when the above failures occur, a backup processor It is likely that when the above failures occur, a backup processor
or a backup control channel will be activated. The signaling or a backup control channel will be activated. The signaling
protocol must be designed such that it is resilient to transient protocol must be designed such that it is resilient to transient
failures. During failure recovery, it is desirable to recover local failures. During failure recovery, it is desirable to recover local
state at the concerned OXC with least disruption to existing optical state at the concerned OXC with least disruption to existing optical
paths. paths.
8.6.3 Restoration 7.6.3 Restoration
Signaling for restoration has two distict phases. There is a Signaling for restoration has two distict phases. There is a
reservation phase in which capacity for the protection path is reservation phase in which capacity for the protection path is
established. Then, there is an activation phase in which the established. Then, there is an activation phase in which the
back-up path is actually put in service. The former phase typically back-up path is actually put in service. The former phase typically
is not subject to strict time constraints, while the latter is. is not subject to strict time constraints, while the latter is.
Signaling to establish a "1+1" back-up path is relatively straight- Signaling to establish a "1+1" back-up path is relatively straight-
forward. This signaling is very similar to signaling used for forward. This signaling is very similar to signaling used for
establishing the primary path. Signaling to establish a shared back- establishing the primary path. Signaling to establish a shared back-
skipping to change at line 1592 skipping to change at line 1588
LDP for activating protection paths, these protocols do not provide LDP for activating protection paths, these protocols do not provide
any means to give priority to restoration signaling as opposed to any means to give priority to restoration signaling as opposed to
signaling for provisioning. For instance, it is possible for a signaling for provisioning. For instance, it is possible for a
restoration-related RSVP message to be queued behind a number of restoration-related RSVP message to be queued behind a number of
provisioning messages thereby delaying restoration. It is therefore provisioning messages thereby delaying restoration. It is therefore
necessary to develop a definition of QoS for restoration signaling necessary to develop a definition of QoS for restoration signaling
and incorporate mechanisms in existing signaling protocols to and incorporate mechanisms in existing signaling protocols to
achieve this. Or, a new signaling protocol may be developed achieve this. Or, a new signaling protocol may be developed
exclusively for activating protection paths during restoration. exclusively for activating protection paths during restoration.
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
8.7 Optical Internetworking 7.7 Optical Internetworking
Within an optical internetwork, it must be possible to dynamically Within an optical internetwork, it must be possible to dynamically
provision and restore lightpaths across optical networks. Therefore: provision and restore lightpaths across optical networks. Therefore:
o A standard scheme for uniquely identifying lightpath end-points in o A standard scheme for uniquely identifying lightpath end-points in
different networks is required. different networks is required.
o A protocol is required for determining reachability of end-points o A protocol is required for determining reachability of end-points
across networks. across networks.
skipping to change at line 1620 skipping to change at line 1616
o Support for policies that affect the flow of control information o Support for policies that affect the flow of control information
across networks will be required. across networks will be required.
The IP-centric control architecture for optical networks can be The IP-centric control architecture for optical networks can be
extended to satisfy the functional requirements of optical extended to satisfy the functional requirements of optical
internetworking. Routing and signaling interaction between optical internetworking. Routing and signaling interaction between optical
networks can be standardized across the ENNI (Figure 1). The networks can be standardized across the ENNI (Figure 1). The
functionality provided across ENNI is as follows. functionality provided across ENNI is as follows.
8.7.1 Neighbor Discovery 7.7.1 Neighbor Discovery
Neighbor discovery procedure, as described in Section 8.2, can be Neighbor discovery procedure, as described in Section 8.2, can be
used for this. Indeed, a single protocol should be standardized for used for this. Indeed, a single protocol should be standardized for
neighbor discovery within and across networks. neighbor discovery within and across networks.
8.7.2 Addressing and Routing Model 7.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 network. identify OXCs, ports, channels and sub-channels in each network.
It is essential that the OXC IP addresses are unique within the It is essential that the OXC IP addresses are unique within the
internetwork. internetwork.
Provisioning an end-to-end lightpath across multiple networks Provisioning an end-to-end lightpath across multiple networks
involves the establishment of path segments in each network involves the establishment of path segments in each network
sequentially. Thus, a path segment is established from the source sequentially. Thus, a path segment is established from the source
OXC to a border OXC in the source network. From this border OXC, OXC to a border OXC in the source network. From this border OXC,
signaling across NNI is used to establish a path segment to a border signaling across NNI is used to establish a path segment to a border
OXC in the next network. Provisioning then continues in the next OXC in the next network. Provisioning then continues in the next
network and so on until the destination OXC is reached. The usage of network and so on until the destination OXC is reached. The usage of
protocols like BGP for this purpose need to be explored. protocols like BGP for this purpose need to be explored.
draft-ietf-ipo-framework-01.txt draft-ietf-ipo-framework-02.txt
8.7.3 Restoration 7.7.3 Restoration
Local restoration across the ENNI is similar to that across INNI Local restoration across the ENNI is similar to that across INNI
described in Section 8.6.3. End-to-end restoration across networks described in Section 8.6.3. End-to-end restoration across networks
is likely to be either of the 1+1 type, or segmented within each is likely to be either of the 1+1 type, or segmented within each
network, as described in Section 8.4. network, as described in Section 8.4.
9. Other Issues 8. Other Issues
9.1 WDM and TDM in the Same Network 8.1 WDM and TDM in the Same Network
A practical assumption would be that if SONET (or some other TDM A practical assumption would be that if SONET (or some other TDM
mechanism that is capable partitioning the bandwidth of a mechanism that is capable partitioning the bandwidth of a
wavelength) is used, then TDM is leveraged as an additional method wavelength) is used, then TDM is leveraged as an additional method
to differentiate between "flows." In such cases, wavelengths and to differentiate between "flows." In such cases, wavelengths and
time intervals (sub-channels) within a wavelength become analogous time intervals (sub-channels) within a wavelength become analogous
to labels (as noted in [1]) which can be used to make switching to labels (as noted in [1]) which can be used to make switching
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 [4] supports this type of multiplexing. signaling [4] supports this type of multiplexing.
9.2 Wavelength Conversion 8.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 the case in some pure optical elements. This however may not be the case in some pure optical
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.
skipping to change at line 1691 skipping to change at line 1687
the issue of the value of wavelength conversion in an optical the issue of the value of wavelength conversion in an optical
network. Such studies typically use the blocking probability (the network. Such studies typically use the blocking probability (the
probability that a lightpath cannot be established because the probability that a lightpath cannot be established because the
requisite wavelengths are not available) as a metric to adjudicate requisite wavelengths are not available) as a metric to adjudicate
the effectiveness of wavelength conversion. The IP over optical the effectiveness of wavelength conversion. The IP over optical
architecture must take into account hybrid networks with some OXCs architecture must take into account hybrid networks with some OXCs
capable of wavelength conversion and others incapable of this. The capable of wavelength conversion and others incapable of this. The
GMPLS "label set" mechanism [4] supports the selection of the same GMPLS "label set" mechanism [4] supports the selection of the same
label (i.e., wavelength) across an NNI. label (i.e., wavelength) across an NNI.
9.3 Service Provider Peering Points 8.3 Service Provider Peering Points
There are proposed inter-network interconnect models which allow There are proposed inter-network interconnect models which allow
certain types of peering relationships to occur at the optical certain types of peering relationships to occur at the optical
layer. This is consistent with the need to support optical layer layer. This is consistent with the need to support optical layer
services independent of higher layers payloads. In the context of IP draft-ietf-ipo-framework-02.txt
draft-ietf-ipo-framework-01.txt
services independent of higher layers payloads. In the context of IP
over optical networks, peering relationships between different trust over optical networks, peering relationships between different trust
domains will eventually have to occur at the IP layer, on IP routing domains will eventually have to occur at the IP layer, on IP routing
elements, even though non-IP paths may exist between the peering elements, even though non-IP paths may exist between the peering
routers. routers.
9.4 Rate of Lightpath Set-Up 8.4 Rate of Lightpath Set-Up
Dynamic establishment of optical channel trails and lightpaths is Dynamic establishment of optical channel trails and lightpaths is
quite desirable in IP over optical networks, especially when such quite desirable in IP over optical networks, especially when such
instantiations are driven by a stable traffic engineering control instantiations are driven by a stable traffic engineering control
system, or in response to authenticated and authorized requests from system, or in response to authenticated and authorized requests from
clients. clients.
However, there are many proposals suggesting the use of dynamic, However, there are many proposals suggesting the use of dynamic,
data-driven shortcut-lightpath setups in IP over optical networks. data-driven shortcut-lightpath setups in IP over optical networks.
The arguments put forth in such proposals are quite reminiscent of The arguments put forth in such proposals are quite reminiscent of
similar discussions regarding ATM deployment in the core of IP similar discussions regarding ATM deployment in the core of IP
networks. Deployment of highly dynamic data driven shortcuts within networks. Deployment of highly dynamic data driven shortcuts within
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 document
that this paradigm will not change and that highly dynamic, data- assumes that this paradigm will not change and that highly dynamic,
driven shortcut lightpath setups are for future investigation. data-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:
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.
skipping to change at line 1750 skipping to change at line 1746
processed by an ingress or egress network element either because of processed by an ingress or egress network element either because of
aggregate bandwidth limitations or because of a limitation on the aggregate bandwidth limitations or because of a limitation on the
number of flows (e.g., lightpaths) that can be processed number of flows (e.g., lightpaths) that can be processed
concurrently. concurrently.
Another possible short term reason for dynamic shortcut lightpath Another possible short term reason for dynamic shortcut lightpath
setup would be to quickly pre-provisioned paths based on some setup would be to quickly pre-provisioned paths based on some
criteria (TOD, CEO wants a high BW reliable connection, etc.). In criteria (TOD, CEO wants a high BW reliable connection, etc.). In
this scenario, a set of paths is pre-provisioned, but not actually this scenario, a set of paths is pre-provisioned, but not actually
instantiated until the customer initiates an authenticated and instantiated until the customer initiates an authenticated and
draft-ietf-ipo-framework-02.txt
authorized setup requests, which is consistent with existing authorized setup requests, which is consistent with existing
agreements between the provider and the customer. In a sense, the agreements between the provider and the customer. In a sense, the
draft-ietf-ipo-framework-01.txt
provider may have already agreed to supply this service, but will provider may have already agreed to supply this service, but will
only instantiate it by setting up a lightpath when the customer only instantiate it by setting up a lightpath when the customer
submits an explicit request. submits an explicit request.
9.5 Distributed vs. Centralized Provisioning 8.5 Distributed vs. Centralized Provisioning
This draft has mainly dealt with a distributed model for lightpath This document has mainly dealt with a distributed model for
provisioning, in which all nodes maintain a synchronized topology lightpath provisioning, in which all nodes maintain a synchronized
database, and advertise topology state information to maintain and topology database, and advertise topology state information to
refresh the database. A constraint-based routing entity in each node maintain and refresh the database. A constraint-based routing entity
then uses the information in the topology database and other in each node then uses the information in the topology database and
relevant details to compute appropriate paths through the optical other relevant details to compute appropriate paths through the
domain. Once a path is computed, a signaling protocol (e.g., [11]) optical domain. Once a path is computed, a signaling protocol (e.g.,
is used to instantiate the lightpath. [11]) is used to instantiate the lightpath.
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
skipping to change at line 1789 skipping to change at line 1785
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.
9.6 Optical Networks with Additional Configurable Components 8.6 Optical Networks with Additional Configurable Components
Thus far, this memo has focused mainly on IP over optical networks Thus far, this memo has focused mainly on IP over optical networks
where the cross-connect is the basic dynamically re-configurable where the cross-connect is the basic dynamically re-configurable
device in the optical network. Recently, as a consequence of device in the optical network. Recently, as a consequence of
technology evolution, various types of re-configurable optical technology evolution, various types of re-configurable optical
components are now available, including tunable lasers, tunable components are now available, including tunable lasers, tunable
filters, etc. Under certain circumstances, it may be necessary to filters, etc. Under certain circumstances, it may be necessary to
parameterize the characteristics of these components and advertise parameterize the characteristics of these components and advertise
them within the control plane. This aspect is left for further them within the control plane. This aspect is left for further
study. study.
9.7 Optical Networks with Limited Wavelength Conversion Capability draft-ietf-ipo-framework-02.txt
8.7 Optical Networks with Limited Wavelength Conversion Capability
At the time of the writing of this document, the majority of optical At the time of the writing of this document, the majority of optical
networks being deployed are "opaque". In this context the term networks being deployed are "opaque". In this context the term
opaque means that each link is optically isolated by transponders opaque means that each link is optically isolated by transponders
draft-ietf-ipo-framework-01.txt
doing optical-electrical-optical conversions. Such conversions have doing optical-electrical-optical conversions. Such conversions have
the added benefit of permitting 3R regeneration. The 3Rs refer to the added benefit of permitting 3R regeneration. The 3Rs refer to
re-power, signal retiming and reshaping. Unfortunately, this re-power, signal retiming and reshaping. Unfortunately, this
regeneration requires that the underlying optical equipment be aware regeneration requires that the underlying optical equipment be aware
of both the bit rate and frame format of the carried signal. These of both the bit rate and frame format of the carried signal. These
transponders are quite expensive and their lack of transparency transponders are quite expensive and their lack of transparency
constrains the rapid introduction of new services [19]. Thus there constrains the rapid introduction of new services [19]. Thus there
are strong motivators to introduce "domains of transparency" wherein are strong motivators to introduce "domains of transparency" wherein
all-optical networking equipment would transport data unfettered by all-optical networking equipment would transport data unfettered by
these drawbacks. these drawbacks.
skipping to change at line 1838 skipping to change at line 1834
function of topology and resource availability but will also depend function of topology and resource availability but will also depend
on the accumulation of impairments along the path. If the impairment on the accumulation of impairments along the path. If the impairment
accumulation is excessive, the optical signal to noise ratio (OSNR) accumulation is excessive, the optical signal to noise ratio (OSNR)
and hence the electrical bit error rate (BER) at the destination and hence the electrical bit error rate (BER) at the destination
node may exceed prescribed thresholds, making the resultant optical node may exceed prescribed thresholds, making the resultant optical
channel unusable for data communication. The challenge in the channel unusable for data communication. The challenge in the
development of IP-based control plane for optical networks is to development of IP-based control plane for optical networks is to
abstract these peculiar characteristics of the optical layer [19] in abstract these peculiar characteristics of the optical layer [19] in
a generic fashion, so that they can be used for path computation. a generic fashion, so that they can be used for path computation.
10. Evolution Path for IP over Optical Architecture 9. Evolution Path for IP over Optical Architecture
The architectural models described in Section 7 imply a certain The architectural models described in Section 7 imply a certain
degree of implementation complexity. Specifically, the overlay degree of implementation complexity. Specifically, the overlay
model was described as the least complex for near term deployment model was described as the least complex for near term deployment
and the peer model the most complex. Nevertheless, each model has and the peer model the most complex. Nevertheless, each model has
certain advantages and this raises the question as to the evolution certain advantages and this raises the question as to the evolution
path for IP over optical network architectures. path for IP over optical network architectures.
The evolution approach recommended in this framework is the The evolution approach recommended in this framework is the
definition of capability sets that start with simpler functionality definition of capability sets that start with simpler functionality
in the beginning and include more complex functionality later. In in the beginning and include more complex functionality later. In
this regard, it is realistic to expect that initial IP over optical this regard, it is realistic to expect that initial IP over optical
deployments will be based on the domain services model (with overlay deployments will be based on the domain services model (with overlay
interconnection), with no routing exchange between the IP and interconnection), with no routing exchange between the IP and
optical domains. Under this model, direct signaling between IP optical domains. Under this model, direct signaling between IP
routers and optical networks is likely to be triggered by offline routers and optical networks is likely to be triggered by offline
traffic engineering decisions. The next step in the evolution of IP- traffic engineering decisions. The next step in the evolution of IP-
draft-ietf-ipo-framework-02.txt
optical interaction is the introduction of reachability information optical interaction is the introduction of reachability information
exchange between the two domains. This would potentially allow exchange between the two domains. This would potentially allow
lightpaths to be established as part of end-to-end LSP set-up. The lightpaths to be established as part of end-to-end LSP set-up. The
final phase is the support for the full peer model with more final phase is the support for the full peer model with more
sophisticated routing interaction between IP and optical domains. sophisticated routing interaction between IP and optical domains.
draft-ietf-ipo-framework-01.txt
Using a common signaling framework (based on GMPLS) from the Using a common signaling framework (based on GMPLS) from the
beginning facilitates this type of evolution. For the domain beginning facilitates this type of evolution. For the domain
services model, implementation agreement based on GMPLS UNI services model, implementation agreement based on GMPLS UNI
signaling is being developed in the Optical Interworking Forum (OIF) signaling is being developed in the Optical Interworking Forum (OIF)
[5, 6]. This agreement is aimed at near term deployment and this [5, 6]. This agreement is aimed at near term deployment and this
could be the precursor to a future peer model architecture. In this could be the precursor to a future peer model architecture. In this
evolution, the signaling capability and semantics at the IP-optical evolution, the signaling capability and semantics at the IP-optical
boundary would become more sophisticated, but the basic structure of boundary would become more sophisticated, but the basic structure of
signaling would remain. This would allow incremental developments as signaling would remain. This would allow incremental developments as
the interconnection model becomes more sophisticated, rather than the interconnection model becomes more sophisticated, rather than
skipping to change at line 1910 skipping to change at line 1906
interoperabibility evolution, the next level of integration will be interoperabibility evolution, the next level of integration will be
achieved when a single carrier provides dynamic optical routing achieved when a single carrier provides dynamic optical routing
interoperability between subnetworks and between domains. In order interoperability between subnetworks and between domains. In order
to become completely independent of the network switching capability to become completely independent of the network switching capability
within subnetworks and across domains, routing information exchange within subnetworks and across domains, routing information exchange
may need to be enabled at the UNI level. This would constitute a may need to be enabled at the UNI level. This would constitute a
significant evolution: even if the routing instances are kept significant evolution: even if the routing instances are kept
separate and independent, it would still be possible to dynamicallhy separate and independent, it would still be possible to dynamicallhy
exchange reachability and other types of routing information. exchange reachability and other types of routing information.
Another more sophisticated step during this phase is to introduce Another more sophisticated step during this phase is to introduce
draft-ietf-ipo-framework-02.txt
dynamic routing at the E-NNI level. This means that any neighboring dynamic routing at the E-NNI level. This means that any neighboring
networks (independent of internal switching capability) would be networks (independent of internal switching capability) would be
capable of exchanging routing information with peers across the E- capable of exchanging routing information with peers across the E-
NNI. NNI.
draft-ietf-ipo-framework-01.txt
Another alternative would be for private networks to bypass these Another alternative would be for private networks to bypass these
intermediate steps and directly consider an integrated routing model intermediate steps and directly consider an integrated routing model
from the onset. This direct evolution strategy is realistic, but is from the onset. This direct evolution strategy is realistic, but is
more likely to occur in operational contexts where both the IP (or more likely to occur in operational contexts where both the IP (or
MPLS) and optical networks are built simultaneously, using equipment MPLS) and optical networks are built simultaneously, using equipment
from a single source or from multiple sources that are closely from a single source or from multiple sources that are closely
affiliated. In any case, due the current lack of operational affiliated. In any case, due the current lack of operational
experience in managing this degree of control plane interaction in a experience in managing this degree of control plane interaction in a
heterogenous network (these issues may exist even if the hardware heterogenous network (these issues may exist even if the hardware
and software originate from the same vendor), an augmented model is and software originate from the same vendor), an augmented model is
likely to be the most viable initial option. Alternatively, a very likely to be the most viable initial option. Alternatively, a very
modular or hierarchical peer model may be contemplated. There may be modular or hierarchical peer model may be contemplated. There may be
other challenges (not just of a technical, but also administrative other challenges (not just of a technical, but also administrative
and even political issues) that may be need to be resolved in order and even political issues) that may be need to be resolved in order
to achieve full a peer model at the routing level in a multi- to achieve full a peer model at the routing level in a multi-
technology and multi-vendor environment. Ultimately, the main technology and multi-vendor environment. Ultimately, the main
technical improvement would likely arise from efficiencies derived technical improvement would likely arise from efficiencies derived
from the integration of traffic-engineering capabilities in the from the integration of traffic-engineering capabilities in the
dynamic inter-domain routing environments. dynamic inter-domain routing environments.
11. Security Considerations 10. Security Considerations
This draft introduces no new security considerations for any IETF The architectural framework described in this document requires
protocol. different protocol mechanisms for its realization. Specifically, the
role of neighbor discovery, routing and signaling protocols were
described in previous sections. The general security issues that
arise with these protocols include:
12. Summary and Conclusions o The authentication of entities exchanging information
(signaling, routing or link management) across a control
interface;
The objective of this draft was to define a framework for IP over o Ensuring the integrity of the information exchanged across the
interface, and
o Protection of the control mechanisms from outside interference
Because optical connections may carry high volumes of data and
consume significant network resources, mechanisms are required to
safeguard an optical network against unauthorized use of network
resources.
In addition to the security aspects related to the control plane,
the data plane must also be protected from external interference.
draft-ietf-ipo-framework-02.txt
10.1 General security aspects
Communication protocols usually require two main security
mechanisms: authentication and confidentiality. Authentication
mechanisms ensure data origin verification and message integrity so
that unauthorized operations can be detectedd and discarded. For
example, with reference to Figure 1, message authentication service
can prevent a malicious IP client from mounting a denial of service
attack against the optical network by inserting an excessive number
of UNI connection creation requests. Additionally, authentication
mechanisms can provide
1. Replay protection, which detects and rejects attempts to
reorder, duplicate, truncate, or otherwise tamper with the
proper sequence of messages, and
2. Non-repudiation, which may be desirable for accounting and
billing purposes.
Authentication and confidentiality can be achieved using either
symmetric or public-key cryptographic algorithms. Simple message
integrity and confidentiality are normally achieved using symmetric
cryptographic algorithms. These algorithms typically require pair-
wise shared secret keys and do not provide non-repudiation, but are
typically less computationally intensive. Replay protection is
normally achieved by adding sequence numbers to the messages or by
relying on other protocol (e.g., TCP) to guarantee the proper
sequencing of the message stream above the integrity service.
Public-key or asymmetric cryptographic algorithms are typically
used, initially, to provide two-way peer entity authentication and
key agreement, which facilitate use of the integrity and
confidentiality services described above. Asymmetric algorithms also
provide digital signatures used to implement a non-repudiation
service. The use of asymmetric algorithms may be supported by a
public-key infrastructure (PKI) or some other, community-defined,
key assignment scheme. Asymmetric algorithms are typically more
computationally intensive than symmetric algorithms.
Confidentiality of signaling messages is also likely to be
desirable, especially in cases where message attributes include
information private to the communicating parties (client and optical
network operator). Examples of such attributes include account
numbers, contract identification numbers, etc, exchanged over the
UNI (Figure 1).
The case of non-co-located equipment presents increased security
requirements. In this scenario, the signaling (or routing) peers may
be connected using an external network. Since such a network could
be outside the control of the optical (or client) network operator,
control communication between peers may be subject to increased
security threats, such as address spoofing, eavesdropping and
unauthorized intrusion attempts. To counter these threats ,
appropriate security mechanisms have to be employed to protect the
signaling and control channel(s).
draft-ietf-ipo-framework-02.txt
10.2 Protocol Mechanisms
The security-related mechanisms required in IP-centric control
protocols would depend on the specific security requirements. Such
details are beyond the scope of this document and hence are not
considered further.
11. Summary and Conclusions
The objective of this document 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 document, for IP-optical interconnection, service models
and protocol mechanisms. The approach advocated in this draft and protocol mechanisms. The approach advocated in this document
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,
based on a common GMPLS-based signaling framework with increasing based on a common GMPLS-based signaling framework with increasing
interworking functionality was suggested. Under this scenario, the interworking functionality was suggested. Under this scenario, the
IP-optical interaction is first based on the domain services model IP-optical interaction is first based on the domain services model
with overlay interconnection that eventually evolves to support full with overlay interconnection that eventually evolves to support full
peer interaction. peer interaction.
13. References 12. References
1. D. Awduche and Y. Rekhter, , "Multi-Protocol 1. D. Awduche and Y. Rekhter, , "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering Control With Lambda Switching: Combining MPLS Traffic Engineering Control With
Optical Crossconnects," IEEE Communications Magazine, March 2001. Optical Crossconnects," IEEE Communications Magazine, March 2001.
2. J. P. Lang, et. al., "Link Management Protocol," Internet Draft, 2. J. P. Lang, et. al., "Link Management Protocol," Internet Draft,
Work in progress. Work in progress.
draft-ietf-ipo-framework-01.txt
3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE," 3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE,"
Internet Draft, Work in progress. Internet Draft, Work in progress.
4. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling Functional 4. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling Functional
Description", Internet Draft, Work in Progress. Description", Internet Draft, Work in Progress.
5. B. Rajagopalan, "LMP, LDP and RSVP Extensions for Optical UNI 5. B. Rajagopalan, "LMP, LDP and RSVP Extensions for Optical UNI
Signaling," Internet Draft, Work in Progress. Signaling," Internet Draft, Work in Progress.
6. The Optical Interworking Forum, "UNI 1.0 Signaling 6. The Optical Interworking Forum, "UNI 1.0 Signaling
Specification," December, 2001. Specification," December, 2001.
7. K. Kompella et al, "OSPF Extensions in Support of Generalized 7. K. Kompella et al, "OSPF Extensions in Support of Generalized
MPLS," Internet Draft, Work in Progress. MPLS," Internet Draft, Work in Progress.
8. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC 8. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC
1771, March, 1995. 1771, March, 1995.
draft-ietf-ipo-framework-02.txt
9. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999. 9. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999.
10. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling 10. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling
Functional Description," Internet Draft, Work in Progress. Functional Description," Internet Draft, Work in Progress.
11. P. Ashwood-Smith, et. al., "Generalized MPLS - RSVP-TE 11. P. Ashwood-Smith, et. al., "Generalized MPLS - RSVP-TE
Signaling Functional Description", Internet Draft, Work in Signaling Functional Description", Internet Draft, Work in
Progress. Progress.
12. E. Mannie, et. al., "GMPLS Extensions for SONET/SDH Control," 12. E. Mannie, et. al., "GMPLS Extensions for SONET/SDH Control,"
skipping to change at line 2021 skipping to change at line 2102
Framework for QoS-based Routing in the Internet," RFC 2386, Framework for QoS-based Routing in the Internet," RFC 2386,
August, 1998. August, 1998.
17. D. Awduche, L. Berger, Der-Hwa Gan, T. Li, G. Swallow, V. 17. D. Awduche, L. Berger, Der-Hwa Gan, T. Li, G. Swallow, V.
Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC
3209. 3209.
18. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4, 18. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4,
1974. 1974.
draft-ietf-ipo-framework-01.txt
19. A. Chie et al., "Impairments And Other Constraints On Optical 19. A. Chie et al., "Impairments And Other Constraints On Optical
Layer Routing", Internet Draft, Work in Progress. Layer Routing", Internet Draft, Work in Progress.
14. Acknowledgments 13. Acknowledgments
We would like to thank Zouheir Mansourati of Movaz Networks, Ian We would like to thank Zouheir Mansourati (Movaz Networks), Ian
Duncan of Nortel Networks, and Dimitri Papadimitriou of Alcatel for Duncan (Nortel Networks), Dimitri Papadimitriou (Alcatel), and
their comments on this draft. Dimitrios Pendarakis (Tellium) for their contributions to this
document.
15. Author's Addresses draft-ietf-ipo-framework-02.txt
14. Author's Addresses
Bala Rajagopalan James V. Luciani Bala Rajagopalan James V. Luciani
Debanjan Saha Crescent Networks Debanjan Saha Crescent Networks
Tellium, Inc. 900 Chelmsford St. Tellium, Inc. 900 Chelmsford St.
2 Crescent Place Lowell, MA 01851 2 Crescent Place Lowell, MA 01851
P.O. Box 901 Email: jluciani@CrescentNetworks.com P.O. Box 901 Email: jluciani@CrescentNetworks.com
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Email: {braja, dsaha}@tellium.com Email: {braja, dsaha}@tellium.com
Daniel O. Awduche Bilel Jamoussi Daniel O. Awduche Bilel Jamoussi
Movaz Networks Nortel Networks Movaz Networks Nortel Networks
7926 Jones Branch Dr. 600 Tech Park 7926 Jones Branch Dr. 600 Tech Park
McLean, VA 22102 Billerica, MA 01821 McLean, VA 22102 Billerica, MA 01821
Phone: 703-847-7350 Phone: 978-288-4734 Phone: 703-298-5291 Phone: 978-288-4734
Email: awduche@movaz.com Email: jamoussi @nortelnetworks.com Email: awduche@movaz.com Email: jamoussi @nortelnetworks.com
Brad Cain Brad Cain
Cereva Networks Cereva Networks
3 Network Dr. 3 Network Dr.
Marlborough, MA 01752 Marlborough, MA 01752
Email: bcain@cereva.com Email: bcain@cereva.com
 End of changes. 

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