CCAMP WG O. Aboul-Magd Internet Draft Nortel Networks Document: draft-aboulmagd-ccamp-crldp-ason-ext-00.txt June 2002 CR-LDP Extensions for ASON 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 This draft considers CR-LDP extensions for the support of the ITU ASON architecture (G.8080) [2] and its signaling requirements (G.7713) [3]. The CCAMP WG charter includes the statement: "Define signalling protocols and measurement protocols such that they support multiple physical path and tunnel technologies (e.g. O- O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using input from technology-specific working groups such as MPLS, IPO, etc." This draft is within the CCAMP charter since it defines extensions to a CCAMP-defined signaling protocol, namely CR-LDP, for transport network tunnels. 2. Introduction During the IETF meeting in Minneapolis March 2002, an ITU liasian was presented requesting that IETF CCAMP WG to consider extensions for the GMPLS suite of signaling protocols for ASON network architecture [2] and its signaling requirements [3]. Aboul-Magd Expires January 2003 1 draft-aboulmagd-crldp-ext-ason-00.txt June 2002 The liaison identifies five areas where extensions are needed to meet ASON signaling requirements. Those areas are: a. Call and connection control separation b. Additional Error Codes/Values c. Restart Mechanism d. Support for Crankback e. Support for soft permanent connections (SPC) This draft is a follow up to the draft presented during the Minneapolis meeting. 3. CR-LDP Support for Call and Connection Separation One important architecture principle of ASON is that call and connection control are treated separately. With this separation there could be the case where a single call has one or more connections associated to it. It is also quite possible to have a call with no connections associated to it, for example during recovery times. The current set of GMPLS signaling protocols, i.e. CR-LDP and RSVP- TE do not support this requirement. In reality the notion of a call is absent in both protocols. A label switched path (LSP), or a connection, is set end-to-end by assigning a set of labels on the different nodes along the path. Once an LSP is deleted, all the information regarding its end points is lost. This section describes messages and TLV extensions necessary to introduce call and connection control separation to CR-LDP. Those extensions are dependent upon the call/connection model considered. In general there are two cases that have been the subject of some discussion at ITU. Those cases are: a. A call setup is always accompanied by a connection setup. This case is sometimes referred to as "logical separation" b. A call setup is done separately from connection setup. In this case call setup is mainly for the exchange of call control information between the two end points of a call. This case is sometimes referred to as "complete separation" In both cases connections associated with the call could be setup or torn down after the successful set up of the call. Furthermore the release of a call should result in clearing of all the connection associated with it. 3.1 Call Setup in CR-LDP Aboul-Magd Expires: January 2003 2 draft-aboulmagd-crldp-ext-ason-00.txt June 2002 Call setup in CR-LDP makes the distinction between the two cases mentioned above. In the case where the call setup request is always accompanied by a connection setup, the same LDP message used for connection setup (Label Request) is at the same time used for call setup. For the other cases where a call setup is done independently from the connection setup, a new LDP message (Call Setup) is introduced. The introduction of a new message is justified by the observation that the existing LDP messages perform procedures at the connection, or LSP, level. In this case the setup of a call doesn't include any of those procedure. Thus a new message is justified to avoid the inevitable overloading of the semantics of existing messages. 3.1.1 TLV Encodings for Call Operation This section describes the encoding for new TLV required for call setup. Two new TLV are introduced. Those are Call ID TLV and Call Capability TLV. Other TLV that are required for call operation are the Source ID TLV and the Dest ID TLV (Src ID and Dest ID TLV are defined for the OIF UNI [4] in the context of Transport Network Assigned (TNA) address). 3.1.1.1 Call ID TLV The purpose of the call identifier (Call ID) TLV is to locally identify a call in the context of separated call and connection control environment. The format of the Call 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Call ID (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call ID has a minimum length of 32 bits. 3.1.1.2 Call Capability TLV The Call Capability (Call Cap) TLV is used to explicitly indicate the configuration of potentiality of the call, e.g. pt-to-pt call. The format of the Call Capability 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboul-Magd Expires: January 2003 3 draft-aboulmagd-crldp-ext-ason-00.txt June 2002 |U|F| Call Cap (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call Capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.1.3 Source ID TLV The format of the Source ID TLV is as defined in the OIF UNI 1.0 [4] and [5] 3.1.1.4 Dest ID TLV The format of the Dest ID TLV is as defined in the OIF UNI 1.0 [4] and [5]. 3.1.2 CR-LDP Call Setup Messages CR-LDP uses the Label Request message and a newly defined message, Call Setup message, for call setup. The choice of which message to use depends on whether a connection setup is associated with the call setup request or not. 3.1.2.1 Label Request Message for Call Setup Label Request message is used for call setup for those cases where a connection setup is associated with the call setup request. The encoding for the Label Request message for call setup operation 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 (0x401) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call Capability TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other TLVs | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Only TLV that are relevant to the call setup operation are shown above. Other TLV include those TLV that are relevant to connection (LSP) setup as defined in [6]. 3.1.2.2 Call Setup Message Aboul-Magd Expires: January 2003 4 draft-aboulmagd-crldp-ext-ason-00.txt June 2002 The Call Setup message is a new LDP message that is introduced here for the case where call setup is not associated with connection setup. The encoding of the Call Setup 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| Call Setup (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call Capability TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that unlike the Label Request message, the Call Setup message does not include any parameters or TLV that are relevant to connection setup. 3.1.2.3 Call Setup Procedure The call setup procedure is the same for both messages. Procedure: The Calling party initiates a call setup by sending the appropriate message. The Call Setup message SHALL contain all the information required by the network to process the call. In Particular the calling and called party addresses as specified by the Source ID and Dest ID TLV. The setup message MUST include call ID TLV. The call control entity shall identify the call using the selected identifier for the lifetime of the call. The Call Setup message shall progress through the network to the called party. The called party may accept or reject the incoming call. An LDP Notification message with the appropriate status code (to be defined) shall be used to inform the calling party whether the setup is successful. The call can be rejected by either the network, e.g. for policy reasons, or by the called party. 3.1.3 CR-LDP Call Release Message Aboul-Magd Expires: January 2003 5 draft-aboulmagd-crldp-ext-ason-00.txt June 2002 The Call Release message is newly introduced LDP message and is used here for call termination independent of the message used during call setup. The encoding of the Call Release 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| Call Release (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Procedure: The Call Release message is sent by any entity of the network to indicate the desire to terminate an already established call. The Call Release message MUST include the Call ID TLV of the call to be terminated. Confirmation of call release is indicated to the request initiator using a Notification message with the appropriate status code (to be defined). Reception and processing of the Call Release message MUST trigger the release of all connections that are associated to that call. Connection release follows the normal CR-LDP procedure using Label Release and Label Withdraw messages. 4. CR-LDP Support for Crankback Crankback requires that when the Label Request message is blocked at a particular node due to unavailable resources, the node will inform the initiator of the Label Request message of the location of the blockage. The initiator can then re-compute new explicit routes that avoid the area where resource shortage is detected. A new Label Request message is sent that includes the new route. The support of crankback in CR-LDP is facilitated by the introduction of a Crankback TLV. An LDP Notification message is used to inform the Label Request message initiator of the blocking condition. The Notification message includes the Crankback TLV that indicates the location of resource shortage. The location of the resource shortage is identified using the ER-HOP TLV. The encoding of the Crankbck 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 Aboul-Magd Expires: January 2003 6 draft-aboulmagd-crldp-ext-ason-00.txt June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Crankback (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Notification message carrying the Crankback TLV may optionally include a Status TLV indicating the Crankback cause. In order to avoid a large number of retries, a node may be configured with a parameter that counts the number of replies until it reaches a certain allowed maximum. When this maximum value is reached, no further crankback retries are allowed and the connection set up fails. 5. CR-LDP Support for SPC An SPC service assumes that both source and destination user-to- network connection segments are provisioned while the network connection segement is set up via the control plane. For example when the initial request is received from an external source (e.g., from management system) there is an implicit assumption that the control plane has adequate information to determine the specific destination (network-to-user) link connection to use. Support for SPC in CR-LDP is provided by the introduction of the SPC_Label TLV. The SPC Label TLV has the same format as the Generalized Label TLV. The SPC Label Type is TBD. 6. CR-LDP Restart Mechanisms A number of restart mechanisms was defined for CR-LDP [7, 8]. Any of those methods could be used here. It has to be mentioned that in transport network, carriers deploy high availability equipment that are provisioned with backup copies of software and hardware. Upon failure a transport equipment should be able to recover state on its own without relying on its neighbors. Synchronization with neighbors could be achieved using any of the LDP query-type messages as defined in [5] and [9]. 7. CR-LDP Additional Error Codes/Values G.7713 includes a number of error conditions that are currently missing from CR-LDP related drafts. The list of those error conditions is given below. There is the need to assign status codes to them. Invalid SNP ID Calling Party busy Unavailable SNP ID Invalid SNPP ID Aboul-Magd Expires: January 2003 7 draft-aboulmagd-crldp-ext-ason-00.txt June 2002 Unavailable SNPP ID Failed to create SNC Failed to establish LC Invalid A End-User Name Invalid Z End-User Name Invalid CoS Unavailable CoS Invalid GoS Unavailable GoS Failed Security Check TimeOut Invalid Call Name Failed to Release SNC Failed to Free LC 8. Summary of CR-LDP Extensions for ASON This section summarizes those CR-LDP extensions that are necessary for ASON architecture as described in the previous sections. Two new messages: Call Setup and Call Release Four new TLV: Call ID TLV, Call Capability TLV, Crankback TLV, and SPC Label TLV. A number of new error codes as defined in section 7 9. Security Considerations This draft doesn't introduce any new security issues beyond those identified in CR-LDP RFC. 10. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 M. Mayer, Ed., "Architecture for Automatic Switched Optical Networks (ASON)", ITU G.8080/Y1304, V1.0, October 2001 3 Z. Lin, Ed., "Distributed Call and Connection Management", ITU G.7713/Y.1704, October 2001 4 Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0 Signaling Specifications", OIF Contribution, OIF2000.125.7, October 2001 Aboul-Magd Expires: January 2003 8 draft-aboulmagd-crldp-ext-ason-00.txt June 2002 5 B. Rajagopalan "LMP, LDP and RSVP Extensions for Optical UNI Signaling", draft-oif-uni-signaling-extensions-00.txt, work in progress, May 2001. 6 Ashoowd-Smith, P. et. al., "Generalized MPLS Signaling: CR-LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-05.txt, work in progress, Nov. 2001 7 A. Farrel, et. al., Fault Tolerance for LDP and CR-LDP", draft- ietf-mpls-ldp-ft-03.txt, work in progress, June 2002. 8 M. Leelanivas, et. al., " Graceful Restart Mechanism for LDP" draft-ietf-mpls-ldp-restart-00.txt, work in progress, January 2002. 9 P. Ashwood-Smih, et. al., "MPLS LDP Query Message Description", draft-ietf-mpls-lsp-query-03.txt, work in progress, August 2001. 11. Author's Addresses Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, Ontario, Canada K1Y-4H7 Tel: + 1 613 763 5827 Email: osama@nortelnetworks.com Aboul-Magd Expires: January 2003 9 draft-aboulmagd-crldp-ext-ason-00.txt June 2002 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 2003 10