RFC 4974

Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls

📅 published August 2007, from ietf

RFC 4974 🎀 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls

Okay bestie, this one is all about Calls 📞✨ It's from August 2007 and it's a Standards Track doc, so it's the real deal. The authors are D. Papadimitriou from Alcatel and A. Farrel from Old Dog Consulting 🫶 It updates RFC 3473 (that's the big one we'll keep referencing) and there's no Obsoletes line, so it doesn't replace anything 🦋

Status of This Memo 📜

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 If you want to know where this protocol stands, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍 Distribution of this memo is unlimited, so share away 🌈

Copyright (C) The IETF Trust (2007).

Abstract 🌸

In some network layouts, it's super handy to keep associations between endpoints and key transit points so they can support an instance of a service 🧚 These associations are called Calls 💖

A Call doesn't carry the actual connectivity for user traffic. It just builds a relationship that later Connections can use 🦋 In Generalized MPLS (GMPLS), those Connections are called Label Switched Paths (LSPs) 🔥

This document describes how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling can be used and extended to support Calls ✨ These mechanisms give you full and logical Call/Connection separation, which is literally the whole point 💅

The mechanisms here apply to any environment (including multi-area) and to any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching 🌈

Table of Contents 🗺️

   1. Introduction ....................................................3
      1.1. Applicability to ASON ......................................4
   2. Conventions Used in This document ...............................4
   3. Requirements ....................................................4
      3.1. Basic Call Function ........................................4
      3.2. Call/Connection Separation .................................5
      3.3. Call Segments ..............................................5
   4. Concepts and Terms ..............................................5
      4.1. What Is a Call? ............................................5
      4.2. A Hierarchy of Calls, Connections, Tunnels, and LSPs .......6
      4.3. Exchanging Access Link Capabilities ........................6
           4.3.1. Network-Initiated Calls .............................7
           4.3.2. User-Initiated Calls ................................7
           4.3.3. Utilizing Call Setup ................................8
   5. Protocol Extensions for Calls and Connections ...................8
      5.1. Call Setup and Teardown ....................................8
      5.2. Call Identification ........................................9
           5.2.1. Long Form Call Identification .......................9
           5.2.2. Short Form Call Identification ......................9
           5.2.3. Short Form Call ID Encoding ........................10
      5.3. LINK_CAPABILITY Object ....................................11
      5.4. Revised Message Formats ...................................12
           5.4.1. Notify Message .....................................12
      5.5. ADMIN_STATUS Object .......................................13
   6. Procedures in Support of Calls and Connections .................14
      6.1. Call/Connection Setup Procedures ..........................14
      6.2. Call Setup ................................................14
           6.2.1. Accepting Call Setup ...............................16
           6.2.2. Call Setup Failure and Rejection ...................16
      6.3. Adding a Connections to a Call ............................17
           6.3.1. Adding a Reverse Direction LSP to a Call ...........18
      6.4. Call-Free Connection Setup ................................18
      6.5. Call Collision ............................................18
      6.6. Call/Connection Teardown ..................................19
           6.6.1. Removal of a Connection from a Call ................20
           6.6.2. Removal of the Last Connection from a Call .........20
           6.6.3. Teardown of an "Empty" Call ........................20
           6.6.4. Attempted Teardown of a Call with Existing
                  Connections ........................................20
           6.6.5. Teardown of a Call from the Egress .................21
      6.7. Control Plane Survivability ...............................21
   7. Applicability of Call and Connection Procedures ................22
      7.1. Network-Initiated Calls ...................................22
      7.2. User-Initiated Calls ......................................23
      7.3. External Call Managers ....................................23
           7.3.1. Call Segments ......................................23

   8. Non-Support of Call ID .........................................24
      8.1. Non-Support by External Call Managers .....................24
      8.2. Non-Support by Transit Node ...............................24
      8.3. Non-Support by Egress Node ................................25
   9. Security Considerations ........................................25
      9.1. Call and Connection Security Considerations ...............25
   10. IANA Considerations ...........................................26
      10.1. RSVP Objects .............................................26
      10.2. RSVP Error Codes and Error Values ........................27
      10.3. RSVP ADMIN_STATUS Object Bits ............................27
   11. Acknowledgements ..............................................27
   12. References ....................................................28
      12.1. Normative References .....................................28
      12.2. Informative References ...................................29

1. Introduction 🎀

This doc defines the protocol procedures and extensions that support Calls within Generalized MPLS (GMPLS) 💅

A Call is an association between endpoints, and possibly between key transit points (like network boundaries), that supports an instance of a service ✨ The end-to-end association is called a "Call", and the association between two transit points, or between an endpoint and a transit point, is called a "Call Segment" 🧩 Anything that processes a Call or Call Segment is called a "Call Manager" 👑

Again, a Call doesn't provide the actual connectivity for user traffic. It only builds a relationship that later Connections can be made from 🦋 In GMPLS, those Connections are Label Switched Paths (LSPs) 🔥 This document doesn't change the Connection setup procedures defined in [RFC3473], [RFC4208], and [STITCH] 🙈 Connections set up as part of a Call follow the rules in those docs, so no new rulebook, bestie 💖

A Call can have zero, one, or more than one Connection, and a Connection can have zero or one Call 🌸 That's why full and logical Call/Connection separation is needed 🫶

There's an example of Call requirements in the ITU-T's Automatically Switched Optical Network (ASON) architecture [G.8080] 🌈 The specific requirements for supporting Calls in that context are in [RFC4139] 📜 Just note that while the mechanisms here meet the requirements in [RFC4139], they're useful beyond that too ✨

The mechanisms in this document apply equally to any packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable interfaces, LSC interfaces, or FSC interfaces 🦋 The mechanisms and protocol extensions are backward compatible, and they can be used for Call management where only the Call Managers need to know about the protocol extensions 💜

1.1. Applicability to ASON 🌍

[RFC4139] details the requirements on GMPLS signaling needed to satisfy the ASON architecture described in [G.8080] 📜 The mechanisms in this document meet the requirements for Calls described in Sections 4.2 and 4.3 of [RFC4139], plus the extra Call-related requirements in Sections 4.4, 4.7, 5, and 6 of [RFC4139] 🔥

[ASON-APPL] describes how the GMPLS protocols apply to the ASON architecture 🧚

2. 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 [RFC2119] 💅 These are the official rule words, so treat them seriously 🙈

Also, the reader is assumed to already know the terminology in [RFC3471], [RFC3473], [RFC3477], and [RFC3945] 🤓

3. Requirements 📋

3.1. Basic Call Function ✨

The Call concept is there to deliver these capabilities:

  • Verification and identification of the Call initiator (before LSP setup) 🔍
  • Support of virtual concatenation with diverse path component LSPs 🌈
  • Association of multiple LSPs with a single Call (note that aspects related to recovery are covered in [RFC4426] and [GMPLS-E2E]) 🦋
  • Facilitation of control plane operations by letting the associated LSP change its operational status 👑

The procedures and protocol extensions for Call setup, and for associating Calls with Connections, are described in Section 5 and onwards of this document 💖

3.2. Call/Connection Separation 💔➡️💖

Full and logical Call and Connection separation is non-negotiable 🔥 Specifically:

  • It MUST be possible to establish a Connection without dependence on a Call 🫶
  • It MUST be possible to establish a Call without any associated Connections 🌸
  • It MUST be possible to associate more than one Connection with a Call 🧚
  • Removing the last Connection associated with a Call SHOULD NOT result in the automatic removal of the Call, except as a matter of local policy at the ingress of the Call 🙈
  • Signaling a Connection associated with a Call MUST NOT require the distribution or retention of Call-related information (state) within the network 🤫

3.3. Call Segments 🧩

Call Segment capabilities MUST be supported 💅

The procedures and (GMPLS) RSVP-TE signaling protocol extensions that support Call Segments are described in Section 7.3.1 of this document 📍

4. Concepts and Terms 🧠

The ASON architecture [G.8080] and [RFC4139] also discuss the concepts of a Call and a Connection 🌈 This section isn't meant to replace those docs. It's just a quick summary of the key terms and concepts 💜

4.1. What Is a Call? 📞

A Call is an agreement between endpoints, possibly working together with the nodes that give access to the network 🤝 Call setup may include capability exchange, policy, authorization, and security 🔐

A Call is used to facilitate and manage a set of Connections that provide end-to-end data services 🦋 Connections need state maintained at nodes along the data path within the network, but Calls don't involve transit nodes, except to forward the Call management requests as transparent messages 🧚

A Call can be set up and maintained independently of the Connections it supports ✨

4.2. A Hierarchy of Calls, Connections, Tunnels, and LSPs ✨

okay so Calls and Connections have a total parent-child energy 👑. One or more Connections can be attached to a Call, but a Connection can't be part of more than one Call 🙅‍♀️. A Connection can also exist with no Call at all 🦋.

In GMPLS RSVP-TE [RFC3473], a Connection is basically the same thing as a GMPLS TE Tunnel 🎀. Usually a Tunnel is one LSP, but for protection, load balancing, and a bunch of other stuff, a Tunnel can be backed by multiple parallel LSPs 🌈. Here's how the IDs mirror that whole hierarchy 💖:

  • Call IDs are unique within the context of the pair of addresses that are the source and destination of the Call.
  • Tunnel IDs are unique within the context of the Session (that is, the destination of the Tunnel). Applications may also find it convenient to keep the Tunnel ID unique within the context of a Call.
  • LSP IDs are unique within the context of a Tunnel.
Note that the Call_ID value of zero is reserved and MUST NOT be used during LSP-independent Call establishment. 🙈

Throughout the rest of this doc, LSP and Tunnel are used interchangeably with Connection 💅. The case of a Tunnel backed by more than one LSP is covered implicitly, so you don't need to worry about it separately 🫶.

In an overlay model, it's really useful for the ingress node of an LSP to know the link capabilities of the link between the network and the remote overlay network 👀. In the language of [RFC4208], the ingress node can use info about the link between the egress core node (CN) and the remote edge node (EN). We call this the egress network link 🔗. This info can help the ingress node tailor its LSP request to fit those capabilities, so it uses network resources better 💅.

For example, in transparent optical networks this could supply info on lambda availability on egress network links 🌈. Or, if the egress CN can do signal regeneration, it could be a way to negotiate signal quality attributes (like bit error rate) 💀. Similarly, in multi-domain routing environments, it could provide end-to-end selection of component links (that's spatial attribute negotiation) where TE links were bundled based on technology-specific attributes 🍓.

Sometimes the Traffic Engineering Database (TED) already has enough info to decide which egress network link to use ✨. Other times the TED doesn't have that info, and Call setup might be a good way to swap it 🎀. The Call-responder can use the Call parameters to pick a subset of the available egress network links between the egress CN and the remote EN. It can then report those links and their capabilities in the Call response, so the Call-initiator can pick a good one 🫶.

The next sections cover when the TED can be used and when Call parameter exchange might make more sense 🦋.

4.3.1. Network-Initiated Calls 🏠

Network-initiated Calls happen when the ingress (and so the egress) is inside the network 🏰. In that case there may be no need to distribute extra link capability info beyond what the TE and GMPLS extensions to the IGP already distribute 😌. Future IGP extensions might also let them distribute more detailed info, including optical impairments 🔮.

4.3.2. User-Initiated Calls 🙋‍♀️

User-initiated Calls happen when the ingress (and so the egress) is outside the network 🌍. Edge link info might not be visible inside the core network, or at other edge nodes either 🙈. That can stop an ingress from requesting LSP characteristics that will actually set up successfully 😭.

There are a few ways around this, like defining static TE links (ones not advertised by a routing protocol) between the CNs and ENs 🔧. Even so, special procedures may be needed to advertise egress network link info to edge nodes outside the network, without also advertising the info specific to what's inside the network 🤫.

Later on, once we understand better what info needs to be supported, TE extensions to EGPs might be defined for this 🔮. New rules for leaking TE info between routing instances might also come into play 💜.

4.3.3. Utilizing Call Setup 📞

When there are no IGP or EGP solutions available at the User-to-Network Interface (UNI), the local edge nodes still need to know the remote edge link capabilities 😩.

The Call setup procedure is a chance to discover the edge link capabilities of remote edge nodes before LSP setup is attempted ✨.

  • The Call-responder can return info on one or more egress network links. It could return a full list of the available links with info about their capabilities. Or it could filter the list and return info only about the links that might be appropriate for the Connections the Call needs. For that second option, the Call-responder must determine those appropriate links from info in the Call request, including the destination of the Call and the level of service (bandwidth, protection, etc.) required 🎯.
  • When a Call response comes in, the Call-initiator must determine paths for the Connections (LSPs) it's going to set up. How it does that is out of scope for this document, since it's an implementation-specific, algorithmic process 🤓. It can still take as input the info about the available egress network links that was supplied in the Call response 💅.

The LINK_CAPABILITY object is defined so this info can be exchanged 📦. The info in this object is similar to what GMPLS-capable IGPs distribute (see [RFC4202]) 💖.

5. Protocol Extensions for Calls and Connections 🎀

This section covers the protocol extensions needed to support Call identification and the management of Calls and Connections 💅. How to use these extensions is described in Section 6 📖.

5.1. Call Setup and Teardown 🌸

Calls get established independently of Connections, using the Notify message 📨. The Notify message is a targeted message, so it doesn't have to follow the path of the LSPs through the network 🧚.

Simultaneous Call and Connection establishment (sometimes called piggybacking) is not supported 🙅‍♀️.

5.2. Call Identification 🪪

Once the concept of a Call is introduced, we need some way to identify it 👑. This gets super important when Calls and Connections are separated, because Connections have to contain some reference to the Call 🔗.

A Call may be identified by a sequence of bytes that can have a fairly big (but not arbitrary) length. A 40-byte Call ID wouldn't be unreasonable 😤. This document doesn't set rules for encoding or parsing Call IDs, but it does have to provide a suitable way to communicate Call IDs within the protocol 💅. The full Call identification is called the long Call ID 💖.

The Call_ID only matters at the sender and receiver nodes 🫶. Keeping this info in the signaling state is not mandated at any intermediate node 🦋. So no change to [RFC3473] transit implementations is needed, and there are no backward compatibility issues 🙌. Forward compatibility is kept by using the existing default values to indicate that no Call processing is required 🌈.

The long Call ID isn't required as part of the Connection (LSP) state, even at the sender and receiver nodes, as long as some form of correlation is available 🔍. That correlation is provided through the short Call ID ✨.

5.2.1. Long Form Call Identification 📜

The long Call ID is only required on the Notify message that establishes the Call 📨. It's carried in the "Session Name" field of the SESSION_ATTRIBUTE object on that Notify message 💜.

The initiator of the Call inserts a unique value per Call into the "Session Name" field 🪄. Subsequent core nodes MAY inspect this object, and they MUST forward this object transparently across network interfaces until it reaches the egress node 🚀. The structure of this field MAY be formatted further, depending on the naming convention(s) 🎨. But [RFC3209] defines the "Session Name" field as a Null padded display string, so any formatting conventions for the Call ID have to stay within that scope 🙏.

5.2.2. Short Form Call Identification 🪶

The Connections (LSPs) associated with a Call need to carry a reference to that Call, called the short Call ID 🔖. A new field gets added to the signaling protocol so each LSP can be identified with the Call it belongs to 💖.

The new field is a 16-bit identifier. It's unique within the context of the address pairing given by the Tunnel_End_Point_Address and the Sender_Address of the SENDER_TEMPLATE object 🧩. It MUST be exchanged on the Notify message during Call initialization, and it gets used on all later LSP messages associated with the Call ✨. This identifier is known as the short Call ID, and it's encoded as described in Section 5.2.3 📐. The Call ID MUST NOT be used as part of the processing that determines which session an RSVP signaling message applies to 🙅‍♀️. This doesn't cause any backward compatibility issue, because the reserved field of the SESSION object defined in [RFC3209] MUST NOT be examined on receipt 🫶.

In the unlikely case that the short Call_ID runs out, local node policy decides what actions to take. Those might include using a second Sender_Address 😮. Local policy details are outside the scope of this document 🤷‍♀️.

5.2.3. Short Form Call ID Encoding 🔢

The short Call ID is carried in a 16-bit field in the SESSION object. That object is carried on the Notify message used during Call setup, and on all messages during LSP setup and management 📦. This field used to be reserved (it MUST be set to zero on transmission and ignored on receipt) 🙈. Using it this way keeps things backward compatible with nodes that don't use Calls 💅.

The figure below shows the new version of the object 👀.

   Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6)

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~               IPv4/IPv6 Tunnel End Point Address              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call_ID            |           Tunnel ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the breakdown of each field 🧁:

  • IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209]) 🌐
  • Call_ID: 16 bits 🪪. This is a 16-bit identifier used in the SESSION object that stays constant over the life of the Call. The Call_ID value MUST be set to zero when there is no corresponding Call 🙅‍♀️.
  • Tunnel ID: 16 bits (see [RFC3209]) 🎀
  • Extended Tunnel ID: 32 bits/128 bits (see [RFC3209]) ✨

Okay bestie, the LINK_CAPABILITY object 🎀 is the one that lets nodes swap link capability info during Call setup. It MAY be included in a Notify message used for Call setup. It's totally optional, and it describes the link-local capabilities of a link joining the Call-initiating node (or Call-terminating node) to the network. You figure out which node it's talking about from the source address of the Notify message. 🦋

The link being reported can be a single link or a bundled link [RFC4201] 🧚

The Class Number is picked so that any node that doesn't recognize this object just drops it silently. Basically the top bit is set and the next bit is clear, so nobody gets confused 🙈

Class-Num = 133 (form 10bbbbbb), 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The contents of the LINK_CAPABILITY object are a series of variable-length data items called subobjects. The subobject format is defined in [RFC3209]. Here's the list of subobjects that exist right now 💅

  • Type 1: the link local IPv4 address of a link or a numbered bundle using the format defined in [RFC3209].
  • Type 2: the link local IPv6 address of a link or a numbered bundle using the format defined in [RFC3209].
  • Type 4: the link local identifier of an unnumbered link or bundle using the format defined in [RFC3477].
  • Type 64: the Maximum Reservable Bandwidth corresponding to this link or bundle (see [RFC4201]).
  • Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this link or bundle (see also [RFC4201]).

Note: future revisions of this document may extend the above list. 👀

A single instance of this object MAY be used to exchange capability information for more than one link or bundled link. When that happens, the following ordering MUST be used 🌈

  • each link MUST be identified by an identifier subobject (Type 1, 2, or 4)
  • capability subobjects (Type 64 or 65, and future subobjects) MUST be placed after the identifier subobject for the link or bundle to which they refer.

Multiple instances of the LINK_CAPABILITY object within the same Notify message are not supported by this spec 🙅 If a Notify message does end up with multiple LINK_CAPABILITY objects, the receiver SHOULD process the first one as normal and SHOULD ignore the later instances of the object. Chef's kiss 👑

5.4. Revised Message Formats 💖

The Notify message gets an upgrade so it can handle Call establishment and teardown. See Section 6 for a description of the procedures ✨

5.4.1. Notify Message 🫶

The Notify message is modified for Call establishment with the optional addition of the LINK_CAPABILITY object. The SESSION_ATTRIBUTE object is also added to the <notify session> sequence so it can carry the long Call ID. The presence of the SESSION_ATTRIBUTE object MAY be used to tell apart a Notify message used for Call management, but check Section 5.5 for another mechanism too 🔍 The <notify session list> MAY be used to set up multiple Calls at the same time 🍓

The format of the Notify Message looks like this:

<Notify message>  ::= <Common Header> [ <INTEGRITY> ]
                      [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
                      [ <MESSAGE_ID> ]
                      <ERROR_SPEC>
                      <notify session list>

<notify session list> ::= [ <notify session list> ] <notify session>

<notify session>  ::= <SESSION> [ <ADMIN_STATUS> ]
                      [ <POLICY_DATA>...]
                      [ <LINK_CAPABILITY> ]
                      [ <SESSION_ATTRIBUTE> ]
                      [ <sender descriptor> | <flow descriptor> ]

<sender descriptor> ::= see [RFC3473]

<flow descriptor> ::= see [RFC3473]

5.5. ADMIN_STATUS Object 🌸

Notify messages used for Call control and management carry a specific new bit in the ADMIN_STATUS object, called the Call Management or C bit 🦋

[RFC3473] says the format and contents of the ADMIN_STATUS object are the ones defined in [RFC3471]. The new "C" bit gets added for Call control, and it looks like this 💜

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                        Reserved                     |C|T|A|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Reflect (R): 1 bit - see [RFC3471]
  • Testing (T): 1 bit - see [RFC3471]
  • Administratively down (A): 1 bit - see [RFC3471]
  • Deletion in progress (D): 1 bit - see [RFC3471]
  • Call Management (C): 1 bit
    • This bit is set when the message is being used to control and manage a Call.

The procedures for using the C bit are described in Section 6 💅

6. Procedures in Support of Calls and Connections 🎀

6.1. Call/Connection Setup Procedures 🍓

This section describes the processing steps for Call and Connection setup. Let's go 🧚

There are three cases considered:

  • A Call is set up without any associated Connection. It is assumed that Connections will be added to the Call at a later time, but this is neither a requirement nor a constraint.
  • A Connection may be added to an existing Call. This may happen if the Call was set up without any associated Connections, or if another Connection is added to a Call that already has one or more associated Connections.
  • A Connection may be established without any reference to a Call (see Section 6.4). This encompasses the previous LSP setup procedure.

Okay, the important bit: a Call MUST NOT be imposed upon a Connection that is already established 🚫 Doing that would mean changing the short Call ID in the SESSION object of the existing LSPs, and that would be a change in the Session Identifier. Existing protocol specs don't allow that, so it's a hard no 😭

Call and Connection teardown procedures are described later in Section 6.6.

6.2. Call Setup 💖

A Call is set up before, and independent of, LSP (i.e., Connection) setup ✨

Call setup MAY necessitate verification of the link status and link capability negotiation between the Call ingress node and the Call egress node. The procedure described below is applied only once for a Call, and so only once for the set of LSPs associated with a Call 🌸

The Notify message (see [RFC3473]) is used to signal the Call setup request and response. The new Call Management (C) bit in the ADMIN_STATUS object is used to indicate that this Notify is managing a Call. The Notify message is sent with source and destination IPv4/IPv6 addresses set to any of the routable ingress/egress node addresses, respectively 🦋

At least one session MUST be listed in the <notify session list> of the Notify message. To allow for long identification of the Call, the SESSION_ATTRIBUTE object is added as part of the <notify session list>. The ERROR_SPEC object isn't relevant in Call setup, but it MUST carry the Error Code zero ("Confirmation") to show there's no error 🫶

During Call setup, the ADMIN_STATUS object is sent with the following bits set. Bits not listed MUST be set to zero 🎀

  • R - to cause the egress to respond
  • C - to indicate that the Notify message is managing a Call.

The SESSION, SESSION_ATTRIBUTE, SENDER_TEMPLATE, and SENDER_TSPEC objects included in the <notify session> of the Notify message are built like this 🧚

  • The SESSION object includes as Tunnel_End_Point_Address any of the Call-terminating (egress) node's IPv4/IPv6 routable addresses. The Call_ID is set to a non-zero value that is unique within the context of the address pairing provided by the Tunnel_End_Point_Address and the Sender_Address from the SENDER_TEMPLATE object (see below). This value will be used as the short Call ID carried on all messages for LSPs associated with this Call.

The Call_ID value of zero is reserved and MUST NOT be used, since it will be present in SESSION objects of LSPs that are not associated with Calls. The Tunnel_ID of the SESSION object isn't relevant for this procedure and SHOULD be set to zero. The Extended_Tunnel_ID of the SESSION object isn't relevant for this procedure either, and MAY be set to zero or to an address of the ingress node.

  • The SESSION_ATTRIBUTE object contains priority flags. Right now there's no planned use for these flags, but future work may find value in assigning priorities to Calls, so the Priority fields MAY be set to non-zero values. None of the Flags in the SESSION_ATTRIBUTE object is relevant to this process, and this field SHOULD be set to zero. The Session Name field is used to carry the long Call Id as described in Section 5 🌈
  • The SENDER_TEMPLATE object includes as Sender Address any of the Call-initiating (ingress) node's IPv4/IPv6 routable addresses. The LSP_ID isn't relevant and SHOULD be set to zero 💅
  • The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC objects MUST be ignored upon receipt, and SHOULD be set to zero when sent 🙈

Additionally, ingress and egress nodes that need to share their respective link local capabilities may include a LINK_CAPABILITY object in the Notify message 🌸

The receiver of a Notify message can tell whether it's part of Call management or reporting an error by checking for the presence or absence of the SESSION_ATTRIBUTE object in the <notify session list>. For full clarity, though, you can inspect the new Call Management (C) bit in the ADMIN_STATUS object 🔍

Note that the POLICY_DATA object may be included in the <notify session list>, and MAY be used to identify requestor credentials, account numbers, limits, quotas, etc. This object is opaque to RSVP, which just passes it to policy control when required 🦋

Message IDs MUST be used during Call setup. No skipping 🙅

6.2.1. Accepting Call Setup 🦋

A node that receives a Notify message carrying the ADMIN_STATUS object with the R and C bits set is being asked to set up a Call. The receiver MAY perform authorization and policy according to local requirements 🫶

If the Call is acceptable, the receiver responds with a Notify message that reflects the information from the Call request, with two exceptions 💖

  • The responder removes any LINK_CAPABLITY object that was received, and MAY insert a LINK_CAPABILITY object that describes its own access link.
  • The ADMIN_STATUS object is sent with only the C bit set. All other bits MUST be set to zero.

The responder MUST use the Message ID object to make sure the response is delivered reliably. If no Message ID Acknowledgement comes back after the configured number of retries, the responder SHOULD keep assuming that the Call was successfully established. Call liveliness procedures are covered in Section 6.7 🌈

6.2.2. Call Setup Failure and Rejection 💥

okay so call setup can totally fail or get rejected 💀 no cap, it happens. 🫠

if the Notify message never gets delivered, the sender won't get a Message ID Acknowledgement back 😭. so if the sender has retransmitted the Notify message a configurable number of times and still hasn't gotten a Message ID Acknowledgement (see [RFC2961]), the initiator SHOULD declare the Call failed and SHOULD send a Call teardown request (see Section 6.6) 🛑.

it's also possible to get a Message ID Acknowledgement but never get the Call response Notify message 🙃. in that case the initiator MAY re-send the Call setup request a configurable number of times (see Section 6.7) before deciding the Call has failed. at that point the initiator MUST send a Call teardown request (see Section 6.6) 💅.

if the Notify message can't be parsed or is in error, it MAY be responded to with a Notify message carrying the error code 13 ("Unknown object class") or 14 ("Unknown object C-Type"), as long as that fits the error that was detected 🧐.

the receiver MAY reject the Call setup for security, authorization, or policy reasons 🔐. the good news is there are already error codes for this [RFC2205], and they can go in the ERROR_SPEC object inside the Notify message sent back as the response ✨.

error response Notify messages SHOULD also use the Message ID object so delivery is reliable 🫶. and no action should be taken if a Message ID Acknowledgement doesn't show up after the configured number of retries 🙈.

6.3. Adding a Connections to a Call 🦋

once a Call is established, LSPs can be added to it 🌸. since the short Call ID is part of the SESSION object, any LSP with the same Call ID value in its SESSION object belongs to the same Call. the Notify message that set up the Call carried that same Call ID in its SESSION object too 💜.

there won't be any mix-ups between LSPs that belong to a Call and ones that don't 👀. the Call ID MUST be equal to zero for LSPs that aren't associated with a Call, and MUST NOT be equal to zero for a valid Call ID ✨.

LSPs for different Calls can be told apart because the Call ID is unique within the context of the source address (in the SENDER_TEMPLATE object) and the destination address (in the SESSION object) 🧚.

ingress and egress nodes MAY group LSPs that belong to the same Call together and process them as a group, depending on implementation requirements 🍓. transit nodes don't need to know that multiple LSPs are associated with the same Call 🫧.

the ingress node MAY choose to set the Session Name of an LSP to match the long Call ID of the associated Call 🎀.

the C bit of the ADMIN_STATUS object MUST NOT be set on LSP messages, including Notify messages that are about the LSP, and MUST be ignored 🙅‍♀️.

6.3.1. Adding a Reverse Direction LSP to a Call 🔁

heads up: once a Call is established, it's symmetric 🪞. either end of the Call can add LSPs to it, no permission slip needed 💖.

managing LSPs in the reverse direction takes some extra care, because the addresses in the SESSION and SENDER_TEMPLATE are flipped 🙃. but the short Call ID is unique in the context of a given ingress-egress address pair, so it can safely be used to link the LSP to the Call 💅.

since Calls are defined here to be symmetrical, a potential Call ID collision can come up. Section 6.5 talks about that 👯‍♀️.

6.4. Call-Free Connection Setup 🫶

it's still possible to set up LSPs as per [RFC3473] without tying them to a Call 🌈. if the short Call ID in the SESSION object is set to zero, there's no associated Call, and the Session Name field in the SESSION_ATTRIBUTE object MUST be interpreted simply as the name of the session (see [RFC3209]) 📝.

the C bit of the ADMIN_STATUS object MUST NOT be set on messages for LSP control, including Notify messages that are about LSPs, and MUST be ignored when it shows up on those messages 🚫.

6.5. Call Collision 💥👥

since Calls are symmetrical, both ends of a Call could try to set up Calls with the same long Call IDs at the same time 😬. this only matters if the source and destination address pairs match. some rules applied to the contents of the long Call ID could avoid this, but those mechanisms are outside the scope of this document 🙏.

if a node has sent a Call setup request, hasn't gotten a response yet, and then receives a Call setup request with the same long Call ID and matching source/destination addresses, it SHOULD process it like this 🧠:

  • if its source address is numerically greater than the remote source address, it MUST discard the received message and keep waiting for a response to its setup request 🙅.
  • if its source address is numerically smaller than the remote source address, it MUST discard the state associated with the Call setup it initiated, and MUST respond to the received Call setup 🤝.

if a node gets a Call setup request carrying an address pair and long Call ID that match an existing Call, the node MUST return an error message (Notify message) with the new Error Code "Call Management" and the new Error Value "Duplicate Call" in response to the new Call request, and MUST NOT make any changes to the existing Call 🛑.

there's one more possible contention 🫣. it shows up when short Call IDs get assigned by a pair of nodes for two distinct Calls that are set up at the same time using different long Call IDs. in this case, a node receives a Call setup request carrying a short Call ID that matches one it previously sent for the same address pair. the following processing MUST be followed:

  • if the receiver's source address is numerically greater than the remote source address, the receiver returns an error (Notify message) with the new Error Code "Call Management" and the new Error Value "Call ID Contention" 🙅‍♀️.
  • if the receiver's source address is numerically less than the remote source address, the receiver accepts and processes the Call request. it will get an error message sent as described above, and at that point it selects a new short Call ID and re-sends the Call setup request 🔄.

6.6. Call/Connection Teardown 👋

just like with Call/Connection setup, there are several cases to think about 🧩:

  • Removal of a Connection from a Call
  • Removal of the last Connection from a Call
  • Teardown of an "empty" Call

tearing down an LSP that isn't associated with a Call doesn't need to be examined, because it follows exactly the procedures described in [RFC3473] 🤷‍♀️.

6.6.1. Removal of a Connection from a Call 🗑️

an LSP that's associated with a Call can be deleted using the standard procedures described in [RFC3473]. no special procedures needed 💁‍♀️.

it's not possible to remove an LSP from a Call without deleting the LSP 🙅. it's also not valid to change the short Call ID from non-zero to zero, because that changes the SESSION object, and that's not allowed 🚫.

6.6.2. Removal of the Last Connection from a Call 🫥

when the last LSP associated with a Call gets deleted, the question is what happens to the Call 🤔. since a Call can exist independently of Connections, it isn't always okay to say that removing the last LSP removes the Call 🫠.

removing the last LSP does not remove the Call, and the procedures in the next Section MUST be used to delete the Call 🧹.

6.6.3. Teardown of an "Empty" Call 🫧

when all LSPs have been removed from a Call, the Call may be torn down or left around for future LSPs 🌷.

deleting Calls works by sending a Notify message, just like with Call setup 📨. but the ADMIN_STATUS object carries the R, D, and C bits on the teardown request, and the D and C bits on the teardown response. other bits MUST be set to zero 🔢.

if a Notify message for deleting a Call goes out and the initiator doesn't get the matching reflected Notify message (or maybe even the Message ID Ack), the initiator MAY retry the deletion request using the same retry procedures as during Call establishment 🔁. if no response comes back after the full retries, the node deleting the Call MAY declare the Call deleted 🫡. but in that situation, the node SHOULD avoid re-using the long or short Call IDs for at least five times the Notify refresh period ⏳.

6.6.4. Attempted Teardown of a Call with Existing Connections 🚧

if a Notify request with the D bit of the ADMIN_STATUS object set comes in for a Call that still has LSPs, the request MUST be rejected with the Error Code "Call Management" and Error Value "Connections Still Exist" ❌. the state of the Call MUST NOT be changed 🔒.

6.6.5. Teardown of a Call from the Egress 🌅

since Calls are symmetric, they can be torn down from either the ingress or the egress 🔀.

when the Call is "empty" (has no associated LSPs), the egress can delete it by sending a Notify message just as described above 🙌.

heads up: both ends of a Call might start deleting it at the same time 😳. in that case, the Notify message acting as a teardown request MAY be interpreted by its recipient as a teardown response. but since Notify messages acting as teardown requests carry the R bit in the ADMIN_STATUS object, they MUST be responded to anyway 💯. if a teardown request Notify message comes in for an unknown Call ID, it is still responded to in the affirmative ✅.

6.7. Control Plane Survivability ✨

okay so Notify messages get their own bodyguard 🛡️ their delivery is secured with Message ID Acknowledgements, same as in the sections before this one 🫶

Notify messages give you end-to-end communication that doesn't need constant paths through the network 🦋 they get routed according to IGP routing information, so no network resilience stuff (like make-before-break, protection, or fast re-route) needs to be considered for them 💅 end-to-end resilience still matters for node restart and completely disjoint networks though, so don't get it twisted 🙈

Periodic Notify messages SHOULD be sent by the initiator and terminator of the Call. This keeps the Call alive and handles ingress or egress node restart 🌸 the timing is a local matter, but it is RECOMMENDED that this period should be twice the shortest refresh period of any LSP associated with the Call. When there are no LSPs associated with a Call, an LSR is RECOMMENDED to use a refresh period of no less than one minute ⏰ the Notify messages are identical to the ones sent when establishing the Call for the first time, except for the LINK_CAPABILITY object, which may have changed since the Call was first established (due to, e.g., the establishment of Connections, link failures, or the addition of new component links) ✨ the current link information is useful for establishing subsequent Connections, so it's a total win 🎀

A node that receives a refresh Notify message carrying the R bit in the ADMIN_STATUS object MUST respond with a Notify response. A node that receives a refresh Notify message (response or request) MAY reset its timer, so in normal processing, Notify refreshes involve a single exchange once per time period 💖

A node (sender or receiver) that is unsure of the status of a Call MAY immediately send a Notify message as if establishing the Call for the first time 🧚

Failure to receive a refresh Notify request has no specific meaning, bestie 🤷‍♀️ a node that fails to receive one MAY send its own refresh Notify request to establish the status of the Call. If a node receives no response to a refresh Notify request (including no Message ID Acknowledgement), it MAY assume that the remote node is unreachable or unavailable 😭 whether this causes the local node to tear down associated LSPs and delete the Call is a local policy matter, so that's on the local team 💅

In the event that an edge node restarts without preserved state, it MAY relearn LSP state from adjacent nodes and Call state from remote nodes 🔄 if a Path or Resv message is received with a non-zero Call ID but without the C bit in the ADMIN_STATUS, and for a Call ID that is not recognized, the receiver is RECOMMENDED to assume that the Call establishment is delayed and ignore the received message ⏳ if the Call setup never materializes, the failure by the restarting node to refresh state will cause the LSPs to be torn down 💀 optionally, the receiver of such an LSP message for an unknown Call ID may return an error (PathErr or ResvErr message) with the error code "Call Management" and Error Value "Unknown Call ID" 🌈

7. Applicability of Call and Connection Procedures ✨

This section looks at how the different Call establishment procedures apply at the NNI and UNI reference points 🦋 it's informative and isn't meant to prescribe or prevent other options, so think of it as a vibe check, not a rulebook 💜

7.1. Network-Initiated Calls

Since the link properties and other traffic-engineering attributes are likely known through the IGP, the LINK_CAPABILITY object isn't usually required 🌸

In multi-domain networks, it's possible that access link properties and other traffic-engineering attributes aren't known, since the domains don't share that sort of information 🌐 in this case, the Call setup mechanism may include the LINK_CAPABILITY object 🎀

7.2. User-Initiated Calls

It's possible that the access link properties and other traffic-engineering attributes aren't shared across the core network 🙈 in this case, the Call setup mechanism may include the LINK_CAPABILITY object 💅

Further, the first node within the network may be responsible for managing the Call ✨ in that case, the Notify message used to set up the Call is addressed by the user network edge node to the first node of the core network. Moreover, neither the long Call ID nor the short Call ID is supplied (the Session Name Length is set to zero and the Call ID value is set to zero) 🧚 the Notify message is passed to the first core node, which is responsible for generating the long and short Call IDs before dispatching the message to the remote Call end point (which is known from the SESSION object) 🫶

Further, when used in an overlay context, the first core node is allowed (see [RFC4208]) to replace the Session Name assigned by the ingress node and passed in the Path message. In the case of Call management, the first core node:

  1. MAY insert a long Call ID in the Session Name of a Path message.
  2. MUST replace the Session Name with that originally issued by the user edge node when it returns the Resv message to the ingress node.

7.3. External Call Managers

Third-party Call management agents may be used to apply policy and authorization at a point that is neither the initiator nor the terminator of the Call 👑 the previous example is a particular case of this, but the process and procedures are identical 🔥

7.3.1. Call Segments

Call Segments exist between a set of default and configured External Call Managers along a path between the ingress and egress nodes, and they use the protocols described in this document 🌈

The techniques that a given service provider uses to identify which External Call Managers within its network should process a given Call are beyond the scope of this document 🤫

An External Call Manager uses normal IP routing to route the Notify message to the next External Call Manager 🛣️ Notify messages (requests and responses) are therefore encapsulated in IP packets that identify the sending and receiving External Call Managers. But the addresses used to identify the Call (the Sender Address in the SENDER_TEMPLATE object and the Tunnel Endpoint Address in the SESSION object) keep identifying the endpoints of the Call 💖

8. Non-Support of Call ID ✨

It's important that the procedures described above operate as seamlessly as possible with legacy nodes that don't support the extensions described 🥺

Clearly, there's no need to consider the case where the Call initiator doesn't support Call setup initiation 🙄

8.1. Non-Support by External Call Managers

It's unlikely that a Call initiator will be configured to send Call establishment Notify requests to an external Call manager, including the first core node, if that node doesn't support Call setup 🙅‍♀️

A node that receives an unexpected Call setup request will fall into one of the following categories 👀

  • Node does not support RSVP. The message will fail to be delivered or responded to. No Message ID Acknowledgement will be sent. The initiator will retry and then give up 💀
  • Node supports RSVP or RSVP-TE but not GMPLS. The message will be delivered but not understood. It will be discarded. No Message ID Acknowledgement will be sent. The initiator will retry and then give up 😭
  • Node supports GMPLS but not Call management. The message will be delivered, but parsing will fail because of the presence of the SESSION_ATTRIBUTE object. A Message ID Acknowledgement may be sent before the parse fails. When the parse fails, the Notify message may be discarded, in which case the initiator will retry and then give up. Alternatively, a parse error may be generated and returned in a Notify message, which will indicate to the initiator that Call management is not supported 🫠

8.2. Non-Support by Transit Node

Transit nodes SHOULD NOT examine Notify messages that aren't addressed to them 🙈 however, they will see short Call IDs in all messages for all LSPs associated with Calls 👁️

Previous specifications state that these fields SHOULD be ignored on receipt and MUST be transmitted as zero. This might be interpreted by some implementations as meaning that the fields should be zeroed before the objects are forwarded. If this happens, LSP setup will not be possible 😱 if either of the fields is zeroed on either the Path or the Resv message, the Resv message will reach the initiator with the field set to zero, and that's an indication to the initiator that some node in the network is preventing Call management 🚫 use of Explicit Routes may help mitigate this issue by avoiding such nodes 🗺️ ultimately, though, it may be necessary to upgrade the offending nodes to handle these protocol extensions 🛠️

8.3. Non-Support by Egress Node

It's unlikely that an attempt will be made to set up a Call to a remote node that doesn't support Calls 🤔

If the egress node doesn't support Call management through the Notify message, it will react (as described in Section 8.1) in the same way as an External Call Manager 🔁

9. Security Considerations ✨

Heads up, bestie: this section is serious business 🚨 please refer to each of the documents referenced in the following sections for a description of the security considerations that apply to the features they provide 🔐

9.1. Call and Connection Security Considerations

Call setup is vulnerable to attacks of both spoofing and denial of service 😱 since Call setup uses Notify messages, the process can be protected by using the INTEGRITY object to secure those messages, as described in [RFC2205] and [RFC3473]. Deployments where security is a concern SHOULD use this mechanism 🛡️

Implementations and deployments MAY additionally protect the Call setup exchange using end-to-end security mechanisms, such as those provided by IPsec (see [RFC4302] and [RFC4303]), or using RSVP security [RFC2747] 🔒

Note, additionally, that it would be desirable to use the process of independent Call establishment, where the Call is set up separately from the LSPs, to apply an extra level of authentication and policy for the end-to-end LSPs above what is available with Call-less, hop-by-hop LSP setup 👑 however, doing so will require additional work to set up security associations between the peer and the call manager that meet the requirements of [RFC4107]. The mechanism described in this document is expected to meet this use case when combined with this additional work. Applying this mechanism to the authentication and policy use case before a security solution is standardized is inappropriate and outside the current applicability of the mechanism 🚧

The frequency of Call establishment is application dependent and hard to generalize 🤷‍♀️ key exchange for Call-related message exchanges is therefore something that should be configured or arranged dynamically in different deployments, according to the advice in [RFC4107]. Note that the remote RSVP-TE signaling relationship between Call endpoints is no different from the signaling relationship between LSRs that establish an LSP 💫 that is, the LSRs are not necessarily IP-adjacent in the control plane in either case. Thus, key exchange should be regarded as a remote procedure, not a single-hop procedure 🦋 there are several procedures for automatic remote exchange of keys, and IKEv2 [RFC4306] is particularly suggested in [RFC3473] 🎀

10. IANA Considerations ✨

10.1. RSVP Objects

Okay bestie, IANA gave us a brand new RSVP object 💅 It came from the "RSVP Parameters" registry, in the sub-registry called "Class Names, Class Numbers, and Class Types" 🎀

  • LINK_CAPABILITY object
    • Class-Num = 133 (form 10bbbbbb)
    • C-Type = 1 (TE Link Capabilities)

The Class Number was picked on purpose so that nodes who don't recognize this object just drop it silently 🙈 The top bit is set and the next bit is cleared, so it's giving "ignore me if you don't know me" energy ✨

The LINK_CAPABILITY object is only defined for inclusion on Notify messages. Refer to Section 5.3 of this document for the details 🧚

IANA keeps a list of the subobjects that can ride inside this object 📋 It lives in the registry entry for LINK_CAPABILITY, which is the same common practice used for the subobjects of other RSVP objects. For each subobject, IANA lists:

  • subobject type number
  • subobject name
  • reference indicating where the subobject is defined

The starting list of subobjects is in Section 5.3 of this document 🦋

10.2. RSVP Error Codes and Error Values

A new RSVP Error Code and some new Error Values have arrived 🌸 IANA assigned them from the "RSVP Parameters" registry, using the sub-registry "Error Codes and Globally-Defined Error Value Sub-Codes".

  • Error Codes:
    • Call Management (value 32)
  • Error Values:
    • Call Management/Call ID Contention (value 1)
    • Call Management/Connections Still Exist (value 2)
    • Call Management/Unknown Call ID (value 3)
    • Call Management/Duplicate Call (value 4)

10.3. RSVP ADMIN_STATUS Object Bits

[GMPLS-E2E] asked IANA to manage the bits of the RSVP ADMIN_STATUS object 🍓 So a new "Administrative Status Information Flags" sub-registry got created under the "GMPLS Signaling Parameters" registry. Iconic organization, honestly 👑

This document defines exactly one new bit, the C bit, and it gets tracked in that sub-registry. Bit number 28 has been assigned to it. See Section 5.5 of this document 💜

11. Acknowledgements

The authors want to give a huge shoutout to George Swallow, Yakov Rekhter, Lou Berger, Jerry Ash, and Kireeti Kompella 🫶 Their super useful input and comments on an earlier revision really helped.

Thanks to Lyndon Ong and Ben Mack-Crane for the long chats during and after working group last call 🌈 Thanks to Deborah Brungard for a final, detailed review, which was sooo thorough 🎀

Thanks to Suresh Krishnan for the GenArt review, and to Magnus Nystrom for talking security with us 🔥

Useful comments came in during IESG review from Brian Carpenter, Lars Eggert, Ted Hardie, Sam Hartman, and Russ Housley. Y'all are the real MVPs ✨

12. References

12.1. Normative References

[GMPLS-E2E] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
            Ed., "RSVP-TE Extensions in Support of End-to-End
            Generalized Multi-Protocol Label Switching (GMPLS)
            Recovery", RFC 4872, May 2007.

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2205]   Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
            S. Jamin, "Resource ReSerVation Protocol (RSVP) --
            Version 1 Functional Specification", RFC 2205, September
            1997.

[RFC2747]   Baker, F., Lindell, B., and M. Talwar, "RSVP
            Cryptographic Authentication", RFC 2747, January 2000.

[RFC2961]   Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
            and S. Molendini, "RSVP Refresh Overhead Reduction
            Extensions", RFC 2961, April 2001.

[RFC3209]   Awduche, 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., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Functional Description", RFC
            3471, January 2003.

[RFC3473]   Berger, L., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Resource ReserVation
            Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
            3473, January 2003.

[RFC3477]   Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
            in Resource ReSerVation Protocol - Traffic Engineering
            (RSVP-TE)", RFC 3477, January 2003.

[RFC3945]   Mannie, E., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Architecture", RFC 3945, October 2004.

[RFC4201]   Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
            in MPLS Traffic Engineering (TE)", RFC 4201, October
            2005.

[RFC4202]   Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
            Extensions in Support of Generalized Multi-Protocol Label
            Switching (GMPLS)", RFC 4202, October 2005.

[RFC4208]   Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
            "Generalized Multiprotocol Label Switching (GMPLS) User-
            Network Interface (UNI): Resource ReserVation Protocol-
            Traffic Engineering (RSVP-TE) Support for the Overlay
            Model", RFC 4208, October 2005.

[RFC4302]   Kent, S., "IP Authentication Header", RFC 4302, December
            2005.

[RFC4303]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
            4303, December 2005.

[RFC4306]   Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
            Protocol", RFC 4306, December 2005.

[RFC4426]   Lang, J., Ed., Rajagopalan, B., Ed., and D.
            Papadimitriou, Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Recovery Functional Specification", RFC
            4426, March 2006.

12.2. Informative References

[ASON-APPL] Drake, J., Papadimitriou, D., Farrel, A., Brungard, D.,
            Ali, Z., Ayyangar, A., Ould-Brahim, H., and D. Fedyk,
            "Generalized MPLS (GMPLS) RSVP-TE Signalling in support
            of Automatically Switched Optical Network (ASON), Work in
            Progress, July 2005.

[RFC4107]   Bellovin, S. and R. Housley, "Guidelines for
            Cryptographic Key Management", BCP 107, RFC 4107, June
            2005.

[RFC4139]   Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L.
            Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
            Usage and Extensions for Automatically Switched Optical
            Network (ASON)", RFC 4139, July 2005.

[STITCH]    Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
            "Label Switched Path Stitching with Generalized
            Multiprotocol Label Switching Traffic Engineering (GMPLS
            TE)", Work in Progress, April 2007.

For information on the availability of the following document, please see http://www.itu.int.

[G.8080]    ITU-T, "Architecture for the Automatically Switched
            Optical Network (ASON)," Recommendation G.8080/ Y.1304,
            November 2001 (and Revision, January 2003).

Authors' Addresses

John Drake
Boeing Satellite Systems
2300 East Imperial Highway
El Segundo, CA 90245
EMail: John.E.Drake2@boeing.com

Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
EMail: dbrungard@att.com

Zafar Ali (Cisco)
100 South Main St. #200
Ann Arbor, MI 48104, USA
EMail: zali@cisco.com

Arthi Ayyangar (Nuova Systems)
2600 San Tomas Expressway
Santa Clara, CA 95051
EMail: arthi@nuovasystems.com

Don Fedyk (Nortel Networks)
600 Technology Park Drive
Billerica, MA, 01821, USA
EMail: dwfedyk@nortel.com

Contact Addresses

Dimitri Papadimitriou
Alcatel-Lucent,
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel-lucent.be

Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk

Copyright (C) The IETF Trust (2007) 💖

This document is subject to the rights, licenses and restrictions in BCP 78. Except as set forth there, the authors keep all their rights.

THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

The IETF takes no position on whether any Intellectual Property Rights or other rights might be claimed to cover the technology in this document, or on whether any license under those rights might be available. It also doesn't claim to have made any independent effort to find such rights. Info on how RFC documents handle rights is in BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission to use such proprietary rights are available from the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org 🫶

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 🌸

📦 where this page comes from