draft-ietf-ipo-framework-05.txt   rfc3717.txt 
Bala Rajagopalan Network Working Group B. Rajagopalan
Internet Draft Tellium, Inc. Request for Comments: 3717 Consultant
draft-ietf-ipo-framework-05.txt James Luciani Category: Informational J. Luciani
Expires on: 3/13/2004 Crescent Networks Marconi Communications
Daniel O. Awduche D. Awduche
MCI MCI
March 2004
IP over Optical Networks: A Framework IP over Optical Networks: A Framework
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2004). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract 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
document defines a framework for IP over Optical networks, document defines a framework for IP over Optical networks,
considering both the IP-based control plane for optical networks as considering both the IP-based control plane for optical networks as
well as IP-optical network interactions (together referred to as "IP well as IP-optical network interactions (together referred to as "IP
over optical networks"). over optical networks").
Table of Contents Table of Contents
-----------------
Abstract..............................................................1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction.......................................................3 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Concepts...........................................4 3. The Network Model. . . . . . . . . . . . . . . . . . . . . . . 8
3. The Network Model..................................................8 3.1. Network Interconnection. . . . . . . . . . . . . . . . . 8
3.1 Network Interconnection.........................................8 3.2. Control Structure. . . . . . . . . . . . . . . . . . . . 11
3.2 Control Structure..............................................10 4. IP over Optical Service Models and Requirements. . . . . . . . 13
4. IP over Optical Service Models and Requirements...................12 4.1. Domain Services Model. . . . . . . . . . . . . . . . . . 13
4.1 Domain Services Model..........................................12 4.2. Unified Service Model. . . . . . . . . . . . . . . . . . 14
4.2 Unified Service Model..........................................13 4.3. Which Service Model? . . . . . . . . . . . . . . . . . . 15
4.3 Which Service Model?...........................................14 4.4. What are the Possible Services?. . . . . . . . . . . . . 16
4.4 What are the Possible Services?.................................14 5. IP transport over Optical Networks . . . . . . . . . . . . . . 16
5. IP transport over Optical Networks................................15 5.1. Interconnection Models . . . . . . . . . . . . . . . . . 17
5.1 Interconnection Models..........................................15 5.2. Routing Approaches . . . . . . . . . . . . . . . . . . . 18
5.2 Routing Approaches..............................................16 5.3. Signaling-Related. . . . . . . . . . . . . . . . . . . . 21
5.3 Signaling-Related...............................................19 5.4. End-to-End Protection Models . . . . . . . . . . . . . . 23
5.4 End-to-End Protection Models...................................21 6. IP-based Optical Control Plane Issues. . . . . . . . . . . . . 25
6. IP-based Optical Control Plane Issues.............................23 6.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . 25
6.1 Addressing.....................................................23 6.2. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 27
6.2 Neighbor Discovery.............................................24 6.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 28
6.3 Topology Discovery.............................................26 6.4. Protection and Restoration Models. . . . . . . . . . . . 29
6.4 Protection and Restoration Models..............................26 6.5. Route Computation. . . . . . . . . . . . . . . . . . . . 30
6.5 Route Computation..............................................27 6.6. Signaling Issues . . . . . . . . . . . . . . . . . . . . 32
6.6 Signaling Issues...............................................29 6.7. Optical Internetworking. . . . . . . . . . . . . . . . . 34
6.7 Optical Internetworking........................................31 7. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
7. Other Issues......................................................32 7.1. WDM and TDM in the Same Network. . . . . . . . . . . . . 35
7.1 WDM and TDM in the Same Network...............................32 7.2. Wavelength Conversion. . . . . . . . . . . . . . . . . . 36
7.2 Wavelength Conversion.........................................33 7.3. Service Provider Peering Points. . . . . . . . . . . . . 36
7.3 Service Provider Peering Points...............................33 7.4. Rate of Lightpath Set-Up . . . . . . . . . . . . . . . . 36
7.4 Rate of Lightpath Set-Up......................................33 7.5. Distributed vs. Centralized Provisioning . . . . . . . . 37
7.5 Distributed vs. Centralized Provisioning......................34 7.6. Optical Networks with Additional Configurable
7.6 Optical Networks with Additional Configurable Components......35 Components . . . . . . . . . . . . . . . . . . . . . . . 38
7.7 Optical Networks with Limited Wavelength Conversion Capability35 7.7. Optical Networks with Limited Wavelength Conversion
8. Evolution Path for IP over Optical Architecture..................36 Capability . . . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations...........................................38 8. Evolution Path for IP over Optical Architecture. . . . . . . . 39
9.1 General Security Aspects........................................39 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
9.2 Security Considerations for Protocol Mechanisms.................40 9.1. General Security Aspects . . . . . . . . . . . . . . . . 42
10. Summary and Conclusions..........................................40 9.2. Security Considerations for Protocol Mechanisms. . . . . 43
11. References.......................................................40 10. Summary and Conclusions. . . . . . . . . . . . . . . . . . . . 44
12. Acknowledgments..................................................41 11. Informative References . . . . . . . . . . . . . . . . . . . . 44
13. Contributors.....................................................42 12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 45
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. 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 major network service providers, interworking issues by all major network service providers,
telecommunications equipment vendors, and standards organizations. telecommunications equipment vendors, and standards organizations. In
In this regard, the term "optical network" is used generically 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
well as switched optical networks (including all-optical networks). as switched optical networks (including all-optical networks).
It has been realized that optical networks must be survivable, It has been realized that optical networks must be survivable,
flexible, and controllable. There is, therefore, an ongoing trend to flexible, and controllable. There is, therefore, an ongoing trend to
introduce intelligence in the control plane of optical networks to introduce intelligence in the control plane of optical networks to
make them more versatile [1]. An essential attribute of intelligent make them more versatile [1]. An essential attribute of intelligent
optical networks is the capability to instantiate and route optical optical networks is the capability to instantiate and route optical
layer connections in real-time or near real-time, and to provide layer connections in real-time or near real-time, and to provide
capabilities that enhance network survivability. Furthermore, there capabilities that enhance network survivability. Furthermore, there
is a need for multi-vendor optical network interoperability, when an is a need for multi-vendor optical network interoperability, when an
optical network may consist of interconnected vendor-specific optical network may consist of interconnected vendor-specific optical
optical sub-networks. sub-networks.
The optical network must also be versatile because some service The optical network must also be versatile because some service
providers may offer generic optical layer services that may not be providers may offer generic optical layer services that may not be
client-specific. It would therefore be necessary to have an optical client-specific. It would therefore be necessary to have an optical
network control plane that can handle such generic optical services. network control plane that can handle such generic optical services.
There is general consensus in the industry that the optical network There is general consensus in the industry that the optical network
control plane should utilize IP-based protocols for dynamic control plane should utilize IP-based protocols for dynamic
provisioning and restoration of optical channels within and across provisioning and restoration of optical channels within and across
optical sub-networks. This is based on the practical view that optical sub-networks. This is based on the practical view that
signaling and routing mechanisms developed for IP traffic signaling and routing mechanisms developed for IP traffic engineering
engineering applications could be re-used in optical networks. applications could be re-used in optical networks. Nevertheless, the
Nevertheless, the issues and requirements that are specific to issues and requirements that are specific to optical networking must
optical networking must be understood to suitably adopt and adapt be understood to suitably adopt and adapt the IP-based protocols.
the IP-based protocols. This is especially the case for restoration, This is especially the case for restoration, and for routing and
and for routing and signaling in all-optical networks. Also, there signaling in all-optical networks. Also, there are different views
are different views on the model for interaction between the optical on the model for interaction between the optical network and client
network and client networks, such as IP networks. Reasonable networks, such as IP networks. Reasonable architectural alternatives
architectural alternatives in this regard must be supported, with an in this regard must be supported, with an understanding of their
understanding of their relative merits. relative merits.
Thus, there are two fundamental issues related to IP over optical Thus, there are two fundamental issues related to IP over optical
networks. The first is the adaptation and reuse of IP control plane networks. The first is the adaptation and reuse of IP control plane
protocols within the optical network control plane, irrespective of protocols within the optical network control plane, irrespective of
the types of digital clients that utilize the optical network. The the types of digital clients that utilize the optical network. The
second is the transport of IP traffic through an optical network second is the transport of IP traffic through an optical network
together with the control and coordination issues that arise together with the control and coordination issues that arise
therefrom. therefrom.
This document defines a framework for IP over optical networks This document defines a framework for IP over optical networks
covering the requirements and mechanisms for establishing an IP- covering the requirements and mechanisms for establishing an IP-
centric optical control plane, and the architectural aspects of IP centric optical control plane, and the architectural aspects of IP
transport over optical networks. In this regard, it is recognized transport over optical networks. In this regard, it is recognized
that the specific capabilities required for IP over optical networks that the specific capabilities required for IP over optical networks
would depend on the services expected at the IP-optical interface as would depend on the services expected at the IP-optical interface as
well as the optical sub-network interfaces. Depending on the well as the optical sub-network interfaces. Depending on the
specific operational requirements, a progression of capabilities is specific operational requirements, a progression of capabilities is
possible, reflecting increasingly sophisticated interactions at possible, reflecting increasingly sophisticated interactions at these
these interfaces. This document therefore advocates the definition interfaces. This document therefore advocates the definition of
of "capability sets" that define the evolution of functionality at "capability sets" that define the evolution of functionality at the
the interfaces as more sophisticated operational requirements arise. interfaces as more sophisticated operational requirements arise.
This document is organized as follows. In the next section, This document is organized as follows. In the next section,
terminology covering some basic concepts related to this framework terminology covering some basic concepts related to this framework
are described. The definitions are specific to this framework and are described. The definitions are specific to this framework and
may have other connotations elsewhere. In Section 3, the network may have other connotations elsewhere. In Section 3, the network
model pertinent to this framework is described. The service model model pertinent to this framework is described. The service model
and requirements for IP-optical, and multi-vendor optical and requirements for IP-optical, and multi-vendor optical
internetworking are described in Section 4. This section also internetworking are described in Section 4. This section also
considers some general requirements. Section 5 considers the considers some general requirements. Section 5 considers the
architectural models for IP-optical interworking, describing the architectural models for IP-optical interworking, describing the
relative merits of each model. It should be noted that it is not the relative merits of each model. It should be noted that it is not the
intent of this document to promote any particular model over the intent of this document to promote any particular model over the
others. However, particular aspects of the models that may make one others. However, particular aspects of the models that may make one
approach more appropriate than another in certain circumstances are approach more appropriate than another in certain circumstances are
described. Section 6 describes IP-centric control plane mechanisms described. Section 6 describes IP-centric control plane mechanisms
for optical networks, covering signaling and routing issues in for optical networks, covering signaling and routing issues in
support of provisioning and restoration. The approaches described in support of provisioning and restoration. The approaches described in
Section 5 and 6 range from the relatively simple to the Section 5 and 6 range from the relatively simple to the
sophisticated. Section 7 describes a number of specialized issues in sophisticated. Section 7 describes a number of specialized issues in
relation to IP over optical networks. Section 8 describes a relation to IP over optical networks. Section 8 describes a possible
possible evolution path for IP over optical networking capabilities evolution path for IP over optical networking capabilities in terms
in terms of increasingly sophisticated functionality that may be of increasingly sophisticated functionality that may be supported as
supported as the need arises. Section 9 considers security issues the need arises. Section 9 considers security issues pertinent to
pertinent to this framework. Finally, the summary and conclusion are this framework. Finally, the summary and conclusion are presented in
presented in Section 10. Section 10.
2. Terminology and Concepts 2. Terminology and Concepts
This section introduces terminology pertinent to this framework and This section introduces terminology pertinent to this framework and
some related concepts. The definitions are specific to this some related concepts. The definitions are specific to this
framework and may have other interpretations elsewhere. framework and may have other interpretations elsewhere.
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 optical fiber and transported in parallel multiplexed onto a single optical fiber and transported in parallel
through the fiber. In general, each optical wavelength may carry through the fiber. In general, each optical wavelength may carry
digital client payloads at a different data rate (e.g., OC-3c, OC- 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, 12c, OC- 48c, OC-192c, etc.) and in a different format (SONET,
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 dense performance and reliability. In the near future, commercial dense
WDM systems are expected to concurrently carry more than 160 WDM systems are expected to concurrently carry more than 160
wavelengths at data rates of OC-192c and above, for a total of 1.6 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 to
to both WDM and DWDM (Dense WDM). both WDM and DWDM (Dense WDM).
In general, it is worth noting that WDM links are affected by the In general, it is worth noting that WDM links are affected by the
following factors, which may introduce impairments into the optical following factors, which may introduce impairments into the optical
signal path: signal path:
1. The number of wavelengths on a single fiber. 1. The number of wavelengths on a single fiber.
2. The serial bit rate per wavelength. 2. The serial bit rate per wavelength.
3. The type of fiber. 3. The type of fiber.
4. The amplification mechanism. 4. The amplification mechanism.
5. The number and type of nodes through which the signals pass 5. The number and type of nodes through which the signals pass before
before reaching the egress node or before regeneration. reaching the egress node or before regeneration.
All these factors (and others not mentioned here) constitute domain All these factors (and others not mentioned here) constitute domain
specific features of optical transport networks. As noted in [1], specific features of optical transport networks. As noted in [1],
these features should be taken into account in developing standards these features should be taken into account in developing standards
based solutions for IP over optical networks. based solutions for IP over optical networks.
Optical cross-connect (OXC) Optical cross-connect (OXC)
---------------------------
An OXC is a space-division switch that can switch an optical data An OXC is a space-division switch that can switch an optical data
stream from an input port to a output port. Such a switch may stream from an input port to a output port. Such a switch may
utilize optical-electrical conversion at the input port and utilize optical-electrical conversion at the input port and
electrical-optical conversion at the output port, or it may be all- electrical-optical conversion at the output port, or it may be all-
optical. An OXC is assumed to have a control-plane processor that optical. An OXC is assumed to have a control-plane processor that
implements the signaling and routing protocols necessary for implements the signaling and routing protocols necessary for
computing and instantiating optical channel connectivity in the computing and instantiating optical channel connectivity in the
optical domain. optical domain.
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
connection between two access points in an optical network. In this between two access points in an optical network. In this document,
document, the term "lightpath" is used interchangeably with optical the term "lightpath" is used interchangeably with optical channel
channel trail. trail.
Optical mesh sub-network Optical mesh sub-network
------------------------
An optical sub-network, as used in this framework, is a network of An optical sub-network, as used in this framework, is a network of
OXCs that supports end-to-end networking of optical channel trails OXCs that supports end-to-end networking of optical channel trails
providing functionality like routing, monitoring, grooming, and providing functionality like routing, monitoring, grooming, and
protection and restoration of optical channels. The interconnection protection and restoration of optical channels. The interconnection
of OXCs in this network can be based on a general mesh topology. of OXCs in this network can be based on a general mesh topology. The
The following sub-layers may be associated with this network: following sub-layers may be associated with this network:
(a) An optical multiplex section (OMS) layer network : The optical (a) An optical multiplex section (OMS) layer network : The optical
multiplex section layer provides transport for the optical multiplex section layer provides transport for 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 may have a stream comprising a set of optical channels, which may have a
defined aggregate bandwidth. defined aggregate bandwidth.
(b) An optical transmission section (OTS) layer network : This layer (b) An optical transmission section (OTS) layer network : This layer
provides functionality for transmission of optical signals provides functionality for transmission of optical signals
through different types of optical media. through different types of optical media.
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 used in document, is a topologically A mesh optical network, as used in document, is a topologically
connected collection of optical sub-networks whose node degree may connected collection of optical sub-networks whose node degree may
exceed 2. Such an optical network is assumed to be under the purview exceed 2. Such an optical network is assumed to be under the purview
of a single administrative entity. It is also possible to conceive of a single administrative entity. It is also possible to conceive
of a large scale global mesh optical network consisting of the of a large scale global mesh optical network consisting of the
voluntary interconnection of autonomous optical networks, each of voluntary interconnection of autonomous optical networks, each of
which is owned and administered by an independent entity. In such an which is owned and administered by an independent entity. In such an
environment, abstraction can be used to hide the internal details of environment, abstraction can be used to hide the internal details of
each autonomous optical cloud from external clouds. each autonomous optical cloud from external clouds.
Optical internetwork Optical internetwork
--------------------
An optical internetwork is a mesh-connected collection of optical An optical internetwork is a mesh-connected collection of optical
networks. Each of these networks may be under a different networks. Each of these networks may be under a 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.
Wavelength path Wavelength path
---------------
A lightpath that satisfies the wavelength continuity property is A lightpath that satisfies the wavelength continuity property is
called a wavelength path. called a wavelength path.
Opaque vs. transparent optical networks Opaque vs. transparent optical networks
---------------------------------------
A transparent optical network is an optical network in which optical A transparent optical network is an optical network in which optical
signals are transported from transmitter to receiver entirely in the signals are transported from transmitter to receiver entirely in the
optical domain without OEO conversion. Generally, intermediate optical domain without OEO conversion. Generally, intermediate
switching nodes in a transparent optical network do not have access switching nodes in a transparent optical network do not have access
to the payload carried by the optical signals. to the payload carried by the optical signals.
Note that amplification of signals at transit nodes is Note that amplification of signals at transit nodes is permitted in
permitted in transparent optical networks (e.g. using Erbium Doped transparent optical networks (e.g., using Erbium Doped Fiber
Fiber Amplifiers EDFAs). Amplifiers << EDFAs).
On the other hand, in opaque optical networks, transit nodes may On the other hand, in opaque optical networks, transit nodes may
manipulate optical signals traversing through them. An example of manipulate optical signals traversing through them. An example of
such manipulation would be OEO conversion which may involve 3R such manipulation would be OEO conversion which may involve 3R
operations (reshaping, retiming, regeneration, and perhaps operations (reshaping, retiming, regeneration, and perhaps
amplification). amplification).
Trust domain Trust domain
------------
A trust domain is a network under a single technical administration A trust domain is a network under a single technical administration
in which adequate security measures are established to prevent in which adequate security measures are established to prevent
unauthorized intrusion from outside the domain. Hence, it may be unauthorized intrusion from outside the domain. Hence, it may be
assumed that most nodes in the domain are deemed to be secure or assumed that most nodes in the domain are deemed to be secure or
trusted in some fashion. Generally, the rule for "single" trusted in some fashion. Generally, the rule for "single"
administrative control over a trust domain may be relaxed in administrative control over a trust domain may be relaxed in practice
practice if a set of administrative entities agree to trust one if a set of administrative entities agree to trust one another to
another to form an enlarged heterogeneous trust domain. However, to form an enlarged heterogeneous trust domain. However, to simplify
simplify the discussions in this document, it will be assumed, the discussions in this document, it will be assumed, without loss of
without loss of generality, that the term trust domain applies to a generality, that the term trust domain applies to a single
single administrative entity with appropriate security policies. It administrative entity with appropriate security policies. It should
should be noted that within a trust domain, any subverted node can be noted that within a trust domain, any subverted node can send
send control messages which can compromise the entire network. control messages which can compromise the entire network.
Flow Flow
----
In this document, the term flow will be used to signify the smallest In this document, the term flow will be used to signify the smallest
non-separable stream of data, from the point of view of an endpoint non-separable stream of data, from the point of view of an endpoint
or termination point (source or destination node). The reader or termination point (source or destination node). The reader should
should note that the term flow is heavily overloaded in contemporary note that the term flow is heavily overloaded in contemporary
networking literature. In this document, we will consider a networking literature. In this document, we will consider a
wavelength to be a flow, under certain circumstances. However, if wavelength to be a flow, under certain circumstances. However, if
there is a method to partition the bandwidth of the wavelength, then there is a method to partition the bandwidth of the wavelength, then
each partition may be considered a flow, for example using time each partition may be considered a flow, for example using time
division multiplexing (TDM), it may be feasible to consider each division multiplexing (TDM), it may be feasible to consider each
quanta of time within a given wavelength as a flow. quanta of time within a given wavelength as a flow.
Traffic Trunk Traffic Trunk
-------------
A traffic trunk is an abstraction of traffic flow traversing the A traffic trunk is an abstraction of traffic flow traversing the same
same path between two access points which allows some path between two access points which allows some characteristics and
characteristics and attributes of the traffic to be parameterized. attributes of the traffic to be parameterized.
3. The Network Model 3. The Network Model
3.1 Network Interconnection 3.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 optical channels. The peers over dynamically established switched optical channels. The
optical core itself is assumed to be incapable of processing optical core itself is assumed to be incapable of processing
individual IP packets in the data plane. individual IP 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 of which may be administered by a different entity. networks, each of which may 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 384 skipping to change at page 9, line 6
can be expected that topologically adjacent OXCs in an optical mesh can be expected that topologically adjacent OXCs in an optical mesh
network will be connected via multiple, parallel (bi-directional) network will be connected via multiple, parallel (bi-directional)
optical links. This network model is shown in Figure 1. optical links. This network model is shown in Figure 1.
In this environment, an optical sub-network may consist entirely of In this environment, an optical sub-network may consist entirely of
all-optical OXCs or OXCs with optical-electrical-optical (OEO) all-optical OXCs or OXCs with optical-electrical-optical (OEO)
conversion. Interconnection between sub-networks is assumed to be conversion. Interconnection between sub-networks is assumed to be
implemented through compatible physical interfaces, with suitable implemented through compatible physical interfaces, with suitable
optical-electrical conversions where necessary. The routers that optical-electrical conversions where necessary. The routers that
have direct physical connectivity with the optical network are have direct physical connectivity with the optical network are
referred to as "edge routers" with respect to the optical network. referred to as "edge routers" with respect to the optical network. As
As shown in Figure 1, other client networks (e.g., ATM) may also shown in Figure 1, other client networks (e.g., ATM) may also connect
connect to the optical network. 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
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
skipping to change at line 451 skipping to change at page 10, line 51
| Network | | Network | | Network | | Network |
| (e.g., ATM) | | | | (e.g., ATM) | | |
+- ------------+ +------------+ +- ------------+ +------------+
Figure 1: Optical Internetwork Model Figure 1: Optical Internetwork Model
Multiple traffic streams exiting from an OXC may be multiplexed onto Multiple traffic streams exiting from an OXC may be multiplexed onto
a fiber optic link using WDM technology. The WDM functionality may a fiber optic link using WDM technology. The WDM functionality may
exist outside of the OXC, and be transparent to the OXC. Or, this exist 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- function may be built into the OXC. In the later case, the cross-
connect table (conceptually) consists of pairs of the form, connect table (conceptually) consists of pairs of the form, <{input
<{input port i, Lambda(j)}, {output port k, Lambda(l)}>. This port i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that
indicates that the data stream received on wavelength Lambda(j) over the data stream received on wavelength Lambda(j) over input port i is
input port i is switched to output port k on Lambda(l). Automated switched to output port k on Lambda(l). Automated establishment of
establishment of lightpaths involves setting up the cross-connect lightpaths involves setting up the cross-connect table entries in the
table entries in the appropriate OXCs in a coordinated manner such appropriate OXCs in a coordinated manner such that the desired
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 the routers can transfer user between a pair of IP routers before the routers can transfer user
traffic among themselves. A lightpath between IP routers may traffic among themselves. A lightpath between IP routers may
traverse multiple optical networks and be subject to different traverse multiple optical networks and be subject to different
provisioning and restoration procedures in each network. provisioning and restoration procedures in each network.
The IP-based control plane issue for optical networks pertains to The IP-based control plane issue for optical networks pertains to the
the design of standard signaling and routing protocols for design of standard signaling and routing protocols for provisioning
provisioning and restoration of lightpaths across multiple optical and restoration of lightpaths across multiple optical networks.
networks. Similarly, IP transport over optical networks Similarly, IP transport over optical networks involves establishing
involves establishing IP reachability and seamlessly constructing IP reachability and seamlessly constructing forwarding paths from one
forwarding paths from one IP endpoint to another over an optical IP endpoint to another over an optical network.
network.
3.2 Control Structure 3.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 an optical network (between OXCs in node-to-node interface within an optical network (between OXCs in
different sub-networks), and the external node-to-node interface different sub-networks), and the external node-to-node interface
between nodes in different optical networks. These interfaces are between nodes in different optical networks. These interfaces are
also referred to as the User-Network Interface (UNI), the internal also referred to as the User-Network Interface (UNI), the internal
NNI (INNI), and the external NNI (ENNI), respectively. NNI (INNI), and the external NNI (ENNI), respectively.
The distinction between these interfaces arises out of the type and The distinction between these interfaces arises out of the type and
amount of control information flow across them. The client-optical amount of control information flow across them. The client-optical
internetwork interface (UNI) represents a service boundary between internetwork interface (UNI) represents a service boundary between
the client (e.g. IP router) and the optical network. The client and the client (e.g., IP router) and the optical network. The client and
server (optical network) are essentially two different roles: the server (optical network) are essentially two different roles: the
client role requests a service connection from a server; the server client role requests a service connection from a server; the server
role establishes the connection to fulfill the service request -- role establishes the connection to fulfill the service request --
provided all relevant admission control conditions are satisfied. provided all relevant admission control conditions are satisfied.
Thus, the control flow across the client-optical internetwork Thus, the control flow across the client-optical internetwork
interface is dependent on the set of services defined across it interface is dependent on the set of services defined across it and
and the manner in which the services may be accessed. The service the manner in which the services may be accessed. The service models
models are described in Section 4. The NNIs represent vendor- are described in Section 4. The NNIs represent vendor-independent
independent standardized interfaces for control flow between nodes. standardized interfaces for control flow between nodes. The
The distinction between the INNI and the ENNI is that the former is distinction between the INNI and the ENNI is that the former is an
an interface within a given network under a single technical interface within a given network under a single technical
administration, while the later indicates an interface at the administration, while the later indicates an interface at the
administrative boundary between networks. The INNI and ENNI may thus administrative boundary between networks. The INNI and ENNI may thus
differ in the policies that restrict control flow between nodes. differ in the policies that restrict control flow between nodes.
Security, scalability, stability, and information hiding are Security, scalability, stability, and information hiding are
important considerations in the specification of the ENNI. It is important considerations in the specification of the ENNI. It is
possible in principle to harmonize the control flow across the UNI possible in principle to harmonize the control flow across the UNI
and the NNI and eliminate the distinction between them. On the other and the NNI and eliminate the distinction between them. On the other
hand, it may be required to minimize flow of control information, hand, it may be required to minimize flow of control information,
especially routing-related information, over the UNI; and even over especially routing-related information, over the UNI; and even over
skipping to change at line 520 skipping to change at page 12, line 22
respects. In this document, these interfaces are treated as respects. In this document, these interfaces are treated as
distinct. distinct.
The client-optical internetwork interface can be categorized as The client-optical internetwork interface can be categorized as
public or private depending upon context and service models. Routing public or private depending upon context and service models. Routing
information (i.e., topology state information) can be exchanged information (i.e., topology state information) can be exchanged
across a private client-optical internetwork interface. On the other across a private client-optical internetwork interface. On the other
hand, such information is not exchanged across a public client- hand, such information is not exchanged across a public client-
optical internetwork interface, or such information may be exchanged optical internetwork interface, or such information may be exchanged
with very explicit restrictions (including, for example abstraction, with very explicit restrictions (including, for example abstraction,
filtration, etc). Thus, different relationships (e.g., peer or over- filtration, etc). Thus, different relationships (e.g., peer or
lay, Section 5) may occur across private and public logical over-lay, Section 5) may occur across private and public logical
interfaces. interfaces.
The physical control structure used to realize these logical The physical control structure used to realize these logical
interfaces may vary. For instance, for the client-optical interfaces may vary. For instance, for the client-optical
internetwork interface, some of the possibilities are: internetwork interface, some of the possibilities are:
1. Direct interface: An in-band or out-of-band IP control channel 1. Direct interface: An in-band or out-of-band IP control channel
(IPCC) may be implemented between an edge router and each OXC (IPCC) may be implemented between an edge router and each OXC to
to which it is connected. This control channel is used for which it is connected. This control channel is used for
exchanging signaling and routing messages between the router and exchanging signaling and routing messages between the router and
the OXC. With a direct interface, the edge router and the OXC it the OXC. With a direct interface, the edge router and the OXC it
connects to are peers with respect to the control plane. This connects to are peers with respect to the control plane. This
situation is shown in Figure 2. The type of routing and signaling situation is shown in Figure 2. The type of routing and signaling
information exchanged across the direct interface may vary information exchanged across the direct interface may vary
depending on the service definition. This issue is addressed in depending on the service definition. This issue is addressed in
the next section. Some choices for the routing protocol are OSPF the next section. Some choices for the routing protocol are OSPF
or ISIS (with traffic engineering extensions and additional or ISIS (with traffic engineering extensions and additional
enhancements to deal with the peculiar characteristics of optical enhancements to deal with the peculiar characteristics of optical
networks) or BGP, or some other protocol. Other directory-based networks) or BGP, or some other protocol. Other directory-based
skipping to change at line 553 skipping to change at page 13, line 6
The details of how the IP control channel is realized is outside The details of how the IP control channel is realized is outside
the scope of this document. the scope of this 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.
OXCs. One reason to have an indirect interface would be that the One reason to have an indirect interface would be that the OXCs
OXCs and/or clients do not support a direct signaling interface. and/or clients do not support a direct signaling interface.
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
| | | | | | | |
| +---------+ +---------+ | | +---------+ +---------+ | | +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | | | | | | | | | | | | | | | | | |
| | Routing | |Signaling| | | | Routing | |Signaling| | | | Routing | |Signaling| | | | Routing | |Signaling| |
| | Protocol| |Protocol | | | | Protocol| |Protocol | | | | Protocol| |Protocol | | | | Protocol| |Protocol | |
| | | | | | | | | | | | | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ |
| | | | | | | | | | | | | | | |
skipping to change at line 593 skipping to change at page 13, line 46
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.
4. IP over Optical Service Models and Requirements 4. 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.
4.1 Domain Services Model 4.1. Domain Services Model
Under the domain services model, the optical network primarily Under the domain services model, the optical network primarily offers
offers high bandwidth connectivity in the form of lightpaths. high bandwidth connectivity in the form of lightpaths. Standardized
Standardized signaling across the UNI (Figure 1) is used to invoke 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.
2. Lightpath deletion: This service allows an existing lightpath to 2. Lightpath deletion: This service allows an existing lightpath to
be deleted. be deleted.
skipping to change at line 638 skipping to change at page 14, line 43
the signaling protocol is required to convey a few messages with the signaling protocol is required to convey a few messages with
certain attributes in a point-to-point manner between the router and certain attributes in a point-to-point manner between the router and
the optical network. Such a protocol may be based on RSVP-TE or LDP, the optical network. Such a protocol may be based on RSVP-TE or LDP,
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
is discussed in Section 5. discussed in Section 5.
4.2 Unified Service Model 4.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
as a single integrated network from a control plane point of view. a single integrated network from a control plane point of view. In
In this regard, the OXCs are treated just like any other router as this regard, the OXCs are treated just like any other router as far
far as the control plane is considered. Thus, in principle, there is as the control plane is considered. Thus, in principle, there is no
no distinction between the UNI, NNIs and any other router-to-router 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 IP-based, for example leveraging the that this control plane is IP-based, for example leveraging the
traffic engineering extensions for MPLS or GMPLS, as described in traffic engineering extensions for MPLS or GMPLS, as described in
[1]. The unified service model has so far been discussed only in the [1]. The unified service model has so far been discussed only in the
context of a single administrative domain. A unified control plane context of a single administrative domain. A unified control plane
is possible even when there are administrative boundaries within an is 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
capabilities may not be practically attractive or even feasible in may not be practically attractive or even feasible in this case (see
this case (see Section 5). Section 5).
Under the unified service model and within the context of a GMPLS Under the unified service model and within the context of a GMPLS
network, optical network services are obtained implicitly during network, optical network services are obtained implicitly during
end-to-end GMPLS signaling. Specifically, an edge router can create end-to-end GMPLS signaling. Specifically, an edge router can create
a lightpath with specified attributes, or delete and modify a lightpath with specified attributes, or delete and modify
lightpaths as it creates GMPLS label-switched paths (LSPs). In this lightpaths as it creates GMPLS label-switched paths (LSPs). In this
regard, the services obtained from the optical network are similar regard, the services obtained from the optical network are similar to
to the domain services model. These services, however, may be the domain services model. These services, however, may be invoked
invoked in a more seamless manner as compared to the domain services in a more seamless manner as compared to the domain services model.
model. For instance, when routers are attached to a single optical For instance, when routers are attached to a single optical network
network (i.e., there are no ENNIs), a remote router could compute an (i.e., there are no ENNIs), a remote router could compute an end-to-
end-to-end path across the optical internetwork. It can then end path across the optical internetwork. It can then establish an
establish an LSP across the optical internetwork. But the edge LSP across the optical internetwork. But the edge routers must still
routers must still recognize that an LSP across the optical recognize that an LSP across the optical internetwork is a
internetwork is a lightpath, or a conduit for multiple packet-based lightpath, or a conduit for multiple packet-based LSPs.
LSPs.
The concept of "forwarding adjacency" can be used to specify virtual The concept of "forwarding adjacency" can be used to specify virtual
links across optical internetworks in routing protocols such as OSPF links across optical internetworks in routing protocols such as OSPF
[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, the lightpath can be internetwork between two edge routers, the lightpath can be
advertised as a forwarding adjacency (a virtual link) between these advertised as a forwarding adjacency (a virtual link) between these
routers. Thus, from a data plane point of view, the lightpaths routers. Thus, from a data plane point of view, the lightpaths
result in a virtual overlay between edge routers. The decisions as result in a virtual overlay between edge routers. The decisions as
to when to create such lightpaths, and the bandwidth management for to when to create such lightpaths, and the bandwidth management for
these lightpaths is identical in both the domain services model and these lightpaths is identical in both the domain services model and
the unified service model. The routing and signaling models for the unified service model. The routing and signaling models for
unified services is described in Sections 5 and 6. unified services is described in Sections 5 and 6.
4.3 Which Service Model? 4.3. Which Service Model?
The relative merits of the above service models can be debated at The relative merits 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 models. As noted routing and signaling mechanisms in support of both models. As noted
above, signaling for service requests can be unified to cover both above, signaling for service requests 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 Sections 5 and 6. routing protocols, as described in Sections 5 and 6.
4.4 What are the Possible Services? 4.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,
optical virtual private networks and bandwidth on demand are some of optical virtual private networks and bandwidth on demand are some of
the services that can be envisioned. the services that can be envisioned.
4.4.1 Optical Virtual Private Networks (OVPNs) 4.4.1. Optical Virtual Private Networks (OVPNs)
Given that the data plane links between IP routers over an optical Given that the data plane links between IP routers over an optical
network amounts to a virtual topology which is an overlay over the network amounts to a virtual topology which is an overlay over the
fiber optic network, it is easy to envision a virtual private fiber optic network, it is easy to envision a virtual private network
network of lightpaths that interconnect routers (or any other set of of lightpaths that interconnect routers (or any other set of clients)
clients) belonging to a single entity or a group of related entities belonging to a single entity or a group of related entities across a
across a public optical network. Indeed, in the case where the public optical network. Indeed, in the case where the optical
optical network provides connectivity for multiple sets of external network provides connectivity for multiple sets of external client
client networks, there has to be a way to enforce routing policies networks, there has to be a way to enforce routing policies that
that ensure routing separation between different sets of client ensure routing separation between different sets of client networks
networks (i.e., VPN service). (i.e., VPN service).
5. IP transport over Optical Networks 5. 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
control planes. The optical network provides a service to external planes. The optical network provides a service to external entities
entities in the form of fixed bandwidth transport pipes (optical in the form of fixed bandwidth transport pipes (optical paths). IP
paths). IP routers at the edge of the optical networks must routers at the edge of the optical networks must necessarily have
necessarily have such paths established between them before such paths established between them before communication at the IP
communication at the IP layer can commence. Thus, the IP data plane layer can commence. Thus, the IP data plane over optical networks is
over optical networks is realized over a virtual topology of optical realized over a virtual topology of optical paths. On the other
paths. On the other hand, IP routers and OXCs can have a peer hand, IP routers and OXCs can have a peer relation with respect to
relation with respect to the control plane, especially for routing the control plane, especially for routing protocols that permit the
protocols that permit the dynamic discovery of IP endpoints attached dynamic discovery of IP endpoints attached to the optical network.
to the optical network.
The IP over optical network architecture is defined essentially by The IP over optical network architecture is defined essentially by
the organization of the control plane. The assumption in this the organization of the control plane. The assumption in this
framework is that an IP-based control plane [1] is used, such as framework is that an IP-based control plane [1] is used, such as
GMPLS. Depending on the service model(Section 4), however, the GMPLS. Depending on the service model(Section 4), however, the
control planes in the IP and optical networks can be loosely or control planes in the IP and optical networks can be loosely or
tightly coupled. This coupling determines the following tightly coupled. This coupling determines the following
characteristics: characteristics:
o The details of the topology and routing information advertised by o The details of the topology and routing information advertised by
skipping to change at line 746 skipping to change at page 17, line 4
GMPLS. Depending on the service model(Section 4), however, the GMPLS. Depending on the service model(Section 4), however, the
control planes in the IP and optical networks can be loosely or control planes in the IP and optical networks can be loosely or
tightly coupled. This coupling determines the following tightly coupled. This coupling determines the following
characteristics: characteristics:
o The details of the topology and routing information advertised by o The details of the topology and routing information advertised by
the optical network across the client interface; the optical network across the client interface;
o The level of control that IP routers can exercise in selecting o The level of control that IP routers can exercise in selecting
explicit paths for connections across the optical network; explicit paths for connections across the optical network;
o Policies regarding the dynamic provisioning of optical paths o Policies regarding the dynamic provisioning of optical paths
between routers. These include access control, accounting, and between routers. These include access control, accounting, and
security issues. security issues.
The following interconnection models are then possible: The following interconnection models are then possible:
5.1 Interconnection Models 5.1. Interconnection Models
5.1.1 The Peer Model 5.1.1. The Peer Model
Under the peer model, the IP control plane acts as a peer of the Under the peer model, the IP control plane acts as a peer of the
optical transport network control plane. This implies that a single optical transport network control plane. This implies that a single
instance of the control plane is deployed over the IP and optical instance of the control plane is deployed over the IP and optical
domains. When there is a single optical network involved and the IP domains. When there is a single optical network involved and the IP
and optical domains belong to the same entity, then a common IGP and optical domains belong to the same entity, then a common IGP such
such as OSPF or IS-IS, with appropriate extensions, can be used to 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. Many of have to be defined to propagate topology state information. Many of
these extensions are occurring within the context of GMPLS. these extensions are occurring within the context of GMPLS.
When an optical internetwork with multiple optical networks is When an optical internetwork with multiple optical networks is
involved (e.g., spanning different administrative domains), a involved (e.g., spanning different administrative domains), a single
single instance of an intra-domain routing protocol is not instance of an intra-domain routing protocol is not attractive or
attractive or even realistic. In this case, inter-domain routing and even realistic. In this case, inter-domain routing and signaling
signaling protocols are needed. In either case, a tacit assumption protocols are needed. In either case, a tacit assumption is that a
is that a common addressing scheme will be used for the optical and common addressing scheme will be used for the optical and IP
IP networks. A common address space can be trivially realized by networks. A common address space can be trivially realized by using
using IP addresses in both IP and optical domains. Thus, the optical IP addresses in both IP and optical domains. Thus, the optical
network elements become IP addressable entities as noted in [1]. network elements become IP addressable entities as noted in [1].
5.1.2 The Overlay Model 5.1.2. The Overlay Model
Under the overlay model, the IP layer routing, topology Under the overlay model, the IP layer routing, topology distribution,
distribution, and signaling protocols are independent of the and signaling protocols are independent of the routing, topology
routing, topology distribution, and signaling protocols within the distribution, and signaling protocols within the optical domain.
optical domain. This model is conceptually similar to the classical This model is conceptually similar to the classical IP over ATM or
IP over ATM or MPOA models, but applied to an optical internetwork MPOA models, but applied to an optical internetwork instead. In the
instead. In the overlay model, a separate instance of the control overlay model, a separate instance of the control plane (especially
plane (especially the routing and signaling protocols) would have to the routing and signaling protocols) would have to be deployed in the
be deployed in the optical domain, independent of what exists in the optical domain, independent of what exists in the IP domain. In
IP domain. In certain circumstances, it may also be feasible to certain circumstances, it may also be feasible to statically
statically configure the optical channels that provide connectivity configure the optical channels that provide connectivity for the IP
for the IP domain in the overlay model. Static configuration can be domain in the overlay model. Static configuration can be effected
effected through network management functions. Static configuration, through network management functions. Static configuration, however,
however, is unlikely to scale in very large networks, and may not is unlikely to scale in very large networks, and may not support the
support the rapid connection provisioning requirements of future rapid connection provisioning requirements of future highly
highly competitive networking environments. competitive networking environments.
5.1.3 The Augmented Model 5.1.3. The Augmented Model
Under the augmented model, there are separate routing instances in Under the augmented model, there are separate routing instances in
the IP and optical domains, but certain types of information from the IP and optical domains, but certain types of information from one
one routing instance can be passed through to the other routing routing instance can be passed through to the other routing instance.
instance. For example, external IP addresses could be carried within For example, external IP addresses could be carried within the
the optical routing protocols to allow reachability information to optical routing protocols to allow reachability information to be
be passed to IP clients. passed to IP clients.
The routing approaches corresponding to these interconnection models The routing approaches corresponding to these interconnection models
are described below. are described below.
5.2 Routing Approaches 5.2. Routing Approaches
5.2.1 Integrated Routing 5.2.1. Integrated Routing
This routing approach supports the peer model within a single This routing approach supports the peer model within a single
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) may be information maintained by all nodes (OXCs and routers) may be
identical, but not necessarily. This approach permits a router to identical, but not necessarily. This approach permits a router to
compute an end-to-end path to another router across the optical compute an end-to-end path to another router across the optical
network. Suppose the path computation is triggered by the need to network. Suppose the path computation is triggered by the need to
route a label switched path (LSP) in a GMPLS environment. Such an route a label switched path (LSP) in a GMPLS environment. Such an
LSP can be established using GMPLS signaling, e.g., RSVP-TE or CR- LSP can be established using GMPLS signaling, e.g., RSVP-TE or CR-LDP
LDP with appropriate extensions. In this case, the signaling with appropriate extensions. In this case, the signaling protocol
protocol will establish a lightpath between two edge routers. This will establish a lightpath between two edge routers. This lightpath
lightpath is in essence a tunnel across the optical network, and may is in essence a tunnel across the optical network, and may have
have capacity much larger than the bandwidth required to support the capacity much larger than the bandwidth required to support the first
first LSP. Thus, it is essential that other routers in the network LSP. Thus, it is essential that other routers in the network realize
realize the availability of excess capacity within the lightpath so the availability of excess capacity within the lightpath so that
that subsequent LSPs between the routers can use it rather than subsequent LSPs between the routers can use it rather than
instantiating a new lightpath. The lightpath may therefore be instantiating a new lightpath. The lightpath may therefore be
advertised as a virtual link in the topology as a means to address advertised as a virtual link in the topology as a means to address
this issue. this issue.
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 872 skipping to change at page 19, line 35
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.
5.2.2 Domain-Specific Routing 5.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.
5.2.2.1 Domain-Specific Routing using BGP 5.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
would allow routers to advertise IP address prefixes within their would allow routers to advertise IP address prefixes within their
network to the optical internetwork and to receive external IP network to the optical internetwork and to receive external IP
address prefixes from the optical internetwork. The optical 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 may be used between border optical switches, and EBGP may (IBGP) is may be used between border optical switches, and EBGP may
skipping to change at line 920 skipping to change at page 20, line 35
prefixes to other border OXCs or edge routers. An edge router prefixes to other border OXCs or edge routers. An edge router
receiving this information need not propagate the egress address receiving this information need not propagate the egress address
further, but it must keep the association between external IP further, but it must keep the association between external IP
addresses and egress OXC addresses. When optical VPNs are addresses and egress OXC addresses. When optical VPNs are
implemented, the address prefixes advertised by the border OXCs may implemented, the address prefixes advertised by the border OXCs may
be accompanied by some VPN specific identification. be accompanied by some VPN specific identification.
There are however, some potential negative effects that could result There are however, some potential negative effects that could result
from domain-specific routing using BGP in an IPO environment: from domain-specific routing using BGP in an IPO environment:
o The amount of information that optical nodes will have to o The amount of information that optical nodes will have to maintain
maintain will not be bound by the size of the optical network will not be bound by the size of the optical network anymore, but
anymore, but will have to include external routes as well. will have to include external routes as well.
o The stability of the optical network control plane will o The stability of the optical network control plane will no longer
no longer be dictated solely by the dynamics emanating be dictated solely by the dynamics emanating within the optical
within the optical network, but may be affected by the network, but may be affected by the dynamics originating from
dynamics originating from external routing domains external routing domains from which external reachability
from which external reachability information is received. information is received.
5.2.3 Overlay Routing 5.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
used for IP over ATM. Under this approach, the optical network could 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
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.
5.3 Signaling-Related 5.3. Signaling-Related
5.3.1 The Role of MPLS 5.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, can be appropriately extended and used extensions, such as RSVP-TE, can be appropriately extended and used
for signaling lightpath requests. These protocols can be adapted for for signaling lightpath requests. These protocols can be adapted for
client/server signaling in the case of the domain services model, client/server signaling in the case of the domain services model, and
and for end-to-end integrated signaling in the case of the unified for end-to-end integrated signaling in the case of the unified
services model. services model.
5.3.2 Signaling Models 5.3.2. Signaling Models
With the domain-services model, the signaling control plane in the
IP and optical network are completely separate as shown in Figure 3 With the domain-services model, the signaling control plane in the 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
described in [5, 6]. described in [5, 6].
MPLS Signaling UNI Signaling MPLS or other signaling MPLS Signaling UNI Signaling MPLS or other signaling
skipping to change at line 999 skipping to change at page 22, line 22
| | | | | | | | | | | | | | | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ |
+-----------------------------+ | +-----------------------------+ +-----------------------------+ | +-----------------------------+
| |
| |
Completely Separated Addressing and Control Planes Completely Separated Addressing and Control Planes
Figure 3: Domain Services Signaling Model Figure 3: Domain Services Signaling Model
With the unified services model, the addressing is common in the IP With the unified services model, the addressing is common in the IP
network and optical internetwork and the respective signaling network and optical internetwork and the respective signaling control
control are related, as shown in Figure 4. It is understood that are related, as shown in Figure 4. It is understood that GMPLS
GMPLS signaling is implemented in the IP and optical domains, using 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
with regard to bandwidth. While the IP network may offer a continuum with regard to bandwidth. While the IP network may offer a continuum
of bandwidths, the optical internetwork will offer only discrete of bandwidths, the optical internetwork will offer only discrete
bandwidths. Thus, the signaling attributes and services are defined bandwidths. Thus, the signaling attributes and services are defined
independently for IP and optical domains. The routers at the edge of independently for IP and optical domains. The routers at the edge of
the optical internetwork must therefore identify service boundaries the optical internetwork must therefore identify service boundaries
and perform suitable translations in the signaling messages crossing and perform suitable translations in the signaling messages crossing
the IP-optical boundary. This may still occur even though the the IP-optical boundary. This may still occur even though the
signaling control plane in both networks are GMPLS-based and there signaling control plane in both networks are GMPLS-based and there is
is tighter coupling of the control plane as compared to the domain tighter coupling of the control plane as compared to the domain
services model. services model.
Service Boundary Service Boundary Service Boundary Service Boundary
| | | |
IP Layer GMPLS Signaling | Optical Layer GMPLS | IP Layer GMPLS IP Layer GMPLS Signaling | Optical Layer GMPLS | IP Layer GMPLS
| | | |
+--------+ +--------+ | +-------+ +-------+ | +--------+ +--------+ +--------+ | +-------+ +-------+ | +--------+
| | | | | | | | | | | | | | | | | | | | | | | |
| IP LSR +--+ IP LSR +--+--+Optical+--+Optical+-+--+ IP LSR +--- | IP LSR +--+ IP LSR +--+--+Optical+--+Optical+-+--+ IP LSR +---
| | | | | | LSR | | LSR | | | | | | | | | | LSR | | LSR | | | |
+-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+ +-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+
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 [10].
5.4 End-to-End Protection Models 5.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:
5.4.1 Segment-Wise Protection 5.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, i.e.,
i.e., each protected LSP has a pre-established hot stand-by in a 1+1 each protected LSP has a pre-established hot stand-by in a 1+1 or 1:1
or 1:1 configuration. In case of a failure of the primary LSP, configuration. In case of a failure of the primary LSP, traffic can
traffic can be immediately switched to the stand-by. This type of be immediately switched to the stand-by. This type of protection can
protection can be realized end-to-end as follows. With reference to be realized end-to-end as follows. With reference to Figure 5, let
Figure 5, let an LSP originate at (ingress) router interface A and an LSP originate at (ingress) router interface A and terminate at
terminate at (egress) router interface F. Under the first protection (egress) router interface F. Under the first protection option, a
option, a primary path for the LSP must be established first. Let primary path for the LSP must be established first. Let this path be
this path be as shown in Figure 5, traversing router interface B as shown in Figure 5, traversing router interface B in the ingress
in the ingress network, optical ports C (ingress) and D (egress), network, optical ports C (ingress) and D (egress), and router
and router interface E in the egress network. Next, 1+1 protection interface E in the egress network. Next, 1+1 protection is realized
is realized separately in each network by establishing a protection separately in each network by establishing a protection path between
path between points A and B, C and D and E and F. Furthermore, the points A and B, C and D and E and F. Furthermore, the segments B-C
segments B-C and D-E must themselves be 1+1 protected, using drop- and D-E must themselves be 1+1 protected, using drop- side
side protection. For the segment between C and D, the optical protection. For the segment between C and D, the optical
internetwork must offer a 1+1 service similar to that offered in the internetwork must offer a 1+1 service similar to that offered in the
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
5.4.2 Single-Layer Protection 5.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
rely on any protection services offered in the optical internetwork. on any protection services offered in the optical internetwork. Thus,
Thus, with reference to Figure 5, two SRLG-disjoint LSPs are with reference to Figure 5, two SRLG-disjoint LSPs are established
established between A and F. The corresponding segments in the between A and F. The corresponding segments in the optical
optical internetwork are treated as independent lightpaths in the internetwork are treated as independent lightpaths in the optical
optical internetwork. These lightpaths may be unprotected in the internetwork. These lightpaths may be unprotected in the optical
optical internetwork. internetwork.
5.4.3 Differences 5.4.3. Differences
A distinction between these two choices is as follows. Under the A distinction between these two choices is as follows. Under the
first choice, the optical internetwork is actively involved in end- first choice, the optical internetwork is actively involved in end-
to-end protection, whereas under the second choice, any protection to-end protection, whereas under the second choice, any protection
service offered in the optical internetwork is not utilized directly service offered in the optical internetwork is not utilized directly
by client IP network. Also, under the first choice, the protection by client IP network. Also, under the first choice, the protection
in the optical internetwork may apply collectively to a number of IP in the optical internetwork may apply collectively to a number of IP
LSPs. That is, with reference to Figure 5, many LSPs may be LSPs. That is, with reference to Figure 5, many LSPs may be
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
skipping to change at line 1120 skipping to change at page 25, line 10
up" at the service boundaries to realize end-to-end protection. A up" at the service boundaries to realize end-to-end protection. A
further advantage of this is that restoration is entirely contained further advantage of this is that restoration is entirely contained
within the network where the failure occurs, thereby improving the within the network where the failure occurs, thereby improving the
restoration latency, and perhaps network stability as a fault within restoration latency, and perhaps network stability as a fault within
an optical domain is contained and corrected within the domain. For an optical domain is contained and corrected within the domain. For
instance, if there is a failure in the optical internetwork, optical instance, if there is a failure in the optical internetwork, optical
network protocols restore the affected internal segments. Under the network protocols restore the affected internal segments. Under the
second choice, restoration signaling is always end-to-end between IP second choice, restoration signaling is always end-to-end between IP
routers, essentially by-passing the optical internetwork. A result routers, essentially by-passing the optical internetwork. A result
of this is that restoration latency could be higher. In addition, of this is that restoration latency could be higher. In addition,
restoration protocols in the IP layer must run transparently over restoration protocols in the IP layer must run transparently over the
the optical internetwork in the overlay mode. IP based recovery 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.
6. IP-based Optical Control Plane Issues 6. 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
followed across sub-networks and networks. 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
and across sub-networks. But this is simply a recommendation within and across sub-networks. But this is simply a recommendation within
this framework document, rather than an imperative requirement. this framework document, rather than an imperative requirement. Thus,
Thus, in the following, signaling and routing across sub-networks is in the following, signaling and routing across sub-networks is
considered first, followed by a discussion of similar issues across considered first, followed by a discussion of similar issues across
networks. networks.
6.1 Addressing 6.1. Addressing
For interoperability across optical sub-networks using an IP-centric For interoperability across optical sub-networks using an IP-centric
control plane, one of the fundamental issues is that of addressing. control plane, one of the fundamental issues is that of addressing.
What entities should be identifiable from a signaling and routing What entities should be identifiable from a signaling and routing
point of view? How should they be addressed? This section presents point of view? How should they be addressed? This section presents
some high level guidelines on this issue. some high level guidelines on this issue.
Identifiable entities in optical networks include OXCs, optical Identifiable entities in optical networks include 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 1175 skipping to change at page 26, line 21
adequate granularity when establishing optical trails. For instance, adequate granularity when establishing optical trails. For instance,
an OXC could have many ports, each of which may in turn terminate an OXC could have many ports, each of which may in turn terminate
many optical channels, each of which contain many sub-channels etc. many optical channels, each of which contain many sub-channels etc.
It is perhaps not reasonable to assume that every sub-channel or It is perhaps not reasonable to assume that every sub-channel or
channel termination, or even OXC ports could be assigned a unique IP channel termination, or even OXC ports could be assigned a unique IP
address. Also, the routing of an optical trail within the network address. Also, the routing of an optical trail within the network
does not depend on the precise termination point information, but does not depend on the precise termination point information, but
rather only on the terminating OXC. Thus, finer granularity rather only on the terminating OXC. Thus, finer granularity
identification of termination points is of relevance only to the identification of termination points is of relevance only to the
terminating OXC and not to intermediate OXCs (of course, resource terminating OXC and not to intermediate OXCs (of course, resource
allocation at each intermediate point would depend on the allocation at each intermediate point would depend on the granularity
granularity of resources requested). This suggests an identification of resources requested). This suggests an identification scheme
scheme whereby OXCs are identified by a unique IP address and a whereby OXCs are identified by a unique IP address and a "selector"
"selector" identifies further fine-grain information of relevance at identifies further fine-grain information of relevance at an OXC.
an OXC. This, of course, does not preclude the identification of This, of course, does not preclude the identification of these
these termination points directly with IP addresses(with a null termination points directly with IP addresses(with a null selector).
selector). The selector can be formatted to have adequate number of The selector can be formatted to have adequate number of bits and a
bits and a structure that expresses port, channel, sub-channel, etc, structure that expresses port, channel, sub-channel, etc,
identification. identification.
Within the optical network, the establishment of trail segments Within the optical network, the establishment of trail segments
between adjacent OXCs require the identification of specific port, between adjacent OXCs require the identification of specific port,
channel, sub-channel, etc. With a GMPLS control plane, a label channel, sub-channel, etc. With a GMPLS control plane, a label
serves this function. The structure of the label must be such that serves this function. The structure of the label must be such that
it can encode the required information [12]. it can encode the required information [10].
Another entity that must be identified is the SRLG [13]. An Another entity that must be identified is the SRLG [11]. An SRLG is
SRLG is an identifier assigned to a group of optical links that an identifier assigned to a group of optical links that share a
share a physical resource. For instance, all optical channels routed physical resource. For instance, all optical channels routed over
over the same fiber could belong to the same SRLG. Similarly, all the same fiber could belong to the same SRLG. Similarly, all fibers
fibers routed over a conduit could belong to the same SRLG. The routed over a conduit could belong to the same SRLG. The notable
notable characteristic of SRLGs is that a given link could belong to characteristic of SRLGs is that a given link could belong to more
more than one SRLG, and two links belonging to a given SRLG may than one SRLG, and two links belonging to a given SRLG may
individually belong to two other SRLGs. This is illustrated in individually belong to two other SRLGs. This is illustrated in
Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links
1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3. 1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3.
Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8 Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8
could belong to SRLG 4. (In this example, the same SRLG, i.e., 1, could belong to SRLG 4. (In this example, the same SRLG, i.e., 1,
contains links from two different adjacencies). contains links from two different adjacencies).
While the classification of physical resources into SRLGs is a While the classification of physical resources into SRLGs is a manual
manual operation, the assignment of unique identifiers to these operation, the assignment of unique identifiers to these SRLGs
SRLGs within an optical network is essential to ensure correct within an optical network is essential to ensure correct SRLG-
SRLG-disjoint path computation for protection. SRLGs could be disjoint path computation for protection. SRLGs could be identified
identified with a flat identifier (e.g., 32 bit integer). 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 [12]. 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.
6.2 Neighbor Discovery 6.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
local links to all neighbors by each OXC. Specifically, each OXC links to all neighbors by each OXC. Specifically, each OXC must
must determine the up/down status of each optical link, the determine the up/down status of each optical link, the bandwidth and
bandwidth and other parameters of the link, and the identity of the other parameters of the link, and the identity of the remote end of
remote end of the link (e.g., remote port number). The last piece of the link (e.g., remote port number). The last piece of information
information is used to specify an appropriate label when signaling is used to specify an appropriate label when signaling for lightpath
for lightpath provisioning. The determination of these parameters provisioning. The determination of these parameters could be based
could be based on a combination of manual configuration and an on a combination of manual configuration and an automated protocol
automated protocol running between adjacent OXCs. The running between adjacent OXCs. The characteristics of such a
characteristics of such a protocol would depend on the type of OXCs protocol would depend on the type of OXCs that are adjacent (e.g.,
that are adjacent (e.g., transparent or opaque). transparent or opaque).
Neighbor discovery would typically require in-band communication on Neighbor discovery would typically require in-band communication on
the bearer channels to determine local connectivity and link status. the bearer channels to determine local connectivity and link status.
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
skipping to change at line 1267 skipping to change at page 28, line 25
| | +----+-+-----+ | | +------+-----+ | | +----+-+-----+ | | +------+-----+
| +----------+ +--+ | | | | +----------+ +--+ | | |
| OXC4 +----------+ +----+ | | | OXC4 +----------+ +----+ | |
| +----------+ OXC5 +--------+ OXC6 | | +----------+ OXC5 +--------+ OXC6 |
| | | +--------+ | | | | +--------+ |
+--------------+ | | | | +--------------+ | | | |
+------+-----+ +------+-----+ +------+-----+ +------+-----+
Figure 6: Mesh Optical Network with SRLGs Figure 6: Mesh Optical Network with SRLGs
6.3 Topology Discovery 6.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.,
(e.g., OSPF, ISIS), or it can be done via the management plane (in OSPF, ISIS), or it can be done via the management plane (in the case
the case of centralized path computation). The implementation of a of centralized path computation). The implementation of a link state
link state protocol within a network (i.e., across sub-network protocol within a network (i.e., across sub-network boundaries) means
boundaries) means that the same protocol runs in OXCs in every sub- that the same protocol runs in OXCs in every sub-network. If this
network. If this assumption does not hold then interworking of assumption does not hold then interworking of routing between sub-
routing between sub-networks is required. This is similar to inter- networks is required. This is similar to inter-network routing
network routing discussed in Section 6.7. The focus in the following discussed in Section 6.7. The focus in the following is therefore on
is therefore on standardized link state routing. standardized link state routing.
In general, most of the link state routing functionality is In general, most of the link state routing functionality is
maintained when applied to optical networks. However, the maintained when applied to optical networks. However, the
representation of optical links, as well as some link parameters, representation of optical links, as well as some link parameters, are
are changed in this setting. Specifically, changed in this setting. Specifically,
o The link state information may consist of link bundles [14]. o The link state information may consist of link bundles [12]. Each
Each link bundle is represented as an abstract link in the network link bundle is represented as an abstract link in the network
topology. Different bundling representations are possible. For topology. Different bundling representations are possible. For
instance, the parameters of the abstract link may include the instance, the parameters of the abstract link may include the
number, bandwidth and the type of optical links contained in the number, bandwidth and the type of optical links contained in the
underlying link bundle [14]. Also, the SRLGs corresponding to each underlying link bundle [12]. Also, the SRLGs corresponding to
optical link in the bundle may be included as a parameter. each 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
(Section 6.5), the link state updates must have information that protection (Section 6.5), the link state updates must have
allows the computation of shared protection paths. information that allows the computation of shared protection
paths.
o A single routing adjacency could be maintained between neighbors o A single routing adjacency could be maintained between neighbors
which may have multiple optical links (or even multiple link which may have multiple optical links (or even multiple link
bundles) between them. This reduces the protocol messaging bundles) between them. This reduces the protocol messaging
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
process for hierarchical routing (e.g., OSPF with multiple areas) for hierarchical routing (e.g., OSPF with multiple areas) are areas
are areas that need further work. that need further work.
6.4 Protection and Restoration Models 6.4. Protection and 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 (or network segment) mechanisms are used to select an alternate link (or network segment)
between two OXCs across the INNI when a failure affects the primary between two OXCs across the INNI when a failure affects the primary
link (or primary network segment) over which the (protected) link (or primary network segment) over which the (protected)
lightpath is routed. Local restoration does not affect the end-to- lightpath is routed. Local restoration does not affect the end-to-
end route of the lightpath. When local restoration is not possible end route of the lightpath. When local restoration is not possible
(e.g., no alternate link is available between the adjacent OXCs in (e.g., no alternate link is available between the adjacent OXCs in
skipping to change at line 1339 skipping to change at page 29, line 51
alternate diverse path to circumvent failed resources. For end-to- alternate diverse path to circumvent failed resources. For end-to-
end restoration, alternate paths may be pre-computed to expedite the end restoration, alternate paths may be pre-computed to expedite the
recovery time. End to end restoration may also be mixed with local recovery time. End to end restoration may also be mixed with local
recovery in various ways depending on acceptable tradeoffs between recovery in various ways depending on acceptable tradeoffs between
utilization of network resources and recovery times. utilization of network resources and recovery times.
End-to-end protection may be based on two types of protection End-to-end protection may be based on two types of protection
schemes; "1 + 1" protection or shared protection. Under 1 + 1 schemes; "1 + 1" protection or shared protection. Under 1 + 1
protection, a back-up path is established for the protected primary protection, a back-up path is established for the protected primary
path along a physically diverse route. Both paths are active and the path along a physically diverse route. Both paths are active and the
failure along the primary path results in an immediate switch-over failure along the primary path results in an immediate switch-over to
to the back-up path. Under shared protection, back-up paths the back-up path. Under shared protection, back-up paths
corresponding to physically diverse primary paths may share the same corresponding to physically diverse primary paths may share the same
network resources. When a failure affects a primary path, it is network resources. When a failure affects a primary path, it is
assumed that the same failure will not affect the other primary assumed that the same failure will not affect the other primary paths
paths whose back-ups share resources. 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-
sub-network. If this fails, end-to-end restoration across sub- network. If this fails, end-to-end restoration across sub-networks
networks could be invoked. The border OXC that is the ingress to a could be invoked. The border OXC that is the ingress to a sub-
sub-network can act as the source for restoration procedures within network can act as the source for restoration procedures within a
a sub-network. The signaling for invoking end-to-end restoration sub-network. The signaling for invoking end-to-end restoration
across the INNI is described in Section 6.6.3. The computation of across the INNI is described in Section 6.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.
6.5 Route Computation 6.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
capacity required for routing lightpaths [15]. required for routing lightpaths [13].
Route computation with constraints may be accomplished using a Route computation with constraints may be accomplished using a number
number of algorithms [16]. When 1+1 protection is used, a back-up of algorithms [14]. When 1+1 protection is used, a back-up path that
path that does not traverse on any link which is part of the same does not traverse on any link which is part of the same SRLG as links
SRLG as links in the primary path must be computed. Thus, it is in the primary path must be computed. Thus, it is essential that the
essential that the SRLGs in the primary path be known during SRLGs in the primary path be known during alternate path computation,
alternate path computation, along with the availability of resources along with the availability of resources in links that belong to
in links that belong to other SRLGs. This requirement has certain other SRLGs. This requirement has certain implications on optical
implications on optical link bundling. Specifically, a bundled LSA link bundling. Specifically, a bundled LSA must include adequate
must include adequate information such that a remote OXC can information such that a remote OXC can determine the resource
determine the resource availability under each SRLG that the bundled availability under each SRLG that the bundled link refers to, and the
link refers to, and the relationship between links belonging to relationship between links belonging to different SRLGs in the
different SRLGs in the bundle. For example, considering Figure 3, bundle. For example, considering Figure 3, if links 1,2,3 and 4 are
if links 1,2,3 and 4 are bundled together in an LSA, the bundled LSA bundled together in an LSA, the bundled LSA must indicate that there
must indicate that there are three SRLGs which are part of the are three SRLGs which are part of the bundle (i.e., 1, 2 and 3), and
bundle (i.e., 1, 2 and 3), and that links in SRLGs 2 and 3 are also that links in SRLGs 2 and 3 are also part of SRLG 1.
part of SRLG 1.
To encode the SRLG relationships in a link bundle LSA, only links To encode the SRLG relationships in a link bundle LSA, only links
which belong to exactly the same set of SRLGs must be bundled which belong to exactly the same set of SRLGs must be bundled
together. With reference to Figure 3, for example, two bundles can together. With reference to Figure 3, for example, two bundles can
be advertised for links between OXC1 and OXC2, with the following be advertised for links between OXC1 and OXC2, with the following
information: information:
Bundle No. SRLGs Link Type Number Other Info Bundle No. SRLGs Link Type Number Other Info
---------- ----- --------- ------ ---------- -------------------------------------------------------
1 1,2 OC-48 3 --- 1 1,2 OC-48 3 ---
2 1,3 OC-192 1 --- 2 1,3 OC-192 1 ---
Assuming that the above information is available for each bundle at Assuming that the above information is available for each bundle at
every node, there are several approaches possible for path every node, there are several approaches possible for path
computation. For instance, computation. For instance,
1. The primary path can be computed first, and the (exclusive 1. The primary path can be computed first, and the (exclusive or
or shared) back-up is computed next based on the SRLGs chosen shared) back-up is computed next based on the SRLGs chosen for the
for the primary path. In this regard, primary path. In this regard,
o The primary path computation procedure can output a series of o The primary path computation procedure can output a series of
bundles the path is routed over. Since a bundle is uniquely bundles the path is routed over. Since a bundle is uniquely
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
skipping to change at line 1424 skipping to change at page 31, line 38
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
path computation procedure would output a series of nodes the path computation procedure would output a series of nodes the
path traverses. Each OXC in the path would have the freedom to path traverses. Each OXC in the path would have the freedom to
choose the particular bundle to route that segment of the choose the particular bundle to route that segment of the
primary path. This procedure would increase the chances of primary path. This procedure would increase the chances of
successfully setting up the primary path when link state successfully setting up the primary path when link state
information is not up to date everywhere. But the specific information is not up to date everywhere. But the specific
bundle chosen, and hence the SRLGs in the primary path, must be bundle chosen, and hence the SRLGs in the primary path, must be
captured during primary path set-up, for example, using the captured during primary path set-up, for example, using the
RSVP-TE Route Record Object [17]. This SRLG information is RSVP-TE Route Record Object [15]. This SRLG information is
then used for computing the back-up path. The back-up path may then used for computing the back-up path. The back-up path may
also be established specifying only which SRLGs to avoid in a also be established specifying only which SRLGs to avoid in a
given segment, rather than which bundles to use. This would given segment, rather than which bundles to use. This would
maximize the chances of establishing the back-up path. maximize the chances of establishing the back-up path.
2. The primary path and the back-up path are computed together in 2. The primary path and the back-up path are computed together in one
one step, for example, using Suurbaale's algorithm [18]. In this step, for example, using Suurbaale's algorithm [16]. In this
case, the paths must be computed using specific bundle case, the paths must be computed using specific bundle
information. information.
To summarize, it is essential to capture sufficient information in To summarize, it is essential to capture sufficient information in
link bundle LSAs to accommodate different path computation link bundle LSAs to accommodate different path computation procedures
procedures and to maximize the chances of successful path and to maximize the chances of successful path establishment.
establishment. Depending on the path computation procedure used, Depending on the path computation procedure used, the type of support
the type of support needed during path establishment (e.g., the needed during path establishment (e.g., the recording of link group
recording of link group or SRLG information during path or SRLG information during path establishment) may differ.
establishment) may differ.
When shared protection is used, the route computation algorithm must When shared protection is used, the route computation algorithm must
take into account the possibility of sharing links among multiple take into account the possibility of sharing links among multiple
back-up paths. Under shared protection, the back-up paths back-up paths. Under shared protection, the back-up paths
corresponding to SRLG-disjoint primary paths can be assigned the corresponding to SRLG-disjoint primary paths can be assigned the same
same links. The assumption here is that since the primary paths are links. The assumption here is that since the primary paths are not
not routed over links that have the same SRLG, a given failure will 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.
The distributed implementation of route computation for shared back- The distributed implementation of route computation for shared back-
up paths require knowledge about the routing of all primary and up paths require knowledge about the routing of all primary and
back-up paths at every node. This raises scalability concerns. For back-up paths at every node. This raises scalability concerns. For
this reason, it may be practical to consider the centralization of this reason, it may be practical to consider the centralization of
the route computation algorithm in a route server that has complete the route computation algorithm in a route server that has complete
knowledge of the link state and path routes. Heuristics for fully knowledge of the link state and path routes. Heuristics for fully
distributed route computation without complete knowledge of path distributed route computation without complete knowledge of path
routes are to be determined. Path computation for restoration is routes are to be determined. Path computation for restoration is
further described in [13]. further described in [11].
6.6 Signaling Issues 6.6. Signaling Issues
Signaling within an optical network for lightpath provisioning Signaling within an optical network for lightpath provisioning is a
is a relatively simple operation if a standard procedure is relatively simple operation if a standard procedure is implemented
implemented within all sub-networks. Otherwise, proprietary within all sub-networks. Otherwise, proprietary signaling may be
signaling may be implemented within sub-networks, but converted back implemented within sub-networks, but converted back to standard
to standard signaling across the INNI. This is similar to signaling signaling across the INNI. This is similar to signaling across the
across the ENNI, as described in Section 6.7. In the former case, ENNI, as described in Section 6.7. In the former case, signaling
signaling messages may carry strict explicit route information, messages may carry strict explicit route information, while in the
while in the latter case the route information should be loose, at latter case the route information should be loose, at the level of
the level of abstraction of sub-networks. Once a route is determined abstraction of sub-networks. Once a route is determined for a
for a lightpath, each OXC along the path must appropriately lightpath, each OXC along the path must appropriately configure their
configure their cross-connects in a coordinated fashion. This cross-connects in a coordinated fashion. This coordination is
coordination is conceptually analogous to selecting incoming and conceptually analogous to selecting incoming and outgoing labels in a
outgoing labels in a label-switched environment. Thus, protocols label-switched environment. Thus, protocols like RSVP-TE [9] may be
like RSVP-TE [11] may be adapted and used across the INNI for this adapted and used across the INNI for this purpose. The adaptation of
purpose. The adaptation of IP-based signaling protocols must take IP-based signaling protocols must take into account a number of
into account a number of peculiar attributes of optical networks. peculiar attributes of optical networks.
6.6.1 Bi-Directional Lightpath Establishment 6.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"
"next" OXC B. Concurrently, OXC B may select output port j for OXC B. Concurrently, OXC B may select output port j for setting up a
setting up a different optical path, where the "next" OXC is A. This different optical path, where the "next" OXC is A. This results in a
results in a "collision". Similarly, when WDM functionality is built "collision". Similarly, when WDM functionality is built into OXCs, a
into OXCs, a collision occurs when adjacent OXCs choose directly collision occurs when adjacent OXCs choose directly connected output
connected output ports and the same wavelength for two different ports and the same wavelength for two different optical paths. There
optical paths. There are two ways to deal with such collisions. are two ways to deal with such collisions. First, collisions may be
First, collisions may be detected and the involved paths may be torn detected and the involved paths may be torn down and re-established.
down and re-established. Or, collisions may be avoided altogether. Or, collisions may be avoided altogether.
6.6.2 Failure Recovery 6.6.2. Failure Recovery
The impact of transient partial failures must be minimized in an The impact of transient partial failures must be minimized in an
optical network. Specifically, optical paths that are not directly optical network. Specifically, optical paths that are not directly
affected by a failure must not be torn down due to the failure. For affected by a failure must not be torn down due to the failure. For
example, the control processor in an OXC may fail, affecting example, the control processor in an OXC may fail, affecting
signaling and other internodal control communication. Similarly, signaling and other internodal control communication. Similarly,
the control channel between OXCs may be affected temporarily by a the control channel between OXCs may be affected temporarily by a
failure. These failure may not affect already established optical failure. These failure may not affect already established optical
paths passing through the OXC fabric. The detection of such failures paths passing through the OXC fabric. The detection of such failures
by adjacent nodes, for example, through a keepalive mechanism by adjacent nodes, for example, through a keepalive mechanism between
between signaling peers, must not result in these optical paths signaling peers, must not result in these optical paths being torn
being torn down. 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.
6.6.3 Restoration 6.6.3. Restoration
Signaling for restoration has two distict phases. There is a Signaling for restoration has two distinct 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
back-up path is actually put in service. The former phase typically path is actually put in service. The former phase typically is not
is not subject to strict time constraints, while the latter is. 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
up path is a little bit different. Here, each OXC must understand back-up path is a little bit different. Here, each OXC must
which back-up paths can share resources among themselves. The understand which back-up paths can share resources among themselves.
signaling message must itself indicate shared reservation. The The signaling message must itself indicate shared reservation. The
sharing rule is as described in Section 6.4: back-up paths sharing rule is as described in Section 6.4: back-up paths
corresponding to physically diverse primary paths may share the same corresponding to physically diverse primary paths may share the same
network resources. It may therefore be necessary for the signaling network resources. It may therefore be necessary for the signaling
message to carry adequate information that allows an OXC to verify message to carry adequate information that allows an OXC to verify
that appropriateness of having a set of back-up paths sharing that appropriateness of having a set of back-up paths sharing
certain. certain.
Under both 1+1 and shared protection, the activation phase has two Under both 1+1 and shared protection, the activation phase has two
parts: propagation of failure information to the source OXC from the parts: propagation of failure information to the source OXC from the
point of failure, and activation of the back-up path. The signaling point of failure, and activation of the back-up path. The signaling
for these two phases must be very fast in order to realize response for these two phases must be very fast in order to realize response
times in the order of tens of milliseconds. When optical links are times in the order of tens of milliseconds. When optical links are
SONET-based, in-band signals may be used, resulting in expedited SONET-based, in-band signals may be used, resulting in expedited
response. With out-of-band control, it may be necessary to response. With out-of-band control, it may be necessary to consider
consider fast signaling over the control channel using very short IP fast signaling over the control channel using very short IP packets
packets and prioritized processing. While it is possible to use RSVP and prioritized processing. While it is possible to use RSVP or CR-
or CR-LDP for activating protection paths, these protocols do not LDP for activating protection paths, these protocols do not provide
provide any means to give priority to restoration signaling as any means to give priority to restoration signaling as opposed to
opposed to signaling for provisioning. For instance, it is possible signaling for provisioning. For instance, it is possible for a
for a restoration-related RSVP message to be queued behind a number restoration-related RSVP message to be queued behind a number of
of provisioning messages thereby delaying restoration. It may provisioning messages thereby delaying restoration. It may therefore
therefore be necessary to develop a notion of prioritization for be necessary to develop a notion of prioritization for restoration
restoration signaling and incorporate appropriate mechanisms into signaling and incorporate appropriate mechanisms into existing
existing signaling protocols to achieve this. Alternatively, a new signaling protocols to achieve this. Alternatively, a new signaling
signaling mechanism may be developed exclusively for activating mechanism may be developed exclusively for activating protection
protection paths during restoration. paths during restoration.
6.7 Optical Internetworking 6.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 1591 skipping to change at page 35, line 17
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.
6.7.1 Neighbor Discovery 6.7.1. Neighbor Discovery
Neighbor discovery procedure, as described in Section 6.2, can be Neighbor discovery procedure, as described in Section 6.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.
6.7.2 Addressing and Routing Model 6.7.2. Addressing and Routing Model
The addressing mechanisms described in Section 6.1 can be used to The addressing mechanisms described in Section 6.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
It is essential that the OXC IP addresses are unique within the 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.
6.7.3 Restoration 6.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 6.6.3. End-to-end restoration across networks described in Section 6.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 6.4. network, as described in Section 6.4.
7. Other Issues 7. Other Issues
7.1 WDM and TDM in the Same Network 7.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)
wavelength) is used, then TDM is leveraged as an additional method is used, then TDM is leveraged as an additional method to
to differentiate between "flows." In such cases, wavelengths and differentiate between "flows". In such cases, wavelengths and time
time intervals (sub-channels) within a wavelength become analogous intervals (sub-channels) within a wavelength become analogous to
to labels (as noted in [1]) which can be used to make switching 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.
7.2 Wavelength Conversion 7.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
more sophisticated than a simple repeater, that is capable of sophisticated than a simple repeater, that is capable of switching
switching and converting a wavelength Lambda(k) from an input port and converting a wavelength Lambda(k) from an input port to a
to a wavelength Lambda(l) on an output port. In this display, it wavelength Lambda(l) on an output port. In this display, it is not
is not necessarily the case that Lambda(k) = Lambda(l), nor is it necessarily the case that Lambda(k) = Lambda(l), nor is it
necessarily the case that the data carried on Lambda(k) is switched necessarily the case that the data carried on Lambda(k) is switched
through the device without being examined or modified. through the device without being examined or modified.
It is not necessary to have a wavelength converter at every It is not necessary to have a wavelength converter at every switching
switching element. A number of studies have attempted to address element. A number of studies have attempted to address the issue of
the issue of the value of wavelength conversion in an optical the value of wavelength conversion in an optical network. Such
network. Such studies typically use the blocking probability (the studies typically use the blocking probability (the probability that
probability that a lightpath cannot be established because the a lightpath cannot be established because the requisite wavelengths
requisite wavelengths are not available) as a metric to adjudicate are not available) as a metric to adjudicate the effectiveness of
the effectiveness of wavelength conversion. The IP over optical wavelength conversion. The IP over optical architecture must take
architecture must take into account hybrid networks with some OXCs into account hybrid networks with some OXCs capable of wavelength
capable of wavelength conversion and others incapable of this. The conversion and others incapable of this. The GMPLS "label set"
GMPLS "label set" mechanism [4] supports the selection of the same mechanism [4] supports the selection of the same label (i.e.,
label (i.e., wavelength) across an NNI. wavelength) across an NNI.
7.3 Service Provider Peering Points 7.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.
layer. This is consistent with the need to support optical layer This is consistent with the need to support optical layer services
services independent of higher layers payloads. In the context of IP independent of higher layers payloads. In the context of IP over
over optical networks, peering relationships between different trust 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.
7.4 Rate of Lightpath Set-Up 7.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
skipping to change at line 1705 skipping to change at page 37, line 41
routed data traffic, routed data traffic,
o Establishment and re-arrangement of arbitrary virtual topologies o Establishment and re-arrangement of arbitrary virtual topologies
over rings and other physical layer topologies. over rings and other physical layer topologies.
o Use of stable traffic engineering control systems to engineer o Use of stable traffic engineering control systems to engineer
lightpath connections to enhance network performance, either for lightpath connections to enhance network performance, either for
explicit demand based QoS reasons or for load balancing). explicit demand based QoS reasons or for load balancing).
Other issues surrounding dynamic connection setup within the core Other issues surrounding dynamic connection setup within the core
center around resource usage at the edge of the optical domain. center around resource usage at the edge of the optical domain. One
One potential issue pertains to the number of flows that can be potential issue pertains to the number of flows that can be processed
processed by an ingress or egress network element either because of by an ingress or egress network element either because of aggregate
aggregate bandwidth limitations or because of a limitation on the bandwidth limitations or because of a limitation on the number of
number of flows (e.g., lightpaths) that can be processed 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-provision paths based on some criteria setup would be to quickly pre-provision paths based on some criteria
(e.g., a corporate executive wants a high bandwidth reliable (e.g., a corporate executive wants a high bandwidth reliable
connection, etc.). In this scenario, a set of paths can be pre- connection, etc.). In this scenario, a set of paths can be pre-
provisioned, but not actually instantiated until the customer provisioned, but not actually instantiated until the customer
initiates an authenticated and authorized setup requests, which is initiates an authenticated and authorized setup requests, which is
consistent with existing agreements between the provider and the consistent with existing agreements between the provider and the
customer. In a sense, the customer. In a sense, the provider may have already agreed to supply
provider may have already agreed to supply this service, but will this service, but will only instantiate it by setting up a lightpath
only instantiate it by setting up a lightpath when the customer when the customer submits an explicit request.
submits an explicit request.
7.5 Distributed vs. Centralized Provisioning 7.5. Distributed vs. Centralized Provisioning
This document has mainly dealt with a distributed model for This document has mainly dealt with a distributed model for lightpath
lightpath provisioning, in which all nodes maintain a synchronized provisioning, in which all nodes maintain a synchronized topology
topology database, and advertise topology state information to database, and advertise topology state information to maintain and
maintain and refresh the database. A constraint-based routing entity refresh the database. A constraint-based routing entity in each node
in each node then uses the information in the topology database and then uses the information in the topology database and other relevant
other relevant details to compute appropriate paths through the details to compute appropriate paths through the optical domain.
optical domain. Once a path is computed, a signaling protocol (e.g., Once a path is computed, a signaling protocol (e.g., [9]) is used to
[11]) is used to instantiate the lightpath. 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
server in order to set up a lightpath from the source to the in order to set up a lightpath from the source to the destination.
destination. The server would then check to see if such a lightpath The server would then check to see if such a lightpath can be
can be established based on prevailing conditions. Furthermore, established based on prevailing conditions. Furthermore, depending
depending on the specifics of the model, the server may either setup on the specifics of the model, the server may either setup the
the lightpath on behalf of the client or provide the necessary lightpath on behalf of the client or provide the necessary
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.
7.6 Optical Networks with Additional Configurable Components 7.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.
7.7 Optical Networks with Limited Wavelength Conversion Capability 7.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
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 [17]. Thus there
are strong motivators to introduce "domains of transparency" wherein are strong motivators to introduce "domains of transparency" wherein
all-optical networking equipment would transport data unfettered by all-optical networking equipment would transport data unfettered by
these drawbacks. these drawbacks.
Thus, the issue of IP over optical networking in all optical sub- Thus, the issue of IP over optical networking in all optical sub-
networks, and sub-networks with limited wavelength conversion networks, and sub-networks with limited wavelength conversion
capability merits special attention. In such networks, transmission capability merits special attention. In such networks, transmission
impairments resulting from the peculiar characteristics of optical impairments resulting from the peculiar characteristics of optical
communications complicate the process of path selection. These communications complicate the process of path selection. These
transmission impairments include loss, noise (due primarily to transmission impairments include loss, noise (due primarily to
skipping to change at line 1801 skipping to change at page 39, line 41
dispersion and polarization mode dispersion), cross-talk, and non- dispersion and polarization mode dispersion), cross-talk, and non-
linear effects. In such networks, the feasibility of a path between linear effects. In such networks, the feasibility of a path between
two nodes is no longer simply a function of topology and resource two nodes is no longer simply a function of topology and resource
availability but will also depend on the accumulation of impairments availability but will also depend on the accumulation of impairments
along the path. If the impairment accumulation is excessive, the along the path. If the impairment accumulation is excessive, the
optical signal to noise ratio (OSNR) and hence the electrical bit optical signal to noise ratio (OSNR) and hence the electrical bit
error rate (BER) at the destination node may exceed prescribed error rate (BER) at the destination node may exceed prescribed
thresholds, making the resultant optical channel unusable for data thresholds, making the resultant optical channel unusable for data
communication. The challenge in the development of IP-based control communication. The challenge in the development of IP-based control
plane for optical networks is to abstract these peculiar plane for optical networks is to abstract these peculiar
characteristics of the optical layer [19] in a generic fashion, so characteristics of the optical layer [17] in a generic fashion, so
that they can be used for path computation. that they can be used for path computation.
8. Evolution Path for IP over Optical Architecture 8. Evolution Path for IP over Optical Architecture
The architectural models described in Section 5 imply a certain The architectural models described in Section 5 imply a certain
degree of implementation complexity. Specifically, the overlay degree of implementation complexity. Specifically, the overlay model
model was described as the least complex for near term deployment was described as the least complex for near term deployment and the
and the peer model the most complex. Nevertheless, each model has peer model the most complex. Nevertheless, each model has certain
certain advantages and this raises the question as to the evolution advantages and this raises the question as to the evolution path for
path for IP over optical network architectures. 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
optical domains. Under this model, direct signaling between IP domains. Under this model, direct signaling between IP routers and
routers and optical networks is likely to be triggered by offline optical networks is likely to be triggered by offline traffic
traffic engineering decisions. The next step in the evolution of IP- engineering decisions. The next step in the evolution of IP-optical
optical interaction is the introduction of reachability information interaction is the introduction of reachability information exchange
exchange between the two domains. This would potentially allow between the two domains. This would potentially allow lightpaths to
lightpaths to be established as part of end-to-end LSP set-up. The be established as part of end-to-end LSP set-up. The final phase is
final phase is the support for the full peer model with more the support for the full peer model with more sophisticated routing
sophisticated routing interaction between IP and optical domains. interaction between IP and optical domains.
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. In this evolution, the beginning facilitates this type of evolution. In this evolution, the
signaling capability and semantics at the IP-optical boundary would signaling capability and semantics at the IP-optical boundary would
become more sophisticated, but the basic structure of signaling become more sophisticated, but the basic structure of signaling would
would remain. This would allow incremental developments as the remain. This would allow incremental developments as the
interconnection model becomes more sophisticated, rather than interconnection model becomes more sophisticated, rather than
complete re-development of signaling capabilities. complete re-development of signaling capabilities.
From a routing point of view, the use of Network Management Systems From a routing point of view, the use of Network Management Systems
(NMS) for static connection management is prevalent in legacy (NMS) for static connection management is prevalent in legacy optical
optical networks. Going forward, it can be expected that connection networks. Going forward, it can be expected that connection routing
routing using the control plane will be gradually introduced and using the control plane will be gradually introduced and integrated
integrated into operational infrastructures. The introduction of into operational infrastructures. The introduction of routing
routing capabilities can be expected to occur in a phased approach. capabilities can be expected to occur in a phased approach.
It is likely that in the first phase, service providers will either It is likely that in the first phase, service providers will either
upgrade existing local element management (EMS) software with upgrade existing local element management (EMS) software with
additional control plane capabilities (and perhaps the hardware as additional control plane capabilities (and perhaps the hardware as
well), or upgrade the NMS software in order to introduce some degree well), or upgrade the NMS software in order to introduce some degree
of automation within each optical subnetwork. For this reason, it of automation within each optical subnetwork. For this reason, it
may be desirable to partition the network into subnetworks and may be desirable to partition the network into subnetworks and
introduce IGP interoperability within each subnetwork (i.e. at the introduce IGP interoperability within each subnetwork (i.e., at the
I-NNI level), and employ either static or signaled interoperability I-NNI level), and employ either static or signaled interoperability
between subnetworks. Consequently, it can be envisioned that the between subnetworks. Consequently, it can be envisioned that the
first phase in the evolution towards network level control plane first phase in the evolution towards network level control plane
interoperability in IP over Optical networks will be organized interoperability in IP over Optical networks will be organized around
around a system of optical subnetworks which are interconnected a system of optical subnetworks which are interconnected statically
statically (or dynamically in a signaled configuration). During this (or dynamically in a signaled configuration). During this phase, an
phase, an overlay interconnection model will be used between the overlay interconnection model will be used between the optical
optical network itself and external IP and MPLS routers (as network itself and external IP and MPLS routers (as described in
described in Section 5.2.3). Section 5.2.3).
Progressing with this phased approach to IPO routing Progressing with this phased approach to IPO routing
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 dynamically
exchange reachability and other types of routing information. exchange reachability and other types of routing information. Another
Another more sophisticated step during this phase is to introduce more sophisticated step during this phase is to introduce dynamic
dynamic routing at the E-NNI level. This means that any neighboring routing at the E-NNI level. This means that any neighboring networks
networks (independent of internal switching capability) would be (independent of internal switching capability) would be capable of
capable of exchanging routing information with peers across the E- exchanging routing information with peers across the E-NNI.
NNI.
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 to the current lack of operational affiliated. In any case, due to 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
heterogeneous network (these issues may exist even if the hardware heterogeneous network (these issues may exist even if the hardware
skipping to change at line 1904 skipping to change at page 41, line 48
inter-domain routing environments. inter-domain routing environments.
9. Security Considerations 9. Security Considerations
The architectural framework described in this document requires a The architectural framework described in this document requires a
number of different protocol mechanisms for its realization. number of different protocol mechanisms for its realization.
Specifically, the role of neighbor discovery, routing, and signaling Specifically, the role of neighbor discovery, routing, and signaling
protocols were highlighted in previous sections. The general protocols were highlighted in previous sections. The general
security issues that arise with these protocols include: security issues that arise with these protocols include:
o The authentication of entities exchanging information o The authentication of entities exchanging information (e.g.,
(e.g., signaling, routing, or link management) across a control signaling, routing, or link management) across a control
interface; interface;
o Ensuring the integrity of the information exchanged across the o Ensuring the integrity of the information exchanged across the
interface; interface;
o Protection of the control mechanisms from intrusions and other o Protection of the control mechanisms from intrusions and other
modes of outside interference. modes of outside interference.
Because optical connections may carry high volumes of traffic and Because optical connections may carry high volumes of traffic and are
are generally quite expensive, mechanisms are required to safeguard generally quite expensive, mechanisms are required to safeguard
optical networks against intrusions and unauthorized utilization of optical networks against intrusions and unauthorized utilization of
network resources. network resources.
In addition to the security aspects relating to the control plane, In addition to the security aspects relating to the control plane,
the data plane must also be protected from external interference. the data plane must also be protected from external interference.
An important consideration in optical networks is the separation of An important consideration in optical networks is the separation of
control channels from data channels. This decoupling implies that control channels from data channels. This decoupling implies that
the state of the bearer channels carrying user traffic cannot be the state of the bearer channels carrying user traffic cannot be
inferred from the state of the control channels. Similarly, the inferred from the state of the control channels. Similarly, the
skipping to change at line 1948 skipping to change at page 42, line 44
security (RPSEC) efforts within the IETF should be considered in the security (RPSEC) efforts within the IETF should be considered in the
design of control protocols for optical networks. design of control protocols for optical networks.
In Section 2, the concept of a trust domain was defined as a network In Section 2, the concept of a trust domain was defined as a network
under a single technical administration in which adequate security under a single technical administration in which adequate security
measures are established to prevent unauthorized intrusion from measures are established to prevent unauthorized intrusion from
outside the domain. It should be strongly noted that within a trust outside the domain. It should be strongly noted that within a trust
domain, any subverted node can send control messages which can domain, any subverted node can send control messages which can
compromise the entire network. compromise the entire network.
9.1 General security aspects 9.1. General security aspects
Communication protocols usually require two main security Communication protocols usually require two main security mechanisms:
mechanisms: authentication and confidentiality. Authentication authentication and confidentiality. Authentication mechanisms ensure
mechanisms ensure data origin verification and message integrity so data origin verification and message integrity so that intrusions and
that intrusions and unauthorized operations can be detected and unauthorized operations can be detected and mitigated. For example,
mitigated. For example, with reference to Figure 1, message with reference to Figure 1, message authentication can prevent a
authentication can prevent a malicious IP client from mounting a malicious IP client from mounting a denial of service attack against
denial of service attack against the optical network by invoking an the optical network by invoking an excessive number of connection
excessive number of connection creation requests across the UNI creation requests across the UNI interface. Another important
interface. security consideration is the need to reject replayed control
packets. This capability can assist in countering some forms of
denial of service attacks. Replay protection provides a form of
partial sequence integrity, and can be implemented in conjunction
with an authentication mechanism.
Confidentiality of signaling messages is also desirable, especially Confidentiality of signaling messages is also desirable, especially
in scenarios where message attributes between communicating entities in scenarios where message attributes between communicating entities
include sensitive or private information. Examples of such include sensitive or private information. Examples of such
attributes include account numbers, contract identification attributes include account numbers, contract identification
information, and similar types of private data. information, and similar types of private data.
The case of equipment that are not co-located presents increased The case of equipment that are not co-located presents increased
security threats. In such scenarios, the communicating entities security threats. In such scenarios, the communicating entities
engaged in protocol message transactions may be connected over an engaged in protocol message transactions may be connected over an
skipping to change at line 1995 skipping to change at page 44, line 5
blocking for subsequent requests. This aspect might require some blocking for subsequent requests. This aspect might require some
global coordination of resource allocation. global coordination of resource allocation.
Another related form of subtle denial of service attack could occur Another related form of subtle denial of service attack could occur
when improbable optical paths are requested (i.e., paths within the when improbable optical paths are requested (i.e., paths within the
network for which resources are insufficiently provisioned). Such network for which resources are insufficiently provisioned). Such
requests for improbable paths may consume ports on optical switching requests for improbable paths may consume ports on optical switching
elements within the network resulting in denial of service for elements within the network resulting in denial of service for
subsequent connection requests. subsequent connection requests.
9.2 Security Considerations for Protocol Mechanisms 9.2. Security Considerations for Protocol Mechanisms
The security requirements for IP-centric control protocols employed The security requirements for IP-centric control protocols employed
in the control plane of optical networks would depend on the in the control plane of optical networks would depend on the specific
specific characteristics of the protocols and the security risks characteristics of the protocols and the security risks that exist in
that exist in a particular operational context. Such details a particular operational context. Such details relating to
relating to particular operational contexts are beyond the scope of particular operational contexts are beyond the scope of this document
this document and hence are not considered further. Nevertheless, it and hence are not considered further. Nevertheless, it must be
must be stated that such control protocols must take into account stated that such control protocols must take into account the issues
the issues associated with the separation of control channels from associated with the separation of control channels from data channels
data channels in switched optical networks, and the magnitude and in switched optical networks, and the magnitude and extent of service
extent of service interruptions within the IP domain that could interruptions within the IP domain that could result from outages
result from outages emanating from the optical domain. emanating from the optical domain.
10. Summary and Conclusions 10. Summary and Conclusions
The objective of this document was to define a framework for IP over The objective of this document was to define a framework for IP over
optical networks, considering the service models, and routing and optical networks, considering the service models, and routing and
signaling issues. There are a diversity of choices for IP-optical signaling issues. There are a diversity of choices for IP-optical
control interconnection, service models, and protocol mechanisms. control interconnection, service models, and protocol mechanisms. The
The approach advocated in this document was to support different approach advocated in this document was to support different service
service models which allow for future enhancements, and define models which allow for future enhancements, and define complementary
complementary signaling and routing mechanisms to enable these signaling and routing mechanisms to enable these capabilities. An
capabilities. An evolutionary scenario, based on a common signaling evolutionary scenario, based on a common signaling framework (e.g.,
framework (e.g. based on GMPLS) was suggested, with the capability based on GMPLS) was suggested, with the capability to increase the
to increase the complexity of interworking functionality as the complexity of interworking functionality as the requirements become
requirements become more sophisticated. A key aspect of this more sophisticated. A key aspect of this evolutionary principle is
evolutionary principle is that the IP-optical control and service that the IP-optical control and service interaction is first based on
interaction is first based on the domain services model with overlay the domain services model with overlay interconnection that will
interconnection that will eventually evolve to support full peer eventually evolve to support full peer interaction.
interaction.
11. References
Note: All references are informative: 11. Informative References
1. D. Awduche and Y. Rekhter, , "Multi-Protocol [1] Awduche, D. and Y. Rekhter, "Multi-Protocol Lambda Switching:
Lambda Switching: Combining MPLS Traffic Engineering Control With Combining MPLS Traffic Engineering Control With Optical
Optical Crossconnects," IEEE Communications Magazine, March 2001. Crossconnects", IEEE Communications Magazine, March 2001.
2. J. P. Lang, et. al., "Link Management Protocol," Internet Draft, [2] Lang, J., et al., "Link Management Protocol", Work in progress.
Work in progress.
3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE," [3] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE",
Internet Draft, Work in progress. Internet Draft, Work in progress.
4. L. Berger, et. al, "Generalized MPLS - Signaling Functional [4] Berger, L., Ed., "Generalized Multi-Protocol Label Switching
Description", RFC 3471. (GMPLS) Signaling Functional Description", RFC 3471, January
2003.
5. B. Rajagopalan, "Documentation of IANA Assignments for LDP, RSVP
and RSVP-TE Extensions for Optical UNI Signaling," RFC 3476.
6. The Optical Interworking Forum, "UNI 1.0 Signaling
Specification," December, 2001.
7. K. Kompella et al, "OSPF Extensions in Support of Generalized [5] Rajagopalan, B., "Documentation of IANA Assignments for Label
MPLS," Internet Draft, Work in Progress. Distribution Protocol (LDP), Resource ReSeVation Protocol
(RSVP), and Resource ReSeVation Protocol-Traffic Engineering
(RSVP-TE) Extensions for Optical UNI Signaling", RFC 3476,
March 2003.
8. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC [6] The Optical Interworking Forum, "UNI 1.0 Signaling
1771, March, 1995. Specification", December 2001.
9. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999. [7] Kompella, K., et al., "OSPF Extensions in Support of
Generalized MPLS," Work in Progress.
10. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling [8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP4)",
Functional Description," RFC 3472. RFC 1771, March 1995.
11. L. Berger, et. al., "Generalized MPLS - RSVP-TE Signaling [9] Berger, L., Ed., "Generalized Multi-Protocol Label Switching
Functional Description", RFC 3473. (GMPLS) Signaling Resource ReSeVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
12. E. Mannie, et. al., "GMPLS Extensions for SONET/SDH Control," [10] Mannie, E., "GMPLS Extensions for SONET/SDH Control", Work in
Internet Draft, Work in Progress. Progress.
13. B. Doshi, S. Dravida, P. Harshavardhana, et. al, "Optical [11] Doshi, B., Dravida, S., Harshavardhana, P., et. al, "Optical
Network Design and Restoration," Bell Labs Technical Journal, Network Design and Restoration," Bell Labs Technical Journal,
Jan-March, 1999. Jan-March, 1999.
14. K. Kompella, et al., "Link Bundling in MPLS Traffic [12] Kompella, K., et al., "Link Bundling in MPLS Traffic
Engineering," Internet Draft, Work in Progress. Engineering", Work in Progress.
15. S. Ramamurthy, Z. Bogdanowicz, S. Samieian, et al., "Capacity [13] Ramamurthy, S., Bogdanowicz, Z., Samieian, S., et al.,
Performance of Dynamic Provisioning in Optical Networks", J. of "Capacity Performance of Dynamic Provisioning in Optical
Lightwave Technology, January, 2001. Networks", Journal of Lightwave Technology, January 2001.
16. E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, "A [14] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A
Framework for QoS-based Routing in the Internet," RFC 2386, Framework for QoS-based Routing in the Internet", RFC 2386,
August, 1998. August 1998.
17. D. Awduche, L. Berger, Der-Hwa Gan, T. Li, G. Swallow, V. [15] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V.
Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209. 3209, December 2001.
18. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4, [16] Suurballe, J., "Disjoint Paths in a Network", Networks, vol. 4,
1974. 1974.
19. A. Chiu et al., "Impairments and Other Constraints On Optical [17] Chiu, A., et al., "Impairments and Other Constraints On Optical
Layer Routing", Internet Draft, Work in Progress. Layer Routing", Work in Progress.
12. Acknowledgments 12. Acknowledgments
We would like to thank Zouheir Mansourati (Movaz Networks), Ian We would like to thank Zouheir Mansourati (Movaz Networks), Ian
Duncan (Nortel Networks), Dimitri Papadimitriou (Alcatel), and Duncan (Nortel Networks), Dimitri Papadimitriou (Alcatel), and
Dimitrios Pendarakis (Tellium) for their contributions to this Dimitrios Pendarakis (Tellium) for their contributions to this
document. The Security Considerations section was revised to reflect document. The Security Considerations section was revised to reflect
input from Scott Bradner and Steve Bellovin. input from Scott Bradner and Steve Bellovin.
13. Contributors 13. Contributors
Contributors are listed alphabetically. Contributors are listed alphabetically.
Daniel O. Awduche
MCI
22001 Loudoun County Parkway
Ashburn, VA 20147
Phone: 703-886-1753
Email: awduche@awduche.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
Bilel Jamoussi Bilel Jamoussi
Nortel Networks Nortel Networks
600 Tech Park 600 Tech Park
Billerica, MA 01821 Billerica, MA 01821
Phone: 978-288-4734 Phone: 978-288-4734
Email: jamoussi@nortelnetworks.com EMail: jamoussi@nortelnetworks.com
James V. Luciani Debanjan Saha
Independent Consultant
PO Box 1010 EMail: debanjan@acm.org
Concord, MA 01742
Email: james_luciani@mindspring.com 14. Authors' Addresses
Bala Rajagopalan Bala Rajagopalan
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Email: braja@tellium.com
Debanjan Saha EMail: braja@tellium.com
Email: debanjan@acm.org
James V. Luciani
Marconi Communications
2000 Marconi Dr.
Warrendale, PA 15086
EMail: james_luciani@mindspring.com
Daniel O. Awduche
MCI
22001 Loudoun County Parkway
Ashburn, VA 20147
Phone: 703-886-1753
EMail: awduche@awduche.com
15. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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