doc: Add RFC documents

1 files changed, 2691 insertions, 0 deletions

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