Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 3717

IP over Optical Networks: A Framework

Pages: 48
Part 1 of 2 – Pages 1 to 25
None   None   Next

Top   ToC   RFC3717 - Page 1
Network Working Group                                     B. Rajagopalan
Request for Comments: 3717                                    Consultant
Category: Informational                                       J. Luciani
                                                  Marconi Communications
                                                              D. Awduche
                                                              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.


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").
Top   ToC   RFC3717 - Page 2

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
Top   ToC   RFC3717 - Page 3

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
Top   ToC   RFC3717 - Page 4
   second is the transport of IP traffic through an optical network
   together with the control and coordination issues that arise

   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.
Top   ToC   RFC3717 - Page 5

   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.
Top   ToC   RFC3717 - Page 6
   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

   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
Top   ToC   RFC3717 - Page 7
   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

   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.
Top   ToC   RFC3717 - Page 8

   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
Top   ToC   RFC3717 - Page 9
   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.
Top   ToC   RFC3717 - Page 10
                           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
Top   ToC   RFC3717 - Page 11
   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.
Top   ToC   RFC3717 - Page 12
   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

   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

   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
Top   ToC   RFC3717 - Page 13
      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:
Top   ToC   RFC3717 - Page 14
   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
Top   ToC   RFC3717 - Page 15
   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.
Top   ToC   RFC3717 - Page 16

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;
Top   ToC   RFC3717 - Page 17
   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,
Top   ToC   RFC3717 - Page 18
   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
Top   ToC   RFC3717 - Page 19
   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. 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
Top   ToC   RFC3717 - Page 20
   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
Top   ToC   RFC3717 - Page 21
   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

   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].
Top   ToC   RFC3717 - Page 22
   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.
Top   ToC   RFC3717 - Page 23
                        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
Top   ToC   RFC3717 - Page 24
   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
Top   ToC   RFC3717 - Page 25
   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.

(page 25 continued on part 2)

Next Section