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

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

MPLS Working Group                                        O. Aboul-Magd
Internet Draft                                           Sandra Ballare
Document: draft-ietf-mpls-ldp-optical-uni-01.txt          Ewart Tempest
                                                        Nortel Networks

                                                               Raj Jain
                                                         Nayna Networks

                                                            LiangYu Jia
                                                            ONI Systems

                                                       Bala Rajagopalan
                                                           Tellium Inc.

                                                        Robert Rennison
                                                        Laurel Networks

                                                           Yangguang Xu
                                                      Lucent Technology

                                                        Zhensheng Zhang
                                                      Sorrento Networks

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

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

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


1. Abstract

   In OTNs using overlay model, clients request network services
   through a user network interface (UNI). This draft describes LDP
   necessary extensions for signaling support across the optical UNI

Aboul-Magd               Expires January 2002                        1

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

   (O-UNI). LDP extensions are those needed to satisfy the main
   functions supported at the 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 [2].


3. Introduction

   Several models have been discussed for the support of IP traffic
   over the transport layer (L1/L0) [3]. Three models are identified
   and are differentiated based on the amount of routing/topological
   information exchanged between the optical transport network (OTN)
   and its clients. Those models are overlay, peer, and augmented
   models.

   In an overlay network architecture such as the ITU-T automatic
   switched OTN (ASTN) [4], there is a clear boundary between the
   client and the network layers. Routing and topological information
   does not cross this boundary in the sense that each layer is 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 optical user network interface (O-
   UNI).

   MPLS based protocols have already been proposed for the realization
   of 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 plane signaling protocols. It
   therefore makes sense to use the same set of protocols for the
   implementation of the O-UNI. This draft introduces the necessary LDP
   [8] extensions to support the basic O-UNI functionality.

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

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

   - Connection Delete: Deletes an already existing connection.

   - Connection Modify: Modifies one or more of the connection
     attributes of the existing connections. Connection Modify is not
     supported in this version of the draft.

   - Status Enquiry: Allows the client to enquire the 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 in order to
     recover connection state.

   Tightly related to the O-UNI, and any UNI in general, is the need to
   uniquely identify clients and their points of attachment to the
   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 is assigned to the client by the network
   provider. The scope of the TNA could be on a one-to-one basis with
   logical links that the 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 latter case there
   is the need to introduce a logical port identifier (LPI) to
   differentiate between multiple logical links between an OTN client
   and an OTN NE that share the same TNA address. Similar to the TNA,
   LPI is assigned to the client by the network provider. Protocol
   extensions are required to support signaling of the TNA and LPI.

   O-UNI reference models have been discussed in [9]. The client side
   of the O-UNI has been denoted as UNI-C, while the term UNI-N has
   been used to identify the network side of the O-UNI. One or more
   signaling channels exist between the UNI-C and UNI-N. The UNI
   control channel MUST support the transport of IP protocols. This
   capability is necessary since IP based protocols, e.g. LDP, are
   proposed for O-UNI signaling.

4.0 LDP for the O-UNI

   In extending LDP for implementation at the O-UNI, there have been
   two main guiding principles. Firstly every effort was made to limit
   the introduction of new LDP messages. New messages are only
   introduced whenever the desired functionality could not be supported
   by existing messages, and have been limited to only those required
   to support the status enquiry function of the O-UNI.

   Secondly care has been taken not to violate any of the LDP semantics
   as defined in [8]. Therefore LDP O-UNI extensions could easily be
   implemented as a simple add-on to the already existing LDP
   implementations.

   The mode of operation of the LDP at the O-UNI is downstream on
   demand label advertisement with ordered control.

4.1 LDP Session Initialization

   For the O-UNI the LDP session is established between UNI-C and UNI-
   N. Furthermore the client (UNI-C) MUST play the active role during
   the LDP session initialization phase. Moreover, if all logical links
   are in the same O-VPN,:

   - There will be a single LDP session between an OTN client and an
     OTN NE, regardless of the 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 single LDP session
     between a proxy agent and an OTN NE regardless of the number of
     OTN clients and logical links the proxy agent signals on behalf
     of.

   The LDP Hello and Extended Hello SHALL be 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 TCP session. In addition to the
   parameters described in [8], the Initialization message from the
   UNI-C to the UNI-N contains all the O-UNI version numbers that are
   supported by the UNI-C.

   The UNI-N follows the procedure specified in section 2.5.3 of [8]
   for the passive LSR. It replies with an Initialization message to
   propose the parameters it wishes to use. Those parameters MUST
   include the highest version number from the list advertised by the
   UNI-C that the UNI-N supports. If the UNI-C and UNI-N have no UNI
   version in common, the LDP session establishment will fail.

   The Initialization message also includes a Contract ID TLV. Contract
   ID is determined by the network provider and identifies the contract
   agreement between the OTN client and the OTN operator. Its format is
   determined by the OTN operator.

   Maintaining the LDP session at the O-UNI MUST follow the procedure
   explained in section 2.5.6 of [8].

4.2 Connection Create using LDP

   In LDP, the connection create request is implemented using the Label
   Request message as defined in [8]. The Label Request message is from
   the source UNI-C to the source UNI-N. At the other end of the
   network the Label Request message is sent from the destination UNI-N
   to destination UNI-C.

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

   OTN connections are usually bi-directional. As in GMPLS, a bi-
   directional connection is signaled at the O-UNI by the inclusion of
   the Upstream Label in the Label Request message. Reception of the
   Label Request message by the destination UNI-C signifies the
   reservation success, i.e. all the requested connection attributes
   can be satisfied, of the 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 Configuration of any intermediate
   cross connect likely to require some time to complete and, depending
   on the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|   O-UNI Service (0x0953)  |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |     Service Level             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Diversity TLV                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Service Level:
     A Service Level corresponds to carrier-defined characteristics
     such as time to restore, BER, bumping priority, etc.

5.1.9 O-UNI Version Number TLV



Aboul-Magd               Expires January 2002                       13

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

   The O-UNI Version Number TLV is of the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|Version Num TLV (0x0955)   |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Major Vesrion Number        |       Minor Version Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Minor version number is set relative to the major version number.

5.2 LDP Message Extensions for O-UNI

   This section describes the necessary extensions for LDP messages for
   the support of signaling across the O-UNI. This section also
   includes the definition of the two new messages needed for status
   enquiry. Those messages are Status Enquiry message and Status
   Response Message.

5.2.1 Hello Message

   The format and the procedure for the Hello message is as defined in
   section 3.5.2 in [8].

5.2.2 Initialization Message

   The encoding for the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Initialization (0x0200)   |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Message ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Common Session Parameters TLV                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         O-UNI Version Number TLV  (O-UNI Mandatory)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          O-UNI Version Number TLV (O-UNI Mandatory)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Contract ID TLV (O-UNI Mandatory)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Optional Parameters                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The initialization message procedure is as described in section 2.5.
   in [8] and section 4.1 of this draft.

   Message ID is as defined in section 3.5. in [8]. Common Session
   Parameter TLV is 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 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|  Label Request (0x0401)     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Message ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               FEC TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Src ID TLV  (UNI mandatory)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Dest ID TLV TLV (UNI mandatory)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Egress Label TLV  (UNI Optional)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Connection ID TLV   (UNI mandatory)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Generalized Label Request TLV (UNI mandatory)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             O-UNI Service TLV    (UNI mandatory)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SONET/SDH Traffic Parameters TLV    (UNI mandatory)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Upstream Label TLV   (UNI optional)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Suggested Label TLV   (UNI optional)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Label Set TLV         (UNI optional)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Parameters                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Label Request Message is sent from:

   - the source UNI-C to source UNI-N to indicate an outgoing
     connection request;
   - the destination UNI-N to the 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 Label Request message is propagated through OTN from the
   source UNI-N to the destination UNI-N is outside the scope of this
   specification.

   In the Label Request Message, the initiating UNI-C identifies the
   two connection termination points (Src and Dest ID TLVs). The UNI-N
   is expected to assign a Connection ID that is unique within the
   transport network. The Connection ID is passed to the terminating
   UNI-C in the Label Request Message by the destination UNI-N.

   Upon the reception of the Label Request Message, the source UNI-N
   should verify that the signaled attributes (including the validity
   of the Source and the Destination IDs) can be supported. Failure to
   support one or more of the connection attributes triggers the
   generation of the Notification Message with the appropriate error
   code.

   The Label Request message Message ID should be used as a local
   connection identifier, until such a time when the network-assigned
   Connection ID is sent back to the source client. As stated in [8],
   since LSRs use Label Request message IDs as transaction identifiers,
   an LSR SHOULD NOT reuse the Message ID of a Label Request message
   until the corresponding transaction completers. Thus the local
   connection identifier has a very limited lifespan.

5.2.4 Label Mapping Message

   The format of the Label Mapping message for 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 Mapping (0x0400)     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Message ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               FEC TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Generalized Label TLV    (UNI mandatory)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               UNI Label Request Message ID                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Connection ID TLV   (UNI mandatory)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Parameters                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Label Mapping message procedure for the O-UNI is limited to
   downstream on demand ordered control mode. The UNI Label Mapping
   Message flows between:

   - The destination UNI-C to destination UNI-N in response to a Label
     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 connection requested previously.

   The network transports the assigned Connection ID to the calling
   client (source UNI-C) in the Label Mapping Message.

   A terminating UNI-C that desires to receive a reservation
   confirmation from the initiating UNI-C MUST set the C-bit in the
   Connection ID TLV.

5.2.5 Label Release Message

   The encoding for the Label Release 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                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Connection ID TLV                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Src ID TLV                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LDP Label Release Message is used for connection deletion in 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 the 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 Connection ID TLV is included,
   it is an indication that the connection identified by this ID is the
   one to be deleted. The Src ID TLV will only be present if a forced
   (i.e. non graceful) OTN connection deletion is to be 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 encoding for the Label Withdraw 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 Withdraw (0x0402)    |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Message ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               FEC TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Connection ID TLV (UNI Mandatory)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Parameters                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 is defined in section
   3.5.10 of [8]. The recipient of the Label Withdraw Message MUST
   respond with a Label Release message as in [8]. The Label Withdraw
   message for UNI carries a mandatory Connection ID.

5.2.7 Label Abort Message

   The format and the procedure of the Label Abort message are as given
   in section 3.5.9 of [8].

5.2.8 Notification Message

   The format of the Notification for 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|  Notification (0x0001)      |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Message ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Aboul-Magd               Expires January 2002                       18

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

   |                       Connection ID TLV                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              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 Enquiry, or
   Abort.

   The Notification message plays a number of roles within the O-UNI:

   - A failed connection setup event is indicated to 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 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 identifier).
     The Status TLV MUST include the status code for the cause of the
     failed setup, e.g. "no_bandwidth_available".

   - A Notification message is needed to initiate graceful deletion of
     a single OTN connection. In this case the Notification message
     MUST include the Connection ID of the connection to be deleted.
     The "delete_indication" status code must be included.

   - A Notification message is sent in response to 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 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 deleted connection. When used to acknowledge
     the deletion of a group of connections, the Notification message
     MUST not contain IDs of any of the connections that were deleted.

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

   - A Notification message is sent for those cases where the source
     UNI-C attempts to abort a connection request after sending the
     Label Request Message. The Notification message is sent in
     response to an Abort message. In this case the Notification
     message MUST include the Label Request Message ID 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 is a new LDP 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 Enquiry (0x0420)   |        Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Reserved                             |S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Src ID TLV 1                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Src ID TLV m                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Connection ID TLV 1                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Connection ID TLV n                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Parameters                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Status Enquiry message allows a client to enquire about the
   status of a connection or group of connections for which the client
   is 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 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
     Status Response message contains summary information (Connection
     ID and connection Status) of the specified connections. Otherwise,
     S=0, detailed information is requested.

5.2.10 Status Response Message

   The Status Response message is a new LDP message that is defined
   specifically for LDP applications for O-UNI. The encoding for the
   Status Response message is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| Status Response (0x0421)  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Connection ID TLV 1                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Src ID TLV                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Dest ID TLV TLV                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     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                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Status Response message is generated in response to a Status
   Enquiry message. The Status Response message contains information
   regarding the status of those connections (implicitly or explicitly)
   specified in the Status Enquiry message to which it is a response.
   The amount information included in the Status Response message
   depends on the whether the Status Enquiry is for summary or detailed
   information.

6.0 Status Code Summary

   The following are the status codes defined for this 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
   0x000000xx = Connection unavailable
   0x000000xx = Connection dropped by far end
   0x000000xx = Connection Pending

7. IANA Consideration

   This draft requires the use of a number of new messages, TLVs, and
   status codes from the number spaces within the LDP protocol.

   The two new messages (sections 5.2.9 and 5.2.10) and the 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 values given in this draft should be
   interpreted as advisory. There does not exist a preference to what
   values should be used.



Aboul-Magd               Expires January 2002                       22

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

   The authors' current understanding is that MPLS status codes are not
   sub-divided into specific ranges for different types of error. Hence,
   the numeric status code values assigned for this draft should simply
   be the next available values at the time of writing and may be
   substituted for other numeric values. See section "Status Codes" for
   details of the status codes defined in this draft.


8. Security Considerations

   This draft doesn't introduce any new security 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 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
   Nortel Networks
   P.O. Box 3511, Station ôCö
   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
   Phone: 408-956-8000x309
   Fax: 408-956-8730
   Email:raj@nayna.com

   Liangyu Jia
   ONI Systems Corp.
   166 Baypoints Parkway
   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
   Email :braja@tellium.com

   Robert Rennison
   Laurel Networks
   2607 Nicholson 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.
   N. Anderson, MA 01845
   Tel : 978-960-6105
   e.mail :xuyg@Lucent.com

   Zhensheng Zhang
   Sorrento Networks
   9990 Mesa Rim Road
   San Diego, CA 92121
   Tel: 858-646-7195
   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 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








































Aboul-Magd               Expires January 2002                       26


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