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