[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

IPO and MPLS Working Groups                       S. Seetharaman
Internet Draft                                    Ohio State University
Expires: October 2001                             A. Durresi
Document: draft-osu-ipo-mpls-issues-02.txt        Ohio State University
Category: Informational                           R. Jagannathan
                                                  Ohio State University
                                                  R. Jain
                                                  Nayna Networks
                                                  N. Chandhok
                                                  Ohio State University
                                                  K. Vinodkrishnan
                                                  Ohio State University

                                                  April 2001

             IP over Optical Networks: A Summary of Issues

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsolete by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at

1. Abstract

   This draft presents a summary of issues related to transmission of
   IP packets over optical networks.  This is a compilation of many
   drafts presented so far in IETF.  The goal is to create a common
   document, which by including all the views and proposals will serve
   as a better reference point for further discussion.  The novelty of
   this draft is that we try to cover all the main areas of integration
   and deployment of IP and optical networks including architecture,
   routing, signaling, management, and survivability.

Many Authors     Informational - Expires October 2001     Page 1 of 53             IP over Optical Networks: Summary of Issues    March 2001

   Several existing and proposed network architectures are discussed.
   The two-layer model, which aims at a tighter integration between IP
   and optical layers, offers a series of important advantages over the
   current multi-layer architecture.  The benefits include more
   flexibility in handling higher capacity networks, better network
   scalability, more efficient operations and better traffic

   Multiprotocol Label Switching (MPLS) and its extension Generalized
   Multiprotocol Label Switching (GMPLS) have been proposed as the
   integrating structure between IP and optical layers. Routing in the
   non-optical and optical parts of the hybrid IP network needs to be
   coordinated.  Several models have been proposed including overlay,
   augmented, and peer-to-peer models.  These models and the required
   enhancements to IP routing protocols, such as, OSPF and IS-IS are

   Control in the IP over Optical networks is facilitated by MPLS
   control plane.  Each node consists of an integrated IP router and
   optical layer crossconnect (OLXC).  The interaction between the
   router and OLXC layers is defined.  Signaling among various nodes is
   achieved using CR-LDP and RSVP-TE protocols.

   The management functionality in optical networks is still being
   developed.  The issues of link initialization and performance
   monitoring are summarized in this document.

   With the introduction of IP in telecommunications networks, there is
   tremendous focus on reliability and availability of the new IP-
   optical hybrid infrastructures.  Automated establishment and
   restoration of end to end paths in such networks require
   standardized signaling and routing mechanisms.  Layering models that
   facilitate fault restoration are discussed.  A better integration
   between IP and optical will provide opportunities to implement a
   better fault restoration.

   The 02 revision fixes an error in the list of authors.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC-2119.


   1.  Overview
        1.1 Introduction
        1.2 Network Models

Many Authors     Informational - Expires October 2001     Page 2 of 53             IP over Optical Networks: Summary of Issues    March 2001

   2. Optical Switch Architecture
        2.1 Multi Protocol Label Switching (MPLS).
        2.2 Isomorphic Relations and Distinctions between OXCs and LSRs
        2.3 Isomorphic Relations and Distinctions between LSPs and
        2.4 General Requirements for the OXC Control Plane
                2.4.1 Overview of the MPLS Traffic Engineering Control
                2.4.2 OXC Enhancements to Support MPLS Control Plane
                2.4.3 MPLS Control Plane Enhancements
        2.5 MPLS Traffic Engineering Control Plane with OXCs
        2.6 Generalized MPLS

   3.  IP over Optical Networks
        3.1 Service Models
                3.1.1 Client Server Model
                3.1.2 Integrated Service Model
        3.2 IP Optical Interaction Models
                3.2.1 Overlay Model
                3.2.2 Peer Model
                3.2.3 Augmented Model
        3.3 Routing approaches
                3.3.1 Fully Peered Routing Model
                3.3.2 Domain Specific Routing
                3.3.3 Overlay Routing
        3.4 Path Selection
        3.5 Constraints on Routing

   4.  Control
        4.1 MPLS Control Plane
        4.2 Addressing
        4.3 Path Setup
                4.3.1 UNI Path provisioning
                4.3.2 Basic Path Setup Procedure for NNI
        4.4 Signaling protocols
                4.4.1 CR-LDP Extensions for Path Setup
                4.4.2 RSVP-TE Extensions for Path Setup
        4.5 Stream Control Transmission Protocol (SCTP)
        4.6 Configuration Control Using GSMP
         4.7 Resource Discovery Using NHRP

   5.  Optical Network Management
        5.1 Link Initialization
                5.1.1 Control Channel Management
                5.1.2 Verifying Link Connectivity
                5.1.3 Fault Localization
        5.2 Optical Performance Monitoring (OPM)

   6.  Fault restoration in Optical networks
        6.1 Layering
                6.1.1 SONET Layer Protection
                6.1.2 Optical Layer Protection
                6.1.3 IP Layer Protection

Many Authors     Informational - Expires October 2001     Page 3 of 53             IP over Optical Networks: Summary of Issues    March 2001

                6.1.4 MPLS Layer Protection
        6.2 Failure Detection
        6.3 Failure Notification
                6.3.1 Reverse Notification Tree (RNT)
        6.4 Protection Options
                6.4.1 Dynamic Protection
                6.4.2 Pre-negotiated Protection
                6.4.3 End to end repair
                6.4.4 Local Repair
                6.4.5 Link Protection
                6.4.6 Path Protection
                6.4.7 Revertive Mode
                6.4.8 Non-revertive Mode
                6.4.9 1+1 Protection
                6.4.10 1:1, 1:n, and n:m  Protection
                6.4.11 Recovery Granularity
        6.5 Signaling Requirements related to Restoration
        6.6 Pre-computed, Priority based restoration mechanism
        6.7 RSVP-TE/CR-LDP Support for Restoration

   7.  Security Considerations
   8.  Acronyms
   9.  Terminology
   10. References
   11. Author's Addresses

1. Overview

1.1 Introduction

   Challenges presented by the exponential growth of the Internet have
   resulted in the intense demand for broadband services.  In
   satisfying the increasing demand for bandwidth, optical network
   technologies represent a unique opportunity because of their almost
   unlimited potential bandwidth.

   Recent developments in wavelength-division multiplexing (WDM)
   technology have dramatically increased the traffic capacities of
   optical networks. Research is ongoing to introduce more intelligence
   in the control plane of the optical transport systems, which will
   make them more survivable, flexible, controllable and open for
   traffic engineering.  Some of the essential desirable attributes of
   optical transport networks include real-time provisioning of
   lightpaths, providing capabilities that enhance network
   survivability, providing interoperability functionality between
   vendor-specific optical sub-networks, and enabling protection and
   restoration capabilities in operational contexts.  The research
   efforts now are focusing on the efficient internetworking of higher
   layers, primarily IP with WDM layer.

   Along with this WDM network, IP networks, SONET networks, ATM
   backbones shall all coexist.  Various standardization bodies have

Many Authors     Informational - Expires October 2001     Page 4 of 53             IP over Optical Networks: Summary of Issues    March 2001

   been involved in determining an architectural framework for the
   interoperability of all these systems.

   One approach for sending IP traffic on WDM networks would use a
   multi-layered architecture comprising of IP/MPLS layer over ATM over
   SONET over WDM.  If an appropriate interface is designed to provide
   access to the optical network, multiple higher layer protocols can
   request lightpaths to peers connected across the optical network.
   This architecture has 4 management layers.  One can also use a
   packet over SONET approach, doing away with the ATM layer, by
   putting IP/PPP/HDLC into SONET framing.  This architecture has 3
   management layers.  A few problems of such multi layered
   architectures have been studied.

        |               |
        |   IP/MPLS     |
        |               |
        +---------------+   +---------------+
        |               |   |               |
        |     ATM       |   |    IP/MPLS    |
        |               |   |               |
        +---------------+   +---------------+    +-------------+
        |               |   |               |    |             |
        |    SONET      |   |    SONET      |    |  IP/MPLS    |
        |               |   |               |    |             |
        +---------------+   +---------------+    +-------------+
        |               |   |               |    |             |
        |     WDM       |   |      WDM      |    |     WDM     |
        |               |   |               |    |             |
        +---------------+   +---------------+    +-------------+

            (4 LAYERS)         (3 LAYERS)           (2 LAYERS)

              Figure 1: Layering Architectures Possible

   The fact that it supports multiple protocols, will increase
   complexity for IP-WDM integration because of various edge-
   interworkings required to route, map and protect client signals
   across WDM subnetworks.  The existence of separate optical layer
   protocols may increase management costs for service providers.

   One of the main goals of the integration architecture is to make
   optical channel provisioning driven by IP data paths and traffic
   engineering mechanisms.  This will require a tight cooperation of
   routing and resource management protocols at the two layers.  The
   multi-layered protocols architecture can complicate the timely flow
   of the possibly large amount of topological and resource

   Another problem is with respect to survivability.  There are various
   proposals stating that the optical layer itself should provide

Many Authors     Informational - Expires October 2001     Page 5 of 53             IP over Optical Networks: Summary of Issues    March 2001

   restoration/protection capabilities of some form.  This will require
   careful coordination with the mechanisms of the higher layers such
   as the SONET Automatic Protection Switching (APS) and the IP re-
   routing strategies.  Hold-off timers have been proposed to inhibit
   higher layers backup mechanisms.

   Problems can also arise from the high level of multiplexing done.
   The optical fiber links contain a large number of higher layer flows
   such as SONET/SDH, IP flows or ATM VCs.  Since these have their own
   mechanisms, a flooding of alarm messages can take place.

   Hence, a much closer IP/WDM integration is required.  The
   discussions, henceforth in this document, shall be of such an
   architecture.  There exist, clouds of IP networks, clouds of WDM
   networks.  Transfer of packets from a source IP router to a
   destination is required.  How the combination does signaling to find
   an optimal path, route the packet, and ensure survivability are the
   topics of discussion.

   Multi-Protocol Label Switching (MPLS) for IP packets is believed to
   be the best integrating structure between IP and WDM.  MPLS brings
   two main advantages.  First, it can be used as a powerful instrument
   for traffic engineering.  Second, it fits naturally to WDM when
   wavelengths are used as labels.  This extension of the MPLS is
   called the Multi-protocol lambda switching.

   This document starts off with a description of the optical network
   model.  Section 2 describes the correspondence between the optical
   network model and the MPLS architecture and how it can bring about
   the inter-working.  Section 3 is on routing in this architecture.
   It also describes 3 models for looking at the IP cloud and the
   Optical cloud namely the Overlay model, the augmented model and the
   peer model.  Sections 4 and 5 are on control, signaling and
   management, respectively.  Section 6 is on restoration. Acronyms and
   glossary are defined in Sections 8 and 9.

1.2 Network Model

   In this draft, all the discussions assume the network model shown in
   Figure 2 [Luciani00].  Here, we consider a network model consisting
   of IP routers attached to an optical core network and connected to
   their peers over dynamically switched lightpaths.  The optical core
   network is assumed to consist of multi-vendor optical sub-networks
   and are incapable of processing IP packets.  In this network model,
   a switched lightpath has to be established between a pair of IP
   routers for their communication. The lightpath might have to
   traverse multiple optical sub-networks and be subject to different
   provisioning and restoration procedures in each sub-network.

   For this network model, two logical control interfaces are
   identified, viz., the client-optical network interface (UNI), and
   the optical sub-network interface (NNI). The UNI represents a
   technology boundary between the client and optical networks. And,

Many Authors     Informational - Expires October 2001     Page 6 of 53             IP over Optical Networks: Summary of Issues    March 2001

   the NNI represents a technology boundary across multi-vendor optical
   sub-networks [Luciani00].

   The physical control structure used to realize these logical
   interfaces may vary depending on the context and service models,
   which are discussed later in this draft.

                              |          Optical Network              |
         +--------------+     |                                       |
         |              |     | +------------+        +------------+  |
         |   IP         |     | |            |        |            |  |
         |   Network     +--UNI--+   Optical  +---NNI--+   Optical |  |
         |              |     | | Subnetwork |        | Subnetwork |  |
         +--------------+     | |            |  +-----+            |  |
                              | +------+-----+  |     +------+-----+  |
                              |        |        |            |        |
                              |       NNI      NNI          NNI       |
         +--------------+     |        |        |            |        |
         |              |     | +------+-----+  |     +------+-----+  |
         |   IP         +--UNI--|            +--+     |            |  |
         |   Network    |     | |   Optical  |        |   Optical  |  |
         |              |     | | Subnetwork +---NNI--+ Subnetwork |  |
         +--------------+     | |            |        |            |  |
                              | +------+-----+        +------+-----+  |
                              |        |                     |        |
                                       |                     |
                                       |                     |
                                +------+-------+     +------------+
                                |              |     |            |
                                | Other Client |     |Other Client|
                                |   Network    |     |   Network  |
                                | (e.g., ATM)  |     |            |
                                +--------------+     +------------+

                         Figure 2: Network Model

2.  Optical Switch Architecture

   It has been realized that optical networks must be survivable,
   flexible, and controllable.  And hence, there is ongoing trend to
   introduce intelligence in the control plane of optical networks to
   make them more versatile.  There is general consensus in the
   industry that the optical network control plane should utilize IP-
   based protocols for dynamic provisioning and restoration of
   lightpaths within and across optical sub-networks.  In the existing
   IP-centric data network domain, these functionalities are performed
   by the Multi Protocol Label Switching (MPLS) traffic engineering
   control plane and currently in the optical domain it is achieved by
   Multi Protocol Lambda Switching (MPLambdaS), where wavelength is
   used as a label for switching the data at each hop.  In this

Many Authors     Informational - Expires October 2001     Page 7 of 53             IP over Optical Networks: Summary of Issues    March 2001

   section, we identify the similarities that exist between the all-
   optical crossconnects (OXCs) of the optical networks and the label
   switch routers (LSRs) of the MPLS networks and identify how the
   control plane model of MPLS traffic engineering (TE) can be applied
   to that of optical transport network.

2.1 Multi Protocol Label Switching (MPLS)

   Multi Protocol Label Switching is a switching method in which a
   label field in the incoming packets is used to determine the next
   hop. At each hop, the incoming label is replaced by another label
   that is used at the next hop. The path thus realized is called a
   Label Switched Path (LSP).  Devices which base their forwarding
   decision based solely on the incoming labels (and ports) are called
   Label Switched Routers (LSRs). In an IP-centric optical
   internetworking environment, OXCs and LSRs are used to switch the
   LSPs in the optical domain and the IP domain respectively.  The OXCs
   are programmable and may support wavelength conversion and
   translation.  It is important here to enumerate the relations and
   distinctions between OXCs and LSRs to expose the reusable software
   artifacts from the MPLS traffic engineering control plane model.
   Both OXCs and LSRs emphasize problem decomposition by
   architecturally decoupling the control plane from the data plane.

2.2 Isomorphic Relations and Distinctions between OXCs And LSRs

   While an LSR's data plane uses the label swapping paradigm to
   transfer a labeled packet from an input port to an output port, the
   data plane of an OXC uses a switch matrix to provision a lightpath
   from an input port to an output port.  LSR's control plane is used
   to discover, distribute, and maintain relevant state information
   related to the MPLS network, and to instantiate and maintain label
   switched paths (LSPs) under various MPLS traffic engineering rules
   and policies.  OXC's control plane is used to discover, distribute,
   and maintain relevant state information associated with the Optical
   Transport Network (OTN), and to establish and maintain lightpaths
   under various optical internetworking traffic engineering rules and
   policies [Awuduche].

   Current generation of OXCs and LSRs differ in certain
   characteristics.  While LSRs are datagram devices that can perform
   certain packet level operations in the data plane, OXCs cannot.
   They cannot perform packet level processing in the data plane.
   Another difference is that the forwarding information is carried
   explicitly in LSRs as part of the labels appended to the data
   packets unlike OXCs, where the switching information is implied from
   the wavelength or the optical channel.

2.3 Isomorphic Relations and Distinctions between LSPs and Lightpaths

   Both the explicit LSPs and lightpaths exhibit certain commonalties.
   For example, both of them are the abstractions of unidirectional,

Many Authors     Informational - Expires October 2001     Page 8 of 53             IP over Optical Networks: Summary of Issues    March 2001

   point-to-point virtual path connections.  [Awuduche].  Another
   commonality is that the payload carried by both LSPs and lightpaths
   are transparent along their respective paths.  They can be
   parameterized to stipulate their performance, behavioral, and
   survivability requirements from the network.  There are certain
   similarities in the allocation of labels to LSPs and in the
   allocation of wavelengths to lightpaths.

   There is one major distinction between LSPs and lightpaths in that
   LSPs support label stacking, but the concept similar to label
   stacking, i.e., wavelength stacking doesn't exist in the optical
   domain at this time.

2.4 General Requirements for the OXC Control Plane
   This section describes some of the requirements for the OXC control
   plane with emphasis on the routing components. Some of the key
   aspects to these requirements are:
   (a) to expedite the capability to establish lightpaths,
   (b) to support traffic engineering functions, and
   (c) to support various protection and restoration schemes.

   Since the historical implementation of the "control plane" of
   optical transport networks via network management has detrimental
   effects like slow restoration, preclusion of distributed dynamic
   routing control, etc., motivation is to improve the responsiveness
   of the optical transport network and to increase the level of
   interoperability within and between service provider networks.

   In the following sections, we give a brief overview of MPLS traffic
   engineering (MPLS-TE), summarize the enhancements that are required
   in the OXCs to support the MPLS TE as well as the changes required
   in the MPLS control plane to adapt to the OXCs.

2.4.1 Overview Of The MPLS Traffic Engineering Control

   The components of the MPLS traffic engineering control plane model
   include the following modules [Awuduche]:

   (a) Resource discovery.
   (b) State information dissemination to distribute relevant
   information concerning the state of the network, like network
   topology, resource availability information.
   (c) Path selection that is used to select an appropriate route
   through the MPLS network for explicit routing.
   (d) Path management, which includes label distribution, path
   placement, path maintenance, and path revocation.

   The above components of the MPLS traffic engineering control plane
   are separable, and independent of each other, and hence it allows an
   MPLS control plane to be implemented using a composition of best of
   breed modules.

Many Authors     Informational - Expires October 2001     Page 9 of 53             IP over Optical Networks: Summary of Issues    March 2001

2.4.2 OXC Enhancements to Support MPLS Control Plane

   This section discusses some of the enhancements to OXCs to support
   wavelength switching. This extension, which has now been superceded
   with Generalized MPLS (GMPLS) was originally called  Multiprotocol
   Lambda Switching or MPL(ambda)S.  There are three key enhancements.
   First, there should be a mechanism to exchange control information
   between OXCs, and between OXCs and other LSRs.  This can be
   accomplished in-band or quasi-in-band using the same links that are
   used to carry data-plane traffic, or out-of-band via a separate
   network.  Second, an OXC should be able to provide the MPLS traffic
   engineering control plane with pertinent information regarding the
   state of individual fibers attached to that OXC, as well the state
   of individual lightpaths or lightpaths within each fiber. Third,
   even when an edge LSR does not have WDM capabilities, it should
   still have the capability to exchange control information with the
   OXCs in the domain.

2.4.3 MPLS Control Plane Enhancements

   This section discusses the enhancements that are to be made in the
   MPLS control plane to support MPL(ambda)S.

   An MPLS domain may consist of links with different properties
   depending upon the type of network elements at the endpoints of the
   links.  Within the context of MPL(ambda)S, the properties of a link
   consisting of a fiber with WDM that interconnects two OXCs are
   different from that of a SONET link that interconnects two LSRs.  As
   an example, a conventional LSP cannot be terminated on a link
   connected to a pure OXC.  However, a conventional LSP can certainly
   be terminated on a link connected to a frame-based LSR.  These
   differences should be taken into account when performing path
   computations to determine an explicit route for an LSP.  It is also
   feasible to have the capability to restrict the path of some LSPs to
   links with certain characteristics.  Path computation algorithms may
   then take this information into account when computing paths LSPs.

   If there are multiple control channels and bearer channels between
   two OXCs, then there must be procedures to associate bearer channels
   to corresponding control channels.  Procedures are required to de-
   multiplex the control traffic for different bearer channels if a
   control channel is associated with multiple bearer channels.
   Procedures are also needed to activate and deactivate bearer
   channels, to identify the bearer channels associated with any given
   physical link, to identify spare bearer channels for protection
   purposes, and to identify impaired bearer channels, particularly, in
   the situation where the physical links carrying the bearer channel
   are not impaired.

   Signaling protocols (RSVP-TE and CR-LDP) need to be extended with
   objects that can provide sufficient details to establish
   reconfiguration parameters for OXC switch elements.  Interior

Many Authors     Informational - Expires October 2001    Page 10 of 53             IP over Optical Networks: Summary of Issues    March 2001

   Gateway Protocols (IGPs) should be extended to carry information
   about the physical diversity of the fibers.  IGPs should be able to
   distribute information regarding the allocatable bandwidth
   granularity of any particular link.

2.5 MPLS Traffic Engineering Control Plane with OXCs

   In IP-centric optical interworking systems, given that both OXCs and
   LSRs require control planes, one option would be to have two
   separate and independent control planes [Awuduche].  Another option
   is to develop a uniform control plane that can be used for both LSRs
   and OXCs.  This option of having a uniform control plane will
   eliminate the administrative complexity of managing hybrid optical
   internetworking systems with separate, dissimilar control and
   operational semantics.  Specialization may be introduced in the
   control plane, as necessary, to account for inherent peculiarities
   of the underlying technologies and networking contexts.  A single
   control plane would be able to span both routers and OXCs.  In such
   an environment, a LSP could traverse an intermix of routers and
   OXCs, or could span just routers, or just OXCs.  This offers the
   potential for real bandwidth-on-demand networking, in which an IP
   router may dynamically request bandwidth services from the optical
   transport network.

   To bootstrap the system, OXCs must be able to exchange control
   information.  One way to support this is to pre-configure a
   dedicated control wavelength between each pair of adjacent OXCs, or
   between an OXC and a router, and to use this wavelength as a
   supervisory channel for exchange of control traffic.  Another
   possibility would be to construct a dedicated out-of-band IP network
   for the distribution of control traffic.

   Though an OXC equipped with MPLS traffic engineering control plane
   would resemble a Label Switching Router; there are some important
   distinctions and limitations.  As discussed earlier, the distinction
   concerns the fact that there are no analogs of label merging in the
   optical domain, which implies that an OXC cannot merge several
   wavelengths into one wavelength.  Another major distinction is that
   an OXC cannot perform the equivalent of label push and pop operation
   in the optical domain.  This is due to lack of the concept of
   pushing and popping wavelengths is infeasible with contemporary
   commercial optical technologies.  Finally, there is another
   important distinction, which is concerned with the granularity of
   resource allocation.  An MPLS router operating in the electrical
   domain can potentially support an arbitrary number of LSPs with
   arbitrary bandwidth reservation granularities, whereas an OXC can
   only support a relatively small number of lightpaths, each of which
   will have coarse discrete bandwidth granularities.

2.6 Generalized MPLS (GMPLS)

   The Multi Protocol Lambda Switching architecture has recently been
   extended to include routers whose forwarding plane recognizes

Many Authors     Informational - Expires October 2001    Page 11 of 53             IP over Optical Networks: Summary of Issues    March 2001

   neither packet, nor cell boundaries, and therefore, can't forward
   data based on the information carried in either packet or cell
   headers. Specifically, such routers include devices where the
   forwarding decision is based on time slots, wavelengths, or physical
   ports. GMPLS differs from traditional MPLS in that it supports
   multiple types of switching, i.e., the addition of support for TDM,
   lambda, and fiber (port) switching. The support for the additional
   types of switching has driven generalized MPLS to extend certain
   base functions of traditional MPLS [GMPLS].

   While traditional MPLS links are unidirectional, generalized MPLS
   supports the establishment of bi-directional paths. The need for bi-
   directional LSPs comes from its extent of reach. Bi-directional
   paths also have the benefit of lower setup latency and lower number
   of messages required during setup. Other features supported by
   generalized MPLS are rapid failure notification and termination of a
   path on a specific egress port.

   To deal with the widening scope of MPLS into the optical and time
   domain, several new forms of "label" are required. These new forms
   of label are collectively referred to as a "generalized label". A
   generalized label contains enough information to allow the receiving
   node to program its crossconnect.  Since the nodes sending and
   receiving this new form of label know what kinds of link they are
   using, the generalized label does not contain a type field, instead
   the nodes are expected to know from context what type of label to
   expect.  Currently, label formats supported by GMPLS are the
   Generalized Label, the Waveband Switching Label (which apparently
   uses the same Generalized Label format), the Suggested Label and the
   Label Set [GMPLS00].

   (1) The Generalized Label:  It extends the traditional Label Object
   in that it allows the representation of not only labels which travel
   in-band with associated data packets, but also labels which identify
   time-slots, wavelengths, or space division multiplexed positions. A
   Generalized Label only carries a single level of label, i.e., it is
   non-hierarchical.  When multiple levels of label (LSPs within LSPs)
   are required, each LSP must be established separately.

   (2) Waveband Switching Label: Waveband switching label format uses
   the same format as the generalized label.  Waveband switching is a
   special case of lambda switching, where a set of contiguous
   wavelengths are represented as a waveband and can be switched
   together to a new waveband.

   (3) Suggested Label: The Suggested Label is used to provide a
   downstream node with the upstream node's label preference, which
   permits the upstream node to start configuring its hardware with the
   proposed label before the label is communicated by the downstream
   node.  This feature is valuable to systems where it takes non-
   trivial time to establish a label in hardware and thus reducing
   setup latency. One use of suggested labels is to indicate preferred

Many Authors     Informational - Expires October 2001    Page 12 of 53             IP over Optical Networks: Summary of Issues    March 2001

   (4) Label Set: The Label Set is used to limit the label choices of a
   downstream node to a set of acceptable labels.  This limitation
   applies on a per hop basis. Label Set is used to restrict label
   ranges that may be used for a particular LSP between two peers.  The
   receiver of a Label Set must restrict its choice of labels to one
   which is in Label Set. Conceptually, the absence of a Label Set
   implies a Label Set whose value is the set of all valid labels.

3. IP over Optical Networks

3.1 Service models

   The optical network model considered in this draft consists of
   multiple Optical Crossconnects (OXCs) interconnected by optical
   links in a general topology (referred to as an "optical mesh
   network").  Each OXC is assumed to be capable of switching a data
   stream from a given input port to a given output port.  This
   switching function is controlled by appropriately configuring a
   crossconnect table.  Conceptually, the crossconnect table consists
   of entries of the form <input port i, output port j>, indicating
   that data stream entering input port i will be switched to output
   port j.  An "lightpath" from an ingress port in an OXC to an egress
   port in a remote OXC is established by setting up suitable
   crossconnects 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.  Lightpaths are assumed to be bi-directional, i.e.,
   the return path from the egress port to the ingress port follows the
   same path as the forward path.It is assumed that one or more control
   channels exist between neighboring OXCs for signaling purposes.

   In this section two possible service models are discussed in brief.
   The first being at the optical UNI and the second being at the
   optical sub-network NNI[Luciani00].

3.1.1 Client Server Model

   Under this model the optical network primarily provides a set of
   high bandwidth pipes to the client requesting such. Standardized
   signaling can be used to invoke the following:

   1. Lightpath creation.
   2. Lightpath deletion.
   3. Lightpath modification.
   4. Lightpath status enquiry.

   The continued operation of the system requires that the client
   systems continuously register with the optical network. Signalling
   extensions need to be added to allow clients to register, deregister
   and query other clients for an optical-networked administered
   address so that lightpaths can be established with other clients
   across the optical network. Along with these signaling extensions a
   service discovery mechanism needs to be added which will allow the

Many Authors     Informational - Expires October 2001    Page 13 of 53             IP over Optical Networks: Summary of Issues    March 2001

   client to discover the static parameters of the link along with the
   UNI signaling protocol being used on the link. In this service model
   the routing protocols inside the optical network are exclusive of
   what is followed inside the client network. Only a minimal set of
   messages need to be defined between the router and the optical
   network. RSVP-TE, LDP or a TCP based control channel can be used for
   the same. Within the optical cloud NNI interface is defined between
   the various optical subnetworks. Details of the UNI and NNI
   signaling requirements are provided further on in this document.

3.1.2 Integrated Service Model

   In the Integrated Service Model the IP and the optical networks are
   treated as a single network and there is no distinction between the
   optical switches and the IP routers as far as the control plane
   goes. MPLS would be the preferred method for control and routing and
   there is no distinction between the UNI, NNI or any other router-
   router interface. Under this model, optical network services are
   provisioned using MPLS signaling as specified in [GMPLS]. In this
   service model the edge router can do the creation and modification
   of the label switched paths across the optical network. In some
   sense this resembles the client server model just presented, but it
   seems to promise seamless integration when compared to the client
   server model. OSPF with TE extensions to support optical networks
   could be used to exchange topology information and do the routing
   .It might happen in an optical network that a LSP across the optical
   network may be a conduit for a lot of other LSPs. This can be
   advertised as a virtual link inside a forward adjacency in protocols
   like OSPF. Thus from the point of view of the data plane an overlay
   is created between two edge routers across the optical network.

3.2 IP Optical Interaction Models

   The previous section presented possible service models for IP over
   optical networks. The models differ in the way routing is
   implemented. It is important to examine the architectural
   alternatives for routing information exchange between IP routers and
   optical switches. The aim of this exercise is to allow service
   discovery, automated establishment and seamless integration with
   minimal intervention. MPLS based signaling is assumed in the
   following discussion.

   Some of the proposed models for interaction between IP and optical
   components in a hybrid network are [Luciani00]:

   (1) Overlay model
   (2) Integrated/Augmented model
   (3) Peer model

   The key consideration in deciding the type of model is whether there
   is a single or separate monolithic routing and signaling protocol
   spanning the IP and the Optical domains.  If there are separate

Many Authors     Informational - Expires October 2001    Page 14 of 53             IP over Optical Networks: Summary of Issues    March 2001

   instances of routing protocols running for each domain then the
   following three considerations help determine the model:
   1. What is the interface defined between the two protocol instances?
   2. What kind of information is exchanged between the protocol
   3. What are policies regarding provisioning of the lightpaths across
      the optical domain between edge routers? This includes access
      control accounting and security.

3.2.1 Overlay Model

   Under the overlay model, IP domain is more or less independent of
   the optical domain.  That is IP domain acts as a client to the
   Optical domain.  In this scenario, the optical network provides
   point to point connection to the IP domain.  The IP/MPLS routing
   protocols are independent of the routing and signaling protocols of
   the optical layer.  The overlay model may be statically provisioned
   using a Network Management System or may be dynamically provisioned.
   Static provisioning solution may not be scalable though.

3.2.2 Peer Model

   In the peer model the optical routers and optical switches act as
   peers and there is only one instance of a routing protocol running
   in the optical domain and in the IP domain. A common IGP like OSPF
   or IS-IS may be used to exchange topology information. OSPF opaque
   Link State Advertisements (LSAs) and extended type-length-value
   encoded fields (TLVs) may be used in the case of IS-IS. The
   assumption in this model is that all the optical switches and the
   routers have a common addressing scheme.

3.2.3 Augmented Model

   In the augmented model, there are actually separate routing
   instances in the IP and optical domains but information from one
   routing instance is leaked into the other routing instance.  For
   example IP addresses could be assigned to optical network elements
   and carried by optical routing protocols to allow reachability
   information to be shared with the IP domain to support some degree
   of automated discovery.

3.3 Routing Approaches

3.3.1 Fully peered routing model

   This routing model is used for the peer model described above. Under
   this approach there is only one instance of the routing protocol
   running in the IP and Optical domains. An IGP like OSPF or IS-IS
   with suitable optical extensions is used to exchange topology
   information. These optical extensions will capture the unique
   optical link parameters. The OXCs and the routers maintain the same
   link state database. The routers can then compute end-to-end paths

Many Authors     Informational - Expires October 2001    Page 15 of 53             IP over Optical Networks: Summary of Issues    March 2001

   to other routers across the OXCs. Such a Label Switched Path (LSP)
   can then be signaled using MPLS signaling protocols like RSVP-TE or
   CR-LDP. This lighpath is always a tunnel across the optical network
   between edge routers. Once created such lightpaths are treated as
   virtual links and are used in traffic engineering and route
   computation. As and when forwarding adjacencies (FAs) are introduced
   in the link state corresponding links over the IP Optical interface
   are removed from the link state advertisements. Finally the details
   of the optical network are completely replaced by the FAs advertised
   in the link state.

3.3.2 Domain Specific Routing

   This routing model supports the augmented routing model. In this
   model the routing between the optical and the IP domains is
   separated with a specific routing protocol running between the
   domains. The focus is on the routing information to be exchanged at
   the IP optical interface. Interdomain routing protocols like BGP may
   be used to exchange information between the IP and optical domain.
   OSPF areas may also be used to exchange routing information across
   the two domains. Routing using BGP

   BGP will allow IP networks to advertise IP addresses within its
   network to external optical networks while receiving external IP
   prefixes from the optical network. Edge routers and OXCs can run
   External BGP (EBGP). Within the optical network EBGP can be used
   between optical subnetworks across the NNI and Internal BGP (IBGP)
   can be used within the optical network. Using this scheme it is
   essential to identify the optical network corresponding to the
   egress IP addresses. The reason is as follows.  Whenever an edge
   router wants to setup a LSP across an optical network it is just
   going to specify the destination IP. Now if the edge router has to
   request another path to the destination it must know if there
   already exist lightpaths with residual capacity to the destination.
   To determine this it needs to know which ingress ports in an OXC
   correspond to which external destination. Thus a border OXC
   receiving external IP addresses by way of EBGP must include
   information about its IP address and pass it on to the edge router.
   The edge router must store this association between the OXCs and the
   external IP addresses and need not propagate the egress address
   further. Specific mechanisms to propagate the BGP egress addresses
   are yet to be determined. Routing using OSPF

   OSPF supports the concept of hierarchical routing using OSPF areas.
   Information across a UNI can be exchanged using this concept of a
   hierarchy. Routing within each area is flat. Routers attached to
   more than one areas are called Area Border Routers (ABR). An ABR
   propogates IP addressing information from one area to another using
   a summary LSA. Domain specific routing can be done within each area.

Many Authors     Informational - Expires October 2001    Page 16 of 53             IP over Optical Networks: Summary of Issues    March 2001

   Optical networks can be implemented as an area with an enhanced
   version of OSPF with optical extensions running on it. IP client
   networks can be running OSPF with TE extensions. Summary LSAs
   exchanged between the two areas would provide enough information for
   the establishment of lightpaths across the optical network. Domain
   specific information in the optical network can be hidden from the
   client network.

   OSPF or BGP help in route discovery and collecting reachability
   information. Determination of paths and setting up of the LSPs is a
   traffic engineering decision.

3.3.3 Overlay Routing

   Overlay routing is much like the IP over ATM and supports the
   overlay connection model. IP overlays are setup across the optical
   network. Address resolution similar to that in IP over ATM is used.
   The optical network can maintain a registry of IP addresses and VPN
   identifiers it is connected to. On querying the database for an
   external IP address it would return the appropriate egress port
   address on the OXC. Once an initial set of lightpaths are created
   VPN wide routing adjacencies can be formed using OSPF. The IP VPN
   would then be "overlayed" on the underlying optical network which
   could have an independent way of routing.

3.4 Path Selection

   A possible scenario for path selection is presented in Figure 3.

         +--------+       +--------+       +--------+
         |        |<----->|Path    |       |OSPF    |
         | CR-LDP |   +-->|Selector|       |        |
         |        |   |   |        |       |TE EXT  |
         +--------+   |   +---+----+   +---|OPT EXT |
                      |       |        |   +--------+
                      |       v        |
                      |   +--------+   |   +--------+
         +--------+   |   |TE      |   |   |IS-IS   |
         |        |   |   |Database|   |   |        |
         | RSVP-TE|<--+   |        |   |   |TE EXT  |
         |        |       |        |<--+---|OPT EXT |
         +--------+       +--------+       +--------+

                Figure 3: Lightpath Selection

   These systems use CR-LDP or RSVP-TE to signal MPLS paths.  These
   protocols can source route by consulting a traffic engineering
   database, which is maintained along with the IGP database.  This
   information is carried opaquely by the IGP for constraint based
   routing.  If RSVP-TE or CR-LDP is used solely for label
   provisioning, the IP router functionality must be present at every
   label switch hop along the way.  Once the label has been provisioned

Many Authors     Informational - Expires October 2001    Page 17 of 53             IP over Optical Networks: Summary of Issues    March 2001

   by the protocol then at each hop the traffic is switched using the
   native capabilities of the device to the eventual egress LSR.

   Path selection can be online or offline. An offline computation is
   normally centralized while as an online computation is normally
   distributed. An offline computation is facilitated by simulation or
   network planning tools and can be used to provide guidance to
   subsequent real time computations. An online computation may be done
   whenever a connection request comes in. A combination of offline and
   online computations may be used by a network operator. Offline
   computations are used when complicated traffic engineering, demand
   planning, cost planning and global optimization is a priority.

   In case of online computations there can be two choices when it
   comes to routing.
   1) Explicit routing using a global view of the network can be used
   to calculate the most optimal solution taking into consideration
   constraints other than link metrics.
   2) Hop by hop routing using path calculation at every node. This may
   not be able to provide an optimal solution taking into consideration
   constraints other than non additive link metrics.

3.5 Constraints on Routing

   The constraints highlighted here apply to any circuit switched
   networks but differences with an optical network are explained where

   One of the main services provided by any transport network is
   restoration. Restoration introduces the constraint of physically
   diverse routing. Restoration can be provided by pre-computed paths
   or computing the backup path in real time. The backup path has to be
   diverse from the primary path at least in the failed link or
   completely physically diverse. A logical attribute like the Shared
   Risk Link Group (SRLG) is abstracted by the operators from various
   physical attributes like trench ID and destructive areas. Such an
   attribute may be needed to be considered when making a decision
   about which path to take in a network. Two links which share a SRLG
   cant be the backup for one another because they both may go down at
   the same time. In order to satisfy such constraints path selection
   algorithms are needed to find two disjoint paths in a graph.
   Suurballe's algorithm as discussed [Suurballe] is a good example of
   an algorithm to find two node disjoint paths in a network.

   Another restoration mechanism is restoration in a shared mesh
   architecture wherein backup bandwidth may be shared among circuits.
   It may be the case that two link disjoint paths share a backup path
   in the network. This may be possible because a single failure
   scenario is assumed. A few heuristics to optimize the bandwidth
   allocated to a backup path in a mesh architecture have already been
   proposed [Bell-Labs]. Optimal routing requires considerable network
   level information and the most optimal solutions still require

Many Authors     Informational - Expires October 2001    Page 18 of 53             IP over Optical Networks: Summary of Issues    March 2001

   further study. Detailed protection and restoration mechanisms are
   discussed in later sections of this document.

   Another constraint of interest is the concept of node, link, LSP
   inclusion or exclusion, propagation delay, wavelength convertibility
   and connection bandwidth among other things. A service provider may
   want to exclude a set of nodes due to the geographic location of the
   nodes. An example would be nodes lying in an area which is
   earthquake prone. Propagation delay may be another constraint for a
   large global network. Traffic from the US to Europe, shouldn't
   normally be routed over links across the Pacific ocean but instead
   should use links over the Atlantic ocean since propagation delay in
   this case would be much less.

   Wavelength convertibility is a problem encountered in waveband
   networks. It refers to ability of OXC to crossconnect two different
   wavelengths. The wavelengths may be completely different or slightly
   different. Since wavelength convertibility currently involves an
   optical-electrical-optical (OEO) conversion, vendors may selectively
   deploy these converters inside the network. Therein lies the problem
   of routing a circuit over a network using the same wavelength. This
   requires that the path selection algorithms know the availability of
   each wavelength on each link along the route. With link bundling,
   this is difficult since information about all the wavelengths may be
   included in the same bundle. Link probing may have to be employed at
   the source router to find out the number of wavelengths available
   along the path.

   Bandwidth availability is another consideration in routing. This is
   simplified in a wavelength optical network since requests are end to
   end. However, in a TDM transport network such as a SONET/SDH
   network, requests can be variable bandwidth. Routing needs to ensure
   that sufficient capacity is available end to end. There are further
   difficulties introduced due to the different concatenation schemes
   in the SONET/SDH schemes. An example would be a concatenated STS-3c
   channel, which would require three adjacent time slots to be
   allocated. This implies that a time slot map of the link has to be
   distributed to the entire network to facilitate a routing decision.
   Alternatively in a logical link representation one would need N
   different logical links to represent all possible STS-N signals. But
   then this would take up too much control bandwidth. A preferred
   approach would be to advertise just the largest block of time slots
   available on a logical link instead of the entire time slot map.
   This is sufficient to determine if a connection can be supported on
   a link. Detailed resource information on local resource availability
   is only used for routing decisions.

4. Signaling & Control

   Signaling refers to messages used to communicate characteristics of
   services requested or provided. This section discusses a few of the
   signaling procedures.  It is assumed that there exists some default

Many Authors     Informational - Expires October 2001    Page 19 of 53             IP over Optical Networks: Summary of Issues    March 2001

   communication mechanism between routers prior to using any of the
   routing and signaling mechanisms.

4.1 MPLS Control Plane

   A candidate system architecture for an OXC equipped with an MPLS
   control plane model is shown in Figure 4.  The salient feature of
   the network architecture is that every node in the network consists
   of an IP router and a reconfigurable OLXC.  The IP router is
   responsible for all non-local management functions, including the
   management of optical resources, configuration and capacity
   management, addressing, routing, traffic engineering, topology
   discovery, exception handling and restoration.  In general, the
   router may be traffic bearing, or it may function purely as a
   controller for the optical network and carry no IP data traffic.
   Although the IP protocols are used to perform all management and
   control functions, lightpaths may carry arbitrary types of traffic.

   The IP router implements the necessary IP protocols and uses IP for
   signaling to establish lightpaths.  Specifically, optical resource
   management requires resource availability per link to be propagated,
   implying link state protocols such as OSPF.  Between each pair of
   neighbors in the network, one communication channel exists that
   allows router to router connectivity over the channel.  These
   signaling channels reflect the physical topology. All traffic on the
   signaling channel is IP traffic and is processed or forwarded by the
   router. Multiple signaling channels may exist between two neighbors
   and some may be reserved for restoration.  Therefore, we can assume
   that as long as the link between two neighbors is functional, there
   is a signaling channel between those neighbors.

         |                                |
         |       -------------------      |
         |      |                   |     |
         |      | MPLS Control Plane|     |
         |      |                   |     |
         |       -------------------      |
         |               |                |
         |       -------------------      |
         |      |                   |     |
         |      |Control Adaptation |     |
         |       -------------------      |
         |      |    OXC Switch     |     |
         |      |    Controller     |     |
         |       -------------------      |
         |               |                |
         |       -------------------      |
         |      |                   |     |
         |      | OXC Switch Fabric |     |
         |      | OXC Data Plane    |     |
         |       -------------------      |

Many Authors     Informational - Expires October 2001    Page 20 of 53             IP over Optical Networks: Summary of Issues    March 2001

         |                                |

                Figure 4: OXC Architecture

   The IP router module communicates with the OLXC device through a
   logical interface.  The interface defines a set of basic primitives
   to configure the OLXC, and to enable the OLXC to convey information
   to the router.  The mediation device translates the logical
   primitives to and from the proprietary controls of the OLXC.
   Ideally, this interface is both explicit and open.  We recognize
   that a particular realization may integrate the router and the OLXC
   into a single box and use a proprietary interface implementation.
   Figure 5 illustrates this implementation.

   The following interface primitives are examples of a proposal for
   communication between the router and the OLXC within a node:

   a) Connect(input link, input channel, output link, output channel):
   Commands sent from the router to the OLXC requesting that the OLXC
   crossconnect input channel on the input link to the output channel
   on the output link.

   b) Disconnect(input link, input channel, output link, output
   channel):  Command sent from the router to the OLXC requesting that
   it disconnect the output channel on the output link from the
   connected input channel on the input link.

                      |                               |
                      |        Router   module        |
                      |                               |
                      |                               |
                      |  |                         |  |
                      |  |        Primitives       |  |
                      |  |        /|\   |          |  |
                      |  |         |    |          |  |
                      +--+---------+----+----------+--+  Control
   Channel            |  |         |    |          |  |
            ----------+--+         |    |          +--+---------
            ----------+----------  |   \|/  ----------+---------
            ----------+----------           ----------+---------
            ----------+----------           ----------+---------
            ----------+----------           ----------+---------
                      |             OLXC              |
                      |                               |
                      |                               |

                        Figure 5: Control Plane Architecture

Many Authors     Informational - Expires October 2001    Page 21 of 53             IP over Optical Networks: Summary of Issues    March 2001

   c) Bridge(input link, input channel, output link, output channel):
   Command sent from the router controller to the OLXC requesting the
   bridging of a connected input channel on input link to another
   output channel on output link.

   d) Switch(old input link, old input channel, new input link, new
   input channel, output link, output channel): Switch output port from
   the currently connected input channel on the input link to the new
   input channel on the new input link.  The switch primitive is
   equivalent to atomically implementing a disconnect(old input
   channel, old input link, output channel, output link) followed by a
   connect(new input link, new input channel, output link, output

   e) Alarm(exception, object):
   Command sent from the OLXC to the router informing it of a failure
   detected by the OLXC.  The object represents the element for which
   the failure has been detected.

   For all of the above interfaces, the end of the connection can also
   be a drop port.

4.2 Addressing

   Every network addressable element must have an IP address.
   Typically these elements include each node and every optical link
   and IP router port.  When it is desirable to have the ability to
   address individual optical channels those are assigned IP addresses
   as well.  The IP addresses must be globally unique if the element is
   globally addressable.  Otherwise domain unique addresses suffice.  A
   client must also have an IP address by which it is identified.
   However, optical lightpaths could potentially be established between
   devices that do not support IP (i.e., are not IP aware), and
   consequently do not have IP addresses.  This could be handled either
   by assigning an IP address to the device, or by assigning an address
   to the OLXC port to which the device is attached.  Whether or not a
   client is IP aware can be discovered by the network using
   traditional IP mechanisms.

4.3 Path Setup

   This section describes a protocol proposed for setting up an end-to-
   end lightpath for a channel. A complete path might contain the two
   endpoints and an array of intermediate OXCs for transport across the
   optical network. This section describes the handshake used for ad-
   hoc establishment of lightpaths in the network. Provisioning an end-
   to-end optical path across multiple sub-networks involves the
   establishment of path segments in each sub-network sequentially.
   Inside the optical domain, a path segment is established from the
   source OXC to a border OXC in the source sub-network. From this
   border OXC, signaling across the NNI is performed to establish a

Many Authors     Informational - Expires October 2001    Page 22 of 53             IP over Optical Networks: Summary of Issues    March 2001

   path segment to a border OXC in the next sub-network. Provisioning
   continues this way until the destination OXC is reached.

   The link state information is used to compute the routes for
   lightpaths being established. It is assumed that a request to
   establish a lightpath may originate from an IP router (over the
   UNI), a border node (over the NNI) , or a management system. This
   request carries all required parameters. After computing the route,
   the actual path establishment commences. However, once path setup is
   complete the data transfer happens passively and is straightforward
   without much intervention from the control plane. The connection
   needs to be maintained as per the service level agreements.

   To automate this process, there are certain initiation procedures so
   as to determine the route for each segment (viz. IP host _ IP border
   router, IP border router - border OXC, between border OXCs).

   * Resource Discovery

   Routing within the optical network relies on knowledge of network
   topology and resource availability. The first step towards network-
   wide link state determination is the discovery of the status of
   local links to all neighbors by each OXC. The end result is that
   each OXC creates a port state database.

   Topology information is distributed and maintained using standard
   routing algorithms, e.g., OSPF and IS-IS.  On boot, each network
   node goes through neighbor discovery.  By combining neighbor
   discovery with local configuration, each node creates an inventory
   of local resources and resource hierarchies, namely: channels,
   channel capacity, wavelengths, and links.

   * Route calculation

   Different mechanisms for routing exist [Luciani00]. The route
   computation, after receiving all network parameters in the form of
   link state packets, reduces to a mathematical problem. It involves
   solving a problem of Routing and Wavelength Assignment (RWA) for the
   new connection. The problem is simplified if there exists a
   wavelength converter at every hop in the optical network.

4.3.1 UNI Path Provisioning

   The real handshake between the client network and the optical
   backbone happens after performing the initial service & neighbor
   discovery. The continued operation of the system requires that
   client systems constantly register with the optical network. The
   registration procedure aids in verifying local port connectivity
   between the optical and client devices, and allows each device to
   learn the IP address of the other to establish a UNI control

Many Authors     Informational - Expires October 2001    Page 23 of 53             IP over Optical Networks: Summary of Issues    March 2001

   channel. The following procedures may be made available over the

   * Client Registration: This service allows a client to register its
   address(es) and user group identifier(s) with the optical network.
   * Client De-Registration: This service allows a client to withdraw
   its address(es) and user group identifier(s) from the optical

   The optical network primarily offers discrete capacity, high
   bandwidth connectivity in the form of lightpaths. The properties of
   the lightpaths are defined by the attributes specified during
   lightpath establishment or via acceptable modification requests. To
   ensure operation of the domain services model, the following actions
   need to be supported at the UNI so as to offer all essential
   lightpath services. The UNI signaling messages are structured as
   requests and responses [UNI00].

   1. Lightpath creation: This action allows a lightpath with the
      specified attributes to be created between a pair of termination
      points. Each lightpath is assigned a unique identifier by the
      optical network, called the lightpath ID. Lightpath creation may
      be subject to network-defined policies and security procedures.

   2. Lightpath deletion: This action, originating from either end,
      allows an existing lightpath (referenced by its ID) to be

   3. Lightpath modification: This action allows certain parameters of
      the lightpath (referenced by its ID) to be modified. Lightpath
      modification must not result in the loss of the original

   4. Lightpath status enquiry: This service allows the status of
      certain parameters of the lightpath (referenced by its ID) to be

   5. Notification: This action sends an autonomous message from the
      optical network to the client to indicate a change in the status
      of the lightpath (e.g., non-restorable lightpath failure).

   Thus, the above actions provision both edges of the overall
   connection, while NNI provisioning builds the central portion of the

4.3.2 Basic Path Setup Procedure for NNI

   The model for provisioning an optical path across optical sub-
   networks is as follows. A provisioning request may be received by a
   source OXC from the client border IP router (or from a management
   system), specifying the source and destination end-points. The
   source end-point is implicit and the destination endpoint is

Many Authors     Informational - Expires October 2001    Page 24 of 53             IP over Optical Networks: Summary of Issues    March 2001

   identified by the IP address. In both cases, the routing of an
   optical path inside the optical backbone is done as follows

   * The source OXC looks up its routing information corresponding to
   the specified destination IP address. If the destination is an OXC
   in the source sub-network, a path maybe directly computed to it. If
   the destination is an external address, the routing information will
   indicate a border OXC that would terminate the path in the source
   sub-network. A path is computed to the border OXC.

   * The computed path is signaled from the source to the destination
   OXC within the source sub-network. The destination OXC in the source
   sub-network determines if it is the ultimate destination of the
   path. if it is, then it completes the path set-up process.
   Otherwise, it determines the address of a border OXC in an adjacent
   sub-network that leads to the final destination. The path set-up is
   signaled to this OXC using NNI signaling. The next OXC then acts as
   the source for the path and the same steps are repeated.

   Thus, NNI provisioning involves looking up in the routing table
   computed by various schemes mentioned previously and performing path
   setup within an optical sub-network. Techniques for link
   provisioning within the optical sub-network depends upon whether the
   OXCs do or do not have wavelength conversion. Both these cases are
   discussed below. Network with Wavelength Converters

   In an optical network with wavelength conversion, channel allocation
   can be performed independently on different links along a route. A
   lightpath request from a source is received by the first-hop router.
   (The term router here denotes the routing entity in the optical
   nodes or OXCs). The first-hop router creates a lightpath setup
   message and sends it towards the destination of the lightpath where
   it is received by the last-hop router.  The lightpath setup is sent
   from the first-hop router on the default routed lightpath as the
   payload of a normal IP packet with router alert.  A router alert
   ensures that the packet is processed by every router in the path.  A
   channel is allocated for the lightpath on the downstream link at
   every node traversed by the setup.  The identifier of the allocated
   channel is written to the setup message.

   Note that the lightpath is established over the links traversed by
   the lightpath setup packet.  After a channel has been allocated at a
   node, the router communicates with the OLXC to reconfigure the OLXC
   to provide the desired connectivity.  After processing the setup,
   the destination (or the last-hop router) returns an acknowledgement
   to the source.  The acknowledgment indicates that a channel has been
   allocated on each hop of the lightpath.  It does not, however,
   confirm that the lightpath has been successfully implemented (or

Many Authors     Informational - Expires October 2001    Page 25 of 53             IP over Optical Networks: Summary of Issues    March 2001

   If no channel is available on some link, the setup fails, and a
   message is returned to the first-hop router informing it that the
   lightpath cannot be established.  If the setup fails, the first-hop
   router issues a release message to release resources allocated for
   the partially constructed lightpath.  Upon failure, the first-hop
   router may attempt to establish the lightpath over an alternate
   route, before giving up on satisfying the original user request.
   The first-hop router is obligated to establish the complete path.
   Only if it fails on all possible routes does it give a failure
   notification to the true source. Network without wavelength converters

   However, if wavelength converters are not available, then a common
   wavelength must be located on each link along the entire route,
   which requires some degree of coordination between different nodes
   in choosing an appropriate wavelength.

   Sections of a network that do not have wavelength converters are
   thus referred to as being wavelength continuous.  A common
   wavelength must be chosen on each link along a wavelength continuous
   section of a lightpath.  Whatever wavelength is chosen on the first
   link defines the wavelength allocation along the rest of the
   section.  A wavelength assignment algorithm must thus be used to
   choose this wavelength.  Wavelength selection within the network
   must be performed within a subset of client wavelengths.

   Optical non-linearity, chromatic dispersion, amplifier spontaneous
   emission and other factors together may limit the scalability of an
   all-optical network.  Routing in such networks may then have to take
   into account noise accumulation and dispersion to ensure that
   lightpaths are established with adequate signal qualities.  Hence,
   all routes become geographically constrained so that they will have
   adequate signal quality, and physical layer attributes can be
   ignored during routing and wavelength assignment.

   One approach to provisioning in a network without wavelength
   converters would be to propagate information throughout the network
   about the state of every wavelength on every link in the network.
   However, the state required and the overhead involved in maintaining
   this information would be excessive.  By not propagating individual
   wavelength availability information around the network, we must
   select a route and wavelength upon which to establish a new
   lightpath, without detailed knowledge of wavelength availability.

   A probe message can be used to determine available wavelengths along
   wavelength continuous routes.  A vector of the same size as the
   number of wavelengths on the first link is sent out to each node in
   turn along the desired route.  This vector represents wavelength
   availability, and is set at the first node to the wavelength
   availability on the first link along the wavelength continuous
   section.  If a wavelength on a link is not available or does not
   exist, then this is noted in the wavelength availability vector

Many Authors     Informational - Expires October 2001    Page 26 of 53             IP over Optical Networks: Summary of Issues    March 2001

   (i.e. the wavelength is set to being unavailable).  Once the entire
   route has been traversed, the wavelength availability vector will
   denote the wavelengths that are available on every link along the
   route.  The vector is returned to the source OXC, and a wavelength
   is chosen from amongst the available wavelengths using an arbitrary
   wavelength assignment scheme, such as first-fit.

   The construction of a bi-directional lightpath differs from the
   construction of a unidirectional lightpath above only in that upon
   receiving the setup request, the last-hop router returns the setup
   message using the reverse of the explicit route of the forward path.
   Both directions of a bi-directional lightpath share the same
   characteristics, i.e., set of nodes, bandwidth and restoration
   requirements.  For more general bi-directional connectivity, a user
   simply requests multiple individual lightpaths.

   A lightpath must be removed when it is no longer required.  To
   achieve this, an explicit release request is sent by the first-hop
   router along the lightpath route.  Each router in the path processes
   the release message by releasing the resources allocated to the
   lightpath, and removing the associated state.  It is worth noting
   that the release message is an optimization and need not be sent
   reliably, as if it is lost or never issued (e.g., due to customer
   premise equipment failure) the softness of the lightpath state
   ensures that it will eventually expire and be released.

4.4 Signaling protocols

   The OXCs in the optical network are responsible for switching
   streams based on the labels present. The MPLS architecture for IP
   networks defines protocols for associating labels to individual
   paths. The signaling protocols are used to provision such paths in
   the optical networks. There are two options for MPLS-based signaling
   protocols_Resource reSerVation Protocol Traffic Engineering
   Extensions (RSVP-TE) or Constraint Based  Routing Label Distribution
   Protocol (CR-LDP).

   There are some basic differences between the two protocols, but both
   essentially allow hop-by-hop signaling from a source to a
   destination node and in the reverse direction. Each of these
   protocols are capable of providing quality of service (QoS) and
   traffic engineering. Not all features present in these protocols are
   necessary to support lightpath provisioning. On the other hand,
   certain new features must be introduced in these protocols for
   lightpath provisioning, including support for bi-directional paths,
   support for switches without wavelength conversion, support for
   establishing shared backup paths, and fault tolerance.

   The connection request may include bandwidth parameters and channel
   type, reliability parameters, restoration options, setup and holding
   priorities for the path etc. On receipt of the request, the ingress
   node computes a suitable route for the requested path, following

Many Authors     Informational - Expires October 2001    Page 27 of 53             IP over Optical Networks: Summary of Issues    March 2001

   applicable policies and constraints. Once the route has been
   computed, the ingress node invokes RSVP-TE / CR-LDP to set up the

4.4.1 CR-LDP Extensions for Path Setup

   Label Distribution Protocol (LDP) is defined for distribution of
   labels inside one MPLS domain.  CR-LDP is the constraint-based
   extension of LDP. One of the most important services that may be
   offered using MPLS in general and CR-LDP in particular is support
   for constraint-based routing of lightpaths across the routed
   network.  Constraint-based routing offers the opportunity to extend
   the information used to setup paths beyond what is available for the
   routing protocol.  For instance, an LSP can be setup based on
   explicit route constraints, QoS constraints, and other constraints.
   Constraint-based routing (CR) is a mechanism used to meet traffic-
   engineering requirements that have been proposed.

   A Label Request message is used by an upstream LSR to request a
   label binding from the downstream LSR for a specified forwarding
   equivalency class (FEC) and CR-LSP.  In optical networks, a Label
   Request message may be used by the upstream OXC to request a port
   (and wavelength) assignment from the downstream OXC for the
   lightpath being established.  Using downstream-on-demand and ordered
   control mode, a Label Request message is initially generated at the
   ingress OXC and is propagated to the egress OXC.  Also, a protocol
   is required to determine the port mappings.

   To incorporate the above mentioned constraints, the following
   extensions to current version of CR-LDP have been proposed:

   * Inclusion of Signaling Port ID
   * Signaling Optical Switched Path Identifier
   * Signaling the two end points of the path being set up
* Signaling requirements for both span and path protection
   * Recording the precise route of the path being established

4.4.2 RSVP-TE Extensions for Path Setup

   Resource reSerVation Protocol with Traffic Engineering extensions
   (RSVP-TE) is a unicast and multicast signaling protocol designed to
   install and maintain reservation state information at each routing
   engine along a path [Luciani00]. The key characteristics of RSVP are
   that it is simplex, receiver-oriented and soft.  It makes
   reservations for unidirectional data flows. The receiver of a data
   flow generally initiates and maintains the resource reservation used
   for that flow. It maintains "soft" state in routing engines. The
   "path" messages are propagated from the source towards potential
   recipients. The receivers interested in communicating with the
   source send the "Resv" messages.

   The following extensions to RSVP-TE have been proposed to support
   path setup :

Many Authors     Informational - Expires October 2001    Page 28 of 53             IP over Optical Networks: Summary of Issues    March 2001

   - Reduction of lightpath establishment latency
   - Establishment of bi-directional lightpaths
   - Fast failure notification
   - Bundling of notifications

4.5 Stream Control Transmission Protocol (SCTP)

   There is further discussion on which transport layer protocol to use
   for the signaling messages encapsulated in CR-LDP / RSVP-TE. The
   requirements of the transport layer is to provide a reliable channel
   for transmitting information (both data / control). The IETF Sigtran
   workgroup came up with designs for a new protocol called SCTP, which
   could be used in lieu of TCP, and is designed especially for
   signaling purposes[SCTP]. Like TCP it runs directly over IP but
   offers some signaling tailored features:

   * Datagram-oriented (TCP is byte-stream-oriented)
   * Fragmentation and re-assembly for large datagrams
   * Multiplexing of several small datagrams into one IP packet
   * Support of multi-homing (an SCTP endpoint may have several IP
   * Path monitoring by periodic heartbeat messages
   * Retransmission over a different path, if available
   * Selective acknowledgements
   * Fast retransmit
   * 32 bit checksum over the whole payload
   * Avoids IP fragmentation due to MTU discovery
   * Protection against SYN attacks and blind masquerade attacks

   SCTP is far from complete and is quite immature compared to its
   nemesis TCP. Current implementation of the signaling protocol shall
   thereby use TCP for its reliable transmissions.

4.6 Configuration Control using GSMP

   In a general mesh network where the OXCs do not participate in
   topology distribution protocols, General Switch Management Protocol
   (GSMP) can be used to communicate crossconnect information.  This
   ensures that the OXCs on the lightpath maintain appropriate
   databases.  The first hop router having complete knowledge of LP, L2
   and L3 topology acts as the "controller" to the OXCs in the

   GSMP is a master-slave protocol [GSMP].  The controller issues
   request messages to the switch.  Each request message indicates
   whether a response is required from the switch (and contains a
   transaction identifier to enable the response to be associated with
   the request).  The switch replies with a response message indicating
   either a successful result or a failure. The switch may also

Many Authors     Informational - Expires October 2001    Page 29 of 53             IP over Optical Networks: Summary of Issues    March 2001

   generate asynchronous Event messages to inform the controller of
   asynchronous events.

4.7 Resource Discovery Using NHRP

   The Next Hop Resolution Protocol (NHRP) allows a source station (a
   host or router), wishing to communicate over a Non-Broadcast, Multi-
   Access (NBMA) subnetwork, to determine the internetworking layer
   addresses and NBMA addresses of suitable "NBMA next hops" toward a
   destination station [NHRP].  A subnetwork can be non-broadcast
   either because it technically doesn't support broadcasting (e.g., an
   X.25 subnetwork) or because broadcasting is not feasible for one
   reason or another (e.g., a Switched Multi-megabit Data Service
   multicast group or an extended Ethernet would be too large).

   If the destination is connected to the NBMA subnetwork, then the
   NBMA next hop is the destination station itself.  Otherwise, the
   NBMA next hop is the egress router from the NBMA subnetwork that is
   "nearest" to the destination station.  NHRP is intended for use in a
   multiprotocol internetworking layer environment over NBMA

   In short, NHRP may be applied as a resource discovery to find the
   egress OXC in an optical network. To request this information, the
   existing packet format for the NHRP Resolution Request would be used
   with a new extension in the form of a modified Forward Transit NHS
   Extension.  The extension would include enough information at each
   hop (including the source and destination)

   * to uniquely identify which wavelength.
   * to use when bypassing each routed/forwarded hop and which port
   that the request was received on.

   Essentially a shortcut is setup from ingress to egress using this

5.  Optical Network Management

   The management functionality in all-optical networks is still in the
   rudimentary phase.  Management in a system refers to set of
   functionalities like performance monitoring, link initialization and
   other network diagnostics to verify safe and continued operation of
   the network.  The wavelengths in the optical domain will require
   routing, add/drop, and protection functions, which can only be
   achieved through the implementation of network-wide management and
   monitoring capabilities. Current proposals for link initialization
   and performance monitoring are summarized below.

5.1 Link Initialization

   The links between OXCs will carry a number of user bearer channels
   and possibly one or more associated control channels.  This section

Many Authors     Informational - Expires October 2001    Page 30 of 53             IP over Optical Networks: Summary of Issues    March 2001

   describes a link management protocol (LMP) that can be run between
   neighboring OXCs and can be used for both link provisioning and
   fault isolation.  A unique feature of LMP is that it is able to
   isolate faults independent of the encoding scheme used for the
   bearer channels.  LMP will be used to maintain control channel
   connectivity, verify bearer channel connectivity, and isolate link,
   fiber, or channel failures within the optical network.

5.1.1 Control Channel Management

   For LMP, it is essential that a control channel is always available
   for a link, and in the event of a control channel failure, an
   alternate (or backup) control channel should be made available to
   reestablish communication with the neighboring OXC.  If the control
   channel cannot be established on the primary (fiber, wavelength)
   pair, then a backup control channel should be tried.  The control
   channel of a link can be either explicitly configured or
   automatically selected. The control channel can be used to exchange:

   a) MPLS control-plane information such as link provisioning and
   fault isolation information (implemented using a messaging protocol
   such as LMP, proposed in this section),

   b) path management and label distribution information (implemented
   using a signaling protocol such as RSVP-TE or CR-LDP), and

   c) topology and state distribution information (implemented using
   traffic engineering extended protocols such as OSPF and IS-IS).

Once a control channel is configured between two OXCs, a Hello protocol
can be used to establish and maintain connectivity between the OXCs and
to detect link failures.  The Hello protocol of LMP is intended to be a
lightweight keep-alive mechanism that will react to control channel
failures rapidly.  A protocol similar to the HDLC frame exchange is
used to continue the handshake. [Lang00]

5.1.2 Verifying Link Connectivity

   In this section, we describe the mechanism used to verify the
   physical connectivity of the bearer channels.  This will be done
   initially when a link is established, and subsequently, on a
   periodic basis for all free bearer channels on the link.  To ensure
   proper verification of bearer channel connectivity, it is required
   that until the bearer channels are allocated, they should be opaque.

   As part of the link verification protocol, the control channel is
   first verified, and connectivity maintained, using the Hello
   protocol discussed in Section 5.1.1.  Once the control channel has
   been established between the two OXCs, bearer channel connectivity
   is verified by exchanging Ping-type Test messages over all of the
   bearer channels specified in the link.  It should be noted that all
   messages except for the Test message are exchanged over the control
   channel and that Hello messages continue to be exchanged over the

Many Authors     Informational - Expires October 2001    Page 31 of 53             IP over Optical Networks: Summary of Issues    March 2001

   control channel during the bearer channel verification process.  The
   Test message is sent over the bearer channel that is being verified.
   Bearer channels are tested in the transmit direction as they are
   unidirectional, and as such, it may be possible for both OXCs to
   exchange the Test messages simultaneously [Lang00].

5.1.3 Fault Localization

   Fault detection is delegated to the physical layer (i.e., loss of
   light or optical monitoring of the data) instead of the layer 2 or
   layer 3.  Hence, detection should be handled at the layer closest to
   the failure; for optical networks, this is the physical (optical)
   layer.  One measure of fault detection at the physical layer is
   simply detecting loss of light (LOL).  Other techniques for
   monitoring optical signals are still being developed.

   A link connecting two OXCs consists of a control channel and a
   number of bearer channels.  If bearer channels fail between two
   OXCs, a mechanism should be used to rapidly locate the failure so
   that appropriate protection/restoration mechanisms can be initiated.
   This is discussed further in Section 6.10.

5.2 Optical Performance Monitoring (OPM)

   Current-generation WDM networks are monitored, managed, and
   protected within the digital domain, using SONET and its associated
   support systems.  However, to leverage the full potential of
   wavelength-based networking, the provisioning, switching, management
   and monitoring functions have to move from the digital to the
   optical domain.

   The information generated by the performance monitoring operation
   can be used to ensure safe operation of the optical network.  In
   addition to verifying the service level provided by the network to
   the user, performance monitoring is also necessary to ensure that
   the users of the network comply with the requirements that were
   negotiated between them and the network operator.  For example, one
   function may be to monitor the wavelength and power levels of
   signals being input to the network to ensure that they meet the
   requirements imposed by the network.  Current performance monitoring
   in optical networks requires termination of a channel at an optical-
   electrical-optical conversion point to detect bits related to BER of
   the payload or frame (e.g., SONET LTE monitoring).  However, while
   these bits indicate if errors have occurred, they do not supply
   channel-performance data.  This makes it very difficult to assess
   the actual cause of the degraded performance.

   Fast and accurate determination of the various performance measures
   of a wavelength channel implies that measurements have to be done
   while leaving it in optical format.  One possible way of achieving
   this is by tapping a portion of the optical power from the main
   channel using a low loss tap of about 1%.  In this scenario, the
   most basic form of monitoring will utilize a power-averaging

Many Authors     Informational - Expires October 2001    Page 32 of 53             IP over Optical Networks: Summary of Issues    March 2001

   receiver to detect loss of signal at the optical power tap point.
   Existing WDM systems use optical time-domain reflectometers to
   measure the parameters of the optical links.

   Another problem lies in determining the threshold values for the
   various parameters at which alarms should be declared.  Very often
   these values depend on the bit rate on the channel and should
   ideally be set depending on the bit rate.  In addition, since a
   signal is not terminated at an intermediate node, if a wavelength
   fails, all nodes along the path downstream of the failed wavelength
   could trigger an alarm.  This can lead to a large number of alarms
   for a single failure, and makes it somewhat more complicated to
   determine the cause of the alarm (alarm correlation).  A list of
   such optical parameters to be monitored periodically have been
   proposed .  Optical cross talk, dispersion, and insertion loss are
   key parameters to name a few.

   Care needs to be taken in exchanging these performance parameters.
   The vast majority of existing telecommunication networks use framing
   and data formatting overhead as the means to communicate between
   network elements and management systems.  It is worth mentioning
   that while the signaling is used to communicate all monitoring
   results, the monitoring itself is done on the actual data channel,
   or some range of bandwidth around the channel.  Therefore, all
   network elements must be guaranteed to pass this bandwidth in order
   for monitoring to happen at any point in the network.

   One of the options being considered for transmitting the information
   is the framing and formatting bits of the SONET interface.  But, it
   hampers transparency.  It is clear that truly transparent and open
   photonic networks can only be built with transparent signaling
   support.  The MPLS control plane architecture suggested can be
   extended beyond simple bandwidth provisioning to include optical
   performance monitoring.

6.  Fault restoration in Optical networks

   Telecom networks have traditionally been designed with rapid fault
   detection, rapid fault isolation and recovery. With the introduction
   of IP and WDM in these networks, these features need to be provided
   in the IP and WDM layers also. Automated establishment and
   restoration of end-to-end paths in such networks requires
   standardized signaling, routing, and restoration mechanisms.

   Survivability techniques are being made available at multiple layers
   in the network. Each layer has certain recovery features and one
   needs to understand the impact of interaction between these layers.
   The central idea is that the lower layers can provide fast
   protection while the higher layers can provide intelligent
   restoration. It is desirable to avoid too many layers with
   functional overlaps. The IP over MPLS scheme can provide a smooth
   mapping of IP into WDM layer, thus bringing about a integrated

Many Authors     Informational - Expires October 2001    Page 33 of 53             IP over Optical Networks: Summary of Issues    March 2001

   protection/restoration capability, which is coordinated at both the

6.1 Layering

   Clearly the layering and architecture for service restoration is a
   major component for IP to optical internetworking.  This section
   summarizes some schemes, which aid in optical protection at the
   lower layers, SONET and Optical.

6.1.1 SONET Layer Protection

   The SONET standards specify an end-to-end two-way availability
   objective of 99.98% for inter office applications (0.02%
   unavailability or 105 minutes/year maximum down time) and 99.99 %
   for loop transport between the central office and the customer's
   premises.  To conform to these standards, failure/restoration times
   have to be short.  For both, point-to-point and ring systems,
   automatic protection switching (APS) is used, the network performs
   failure restoration in tens of milliseconds (approximately 50

   Architectures composed of SONET add-drop multiplexers (ADMs)
   interconnected in a ring provide a method of APS that allows
   facilities to be shared while protecting traffic within an
   acceptable restoration time.  There are 2 possible ring

   * UPSR:  Unidirectional path switched ring architecture is a 1+1
   single-ended, unidirectional, SONET path layer dedicated protection
   architecture.  The nodes are connected in a ring configuration with
   one fiber pair connecting adjacent nodes.  One fiber on a link is
   used as the working and other is protection.  They operate in
   opposite directions.  So there is a working ring in one direction
   and a protection ring in the opposite direction. The optical signal
   is sent on both outgoing fibers.  The receiver compares the 2
   signals and selects the better of the two based on signal quality.
   This transmission on both fibers is called 1+1 protection.

   * BLSR: In bi-directional line switched ring architecture, a bi-
   directional connection between 2 nodes traverses the same
   intermediate nodes and links in opposite directions.  In contrast to
   the UPSR, where the protection capacity is dedicated, the BLSR
   shares protection capacity among all spans on the ring.  They are
   also called Shared Protection ring (SPRing) architectures.  In BLSR
   architecture, switching is coordinated by the nodes on either side
   of a failure in the ring, so that a signaling protocol is required
   to perform a line switch and to restore the network.  These
   architectures are more difficult to operate than UPSRs where no
   signaling is required.

   The disadvantage of the SONET layer is that it is usually restricted
   to ring type architectures. These are extremely bandwidth

Many Authors     Informational - Expires October 2001    Page 34 of 53             IP over Optical Networks: Summary of Issues    March 2001

   inefficient. The bandwidth along each segment of the ring ahs to be
   equal to the bandwidth of the busiest segment. It does not
   incorporate traffic priorities. It cannot detect higher layer

6.1.2 Optical Layer Protection

   The concept of SONET ring architectures can be extended to WDM self-
   healing optical rings (SHRs). As in SONET, WDM SHRs can be either
   path switched or line switched.  In recent testbed experiments,
   lithium niobate protection switches have been used to achieve 10-
   microsecond restoration times in WDM Shared protection Rings.
   Multi-wavelength systems add extra complexity to the restoration
   problem.  Under these circumstances, simple ring architecture may
   not suffice.  Hence, arbitrary mesh architectures become important.
   Usually, for such architectures, restoration is usually performed
   after evaluation at the higher layer.  But this takes a lot of time. Point-to-Point Mechanisms

   In case of point to point, one can provide 1+1, 1:1 or 1:N
   protection. In 1+1, the same information is sent through 2 paths and
   the better one is selected at the receiver.  The receiver makes a
   blind switch when the selected (working) path's signal is poor.
   Unlike SONET, a continuous comparison of 2 signals is not done in
   the optical layer.  In 1:1 protection, signal is sent only on the
   working path while a protection path is also set but it can be used
   for lower priority signals that are preempted if the working path
   fails.  A signaling channel is required to inform the transmitter to
   switch path if the receiever detects a failure in the working path.
   A generalization of 1:1 protection is 1:N protection in which one
   protection fiber is shared among N working fibers.  It is usually
   applied for equipment protection [JOHNSON99]. Ring systems [MANCHESTER99]

   Ring mechanisms are broadly classified into: Dedicated linear
   protection and Shared protection rings.

   Dedicated linear protection is an extension of 1+1 protection
   applied to a ring. It is effectively a path protection mechanism.
   Entire path from source to the destination node is protected.  Since
   each channel constitutes a separate path, it is also called Optical
   Channel Subnetwork Connection Protection (OCh-SNCP).  From each
   node, the working and protection signals are transmitted in opposite
   directions along the 2 fibers.  At the receiving end, if the working
   path signal is weak, the receiver switches to the protection path
   signal. Bidirectional traffic between two nodes, travels along the
   same direction of the ring. The ring through put is restricted to
   that of a single fiber. This is usually applied to hubbed transport
   scenarios, near access rings. For other types of connections, it is
   very expensive [GERSTEL00].

Many Authors     Informational - Expires October 2001    Page 35 of 53             IP over Optical Networks: Summary of Issues    March 2001

   Shared protection rings (SPRings) protect a link rather than a path.
   This is conceptually similar to the SONET BLSR architecture.
   Bidirectional traffic between 2 nodes travels along opposite
   directions and between the same intermediate nodes. The wavelength
   used in one part of the network can be re-used in another non-
   overlapping part of the ring also. Thus this permits reusing of
   wavelengths. Moreover, unless there is a fault, only half the
   capacity is used at any time. So the protection bandwidth can be
   used by a some other traffic. These are also easier to setup and are
   the more common ring protection mechanisms.

   In a 2-fiber SPRings case with two counter-rotating rings, half the
   wavelengths in each fiber are reserved for protection. If a link
   failure occurs, the OADM adjacent to the link failure bridges its
   outgoing channels in a direction opposite to that of the failure and
   selects its incoming working channels from the incoming protection
   channels in the direction away from the failure. This is called ring

   In a 4-fiber SPRing, two fibers each are allocated for working and
   protection. The operation is similar to that of the 2-fiber SPRing.
   However, this system can allow span switching in addition to ring
   switching. Span switching means that if only the working fiber in a
   link fails, the traffic can use the protection fiber in the same
   span. In case of 2-fiber systems, it will have to take the longer
   path around the ring.

   The 2 fiber and 4 fiber SPRing architectures have signaling
   complexities associated with them, because these rings perform
   switching at intermediate nodes.

   Sometimes the need arises to protect against isolated optoelectronic
   failures that will affect only a single optical channel at a time.
   Thus, we need a protection architecture that performs channel level
   switching based on channel level indications. The Optical
   Multiplexed Section (OMS) SPRings, discussed so far,  switch a group
   of channels within the fiber. The Optical Channel (OCh) SPRings are
   capable of protecting OChs independent of one another based on OCh
   level failure indication. An N-Channel OADM based 4-fiber ring can
   support upto N independent OCh SPRings.

   SPRing architectures are referred to as Bidirectional line switched
   ring (BLSR) architectures. OCh SPRings are referred to as
   Bidirectional Wavelength Line Switched Ring technology, (BWLSR).
   ITU-T draft recommendation G.872 describes a transoceanic switching
   protocol for 4-fiber OMS SPRings. This protocols requires that after
   a span switching a path should not traverse any span more than once.
   When ring switching occurs, this may not be true.  This protocol is
   essential in long-distance undersea transmissions to avoid
   unnecessary delay. Mesh Architectures

Many Authors     Informational - Expires October 2001    Page 36 of 53             IP over Optical Networks: Summary of Issues    March 2001

   Along a single fiber, any two connections cannot use the same
   wavelength. The whole problem of routing in a WDM network with
   proper allocation of a minimum number of wavelengths is called the
   routing and wavelength assignment (RWA) problem. It is found that in
   arbitrary mesh architectures, where the connectivity of each node is
   high, the number of wavelengths required greatly decreases. This is
   the advantage of having a mesh architecture. Moreover addition of
   new nodes and removing existing nodes becomes very easy.  However,
   with mesh architectures, finding an alternate path every time a
   failure occurs would be a time consuming process. Hence, an
   automatic protection switching mechanism, like that for the rings,
   is required. Three alternatives are briefly discussed here:

   Ring Covers

   The whole mesh configuration is divided into smaller cycles in such
   a way that each edge comes under atleast one cycle.  Along each
   cycle, a protection fiber is laid.  It may so happen that certain
   edges come under more than one cycle.  In these edges, more than one
   protection fiber will have to be laid.  Hence, the idea is to divide
   the graph into cycles in such a way that this redundancy is
   minimized [WU].  However, in most cases the redundancy required is
   more than 100%.

   Protection Cycles [ELLINAS]

   This method reduces the redundancy to exactly 100%.  The networks
   considered have a pair of bi-directional working and protection
   fibers.  Fault protection against link failures is possible in all
   networks that are modeled by 2-edge connected digraphs.  The idea is
   to find a family of directed cycles so that all protection fibers
   are used exactly once and in any directed cycle a pair of protection
   fibers is not used in both directions unless they belong to a

   For planar graphs, such directed cycles are along the faces of the
   graph.  For non-planar graphs, the directed cycles are taken along
   the orientable cycle double covers, which are conjectured to exist
   for every digraph.  Heuristic algorithms exist for obtaining cyclic
   double covers for every non-planar graph.

   Thus, the main advantage of optical layer mechanisms is the fast
   restoration.  It also has the capacity of large switching
   granularity in the sense that it can restore a large number of
   higher layer flows by a single switching.

   The disadvantage is that it cannot carry traffic engineering
   capabilities. It can only operate at the lightpath level and cannot
   differentiate between different data types. Also the switching speed
   comes into play only if all the nodes which can detect a fault have
   switching capabilities. Building such an architecture is extremely

Many Authors     Informational - Expires October 2001    Page 37 of 53             IP over Optical Networks: Summary of Issues    March 2001

6.1.3 IP Layer Protection

   The IP layer plays a major role in the IP network infrastructure.
   There are some advantages of having survivability mechanism in this
   layer. It can find optimal routes in the system. It provides a finer
   granularity at which protection can be done, enabling the system to
   have priorities. It also possesses load balancing capabilities.

   However the recovery operations are very slow. It also cannot detect
   physical layer faults.

6.1.4 MPLS Layer Protection

   The rerouting capability of the optical layer can be expanded and
   newer bandwidth efficient protection can be facilitated if there is
   some controlled coordination between the optical layer and a higher
   layer that has a signaling mechanism.

   Similarly, the optical layer which cannot detect faults in the
   router or switching node, could learn of the faults if the higher
   layer communicated this to it. Then, the optical layer can initiate
   protection at the lower layer.

   Fast signaling is the main advantage of the MPLS layer in
   protection. Since MPLS binds packets to a route (or path) via the
   labels, it is imperative that MPLS be able to provide protection and
   restoration of traffic.  In fact, a protection priority could be
   used as a differentiating mechanism for premium services that
   require high reliability. The MPLs layer has visibility into the
   lower layer. The lower layer can inform this layer about faults by a
   liveness message, basically signaling.

   When we talk of the IP/MPLS over WDM architecture, we may seal off
   SONET APS protection from the discussion and the WDM optical layer
   can provide the same kind of restoration capabilities at the lower
   layer.  Thus there has to be interaction only between the MPLS and
   optical layer and not with the SONET layer.

   The following sections present a summary of techniques being
   proposed for implementing survivability in the MPLS layer. These
   include signaling requirements, architectural considerations and
   timing considerations.

6.2 Failure detection [OWENS00]

   Loss of Signal (LOS) is a lower layer impairment that arises when a
   signal is not detected at an interface, for example, a SONET LOS.
   In this case, enough time should be provided for the lower layer to
   detect LOS and take corrective action.

   A Link Failure (LF) is declared when the link probing mechanism
   fails.  An example of a probing mechanism is the Liveness message

Many Authors     Informational - Expires October 2001    Page 38 of 53             IP over Optical Networks: Summary of Issues    March 2001

   that is exchanged periodically along the working path between peer
   LSRs.  A LF is detected when a certain number k of consecutive
   Liveness messages are either not received from a peer LSR or are
   received in error.

   A Loss of Packets (LOP) occurs when there is excessive discarding of
   packets at an LSR interface, either due to label mismatches or due
   to time-to-live (TTL) errors.  LOP due to label mismatch may be
   detected simply by counting the number of packets dropped at an
   interface because an incoming label did not match any label in the
   forwarding table.  Likewise, LOP due to invalid TTL may be detected
   by counting the number of packets that were dropped at an interface
   because the TTL decrements to zero.

6.3 Failure Notification [OWENS00]

   Protection switching relies on rapid notification of failures.  Once
   a failure is detected, the node that detected the failure must send
   out a notification of the failure by transmitting a failure
   indication signal (FIS) to those of its upstream LSRs that were
   sending traffic on the working path that is affected by the failure.
   This notification is relayed hop-by-hop by each subsequent LSR to
   its upstream neighbor, until it eventually reaches a PSL.

   The PSL is the LSR that originates both the working and protection
   paths, and the LSR that is the termination point of both the FIS and
   the failure recovery signal (FRS).  Note that the PSL need not be
   the origin of the working LSP.

   The PML is the LSR that terminates both the working path and its
   corresponding protection path.  Depending on whether or not the PML
   is a destination, it may either pass the traffic on to the higher
   layers or may merge the incoming traffic on to a single outgoing
   LSR.  Thus, the PML need not be the destination of the working LSP.

   An LSR that is neither a PSL nor a PML is called an intermediate
   LSR.  The intermediate LSR could be either on the working or the
   protection path, and could be a merging LSR (without being a PML).

6.3.1 Reverse Notification Tree (RNT)

   Since the LSPs are unidirectional entities and protection requires
   the notification of failures, the failure indication and the failure
   recovery notification both need to travel along a reverse path of
   the working path from the point of failure back to the PSL(s).  When
   label merging occurs, the working paths converge to form a
   multipoint-to-point tree, with the PSLs as the leaves and the PML as
   the root.  The reverse notification tree is a point-multipoint tree
   rooted at the PML along which the FIS and the FRS travel, and which
   is an exact mirror image of the converged working paths.

   The establishment of the protection path requires identification of
   the working path, and hence the protection domain.  In most cases,

Many Authors     Informational - Expires October 2001    Page 39 of 53             IP over Optical Networks: Summary of Issues    March 2001

   the working path and its corresponding protection path would be
   specified via administrative configuration, and would be established
   between the two nodes at the boundaries of the protection domain
   (the PSL and PML) via explicit (or source) routing using LDP, RSVP,
   signaling (alternatively, using manual configuration).

   The RNT is used for propagating the FIS and the FRS, and can be
   created very easily by a simple extension to the LSP setup process.
   During the establishment of the working path, the signaling message
   carries with it the identity (address) of the upstream node that
   sent it.  Each LSR along the path simply remembers the identity of
   its immediately prior upstream neighbor on each incoming link.  The
   node then creates an inverse crossconnect table that for each
   protected outgoing LSP maintains a list of the incoming LSPs that
   merge into that outgoing LSP, together with the identity of the
   upstream node that each incoming LSP comes from.  Upon receiving an
   FIS, an LSR extracts the labels contained in it (which are the
   labels of the protected LSPs that use the outgoing link that the FIS
   was received on) consults its inverse crossconnect table to
   determine the identity of the upstream nodes that the protected LSPs
   come from, and creates and transmits an FIS to each of them.

6.4 Protection options [SHARMA00]

   When using the MPLS layer for providing survivability, we can have
   different options, just like in any other layer. Each has its own
   advantages depending on requirements.

6.4.1 Dynamic Protection

   These protection mechanisms dynamically create protection paths for
   restoring traffic, based upon failure information, bandwidth
   allocation and optimized reroute assignment.  Thus, upon detecting
   failure, the LSPs crossing a failed link or LSR are broken at the
   point of failure and reestablished using signaling.  These methods
   may increase resource utilization because capacity or bandwidth is
   not reserved beforehand and because it is available for use by other
   (possibly lower priority) traffic, when the protection path does not
   require this capacity.  They may, however, require longer
   restoration times, since it is difficult to instantaneously switch
   over to a protection entity, following the detection of a failure.

6.4.2 Pre-negotiated Protection

   These are dedicated protection mechanisms, where for each working
   path there exists a pre-established protection path, which is node
   and link disjoint with the primary/working path, but may merge with
   other working paths that are disjoint with the primary.  The
   resources (bandwidth, buffers, processing) on the backup entity may
   be either pre-determined and reserved beforehand (and unused), or
   may be allocated dynamically by displacing lower priority traffic
   that was allowed to use them in the absence of a failure on the
   working path.

Many Authors     Informational - Expires October 2001    Page 40 of 53             IP over Optical Networks: Summary of Issues    March 2001

6.4.3 End-to-end Repair

   In end-to-end repair, upon detection of a failure on the primary
   path, an alternate or backup path is re-established starting at the
   source.  Thus, protection is always activated on an end-to-end
   basis, irrespective of where along a working path a failure occurs.
   This method might be slower than the local repair method discussed
   below, since the failure information has to propagate all the way
   back to the source before a protection switch is accomplished.

6.4.4 Local Repair

   In local repair, upon detecting a failure on the primary path, an
   alternate path is re-established starting from the point of failure.
   Thus protection is activated by each LSR along the path in a
   distributed fashion on an as-needed basis.  While this method has an
   advantage in terms of the time taken to react to a fault, it
   introduces the complication that every LSR along a working path may
   now have to function as a protection switch LSR (PSL).

6.4.5 Link Protection

   The intent is to protect against a single link failure.  For
   example, the protection path may be configured to route around
   certain links deemed to be potentially risky.  If static
   configuration is used, several protection paths may be pre-
   configured, depending on the specific link failure that each
   protects against.  Alternatively, if dynamic configuration is used,
   upon the occurrence of a failure on the working path, the protection
   path is rebuilt such that it detours around the failed link.

6.4.6 Path Protection

   The intention is to protect against any link or node failure on the
   entire working path.  This has the advantage of protecting against
   multiple simultaneous failures on the working path, and possibly
   being more bandwidth efficient than link protection.

6.4.7 Revertive Mode

   In the revertive mode of operation, the traffic is automatically
   restored to the working path once repairs have been affected, and
   the PSL(s) are informed that the working path is up.  This is
   useful, since once traffic is switched to the protection path it is,
   in general, unprotected.  Thus, revertive switching ensures that the
   traffic remains unprotected only for the shortest amount of time.
   This could have the disadvantage, however, of producing oscillation
   of traffic in the network, by altering link loads.

6.4.8 Non-revertive Mode

Many Authors     Informational - Expires October 2001    Page 41 of 53             IP over Optical Networks: Summary of Issues    March 2001

   In the non-revertive mode of operation, traffic once switched to the
   protection path is not automatically restored to the working path,
   even if the working path is repaired.  Thus, some form of
   administrative intervention is needed to invoke the restoration
   action.  The advantage is that only one protection switch is needed
   per working path.  A disadvantage is that the protection path
   remains unprotected until administrative action (or manual
   reconfiguration) is taken to either restore the traffic back to the
   working path or to configure a backup path for the protection path.

6.4.9 1+1 Protection

   In 1+1 protection, the resources (bandwidth, buffers, processing
   capacity) on the backup path are fully reserved to carry only
   working traffic. This bandwidth is used to transmit an exact copy of
   the working traffic, with a selection between the traffic on the
   working and protection paths being made at the protection merge LSR

6.4.10 1:1, 1:n, and n:m  Protection

   In 1:1 protection, the resources (bandwidth, buffers, and processing
   capacity) allocated on the protection path are fully available to
   preemptable low priority traffic when the protection path is not in
   use by the working traffic.  In other words, in 1:1 protection, the
   working traffic normally travels only on the working path, and is
   switched to the protection path only when the working entity is
   unavailable.  Once the protection switch is initiated, all the low
   priority traffic being carried on the protection path is discarded
   to free resources for the working traffic.  This method affords a
   way to make efficient use of the backup path, since resources on the
   protection path are not locked and can be used by other traffic when
   the backup path is not being used to carry working traffic.

   Similarly, in 1:n protection, up to n working paths are protected
   using only one backup path, while in m:n protection, up to n working
   paths are protected using up to m backup paths.

6.4.11 Recovery Granularity

   Another dimension of recovery considers the amount of traffic
   requiring protection.  This may range from a fraction of a path to a
   bundle of paths. Selective Traffic Recovery

   This option allows for the protection of a fraction of traffic
   within the same path.  The portion of the traffic on an individual
   path that requires protection is called a protected traffic portion
   (PTP).  A single path may carry different classes of traffic, with
   different protection requirements.  The protected portion of this
   traffic may be identified by its class, as for example, via the EXP

Many Authors     Informational - Expires October 2001    Page 42 of 53             IP over Optical Networks: Summary of Issues    March 2001

   bits in the MPLS shim header or via the cell loss priority (CLP) bit
   in the ATM header. Bundling

   Bundling is a technique used to group multiple working paths
   together in order to recover them simultaneously.  The logical
   bundling of multiple working paths requiring protection, each of
   which is routed identically between a PSL and a PML, is called a
   protected path group (PPG).  When a fault occurs on the working path
   carrying the PPG, the PPG as a whole can be protected either by
   being switched to a bypass tunnel or by being switched to a recovery

6.5 Signaling Requirements related to restoration [SAHA00]

   Signaling mechanisms for optical networks should be tailored to the
   needs of optical networking.

   Some signaling requirements directed towards restoration in optical
   networks are:

   1. Signaling mechanisms should minimize the need for manual
   configuration of relevant information, such as local topology.

   2. Lightpaths are fixed bandwidth pipes.  There is no need to convey
   complex traffic characterization or other QoS parameters in
   signaling messages.  On the other hand, new service related
   parameters such as restoration priority, protection scheme desired,
   etc., may have to be conveyed.

   3. Signaling for path establishment should be quick and reliable.
   It is especially important to minimize signaling delays during

   4. Lightpaths are typically bi-directional.  Both directions of the
   path should generally be established along the same physical route.

   5. OXCs are subject to high reliability requirements.  A transient
   failure that does not affect the data plane of the established paths
   should not result in these paths being torn down.

   6. Restoration schemes in mesh networks rely on sharing backup path
   among many primary paths.  Signaling protocols should support this

   7. The interaction between path establishment signaling and
   automatic protection schemes should be well defined to avoid false
   restoration attempts during path set-up or tear down.

6.6 Pre-computed, Priority-Based Restoration

Many Authors     Informational - Expires October 2001    Page 43 of 53             IP over Optical Networks: Summary of Issues    March 2001

   The previous sections have discussed so far, the different
   requirements for restoration in optical networks and has seen a
   number of methods possible. This section tries to summarize that and
   brings together the best of the options.

   A simple restoration strategy is possible for rings. But the mesh
   architectures promise flexible use of bandwidth. Hence the goal is
   to find a solution to provide fast alternate paths in a mesh based
   optical network.

   The optical network will be surrounded by edge switches, which are
   the entry and exit points for wavelength paths. Hence, these edge
   switches will compute the path through the optical network from
   source to destination. They shall also have the task of having an
   alternate path ready, incase of faults in the network. Each of the
   switches inside the network are called core switches. In case of a
   fault, these switches should propagate the information back to the
   entry switch.

   If the edge switch tries to obtain an alternate path on the spur of
   the moment, it will be time consuming. Hence a pre-computation
   strategy would work better.

   Link based restoration methods re-route disrupted traffic around the
   failed link. This mechanism saves some signaling time, but it
   requires alternate paths from each node. Computation is tougher.
   Also restoration would be tougher in case of a node failure. So a
   path based re-routing is sought, which replaces the whole path
   between two end points.

   The selection of the protection path should be such that, the links
   along working and protection path should be mutually exclusive.
   Also, in case of any single failure, the total bandwidth on any of
   the diverted links should not exceed its capacity. Algorithms for
   alternate path finding are discussed in [Bell-Labs].

   The next thing is to incorporate priority inside the procedure. When
   an edge swich gets a request to route a traffic through the optical
   network, it will include priority information. Let these be
   categorized into 3 levels, 1, 2 and 3 from highest to lowest.

   For traffic no. 1, the switch will compute 2 paths. Also, if the
   protection path is not found, it will preempt a lower priority
   traffic and establish 2 paths during the creation phase itself. In
   other words, this would be a 1+1 style protection.

   For traffic no.2, a working path will be established. The protection
   path will be pre-computed, but need not necessarily be available in
   terms of bandwidth or wavelength at the time of creation. All the
   switches along the path would be pre-configured with the
   information. In case of failure, the lower priority path along those
   switches would be preempted and the traffic no. 2 would be restored.

Many Authors     Informational - Expires October 2001    Page 44 of 53             IP over Optical Networks: Summary of Issues    March 2001

   If this preemption capacity is built into the switches itself, that
   would be the fastest and at the optical layer itself. Otherwise,
   some time is lost in signaling. But still, this can meet the 50mS
   requirement set by SONET.

   Traffic no.3 has the lowest priority. It has no requested back up
   paths. It is set up along the backup paths of the existing  traffic
   2 working paths, unless extra bandwidth is available.

   Thus bandwidth is used efficiently, in providing restoration and
   classes are considered in the above mechanism.

   Other protection priorities like longer protection paths and shorter
   paths can also be taken into account while setting up the paths.
   Also, given a steady traffic flow, with no new paths being created,
   algorithms to optimize the paths selected would enhance the
   performance of the network.

   The next thing required is the signaling messages to set up these
   paths and release them. [Hahm00]

6.7 RSVP-TE/CR-LDP Support for Restoration [BALA00]

   Special requirements for protecting and restoring lightpaths and the
   extensions to RSVP-TE and CR-LDP have been identified. Some of the
   proposed extensions are as follows:

   a. A new SESSION_ATTRIBUTE object has been proposed, which indicates
      whether the path is unidirectional/bi-directional,
      primary/backup. Local protection 1+1 or 1:N can also be
   b. Setup Priority: The priority of the session with respect to
      taking resources. The Setup Priority is used in deciding whether
      this session can preempt another session.
   c. Holding Priority: The priority of the session with respect to
      holding resources.  Holding Priority is used in deciding whether
      this session can be preempted by another session.

   Note that for the shared backup paths the crossconnects can not be
   setup during the signaling for the backup path since multiple backup
   paths may share the same resource and can over-subscribe it.  The
   idea behind shared backups is to make soft reservations and to claim
   the resource only when it is required.

7.  Security Considerations

   This document raises no new security issues for MPL(ambda) Switching
   implementation over optical networks.  Security considerations are
   for future study.

Many Authors     Informational - Expires October 2001    Page 45 of 53             IP over Optical Networks: Summary of Issues    March 2001

8.  Acronyms

   3R   - Regeneration with Retiming and Reshaping
   AIS  - Alarm Indication Signal
   APS  - Automatic Protection Switching
   BER  - Bit Error Rate
   BGP  - Border Gateway Protocol
   BLSR  _ Bi-directional Line-Switched Ring
   CR-LPD  - Constraint-Based Routing LDP
   CSPF  - Constraint Shortest Path First
   FA   - Forwarding Adjacency
   FA-LSP  _ Forwarding Adjacency Label Switched Path
   FA-TDM  _ Time Division Multiplexing capable Forwarding Adjacency
   FA-LSC  _ Lambda Switch Capable Forwarding Adjacency
   FA-PSC  _ Packet Switch Capable Forwarding Adjacency
   FA-FSC  _ Fiber Switch Capable Forwarding Adjacency
   FEC  - Forwarding Equivalence Class
   FIS  - Failure Indication Signal
   FRS  - Failure Recovery Signal
   GSMP  - General Switch Management Protocol
   IGP  - Interior Gateway Protocol
   IS-IS  _ Intermediate System to Intermediate System Protocol
   ITU-T  _ International Telecommunications Union _ Telecommunications
   LDP  - Label Distribution Protocol
   LF  - Link Failure
   LMP  - Link Management Protocol
   LMT  - Link Media Type
   LOL  - Loss of Light
   LOP  - Loss of Packets
   LOS  - Loss Of Signal
   LP  - Lightpath
   LSA  - Link State Advertisement
   LSC  - Lambda Switch Capable
   LSP  - Label Switched Path
   LSR  - Label Switched Router
   MPLS - Multi-Protocol Lambda Switching
   MTG  - MPLS Traffic Group
   NBMA - Non-Broadcast Multi-Access
   NHRP - Next Hop Resolution Protocol
   OCT  - Optical Channel Trail
   OLXC  - Optical layer crossconnect
   OMS  - Optical Multiplex Section
   OPM  - Optical Performance Monitoring
   OSPF  - Open Shortest Path First
   OTN  - Optical Transport Network
   OTS  - Optical Transmission Section
   OXC  - Optical Crossconnect
   PML  - Protection Merge LSR
   PMTG  - Protected MPLS Traffic Group
   PMTP  - Protected MPLS Traffic Portion
   PPG  - Protected Path Group

Many Authors     Informational - Expires October 2001    Page 46 of 53             IP over Optical Networks: Summary of Issues    March 2001

   PSC  - Packet Switch Capable
   PSL  - Protection Switch LSR
   PTP  - Protected Traffic Portion
   PVC  - Permanent Virtual Circuit
   PXC  - Photonic Crossconnect
   QoS  - Quality of Service
   RNT  - Reverse Notification Tree
   RSVP  - Resource reSerVation Protocol
   RSVP-TE - Resource reSerVation Protocol with Traffic Engineering
   SHR  - Self-healing Ring
   SPRing - Shared Protection ring
   SRLG _ Shared Risk Link Group
   TDM  - Time Division Multiplexing
   TE   - Traffic Engineering
   TLV  - Type Length Value
   TTL  - Time to Live
   UNI  - User to Network Interface
   UPSR _ Unidirectional Path-Switched Ring
   VC   - Virtual Circuit
   WDM  _ Wavelength Division Multiplexing

9.  Terminology

   A channel is a unidirectional optical tributary connecting two
   OLXCs.  Multiple channels are multiplexed optically at the WDM
   system.  One direction of an OC-48/192 connecting two immediately
   neighboring OLXCs is an example of a channel.  A channel can
   generally be associated with a specific wavelength in the WDM
   system.  A single wavelength may transport multiple channels
   multiplexed in the time domain.

   Downstream node:
   In a unidirectional lightpath, this is the next node closer to

   Failure Indication Signal:
   A signal that indicates that a failure has been detected at a peer
   LSR.  It consists of a sequence of failure indication packets
   transmitted by a downstream LSR to an upstream LSR repeatedly.  It
   is relayed by each intermediate LSR to its upstream neighbor, until
   it reaches an LSR that is setup to perform a protection switch.

   Failure Recovery Signal:
   A signal that indicates that a failure along the path of an LSP has
   been repaired.  It consists of a sequence of recovery indication
   packets that are transmitted by a downstream LSR to its upstream
   LSR, repeatedly.  Again, like the failure indication signal, it is
   relayed by each intermediate LSR to its upstream neighbor, until is
   reaches the LSR that performed the original protection switch.

Many Authors     Informational - Expires October 2001    Page 47 of 53             IP over Optical Networks: Summary of Issues    March 2001

   First-hop router:
   The first router within the domain of concern along the lightpath
   route.  If the source is a router in the network, it is also its own
   first-hop router.

   Intermediate LSR:
   LSR on the working or protection path that is neither a PSL nor a

   Last-hop router:
   The last router within the domain of concern along the lightpath
   route.  If the destination is a router in the network, it is also
   its own last-hop router.

   This denotes an Optical Channel Trail in the context of this
   document. See "Optical Channel Trail" later in this section.

   Link Failure:
   A link failure is defined as the failure of the link probing
   mechanism, and is indicative of the failure of either the underlying
   physical link between adjacent LSRs or a neighbor LSR itself.  (In
   case of a bi-directional link implemented as two unidirectional
   links, it could mean that either one or both unidirectional links
   are damaged.)

   Liveness Message:
   A message exchanged periodically between two adjacent LSRs that
   serves as a link probing mechanism.  It provides an integrity check
   of the forward and the backward directions of the link between the
   two LSRs as well as a check of neighbor aliveness.

   Loss of Signal:
   A lower layer impairment that occurs when a signal is not detected
   at an interface.  This may be communicated to the MPLS layer by the
   lower layer.

   Loss of Packet:
   An MPLS layer impairment that is local to the LSR and consists of
   excessive discarding of packets at an interface, either due to label
   mismatch or due to TTL errors.  Working or Active LSP established to
   carry traffic from a source LSR to a destination LSR under normal
   conditions, that is, in the absence of failures.  In other words, a
   working LSP is an LSP that contains streams that require protection.

   MPLS Traffic Group:
   A logical bundling of multiple, working LSPs, each of which is
   routed identically between a PSL and a PML.  Thus, each LSP in a
   traffic group shares the same redundant routing between the PSL and
   the PML.

   MPLS Protection Domain:

Many Authors     Informational - Expires October 2001    Page 48 of 53             IP over Optical Networks: Summary of Issues    March 2001

   The set of LSRs over which a working path and its corresponding
   protection path are routed.  The protection domain is denoted as:
   (working path, protection path).

   A switching option in which streams are not automatically switched
   back from a protection path to its corresponding working path upon
   the restoration of the working path to a fault-free condition.

   Used to denote a bearer channel characteristic where it is capable
   of being terminated.

   Optical Channel Trail:
   The elementary abstraction of optical layer connectivity between two
   end points is a unidirectional Optical Channel Trail.  An Optical
   Channel Trail is a fixed bandwidth connection between two network
   elements established via the OLXCs.  A bi-directional Optical
   Channel Trail consists of two associated Optical Channel Trails in
   opposite directions routed over the same set of nodes.

   Optical layer crossconnect (OLXC):
   A switching element which connects an optical channel from an input
   port to an output port. The switching fabric in an OLXC may be
   either electronic or optical.

   Protected MPLS Traffic Group (PMTG):
   An MPLS traffic group that requires protection.

   Protected MPLS Traffic Portion:
   The portion of the traffic on an individual LSP that requires
   protection.  A single LSP may carry different classes of traffic,
   with different protection requirements.  The protected portion of
   this traffic may be identified by its class, as for example, via the
   EXP bits in the MPLS shim header or via the priority bit in the ATM

   Protection Merge LSR:
   LSR that terminates both a working path and its corresponding
   protection path, and either merges their traffic into a single
   outgoing LSP, or, if it is itself the destination, passes the
   traffic on to the higher layer protocols.

   Protection Switch LSR:
   LSR that is the origin of both the working path and its
   corresponding protection path.  Upon learning of a failure, either
   via the FIS or via its own detection mechanism, the protection
   switch LSR switches protected traffic from the working path to the
   corresponding backup path.

   Protection or Backup LSP (or Protection or Backup Path):
   A LSP established to carry the traffic of a working path (or paths)
   following a failure on the working path (or on one of the working

Many Authors     Informational - Expires October 2001    Page 49 of 53             IP over Optical Networks: Summary of Issues    March 2001

   paths, if more than one) and a subsequent protection switch by the
   PSL.  A protection LSP may protect either a segment of a working LSP
   (or a segment of a PMTG) or an entire working LSP (or PMTG).  A
   protection path is denoted by the sequence of LSRs that it

   Reverse Notification Tree:
   A point-to-multipoint tree that is rooted at a PML and follows the
   exact reverse path of the multipoint-to-point tree formed by merging
   of working paths (due to label merging).  The reverse notification
   tree allows the FIS to travel along its branches towards the PSLs,
   which perform the protection switch.

   A switching option in which streams are automatically switched back
   from the protection path to the working path upon the restoration of
   the working path to a fault-free condition.

   Soft state:
   It has an associated time-to-live, and expires and may be discarded
   once that time is passed.  To avoid expiration the state should be
   periodically refreshed.  To reduce the overhead of the state
   maintenance, the expiration period may be increased exponentially
   over time to a predefined maximum.  This way the longer a state has
   survived the fewer the number of refresh messages that are required.

   Traffic Trunk:
   An abstraction of traffic flow that follows the same path between
   two access points which allows some characteristics and attributes
   of the traffic to be parameterized.

   Upstream node:
   In a unidirectional lightpath, this is the node closer to the

   Working or Active Path:
   The portion of a working LSP that requires protection.  (A working
   path can be a segment of an LSP (or a segment of a PMTG) or a
   complete LSP (or PMTG).) The working path is denoted by the sequence
   of LSRs that it tranverses.

10. References

   [Awuduche] D.  Awduche, Y.  Rekhter, J.  Drake, R.  Coltun, "Multi-
   Protocol Lambda Switching: Combining MPLS Traffic Engineering
   Control With Optical Crossconnects," Internet Draft draft-awduche-
   mpls-te-optical-02.txt, Work in Progress, July 2000.

   [BALA00] Bala rajagopalan, D.Saha, B.tang, _RSVP extensions for
   signaling optical paths," Internet Draft draft-saha-rsvp-optical-
   signalling-00.txt, Work in Progress, September 2000.

Many Authors     Informational - Expires October 2001    Page 50 of 53             IP over Optical Networks: Summary of Issues    March 2001

   [Bell-Labs] B. Doshi, S. Dravida, P. Harshavardhana, et. al,"Optical
   Network Design and Restoration," Bell Labs Technical Journal, Jan-
   March, 1999.

   [CRLDP] B.  Jamoussi, et.  al.  "Constraint-Based LSP Setup using
   LDP," Internet Draft draft-ietf-mpls-cr-ldp-04.txt, Work in
   Progress, July 2000.

   [ELLINAS] G. N. Ellinas, "Fault Restoration in Optical Networks:
   General Methodology and Implementation," PhD thesis, Columbia

   [GERSTEL00] Gerstel and R. Ramaswami, "Optical layer survivability:
   A Services Perspective," IEEE Communications, March 2000, pp.104 _

   [GHANI01] N.Ghani et al.,"Architectural Framework for automatic
   protection provisioning in dynamic optical rings," Internet draft,
   draft-ghani-optical-rings-00.txt, Work in Progress, January 2000.

   [GMPLS00] P. Ashwood-Smith et al., "Generalized MPLS - Signaling
   Functional Description," Internet Draft draft-ietf-mpls-generalized-
   mpls-signaling-01.txt, Work in progress, November 2000.

   [GMPLS-CONTROL] Y. Xu et al, "GMPLS Control Plane Architecture for
   Automatic Switched Transport Network," Nov 2000

   [GSMP] A.  Doria, et.  al.  "General Switch Management Protocol
   V3,"Internet Draft draft-ietf-gsmp-08.txt, Work in Progress,
   November 2000.

   [HAHM00] Jin Ho hahm, K.Lee, "Bandwidth provisioning and restoration
   mechanism in Optical networks", Internet draft, draft-hahm-optical-
   restoration-01.txt, Work in Progress, December 2000.

   [ISIS] ISO 10589, "Intermediate System to Intermediate System Intra-
   Domain Routing Exchange Protocol for use in Conjunction with the
   Protocol for Providing the Connectionless-mode Network Service."

   [ISISTE] Henk Smit, Tony Li, "IS-IS extensions for Traffic
   Engineering," Internet Draft, draft-ietf-isis-traffic-02.txt, work
   in progress, March 2000.

   [Johnson99] D. Johnson, N. Hayman and P. Veitch, "The Evolution of a
   Reliable Transport Network," IEEE Communications , August 1999, pp.

   [Kompella00-b] Kompella, K., Rekhter, Y., "Link Bundling in MPLS
   Traffic Engineering," draft-kompella-mpls-bundle-04.txt, Work in
   Progress, November 2000.

Many Authors     Informational - Expires October 2001    Page 51 of 53             IP over Optical Networks: Summary of Issues    March 2001

   [Lang00] J.P.  Lang, "Link Management Protocol (LMP)," Internet
   Draft draft-lang-mpls-lmp-02.txt, Work in Progress, July 2000.

   [Luciani00] J.  Luciani, B.  Rajagopalan, D.  Awuduche, B.  Cain,
   Bilel Jamoussi, Debanjan Saha, "IP Over Optical Networks - A
   Framework," Internet Draft draft-many-ip-optical-framework-01.txt,
   Work in Progress, November 2000.

   [MANCHESTER99] J. Manchester, P. Bonenfant and C. Newton, "The
   Evolution of Transport Network Survivability," IEEE Communications,
   August 1999, pp. 44-51.

   [NHRP] Luciani, et.  al.  "NBMA Next Hop Resolution Protocol
   (NHRP)," RFC 2332, April 1998.

   [ODSI00] G.Bernstein et.  al., "Optical Domain Service Interconnect
   (ODSI) Functional Specification," ODSI Coalition, April 2000.

   [OSPF] Moy, J., _"OSPF Version 2," RFC 1583, March 1994

   [OWENS00] Ken Owens, Srinivas Makam, Vishal Sharma, Ben Mack-Crane,
   Changcheng Huan, "A Path Protection/Restoration mechanism for MPLS
   networks," Internet Draft draft-chang-mpls-path-protection-02.txt,
   Work in progress, November 2000

   [Pendarakis00] D. Pendarakis, B. Rajagopalan, D. Saha, "Routing
   Information Exchange in Optical Networks," Internet Draft draft-prs-
   optical-routing-01.txt, Work in progress, November 2000.

   [SAHA00] B. Rajagopalan, D.Saha, B. Tang, K. Bala , "Signaling
   framework for automated provisioning and restoration of paths in
   optical mesh networks," Internet Draft draft-rstb-optical-signaling-

   [SCTP] R.R. Stewart et al., "Stream Control Transmission Protocol,"
   RFC 2960, October 2000.

   [SHARMA00] Vishal Sharma et al. "Framework for MPLS-based recovery,"
   Internet Draft draf-ietf-mpls-recovery-frmwrk-01.txt, Work in
   progress, November 2000

   [Suurballe] J. Suurballe, "Disjoint Paths in a Network," Networks,
   vol. 4, 1974.

   [UNI00] O. S. Aboul-Magd et al., "Signaling Requirements at the
   Optical UNI," Internet Draft draft-bala-mpls-optical-uni-signaling-
   01.txt, Work in Progress, November 2000.

   [WU] T.H. Wu, "A Passive Protected Self Healing Mesh Network
   Architecture and Applications," IEEE Transactions on Networking,
   Vol. 2, No. 1, February 1994.

Many Authors     Informational - Expires October 2001    Page 52 of 53             IP over Optical Networks: Summary of Issues    March 2001

11. Author's Addresses

   S. Seetharaman, A. Durresi, R. Jagannathan, N. Chandhok, K.
   Department of Computer and Information Science
   The Ohio State University
   2015 Neil Avenue, Columbus, OH 43210-1277, USA
   Phone: (614)-292-3989
   Email: {seethara, durresi, rjaganna, chandhok, vinodkri}@cis.ohio-

   Raj Jain
   Nayna Networks, Inc.
   157 Topaz Street
   Milpitas, CA 95035
   Phone: (408)-956-8000X309
   Email: raj@nayna.com

Full Copyright Statement

   "Copyright (C) The Internet Society (date).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into.

Many Authors     Informational - Expires October 2001    Page 53 of 53

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/