RFC 3474

Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched…

📅 published April 2003, from ietf

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) 🦋

Okay bestie, this one is RFC 3474 and it's a Network Working Group doc 🎀. It was written by Z. Lin from New York City Transit and D. Pendarakis from Tellium, and it's dated March 2003 ✨. Its category is Informational, so it's giving "here's some info," not "this is a binding standard" 💅. The title block doesn't list anything it obsoletes or updates, so it's a standalone doc 🌸.

Status of this Memo 💜

This memo is info for the Internet community. It doesn't specify an Internet standard of any kind, and distribution of it is unlimited, no cap 🫶.

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract ✨

Okay so GMPLS is this whole suite of protocol specs that's built to support different technologies and different applications 🔥. Those include requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH), plus Optical Transport Networks (OTNs) 🦋.

This doc focuses on the signaling side of the GMPLS suite, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 💖. It proposes extra extensions to those signaling protocols so they can support the capabilities of an ASON network, which is giving main character energy 👑.

It also proposes appropriate extensions to resolve additional requirements that ITU-T Study Group 15 identified and communicated in support of ITU's ASON standardization effort 🧚.

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

1. Conventions used in this document 📏

Here's the key-word rule: "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 doc contains the extensions to GMPLS for ASON-compliant networks [G7713.2] 🦋. The requirements that explain why these extensions are needed are in [GMPLS-ASON] and [ASON-RQTS] 🫶. Those requirements 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 doc focuses on the signaling side of GMPLS, specifically GMPLS RSVP-TE signaling 💖. It adds extensions to GMPLS RSVP-TE so it can support the capabilities in those referenced docs ✨. Specifically, it builds on the messages and objects defined by [RFC2205], [RFC2961], [RFC3209], [RFC3471], [RFC3473], [OIF-UNI1] and [RFC3476] as the base for the GMPLS RSVP-TE protocol, and then adds its own extensions on top 🎀.

3. Support for Soft Permanent Connection 🧚

In the ASON scope, supporting soft permanent connection (SPC) for RSVP-TE means defining one new sub-type for the GENERALIZED_UNI object 💜. 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)

Here's the tea 🫖: how the permanent ingress segment is associated with the switched segment at the switched connection ingress node is a local policy matter. That means it's between the management system and the switched connection ingress node, so it's beyond the scope of this document 🙈.

The SPC_LABEL sub-object is processed the same way as the EGRESS_LABEL sub-object [OIF-UNI1] 🔥. Explicit label control, described in [RFC3471] and [RFC3473], might give you a way to specify the egress label for the GMPLS application. But for SPC in the ASON model, this extension uses the GENERALIZED_UNI object instead. That keeps the model aligned for both switched connection and soft permanent connection, and it lets you 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 added to the RSVP-TE message sets 💖. This basic call capability helps introduce the call model. However, extra 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 for logical call/connection separation 🦋. For complete call/connection separation, both the Call identifier object and a Call capability object are used 💅.

4.1.1 Call Identifier ✨

okay so first things first, we need a way to tell calls apart 💅 A brand new object gets defined for RSVP-TE: the CALL_ID object! It carries the call identifier, and the value is globally unique 🦋 (the Class-num is the suggested value for the new object, fyi): 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                        |
~                              ...                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

so there are two C-Types here, and they're giving different vibes 🌈

  • C-Type = 1 (operator specific): the call identifier holds an operator specific identifier.
  • C-Type = 2 (globally unique): the call identifier holds a globally unique part plus an operator specific identifier.

the call identifier itself is a 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. no shortcuts, bestie 🙈

now the globally unique version is the main character 👑 To guarantee global uniqueness, you glue together a globally unique fixed ID (country code, carrier code, unique access point code) with an operator specific ID. And that operator specific ID is made of a source LSR address and a local identifier.

so a generic CALL_ID with global uniqueness has <global ID> (that's <country code> + <carrier code> + <unique access point code>) and <operator specific ID> (that's <source LSR address> + <local identifier>). if you only need operator specific uniqueness, you just need the <operator specific ID>. but if the call has to be globally unique, you need both <global ID> and <operator specific ID> 💖

the <global ID> is a three-character International Segment (that's the <country code>) plus a twelve-character National Segment (that's the <carrier code> plus the <unique access point code>). these characters shall be coded according to ITU-T Recommendation T.50. the International Segment (IS) field gives 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). 🇺🇸

the National Segment (NS) field has two subfields:

  • 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 or service provider. it's maintained by the ITU-T Telecommunication Service Bureau in association with Recommendation M.1400. it's 1-6 left-justified alphabetic characters (bytes), or leading alphabetic followed by numeric. if the code is less than 6 characters (bytes), it gets padded with a trailing NULL to fill the subfield 🎀

the Unique Access Point Code is up to the organization the country code and ITU carrier code were assigned to, as long as uniqueness is guaranteed. it's 1-6 characters (bytes), with a trailing NULL, completing the 12-character National Segment. if it's less than 6 characters, it's padded with a trailing NULL to fill the subfield 🍓

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)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and 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 there's a "Type" field that tells you what format the source LSR address is in. here's the tea ☕

  • Type=0x01: the source LSR address is 4 bytes
  • Type=0x02: the source LSR address is 16 bytes
  • Type=0x03: the source LSR address is 20 bytes
  • type=0x04: the source LSR address is 6 bytes
  • type=0x7f: the source LSR address has the length defined by the vendor

the Source LSR address is an address of the LSR controlled by the source network. 💜

the Local identifier is a 64-bit identifier that remains constant over the life of the call. it's the same forever, periodt 🔒

one more thing, and it's a bit of a plot twist ✨ if the source LSR address comes from a globally unique address space, then the operator-specific CALL_ID can also represent a globally unique CALL_ID. BUT that's not guaranteed, because the source LSR address might come from an operator-specific address space 🙈

4.1.2 Call Capability 🧚

the call capability feature is covered in Section 10. it's an optional capability. if it's 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. BUT it doesn't give you the ability to support the call model 😭 a call can be seen as a special purpose connection that needs a different subset of information carried by the messages. that information is aimed at the call controller, so it can set up a call/connection association.

4.3 Support for Call and Connection 🫶

for this document, every call (during steady state) may have one (or more) associated connections. a zero connection call counts as a transient state, like during a break-before-make restoration event ✨

in ASON, to support a logical call/connection separation, we need that new call identifier we talked about above. the new GENERALIZED_UNI object gets carried by the Path message. the new CALL_ID object gets carried by the Path, Resv, PathTear, PathErr, and Notify messages. the ResvConf message is left unmodified 🦋 the CALL_ID object (along with other objects tied to a call, like GENERALIZED_UNI) is processed by the call controller. everything else in these messages is 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 apply 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 that the call exists.
  • the CALL_ID object on all messages MUST be sent from the ingress call controller to the egress call controller by all other (intermediate) controllers without alteration. the Class-Num is chosen so that a node which doesn't support ASON extensions to GMPLS forwards the object unmodified (value in the range 11bbbbbb). main character behavior 👑
  • 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 use 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 isn't modified by this document. same goes for bidirectional LSPs 🦋

but here's the key bit: the GENERALIZED_UNI and CALL_ID objects are optional for GMPLS signaling, but they're mandatory for ASON-compliant networks. so the Path message MUST include both GENERALIZED_UNI and CALL_ID objects 🔥

4.3.3 Modification to Resv Message ✨

okay so the Resv message gets its own glow-up too 💖 here's the grammar:

<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>

bestie, the <flow descriptor list> is literally not modified by this document 🙅‍♀️ it's untouched, no notes.

ngl the CALL_ID thing is the main plot here 🎀 it's optional for GMPLS signaling, BUT for ASON-compliant networks it's mandatory. so, the Resv message MUST include the CALL_ID object. no exceptions, periodt 💅

4.3.4 Modification to PathTear Message 🦋

the PathTear message is getting the same CALL_ID energy:

<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)

same vibe as before 🌸 CALL_ID is optional for GMPLS signaling, but for ASON-compliant networks it's a hard requirement. the PathTear message MUST include the CALL_ID object. no cap 🧚

4.3.5 Modification to PathErr Message 💜

the PathErr message gets the exact same treatment:

<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)

so, CALL_ID is optional for GMPLS signaling 🫶 but for ASON-compliant networks it's mandatory, i.e., the PathErr message MUST include the CALL_ID object. it's giving consistency, and I'm obsessed 😭

4.3.6 Modification to Notify Message 🌈

first things first, this message is allowed to carry sessions from several calls at once 👑 that's the main character move here.

<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>

and yes, the CALL_ID rule shows up again 🙈 it's optional for GMPLS signaling, but for ASON-compliant networks the Notify message MUST include the CALL_ID object. iykyk 🍓

5. Support For Behaviors during Control Plane Failures 🌩️

okay, real talk, things break 😭 control plane failures can happen anywhere in the network. they can hit the control plane AND the data plane. like, in an SDH/SONET network where the control plane transport runs over the DCC, a fiber cut takes out both the control plane signaling channel and the transport plane connection at once. yikes 💀

the good news is that, as described in [RFC3473], the current GMPLS restart mechanisms can handle all of these scenarios, so no extra extensions are needed ✨

in the ASON model, a few procedures can 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 lets each control plane node recover the states of calls/connections after a signaling controller entity failure/reboot (or loss of local FSM state). note that the restart mechanism lets neighbor control plane nodes automatically recover (and thus infer) those states, but it can also be used to verify neighbor states, while persistent storage gives 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 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 exist in GMPLS to describe the resources a connection uses 💖 they can point to a particular timeslot, a particular wavelength, or a particular port/fiber. in the context of the automatic switched optical network, though, the value of a label might not be the same across a link. the figure below shows two GMPLS/ASON-enabled nodes (A and Z) connected across two non-GMPLS/ASON-enabled nodes (B and C; i.e., nodes B and C do not support the ASON capability). all of these nodes are SDH/SONET nodes providing, e.g., a VC-4 service.

+-----+                   +-----+
|     |   +---+   +---+   |     |
|  A  |---| B |---| C |---|  Z  |
|     |   +---+   +---+   |     |
+-----+                   +-----+

labels come with a structure that's imposed locally, based on [GMPLS-SDHSONET] and [GMPLS-OTN]. once the local label is sent across an interface to its neighboring control plane node, that structure might not mean anything to the neighbor, because the local and remote labels don't have to match 🌀 this isn't a problem for a simple point-to-point connection between two control plane-enabled nodes where the timeslots map 1:1 across the interface. but in the ASON scope, once a non-GMPLS capable sub-network shows up between them (like in the figure, where the sub-network can rearrange the timeslots), label scoping can become an issue 😬

there's an implicit assumption here: the data plane connections between the GMPLS capable edges already exist before 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 (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]). so by the time node Z gets the request from node A with label=[1,0,0,0,0], node Z's local label and timeslot don't line up with the received label and timeslot information anymore 🙃

so, to support the general case, the scope of a label value is treated as 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 info needed to map a received label value to a locally significant label value can be derived in a couple of ways:

  • Via manual provisioning of the label association
  • Via discovery of the label association

either method may be used 💜 with dynamic association, the discovery mechanism works at the timeslot/label level before the connection request is processed at the ingress node. and if two nodes are directly connected, no association may be necessary. in those cases, the label association function gives 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 for UNI signaling when IPv4 addressing is used. this document brings in three new extensions 🎀 they cover the IPv4 and IPv6 E-NNI session and the IPv6 UNI session. these C-Types exist so messages are easier to identify as regular GMPLS messages, UNI messages, or E-NNI messages. this is super useful when a single interface handles multiple service requests 🫶

extensions to the 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 the one with C-Type = 7. the format of the SESSION object with C-Type = 12 and 16 is the same as the one with C-Type = 8 🌸

the destination address field holds the address of the downstream controller processing the message. for the E-NNI signaling interface (where eNNI-U is the upstream controller and eNNI-D is the downstream controller), the destination address contains the address of eNNI-D. [OIF-UNI1] and [RFC3476] describes the content of the address for the UNI_IPv4 SESSION object, which also applies to the UNI_IPv6 SESSION object 💖

8. Additional Error Cases 💅

okay so ASON has a bunch of extra error cases, and they're kinda iconic 🥹 Here they are:

  • Policy control failure: unauthorized source 🚫 This one fires when the receiving node decides the source user/client's request for service isn't authorized after checking it. Like, it's not part of a contracted service. Defined in [RFC3476].
  • Policy control failure: unauthorized destination 🙅‍♀️ This happens when the receiving node decides the destination user/client isn't allowed to be connected with the source user/client. Defined in [RFC3476].
  • Routing problem: diversity not available 🛤️ The receiving node can't provide the diversity that was requested (for example, because of resource constraints). Defined in [RFC3476].
  • Routing problem: service level not available 📉 The receiving node can't provide the requested service level (for example, because of resource constraints). Defined in [RFC3476].
  • Routing problem: invalid/unknown connection ID 🔢 The connection ID generated by the upstream node isn't valid or is unknown (for example, it doesn't meet the uniqueness property). Connection ID is defined in [OIF-UNI1].
  • Routing problem: no route available toward source 🗺️ The receiving node finds there's no available route back toward the source node (for example, because resources are unavailable).
  • Routing problem: unacceptable interface ID 🔌 The interface ID the upstream node specified is unacceptable (for example, because of resource contention).
  • Routing problem: invalid/unknown call ID 📞 The call ID the source user/client generated is invalid or unknown (for example, it doesn't meet the uniqueness property).
  • Routing problem: invalid SPC interface ID/label 🏷️ The SPC interface ID (or the label, or both the interface ID and label) that the upstream node specified is unacceptable (for example, because of resource contention).

9. Optional Extensions for Supporting Complete Separation of Call and Connection 🦋

so this section is the optional, non-normative extra that lets you do a complete separation of call and connection ✨ To make that happen, there's a brand new call capability object. This capability is meant to be optional within the ASON spec, and an implementation of the extensions in this document can include support for complete separation of call and connection, which is what this section covers.

9.1 Call Capability 🎀

a call capability is how you spell out the capabilities supported for a call. For RSVP-TE there's a new CALL_OPS object that rides along in the Path, Resv, PathTear, PathErr, and Notify messages. It also helps tell these messages apart when you're dealing with a "call-only" call. If you're doing logical separation of call and connection, you don't need CALL_OPS at all 🙈

The CALL_OPS object looks like this (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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

There are two flags defined so far 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) 💖

okay the big idea here is that during steady state, a call can have zero (or more) connections attached. A zero connection call is a steady state, e.g., just setting up the user end-point relationship before any connection setup happens 🧚 The messages below are the modified ones used to set up a call. Setting up a connection still uses the messages from Section 5 above.

9.2.1 Modification to Path 🛤️

here's the Path message grammar, copied exactly:

<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 sender descriptor for unidirectional LSPs looks like this:

<sender descriptor> ::=  <SENDER_TEMPLATE>
     <SENDER_TSPEC>
     [ <RECORD_ROUTE> ]

and for bidirectional LSPs it's this:

<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. They're still mandatory objects though, so for backwards compatibility, processing them for a call follows these 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.2 Modification to Resv 📬

here's the Resv message grammar, exactly as it is:

<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> ]

Note that FILTER_SPEC and LABEL are not required for a call. They're mandatory objects though, so for backwards compatibility, processing them for a call follows these 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 🧹

here's the PathTear grammar:

<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 🚨

and the PathErr grammar:

<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)

9.2.5 Modification to Notify 🔔

last one, the Notify grammar:

<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 ✨ Nothing new to panic about here, bestie 🫶

11. IANA Considerations 🧾

there are multiple fields and values defined in 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. Zero new messages, zero drama 💅

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's no range restriction. The entire range 0x00 to 0xff is open for assignment, with 0x00 to 0x7f assigned on FCFS and 0x80 to 0xff reserved for Private Use. These 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, and 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

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 📚✨

okay bestie, these are the docs this spec leans on so hard it literally can't stand without them 💅 every one is listed here with its full details:

  • [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.
  • [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 🦋

these ones are the helpful background reads, not strictly required to get the spec, but they're lowkey so good for context 🌸

  • [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 🔥

so the IETF is basically saying "we're not picking a side on who owns what" 💅 they don't say whether any rights apply to the tech in here, or whether you can get a license, and they haven't gone hunting for any rights either. if you want the nitty gritty on how they handle this stuff for standards-track docs, that's in RFC 2028. any claims of rights that were made available for publication, plus any promises of licenses, or the result of trying to get a general license or permission for implementers or users, can all be asked for from the IETF Secretariat 📬

and the IETF is totally inviting you to speak up 🫶 if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to practice this standard, send that info to the IETF Executive Director. no cap, they want to hear it 🌈

15. Contributors Contact Information 🎀

these are the lovely people who helped build this spec, so here's where to reach them 💖

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 🧚

and these are the two main authors, the ones who really carried this whole thing 👑

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

the Internet Society owns the copyright here (2003), all rights reserved, but honestly it's giving generous 🌈 you can copy and share this document and translations of it, and you can make derivative works that comment on it, explain it, or help with implementing it, as long as the copyright notice and this paragraph stay on every copy. the one thing you can't do is modify this document itself in any way, like deleting the copyright notice or the references to the Internet Society or other Internet orgs. the exceptions are when you're developing Internet standards, where the Internet Standards process copyright procedures must be followed, or when you're translating it into a language other than English 🌍

those permissions are perpetual and the Internet Society (or whoever takes over for them) won't revoke them ⭐

and the whole document is provided "AS IS" 💀 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 ✨

📦 where this page comes from