MPLS Working Group                                     Osama                                        O. Aboul-Magd
Internet Draft                                           Sandra Ballare
Document: draft-ietf-mpls-ldp-optical-uni-01.txt          Ewart Tempest
                                                        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 Inc.

                                                        Robert Rennison
                                                        Laurel Networks

                                                           Yangguang Xu
                                                      Lucent Tech Technology

                                                        Zhensheng Zhang
                                                      Sorrento Networks
                                                               October, 2000

                                                              July 2001

  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. 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. 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].

   In OTNs using overlay model, clients request network services
   through a user network interface (UNI). This draft describes extensions to the LDP protocol
        [2] to support those requirements. The LDP
   necessary extensions described here
        address two areas:

        - The addition of new TLVs to support the attributes required for
        lightpath establishment at signaling support across the O-UNI optical UNI

Aboul-Magd                    April 2001               Expires January 2002                        1
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000

        - Two new

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   (O-UNI). LDP messages extensions are those needed to allow for satisfy the exchange of lightpath status
        information across main
   functions supported at the UNI. O-UNI. Those functions are: connection
   create, connection delete, connection modify, and connection status
   enquiry.

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]. [2].

3. Use of LDP Introduction

   Several models have been discussed for the O-UNI

        This draft describes how LDP with extensions will be used as a
        signaling mechanism for support of IP traffic
   over the O-UNI. Several O-UNI abstract messages transport layer (L1/L0) [3]. Three models are
        defined in [1]. This draft specifies how to use identified
   and are differentiated based on the existing LDP
        messages for that purpose. Two new LDP messages amount of routing/topological
   information exchanged between the optical transport network (OTN)
   and its clients. Those models are introduced to meet overlay, peer, and augmented
   models.

   In an overlay network architecture such as the requirements for ITU-T automatic
   switched OTN (ASTN) [4], there is a clear boundary between the exchange of status
   client and the network layers. Routing and topological information across
   does not cross this boundary in the O-
        UNI.

     3.1. Overview

        LDP sense that each layer is one running
   its own instant of a routing protocol, e.g. OSPF or entirely
   different routing protocols. Network clients request network
   services, e.g. connections, across a well-defined interface. This
   interface is generally called the candidate optical user network interface (O-
   UNI).

   MPLS based protocols described in [1] have already been proposed 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 realization
   of LDP session management the optical layer control plane in what is termed as generalized
   MPLS (GMPLS) [5]. Both CR-LDP [6] and RSVP-TE [7] have been extended
   for possible use as the control procedures
        - Additions plane signaling protocols. It
   therefore makes sense to use the already specified procedures for notification of
        errors.
        - The reuse same set of protocols for the
   implementation of the O-UNI. This draft introduces the necessary LDP security mechanism

        Support for
   [8] extensions to support the basic O-UNI signaling requirements depends upon functionality.

   At the use of O-UNI, four O-UNI actions are provided. Those actions are:

   - Connection Create: Creates an end-to-end connection across the following LDP behaviors and mechanisms OTN
     with specified connection attributes such as defined bandwidth, diversity,
     etc. Numerous connection attributes have been articulated in [2]. [9]

   - Use of Basic and/or Extended discovery mechanisms. Connection Delete: Deletes an already existing connection.

   - Use Connection Modify: Modifies one or more of the Label Request Message in downstream on demand label
        advertisement mode with ordered control.
        - Use connection
     attributes of the Label Mapping Message existing connections. Connection Modify is not
     supported in downstream on demand label
        advertisement mode with ordered control.
        - Use this version of the Notification Message. draft.

   - Use of Status Enquiry: Allows the Withdraw and Release Messages.

        Additional messages are defined client to support enquire the propagation of lightpath status of a
     connection or a group of connections. A connection can be in one

Aboul-Magd               Expires January 2002                        2

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

     of a number of states such as, active, redialing, etc [9]. This
     operation also allows querying connection information as defined in [1].

        Additional TLVs are specified order to
     recover connection state.

   Tightly related to support the lightpath attributes
        specified O-UNI, and any UNI in [1].

     Aboul-Magd                    April 2001                             2
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000

     4. O-UNI Session Management general, is the need to
   uniquely identify clients and Control

        LDP messages that relevant their points of attachment to the O-UNI session management and control
        are Hello Message, Initialization Message,
   network. An addressing scheme for the OTN has been discussed in [9].
   Client identification is based on a transport network address (TNA)
   that is globally unique and KeepAlive Message.

     4.1. Hello Message

        This draft does not change is assigned to the format or client by the procedures network
   provider. The scope of the LDP
        Hello Message as described in section 3.5.2. of [2].

     4.2. KeepAlive Message

        This draft does not change TNA could be on a one-to-one basis with
   logical links that the format network provider provision between an OTN
   network element (NE) and an OTN client, or it could be a single TNA
   per OTN (optical transport network) client. In 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 latter case there
   is the only label distribution mode supported at the O-UNI. The
        assignment A=0 should result in generating need to introduce a Notification Message with logical port identifier (LPI) to
   differentiate between multiple logical links between an OTN client
   and an OTN NE that share the appropriate error code.
        - Loop Detection same TNA address. Similar to the TNA,
   LPI is always disabled, D=0. The assignment D=1 should
        result in generating a Notification Message with assigned to the appropriate error
        code.

     5. The Use client by the network provider. Protocol
   extensions are required to support signaling of LDP Messages for the TNA and LPI.

   O-UNI

        A set reference models have been discussed in [9]. The client side
   of abstract the O-UNI messages is defined in [1]. Those abstract
        messages support has been denoted as UNI-C, while the basic functions of term UNI-N has
   been used to identify the optical UNI. Those
        functions are,

        - Lightpath Create: Creates a lightpath with certain attributes between
        two ends in network side of the optical networks

        - Lightpath Delete: Deletes an already existing lightpath

        - Lightpath Modify: Modifies one O-UNI. One or more of
   signaling channels exist between the attributes of already
        existing lightpath

        - Lightpath Status Enquiry: Enquires about UNI-C and UNI-N. The UNI
   control channel MUST support the status of an already
        existing lightpath

        Each transport of the above functions IP protocols. This
   capability is accomplished by a set of necessary since IP based protocols, e.g. LDP, are
   proposed for O-UNI messages
        using signaling.

4.0 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

   In extending LDP FEC TLV should be ignored for implementation at the O-UNI since it has no
        significance, and
        - The use O-UNI, there have been
   two main guiding principles. Firstly every effort was made to limit
   the introduction of new LDP messages. New messages for O-UNI does not change are only
   introduced whenever the semantics of
        the LDP Message ID.

     5.1. Lightpath Create Action

        Lightpath Create Action requires two desired functionality could not be supported
   by existing messages, the lightpath Create
        Request and have been limited to only those required
   to support the Lightpath Create Response. The mapping status enquiry function of the LDP
        messages O-UNI.

   Secondly care has been taken not to fulfill the lightpath create action is:

        - Lightpath Create Request: The create request function is achieved by violate any of the LDP Label Request Message. The Generalized Label Request TLV semantics
   as defined in [4] is used to convey some lightpath attributes [8]. Therefore LDP O-UNI extensions could easily be
   implemented as a simple add-on to the
        network side.
        - Lightpath Create Response: already existing LDP
   implementations.

   The create response function is achieved
        by the use mode of operation of the LDP Label Mapping Message. The create response
        function makes use of at the Generalized label defined in [4]. The Label
        Mapping procedures are limited to O-UNI is downstream on demand, ordered control
        mode with conservative
   demand 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 advertisement with ordered control.

4.1 LDP messages to fulfill the function of Session Initialization

   For the lightpath
        delete action is:

        - Lightpath Delete Request: The delete request is achieved by O-UNI the LDP
        Label Release Request Message. The Label Release Message session is sent from established between UNI-C and UNI-
   N. Furthermore the client or (UNI-C) MUST play the network at any time after active role during
   the establishment of LDP session initialization phase. Moreover, if all logical links
   are in the
        lightpath to delete it. same O-VPN,:

   - Lightpath Delete Response: The delete Response is achieved by the There will be a single LDP
        Label Withdraw Message. The Label Withdraw Message is sent from the session between an OTN client or and an
     OTN NE, regardless of the network in response to number of logical links between them.

Aboul-Magd               Expires January 2002                        3

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   - In the case of proxy signaling, there will be a Label Release Request.

     5.3. Lightpath Modify Action

        After single LDP session
     between a lightpath is setup, some proxy agent and an OTN NE regardless of its attributes, e.g. bandwidth, may
        need to be changed by the network operator due to new requiremenst for number of
     OTN clients and logical links the traffic carried proxy agent signals on that lightpath. Lightpath Modify Action does not
        require the definition of new LDP messages. behalf
     of.

   The modify action follows
        the procedure described in [5].

        Lightpath modification can only LDP Hello and Extended Hello SHALL be allowed when used for neighbor
   discovery as specified in [8].

   An LDP session starts by UNI-C sending an LDP Initialization message
   to its neighbor UNI-N over the lightpath is
        already established. The procedure TCP session. In addition to the
   parameters described in [5] allows for
        modification of lightpath attributes without service interruption. Only
        modifications requested by [8], the owner of a particular lightpath Initialization message from the
   UNI-C to the UNI-N contains all the O-UNI version numbers that are
        allowed.

     Aboul-Magd                    April 2001                             4
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000
   supported by the UNI-C.

   The UNI-N follows the procedure described specified in [5] for lightpath modification relies on the
        introduction section 2.5.3 of [8]
   for the Action Flag (ActFlg) field in passive LSR. It replies with an Initialization message to
   propose the Lightpath Id TLV
        (see section 6.1.3). Similar parameters it wishes to use. Those parameters MUST
   include the case in CR-LDP [7], highest version number from the ActFlg
        field indicates if list advertised by 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
   UNI-C that the UNI-N supports. If the UNI-C and Lightpath Status Response functions
        require UNI-N have no UNI
   version in common, the definition of two new LDP messages, session establishment will fail.

   The Status Enquiry
        Message Initialization message also includes a Contract ID TLV. Contract
   ID is determined by the network provider and identifies the Status Response Message. The encoding of contract
   agreement between the new
        messages is defined in sections 6.6 OTN client and 6.7.

     5.5. Notification Action

        The Notification function the OTN operator. Its format is similar in scope to that of
   determined by the CR-LDP
        Notification Message. Hence OTN operator.

   Maintaining the LDP Notification message is used across session at the O-UNI for this purpose.

     6. LDP Message Extensions

        This MUST follow the procedure
   explained in section gives detailed description 2.5.6 of [8].

4.2 Connection Create using LDP message extensions for

   In LDP, the connection create request is implemented using the support of O-UNI.

     6.1. Label
   Request Message message as defined in [8]. The LDP Label Request Message message is as defined in 3.5.8. of [2] with from
   the
        following modifications (required only if any source UNI-C to the source UNI-N. At the other end of O-UNI TLVs is included
        in the
   network the Label Request Message):

        - The FEC TLV message is ignored at sent from the O-UNI

        - destination UNI-N
   to destination UNI-C.

   The procedures requested connection might need to support a number of
   attributes. Extensions are needed to handle the Label Request Message message to
   support the client signaling of those attributes.

   OTN connections are augmented usually bi-directional. As in GMPLS, a bi-
   directional connection is signaled at the O-UNI by the procedures for processing inclusion of
   the O-UNI TLVs as defined Upstream Label 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 message. Reception of the
   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 message by the initiator (the
        calling party) destination UNI-C signifies the
   reservation success, i.e. all the requested connection attributes
   can be satisfied, of the lightpath creation request. bi-directional connection. However it
   doesnĂt imply that the connection is available for data transport.
   Connection is only available when configuration of intermediate
   cross connects is complete. The encoding Configuration of any intermediate
   cross connect likely to require some time to complete and, depending
   on the
        Source Id TLV is:

        0                   1                   2                   3
        0 1 2 3 technology used, this delay may be significant, e.g. in the
   order of 10's or 100's of ms.

Aboul-Magd               Expires January 2002                        4

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   The destination UNI-C sends a Label Mapping message in response to
   the Label Request message, only once it has setup its own switch
   fabric. If it so desires, the destination UNI-C MAY indicate to the
   source UNI_C that a reservation confirmation indication is needed.
   The reservation confirmation indication is implemented using the LDP
   Notification message with the status code ˘reservation_confirm÷. In
   general, Uni-directional connections do not require a reservation
   confirmation indication, and depending on the nature of the
   application on the destination OTN client that terminates the OTN
   connection, maybe not even in the case of bi-directional
   connections.

   Contention for labels may occur between two bidirectional connection
   setup requests traveling in opposite directions.  This contention
   occurs when both sides allocate the same resources (labels) at
   effectively the same time. To resolve contention, the node with the
   higher node ID will win the contention and it MUST issue a
   NOTIFICATION message with a "Routing problem/Label allocation
   failure" indication.  Upon receipt of such an error, the node SHOULD
   try to allocate a different Upstream label (and a different Suggested
   Label if used) to the bidirectional path.  However, if no other
   resources are available, the node must proceed with standard error
   handling.

   Similarly the source UNI-N sends a Label Mapping message to the
   source UNI-C. At this instant the transport connection is available
   to the source UNI-C for use provided that its own switch fabric have
   been setup. Figure 1 shows a timing diagram for a successful
   establishment of a bi-directional connection.

              UNI-C    UNI-N          UNI-N    UNI-C
                |       |               |       |
                |       |               |       |
        Label   |------>|               |       |
        Request |       |-------------->|       |  Label
                |       |               |------>|  Request
                |       |               |       |
                |       |               |       |
                |       |               |<------|  Label
        Label   |       |<--------------|       |  Mapping
        Mapping |<------|               |       |
                |       |               |       |
    Reservation |------>|               |       |  Reservation
        Confirm |       |               |------>|  Confirm
                |       |               |       |

          Figure 1: Successful Setup of Bi-Directional Connection

   The connection create request might fail for a number of reasons,
   e.g. no bandwidth available, no physical connectivity, SLA
   violation, connection rejected by far end OTN client. In this case
   failure of the create request is indicated to the source UNI-C using
   the LDP Notification message with the status code reflecting the

Aboul-Magd               Expires January 2002                        5

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   reason for the failure. Figure 2 shows a create request rejection by
   the netwok.

              UNI-C    UNI-N          UNI-N    UNI-C
                |       |               |       |
                |       |               |       |
        Label   |------>|               |       |
        Request |       |               |       |
                |       |               |       |
                |       |               |       |
   Notification |<------|               |       |
                |       |               |       |

            Figure 2: Connection Setup Rejection by the Network

   Should a client desire to abort the connection create process after
   sending the Label Request message, an LDP Abort message MUST be sent
   as defined in section 3.5.9. of [8]. Specifically the Message ID
   used in the Label Request Message is used in the Abort Message as
   the temporary local connection identifier.

4.3 Connection Deletion Using LDP

   LDP employs two mechanisms for an LSR (label switched router) to
   inform its peer to stop using a particular label. The first method
   is based on the use of Label Withdraw message and it is used to
   signal to a peer that the peer may not continue to use a specific
   label mapping that the LSR has previously advertised. The second
   method is based on the use of Label Release message and it is sent
   to signal to a peer that the LSR no longer needs a specific label
   mapping previously requested and/or advertised by the peer.

   The O-UNI LDP extensions make use of the Label Release and Label
   Withdraw messages for connection deletion. The choice of which
   message to use depends on the entity that initiates the deletion.
   The Label Withdraw message is used for the case where the connection
   deletion is in the upstream direction. As per the LDP procedure in
   section 3.5.10 of [8], Label Release message is used in this case to
   acknowledge the delete request.

   The Label Release message is used for the cases where connection
   deletion is in the downstream direction. In this case the delete
   request is confirmed by the use of LDP Notification message with the
   status code "delete_success".

   Figures 3 and 4 show graceful connection deletion requested by the
   source UNI-C and the destination UNI-C respectively.

                 UNI-C    UNI-N          UNI-N    UNI-C
                   |       |               |       |
                   |       |               |       |
    Notification   |------>|               |       |
                   |       |-------------->|       |

Aboul-Magd               Expires January 2002                        6

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

                   |       |               |------>| Notification
                   |       |               |       |
                   |       |               |<------| Label Withdraw
                   |       |<--------------|       |
    Label Withdraw |<------|               |       |
    Label release  |------>|               |       |
                   |       |-------------->|       |
                   |       |               |------>| Label Release
                   |       |               |       |

        Figure 3: Graceful Connection Deletion by the Source UNI-C

                 UNI-C    UNI-N          UNI-N    UNI-C
                   |       |               |       |
                   |       |               |<------| Notification
                   |       |<--------------|       |
    Notification   |<------|               |       |
    Label Release  |------>|               |       |
                   |       |-------------->|       |
                   |       |               |------>| Label Release
                   |       |               |<------| Notification
                   |       |<--------------|       |
     Notification  |<------|               |       |
                   |       |               |       |

      Figure 4: Graceful Connection Deletion by the Destination UNI-C

   Figure 3 shows that the delete request is preceded by an LDP
   Notification message with status code ˘delete_indication÷. In all
   optical networks, loss of light will propagate faster than the
   delete request. Thus downstream NE will detect loss of light and
   potentially alarm on it. This alarm could be used to incorrectly
   trigger restoration and/or protection. To address this issue, a
   Notification message SHOULD be sent along the connection's route to
   inform all nodes of the intended deletion. Upon the receipt of this
   message, each node SHOULD disable its alarm reporting and protection
   mechanisms on the indicated connection.

   Figure 5 shows a connection deletion scenario initiated by the
   network, or a force deletion requested from an OAM entity. In this
   case both Label Withdraw and Label Release messages are used to
   initiate the deletion request.

              UNI-C    UNI-N          UNI-N    UNI-C
                |       |               |       |
                |       |               |       |
      Label     |<------|               |------>| Label
     Withdraw   |       |               |       |  Release
                |       |               |       |
        Label   |------>|               |<------|

Aboul-Magd               Expires January 2002                        7

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

        Release |       |               |       |Notification
                |       |               |       |

          Figure 5: Connection Deletion Initiated by the Network

4.4 Failure Detection and Recovery Using LDP

   In optical transport networks, failures in the out-of-fiber
   signaling communication or optical UNI control plane should not have
   service impact on the existing optical connections. Under such
   circumstances, a mechanism MUST exist to detect a signaling
   communication failure and a recovery procedure SHALL guarantee
   connection integrity at both UNI-C and UNI-N.

   The LDP Keep Alive mechanism MUST be used to detect signaling
   communication failures between a UNI-C and a UNI-N, unless an
   alternative mechanism is in place to detect such failures more
   efficiently. During the signaling communication failure all active
   connections are maintained (the bearer connection is active) and all
   transient connections (in-progress) are cleared.

   Upon signaling communication re-establishment (i.e. re-establishment
   of LDP Keep Alive) a resynchronization period is required in order
   to synchronize connection state information across the UNI. This
   synchronization period shall be performed prior to processing new
   connection requests.

   The resynchronization period starts by the UNI-C either querying the
   network (UNI-N) for the (summary or detailed) states of all
   connections associated with a particular logical link, or otherwise
   (implicitly or explicitly) deleting them. In the former case, the
   UNI-N will respond with appropriate status information. The OTN is
   the master of all oTN connection information. An OTN connection,
   once created, remains within the OTN until implicitly or explicitly
   deleted by either of the terminating OTN clients through UNI
   signaling, or via OTN operator intervention. Specifically the burden
   is on the OTN client to resynchronize with the OTN. Under no
   circumstances will the OTN resynchronize with its OTN connection
   view with that of an OTN client.

   There are three cases to consider during recovery:

   a) Both UNI-C and UNI-N have retained connection information during
     the signaling communication failure.  In this case, the recovery
     consists of synchronizing connection state information.  This
     synchronization process requires UNI-C to send Status Enquiry
     messages requesting summary connection information.

   b) The client device lost all connection information in its UNI-C
     control plane during the signaling communication failure. In this
     case, the recovery procedure requires the UNI-C to query each
     connection to its peer UNI-N in order to rebuild the connection
     state information. This can be performed using the Status Enquiry

Aboul-Magd               Expires January 2002                        8

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

     message(s) requesting detailed connection information based on LDP
     session, logical link or TNA address.

   c) The client device lost all connection information in its UNI-C
     control plane and requires all OTN connections to be deleted on:

     - A per LDP session basis.
     - A specific logical link
     - All logical links that share a specified TNA address

     In this case, the synchronization is a simple restart process that
     can be achieved by sending a Label Release message with the
     corresponding TNA and optional logical port parameters. Figure 6
     shows the scenario for graceful and forced deletion of all
     connection in this case (for the purpose of simplicity, the
     diagram assumes that the OTN connections to be deleted all
     terminate on the same destination OTN client. In reality, this
     will almost certainly not be the case). Graceful deletion is
     indicated by source UNI-N sending a Notification message
     indicating the intended delete. This Notification message is
     OPTIONALLY sent in response to the source UNI-C Label Release
     message. For multiple destinations a separate Notification message
     SHLL be sent per destination.

                 UNI-C    UNI-N          UNI-N    UNI-C
                   |       |               |       |
    Label Release  |------>|               |       |
                   |       |-------------->|       |
                   |       |               |------>| Notification
                   |       |               |<------| Label Withdraw
                   |       |<--------------|       |
                   |       |               |       |
                   |       |-------------->|       |
                   |       |               |       |
                   |       |               |------>| Label Release
     Notification  |<------|               |       |
                   |       |               |       |

                   Figure 6: Deletion of All Connections

   Resynchronization is deemed to be complete between a given OTN
   client and OTN NE when each connection for which OTN NE knows about
   is either queried or deleted by the OTN client. Until such time, no
   new connections can be established for which the OTN client would be
   a terminating point.

5.0 LDP Extensions for O-UNI

   This section describes LDP extensions specific for the support of
   signaling across the optical UNI.

5.1 TLV Encoding for Commonly Used Parameters

Aboul-Magd               Expires January 2002                        9

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   The TLV encoding described in section 3.4 of [8] and in [10] MUST be
   applicable at the O-UNI. This section describes the O-UNI specific
   TLV encoding.

5.1.1 Src ID TLV

   A client used the Src ID TLV to indicate its identification
   parameters. The Src ID TLV MUST contain the source TNA, and
   OPTIONALLY contain a Logical Link ID. The encoding for the Src ID
   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|    Src TNA Value          |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            Src TNA                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Logical Port ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Src TNA:
     Src TNA can be in one of three formats [9]. It can be in either
     IPv4, IPv6, or NSAP format. Only TNA addresses of the same type
     can be compared for equivalence. The Src TNA values are:

         Value              Type
        -------           -------
         0x960             IPv4
         0x961             IPv6
         0x962             NSAP

     The NSAP format is structured according to ISO/IEC 8348, 1993
     (identical to ITU X.213, 1992)

     Only TNA addresses of the same type SHOULD be compared for
     equality.

   Logical Port ID:
     A 32-bit unsigned number indicating identifying a logical port at
     the source OTN NE. Logical Port ID is OPTIONAL and, as such, may
     not be present.

5.1.2 Dest ID TLV

   Dest ID TLV is used to identify the destination end of the
   connection. The Dest ID TLV encoding 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|    Dest TNA Value         |      Length                   |

Aboul-Magd               Expires January 2002                       10

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Dest TNA                                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Logical Port ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Dest TNA:
     Similar to the Src TLV, the following values MUST be supported

         Value              Type
        -------           -------
         0x963             IPv4
         0x964             IPv6
         0x965             NSAP

     The NSAP format is structured according to ISO/IEC 8348, 1993
     (identical to ITU X.213, 1992)

     Only TNA addresses of the same type SHOULD be compared for
     equality.

   Logical Port ID:
     A 32-bit unsigned number indicating identifying a logical port at
     the destination client device. Logical Port ID is OPTIONAL and, as
     such, may not be present.

5.1.3 Egress Label TLV

   Egress Label TLV is an OPTIONAL O-UNI defined TLV. Egress Label TLV,
   when present, indicates the egress label to be used at the
   destination end of the O-UNI. The encoding for the Egress Label 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|    Egress Lbl (0x0957)    |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                          |L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Label                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   L-bit:
     If L=0, then the Label value MUST be copied into Label Set TLV in
     the corresponding outgoing Label Request message from the
     destination UNI-N to destination UNI-C. If L=1, then the Label
     value MUST be copied into an Upstream Label TLV in corresponding
     outgoing Label Request message from the destination UNI-N to the
     destination UNI-C. As such, the Label Request message originated

Aboul-Magd               Expires January 2002                       11

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

     by the source UNI-C may contain up to two Egress Label TLVs, one
     with the L-bit set, and the other with the L-bit not set.

5.1.4. Connection ID TLV

   The Connection ID TLV is used to uniquely identify a connection
   established by the network. The format of the Connection ID 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| Connection ID (0x0952)    |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved                                         |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Connection ID                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   C-bit:
     The value of the C bit is set by the destination UNI-C whenever a
     reservation confirmation indication is needed.

   Connection ID:
     Connection ID has a variable length in multiple of 32, and is at
     least 64 bits wide.

5.1.5 Diversity TLV

   Diversity TLV lists all the other connections from which the
   requested connection MUST be diverse. It also specifies the type of
   diversity. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| Diversity TLV (0x0954)    |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Connection ID TLV 1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Reserved                           | DivT  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           . . . . . . .                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Connection ID TLV n                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Reserved                       | DivT  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Connection ID TLV i:
      This is the Connection ID of an existing connection from which
      the requested connection must be diverse.

Aboul-Magd               Expires January 2002                       12

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   DivT (Diversity Type):
      DivT specifies the manner by which the requested connection
      should be diverse. The allowed values are:

      0x0 = Link diverse
      0x1 = Node diverse
      0x2 = Shared Risk Link Group (SRLG) diverse
      0x3 = Link non-diverse
      0x4 = Node non-diverse
      0x5 = SRLG non-diverse

5.1.6 Contract 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|Contract ID TLV (0x0956)     |      Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Contract ID                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Contract ID:
      This is a variable-length string of characters whose format will
      be determined by the OTN provider. Contract ID identifies the
      contracted service level agreement (SLA) that the OTN client has
      with the OTN operator, and in whose context the connection setup
      request is made. Contract IDs therefore only have local
      significance between an OTN client and an OTN NE.

5.1.8 O-UNI Service TLV

   The O-UNI Service TLV describes connection attributes in terms of
   restoration and routing diversity. The encoding of the O-UNI Service
   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)
   |U|F|   O-UNI Service (0x0953)  |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Node Address                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Port ID           Reserved            | Channel Id     Service Level             | Sub-channel ID|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
        +              Source User Group                +-+-+-+-+-+-+-+-+
        |                                               |  Reserved                        Diversity TLV                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        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

   Service Level:
     A Service Level corresponds to the specified Port Id.

        Sub-Channel Id: carrier-defined characteristics
     such as time to restore, BER, bumping priority, etc.

5.1.9 O-UNI Version Number TLV

Aboul-Magd                    April               Expires January 2002                       13

Draft-ietf-mpls-ldp-optical-uni-01                          July, 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 O-UNI Version Number TLV has the same structure as the Source Id TLV. The
        format is of the Destination Id TLV is: form:

    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
   |U|F|Version Num TLV

        The format of the Lightpath Id is as follows:

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |U|F| lightpath Id (0x0952) (0x0955)   |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved                                   | ActFlg|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          optical network element IPv4 address                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Major Vesrion Number        |                             Index       Minor Version Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        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

   Minor version number 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 set relative to 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 major version number.

5.2 LDP Message Extensions for O-UNI

   This section 3.1 of [4]. It supports communication of characteristics
        (attributes) required describes the necessary extensions for LDP messages for
   the lightpath(LSP) being requested. These
        characteristics include support of signaling across the desired link protection, O-UNI. This section also
   includes the lightpath
        (LSP) encoding, and definition of the lightpath (LSP) payload.

     6.1.4. Suggested Label TLV

        The Suggested Label TLV format and procedure two new messages needed for status
   enquiry. Those messages are as defined in section
        3.4. of [4].

     6.1.5. Label Set TLV Status Enquiry message and Status
   Response Message.

5.2.1 Hello Message

   The format and the procedure of for the Label Set TLV Hello message is as described defined in
   section 3.5. of [4].

     6.1.6. Service TLV

        The Service TLV defines the service attributes requested by the network
        client. 3.5.2 in [8].

5.2.2 Initialization Message

   The encoding for the Service TLV is as follows: Initialization 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|   Service (0x0953)
   |0|   Initialization (0x0200)   |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Contact                             Message ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Dir                 Common Session Parameters TLV                 | Trns
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved         O-UNI Version Number TLV  (O-UNI Mandatory)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Propagation Delay          O-UNI Version Number TLV (O-UNI Mandatory)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Diversity             Contract ID TLV (O-UNI Mandatory)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Bandwidth                   Optional Parameters                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        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 initialization message procedure is interpreted with respect to the LSP encoding as described in section 2.5.
   in [8] and
          bandwidth. Trans is a 4-bit field that defines transparency
          requirements section 4.1 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 draft.

   Message ID is the 4-octet IEEE floating point number.

        Diversity TLV
          Diversity as defined in section 3.5. in [8]. Common Session
   Parameter 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. as defined in section 3.5.3 in [8].

Aboul-Magd               Expires January 2002                       14

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   The currently defined values for the O-UNI version Number are:

     For OIF Demo UNI:
         Major Version Number = 0x0000, Minor Version Number = 0x0001

     For OIF UNI 1.0:
         Major Version Number = 0x0001, Minor Version Number = 0x0000

5.2.3 Label Request Message

   The encoding of the Diversity TLV is as follows: Label Request Message for O-UNI 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| Diversity TLV (0x0954)
   |0|  Label Request (0x0401)     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Lightpath Id                              Message ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               FEC TLV 1                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DivT                 Src ID TLV  (UNI mandatory)                   |                    Reserved
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Dest ID TLV TLV (UNI mandatory)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Lightpath Id                 Egress Label TLV 2  (UNI Optional)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DivT               Connection ID TLV   (UNI mandatory)             |                    Reserved
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Generalized Label Request TLV (UNI mandatory)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ~                           . . . . . . .                       ~
   |             O-UNI Service TLV    (UNI mandatory)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Lightpath Id     SONET/SDH Traffic Parameters TLV n    (UNI mandatory)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DivT             Upstream Label TLV   (UNI optional)               |                    Reserved
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Suggested Label TLV   (UNI optional)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Aboul-Magd                    April 2001                             9
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000

        Lightpath
   |            Label Set TLV n:         (UNI optional)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Parameters                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Label Request Message is sent from:

   - the Lightpath Id of source UNI-C to source UNI-N to indicate an outgoing
     connection request;
   - the LSP from which destination UNI-N to the requested ligthpath
          must be diverse.

        DivT, Diversity Type
          DivT specifies destination UNI-C to indicate an
     incoming connection request.

Aboul-Magd               Expires January 2002                       15

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   How the manner by which Label Request message is propagated through OTN from 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
   source UNI-N to the lightpath bandwidth. Bandwidth is a 4-Octet number in
          IEEE floating point format (the unit destination UNI-N 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 outside the edge optical network element. Upon initiating scope of this
   specification.

   In the Label Request Message, the optical client sets the addresses in the optical network
        for initiating UNI-C identifies the
   two ends of the lightpath (Source Id connection termination points (Src 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. Dest ID TLVs). The lightpath Id UNI-N
   is assigned by
        the optical networks. It expected to assign a Connection ID that is globally unique within the optical
   transport 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 Connection ID is passed to the called client terminating
   UNI-C in the Label Request Message from the network to by the optical client. destination UNI-N.

   Upon the reception of the O-UNI Label Request Message, the edge optical
        network element might consult with a policy server to source UNI-N
   should verify that the signaled attributes (including the verification validity
   of the Source and the Destination Ids) IDs) can be supported. Failure to
   support one or more of the lightpath connection 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 Message
        extracts information from ID should be used as a local
   connection identifier, until such a time when the O-UNI Label Request Message with regard network-assigned
   Connection ID is sent back to the Generalized source client. As stated in [8],
   since LSRs use 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 message IDs as transaction identifiers,
   an LSR SHOULD NOT reuse the owner client sending Message ID of a Label Request Message with ActFlg=1. In this case message
   until the lightpath is
        left unchanged as initially assigned by corresponding transaction completers. Thus the network.

     6.2. local
   connection identifier has a very limited lifespan.

5.2.4 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 format of [2] with the
        following modifications:

             - The Label Mapping Message procedures are limited to downstream
               on demand ordered control mode.

        The encoding of message for the O-UNI Label Mapping Message is as follows: 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|  Label Mapping (0x0400)     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Message ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               FEC TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Generalized Label TLV    (O-UNI    (UNI mandatory)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               O-UNI               UNI Label Request Message ID TLV                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Lightpath                 Connection ID TLV   (O-UNI mandatory)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Source Id TLV (O-UNI mandatory)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Destination Id TLV (O-UNI   (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 Mapping message procedure for the same format and
        procedures as described in [7]

     6.2.3. Procedure O-UNI is limited to
   downstream on demand ordered control mode. The O-UNI UNI Label Mapping
   Message flows between an optical network client
        and the edge optical network element. between:

   - The reception of the O-UNI destination UNI-C to destination UNI-N in response to a Label Mapping Message signifies
     Request message;

Aboul-Magd               Expires January 2002                       16

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   - The source UNI-N to the source UNI-C to indicate 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 connection requested previously.

   The network transports the assigned Lightpath Id Connection ID to the calling
   client (source UNI-C) 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,

   A terminating UNI-C that desires to be used.

        The O-UNI Label Mapping Message optionally includes receive a Service TLV that
        summarizes the level of service extended reservation
   confirmation from the optical network to
        its client. The Service TLV must be included for initiating UNI-C MUST set the cases where
        reserved lightpath attributes, e.g. its bandwidth, are different from
        those requested by C-bit in the customer.

     6.3. The
   Connection ID TLV.

5.2.5 Label Release Message

   The format of encoding for the O-UNI Label Release Message is as follows: message at the O-UNI 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|  Label Release (0x0403)     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Message ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               FEC TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Generalized Label                        Connection ID TLV   (O-UNI Optional)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Lightpath                        Src ID TLV (O-UNI mandatory)                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     6.3.1. Procedure

   The procedure for the O-UNI LDP Label Release Message is as described used for connection deletion in
        section 3.5.11. of [2]. the
   downstream direction, e.g. when the connection termination is
   initiated by the destination UNI-C (graceful OTN connection
   deletion) / source UNI-C (non-graceful OTN connection deletion). The
   O-UNI Label Release Message is sent by:

   - The source UNI-C to source UNI-N to request the deletion a
   connection;

   - The destination UNI-N to a destination UNI-C to indicate the
     deletion of a connection by
        either the client or network.

   For the optical UNI, the receiver of the Label Release Message must
   respond with a Notification Message with the appropriate status code
   indicating the success of the delete request.

   Either the Connection ID TLV or the Src ID TLV MUST be included in
   the Label Release Message. When the network to indicate Connection ID TLV is included,
   it is an indication that the desire connection identified by this ID is the
   one to delete an
        already established lightpath. be deleted. The O-UNI Label Release Message carries Src ID TLV will only be present if a mandatory lightpath Id forced
   (i.e. non graceful) OTN connection deletion is to indicate which lightpath should be
        terminated.

     6.4. The performed.

   When the Src ID TLV is included, it is an indication to the network
   that the source UNI-C requires deletion of all the connections

Aboul-Magd               Expires January 2002                       17

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   associated with the specified logical link. This feature is
   primarily used for forced deletion of connections in failure
   recovery.

5.2.6 Label Withdraw Message

   The format encoding for the O-UNI Label Withdraw Message is as follows: message at the O-UNI 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

     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                  Connection ID TLV (O-UNI mandatory) (UNI Mandatory)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Parameters                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     6.4.1. Procedure

   The LDP Label Withdraw message is used for connection deletion in
   the upstream direction, e.g. when the connection termination is
   initiated by the destination UNI-C (non-graceful OTN connection
   deletion) / source UNI-C (graceful OTN connection deletion). The UNI
   Label Withdraw Message is sent by:

   - The destination UNI-C to destination UNI-N to request the deletion
     of a connection
   - The source UNI-N to the source UNI-C to indicate the deletion of
     the connection by the network.

   The procedure for the Label Withdraw Message follows that is defined in section
   3.5.10 of [2]. [8]. The recipient of the Label Withdraw Message is sent by the
        network or the client in response to MUST
   respond with a Label Release Request. message as in [8]. The Label withdraw Message Withdraw
   message for O-UNI UNI carries a mandatory lightpath Id.
        The reception of the Connection ID.

5.2.7 Label Withdraw Abort Message acts as an indication to
        the client or

   The format and the network that procedure of the lightpath defined by its Lightpath
        Id has been terminated.

     6.5. The Notification Message

        The Notification Message is Label Abort message are as defined given
   in section 3.5.1. 3.5.9 of [2] with
        the following modifications:

        - The O-UNI [8].

5.2.8 Notification Message is sent autonomously from the network
        side

   The format of the O-UNI to the client to indicate the status of Notification for the lightpath
        request.
        - The O-UNI Notification Message includes a mandatory Lightpath 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|  Notification (0x0001)      |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Message ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Aboul-Magd               Expires January 2002                       18

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   |              Lightpath Id                       Connection ID TLV O-UNI (mandatory)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              O-UNI              Label Request Message ID TLV                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Status TLV                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Parameters                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The UNI Notification Message must be forwarded towards the entity
   originating the Label Request, Label Release, 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 Enquiry, or
   Abort.

   The O-UNI Notification Message is used by message plays a number of roles within the optical network O-UNI:

   - A failed connection setup event is indicated to signal the source UNI-C
     using a Notification message. In this case, the Notification
     message is generated in response to a Label Request message before
     the source client has been made aware of its clients failure condition during or after associated Connection
     ID. Therefore, in this case, the Notification message MUST include
     the Label Request Message ID TLV that specifies the Message ID of
     the Label Request message of the failed setup (and which
     constitutes the source OTN client local connection
        establishment phase. New identifier).
     The Status codes relevant to lightpath operation
        are:

        0x00001000 = not able to connect TLV MUST include the status code for the cause of the
     failed setup, e.g. "no_bandwidth_available".

   - A Notification message is needed 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 initiate graceful deletion of
     a single OTN connection. In this case the Notification message
     MUST include the Connection ID of the connection to create lightpath
        0x00001009 = failure be deleted.
     The "delete_indication" status code must be included.

   - A Notification message is sent in response to modify lightpath
        0x0000100A = Failure a connection
     deletion in the downstream direction, i.e. initiated by a Label
     Release message. In this case the Status TLV MUST include the
     status code for "delete_success". The Notification message can be
     sent in response to delete lightpath
        0x0000100B = Encoding unavailable

        If it has been already set, a single connection deletion or the deletion
     of all the connection associated with a source identification
     point (LDP session, logical link, or TNA address). For single
     connection deletion the Notification message MUST include the
     Connection ID of the Notification Messages includes deleted connection. When used to acknowledge
     the
        Lightpath Id TLV. If deletion of a group of connections, the Notification message
     MUST not set, e.g. contain IDs of any of the connections that were deleted.

   - A Notification message is sent for initial set up, those cases where the
     destination UNI-C requests a reservation confirmation indication
     from the source UNI-C. In this case the Lightpath Id status TLV MUST include
     the "reserv_confirm" status code.

   - A Notification message is set sent for those cases where the source
     UNI-C attempts to 0. If abort a connection request after sending the Lightpath Id
     Label Request Message. The Notification message is not set, sent in
     response to an Abort message. In this case the Notification
        Message
     message MUST includes a O-UNI include the Label Request Message ID TLV as defined
        in section 6.2.2.

     6.6. TLV.

Aboul-Magd               Expires January 2002                       19

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   The use of the Notification message for the O-UNI includes those
   procedures that are specified in [8].

5.2.9 Status Enquiry Message

   The Status Enquiry Message is a new LDP message. message that is defined specifically
   for LDP applications for O-UNI signaling. 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
   |U|F| Status Enquiry (0x0002) (0x0420)   |        Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Lightpath                        Reserved                             |S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Src ID TLV 1                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Src ID TLV m                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Connection ID TLV 1                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Connection ID TLV n                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Parameters                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     6.6.1 Procedure

   The Status Enquiry Message message allows a client to enquire about the
   status of a connection or group of connections for which the client
   is sent an end point.

   When a Src ID TLV is present in the Status Enquiry message, the
   client is in effect requesting the status of all connections
   associated with the specified logical link.

   When a Connection ID TLV is present in the Status Enquiry message,
   the client is requesting the status of this particular connection.

   Status Enquiry can be generated by the client or at any time. The
   Status Enquiry message is used to enquire about status of already
   existing connections.

   S-bit:

Aboul-Magd               Expires January 2002                       20

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

     Whenever the S bit is set, S=1, it indicates that the Status
     Enquiry message is for summary information. In that case the network at any
        time to solicit a
     Status Response Message from its peer. The lightpath
        under consideration is identified by message contains summary information (Connection
     ID and connection Status) of the Lightpath Id TLV.

     6.7. The specified connections. Otherwise,
     S=0, detailed information is requested.

5.2.10 Status Response Message

     Aboul-Magd                    April 2001                            14
        Draft-ietf-mpls-ldp-optical-uni-00.txt             October 2000

   The Status Response Message message is a new LDP message. message that is defined
   specifically for LDP applications for O-UNI. The encoding for the
   Status Response Message 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 Status Response (0x0421)  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Lightpath                    Connection ID TLV 1                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Src ID TLV                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Id                     Dest ID TLV TLV                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Destination                     Egress Label TLV                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    O-UNI Service TLV                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               SONET/SDH Traffic Parameters TLV                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Label TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Upstream Label TLV                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Status TLV                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Connection ID TLV n                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Src ID TLV                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Dest ID TLV TLV                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Egress Label TLV                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    O-UNI Service TLV                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               SONET/SDH Traffic Parameters TLV                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Label TLV                                   |

Aboul-Magd               Expires January 2002                       21

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Upstream Label TLV                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Status TLV                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Parameters                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     6.7.1 Procedure

   The Status Response Message message is sent by either the client or the network generated in response to a Status
   Enquiry Message. message. The Status TLV carries Response message contains information that describes the current status of a connection
        (ligtpath) as defined by
   regarding the Lightpath Id TLV. The status of those connections (implicitly or explicitly)
   specified in the
        connection is encoded using the LDP Status TLV. Enquiry message to which it is a response.
   The amount information included in 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 message
   depends on the client side of whether the interface are:

        - Null: no call exists
        - Call Initiated: this state exist Status Enquiry is for an outgoing call when the client
        sends the Label Request Message, but hasĂt yet received the Label
        Mapping Message from summary or detailed
   information.

6.0 Status Code Summary

   The following are the network
        - Call Present: status codes defined for this state version of LDP
   O-UNI protocol.

   0x000000xx = destination_not_reachable
   0x000000xx = invalid_destination_TNA
   0x000000xx = bandwidth_unavailable
   0x000000xx = protection_mode_unavailable
   0x000000xx = routing_directive_unavailable
   0x000000xx = Failure_to_delete_connection
   0x000000xx = Encoding_unavailable
   0x000000xx = bad_egress_label
   0x000000xx = delete_indication
   0x000000xx = delete_success
   0x000000xx = reserv_confirm
   0x000000xx = abort_complete

   0x000000xx = Connection active
   0x000000xx = Connection doesn't exist for an incoming call when the client
        receives
   0x000000xx = Connection unavailable
   0x000000xx = Connection dropped by far end
   0x000000xx = Connection Pending

7. IANA Consideration

   This draft requires the Label Request Message use of a number of new messages, TLVs, and
   status codes from the network, but hasnĂt yet
        responded to it
        - Active: This state exists for an incoming call when number spaces within the client sends LDP protocol.

   The two new messages (sections 5.2.9 and 5.2.10) and the Label Mapping Message eight new
   TLVs (sections 5.1.1 to 5.1.8) should be considered as part of LDP
   base protocol and be assigned message and TLV types accordingly as
   outlined in [8]. All the network. The state also values given in this draft should be
   interpreted as advisory. There does not exist for an
        outgoing call when the initiating client receives the Label Mapping
        Message from the network. a preference to what
   values should be used.

Aboul-Magd                    April               Expires January 2002                       22

Draft-ietf-mpls-ldp-optical-uni-01                          July, 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 authors' current understanding is that MPLS status codes are not
   sub-divided into specific ranges for different types of error. Hence,
   the
        Label Release Message.
        - Release Indication: numeric status code values assigned for 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 draft should simply
   be the Label Release Message.

        Similar connection states exist next available values at the network side time of the interface.
        The Status codes writing and may be
   substituted for other numeric values. See section "Status Codes" for
   details of the lightpath states are:

        0x0000100C = Null
        0x0000100D = Call Initiated
        0x0000100E = Call Present
        0x0000100F = Active
        0x00001010 = Release Request
        0x00001011 = Release Indication

     7. status codes defined in this draft.

8. Security Considerations

   This draft doesn't introduce any new security mechanisms defined issues other than
   those in [8].

9. References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   3  B. Rajagopalan, "IP over Optical Networks: A Framework", draft-
      ietf-ipo-framework-oo.txt, work in [2] shall be used.

     8. progress, July 2001.

   4  Mayer, M. Ed., "Requirements for Automatic Switched Transport
      Networks (ASTN)", ITU G.807/Y.1301, V1.0, May 2001.

   5  Ashwood-Smith, P. et. al., "Generalized MPLS- Signaling
      Functional Description", draft-ietf-mpls-generalized-signaling-
      04.txt, work in progress, May. 2001

   6  Ashoowd-Smith, P. et. al., "Generalized MPLS Signaling: CR-LDP
      Extensions", draft-ietf-mpls-generalized-cr-ldp-03.txt, work in
      progress, May 2001

   7  Ashwood-Smith, P. et. al., "Generalized MPLS Signaling: RSVP-TE
      Extensions", draft-ietf-mpls-generalized-rsvp-te-03.txt, work in
      progress, May 2000.

   8  Anderson, L., et. al., "LDP Specification", RFC 3036, January
      2001.

   9  Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0
      Signaling Specifications", OIF Contribution, OIF2000.125.5, June
      2001

   10 Jamoussi, B., "Constraint-Based LSP Setup using LDP", draft-ietf-
      mpls-cr-ldp-04.txt, work in progress, July 2000.

Aboul-Magd               Expires January 2002                       23

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

10. Author's Addresses

   Osama S. Aboul-Magd                          Raj Jain
   Nortel Networks                              Nayna Networks, Inc.
   P.O. Box 3511, Station ˘C÷                   157 Topaz St.
   Ottawa, Ont, K1Y-4H7
   Tel : 613-763-5827
   e.mail :osama@nortelnetworks.com

   Sandra Ballarte
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario, Canada
   K1Y-4H7
   Phone: 613-763-9510
   Email: ballarte@nortelnetworks.com

   Ewart Tempest
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario, Canada
   K1Y-4H7
   Phone: 613-768-0610
   Email: ewart@nortelnetworks.com

   Raj Jain
   Nayna Networks, Inc.
   157 Topaz St.
   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
   Email:raj@nayna.com

   Liangyu Jia                                  Bala Rajagopalan
   ONI Systems Corp.                            Tellium, Inc.
   166 Baypoints Parkway                        2 Crescent Place
   San Jose, CA 95134
   Tel: 408-965-2743
   Fax: 408-965-2660
   e.mail:ljia@oni.com

   Bala Rajagopalan
   Tellium, Inc.
   2 Crescent Place
   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
   Email :braja@tellium.com

   Robert Ronnison                              Yangguang Xu Rennison
   Laurel Networks                              Lucent Technologies
   2607 Nicholson Rd Road
   Sewickley, PA 15143, USA
   Tel: +1 724-933-7330
   Email:robren@laurelnetworks.com

Aboul-Magd               Expires January 2002                       24

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

   Yangguang Xu
   Lucent Technologies Inc.
   21-2A41
   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
   Tel : 978-960-6105
   e.mail :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:
   Tel: 858-646-7195
        Email: zzhang@sorrentonet.com
   e.mail:zzhang@sorrentonet.com

Aboul-Magd               Expires January 2002                       25

Draft-ietf-mpls-ldp-optical-uni-01                          July, 2001

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 implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into

     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               Expires January 2002                       26