draft-ietf-ipo-framework-04.txt   draft-ietf-ipo-framework-05.txt 
Bala Rajagopalan Bala Rajagopalan
Internet Draft Tellium, Inc. Internet Draft Tellium, Inc.
draft-ietf-ipo-framework-04.txt James Luciani draft-ietf-ipo-framework-05.txt James Luciani
Expires on: 10/8/2003 Crescent Networks Expires on: 3/13/2004 Crescent Networks
Daniel Awduche Daniel O. Awduche
Isocore MCI
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 document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 44 skipping to change at line 44
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").
draft-ietf-ipo-framework-04.txt
Table of Contents Table of Contents
----------------- -----------------
Abstract..............................................................1 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.............................................10 3.2 Control Structure..............................................10
4. IP over Optical Service Models and Requirements...................12 4. IP over Optical Service Models and Requirements...................12
4.1 Domain Services Model.........................................12 4.1 Domain Services Model..........................................12
4.2 Unified Service Model.........................................13 4.2 Unified Service Model..........................................13
4.3 Which Service Model?..........................................14 4.3 Which Service Model?...........................................14
4.4 What are the Possible Services?................................14 4.4 What are the Possible Services?.................................14
5. IP transport over Optical Networks................................15 5. IP transport over Optical Networks................................15
5.1 Interconnection Models.........................................15 5.1 Interconnection Models..........................................15
5.2 Routing Approaches.............................................16 5.2 Routing Approaches..............................................16
5.3 Signaling-Related..............................................19 5.3 Signaling-Related...............................................19
5.4 End-to-End Protection Models..................................21 5.4 End-to-End Protection Models...................................21
6. IP-based Optical Control Plane Issues.............................23 6. IP-based Optical Control Plane Issues.............................23
6.1 Addressing....................................................23 6.1 Addressing.....................................................23
6.2 Neighbor Discovery............................................24 6.2 Neighbor Discovery.............................................24
6.3 Topology Discovery............................................25 6.3 Topology Discovery.............................................26
6.4 Restoration Models............................................26 6.4 Protection and Restoration Models..............................26
6.5 Route Computation.............................................27 6.5 Route Computation..............................................27
6.6 Signaling Issues..............................................29 6.6 Signaling Issues...............................................29
6.7 Optical Internetworking.......................................31 6.7 Optical Internetworking........................................31
7. Other Issues......................................................32 7. Other Issues......................................................32
7.1 WDM and TDM in the Same Network..............................32 7.1 WDM and TDM in the Same Network...............................32
7.2 Wavelength Conversion........................................32 7.2 Wavelength Conversion.........................................33
7.3 Service Provider Peering Points..............................33 7.3 Service Provider Peering Points...............................33
7.4 Rate of Lightpath Set-Up.....................................33 7.4 Rate of Lightpath Set-Up......................................33
7.5 Distributed vs. Centralized Provisioning.....................34 7.5 Distributed vs. Centralized Provisioning......................34
7.6 Optical Networks with Additional Configurable Components.....35 7.6 Optical Networks with Additional Configurable Components......35
7.7 Optical Networks with Limited Wavelength Conversion Capability35 7.7 Optical Networks with Limited Wavelength Conversion Capability35
8. Evolution Path for IP over Optical Architecture..................36 8. Evolution Path for IP over Optical Architecture..................36
9. Security Considerations...........................................37 9. Security Considerations...........................................38
9.1 General Security Aspects.......................................38 9.1 General Security Aspects........................................39
9.2 Security Considerations for Protocol Mechanisms................39 9.2 Security Considerations for Protocol Mechanisms.................40
10. Summary and Conclusions..........................................40 10. Summary and Conclusions..........................................40
11. References.......................................................40 11. References.......................................................40
12. Acknowledgments..................................................41 12. Acknowledgments..................................................41
13. Contributors.....................................................42 13. Contributors.....................................................42
draft-ietf-ipo-framework-04.txt
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 this regard, the term "optical network" is used generically in In this regard, the term "optical network" is used generically in
practice to refer to both SONET/SDH-based transport networks, as practice to refer to both SONET/SDH-based transport networks, as
well as transparent all-optical networks. well as 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
skipping to change at line 143 skipping to change at line 141
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-
draft-ietf-ipo-framework-04.txt
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 interfaces. This document therefore advocates the definition these interfaces. This document therefore advocates the definition
of "capability sets" that define the evolution of functionality at of "capability sets" that define the evolution of functionality at
the interfaces as more sophisticated operational requirements arise. the interfaces as more sophisticated operational requirements arise.
skipping to change at line 196 skipping to change at line 192
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,
draft-ietf-ipo-framework-04.txt
Ethernet, ATM, etc.) For example, there are many commercial WDM Ethernet, ATM, etc.) For example, there are many commercial WDM
networks in existence today that support a mix of SONET signals networks in existence today that support a mix of SONET signals
operating at OC-48c (approximately 2.5 Gbps) and OC-192 operating at OC-48c (approximately 2.5 Gbps) and OC-192
(approximately 10 Gbps) over a single optical fiber. An optical (approximately 10 Gbps) over a single optical fiber. An optical
system with WDM capability can achieve parallel transmission of system with WDM capability can achieve parallel transmission of
multiple wavelengths gracefully while maintaining high system multiple wavelengths gracefully while maintaining high system
performance and reliability. In the near future, commercial 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 both WDM and DWDM (Dense WDM). to 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 of nodes through which the signal passes before 5. The number and type of nodes through which the signals pass
it reaches the egress node or before regeneration. before 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
skipping to change at line 251 skipping to change at line 245
An optical channel trail is a point-to-point optical layer An optical channel trail is a point-to-point optical layer
connection between two access points in an optical network. In this connection between two access points in an optical network. In this
document, the term "lightpath" is used interchangeably with optical document, the term "lightpath" is used interchangeably with optical
channel trail. channel trail.
Optical mesh sub-network Optical mesh sub-network
------------------------ ------------------------
An optical sub-network, as 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
draft-ietf-ipo-framework-04.txt
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 following sub-layers may be associated with this network: The 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.
skipping to change at line 305 skipping to change at line 297
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.
draft-ietf-ipo-framework-04.txt
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 traverse from transmitter to receiver across intermediate signals are transported from transmitter to receiver entirely in the
nodes in the optical domain without OEO conversion. More generally, optical domain without OEO conversion. Generally, intermediate
all intermediate nodes in a transparent optical network will switching nodes in a transparent optical network do not have access
transfer optical signals without performing retiming and reshaping to the payload carried by the optical signals.
and thus such nodes are unaware of the characteristics of 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 transparent optical networks (e.g. using Erbium Doped permitted in transparent optical networks (e.g. using Erbium Doped
Fiber Amplifiers EDFAs). Fiber 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, most nodes in unauthorized intrusion from outside the domain. Hence, it may be
the domain are deemed to be secure or trusted in some fashion. assumed that most nodes in the domain are deemed to be secure or
Generally, the rule for "single" administrative control over a trust trusted in some fashion. Generally, the rule for "single"
domain may be relaxed in practice if a set of administrative administrative control over a trust domain may be relaxed in
entities agree to trust one another to form an enlarged practice if a set of administrative entities agree to trust one
heterogeneous trust domain. However, to simplify the discussions in another to form an enlarged heterogeneous trust domain. However, to
this document, it will be assumed, without loss of generality, that simplify the discussions in this document, it will be assumed,
the term trust domain applies to a single administrative entity with without loss of generality, that the term trust domain applies to a
appropriate security policies. It should be noted that within a single administrative entity with appropriate security policies. It
trust domain, any subverted node can send control messages which can should be noted that within a trust domain, any subverted node can
compromise the entire network. send control messages which can compromise the entire network.
Flow Flow
---- ----
For purposes of this document, the term flow will be used to In this document, the term flow will be used to signify the smallest
signify the smallest non-separable stream of data, from the point of non-separable stream of data, from the point of view of an endpoint
view of an endpoint or termination point (source or destination or termination point (source or destination node). The reader
node). The reader should note that the term flow is heavily should note that the term flow is heavily overloaded in contemporary
overloaded in contemporary networking literature. Therefore, within networking literature. In this document, we will consider a
the context of this document, it may be convenient to consider a wavelength to be a flow, under certain circumstances. However, if
wavelength as a flow under certain circumstances. However, if there there is a method to partition the bandwidth of the wavelength, then
is a method to partition the bandwidth of the wavelength, then each each partition may be considered a flow, for example using time
partition may be considered a flow, for example using time division division multiplexing (TDM), it may be feasible to consider each
multiplexing (TDM) to quantize time into time slots, it may be quanta of time within a given wavelength as a flow.
feasible to consider each quanta of time within a given wavelength
as a flow.
draft-ietf-ipo-framework-04.txt
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 path between two access points which allows some same path between two access points which allows some
characteristics and attributes of the traffic to be parameterized. characteristics and attributes of the traffic to be parameterized.
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
skipping to change at line 381 skipping to change at line 364
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 possibly be administered by a different networks, each of which may be administered by a different entity.
entity. Each optical network consists of sub-networks interconnected Each optical network consists of sub-networks interconnected by
by optical fiber links in a general topology (referred to as an optical fiber links in a general topology (referred to as an optical
optical mesh network). This network may contain re-configurable mesh network). This network may contain re-configurable optical
optical equipment from a single vendor or from multiple vendors. In equipment from a single vendor or from multiple vendors. In the near
the near term, it may be expected that each sub-network will consist term, it may be expected that each sub-network will consist of
of switches from a single vendor. In the future, as standardization switches from a single vendor. In the future, as standardization
efforts mature, each optical sub-network may in fact contain optical efforts mature, each optical sub-network may in fact contain optical
switches from different vendors. In any case, each sub-network switches from different vendors. In any case, each sub-network
itself is assumed to be mesh-connected internally. In general, it itself is assumed to be mesh-connected internally. In general, it
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 shown in Figure 1, other client networks (e.g., ATM) may also As shown in Figure 1, other client networks (e.g., ATM) may also
connect to the optical network. connect to the optical network.
The switching function in an OXC is controlled by appropriately The switching function in an OXC is controlled by appropriately
configuring the cross-connect fabric. Conceptually, this may be configuring the cross-connect fabric. Conceptually, this may be
viewed as setting up a cross-connect table whose entries are of the viewed as setting up a cross-connect table whose entries are of the
form <input port i, output port j>, indicating that the data stream form <input port i, output port j>, indicating that the data stream
entering input port i will be switched to output port j. In the entering input port i will be switched to output port j. In the
context of a wavelength selective cross-connect (generally referred context of a wavelength selective cross-connect (generally referred
to as a WXC), the cross-connect tables may also indicate the input to as a WXC), the cross-connect tables may also indicate the input
and output wavelengths along with the input and output ports. A and output wavelengths along with the input and output ports. A
lightpath from an ingress port in an OXC to an egress port in a lightpath from an ingress port in an OXC to an egress port in a
remote OXC is established by setting up suitable cross-connects in remote OXC is established by setting up suitable cross-connects in
draft-ietf-ipo-framework-04.txt
the ingress, the egress and a set of intermediate OXCs such that a the ingress, the egress and a set of intermediate OXCs such that a
continuous physical path exists from the ingress to the egress port. continuous physical path exists from the ingress to the egress port.
Optical paths tend to be bi-directional, i.e., the return path from Optical paths tend to be bi-directional, i.e., the return path from
the egress port to the ingress port is typically routed along the the egress port to the ingress port is typically routed along the
same set of intermediate ports as the forward path, but this may not same set of intermediate interface cards as the forward path, but
be the case under all circumstances. this may not be the case under all circumstances.
Optical Network Optical Network
+----------------------------------------+ +---------------------------------------+
| | | |
| Optical Subnetwork | | Optical Subnetwork |
+--------------+ | +------------------------------------+ | +---------+ | +-----------------------------------+ |
| | | | +-----+ +-----+ +-----+ | | | | | | +-----+ +-----+ +-----+ | |
| IP | | | | | | | | | | | | IP | | | | | | | | | | |
| Network +--UNI--+--+ OXC +------+ OXC +------+ OXC + | | | Network +-UNI --+-+ OXC +------+ OXC +------+ OXC + | |
| | | | | | | | | | | | | | | | | | | | | | | |
+--------------+ | | +--+--+ +--+--+ +--+--+ | | +---------+ | | +--+--+ +--+--+ +--+--+ | |
| +-----|------------|------------|----+ | | +----|------------|------------|----+ |
| | | | | | INNI INNI INNI | +--------------+ | | | | | | | | +-----+------+ | +-------+----+ | | IP +--UNI--| +-----+ | | | | | | | |
| INNI INNI INNI |
+---------+ | | | | |
| | | +----+------+ | +-------+----+ |
| IP + UNI- | | +-----+ | | |
| Network | | | Optical | | Optical | | | Network | | | Optical | | Optical | |
| | | | Subnetwork +---INNI---+ Subnetwork | | | | | | Subnetwork +---INNI---+ Subnetwork | |
+--------------+ | | | | | | +---------+ | | | | | |
| +------+-----+ +------+-----+ | | +-----+-----+ +------+-----+ |
| | | | | | | |
+--------+-----------------------+-------+ +-------+-----------------------+-------+
| | | |
ENNI ENNI ENNI ENNI
| | | |
+--------+-----------------------+-------+ +-------+-----------------------+-------+
| | | |
| Optical Network | | Optical Network |
| | | |
+--------+-----------------------+-------+ | | +-------+-----------------------+-------+
| |
UNI UNI UNI UNI
| | | |
+------+-------+ +------+-----+ +-----+----- --+ +-----+------+
| | | | | | | |
| Other Client | |Other Client| | Other Client | |Other Client|
| Network | | Network | | Network | | Network |
| (e.g., ATM) | | | | (e.g., ATM) | | |
+--------------+ +------------+ +- ------------+ +------------+
Figure 1: Optical Internetwork Model Figure 1: Optical Internetwork Model
Multiple data streams output from an OXC may be multiplexed onto an Multiple traffic streams exiting from an OXC may be multiplexed onto
optical link using WDM technology. The WDM functionality may exist a fiber optic link using WDM technology. The WDM functionality may
outside of the OXC, and be transparent to the OXC. Or, this function exist outside of the OXC, and be transparent to the OXC. Or, this
may be built into the OXC. In the later case, the cross-connect function may be built into the OXC. In the later case, the cross-
draft-ietf-ipo-framework-04.txt connect table (conceptually) consists of pairs of the form,
<{input port i, Lambda(j)}, {output port k, Lambda(l)}>. This
table (conceptually) consists of pairs of the form, <{input port indicates that the data stream received on wavelength Lambda(j) over
i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that the input port i is switched to output port k on Lambda(l). Automated
data stream received on wavelength Lambda(j) over input port i is establishment of lightpaths involves setting up the cross-connect
switched to output port k on Lambda(l). Automated establishment of table entries in the appropriate OXCs in a coordinated manner such
lightpaths involves setting up the cross-connect table entries in that the desired physical path is realized.
the appropriate OXCs in a coordinated manner such that the desired
physical path is realized.
Under this network model, a switched lightpath must be established Under this network model, a switched lightpath must be established
between a pair of IP routers before they can communicate. This between a pair of IP routers before the routers can transfer user
lightpath might traverse multiple optical networks and be subject to traffic among themselves. A lightpath between IP routers may
different provisioning and restoration procedures in each traverse multiple optical networks and be subject to different
network. provisioning and restoration procedures in each network.
The IP-based control plane issue is that of designing The IP-based control plane issue for optical networks pertains to
standard signaling and routing protocols for provisioning and the design of standard signaling and routing protocols for
restoration of lightpaths across multiple optical provisioning and restoration of lightpaths across multiple optical
networks. Similarly, IP transport over such an optical network networks. Similarly, IP transport over optical networks
involves determining IP reachability and seamlessly establishing involves establishing IP reachability and seamlessly constructing
paths from one IP endpoint to another over an optical network. forwarding paths from one IP endpoint to another over an optical
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.
skipping to change at line 511 skipping to change at line 496
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 the manner in which the services may be accessed. The service and the manner in which the services may be accessed. The service
models are described in Section 4. The NNIs represent vendor- models are described in Section 4. The NNIs represent vendor-
independent standardized control flow between nodes. The distinction independent standardized interfaces for control flow between nodes.
between the INNI and the ENNI is that the former is an interface The distinction between the INNI and the ENNI is that the former is
within a given network under a single technical administration, an interface within a given network under a single technical
while the later indicates an interface at the administrative administration, while the later indicates an interface at the
boundary between networks. The INNI and ENNI may thus differ in the administrative boundary between networks. The INNI and ENNI may thus
policies that restrict control flow between nodes. differ in the policies that restrict control flow between nodes.
draft-ietf-ipo-framework-04.txt
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
the ENNI. In this case, UNI and NNIs may look different in some the ENNI. In this case, UNI and NNIs may look different in some
respects. In this document, these interfaces are treated as respects. In this document, these interfaces are treated as
distinct. distinct.
skipping to change at line 546 skipping to change at line 529
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 over-
lay, Section 5) may occur across private and public logical 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 to which it is connected. This control channel is used for (IPCC) may be implemented between an edge router and each OXC
to 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 573 skipping to change at line 557
implemented between the client and a device in the optical network implemented between the client and a device in the optical network
to signal service requests and responses. For instance, a to signal service requests and responses. For instance, a
management system or a server in the optical network may receive management system or a server in the optical network may receive
service requests from clients. Similarly, out-of-band signaling service requests from clients. Similarly, out-of-band signaling
may be used between management systems in client and optical may be used between management systems in client and optical
networks to signal service requests. In these cases, there is no networks to signal service requests. In these cases, there is no
direct control interaction between clients and respective direct control interaction between clients and respective
OXCs. One reason to have an indirect interface would be that the OXCs. One reason to have an indirect interface would be that the
OXCs and/or clients do not support a direct signaling interface. OXCs and/or clients do not support a direct signaling interface.
draft-ietf-ipo-framework-04.txt +---------------------------+ +---------------------------+
+-----------------------------+ +-----------------------------+
| | | | | | | |
| +---------+ +---------+ | | +---------+ +---------+ | | +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | | | | | | | | | | | | | | | | | |
| | Routing | |Signaling| | | | Routing | |Signaling| | | | Routing | |Signaling| | | | Routing | |Signaling| |
| | Protocol| |Protocol | | | | Protocol| |Protocol | | | | Protocol| |Protocol | | | | Protocol| |Protocol | |
| | | | | | | | | | | | | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| +--+-----------+---+ | | +--+-----------+---+ | | +--+-----------+---+ | | +--+-----------+---+ |
| | | | | | | | | | | | | | | |
| | IP Layer +......IPCC.......+ IP Layer | | | | IP Layer +....IPCC.....+ IP Layer | |
| | | | | | | | | | | | | | | |
| +------------------+ | | +------------------+ | | +------------------+ | | +------------------+ |
| | | | | | | |
| Edge Router | | OXC | | Edge Router | | OXC |
+-----------------------------+ +-----------------------------+ +---------------------------+ +---------------------------+
Figure 2: Direct Interface Figure 2: Direct Interface
3. Provisioned interface: In this case, the optical network services 3. Provisioned interface: In this case, the optical network services
are manually provisioned and there is no control interactions are manually provisioned and there is no control interactions
between the client and the optical network. between the client and the optical network.
Although different control structures are possible, further Although different control structures are possible, further
descriptions in this framework assume direct interfaces for IP- descriptions in this framework assume direct interfaces for IP-
optical and optical sub-network control interactions. optical and optical sub-network control interactions.
skipping to change at line 624 skipping to change at line 606
offers high bandwidth connectivity in the form of lightpaths. offers high bandwidth connectivity in the form of lightpaths.
Standardized signaling across the UNI (Figure 1) is used to invoke Standardized signaling across the UNI (Figure 1) is used to invoke
the following services: the following services:
1. Lightpath creation: This service allows a lightpath with the 1. Lightpath creation: This service allows a lightpath with the
specified attributes to be created between a pair of termination specified attributes to be created between a pair of termination
points in the optical network. Lightpath creation may be subject points in the optical network. Lightpath creation may be subject
to network-defined policies (e.g., connectivity restrictions) and to network-defined policies (e.g., connectivity restrictions) and
security procedures. security procedures.
draft-ietf-ipo-framework-04.txt
2. Lightpath deletion: This service allows an existing lightpath to 2. Lightpath deletion: This service allows an existing lightpath to
be deleted. be deleted.
3. Lightpath modification: This service allows certain parameters of 3. Lightpath modification: This service allows certain parameters of
the lightpath to be modified. the lightpath to be modified.
4. Lightpath status enquiry: This service allows the status of 4. Lightpath status enquiry: This service allows the status of
certain parameters of the lightpath (referenced by its ID) to be certain parameters of the lightpath (referenced by its ID) to be
queried by the router that created the lightpath. queried by the router that created the lightpath.
skipping to change at line 678 skipping to change at line 658
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 may not be practically attractive or even feasible in capabilities may not be practically attractive or even feasible in
this case (see Section 5). this case (see Section 5).
draft-ietf-ipo-framework-04.txt
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 the domain services model. These services, however, may be to the domain services model. These services, however, may be
invoked in a more seamless manner as compared to the domain services invoked in a more seamless manner as compared to the domain services
model. For instance, when routers are attached to a single optical model. For instance, when routers are attached to a single optical
network (i.e., there are no ENNIs), a remote router could compute an network (i.e., there are no ENNIs), a remote router could compute an
skipping to change at line 733 skipping to change at line 711
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 of lightpaths that interconnect routers (or any other set of network of lightpaths that interconnect routers (or any other set of
draft-ietf-ipo-framework-04.txt
clients) belonging to a single entity or a group of related entities clients) belonging to a single entity or a group of related entities
across a public optical network. Indeed, in the case where the across a public optical network. Indeed, in the case where the
optical network provides connectivity for multiple sets of external optical network provides connectivity for multiple sets of external
client networks, there has to be a way to enforce routing policies client networks, there has to be a way to enforce routing policies
that ensure routing separation between different sets of client that ensure routing separation between different sets of client
networks (i.e., VPN service). networks (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
skipping to change at line 787 skipping to change at line 763
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 as OSPF or IS-IS, with appropriate extensions, can be used to such as OSPF or IS-IS, with appropriate extensions, can be used to
draft-ietf-ipo-framework-04.txt
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 instance of an intra-domain routing protocol is not single instance of an intra-domain routing protocol is not
attractive or even realistic. In this case, inter-domain routing and attractive or even realistic. In this case, inter-domain routing and
signaling protocols are needed. In either case, a tacit assumption signaling protocols are needed. In either case, a tacit assumption
is that a common addressing scheme will be used for the optical and is that a common addressing scheme will be used for the optical and
IP networks. A common address space can be trivially realized by IP networks. A common address space can be trivially realized by
using IP addresses in both IP and optical domains. Thus, the optical using 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 routing, topology distribution, and Under the overlay model, the IP layer routing, topology
signaling protocols are independent of the routing, topology distribution, and signaling protocols are independent of the
distribution, and signaling protocols within the optical domain. routing, topology distribution, and signaling protocols within the
This model is conceptually similar to the classical IP over ATM or optical domain. This model is conceptually similar to the classical
MPOA models, but applied to an optical internetwork instead. In the IP over ATM or MPOA models, but applied to an optical internetwork
overlay model, topology distribution, path computation and signaling instead. In the overlay model, a separate instance of the control
protocols would have to be defined for the optical domain, plane (especially the routing and signaling protocols) would have to
independently of what exists in the IP domain. In certain be deployed in the optical domain, independent of what exists in the
circumstances, it may also be feasible to statically configure the IP domain. In certain circumstances, it may also be feasible to
optical channels that provide connectivity in the overlay model statically configure the optical channels that provide connectivity
through network management functions. Static configuration is, for the IP domain in the overlay model. Static configuration can be
however, unlikely to scale in very large networks, and will not effected through network management functions. Static configuration,
support the rapid connection provisioning required in existing and however, is unlikely to scale in very large networks, and may not
future competitive networking environments. support the rapid connection provisioning requirements of future
highly 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 routing instance can be passed through to the other routing one routing instance can be passed through to the other routing
instance. For example, external IP addresses could be carried within instance. For example, external IP addresses could be carried within
the optical routing protocols to allow reachability information to the optical routing protocols to allow reachability information to
be passed to IP clients. be passed to IP clients.
skipping to change at line 842 skipping to change at line 817
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
draft-ietf-ipo-framework-04.txt
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 with appropriate extensions. In this case, the signaling LDP with appropriate extensions. In this case, the signaling
protocol will establish a lightpath between two edge routers. This protocol will establish a lightpath between two edge routers. This
skipping to change at line 896 skipping to change at line 869
link state representation, replacing the links previously advertised link state representation, replacing the links previously advertised
at the IP-Optical interface. Finally, the details of the optical at the IP-Optical interface. Finally, the details of the optical
network captured in the link state representation is replaced by a network captured in the link state representation is replaced by a
network of FAs. 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
draft-ietf-ipo-framework-04.txt
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 the routers to advertise IP address prefixes within would allow routers to advertise IP address prefixes within their
their network to the optical internetwork and to receive external network to the optical internetwork and to receive external IP
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 used between border OXCs within the same network, and EBGP (IBGP) is may be used between border optical switches, and EBGP may
is used between networks (over ENNI, Figure 1). be used between different networks (over ENNI, Figure 1).
Under this scheme, it is necessary to identify the egress points in Under this scheme, it may be necessary to identify the egress points
the optical internetwork corresponding to externally reachable IP in the optical internetwork corresponding to externally reachable IP
addresses. This is due to the following. Suppose an edge router addresses. To see this, suppose an edge router intends to establish
desires to establish an LSP to a destination reachable across the an LSP to a destination node across the optical internetwork. It may
optical internetwork. It could directly request a lightpath to that request a direct lightpath to that destination, without explicitly
destination, without explicitly specifying the egress optical port specifying the egress optical port for the lightpath because the
for the lightpath as the optical internetwork has knowledge of optical internetwork has knowledge of externally reachable IP
externally reachable IP addresses. However, if the same edge router addresses. However, if the same edge router were to establish
has to establish another LSP to a different external destination, it another LSP to a different external destination, then for efficiency
must first determine whether there is a lightpath already available reasons, it may first need to determine whether there is an existing
(with sufficient residual capacity) that leads to that destination. lightpath (with sufficient residual capacity) to the target
To identify this, it is necessary for edge routers to keep track of destination. For this purpose, it may be necessary for edge routers
which egress ports in the optical internetwork lead to which to keep track of which egress ports in the optical internetwork lead
external destinations. Thus, a border OXC receiving external IP to which external destinations. Thus, a border OXC receiving
prefixes from an edge router through EBGP must include its own IP external IP prefixes from an edge router through EBGP must include
address as the egress point before propagating these prefixes to its own IP address as the egress point before propagating these
other border OXCs or edge routers. An edge router receiving this prefixes to other border OXCs or edge routers. An edge router
information need not propagate the egress address further, but it receiving this information need not propagate the egress address
must keep the association between external IP addresses and egress further, but it must keep the association between external IP
OXC addresses. Specific BGP mechanisms for propagating egress OXC addresses and egress OXC addresses. When optical VPNs are
addresses are to be determined, considering prior examples implemented, the address prefixes advertised by the border OXCs may
described in [9]. When VPNs are implemented, the address prefixes be accompanied by some VPN specific identification.
advertised by the border OXCs may be accompanied by some VPN
identification (for example, VPN IPv4 addresses, as defined in [9], There are however, some potential negative effects that could result
may be used). from domain-specific routing using BGP in an IPO environment:
o The amount of information that optical nodes will have to
maintain will not be bound by the size of the optical network
anymore, but will have to include external routes as well.
o The stability of the optical network control plane will
no longer be dictated solely by the dynamics emanating
within the optical network, but may be affected by the
dynamics originating from external routing domains
from which external reachability information is received.
5.2.3 Overlay Routing 5.2.3 Overlay Routing
draft-ietf-ipo-framework-04.txt
The overlay routing approach supports the overlay interconnection The overlay routing approach supports the overlay interconnection
model.Under this approach, an overlay mechanism that allows edge model.Under this approach, an overlay mechanism that allows edge
routers toregister and query for external addresses is implemented. routers toregister and query for external addresses is implemented.
This is conceptually similar to the address resolution mechanism This is conceptually similar to the address resolution mechanism
used for IP over ATM. Under this approach, the optical network could used for IP over ATM. Under this approach, the optical network could
implement a registry that allows edge routers to register IP implement a registry that allows edge routers to register IP
addresses and VPN identifiers. An edge router may be allowed to addresses and VPN identifiers. An edge router may be allowed to
query for external addresses belonging to the same set of VPNs it query for external addresses belonging to the same set of VPNs it
belongs to. A successful query would return the address of the belongs to. A successful query would return the address of the
egress optical port through which the external destination can be egress optical port through which the external destination can be
reached. reached.
Because IP-optical interface connectivity is limited, the Because IP-optical interface connectivity is limited, the
determination of how many lightpaths must be established and to what determination of how many lightpaths must be established and to what
endpoints are traffic engineering decisions. Furthermore, after an endpoints are traffic engineering decisions. Furthermore, after an
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, OSPF. With this approach, an edge router could first determine other adjacencies within VPNs for a VPN-wide routing scheme, for example,
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 and CR-LDP can be used for signaling extensions, such as RSVP-TE, can be appropriately extended and used
lightpath requests. In the case of the domain services model, these for signaling lightpath requests. These protocols can be adapted for
protocols can be adapted for UNI signaling as well [5, 6]. In the client/server signaling in the case of the domain services model,
case of the unified services model, lightpath establishment occurs and for end-to-end integrated signaling in the case of the unified
to support end-to-end LSP establishment using these protocols (with services model.
suitable GMPLS enhancements [10, 11]).
5.3.2 Signaling Models 5.3.2 Signaling Models
With the domain-services model, the signaling control plane in the With the domain-services model, the signaling control plane in the
IP and optical network are completely separate as shown in Figure 3 IP and optical network are completely separate as shown in Figure 3
below. This separation also implies the separation of IP and optical below. This separation also implies the separation of IP and optical
address spaces (even though the optical network would be using address spaces (even though the optical network would be using
internal IP addressing). While RSVP-TE and LDP can be adapted for internal IP addressing). While RSVP-TE and LDP can be adapted for
UNI signaling, the full functionality of these protocols will not be UNI signaling, the full functionality of these protocols will not be
used. For example, UNI signaling does not require the specification used. For example, UNI signaling does not require the specification
of explicit routes. On the other hand, based on the service of explicit routes. On the other hand, based on the service
attributes, new objects need to be signaled using these protocols as attributes, new objects need to be signaled using these protocols as
described in [5, 6]. described in [5, 6].
skipping to change at line 1003 skipping to change at line 982
IP and optical network are completely separate as shown in Figure 3 IP and optical network are completely separate as shown in Figure 3
below. This separation also implies the separation of IP and optical below. This separation also implies the separation of IP and optical
address spaces (even though the optical network would be using address spaces (even though the optical network would be using
internal IP addressing). While RSVP-TE and LDP can be adapted for internal IP addressing). While RSVP-TE and LDP can be adapted for
UNI signaling, the full functionality of these protocols will not be UNI signaling, the full functionality of these protocols will not be
used. For example, UNI signaling does not require the specification used. For example, UNI signaling does not require the specification
of explicit routes. On the other hand, based on the service of explicit routes. On the other hand, based on the service
attributes, new objects need to be signaled using these protocols as attributes, new objects need to be signaled using these protocols as
described in [5, 6]. described in [5, 6].
draft-ietf-ipo-framework-04.txt
MPLS Signaling UNI Signaling MPLS or other signaling MPLS Signaling UNI Signaling MPLS or other signaling
| |
+-----------------------------+ | +-----------------------------+ +-----------------------------+ | +-----------------------------+
| IP Network | | | Optical Internetwork | | IP Network | | | Optical Internetwork |
| +---------+ +---------+ | | | +---------+ +---------+ | | +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | Router +---+ Router +-----+------+ OXC +---+ OXC | | | | Router +---+ Router +-----+------+ OXC +---+ OXC | |
| | | | | | | | | | | | | | | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ |
+-----------------------------+ | +-----------------------------+ +-----------------------------+ | +-----------------------------+
skipping to change at line 1052 skipping to change at line 1029
| | | |
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
draft-ietf-ipo-framework-04.txt
Figure 4: Unified Services Signaling Model Figure 4: Unified Services Signaling Model
Thus, as illustrated in Figure 4, the signaling in the case of Thus, as illustrated in Figure 4, the signaling in the case of
unified services is actually multi-layered. The layering is based on unified services is actually multi-layered. The layering is based on
the technology and functionality. As an example, the specific the technology and functionality. As an example, the specific
adaptations of GMPLS signaling for SONET layer (whose functionality adaptations of GMPLS signaling for SONET layer (whose functionality
is transport) are described in [12]. is transport) are described in [12].
5.4 End-to-End Protection Models 5.4 End-to-End Protection Models
skipping to change at line 1101 skipping to change at line 1077
this path be as shown in Figure 5, traversing router interface B this path be as shown in Figure 5, traversing router interface B
in the ingress network, optical ports C (ingress) and D (egress), in the ingress network, optical ports C (ingress) and D (egress),
and router interface E in the egress network. Next, 1+1 protection and router interface E in the egress network. Next, 1+1 protection
is realized separately in each network by establishing a protection is realized separately in each network by establishing a protection
path between points A and B, C and D and E and F. Furthermore, the path between points A and B, C and D and E and F. Furthermore, the
segments B-C and D-E must themselves be 1+1 protected, using drop- segments B-C and D-E must themselves be 1+1 protected, using drop-
side protection. For the segment between C and D, the optical side 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.
draft-ietf-ipo-framework-04.txt
+----------------+ +------------------+ +---------------+ +----------------+ +------------------+ +---------------+
| | | | | | | | | | | |
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
skipping to change at line 1152 skipping to change at line 1126
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 optical internetwork in the overlay mode. IP based recovery the optical internetwork in the overlay mode. IP based recovery
techniques may however be more resource efficient, as it may be techniques may however be more resource efficient, as it may be
possible to convey traffic through the redundant capacity under possible to convey traffic through the redundant capacity under
fault-free scenarios. In particular, it may be possible to utilize fault-free scenarios. In particular, it may be possible to utilize
classification, scheduling, and concepts of forwarding equivalence classification, scheduling, and concepts of forwarding equivalence
draft-ietf-ipo-framework-04.txt
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),
skipping to change at line 1182 skipping to change at line 1154
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, in the following, signaling and routing across sub-networks is Thus, 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, the fundamental issue is that of addressing. What control plane, one of the fundamental issues is that of addressing.
entities should be identifiable from a signaling and routing point What entities should be identifiable from a signaling and routing
of view? How should they be addressed? This section presents some point of view? How should they be addressed? This section presents
guidelines on this issue. some high level guidelines on this issue.
Identifiable entities in optical networks includes 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
should be as far as the establishment of optical trails are should be as far as the establishment of optical trails are
concerned. The scheme for identification must accommodate the concerned. The scheme for identification must accommodate the
specification of the termination points in the optical network with specification of the termination points in the optical network with
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 of resources requested). This suggests an identification granularity of resources requested). This suggests an identification
draft-ietf-ipo-framework-04.txt
scheme whereby OXCs are identified by a unique IP address and a scheme whereby OXCs are identified by a unique IP address and a
"selector" identifies further fine-grain information of relevance at "selector" identifies further fine-grain information of relevance at
an OXC. This, of course, does not preclude the identification of an OXC. This, of course, does not preclude the identification of
these termination points directly with IP addresses(with a null these termination points directly with IP addresses(with a null
selector). The selector can be formatted to have adequate number of selector). The selector can be formatted to have adequate number of
bits and a structure that expresses port, channel, sub-channel, etc, bits and a structure that expresses port, channel, sub-channel, etc,
identification. identification.
Within the optical network, the establishment of trail segments Within the optical network, the establishment of trail segments
between adjacent OXCs require the identification of specific port, between adjacent OXCs require the identification of specific port,
skipping to change at line 1249 skipping to change at line 1219
identified with a flat identifier (e.g., 32 bit integer). identified with a flat identifier (e.g., 32 bit integer).
Finally, optical links between adjacent OXCs may be bundled for Finally, optical links between adjacent OXCs may be bundled for
advertisement into a link state protocol [14]. A bundled interface advertisement into a link state protocol [14]. A bundled interface
may be numbered or unnumbered. In either case, the component links may be numbered or unnumbered. In either case, the component links
within the bundle must be identifiable. In concert with SRLG within the bundle must be identifiable. In concert with SRLG
identification, this information is necessary for correct path identification, this information is necessary for correct path
computation. computation.
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 links to all neighbors by each OXC. Specifically, each OXC local links to all neighbors by each OXC. Specifically, each OXC
must determine the up/down status of each optical link, the must determine the up/down status of each optical link, the
bandwidth and other parameters of the link, and the identity of the bandwidth and other parameters of the link, and the identity of the
remote end of the link (e.g., remote port number). The last piece of remote end of the link (e.g., remote port number). The last piece of
draft-ietf-ipo-framework-04.txt
information is used to specify an appropriate label when signaling information is used to specify an appropriate label when signaling
for lightpath provisioning. The determination of these parameters for lightpath provisioning. The determination of these parameters
could be based on a combination of manual configuration and an could be based on a combination of manual configuration and an
automated protocol running between adjacent OXCs. The automated protocol running between adjacent OXCs. The
characteristics of such a protocol would depend on the type of OXCs characteristics of such a protocol would depend on the type of OXCs
that are adjacent (e.g., transparent or opaque). that are adjacent (e.g., 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
skipping to change at line 1311 skipping to change at line 1278
Topology discovery is the procedure by which the topology and Topology discovery is the procedure by which the topology and
resource state of all the links in a network are determined. This resource state of all the links in a network are determined. This
procedure may be done as part of a link state routing protocol procedure may be done as part of a link state routing protocol
(e.g., OSPF, ISIS), or it can be done via the management plane (in (e.g., OSPF, ISIS), or it can be done via the management plane (in
the case of centralized path computation). The implementation of a the case of centralized path computation). The implementation of a
link state protocol within a network (i.e., across sub-network link state protocol within a network (i.e., across sub-network
boundaries) means that the same protocol runs in OXCs in every sub- boundaries) means that the same protocol runs in OXCs in every sub-
network. If this assumption does not hold then interworking of network. If this assumption does not hold then interworking of
routing between sub-networks is required. This is similar to inter- routing between sub-networks is required. This is similar to inter-
draft-ietf-ipo-framework-04.txt
network routing discussed in Section 6.7. The focus in the following network routing discussed in Section 6.7. The focus in the following
is therefore on standardized link state routing. is therefore on 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 changed in this setting. Specifically, are 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 [14].
Each link bundle is represented as an abstract link in the network Each link bundle is represented as an abstract link in the network
skipping to change at line 1351 skipping to change at line 1316
availability thresholds may be implemented. For instance, changes availability thresholds may be implemented. For instance, changes
in availability of links of a given bandwidth (e.g., OC-48) may in availability of links of a given bandwidth (e.g., OC-48) may
trigger updates only after the availability figure changes by a trigger updates only after the availability figure changes by a
certain percentage. certain percentage.
These concepts are relatively well-understood. On the other hand, These concepts are relatively well-understood. On the other hand,
the resource representation models and the topology discovery the resource representation models and the topology discovery
process for hierarchical routing (e.g., OSPF with multiple areas) process for hierarchical routing (e.g., OSPF with multiple areas)
are areas that need further work. are areas that need further work.
6.4 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 between two adjacent mechanisms are used to select an alternate link (or network segment)
OXCs across the INNI when a failure affects the primary link over between two OXCs across the INNI when a failure affects the primary
which the (protected) lightpath is being routed. Local restoration link (or primary network segment) over which the (protected)
does not affect the end-to-end route of the lightpath. When local lightpath is routed. Local restoration does not affect the end-to-
restoration is not possible (e.g., no alternate link is available end route of the lightpath. When local restoration is not possible
between the adjacent OXCs in question), end-to-end restoration may (e.g., no alternate link is available between the adjacent OXCs in
be performed. With this, the affected lightpath may be rerouted over question), end-to-end restoration may be performed. Under this
an alternate path that completely avoids the OXCs or the link scenario this, the affected lightpath may be rerouted over an
segment where the failure occurred. For end-to-end restoration, alternate diverse path to circumvent failed resources. For end-to-
draft-ietf-ipo-framework-04.txt end restoration, alternate paths may be pre-computed to expedite the
recovery time. End to end restoration may also be mixed with local
alternate paths are typically pre-computed. Such back-up paths may recovery in various ways depending on acceptable tradeoffs between
have to be physically diverse from the corresponding primary paths. utilization of network resources and recovery times.
End-to-end restoration 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 the back-up path. Under shared protection, back-up paths to 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 whose back-ups share resources. paths whose back-ups share resources.
skipping to change at line 1420 skipping to change at line 1385
implications on optical link bundling. Specifically, a bundled LSA implications on optical link bundling. Specifically, a bundled LSA
must include adequate information such that a remote OXC can must include adequate information such that a remote OXC can
determine the resource availability under each SRLG that the bundled determine the resource availability under each SRLG that the bundled
link refers to, and the relationship between links belonging to link refers to, and the relationship between links belonging to
different SRLGs in the bundle. For example, considering Figure 3, different SRLGs in the bundle. For example, considering Figure 3,
if links 1,2,3 and 4 are bundled together in an LSA, the bundled LSA if links 1,2,3 and 4 are bundled together in an LSA, the bundled LSA
must indicate that there are three SRLGs which are part of the must indicate that there are three SRLGs which are part of the
bundle (i.e., 1, 2 and 3), and that links in SRLGs 2 and 3 are also bundle (i.e., 1, 2 and 3), and that links in SRLGs 2 and 3 are also
part of SRLG 1. part of SRLG 1.
draft-ietf-ipo-framework-04.txt
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 ---
skipping to change at line 1473 skipping to change at line 1436
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 step, for example, using Suurbaale's algorithm [18]. In this one step, for example, using Suurbaale's algorithm [18]. 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
draft-ietf-ipo-framework-04.txt
link bundle LSAs to accommodate different path computation link bundle LSAs to accommodate different path computation
procedures and to maximize the chances of successful path procedures and to maximize the chances of successful path
establishment. Depending on the path computation procedure used, establishment. Depending on the path computation procedure used,
the type of support needed during path establishment (e.g., the the type of support needed during path establishment (e.g., the
recording of link group or SRLG information during path recording of link group or SRLG information during path
establishment) may differ. establishment) may differ.
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
skipping to change at line 1513 skipping to change at line 1474
further described in [13]. further described in [13].
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 relatively simple operation if a standard procedure is is a relatively simple operation if a standard procedure is
implemented within all sub-networks. Otherwise, proprietary implemented within all sub-networks. Otherwise, proprietary
signaling may be implemented within sub-networks, but converted back signaling may be implemented within sub-networks, but converted back
to standard signaling across the INNI. This is similar to signaling to standard signaling across the INNI. This is similar to signaling
across the ENNI, as described in Section 6.7. In the former case, across the ENNI, as described in Section 6.7. In the former case,
signaling messages could carry a strict explicit route in signaling signaling messages may carry strict explicit route information,
messages, while in the latter case the route should be loose, at the while in the latter case the route information should be loose, at
level of sub-networks. Once a route is determined for a lightpath, the level of abstraction of sub-networks. Once a route is determined
each OXC in the path must establish appropriate cross-connects in a for a lightpath, each OXC along the path must appropriately
coordinated fashion. This coordination is akin to selecting incoming configure their cross-connects in a coordinated fashion. This
and outgoing labels in a label-switched environment. Thus, protocols coordination is conceptually analogous to selecting incoming and
like RSVP-TE [11] and CR-LDP [10] can be used across the INNI for outgoing labels in a label-switched environment. Thus, protocols
this. A few new concerns, however, must be addressed. like RSVP-TE [11] may be adapted and used across the INNI for this
purpose. The adaptation of IP-based signaling protocols must take
into account a number of 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
draft-ietf-ipo-framework-04.txt
paths may be autonomously initiated by different nodes, it is paths may be autonomously initiated by different nodes, it is
possible that two path set-up attempts are in progress at the same possible that two path set-up attempts are in progress at the same
time. Specifically, while setting up an optical path, an OXC A may time. Specifically, while setting up an optical path, an OXC A may
select output port i which is connected to input port j of the select output port i which is connected to input port j of the
"next" OXC B. Concurrently, OXC B may select output port j for "next" OXC B. Concurrently, OXC B may select output port j for
setting up a different optical path, where the "next" OXC is A. This setting up a different optical path, where the "next" OXC is A. This
results in a "collision". Similarly, when WDM functionality is built results in a "collision". Similarly, when WDM functionality is built
into OXCs, a collision occurs when adjacent OXCs choose directly into OXCs, a collision occurs when adjacent OXCs choose directly
connected output ports and the same wavelength for two different connected output ports and the same wavelength for two different
optical paths. There are two ways to deal with such collisions. optical paths. There are two ways to deal with such collisions.
skipping to change at line 1575 skipping to change at line 1536
Signaling for restoration has two distict phases. There is a Signaling for restoration has two distict phases. There is a
reservation phase in which capacity for the protection path is reservation phase in which capacity for the protection path is
established. Then, there is an activation phase in which the established. Then, there is an activation phase in which the
back-up path is actually put in service. The former phase typically back-up path is actually put in service. The former phase typically
is not subject to strict time constraints, while the latter is. is not subject to strict time constraints, while the latter is.
Signaling to establish a "1+1" back-up path is relatively straight- Signaling to establish a "1+1" back-up path is relatively straight-
forward. This signaling is very similar to signaling used for forward. This signaling is very similar to signaling used for
establishing the primary path. Signaling to establish a shared back- establishing the primary path. Signaling to establish a shared back-
up path is a little bit different. Here, each OXC must understand up path is a little bit different. Here, each OXC must understand
which back-up paths can share resources. The signaling message must which back-up paths can share resources among themselves. The
itself indicate shared reservation. The sharing rule is as described signaling message must itself indicate shared reservation. The
in Section 6.4: back-up paths corresponding to physically diverse sharing rule is as described in Section 6.4: back-up paths
primary paths may share the same network resources. It is corresponding to physically diverse primary paths may share the same
therefore necessary for the signaling message to carry adequate network resources. It may therefore be necessary for the signaling
draft-ietf-ipo-framework-04.txt message to carry adequate information that allows an OXC to verify
that appropriateness of having a set of back-up paths sharing
information that allows an OXC to verify that back-up paths that certain.
share a certain resources are allowed to do so.
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 quick SONET-based, in-band signals may be used, resulting in expedited
response. With out-of-band control, it is necessary to consider response. With out-of-band control, it may be necessary to
fast signaling over the control channel using very short IP packets consider fast signaling over the control channel using very short IP
and prioritized processing. While it is possible to use RSVP or CR- packets and prioritized processing. While it is possible to use RSVP
LDP for activating protection paths, these protocols do not provide or CR-LDP for activating protection paths, these protocols do not
any means to give priority to restoration signaling as opposed to provide any means to give priority to restoration signaling as
signaling for provisioning. For instance, it is possible for a opposed to signaling for provisioning. For instance, it is possible
restoration-related RSVP message to be queued behind a number of for a restoration-related RSVP message to be queued behind a number
provisioning messages thereby delaying restoration. It is therefore of provisioning messages thereby delaying restoration. It may
necessary to develop a definition of QoS for restoration signaling therefore be necessary to develop a notion of prioritization for
and incorporate mechanisms in existing signaling protocols to restoration signaling and incorporate appropriate mechanisms into
achieve this. Or, a new signaling protocol may be developed existing signaling protocols to achieve this. Alternatively, a new
exclusively for activating protection paths during restoration. signaling mechanism may be developed exclusively for activating
protection 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.
o A standard signaling protocol is required for provisioning o A standard signaling protocol is required for provisioning
lightpaths across networks. lightpaths across networks.
o A standard procedure is required for the restoration of lightpaths o A standard procedure is required for the restoration of lightpaths
across networks. across networks.
o Support for policies that affect the flow of control information across networks will be required. o Support for policies that affect the flow of control information
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
draft-ietf-ipo-framework-04.txt
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 is essential that the OXC IP addresses are unique within the It is essential that the OXC IP addresses are unique within the
skipping to change at line 1684 skipping to change at line 1645
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 sophisticated than a simple repeater, that is capable of more sophisticated than a simple repeater, that is capable of
switching and converting a wavelength Lambda(k) from an input port switching and converting a wavelength Lambda(k) from an input port
to a wavelength Lambda(l) on an output port. In this display, it to a wavelength Lambda(l) on an output port. In this display, it
is not necessarily the case that Lambda(k) = Lambda(l), nor is it is not necessarily the case that Lambda(k) = Lambda(l), nor is it
draft-ietf-ipo-framework-04.txt
necessarily the case that the data carried on Lambda(k) is switched necessarily the case that the data carried on Lambda(k) is switched
through the device without being examined or modified. through the device without being examined or modified.
It is not necessary to have a wavelength converter at every It is not necessary to have a wavelength converter at every
switching element. A number of studies have attempted to address switching element. A number of studies have attempted to address
the issue of the value of wavelength conversion in an optical the issue of the value of wavelength conversion in an optical
network. Such studies typically use the blocking probability (the network. Such studies typically use the blocking probability (the
probability that a lightpath cannot be established because the probability that a lightpath cannot be established because the
requisite wavelengths are not available) as a metric to adjudicate requisite wavelengths are not available) as a metric to adjudicate
the effectiveness of wavelength conversion. The IP over optical the effectiveness of wavelength conversion. The IP over optical
skipping to change at line 1737 skipping to change at line 1696
complexity of proposed solutions, stability concerns, and lack of complexity of proposed solutions, stability concerns, and lack of
true economic drivers for this type of service. This document true economic drivers for this type of service. This document
assumes that this paradigm will not change and that highly dynamic, assumes that this paradigm will not change and that highly dynamic,
data-driven shortcut lightpath setups are for future investigation. data-driven shortcut lightpath setups are for future investigation.
Instead, the optical channel trails and lightpaths that are expected Instead, the optical channel trails and lightpaths that are expected
to be widely used at the initial phases in the evolution of IP over to be widely used at the initial phases in the evolution of IP over
optical networks will include the following: optical networks will include the following:
o Dynamic connections for control plane traffic and default path o Dynamic connections for control plane traffic and default path
routed data traffic, routed data traffic,
draft-ietf-ipo-framework-04.txt
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.
skipping to change at line 1792 skipping to change at line 1751
server in order to set up a lightpath from the source to the server in order to set up a lightpath from the source to the
destination. The server would then check to see if such a lightpath destination. The server would then check to see if such a lightpath
can be established based on prevailing conditions. Furthermore, can be established based on prevailing conditions. Furthermore,
depending on the specifics of the model, the server may either setup depending on the specifics of the model, the server may either setup
the lightpath on behalf of the client or provide the necessary the lightpath on behalf of the client or provide the necessary
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
draft-ietf-ipo-framework-04.txt
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
skipping to change at line 1844 skipping to change at line 1801
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
draft-ietf-ipo-framework-04.txt
characteristics of the optical layer [19] in a generic fashion, so characteristics of the optical layer [19] 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 was described as the least complex for near term deployment model was described as the least complex for near term deployment
and the peer model the most complex. Nevertheless, each model has and the peer model the most complex. Nevertheless, each model has
certain advantages and this raises the question as to the evolution certain advantages and this raises the question as to the evolution
skipping to change at line 1874 skipping to change at line 1829
optical domains. Under this model, direct signaling between IP optical domains. Under this model, direct signaling between IP
routers and optical networks is likely to be triggered by offline routers and optical networks is likely to be triggered by offline
traffic engineering decisions. The next step in the evolution of IP- traffic engineering decisions. The next step in the evolution of IP-
optical interaction is the introduction of reachability information optical interaction is the introduction of reachability information
exchange between the two domains. This would potentially allow exchange between the two domains. This would potentially allow
lightpaths to be established as part of end-to-end LSP set-up. The lightpaths to be established as part of end-to-end LSP set-up. The
final phase is the support for the full peer model with more final phase is the support for the full peer model with more
sophisticated routing interaction between IP and optical domains. sophisticated routing interaction between IP and optical domains.
Using a common signaling framework (based on GMPLS) from the Using a common signaling framework (based on GMPLS) from the
beginning facilitates this type of evolution. For the domain beginning facilitates this type of evolution. In this evolution, the
services model, implementation agreement based on GMPLS UNI signaling capability and semantics at the IP-optical boundary would
signaling is being developed in the Optical Interworking Forum (OIF) become more sophisticated, but the basic structure of signaling
[5, 6]. This agreement is aimed at near term deployment and this would remain. This would allow incremental developments as the
could be the precursor to a future peer model architecture. In this interconnection model becomes more sophisticated, rather than
evolution, the signaling capability and semantics at the IP-optical
boundary would become more sophisticated, but the basic structure of
signaling would remain. This would allow incremental developments as
the interconnection model becomes more sophisticated, rather than
complete re-development of signaling capabilities. complete re-development of signaling capabilities.
From a routing point of view, the use of Network Management Systems 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 networks. Going forward, it can be expected that connection optical networks. Going forward, it can be expected that connection
routing using the control plane will be gradually introduced and routing using the control plane will be gradually introduced and
integrated into operational infrastructures. The introduction of integrated into operational infrastructures. The introduction of
routing capabilities can be expected to occur in a phased approach. routing 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
draft-ietf-ipo-framework-04.txt
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 a system of optical subnetworks which are interconnected around a system of optical subnetworks which are interconnected
statically (or dynamically in a signaled configuration). During this statically (or dynamically in a signaled configuration). During this
phase, an overlay interconnection model will be used between the phase, an overlay interconnection model will be used between the
optical network itself and external IP and MPLS routers (as optical network itself and external IP and MPLS routers (as
described in Section 5.2.3). described in Section 5.2.3).
Progressing with this phased approach to IPO routing Progressing with this phased approach to IPO routing
skipping to change at line 1954 skipping to change at line 1904
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:
draft-ietf-ipo-framework-04.txt
o The authentication of entities exchanging information o The authentication of entities exchanging information
(e.g., signaling, routing, or link management) across a control (e.g., signaling, routing, or link management) across a control
interface; interface;
o Ensuring the integrity of the information exchanged across the interface; o Ensuring the integrity of the information exchanged across the
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 generally quite expensive, mechanisms are required to safeguard are 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,
skipping to change at line 2005 skipping to change at line 1954
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: authentication and confidentiality. Authentication mechanisms: authentication and confidentiality. Authentication
mechanisms ensure data origin verification and message integrity so mechanisms ensure data origin verification and message integrity so
that intrusions and unauthorized operations can be detected and that intrusions and unauthorized operations can be detected and
draft-ietf-ipo-framework-04.txt
mitigated. For example, with reference to Figure 1, message mitigated. For example, with reference to Figure 1, message
authentication can prevent a malicious IP client from mounting a authentication can prevent a malicious IP client from mounting a
denial of service attack against the optical network by invoking an denial of service attack against the optical network by invoking an
excessive number of connection creation requests across the UNI excessive number of connection creation requests across the UNI
interface. Additionally, authentication mechanisms can provide interface.
1. Replay protection, which detects and rejects attempts to
reorder, duplicate, truncate, or otherwise tamper with the
proper sequence of messages, and
2. Non-repudiation, which may be desirable for accounting and
billing purposes.
Confidentiality of signaling messages is also likely to be
desirable, especially in cases where message attributes include
information of a private nature to the communicating parties (client
and optical network operator). Examples of such attributes include
account numbers, contract identification numbers, etc, exchanged
over the UNI (Figure 1).
The case of non-co-located equipment presents increased security Confidentiality of signaling messages is also desirable, especially
threats. In this scenario, the signaling (or routing) peers may be in scenarios where message attributes between communicating entities
connected using an external network. Since such a network could be include sensitive or private information. Examples of such
outside the control of the optical (or client) network operator, attributes include account numbers, contract identification
control communication between peers may be subject to increased information, and similar types of private data.
security threats, such as address spoofing, eavesdropping and
unauthorized intrusion attempts. To counter these threats,
appropriate security mechanisms have to be employed to protect the
signaling and control channel(s).
Requests for optical connections from client networks must be The case of equipment that are not co-located presents increased
filtered against policy to guard against security infringements and security threats. In such scenarios, the communicating entities
excess resource consumption. engaged in protocol message transactions may be connected over an
external network. Generally, the external network may be outside the
span of control of the optical network (or client IP network)
administrators. As a result, the protocol messages may be subject to
increased security threats, such as address spoofing, eavesdropping,
and intrusion. To mitigate such threats, appropriate security
mechanisms must be employed to protect the control channels and
associated signaling and routing messages.
There may be a need for confidentiality of SRLGs in some Requests for optical connections from client networks must also be
circumstances. filtered using appropriate policies to protect against security
infringements and excess resource consumption. Additionally, there
may be a need for confidentiality of SRLGs in some circumstances.
Optical networks may also be subject to subtle forms of denial of Optical networks may also be subject to subtle forms of denial of
service attacks. An example of this would be requests for optical service attacks. An example of this would be requests for optical
connections with explicit routes that induce a high degree of connections with explicit routes that induce a high degree of
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 improbably optical paths are requested (i.e., paths within the when improbable optical paths are requested (i.e., paths within the
network for which resources were 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
draft-ietf-ipo-framework-04.txt
The security mechanisms required for IP-centric control plane The security requirements for IP-centric control protocols employed
protocols for optical networks would depend on the characteristics in the control plane of optical networks would depend on the
of the specific protocols and other pertinent security requirements. specific characteristics of the protocols and the security risks
Such details are beyond the scope of this document and hence are not that exist in a particular operational context. Such details
considered further. Nevertheless, it must be stated that such relating to particular operational contexts are beyond the scope of
control protocols must take into account the issues associated with this document and hence are not considered further. Nevertheless, it
the separation of control channels from data channels in switched must be stated that such control protocols must take into account
optical networks, and the magnitude and extent of service the issues associated with the separation of control channels from
interruptions within the IP domain that could result from outages data channels in switched optical networks, and the magnitude and
within the optical domain. extent of service interruptions within the IP domain that could
result from outages 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, routing and optical networks, considering the service models, and routing and
signaling issues. There are a diversity of choices, as described signaling issues. There are a diversity of choices for IP-optical
in this document, for IP-optical interconnection, service models control interconnection, service models, and protocol mechanisms.
and protocol mechanisms. The approach advocated in this document The approach advocated in this document was to support different
was to allow different service models and proprietary enhancements service models which allow for future enhancements, and define
in optical networks, and define complementary signaling and complementary signaling and routing mechanisms to enable these
routing mechanisms that would support these. An evolution scenario, capabilities. An evolutionary scenario, based on a common signaling
based on a common GMPLS-based signaling framework with increasing framework (e.g. based on GMPLS) was suggested, with the capability
interworking functionality was suggested. Under this scenario, the to increase the complexity of interworking functionality as the
IP-optical interaction is first based on the domain services model requirements become more sophisticated. A key aspect of this
with overlay interconnection that eventually evolves to support full evolutionary principle is that the IP-optical control and service
peer interaction. interaction is first based on the domain services model with overlay
interconnection that will eventually evolve to support full peer
interaction.
11. References 11. References
Note: All references are informative: Note: All references are informative:
1. D. Awduche and Y. Rekhter, , "Multi-Protocol 1. D. Awduche and Y. Rekhter, , "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering Control With Lambda Switching: Combining MPLS Traffic Engineering Control With
Optical Crossconnects," IEEE Communications Magazine, March 2001. Optical Crossconnects," IEEE Communications Magazine, March 2001.
2. J. P. Lang, et. al., "Link Management Protocol," Internet Draft, 2. J. P. Lang, et. al., "Link Management Protocol," Internet Draft,
Work in progress. Work in progress.
3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE," 3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE,"
Internet Draft, Work in progress. Internet Draft, Work in progress.
4. L. Berger, et. al, "Generalized MPLS - Signaling Functional 4. L. Berger, et. al, "Generalized MPLS - Signaling Functional
Description", RFC 3471. Description", RFC 3471.
5. B. Rajagopalan, "Documentation of IANA Assignments for LDP, RSVP 5. B. Rajagopalan, "Documentation of IANA Assignments for LDP, RSVP
skipping to change at line 2108 skipping to change at line 2050
4. L. Berger, et. al, "Generalized MPLS - Signaling Functional 4. L. Berger, et. al, "Generalized MPLS - Signaling Functional
Description", RFC 3471. Description", RFC 3471.
5. B. Rajagopalan, "Documentation of IANA Assignments for LDP, RSVP 5. B. Rajagopalan, "Documentation of IANA Assignments for LDP, RSVP
and RSVP-TE Extensions for Optical UNI Signaling," RFC 3476. and RSVP-TE Extensions for Optical UNI Signaling," RFC 3476.
6. The Optical Interworking Forum, "UNI 1.0 Signaling 6. The Optical Interworking Forum, "UNI 1.0 Signaling
Specification," December, 2001. Specification," December, 2001.
draft-ietf-ipo-framework-04.txt
7. K. Kompella et al, "OSPF Extensions in Support of Generalized 7. K. Kompella et al, "OSPF Extensions in Support of Generalized
MPLS," Internet Draft, Work in Progress. MPLS," Internet Draft, Work in Progress.
8. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC 8. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC
1771, March, 1995. 1771, March, 1995.
9. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999. 9. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999.
10. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling 10. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling
Functional Description," RFC 3472. Functional Description," RFC 3472.
skipping to change at line 2160 skipping to change at line 2100
Layer Routing", Internet Draft, Work in Progress. Layer Routing", Internet Draft, 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.
draft-ietf-ipo-framework-04.txt
13. Contributors 13. Contributors
Contributors are listed alphabetically. Contributors are listed alphabetically.
Daniel O. Awduche Daniel O. Awduche
Isocore MCI
8201 Greensboro Drive, Suite 102, 22001 Loudoun County Parkway
McLean, VA 22102 Ashburn, VA 20147
Phone: 703-298-5291 Phone: 703-886-1753
Email: awduche@awduche.com 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
 End of changes. 

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