From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3474.txt | 1403 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1403 insertions(+) create mode 100644 doc/rfc/rfc3474.txt (limited to 'doc/rfc/rfc3474.txt') diff --git a/doc/rfc/rfc3474.txt b/doc/rfc/rfc3474.txt new file mode 100644 index 0000000..2ab7ff8 --- /dev/null +++ b/doc/rfc/rfc3474.txt @@ -0,0 +1,1403 @@ + + + + + + +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 + + ::= + [ ] + [ [ | + ] ... ] + [ ] + + + + [ ] + [ ] + + [ ] + [ ] + [ ... ] +