Network Working Group Z. Lin Request for Comments: 3474 New York City Transit Category: Informational D. Pendarakis Tellium March 2003 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. Lin & Pendarakis Informational [Page 1] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 Table of Contents 1. Conventions used in this document...............................3 2. Introduction....................................................3 3. Support for Soft Permanent Connection...........................3 4. Support for Call................................................4 4.1 Call Identifier and Call Capability........................4 4.1.1 Call Identifier.....................................4 4.1.2 Call Capability.....................................7 4.2 What Does Current GMPLS Provide............................7 4.3 Support for Call and Connection............................7 4.3.1 Processing Rules....................................8 4.3.2 Modification to Path Message........................8 4.3.3 Modification to Resv Message........................9 4.3.4 Modification to PathTear Message....................9 4.3.5 Modification to PathErr Message....................10 4.3.6 Modification to Notify Message.....................10 5. Support For Behaviors during Control Plane Failures...........11 6. Support For Label Usage.......................................12 7. Support for UNI and E-NNI Signaling Session...................13 8. Additional Error Cases........................................14 9. Optional Extensions for Supporting Complete Separation of Call and Connection....................15 9.1 Call Capability.........;.................................15 9.2 Complete Separation of Call and Connection (RSVP-TE Extensions)...........................16 9.2.1 Modification to Path...............................16 9.2.2 Modification to Resv...............................17 9.2.3 Modification to PathTear...........................18 9.2.4 Modification to PathErr............................18 9.2.5 Modification to Notify.............................18 10. Security Considerations.......................................19 11. IANA Considerations...........................................19 11.1 Assignment of New Messages...............................19 11.2 Assignment of New Objects and Sub-Objects................19 11.3 Assignment of New C-Types................................20 11.4 Assignment of New Error Code/Values......................20 12. Acknowledgements..............................................20 13. References....................................................21 13.1 Normative References.....................................21 13.2 Informative References...................................22 14. Intellectual Property.........................................23 15. Contributors Contact Information..............................24 16. Authors' Addresses............................................24 17. Full Copyright Statement......................................25 Lin & Pendarakis Informational [Page 2] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 1. 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 BCP 14, RFC 2119 [RFC2119]. 2. Introduction This document contains the extensions to GMPLS for ASON-compliant networks [G7713.2]. The requirements describing the need for these extensions are provided in [GMPLS-ASON] as well as [ASON-RQTS]. These include: - Support for call and connection separation - Support for soft permanent connection - Support for extended restart capabilities - Additional error codes/values to support these extensions This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using RSVP-TE. It introduces extensions to GMPLS RSVP-TE to support the capabilities as specified in the above referenced documents. Specifically, this document uses the messages and objects defined by [RFC2205], [RFC2961], [RFC3209], [RFC3471], [RFC3473], [OIF-UNI1] and [RFC3476] as the basis for the GMPLS RSVP-TE protocol, with additional extensions defined in this document. 3. Support for Soft Permanent Connection In the scope of ASON, to support soft permanent connection (SPC) for RSVP-TE, one new sub-type for the GENERALIZED_UNI object is defined. The GENERALIZED_UNI object is defined in [RFC3476] and [OIF-UNI1]. This new sub-type has the same format and structure as the EGRESS_LABEL (the sub-type is the suggested value for the new sub- object): - SPC_LABEL (Type=4, Sub-type=2) The label association of the permanent ingress segment with the switched segment at the switched connection ingress node is a local policy matter (i.e., between the management system and the switched connection ingress node) and is thus beyond the scope of this document. Lin & Pendarakis Informational [Page 3] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 The processing of the SPC_LABEL sub-object follows that of the EGRESS_LABEL sub-object [OIF-UNI1]. Note that although the explicit label control described in [RFC3471] and [RFC3473] may provide a mechanism to support specifying the egress label in the context of supporting the GMPLS application, the SPC services support for the ASON model uses the GENERALIZED_UNI object for this extension to help align the model for both switched connection and soft permanent connection, as well as to use the service level and diversity attributes of the GENERALIZED_UNI object. 4. Support for Call To support basic call capability (logical call/connection separation), a call identifier is introduced to the RSVP-TE message sets. This basic call capability helps introduce the call model; however, additional extensions may be needed to fully support the canonical call model (complete call/connection separation). 4.1 Call Identifier and Call Capability A Call identifier object is used in logical call/connection separation while both the Call identifier object and a Call capability object are used in complete call/connection separation. 4.1.1 Call Identifier To identify a call, a new object is defined for RSVP-TE. The CALL_ID object carries the call identifier. The value is globally unique (the Class-num is the suggested value for the new object): CALL_ID (Class-num = 230) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |Class-Num (230)| C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call identifier | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the following C-types are defined: - C-Type = 1 (operator specific): The call identifier contains an operator specific identifier. - C-Type = 2 (globally unique): The call identifier contains a globally unique part plus an operator specific identifier. Lin & Pendarakis Informational [Page 4] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 The following structures are defined for the call identifier: - Call identifier: generic [Length*8-32]-bit identifier. The number of bits for a call identifier must be multiples of 32 bits, with a minimum size of 32 bits. The structure for the globally unique call identifier (to guarantee global uniqueness) is to concatenate a globally unique fixed ID (composed of country code, carrier code, unique access point code) with an operator specific ID (where the operator specific ID is composed of a source LSR address and a local identifier). Therefore, a generic CALL_ID with global uniqueness includes (composed of plus plus ) and (composed of plus ). For a CALL_ID that only requires operator specific uniqueness, only the is needed, while for a CALL_ID that is required to be globally unique, both and are needed. The shall consist of a three-character International Segment (the ) and a twelve-character National Segment (the plus ). These characters shall be coded according to ITU-T Recommendation T.50. The International Segment (IS) field provides a 3 character ISO 3166 Geographic/Political Country Code. The country code shall be based on the three-character uppercase alphabetic ISO 3166 Country Code (e.g., USA, FRA). National Segment (NS): The National Segment (NS) field consists of two sub-fields: - the first subfield contains the ITU Carrier Code - the second subfield contains a Unique Access Point Code. The ITU Carrier Code is a code assigned to a network operator/service provider, maintained by the ITU-T Telecommunication Service Bureauin association with Recommendation M.1400. This code consists of 1-6 left-justified alphabetic, or leading alphabetic followed by numeric, characters (bytes). If the code is less than 6 characters (bytes), it is padded with a trailing NULL to fill the subfield. The Unique Access Point Code is a matter for the organization to which the country code and ITU carrier code have been assigned, provided that uniqueness is guaranteed. This code consists of 1-6 characters (bytes), trailing NULL, completing the 12-character National Segment. If the code is less than 6 characters, it is padded by a trailing NULL to fill the subfield. Lin & Pendarakis Informational [Page 5] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 Format of the National Segment 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITU carrier code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITU carrie dode (cont) | Unique access point code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unique access point code (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Call identifier field for C-Type = 1: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |Class-Num (230)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Resv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LSR address | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lin & Pendarakis Informational [Page 6] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 The format of the Call identifier field for C-Type = 2: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |Class-Num (230)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | IS (3 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NS (12 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LSR address | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In both cases, a "Type" field is defined to indicate the type of format used for the source LSR address. The Type field has the following meaning: For Type=0x01, the source LSR address is 4 bytes For Type=0x02, the source LSR address is 16 bytes For Type=0x03, the source LSR address is 20 bytes For type=0x04, the source LSR address is 6 bytes For type=0x7f, the source LSR address has the length defined by the vendor Source LSR address: An address of the LSR controlled by the source network. Local identifier: A 64-bit identifier that remains constant over the life of the call. Note that if the source LSR address is assigned from an address space that is globally unique, then the operator-specific CALL_ID may also be used to represent a globally unique CALL_ID. However, this is not guaranteed since the source LSR address may be assigned from an operator-specific address space. Lin & Pendarakis Informational [Page 7] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 4.1.2 Call Capability The call capability feature is provided in Section 10. This is an optional capability. If supported, section 10 extensions must be followed. 4.2 What Does Current GMPLS Provide The signaling mechanism defined in [RFC2961], [RFC3209] and [RFC3471] supports automatic connection management; however it does not provide capability to support the call model. A call may be viewed as a special purpose connection that requires a different subset of information to be carried by the messages. This information is targeted to the call controller for the purpose of setting up a call/connection association. 4.3 Support for Call and Connection Within the context of this document, every call (during steady state) may have one (or more) associated connections. A zero connection call is defined as a transient state, e.g., during a break-before- make restoration event. In the scope of ASON, to support a logical call/connection separation, a new call identifier is needed as described above. The new GENERALIZED_UNI object is carried by the Path message. The new CALL_ID object is carried by the Path, Resv, PathTear, PathErr, and Notify messages. The ResvConf message is left unmodified. The CALL_ID object (along with other objects associated with a call, e.g., GENERALIZED_UNI) is processed by the call controller, while other objects included in these messages are processed by the connection controller as described in [RFC3473]. Processing of the CALL_ID (and related) object is described in this document. Note: unmodified RSVP message formats are not listed below. 4.3.1 Processing Rules The following processing rules are applicable for call capability: - For initial calls, the source user MUST set the CALL_ID's C-Type and call identifier value to all-zeros. - For a new call request, the first network node sets the appropriate C-type and value for the CALL_ID. - For an existing call (in case CALL_ID is non-zero) the first network node verifies existence of the call. Lin & Pendarakis Informational [Page 8] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 - The CALL_ID object on all messages MUST be sent from the ingress call controller to egress call controller by all other (intermediate) controllers without alteration. Indeed, the Class-Num is chosen such that a node which does not support ASON extensions to GMPLS forwards the object unmodified (value in the range 11bbbbbb). - The destination user/client receiving the request uses the CALL_ID value as a reference to the requested call between the source user and itself. Subsequent actions related to the call uses the CALL_ID as the reference identifier. 4.3.2 Modification to Path Message ::= [ ] [ [ | ] ... ] [ ] [ ] [ ] [ ] [ ... ] [ ] [ ] [ ] [ ] [ ... ] The format of the sender descriptor for unidirectional LSPs is not modified by this document. The format of the sender descriptor for bidirectional LSPs is not modified by this document. Note that although the GENERALIZED_UNI and CALL_ID objects are optional for GMPLS signaling, these objects are mandatory for ASON- compliant networks, i.e., the Path message MUST include both GENERALIZED_UNI and CALL_ID objects. Lin & Pendarakis Informational [Page 9] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 4.3.3 Modification to Resv Message ::= [ ] [ [ | ] ... ] [ ] [ ] [ ] [ ] [ ] [ ... ]