RFC3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically SwitchedOptical Network (ASON)
3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically SwitchedOptical Network (ASON). Z. Lin, D. Pendarakis. March 2003. (Format: TXT=52551 bytes) (Status: INFORMATIONAL)
日本語訳
RFC一覧
参照
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