diff options
Diffstat (limited to 'doc/rfc/rfc3474.txt')
| -rw-r--r-- | doc/rfc/rfc3474.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
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 <global + ID> (composed of <country code> plus <carrier code> plus <unique + access point code>) and <operator specific ID> (composed of <source + LSR address> plus <local identifier>). For a CALL_ID that only + requires operator specific uniqueness, only the <operator specific + ID> is needed, while for a CALL_ID that is required to be globally + unique, both <global ID> and <operator specific ID> are needed. + + The <global ID> shall consist of a three-character International + Segment (the <country code>) and a twelve-character National Segment + (the <carrier code> plus <unique access point code>). 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 + + <Path Message> ::= <Common Header> + [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> + <RSVP_HOP> + <TIME_VALUES> + [ <EXPLICIT_ROUTE> ] + <LABEL_REQUEST> + [ <CALL_ID> ] + [ <PROTECTION> ] + [ <LABEL_SET> ... ] + [ <SESSION_ATTRIBUTE> ] + [ <NOTIFY_REQUEST> ] + [ <ADMIN_STATUS> ] + [ <GENERALIZED_UNI> ] + [ <POLICY_DATA> ... ] + <sender descriptor> + + 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 + + <Resv Message> ::= <Common Header> + [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> + <RSVP_HOP> + <TIME_VALUES> + [ <CALL_ID> ] + [ <RESV_CONFIRM> ] + <SCOPE> + [ <NOTIFY_REQUEST> ] + [ <ADMIN_STATUS> ] + [ <POLICY_DATA> ... ] + <STYLE> + <flow descriptor list> + + <flow descriptor list> is not modified by this document. + + Note that although the CALL_ID object is optional for GMPLS + signaling, this object is mandatory for ASON-compliant networks, + i.e., the Resv message MUST include the CALL_ID object. + +4.3.4 Modification to PathTear Message + + <PathTear Message> ::= <Common Header> + [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> + <RSVP_HOP> + [ <CALL_ID> ] + [ <sender descriptor> ] + + <sender descriptor> ::= (see earlier definition) + + Note that although the CALL_ID object is optional for GMPLS + signaling, this object is mandatory for ASON-compliant networks, + i.e., the PathTear message MUST include the CALL_ID object. + + + + + + + + + +Lin & Pendarakis Informational [Page 10] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + +4.3.5 Modification to PathErr Message + + <PathErr Message> ::= <Common Header> + [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> + [ <CALL_ID> ] + <ERROR_SPEC> + [ <ACCEPTABLE_LABEL_SET> ] + [ <POLICY_DATA> ... ] + <sender descriptor> + + <sender descriptor> ::= (see earlier definition) + + Note that although the CALL_ID object is optional for GMPLS + signaling, this object is mandatory for ASON-compliant networks, + i.e., the PathErr message MUST include the CALL_ID object. + +4.3.6 Modification to Notify Message + + Note that this message may include sessions belonging to several + calls. + + <Notify message> ::= <Common Header> + [<INTEGRITY>] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <ERROR_SPEC> + <notify session list> + + <notify session list> ::= + [ <notify session list> ] + <upstream notify session> | + <downstream notify session> + + <upstream notify session> ::= <SESSION> + [ <CALL_ID> ] + [ <ADMIN_STATUS> ] + [<POLICY_DATA>...] + <sender descriptor> + + <downstream notify session> ::= <SESSION> + [ <CALL_ID> ] + [<POLICY_DATA>...] + <flow descriptor list descriptor> + + + +Lin & Pendarakis Informational [Page 11] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + + Note that although the CALL_ID object is optional for GMPLS + signaling, this object is mandatory for ASON-compliant networks, + i.e., the Notify message MUST include the CALL_ID object. + +5. Support For Behaviors during Control Plane Failures + + Various types of control plane failures may occur within the network. + These failures may impact the control plane as well as the data plane + (e.g., in a SDH/SONET network if the control plane transport uses the + DCC and a fiber cut occurs, then both the control plane signaling + channel and the transport plane connection fails). As described in + [RFC3473], current GMPLS restart mechanisms allows support to handle + all of these different scenarios, and thus no additional extensions + are required. + + In the scope of the ASON model, several procedures may take place in + order to support the following control plane behaviors (as per + [G7713] and [IPO-RQTS]): + + - A control plane node SHOULD provide capability for persistent + storage of call and connection state information. This capability + allows each control plane node to recover the states of + calls/connections after recovery from a signaling controller + entity failure/reboot (or loss of local FSM state). Note that + although the restart mechanism allows neighbor control plane nodes + to automatically recover (and thus infer) the states of + calls/connections, this mechanism can also be used for + verification of neighbor states, while the persistent storage + provides the local recovery of lost state. In this case, per + [RFC3473], if during the Hello synchronization the restarting node + determines that a neighbor does not support state recovery (i.e., + local state recovery only), and the restarting node maintains its + state on a per neighbor basis, the restarting node should + immediately consider the Recovery as completed. + - A control plane node detecting a failure of all control channels + between a pair of nodes SHOULD request an external controller + (e.g., the management system) for further instructions. The + default behavior is to enter into self-refresh mode (i.e., + preservation) for the local call/connection states. As an + example, possible external instructions may be to remain in self- + refresh mode, or to release local states for certain connections. + Specific details are beyond the scope of this document. + - A control plane node detecting that one (or more) connections + cannot be re-synchronized with its neighbor (e.g., due to + different states for the call/connection) SHOULD request an + external controller (e.g., the management system) for further + instructions on how to handle the non-synchronized connection. As + an example, possible instructions may be to maintain the current + + + +Lin & Pendarakis Informational [Page 12] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + + local connection states. Specifics of the interactions between + the control plane and management plane are beyond the scope of + this document. + - A control plane node (after recovering from node failure) may lose + information on forwarding adjacencies. In this case the control + plane node SHOULD request an external controller (e.g., the + management system) for information to recover the forwarding + adjacency information. Specifics of the interactions between the + control plane and management plane are beyond the scope of this + document. + +6. Support For Label Usage + + Labels are defined in GMPLS to provide information on the resources + used for a particular connection. The labels may range from + specifying a particular timeslot, or a particular wavelength, to a + particular port/fiber. In the context of the automatic switched + optical network, the value of a label may not be consistently the + same across a link. For example, the figure below illustrates the + case where two GMPLS/ASON-enabled nodes (A and Z) are interconnected + across two non-GMPLS/ASON-enabled nodes (B and C; i.e., nodes B and C + do not support the ASON capability), where these nodes are all + SDH/SONET nodes providing, e.g., a VC-4 service. + + +-----+ +-----+ + | | +---+ +---+ | | + | A |---| B |---| C |---| Z | + | | +---+ +---+ | | + +-----+ +-----+ + + Labels have an associated structure imposed on them for local use + based on [GMPLS-SDHSONET] and [GMPLS-OTN]. Once the local label is + transmitted across an interface to its neighboring control plane + node, the structure of the local label may not be significant to the + neighbor node since the association between the local and the remote + label may not necessarily be the same. This issue does not present a + problem in a simple point-to-point connection between two control + plane-enabled nodes where the timeslots are mapped 1:1 across the + interface. However, in the scope of the ASON, once a non-GMPLS + capable sub-network is introduced between these nodes (as in the + above figure, where the sub-network provides re-arrangement + capability for the timeslots) label scoping may become an issue. + + In this context, there is an implicit assumption that the data plane + connections between the GMPLS capable edges already exist prior to + any connection request. For instance node A's outgoing VC-4's + timeslot #1 (with SUKLM label=[1,0,0,0,0]) as defined in [GMPLS- + SONETSDH]) may be mapped onto node B's outgoing VC-4's timeslot #6 + + + +Lin & Pendarakis Informational [Page 13] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + + (label=[6,0,0,0,0]) may be mapped onto node C's outgoing VC-4's + timeslot #4 (label=[4,0,0,0,0]). Thus by the time node Z receives + the request from node A with label=[1,0,0,0,0], the node Z's local + label and the timeslot no longer corresponds to the received label + and timeslot information. + + As such to support the general case, the scope of the label value is + considered local to a control plane node. A label association + function can be used by the control plane node to map the received + (remote) label into a locally significant label. The information + necessary to allow mapping from a received label value to a locally + significant label value may be derived in several ways: + + - Via manual provisioning of the label association + - Via discovery of the label association + + Either method may be used. In the case of dynamic association, this + implies that the discovery mechanism operates at the timeslot/label + level before the connection request is processed at the ingress node. + Note that in the simple case where two nodes are directly connected, + no association may be necessary. In such instances, the label + association function provides a one-to-one mapping of the received + local label values. + +7. Support for UNI and E-NNI Signaling Session + + [RFC3476] defines a UNI IPv4 SESSION object used to support the UNI + signaling when IPv4 addressing is used. This document introduces + three new extensions. These extensions specify support for the IPv4 + and IPv6 E-NNI session and IPv6 UNI session. These C-Types are + introduced to allow for easier identification of messages as regular + GMPLS messages, UNI messages, or E-NNI messages. This is + particularly useful if a single interface is used to support multiple + service requests. + + Extensions to SESSION object (Class-num = 1): + - C-Type = 12: UNI_IPv6 SESSION object + - C-TYPE = 15: ENNI_IPv4 SESSION object + - C-Type = 16: ENNI_IPv6 SESSION object + + The format of the SESSION object with C-Type = 15 is the same as that + for the SESSION object with C-Type = 7. The format of the SESSION + object with C-Type = 12 and 16 is the same as that for the SESSION + object with C-Type = 8. + + The destination address field contains the address of the downstream + controller processing the message. For the case of the E-NNI + signaling interface (where eNNI-U represents the upstream controller + + + +Lin & Pendarakis Informational [Page 14] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + + and eNNI-D represents the downstream controller) the destination + address contains the address of eNNI-D. [OIF-UNI1] and [RFC3476] + describes the content of the address for UNI_IPv4 SESSION object, + which is also applicable for UNI_IPv6 SESSION object. + +8. Additional Error Cases + + In the scope of ASON, the following additional error cases are + defined: + + - Policy control failure: unauthorized source; this error is + generated when the receiving node determines that a source + user/client initiated request for service is unauthorized based on + verification of the request (e.g., not part of a contracted + service). This is defined in [RFC3476]. + - Policy control failure: unauthorized destination; this error is + generated when the receiving node determines that a destination + user/client is unauthorized to be connected with a source + user/client. This is defined in [RFC3476]. + - Routing problem: diversity not available; this error is generated + when a receiving node determines that the requested diversity + cannot be provided (e.g., due to resource constraints). This is + defined in [RFC3476]. + - Routing problem: service level not available; this error is + generated when a receiving node determines that the requested + service level cannot be provided (e.g., due to resource + constraints). This is defined in [RFC3476]. + - Routing problem: invalid/unknown connection ID; this error is + generated when a receiving node determines that the connection ID + generated by the upstream node is not valid/unknown (e.g., does + not meet the uniqueness property). Connection ID is defined in + [OIF-UNI1]. + - Routing problem: no route available toward source; this error is + generated when a receiving node determines that there is no + available route towards the source node (e.g., due to + unavailability of resources). + - Routing problem: unacceptable interface ID; this error is + generated when a receiving node determines that the interface ID + specified by the upstream node is unacceptable (e.g., due to + resource contention). + - Routing problem: invalid/unknown call ID; this error is generated + when a receiving node determines that the call ID generated by the + source user/client is invalid/unknown (e.g., does not meet the + uniqueness property). + - Routing problem: invalid SPC interface ID/label; this error is + generated when a receiving node determines that the SPC interface + ID (or label, or both interface ID and label) specified by the + upstream node is unacceptable (e.g., due to resource contention). + + + +Lin & Pendarakis Informational [Page 15] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + +9. Optional Extensions for Supporting Complete Separation of Call and + Connection + + This section describes the optional and non-normative capability to + support complete separation of call and connection. To support + complete separation of call and connection, a call capability object + is introduced. The capability described in this Appendix is meant to + be an optional capability within the scope of the ASON specification. + An implementation of the extensions defined in this document include + support for complete separation of call and connection, defined in + this section. + +9.1 Call Capability + + A call capability is used to specify the capabilities supported for a + call. For RSVP-TE a new CALL_OPS object is defined to be carried by + the Path, Resv, PathTear, PathErr, and Notify messages. The CALL_OPS + object also serves to differentiate the messages to indicate a + "call-only" call. In the case for logical separation of call and + connection, the CALL_OPS object is not needed. + + The CALL_OPS object is defined as follows (the Class-num is the + suggested value for the new object): + + CALL_OPS (Class-num = 228, 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 (228)| C-Type (1) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Call ops flag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Two flags are currently defined for the "call ops flag": + 0x01: call without connection + 0x02: synchronizing a call (for restart mechanism) + +9.2 Complete Separation of Call and Connection (RSVP-TE Extensions) + + A complete separation of call and connection implies that a call + (during steady state) may have zero (or more) associated connections. + A zero connection call is a steady state, e.g., simply setting up the + user end-point relationship prior to connection setup. The following + modified messages are used to set up a call. Set up of a connection + uses the messages defined in Section 5 above. + + + + + +Lin & Pendarakis Informational [Page 16] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + +9.2.1 Modification to Path + + <Path Message> ::= <Common Header> + [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> + <RSVP_HOP> + <TIME_VALUES> + [ <EXPLICIT_ROUTE> ] + <LABEL_REQUEST> + <CALL_OPS> + <CALL_ID> + [ <NOTIFY_REQUEST> ] + [ <ADMIN_STATUS> ] + <GENERALIZED_UNI> + [ <POLICY_DATA> ... ] + <sender descriptor> + + The format of the sender descriptor for unidirectional LSPs is: + + <sender descriptor> ::= <SENDER_TEMPLATE> + <SENDER_TSPEC> + [ <RECORD_ROUTE> ] + + The format of the sender descriptor for bidirectional LSPs is: + + <sender descriptor> ::= <SENDER_TEMPLATE> + <SENDER_TSPEC> + [ <RECORD_ROUTE> ] + <UPSTREAM_LABEL> + + Note that LABEL_REQUEST, SENDER_TSPEC and UPSTREAM_LABEL are not + required for a call; however these are mandatory objects. As such, + for backwards compatibility purposes, processing of these objects for + a call follows the following rules: + + - These objects are ignored upon receipt; however, a valid-formatted + object (e.g., by using the received valid object in the + transmitted message) must be included in the generated message. + + + + + + + + + + +Lin & Pendarakis Informational [Page 17] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + +9.2.2 Modification to Resv + + <Resv Message> ::= <Common Header> + [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> + <RSVP_HOP> + <TIME_VALUES> + <CALL_OPS> + <CALL_ID> + [ <RESV_CONFIRM> ] + [ <NOTIFY_REQUEST> ] + [ <ADMIN_STATUS> ] + [ <POLICY_DATA> ... ] + <STYLE> + <flow descriptor list> + + <flow descriptor list> ::= + <FF flow descriptor list> + | <SE flow descriptor> + + <FF flow descriptor list> ::= + <FLOWSPEC> + <FILTER_SPEC> + [ <RECORD_ROUTE> ] + | <FF flow descriptor list> + <FF flow descriptor> + <FF flow descriptor> ::= + [ <FLOWSPEC> ] + <FILTER_SPEC> + [ <RECORD_ROUTE> ] + + <SE flow descriptor> ::= + <FLOWSPEC> + <SE filter spec list> + <SE filter spec list> ::= + <SE filter spec> + | <SE filter spec list> + <SE filter spec> + <SE filter spec> ::= + <FILTER_SPEC> + [ <RECORD_ROUTE> ] + + + + + + + +Lin & Pendarakis Informational [Page 18] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + + Note that FILTER_SPEC and LABEL are not required for a call; however + these are mandatory objects. As such, for backwards compatibility + purposes, processing of these objects for a call follows the + following rules: + + - These objects are ignored upon receipt; however, a valid-formatted + object (e.g., by using the received valid object in the + transmitted message) must be included in the generated message. + +9.2.3 Modification to PathTear + + <PathTear Message> ::= <Common Header> + [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> + <RSVP_HOP> + <CALL_OPS> + <CALL_ID> + [ <sender descriptor> ] + + <sender descriptor> ::= (see earlier definition in this section) + +9.2.4 Modification to PathErr + + <PathErr Message> ::= <Common Header> + [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> + <CALL_OPS> + <CALL_ID> + <ERROR_SPEC> + [ <POLICY_DATA> ... ] + <sender descriptor> + <sender descriptor> ::= (see earlier definition in this section) + + + + + + + + + + + + + +Lin & Pendarakis Informational [Page 19] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + +9.2.5 Modification to Notify + + <Notify message> ::= <Common Header> + [<INTEGRITY>] + [ [<MESSAGE_ID_ACK> | + <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <ERROR_SPEC> + <notify session list> + + <notify session list> ::= + [ <notify session list> ] + <upstream notify session> | + <downstream notify session> + + <upstream notify session> ::= <SESSION> + <CALL_ID> + [ <ADMIN_STATUS> ] + [<POLICY_DATA>...] + <sender descriptor> + + <downstream notify session> ::= <SESSION> + <CALL_ID> + [<POLICY_DATA>...] + <flow descriptor list descriptor> + +10. Security Considerations + + This document introduces no new security considerations. + +11. IANA Considerations + + There are multiple fields and values defined within this document. + IANA administers the assignment of these class numbers in the FCFS + space as shown in [see: http://www.iana.org/assignments/rsvp- + parameters]. + +11.1 Assignment of New Messages + + No new messages are defined to support the functions discussed in + this document. + + + + + + + + + + +Lin & Pendarakis Informational [Page 20] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + +11.2 Assignment of New Objects and Sub-Objects + + Two new objects are defined: + + - CALL_ID (ASON); this object should be assigned an object + identifier of the form 11bbbbbb. A suggested value is 230. Two C- + types are defined for this object + - C-Type = 1: Operator specific + - C-Type = 2: Globally unique + + For the Type field, there is no range restriction, and the entire + range 0x00 to 0xff is open for assignment, with 0x00 to 0x7f + assignment based on FCFS and 0x80 to 0xff assignment reserved for + Private Use. The assignments are defined in this document: + + - Type = 0x01: Source LSR address is 4-bytes + - Type = 0x02: Source LSR address is 16-bytes + - Type = 0x03: Source LSR address is 20-bytes + - Type = 0x04: Source LSR address is 6-bytes + - Type = 0x7f: the source LSR address has the length defined by the + vendor + - CALL_OPS (ASON); this object should be assigned an object + identifier of the form 11bbbbbb. The value is 228. One C-type is + defined for this object; the value is 1. + + One new sub-object is defined under the GENERALIZED_UNI object: + + - SPC_LABEL; this sub-object is part of the GENERALIZED_UNI object, + as a sub-type of the EGRESS_LABEL sub-object (which is Type=4). + The value is sub-type=2. + +11.3 Assignment of New C-Types + + Three new C-Types are defined for the SESSION object (Class-num = 1): + + - C-Type = 12 (ASON): UNI_IPv6 SESSION object + - C-Type = 15 (ASON): ENNI_IPv4 SESSION object + - C-Type = 16 (ASON): ENNI_IPv6 SESSION object + +11.4 Assignment of New Error Code/Values + + No new error codes are required. The following new error values are + defined. Error code 24 is defined in [RFC3209]. + + 24/103 (ASON): No route available toward source + 24/104 (ASON): Unacceptable interface ID + 24/105 (ASON): Invalid/unknown call ID + 24/106 (ASON): Invalid SPC interface ID/label + + + +Lin & Pendarakis Informational [Page 21] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + +12. Acknowledgements + + The authors would like to thank Osama Aboul-Magd, Jerry Ash, Sergio + Belotti, Greg Bernstein, Adrian Farrel, Nic Larkin, Lyndon Ong, + Dimitri Papadimitriou, Bala Rajagopalan, and Yangguang Xu for their + comments and contributions to the document. + +13. References + +13.1 Normative References + + [G8080] ITU-T Rec. G.8080/Y.1304, Architecture for the + Automatically Switched Optical Network (ASON), + November 2001. + + [G7713] ITU-T Rec. G.7713/Y.1704, Distributed Call and + Connection Management (DCM), November 2001. + + [G7713.2] DCM Signalling Mechanisms Using GMPLS RSVP-TE, ITU-T + G.7713.2, January 2003. + + [OIF-UNI1] UNI 1.0 Signaling Specification, The Optical + Internetworking Forum, + http://www.oiforum.com/public/UNI_1.0_ia.html + + [RFC2026] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2205] Braden, R., Editor, Zhang, L., Berson, S., Herzog, + S. and S. Jamin, "Resource ReSerVation Protocol + (RSVP) -- Version 1 Functional Specification", RFC + 2205, September 1997. + + [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, + F. and S. Molendini, "RSVP Refresh Overhead + Reduction Extensions", RFC 2961, April 2001. + + [RFC3209] Awaduche, D., Berger, L., Gan, D., Li, T., + Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions + to RSVP for LSP Tunnels", RFC 3209, December 2001. + + [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol + Label Switching (MPLS) - Signaling Functional + Description", RFC 3471, January 2003. + + + + +Lin & Pendarakis Informational [Page 22] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + + [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol + Label Switching (MPLS) Signaling - Resource + ReserVation Protocol-Traffic Engineering (RSVP-TE) + Extensions", RFC 3473, January 2003. + + [RFC3476] Rajagopalan, R., "Label Distribution Protocol (LDP) + and Resource ReserVation Protocol (RSVP) Extensions + for Optical UNI Signaling", RFC 3476, March 2003. + + [ITU-LIAISE] http://www.ietf.org/IESG/LIAISON/ITU-OIF.html + +13.2 Informative References + + [G807] ITU-T Rec. G.807/Y.1301, Requirements For Automatic + Switched Transport Networks (ASTN), July 2001 + + [IPO-RQTS] Aboul-Magd, O., "Automatic Switched Optical Network + (ASON) Architecture and Its Related Protocols", Work + in Progress. + + [GMPLS-ASON] Lin, Z., "Requirements for Generalized MPLS (GMPLS) + Usage and Extensions For Automatically Switched + Optical Network (ASON)", Work in Progress. + + [ASON-RQTS] Xue, Y., "Carrier Optical Services Requirements", + Work in Progress. + + [GMPLS-SDHSONET] Mannie, E., "GMPLS Extensions for SONET and SDH + Control", Work in Progress. + +14. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in RFC 2028. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + + + + + +Lin & Pendarakis Informational [Page 23] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +15. Contributors Contact Information + + Sergio Belotti + Alcatel + Via Trento 30, + I-20059 Vimercate, Italy + EMail: sergio.belotti@netit.alcatel.it + + Nic Larkin + Data Connection + 100 Church Street, + Enfield + Middlesex EN2 6BQ, UK + EMail: npl@dataconnection.com + + Dimitri Papadimitriou + Alcatel + Francis Wellesplein 1, + B-2018 Antwerpen, Belgium + EMail: Dimitri.Papadimitriou@alcatel.be + + Yangguang Xu + Lucent + 1600 Osgood St, Room 21-2A41 + North Andover, MA 01845-1043 + EMail: xuyg@lucent.com + +16. Authors' Addresses + + Zhi-Wei Lin + New York City Transit + 2 Broadway, Room C3.25 + New York, NY 10004 + + EMail: zhiwlin@nyct.com + + Dimitrios Pendarakis + Tellium + 2 Crescent Place + Oceanport, NJ 07757-0901 + + EMail: dpendarakis@tellium.com + + + +Lin & Pendarakis Informational [Page 24] + +RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003 + + +17. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Lin & Pendarakis Informational [Page 25] + |