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

Versions: (draft-aboulmagd-mpls-ldp-optical-uni) 00 01

     MPLS Working Group                                     Osama Aboul-Magd
     Internet Draft                                          Nortel Networks
     
     draft-ietf-mpls-ldp-optical-uni-00.txt                         Raj Jain
     Expiration Date: April 2001                              Nayna Networks
                                                                 LiangYu Jia
                                                                 ONI Systems
                                                            Bala Rajagopalan
                                                                     Tellium
                                                             Robert Rennison
                                                             Laurel Networks
                                                                Yangguang Xu
                                                                 Lucent Tech
                                                             Zhensheng Zhang
                                                           Sorrento Networks
                                                               October, 2000
     
     
         LDP Extensions for Optical User Network Interface (O-UNI) Signaling
     
     
     Status of this Memo
     
        This document is an Internet-Draft and is in full conformance with all
        provisions of Section 10 of RFC2026.
     
        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.
     
     
     
     1. Abstract
     
        General requirements for signaling across the Optical UNI (O-UNI) are
        discussed in [1]. This draft describes extensions to the LDP protocol
        [2] to support those requirements. The LDP extensions described here
        address two areas:
     
        - The addition of new TLVs to support the attributes required for
        lightpath establishment at the O-UNI
     
     
     
     
     
     Aboul-Magd                    April 2001                             1
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
        - Two new LDP messages to allow for the exchange of lightpath status
        information across the UNI.
     
     
     
     2. Conventions used in this document
     
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in RFC-2119 [3].
     
     
     3. Use of LDP for the O-UNI
     
        This draft describes how LDP with extensions will be used as a
        signaling mechanism for the O-UNI. Several O-UNI abstract messages are
        defined in [1]. This draft specifies how to use the existing LDP
        messages for that purpose. Two new LDP messages are introduced to meet
        the requirements for the exchange of status information across the O-
        UNI.
     
     3.1. Overview
     
        LDP is one of the candidate protocols described in [1] for O-UNI
        signaling implementation.
     
        Applying LDP at the O-UNI allows for:
     
        - The reuse of already defined LDP messages and message formats
        - The reuse of LDP session management and control procedures
        - Additions to the already specified procedures for notification of
        errors.
        - The reuse of the LDP security mechanism
     
        Support for the O-UNI signaling requirements depends upon the use of
        the following LDP behaviors and mechanisms as defined in [2].
     
        - Use of Basic and/or Extended discovery mechanisms.
        - Use of the Label Request Message in downstream on demand label
        advertisement mode with ordered control.
        - Use of the Label Mapping Message in downstream on demand label
        advertisement mode with ordered control.
        - Use of the Notification Message.
        - Use of the Withdraw and Release Messages.
     
        Additional messages are defined to support the propagation of lightpath
        status information as defined in [1].
     
        Additional TLVs are specified to support the lightpath attributes
        specified in [1].
     
     
     
     
     
     
     Aboul-Magd                    April 2001                             2
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
     4. O-UNI Session Management and Control
     
        LDP messages that relevant to the O-UNI session management and control
        are Hello Message, Initialization Message, and KeepAlive Message.
     
     4.1. Hello Message
     
        This draft does not change the format or the procedures of the LDP
        Hello Message as described in section 3.5.2. of [2].
     
     4.2. KeepAlive Message
     
        This draft does not change the format or the procedures of the LDP
        KeepAlive Message as defined in section 3.5.4 of [2].
     
     4.3. Initialization Message
     
        The Initilaization Message is as defined in section 3.5.3 of [2] with
        the following modifications:
     
        - The Label Advertisement Discipline (the ôAö bit) is always set at 1
        to indicate Downstream on Demand label distribution mode. Downstream on
        Demand is the only label distribution mode supported at the O-UNI. The
        assignment A=0 should result in generating a Notification Message with
        the appropriate error code.
        - Loop Detection is always disabled, D=0. The assignment D=1 should
        result in generating a Notification Message with the appropriate error
        code.
     
     5. The Use of LDP Messages for O-UNI
     
        A set of abstract O-UNI messages is defined in [1]. Those abstract
        messages support the basic functions of the optical UNI. Those
        functions are,
     
        - Lightpath Create: Creates a lightpath with certain attributes between
        two ends in the optical networks
     
        - Lightpath Delete: Deletes an already existing lightpath
     
        - Lightpath Modify: Modifies one or more of the attributes of already
        existing lightpath
     
        - Lightpath Status Enquiry: Enquires about the status of an already
        existing lightpath
     
        Each of the above functions is accomplished by a set of O-UNI messages
        using LDP protocol.The procedures for handling LDP messages across the
        optical UNI are augmented to add the additional O-UNI functionality.
        Common across the O-UNI are:
     
     
     
     
     
     
     Aboul-Magd                    April 2001                             3
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
        - The LDP FEC TLV should be ignored at the O-UNI since it has no
        significance, and
        - The use of LDP messages for O-UNI does not change the semantics of
        the LDP Message ID.
     
     5.1. Lightpath Create Action
     
        Lightpath Create Action requires two messages, the lightpath Create
        Request and the Lightpath Create Response. The mapping of the LDP
        messages to fulfill the lightpath create action is:
     
        - Lightpath Create Request: The create request function is achieved by
        the LDP Label Request Message. The Generalized Label Request TLV
        defined in [4] is used to convey some lightpath attributes to the
        network side.
        - Lightpath Create Response: The create response function is achieved
        by the use of the LDP Label Mapping Message. The create response
        function makes use of the Generalized label defined in [4]. The Label
        Mapping procedures are limited to downstream on demand, ordered control
        mode with conservative label retention mode.
     
     5.2. Lightpath Delete Action
     
        Lightpath Delete Action requires two messages,
        the Lightpath Delete Request and the Lightpath Delete Response. The
        mapping of the LDP messages to fulfill the function of the lightpath
        delete action is:
     
        - Lightpath Delete Request: The delete request is achieved by the LDP
        Label Release Request Message. The Label Release Message is sent from
        the client or the network at any time after the establishment of the
        lightpath to delete it.
        - Lightpath Delete Response: The delete Response is achieved by the LDP
        Label Withdraw Message. The Label Withdraw Message is sent from the
        client or the network in response to a Label Release Request.
     
     5.3. Lightpath Modify Action
     
        After a lightpath is setup, some of its attributes, e.g. bandwidth, may
        need to be changed by the network operator due to new requiremenst for
        the traffic carried on that lightpath. Lightpath Modify Action does not
        require the definition of new LDP messages. The modify action follows
        the procedure described in [5].
     
        Lightpath modification can only be allowed when the lightpath is
        already established. The procedure described in [5] allows for
        modification of lightpath attributes without service interruption. Only
        modifications requested by the owner of a particular lightpath are
        allowed.
     
     
     
     
     
     
     
     Aboul-Magd                    April 2001                             4
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
        The procedure described in [5] for lightpath modification relies on the
        introduction of the Action Flag (ActFlg) field in the Lightpath Id TLV
        (see section 6.1.3). Similar to the case in CR-LDP [7], the ActFlg
        field indicates if the signaled Lightpath Request is an initial
        lightpath setup or a modification request.
     
     5.4. Lightpath Status Action
     
        Lightpath Status Actionrequires two messages, Lightpath Status Enquiry
        and Lightpath Status Response
     
        The Lightpath Status Enquiry and Lightpath Status Response functions
        require the definition of two new LDP messages, The Status Enquiry
        Message and the Status Response Message. The encoding of the new
        messages is defined in sections 6.6 and 6.7.
     
     5.5. Notification Action
     
        The Notification function is similar in scope to that of the CR-LDP
        Notification Message. Hence the LDP Notification message is used across
        the O-UNI for this purpose.
     
     6. LDP Message Extensions
     
        This section gives detailed description of LDP message extensions for
        the support of O-UNI.
     
     6.1. Label Request Message
     
        The LDP Label Request Message is as defined in 3.5.8. of [2] with the
        following modifications (required only if any of O-UNI TLVs is included
        in the Label Request Message):
     
        - The FEC TLV is ignored at the O-UNI
     
        - The procedures to handle the Label Request Message are augmented by
        the procedures for processing of the O-UNI TLVs as defined in this
        section
     
        The encoding for the O-UNI LDP Label Request Message 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|  Label Request (0x0401)     |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              Message ID                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               FEC TLV                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 Source Id TLV    (O-UNI mandatory)            |
     
     
     
     
     
     Aboul-Magd                    April 2001                             5
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             Destination Id TLV   (O-UNI mandatory)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               Lightpath Id TLV   (O-UNI mandatory)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        Generalized Label Request TLV (O-UNI mandatory)        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Suggested Label TLV   (O-UNI optional)             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Label Set TLV         (O-UNI optional)             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             Service TLV          (O-UNI mandatory)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Optional Parameters                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
     6.1.1 Source Id TLV
     
        The Source Id TLV is an object that specifies the initiator (the
        calling party) of the lightpath creation request. The encoding of the
        Source Id TLV 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|0|   Source Id (0x0950)      |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Node Address                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Port ID              | Channel Id    | Sub-channel ID|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +              Source User Group                +-+-+-+-+-+-+-+-+
        |                                               |  Reserved     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Node Address:
          The Node Address is the IPv4 address associated with the optical
          network element
     
        Port Id:
          Port Id is a two-octet unsigned integer indicating the port number in
          an optical network element
     
        Channel Id:
          Channel Id is a single octet unsigned integer indicating a channel
          with respect to the specified Port Id.
     
        Sub-Channel Id:
     
     
     
     
     
     
     Aboul-Magd                    April 2001                             6
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
          Sub-Channel Id is a single octet unsigned integer indicating a sub-
          channel with respect to the specified Channel Id.
     
        Source User Group:
          The Source User Group identifies the logical network or group to
          which the optical client belongs. The Source User group is the 7-
          octet structure as defined in [6].
     
     6.1.2. Destination Id TLV:
     
        The Destination Id TLV has the same structure as the Source Id TLV. The
        format of the Destination Id TLV 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|0| Destination Id(0x0951)    |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Node Address                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Port ID              | Channel Id    | Sub-channel ID|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +              Source User Group                +-+-+-+-+-+-+-+-+
        |                                               |  Reserved     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
     6.2.3. Lightpath Id TLV
     
        The format of the Lightpath Id is as follows:
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |U|F| lightpath Id (0x0952)     |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Reserved                                   | ActFlg|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          optical network element IPv4 address                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Index                             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        ActFlag
          A 4-bit field that explicitly indicates the action that should be
          taken on an already existing lightpath. A set of indicator code
          points is proposed as follows
     
          0x0 = initial lightpath setup
          0x1 = modify lightpath
     
        Optical Network Element Ipv4 Address
     
     
     
     
     
     Aboul-Magd                    April 2001                             7
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
          The Ipv4 address of the optical network element
     
        Index
          A 4-octet field uniquely identifies a lightpath.
     
     6.1.3. Generalized Label Request TLV
     
        The Generalized Label TLV format and procedure are as defined in
        section 3.1 of [4]. It supports communication of characteristics
        (attributes) required for the lightpath(LSP) being requested. These
        characteristics include the desired link protection, the lightpath
        (LSP) encoding, and the lightpath (LSP) payload.
     
     6.1.4. Suggested Label TLV
     
        The Suggested Label TLV format and procedure are as defined in section
        3.4. of [4].
     
     6.1.5. Label Set TLV
     
        The format and the procedure of the Label Set TLV is as described in
        section 3.5. of [4].
     
     6.1.6. Service TLV
     
        The Service TLV defines the service attributes requested by the network
        client. The encoding for the Service TLV 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|F|   Service (0x0953)        |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Contact ID                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             Dir               | Trns  |       Reserved        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Propagation Delay                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Diversity TLV                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Bandwidth                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Contact Id:
          Contact Id is a 4-octet unsigned integer that uniquely identifies the
          lightpath owner. It is administratively used for call acceptance,
          billing, policy decisions, etc.
     
        Dir, Directionality
     
     
     
     
     
     
     Aboul-Magd                    April 2001                             8
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
          Dir is 16-bit field that specifies the directionality of the
          requested lightpath. The allowed values are:
     
          0x0000 = Uni-directional
          0x0001 = Bi-directional
          0x000n = Multi-Cast with n destinations
     
        Trans, Transparency
          Transparency is interpreted with respect to the LSP encoding and
          bandwidth. Trans is a 4-bit field that defines transparency
          requirements of the lightpath. For SONET/SDH the allowed values are:
     
          0x0 = PLR-C
          0x1 = STE-C
          0x2 = LTE-C
     
          There are no transparency options for PDH, Digital Wrapper, and
          Ethernet.
     
        Propagation Delay
          Propagation Delay is a 4-octet field. It indicates the maximum
          acceptable propagation delay in ms. The recommended encoding for this
          parameter is the 4-octet IEEE floating point number.
     
        Diversity TLV
          Diversity TLV lists all the other lightpaths from which the requested
          lightpath MUST be diverse. It also specifies the type of diversity.
          Diversity is only valid within a single routing domain. The encoding
          of the Diversity TLV 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|0| Diversity TLV (0x0954)    |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Lightpath Id TLV 1                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | DivT  |                    Reserved                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Lightpath Id TLV 2                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | DivT  |                    Reserved                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ~                           . . . . . . .                       ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Lightpath Id TLV n                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | DivT  |                    Reserved                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
     
     
     
     
     
     Aboul-Magd                    April 2001                             9
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
        Lightpath TLV n:
          is the Lightpath Id of the LSP from which the requested ligthpath
          must be diverse.
     
        DivT, Diversity Type
          DivT specifies the manner by which the requested lightpath should be
          diverse. The allowed values are:
     
          0x0 = Link diverse
          0x1 = Node diverse
          0x2 = Shared Risk Link Group (SRLG) diverse
     
        Bandwidth
          It defines the lightpath bandwidth. Bandwidth is a 4-Octet number in
          IEEE floating point format (the unit is bytes per second). Some
          bandwidth values are enumerated in section 3.1.4. of [4]
     
     6.1.7. Procedure
     
        The O-UNI Label Request Message flows between an optical network client
        and the edge optical network element. Upon initiating the Label Request
        Message, the optical client sets the addresses in the optical network
        for the two ends of the lightpath (Source Id and Destination Id TLVs).
        For initial setup (ActFlg=0), the lightpath Id is set to all 0s when
        sent from the client to the network. The lightpath Id is assigned by
        the optical networks. It is globally unique within the optical network.
        The Lightpath Id is obtained by combining the IPv4 address associated
        with the optical network element and an integer index that is locally
        unique. The Lightpath Id is passed to the called client in the Label
        Request Message from the network to the optical client.
     
        Upon the reception of the O-UNI Label Request Message, the edge optical
        network element might consult with a policy server to verify that the
        signaled attributes (including the verification of the Source and the
        Destination Ids) can be supported. Failure to support one or more of
        the lightpath attributes triggers the generation of the Notification
        Message with the appropriate error code.
     
        After passing the edge optical network verification process, the edge
        optical network constructs the generalized MPLS message for lightpath
        aetup across the optical network. The generalized Label Request Message
        extracts information from the O-UNI Label Request Message with regard
        to the Generalized Label Request TLV, the Suggested Label TLV, and the
        Label Set TLV, whenever applicable. The methods and procedures
        described in [4] are then followed for end-to-end path setup.
     
        Lightpath modification request is achieved by the owner client sending
        a Label Request Message with ActFlg=1. In this case the lightpath is
        left unchanged as initially assigned by the network.
     
     6.2. Label Mapping Message
     
     
     
     
     
     Aboul-Magd                    April 2001                            10
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
     
        The Label Mapping Message is as defined in 3.5.7 of [2] with the
        following modifications:
     
             - The Label Mapping Message procedures are limited to downstream
               on demand ordered control mode.
     
        The encoding of the O-UNI Label Mapping Message 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|  Label Mapping (0x0400)     |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              Message ID                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               FEC TLV                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               Generalized Label TLV    (O-UNI mandatory)      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               O-UNI Label Request Message ID TLV              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 Lightpath ID TLV   (O-UNI mandatory)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Source Id TLV (O-UNI mandatory)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Destination Id TLV (O-UNI mandatory)        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Service TLV (O-UNI optional)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Optional Parameters                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     6.2.1. Generalized Label TLV
        The Generalized Label TLV format and procedures are as in section 3.2.
        of [4].
     
     6.2.2. O-UNI Label Request Message ID TLV
     
        The O-UNI Label Request Message ID TLV has the same format and
        procedures as described in [7]
     
     6.2.3. Procedure
     
        The O-UNI Label Mapping Message flows between an optical network client
        and the edge optical network element.
     
        The reception of the O-UNI Label Mapping Message signifies the
        successful establishment of a lightpath with the desired attributes. It
        also signifies the successful modification of one or more of the
        lightpath attributes.
     
     
     
     
     
     Aboul-Magd                    April 2001                            11
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
     
        The network transports the assigned Lightpath Id to the calling client
        in the Label Mapping Message. This Lightpath Id value is used by the
        client and the network for the exchange of lightpath status
        information.
     
        The O-UNI Label Mapping Message also includes a Generalized Label TLV.
        Its purpose is to indicate to the client label value, e.g. which
        wavelength, to be used.
     
        The O-UNI Label Mapping Message optionally includes a Service TLV that
        summarizes the level of service extended from the optical network to
        its client. The Service TLV must be included for the cases where
        reserved lightpath attributes, e.g. its bandwidth, are different from
        those requested by the customer.
     
     6.3. The Label Release Message
     
        The format of the O-UNI Label Release Message 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|  Label Release (0x0403)     |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              Message ID                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               FEC TLV                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           Generalized Label TLV   (O-UNI Optional)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                Lightpath ID TLV (O-UNI mandatory)             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Optional Parameters                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     6.3.1. Procedure
     
        The procedure for the O-UNI Label Release Message is as described in
        section 3.5.11. of [2]. The O-UNI Label Release Message is sent by
        either the client or the network to indicate the desire to delete an
        already established lightpath. The O-UNI Label Release Message carries
        a mandatory lightpath Id to indicate which lightpath should be
        terminated.
     
     6.4. The Label Withdraw Message
     
        The format for the O-UNI Label Withdraw Message 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
     
     
     
     
     
     Aboul-Magd                    April 2001                            12
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|  Label Withdraw (0x0402)    |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              Message ID                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               FEC TLV                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                  Lightpath ID TLV (O-UNI mandatory)           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Optional Parameters                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     6.4.1. Procedure
     
        The procedure for the Label Withdraw Message follows that defined in
        section 3.5.10 of [2]. The Label Withdraw Message is sent by the
        network or the client in response to a Label Release Request.
     
        The Label withdraw Message for O-UNI carries a mandatory lightpath Id.
        The reception of the Label Withdraw Message acts as an indication to
        the client or the network that the lightpath defined by its Lightpath
        Id has been terminated.
     
     6.5. The Notification Message
     
        The Notification Message is as defined in section 3.5.1. of [2] with
        the following modifications:
     
        - The O-UNI Notification Message is sent autonomously from the network
        side of the O-UNI to the client to indicate the status of the lightpath
        request.
        - The O-UNI Notification Message includes a mandatory Lightpath Id TLV
     
        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|  Notification (0x0001)      |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              Message ID                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |              Lightpath Id TLV O-UNI (mandatory)               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |              O-UNI Label Request Message ID TLV               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Status TLV                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Optional Parameters                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Status TLV is as defined in section 3.4.6. of [2].
     
     
     
     
     
     
     Aboul-Magd                    April 2001                            13
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
     6.5.1. Procedure
     
        The O-UNI Notification Message is used by the optical network to signal
        to its clients failure condition during or after the connection
        establishment phase. New Status codes relevant to lightpath operation
        are:
     
        0x00001000 = not able to connect to destination user group
        0x00001001 = invalid destination address
        0x00001002 = invalid port Id
        0x00001003 = invalid channel Id
        0x00001004 = invalid sub-channel Id
        0x00001005 = bandwidth unavailable
        0x00001006 = protection mode unavailable
        0x00001007 = routing directive unavailable
        0x00001008 = failure to create lightpath
        0x00001009 = failure to modify lightpath
        0x0000100A = Failure to delete lightpath
        0x0000100B = Encoding unavailable
     
        If it has been already set, the Notification Messages includes the
        Lightpath Id TLV. If not set, e.g. for initial set up, the Lightpath Id
        TLV is set to 0. If the Lightpath Id is not set, the Notification
        Message MUST includes a O-UNI Label Request Message ID TLV as defined
        in section 6.2.2.
     
     6.6. The Status Enquiry Message
     
        The Status Enquiry Message is a new LDP message. The encoding for the
        Status Enquiry Message 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |U|F|Status Enquiry (0x0002)    |      Length                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              Message ID                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Lightpath ID TLV                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Optional Parameters                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     6.6.1 Procedure
     
        The Status Enquiry Message is sent by the client or the network at any
        time to solicit a Status Response Message from its peer. The lightpath
        under consideration is identified by the Lightpath Id TLV.
     
     6.7. The Status Response Message
     
     
     
     
     
     
     Aboul-Magd                    April 2001                            14
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
        The Status Response Message is a new LDP message. The encoding for the
        Status Response Message 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |U|F|    0x0003                 |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Message ID                              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Lightpath ID TLV                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Source Id TLV                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                  Destination ID  TLV                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Service TLV                             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Status TLV                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Optional Parameters                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     6.7.1 Procedure
     
        The Status Response Message is sent by either the client or the network
        in response to Status Enquiry Message. The Status TLV carries
        information that describes the current status of a connection
        (ligtpath) as defined by the Lightpath Id TLV. The status of the
        connection is encoded using the LDP Status TLV.
     
        The Status Response Message could optionally include lightpath
        attributes as defined by Source Id, Destination Id, and the level of
        service.
     
     6.7.1.1. Lightpath States
     
        Connection States at the client side of the interface are:
     
        - Null: no call exists
        - Call Initiated: this state exist for an outgoing call when the client
        sends the Label Request Message, but hasÆt yet received the Label
        Mapping Message from the network
        - Call Present: this state exist for an incoming call when the client
        receives the Label Request Message from the network, but hasnÆt yet
        responded to it
        - Active: This state exists for an incoming call when the client sends
        the Label Mapping Message to the network. The state also exist for an
        outgoing call when the initiating client receives the Label Mapping
        Message from the network.
     
     
     
     
     
     
     Aboul-Magd                    April 2001                            15
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
        - Release Request: this state exists when the client has requested the
        network to clear the end-to-end lightpath, i.e. the client sending the
        Label Release Message.
        - Release Indication: this state exists when the client has received an
        disconnect indication because the network has already disconnected the
        lightpath, i.e. when the client receives the Label Release Message.
     
        Similar connection states exist at the network side of the interface.
        The Status codes for the lightpath states are:
     
        0x0000100C = Null
        0x0000100D = Call Initiated
        0x0000100E = Call Present
        0x0000100F = Active
        0x00001010 = Release Request
        0x00001011 = Release Indication
     
     
     7. Security Considerations
     
        This security mechanisms defined in [2] shall be used.
     
     8. Author's Addresses
     
        Osama S. Aboul-Magd                          Raj Jain
        Nortel Networks                              Nayna Networks, Inc.
        P.O. Box 3511, Station ôCö                   157 Topaz St.
        Ottawa, Ontario, Canada                      Milpitas, CA 95035
        Canada                                       Phone: 408-956-8000x309
        Phone: 613-763-5827                          Fax: 408-956-8730
        Email: Osama@nortelnetworks.com              Email: Jain@nayna.com
     
     
        LiangYu Jia                                  Bala Rajagopalan
        ONI Systems Corp.                            Tellium, Inc.
        166 Baypoints Parkway                        2 Crescent Place
        San Jose, CA 95134                           Ocean Port, NJ 07757
        Phone: 408-965-2743                          Phone: 732-923-4237
        Fax: 408-965-2660                            Fax: 732-923-9804
        Email: ljia@oni.com                          Email:braja@tellium.com
     
     
        Robert Ronnison                              Yangguang Xu
        Laurel Networks                              Lucent Technologies
        2607 Nicholson Rd                            1600 Osgood St.
        Sewickley, PA 15143                          N. Anderson, MA 01845
        Phone: 724-933-7330                          Phone:978-960-6105
        Email:robren@laurelnetworks.com              Email:xuyg@lucent.com
     
     
        Zhensheng Zhang
     
     
     
     
     
     Aboul-Magd                    April 2001                            16
     
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
     
     
     
     
     
        Sorrento Networks
        9990 Mesa Rim Road
        San Diego, CA 92121
        Phone: 858-646-7195
        Email: zzhang@sorrentonet.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 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
     
     
     
     9. References
     
        1  Aboul-Magd, O. et. al., "Signaling Requirements at the IP-Optical
           Interface (UNI)" draft-ip-optical-uni-signaling-00.txt, work in
           progress, July 2000.
     
        2  Andersson, L., et. al., "LDP Specificationsö, draft-ietf-mpls-ldp-
           08.txt, work in progress, June 2000
     
        3  Bradner, S., "Key words for use in RFCs to Indicate Requirement
           Levels", BCP 14, RFC 2119, March 1997
     
        4  Ashwood-Smith, P. et. Al., "Generalized MPLS - Signaling Functional
           Descriptionö draft-ietf-mpls-generalized-signaling-00.txt, Work in
           Progress, October 2000.
     
        5  Ash, J., et, al., "LSP Modification Using CR-LDP", draft-ietf-mpls-
           crlsp-modify-01.txt, work in progress, Feb. 2000.
     
        6  Fox, B. and Gleeson, B., ôVPN Identifiersö, IETF RFC-2685, Sept.
           1999.
     
        7  Jamoussi, B. Editor, ôConstraint-Based LSP Setup Using LSPö, draft-
           ietf-mpls-cr-ldp-04.txt, work in progress, July 2000.
     
     
     
     
     
     
     
     
     Aboul-Magd                    April 2001                            17
     

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