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

Versions: 00

MPLS Working Group    Yanhe Fan, Peter Ashwood-Smith (Nortel Networks)
Internet Draft                      Vishal Sharma, Ken Owens (Tellabs)
                                                  Gerald R. Ash (AT&T)
                   Murali Krishnaswamy, Yang Cao (Lucent Technologies)
                         M. K. Girish (SBC Technology Resources, Inc.)
                             Herbert M. Ruck (Packet Network Services)
                             Simon Bernstein, Phuc Nguyen (Global One)
                            Sunil Ahluwalia (Trillium Digital Systems)
                                             Hans Sjostrand (Ericsson)
                                             Klas Eriksson (Utfors AB)
                                     Lihshin Wang(QwestCommunications)
                                 Avri Doria (Nokia Telecommunications)
                                          Heinrich Hummel (Siemens AG)
Expiration Date: September 2000



                                                            March 2000


        Extensions to CR-LDP and RSVP-TE for Optical Path Set-up

                 draft-fan-mpls-lambda-signaling-00.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   Real-time optical path setup is a fundamental requirement for agile
   optical networks and signaling is a mechanism to achieve automatic
   fast path setup. Our objective is to define extensions to both CR-
   LDP and RSVP-TE that address this requirement.  CR-LDP and RSVP-TE


                                                                     1

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   are defined in [CR-LDP] and [RSVP], respectively, for path setup
   within a MPLS domain. In this draft, we specify mechanisms, TLVs and
   Objects required to support Optical Label Switched Path setup.

Table of Contents

   1. Introduction
   2. Agile Optical Network Overview
   2.1 Compatibility Check
   2.2 Optical User-Network Interface Check
   2.3 Optical Information Distribution
   2.4 Composite Labels
   3. Extensions to CR-LDP
   3.1 Messages and TLVs that are affected by the extensions
   3.1.1 Initialization Message
   3.1.2 Label Request Message
   3.1.3 Label Mapping Message
   3.1.4 Notification Message
   3.1.5 Release, Withdraw and Abort Messages
   3.2 Optical TLV Extensions
   3.2.1 Optical Session Parameters TLV
   3.2.2 Optical Interface Type TLV
   3.2.2.1 Service Type Mask
   3.2.2.2 Control Protocol Mask
   3.2.3 Optical Trail Descriptor TLV
   3.2.4 Optical Label TLV
   3.2.5 Lambda Set TLV
   4. Extensions to RSVP-TE
   4.1 Messages and Objects that are affected by the extensions
   4.1.1 Path Message
   4.1.2 Resv Message
   4.1.3 PathErr and ResvErr Messages
   4.2 Optical Object Extensions
   4.2.1 Optical Label Request Object
   4.2.2 Optical Interface Type Object
   4.2.3 Optical Trail Descriptor Object
   4.2.4 Optical Label Object
   4.2.5 Lambda Set Object
   5. Processing of Optical TLVs and Optical Objects
   5.1 Processing of Optical Session Parameters TLV/Optical Label
   Request Object
   5.2 Processing of Optical Interface Type TLV/Object
   5.3 Processing of Optical Trail Descriptor TLV/Object
   5.4 Processing of Optical Label TLV/Object
   5.5 Processing of Lambda Set TLV/Object
   5.6 Error codes
   6. Security Considerations
   7. References
   8. Acknowledgements
   9. Authors' Addresses
   Appendix A


Fan et al.              Expires September 2000                       2

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000




1. Introduction

   There has been an increasing interest recently in agile optical
   networks.  Agility in optical networks implies fast end-to-end
   optical path setup and restoration.  One way to set up an optical
   path through an agile optical network quickly is to use signaling
   together with dynamic routing.  Routing is used to collect
   information on network topology and resources, pass states around
   and compute the optimal paths from one node to the others.
   Signaling is used to setup, maintain, modify/renegotiate and tear
   down these paths.

   CR-LDP and RSVP-TE are defined in [CR-LDP] and [RSVP], respectively.
   They both support constraint-based routed label switched paths.
   Therefore, it is natural to extend them to set up optical paths in
   an agile optical network.

   The extensions defined in this draft provide support for Optical
   Label Switched Path (OLSP) setup, maintenance, and teardown in
   optical networks by introducing five new types of TLVs/Objects and
   procedures related to CR-LDP/RSVP-TE.


2. Agile Optical Network Overview

   An optical MPLS-enabled network consists of Optical Label Switching
   Routers (OLSR) and point-to-point links.  The OLSRs are
   interconnected by links in a mesh topology.  There are two types of
   interfaces in this network: Optical Node-to-Node Interface (ONNI)
   between two OLSRs and Optical User-Network Interface (OUNI) between
   customer premise equipment (CPE) and OLSRs.  The signaling protocol
   defined in this draft may serve as part of both ONNI and OUNI.  An
   agile MPLS-enabled optical network is an optical network with fast
   OLSP setup and restoration.  In this network, the control component
   of an OLSR consists of a routing protocol (OSPF or IS-IS, for
   example) and a signaling protocol (CR-LDP or RSVP-TE, for example).
   All control information can be exchanged through dedicated control
   channels or independent signaling networks as discussed in [Sigarch]
   and [OLXC].  The means to accomplish this is for further study.

   An OLSR can be anyone of the following types of optical cross-
   connects equipped with the control component described above:
   1. Switching at fiber level
   2. Cross-connect at Lambda level only
   3. Cross-connect at sub-Lambda level only (for an example, SONET/SDH
   DXCs, etc.)
   4. Cross-connect at both Lambda and sub-Lambda levels

   An OLSR can be a Lambda conversion-capable (CC) OLSR or a Lambda
   conversion-incapable (CI) OLSR. A CC-OLSR is an OLSR that is capable
   of cross connecting between any wavelengths, and a CI-OLSR is one

Fan et al.              Expires September 2000                       3

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   that can only cross-connect the same wavelength between different
   interfaces.

   There are two types of links, service-transparent (ST) links and
   service-aware (SA) links. A ST-link is a link providing transparent
   bit transmission, and the interfaces on both ends of this link
   simply perform bitwise input and output operation. An ST-Link can
   accept data at any bit rate below a certain maximum bit rate and any
   protocol format. A pure optical link in which the signal remains in
   optical form from the link input interface to the link output
   interface is an example of a ST-link. An SA-link is a link in which
   interfaces on both ends will handle the payload according to
   protocol format and/or data bit rate before transmitting and after
   receiving. An OC-192 link is an example of a SA-link.

   In an MPLS-enabled optical network, an LSP is an optical path
   between two OUNIs. An LSP may consist of a fiber bundle, just single
   fiber, the concatenation of multiple Lambdas, just one Lambda,
   groups of sub-Lambda channels, or just one sub-Lambda. The label in
   an MPLS-enabled agile optical network may represent any of the
   following:
   1. A fiber bundle
   2. An arbitrary number of fibers in that bundle
   3. A single fiber
   4. An arbitrary number of Lambdas within a fiber
   5. A single Lambda
   6. An arbitrary number of sub-Lambda channels
   7. A single sub-Lambda channel

   In the proposal described in [Lambda], a Lambda is the granularity
   of an OLSP. We believe that Lambda granularity is too coarse for a
   number of reasons:

   1) Bandwidth management and allocation is one issue. We may have,
   for example, an OC-48 encoding Lambda coming into an OLSR and OC-192
   encoding Lambda going out of this OLSR. If our allocation
   granularity is only at the Lambda level, we must map the OC-48 to an
   entire OC-192 pipe and, therefore, we waste three quarters of the
   bandwidth.

   2) Scalability is another issue. Many routers are interconnected
   through an optical network, which requires a lot of optical paths
   among them. We may have a similar "n squared" problem that classical
   IP over ATM has because we don't want the traffic to cross the
   optical network twice even we can have the direct optical path
   between the source and destination. We may quickly run out of
   Lambdas if these optical paths are Lambda paths, as opposed to sub-
   Lambda paths. The development of Lambda merging technology may
   alleviate this problem. However, this type of technology is not
   available yet. In this draft the granularity of OPLS can be multiple
   fibers, a single fiber, multiple Lambdas, a single Lambda, different


Fan et al.              Expires September 2000                       4

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   levels of sub-Lambdas, and groups at all fiber, Lambda and sub-
   Lambda levels.

   The Optical Trail Descriptor (OTD) contains the attributes of an
   optical trail. OTD defines the service type and the channel group.
   The service type can be SONET, Ethernet, etc. The Channel group can
   be a Lambda group, an OC-48 group, etc. The Optical Interface Type
   (OIT) defines the OUNI types. When an OLSP Request is generated, the
   OTD and requested OIT of OUNI interface of the egress OLSR must be
   specified.

2.1 Compatibility Check

   To set up an OLSP in agile optical networks, we must make sure that
   all links crossed by the OLSP are compatible with the OTD. The
   compatibility check must be performed at each SA-link. A new type of
   TLV/Object, OTD TLV/Object is defined to encode the OTD information.

   ST or SA information is the property of links. The routing protocol
   will carry this information. When ER-LSPs are calculated, this
   information will be taken into consideration.

2.2 Optical User-Network Interface Check

   To set up an OLSP in agile optical networks, we must make sure that
   both the input interface of the ingress OLSR and the output
   interface of the egress OLSR have the same type of OUNI. The OUNI
   check must be performed at the egress OLSR or at both the Ingress
   and the Egress OLSRs. A new type of TLV/Object, the OIT TLV/Object,
   is defined to encode the OIT information.

   A routing protocol may carry optical interface information about
   particular OUNI, and may take this information into account when
   computing paths for optical trails.

2.3 Optical Information Distribution

   In order to propagate optical state information and calculate the
   available paths, extensions to OSPF/IS-IS are defined in [ROUTING].
   The Optical LSA/LSP extension advertises the available resource
   information. This extension is an opaque LSA/LSP.

2.4 Composite Labels

   The signaling protocols for MPLS explicitly routed LSPs use a label
   which is passed backwards from destination to source to construct
   the actual data-path. As each label is received for a particular
   output, a new label is allocated for the corresponding input. Thus
   the switching from input label/interface to output label/interface
   is programmed. To accommodate the switching of entire fibers,
   Lambdas within those fibers and sub-Lambdas, we introduce the
   concept of a composite label. This composite label allows the

Fan et al.              Expires September 2000                       5

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   signaling protocol to establish entire fiber/Lambda and/or sub-
   Lambda paths using a single end to end mapping/resv message without
   having to run recursive instances of the signaling protocol.
   Composite labels do not however preclude the use of recursive
   signaling instances should this prove necessary for administrative
   or scalability reasons. One important effect of a composite label is
   that sub-Lambdas may result in the allocation of new Lambda, which
   may in turn result in the allocation of entire fibers.

   A composite label has a somewhat complex TLV format, so as an aid to
   understanding them we introduce the following ASCII representation
   for a composite label:

    { <Fiber>*.<Lambda>*.<Sub-Lambda>* }*

   Composite labels travel within a mapping/resv message and behave in
   a manner similar to normal shim or other in-band labels. This means
   that a mapping/resv message can control the switching of an entire
   fiber on some input bundle to an entire fiber on some output bundle,
   an entire Lambda to a corresponding Lambda, or a sub-Lambda to sub-
   Lambda. Many other mapping/sub-mapping combinations exist, and what
   is legal is dictated by what is supported by the switching hardware
   being traversed.

   Example: The receipt of mapping/resv with the label F7.*.* may cause
   the generation of a mapping/resv with the label F4.*.*. The result
   would be that fiber 4 on the input bundle would be mapped entirely
   to fiber 7 on the output bundle.

   Example: The receipt of mapping/resv with the label F7.L4.* may
   cause the generation of a mapping/resv with the label F4.L62.*. The
   result would be that the fiber 4, Lambda 62 would be mapped
   completely to fiber 7 Lambda 4 on the output port.

   Example: The receipt of mapping/resv with the label F1.L1.{0-2} may
   cause the generation of mapping/resv with the label F3.L2.{4-6}. The
   result would be that fiber 3 Lambda 2, timeslots 4,5,6 would be
   mapped to fiber 1, Lambda 1, timeslots 0, 1 and 2 on the output
   port.

   Example: The receipt of mapping/resv with the label F1.{L1,L2}.* may
   cause the generation of mapping/resv with the label F3.{L7,L9}.*.
   The result would be that fiber 3, Lambdas 7 and 9 would be mapped
   into fiber 1, Lambdas 1 and 2 respectively on the output port.

   There are numerous other combinations, limited only by the electro-
   optical transformations that can be done by any specific switch.

   Example: The receipt of a mapping/resv with the label
   F1.L1.{0-47,48-95,96-143,144-191} may cause the generation of a
   mapping/resv with the label {F2.L4.0-47, F2.L5.0-47, F2.L6.0-47,
   F2.L7.0-47}. The result is that 48 timeslots on four Lambdas 4,5,6

Fan et al.              Expires September 2000                       6

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   and 7 on fiber 2, would be mapped into all 192 timeslots on the
   output fiber 1, on Lambda 1. The inverse of this example is also
   possible. So a composite label with 4 Lambdas and timeslots when
   received, may result in the generation of a single Lambda and
   timeslot set. This represents an inverse multiplexing capability by
   the switch being traversed.

   The Appendix of this document shows some examples of the actual
   formats for some different ASCII representations of composite
   labels.



3. Extensions to CR-LDP

3.1 Messages and TLVs that are affected by the extensions

   Any messages, TLVs, and procedures not defined explicitly in this
   document are defined in [LDP] or [CR-LDP].

   The following subsections serve as a cross-reference to [LDP] and
   [CR-LDP] and as an indication of additional functionality beyond
   what is defined in [LDP] and [CR-LDP]. "Optional" in the following
   text is relative to [LDP] or [CR-LDP].  The TLV has to be used if
   specified here.

3.1.1 Initialization Message

   The Initialization message is as defined in Section 3.5.3 of [LDP]
   and is exchanged during LDP peer session initialization to agree
   upon the common set of parameters to be used when setting up LSPs.
   The message is used by OLSRs during the initialization with the
   following extensions:
   - The Optical Session Parameters TLV must be used as an optional TLV
   - The procedures to handle Initialization message are augmented by
   the procedures for processing of the Optical Session Parameters TLV
   as defined in Section 4

3.1.2 Label Request Message

   The Label Request message is as defined in Section 3.5.8 of [LDP]
   and Section 3.2 of [CR-LDP] and used for setting up OLSPs with the
   following extensions:
   - The OIT TLV must be used as an optional TLV
   - The OTD TLV must be used as an optional TLV
   - Lambda Set TLV is an optional TLV
   - The procedures to handle the Label Request message are augmented
   by the procedures for processing of the OIT, OTD and Lambda Set TLVs
   as defined in Section 5

3.1.3 Label Mapping Message



Fan et al.              Expires September 2000                       7

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   The Label Mapping message is as defined in Section 3.5.7 of [LDP]
   and Section 3.3 of [CR-LDP] and used for setting up OLSPs with the
   following extensions:
   - The Optical Label TLV must be used as the Label TLV.
   - The Label Mapping procedures are limited to downstream on demand
   ordered control mode with conservative label retention mode.
   - The procedures to handle the Label Mapping message are augmented
   by the procedures for processing of the Optical Label TLV as defined
   in Section 5.

3.1.4 Notification Message

   The Notification message is as defined in Section 3.5.1 of [LDP] and
   Section 3.3 of [CR-LDP]. The Status TLV encoding is as defined in
   Section 3.4.7 of [LDP]. New status codes are defined in Section 5.6
   to signal error notifications associated with the establishment of
   an OLSP and the processing of the Optical-TLVs. The Notification
   message may also carry an OIT or OTD TLV. When the OUNI check or
   compatibility check fails, the ingress OLSR can updates its database
   correctly by taking into account the actual OUNI type or the link
   attributes contained in the OIT or OTD TLV.

3.1.5 Release, Withdraw and Abort Messages

   The Label Release, Label Withdraw and Label Abort messages are used
   as specified in [LDP] to clear OLSPs. These messages may also carry
   the Optical Label TLV.

3.2 Optical TLV extensions

   The messages defined in [LDP] and [CR-LDP] optionally carry one or
   more of the optional Optical TLVs defined in this section. In this
   specification, the following TLVs are defined:
   - Optical Session Parameters TLV
   - Optical Interface Type TLV
   - Optical Trail Descriptor TLV
   - Optical Label TLV
   - Lambda Set TLV









   3.2.1 Optical Session Parameters TLV

   The Optical Session Parameters TLV is used when an LDP session
   manages label exchange for Optical Link to specify Optics-specific
   session parameters.

Fan et al.              Expires September 2000                       8

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000





   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|   Optical Sess Parms      |            Length             |
   | | |     (0x0503)              |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  M  |   N   |            Reserved                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Optical Label Range Component 1                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Optical Label Range Component 2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Optical Label Range Component N                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M is a 3-bit field that specifies the Multiplexing Capabilities of
   an OLSR. The following values are supported in this version:
             Value            Meaning
             -----    ----------------------------------
               0       Multiplexing not supported
               1       SONET/SDH multiplexing supported
               2       others (e.g., GE multiplexing supported)

   N is a 4-bit field that specifies the number of optical label range
   components.

   The encoding for an Optical Label Range Component is:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Fiber ID          |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Maximum Lambda ID      |        Minimum Lambda ID      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fiber ID is a 16-bit field that identifies one fiber.

   Maximum Lambda ID is a 16-bit field that specifies the lower bound
   of a block of Lambdas that are supported by the originating OLSR.

   Minimum Lambda ID is a 16-bit field that specifies the lower bound
   of a block of Lambdas that are supported by the originating OLSR.

3.2.2 Optical Interface Type TLV




Fan et al.              Expires September 2000                       9

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   The OIT TLV is used to represent the traffic characteristics of a
   User-Network interface. It is carried by Request message. The OIT
   TLV encoding is as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|1|   Optical Interface Type  |            Length             |
   | | |     (0x0910)              |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Sub-TLVs                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit refers to Unknown TLV bit as defined in [LDP].

   Length specifies the length of the value field in bytes.





3.2.2.1 Service Type Mask

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type = 1          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Service Type ID 1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Service Type ID 2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Service Type ID n                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length specifies the length of the value field in bytes.

   Service Type ID identifies each service type by a unique 32-bit
   number. The following numbers are defined in this version:

            Service
            Type ID      Description
           ---------    -------------
                0        IP
                1        ATM
                2        Frame Relay
                3        SONET
                4        GE
                5        FDDI


Fan et al.              Expires September 2000                      10

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000




3.2.2.2 Control Protocol Mask

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type = 2          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Control Protocol ID 1                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Control Protocol ID 2                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Control Protocol ID n                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Length specifies the length of the value field in bytes.

   Control Protocol identifies each control protocol by a unique 32-bit
   number. The following numbers are defined in this version:

            Protocol
            Type ID      Description
           ---------    -------------
                0           OSPF
                1           RIP
                2           BGP4
                3           EGP
                4           MOSPF
                5           DVMRP
                6           PIM
                7           IS-IS
                8           PNNI


3.2.3 Optical Trail Descriptor TLV

   The OTD TLV represents the characteristics of an optical trail. The
   optical trail may consist of one or more channel groups of different
   granularity. All members within a group must have the same
   granularity, but different group types may be mixed into one OTD
   TLV. OTD TLV is carried by Request message and its encoding is as
   follows:








Fan et al.              Expires September 2000                      11

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000




   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|   Optical Trail Desc      |            Length             |
   | | |     (0x0920)              |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Channel Group 1                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Channel Group 2                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Channel Group n                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Length specifies the length of the value field in bytes.

   Channel Group describes the components of an optical trail. The
   encoding of the Channel Group is:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Channel Group Type      |    Number of Group Members    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The Channel Group Type defined in this version is as follows:

            Channel
            Group
            Type         Description
           ---------    -------------
              1          Fiber
              2          Lambda
              3          GE
              4          10 GE
              5          OC-3/STM-1
              6          OC-3c
              7          OC-12/STM-4
              8          OC-12c
              9          OC-48/STM16
              10         OC-48c
              11         OC-192/STM-64
              12         OC-192c
              13         OC-768/STM-256
              14         OC-768c



Fan et al.              Expires September 2000                      12

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   Number of Group Members specifies the number of members within the
   group.

3.2.4 Optical Label TLV

   Optical Label TLVs encode optical labels. A simple composite optical
   Label, noted as F.L.S, is described in 2.4 and is encoded here. The
   multiple F.L.S can be used to compose an optical Label representing
   one or more channel groups of different granularity. Optical Label
   TLVs are carried by the messages used to advertise, request, release
   and withdraw label mappings.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|   Optical Label (0x0930)  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Label Component 1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Label Component 2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Label Component n                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   U bit refers to Unknown TLV bit as defined in [LDP].

   F bit refers to Forward unknown TLV bit as defined in [LDP].

   Length specifies the length of the value field in bytes.

   Label Component encodes F.L.S for a channel group and is as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Channel Group Type      |    Number of Group Members    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Line Rate Encoding Type    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Channel Group ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Channel Group Type is defined in 3.2.3.

   Number of Group Member is defined in 3.2.3.

   Line Rate Encoding Type specifies the top encoding protocol.
   Examples of encoding type include SONET (OC-192, OC-48, etc.) and

Fan et al.              Expires September 2000                      13

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   Ethernet (GE and 10 GE). The type value is the same as channel group
   type, plus one more, the transparent bit service. The transparent
   bit service type value is 0.

   Length specifies the length of field following this field in bytes.

   Fiber ID is a 16-bit field to specify the fiber.

   The Lambda ID is a 16-bit field that identifies a Lambda. All the
   Lambda IDs will be 0x0000 if the group type is fiber. Both Fiber ID
   and Lambda ID have to be consistent between the two peers. The means
   to achieve this is out of the scope of this document.

   Channel Group ID specifies one channel group and is aligned with 4-
   octet boundary and the format depends on Channel Group Type. The
   content of the Channel Group ID depends on the channel group type.
   The Channel Group ID is as follows:

   1) For fiber and Lambda group types

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   2) For SONET/SDH group type

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Channel ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The channel ID consists of all STS-1s/STM-1s identified in the bit
   Mask. The 0 bit in the first 4-octet corresponds to the first STS-
   1/STM-1. If group ID bit masks in the last 4-octet are less than 32-
   bits, it should be left justified in this field and succeeding bits
   should be set to 0. If the encoding type is OC-192, for example, the
   group type is OC-48 and the one member in this group, then the
   Channel ID is 24 bytes long with only 48 bits being set. See
   appendix A for more details.

3.2.5 Lambda Set TLV

Fan et al.              Expires September 2000                      14

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000




   Lambda Set TLV represents the set of current available Lambdas. It
   is useful when trying to setup OLSP through CI-OLSR(s). This TLV is
   carried by Request message and encoded as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|    Lambda Set (0x0940)    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit refers to Unknown TLV bit as defined in [LDP].

   F bit refers to Forward unknown TLV bit as defined in [LDP].

   Length specifies the length of the value field in bytes.

   Lambda ID is defined in 3.2.4.


4. Extensions to RSVP-TE

4.1 Messages and Objects Affected by the Extensions

   Any messages, objects, and procedures not defined explicitly in this
   document are defined in the [RSVP] Specifications.

   The following subsections serve cross-reference to the [RSVP]
   documents and indicate of additional functionality beyond what is

   defined in [RSVP]. "Optional" in the following text is relative to
   [RSVP].  If defined in this specification the TLV has to be used.

4.1.1 Path Message

   The Path message is as defined in Section 3.1 of [RSVP] and with the
   following extensions:
   - The optical label request object must be used as an optional
     object.
   - The optical trail descriptor object must be used as an optical
     object.
   - The optical interface type object must be used as an optical
     object.
   - Lambda object is an optional object.
   - The procedures to handle the Path message are augmented by the
     procedures for processing of optical label request, OIT, OTD and
     Lambda set objects as defined in Section 5.

Fan et al.              Expires September 2000                      15

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000




   The format of the Path message is as follows:

         <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                                  <SESSION> <RSVP_HOP>
                                  <TIME_VALUES>
                                  [ <EXPLICIT_ROUTE> ]
                                  <OPTICAL LABEL_REQUEST>
                                  <OPTICAL TRAIL DESCRIPTOR>
                                  <OPTICAL INTERFACE TYPE>
                                  [ <LAMBDA SET> ]
                                  [ <SESSION_ATTRIBUTE> ]
                                  [ <POLICY_DATA> ... ]
                                  [ <sender descriptor> ]

         <sender descriptor> ::=  <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
                                  [ <ADSPEC> ]
                                  [ <RECORD_ROUTE> ]

4.1.2 Resv Message

   The Resv message is as defined in Section 3.2 of [RSVP] and with the
   following extensions:
   - The optical label must be used as an optional object.
   - The procedures to handle the Resv message are augmented by the
     procedure for the processing of optical label objects as defined
     in Section 5.

   The format of Resv message is the same as that in Section 3.2 of
   [RSVP] except for the replacement the LABEL object with the
   OPTICAL_LABEL object.

4.1.3 PathErr and ResvErr Messages

   The PathErr and ResvErr message may also carry optical objects.

4.2 Optical Object Extensions

   The messages defined in [RSVP] optically carry one or more of the
   optical objects defined in this section. In this specification, the
   following optical objects are defined:
     - OPTICAL_LABEL_REQUEST object
     - OPTICAL_TRAIL_DESCRIPTOR object
     - OPTICAL_INTERFACE_TYPE object
     - OPTICAL_LABEL object
     - LAMBDA_SET object







Fan et al.              Expires September 2000                      16

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



4.2.1 Optical Label Request Object

   The OPTICAL_LABEL_REQUEST object is carried in the Path message.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |  Class-Num=19 |  C-Type = TBD |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved           |             L3PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Optical Label Range Component 1                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Optical Label Range Component 2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Optical Label Range Component n                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Length specifies the object length in bytes.

   Reserved is a reserved field. It MUST be set to zero on transmission
   and MUST be ignored on receipt.

   L3PID identifies the layer 3 protocol using this path. Standard
   Ethertype values are used.

   Optical Label Range Component is defined in Section 3.2.1.








4.2.2 Optical Interface Type

   This OPTICAL_INTERFACE_TYPE object is carried in the Path message.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |  Class-Num=19 |  C-Type = TBD |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sub-objects                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Length specifies the object length in bytes.

Fan et al.              Expires September 2000                      17

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000




   Sub-objects   Are Service Type TLV and Control Protocol TLV defined
   in Section 3.2.2.1 and 3.2.2.2.

4.2.3 Optical Trail Descriptor Object

   The OPTICAL_TRAIL_DESCRIPTOR object is carried in the Path message.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |  Class-Num=19 |  C-Type = TBD |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Channel Group 1                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Channel Group 2                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Channel Group n                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length specifies the object length in bytes.

   Channel Group is defined in Section 3.2.3.

4.2.4 Optical Label Object

   This OPTICAL_LABEL object is carried in the Resv message.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |  Class-Num=19 |  C-Type = TBD |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Label Component 1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Label Component 2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Label Component n                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Length specifies the object length in bytes.

   Label Component is defined in Section 3.2.4.





Fan et al.              Expires September 2000                      18

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



4.2.5 Lambda Set Object

   This LAMBDA_SET object is carried in the Path message.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Length            |  Class-Num=19 |  C-Type = TBD |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . .                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Length specifies the object length in bytes.

   Lambda ID is defined in Section 3.2.4



5 Processing of Optical TLVs and Optical Objects

5.1 Processing of Optical Session Parameters TLV/Optical Label Request
Object

   A receiving OLSR MUST calculate the intersection between the
   received range and its own support range. The intersection is the
   range in which the OLSR may allocate and accept labels. If the
   intersection of ranges is NULL, the OLSR must send a Notification
   message with the error code "Session Rejected/Parameters Label
   Range" in response to the Initialization message and not establish
   the session in CR-LDP case, or should send a PathErr message with
   the error code "Routing problem" and the error value "MPLS label
   allocation failure" in RSVP case.

5.2 Processing of Optical Interface Type TLV/Object

   When an edge OLSR receives a Request or Path message, it retrieves
   the OIT field from the message and compares the value of every
   attribute with that of the requested user-network interface. If all
   the attributes match, the OIT check is successful. Otherwise, this
   OLSR generates a Notification or PathErr message to indicate the
   mismatch. The error code is defined in Section 5.6.

   For the tandem OLSR, the OIT TLV or Object remains untouched.

5.3 Processing of Optical Trail Descriptor TLV/Object



Fan et al.              Expires September 2000                      19

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   When an OLSR receives a Request or Path message over a SA-link, it
   retrieves the OTD field from the message and assigns a Label based
   on the OTD field. When an OLSR sends a Request or Path to next hop
   over a SA-link, it performs the compatibility check first. The
   Request or Path message is sent out if the check is successful.
   Otherwise, this OLSR generates a Notification or PathErr message to
   indicate the compatibility check failure. The Error code is defined
   in Section 5.6.

   The compatibility check must be performed at each SA-link to make
   sure this link can support the certain type of optical trail as
   requested. A requested optical trail for example, could be an OC-48
   trail and may be built over an OC-192 link. The compatibility check
   will be successful if this link can support OC-48 multiplexing and
   an OC-48 channel is available. Otherwise, the compatibility check
   will fail.

   The label is assigned based on the OTD field when Mapping or Resv
   message is handled.

5.4 Processing of Optical Label TLV/Object

   The processing of Optical Label TLV or Object is similar to that of
   non-optical label TLV or Object. When an OLSR receives an Optical
   Label TLV or Object from the Mapping or Resv message, the OLSR
   updates its Label Information Table with the new label and also
   configures its connection table based on the Label.

5.5 Processing of Lambda Set TLV/Object

   When a CI-OLSR receives a Request or Path message and checks the
   existence of Lambda Set TLV or Object. If the Request or Path
   message contains a Lambda Set TLV or Object, this CI-OLSR calculates
   the intersection between the received Lambda set and its own
   available Lambda set, and replace the Lambda Set TLV or Object field
   by the intersection Lambda set if the intersection is not NULL.
   Otherwise, this CI-OLSR generates a Notification or PathErr message
   to indicate NULL intersection. If the Request or Path message
   doesn't have a Lambda Set TLV or Object, this CI-OLSR adds a Lambda
   Set TLV or Object with its own available Lambda set.

   When a CC-OLSR receives a Request or Path message and removes the
   Lambda Set TLV or Object if there is one. This CC-OLSR can assign a
   Label for this OLSP only from the Lambda set contained in Lambda Set
   TLV or Object.

5.6 Error codes

   In the Optical-TLV and Optical-Object processing described above,
   certain errors need to be reported as part of the Notification,
   PathErr or ResvErr Message.  This section defines the status codes


Fan et al.              Expires September 2000                      20

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   for the errors described in this specification.  At present, these
   codes are not exhaustive.

      Status Code                                  Type
     ---------------------------               ------------
      Interface OIT Mismatch                    0x05000001
      Compatibility Check Failure               0x05000002
      Bad OIT TLV/Object                        0x05000003
      Bad OTD TLV/Object                        0x05000004
      Bad Optical Label TLV/Object              0x05000005
      Bad Lambda Set TLV/Object                 0x05000006
      NULL intersection                         0x05000007


6. Security Considerations

   This draft does not introduce any new security considerations beyond
   those specified in [LDP], [CR-LDP], and [RSVP].


7. References



   [LDP] Andersson, et al, "Label Distribution Protocol Specification,"
   draft-ietf-mpls-ldp-06.txt, Work in progress, October 1999.

   [CR-LDP] Bilel Jamoussi, "Constraint-Based LSP Setup using LDP,"
   draft-ietf-mpls-cr-ldp-03.txt, Work in progress, September 1999.

   [RSVP] Awduche, et al, "Extensions to RSVP for LSR Tunnels," draft-
   ietf-mpls-rsvp-lsp-tunnel-04.txt, Work in progress, September 1999

   [Lambda] Awduche, et al, "Multi-Protocol Lambda Switching: Combining
   MPLS Traffic Engineering Control with Optical Crossconnects," draft-
   awduche-mpls-te-optical-01.txt, Work in progress, November 1999

   [ROUTING] Wang, et al, "Extensions to OSPF/IS-IS for Optical
   Routing," draft-wang-ospf-isis-lambda-te-routing-00.txt, Work in
   progress, March 2000

   [PAR] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0,"
   AF-RA-0104.000, January 1999

   [AOTN] Draft ITU-T Recommendation G.872, "Architecture of Optical
   Transport Networks," April 1999.

   [Sigarch] M. Krishnaswamy, et.al., "MPLS Control Plane for Switched
   Optical Networks", draft-krishmaswamy-mpls-son-00.txt, work in
   progress, March 2000



Fan et al.              Expires September 2000                      21

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   [OLXC] Sid Chaudhuri, Gisli Hjalmtysson, Jennifer Yates, "Control of
   Lightpaths in an Optical Network", draft-chaudhuri-ip-olxc-control-
   00.txt, work in progress, February 2000

8. Acknowledgments

   The authors would like to thank Guoqiang Wang, Loa Andersson, Bilel
   Jamoussi and Stephen Shew for their comments on the draft.

9. Author's Addresses

   Yanhe Fan                         Peter Ashwood-Smith
   Nortel Networks                   Nortel Networks
   PO Box 3511 Station C             PO Box 3511 Station C
   Ottawa, ON, K1Y 4H7               Ottawa, ON, K1Y 4H7
   Canada                            Canada
   Phone: 613-765-2315               Phone: 613-763-4534
   yanhe@nortelnetworks.com          petera@nortelnetworks.com


   Vishal Sharma                     Ken Owens
   Tellabs Research Center           Tellabs Operations, Inc.
   One Kendall Square                1106 Fourth Street
   Bldg. 100, Suite 121              St. Louis, MO 63126
   Cambridge, MA 02139               USA
   USA                               Ph: 314-918-1579
   Ph: 617-577-8760                  Ken.Owens@tellabs.com
   vishal.sharma@tellabs.com


   Gerald R. (Jerry) Ash             Murali Krishnaswamy
   AT&T Labs                         Lucent Technologies
   Room MT E3-3C37                   3C-512
   200 Laurel Avenue                 101 Crawfords Corner Rd.
   Middletown, NJ 07748              Holmdel NJ 07733
   USA                               USA
   Phone: 732-420-4578               Voice: +1 732 949 3611
   Fax:   732-440-6687
   gash@att.com                      murali@lucent.com


   Yang Cao                          M. K. Girish
   Lucent Technologies               SBC Technology Resources, Inc.
   21-2A33, 1600 Osgood St           4698 Willow Road,
   North Andover, MA  01845-1043     Pleasanton, CA 94588
   USA                               USA
   Phone: +1 978 960 6173            Phone: +1 925 598-1263
   Fax:   +1 978 960 6329            Fax:   +1 925 598-1322
   yangcao@lucent.com                mgirish@tri.sbc.com




Fan et al.              Expires September 2000                      22

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   Dr. Simon Bernstein               Phuc Nguyen
   Global One                        Global One
   12490 Sunrise Valley Drive        12490 Sunrise Valley Drive
   Reston,                           Reston,
   VA 20196-0001 USA                 VA 20196-0001 USA
   Phone: +1 703 689-7109            Phone: +1 703 689-7870
   Fax: + 1 703 689-6724             Fax: + 1 703 689-6724
   simon.bernstein@globalone.net     Phuc.Nguyen@GlobalOne.net


   Herbert M. Ruck                   Lihshin Wang
   Packet Network Services           Qwest Communication.
   NEC America, Inc.                 4250 N Fairfax Drive
   1525 Walnut Hill Lane             Arlington, VA
   Irving, TX, 75038                 USA
   U.S.A.                            Phone: 703-363-3986
   Tel. 972-518-3590                 Lihshin.Wang@qwest.com
   ruck@asl.dl.nec.com


   Sunil Ahluwalia                   Hans Sjostrand
   Trillium Digital Systems Inc,     Ericsson
   12100 Wilshire Blvd. #1800        Business Unit Datacom Networks
                                     and IP Services
   Los Angeles, CA 90025             S-126 25 Stockholm,
   USA                               Sweden
   Phone: 310 442 9222               Phone: +46 8 719 9960
   sunil@trillium.com                hans.sjostrand@etx.ericsson.se


   Klas Eriksson                     Heinrich Hummel
   Utfors AB                         Siemens AG
   Svetsarvagen 24                   Hofmannstrasse 51
   Sweden                            81379 Munich, Germany
   tel: +46 8 52 70 30 05            Tel: +49 89 722 32057
   klas.eriksson@utfors.se           heinrich.hummel@icn.siemens.de


   Avri Doria
   Nokia Telecommunications
   3 Burlington Woods Drive,
   Suite 250,Burlington, MA 01803
   Phone: +1 781 359 5131
   Mobile: +1 617 678 9402
   avri.doria@nokia.com








Fan et al.              Expires September 2000                      23

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



Appendix A

   This appendix gives more examples of the optical label.

   1) F.<L1, L2>.*
   This is for an optical trail of a Lambda group with no sub-Lambda
   groups.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|           0x0930          |              16               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              2                |              2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              0                |              8                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

































Fan et al.              Expires September 2000                      24

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000



   2) F.L.<S1, S2>

   This is for an optical trail of two sub-Lambda groups (one OC-48
   group with two members and one OC-12 group with one member).

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|           0x0930          |              64               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              9                |              2                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              11               |             28                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-                    Channel ID 1                  +-+-+-+
   |                                                               |
   +-+-+-+-                      . . .                       +-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              7                |              1                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              11               |             28                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Fiber ID         |           Lambda ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-                    Channel ID 2                  +-+-+-+
   |                                                               |
   +-+-+-+-                      . . .                       +-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Channel ID 1 is 192-bits long and with 96 bits being set. The
   Channel ID 2 is 192-bits long with only 12 bits being set. Each bit
   represents an STS-1.















Fan et al.              Expires September 2000                      25

Internet Draft    draft-fan-mpls-lambda-signaling-00.txt     March 2000




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 implementation 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 languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

































Fan et al.              Expires September 2000                      26


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