RFC 6344
Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
RFC 6344: Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) 🦋
Okay bestie, this one is RFC 6344 from the IETF, published in August 2011 as a Standards Track document ✨. The editor is G. Bernstein, Ed. (Grotto Networking), and the other authors are D. Caviglia (Ericsson), R. Rabbat (Google), and H. van Helvoort (Huawei) 💖. It's ISSN 2070-1721, and it updates RFC 4606. There's no Obsoletes entry in the header.
Abstract 🎀
So this doc is about what GMPLS (the control plane) needs to do to support VCAT, the layer 1 inverse multiplexing data plane mechanism, and its buddy LCAS 💅. LCAS is what gives you hitless dynamic resizing of the inverse multiplex group, which is so iconic 🔥. All of this applies to OTN, SONET, SDH, and PDH signals. This document updates RFC 4606 by changing the procedures for supporting virtual concatenation.
Status of This Memo 📋
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🫶. If you want more info on Internet Standards, check out Section 2 of RFC 5741.
You can find info about this doc's current status, any errata, and how to give feedback at http://www.rfc-editor.org/info/rfc6344 🌸.
Copyright Notice 💜
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
Table of Contents 📚
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. VCAT/LCAS Scenarios and Specific Requirements ...................4
2.1. VCAT/LCAS Interface Capabilities ...........................4
2.2. Member Signal Configuration Scenarios ......................5
2.3. VCAT Operation with or without LCAS ........................6
2.4. VCGs and VCG Members .......................................7
3. VCAT Data and Control Plane Concepts ............................7
4. VCGs Composed of a Single Member Set (One LSP) ..................8
4.1. One-Shot VCG Setup .........................................8
4.2. Incremental VCG Setup ......................................9
4.3. Procedure for VCG Reduction by Removing a Member ...........9
4.4. Removing Multiple VCG Members in One Shot .................10
4.5. Teardown of Whole VCG .....................................10
5. VCGs Composed of Multiple Member Sets (Multiple LSPs) ..........10
5.1. Signaled VCG Service Layer Information ....................11
5.2. CALL_ATTRIBUTES Object VCAT TLV ...........................12
5.3. Procedures for Multiple Member Sets .......................14
5.3.1. Setting Up a New VCAT Call and VCG Simultaneously ..14
5.3.2. Setting Up a VCAT Call and LSPs without a VCG ......14
5.3.3. Associating an Existing VCAT Call with a New VCG ...15
5.3.4. Removing the Association between a Call and VCG ....15
5.3.5. VCG Bandwidth Modification .........................15
6. Error Conditions and Codes .....................................16
7. IANA Considerations ............................................17
7.1. RSVP Call Attribute TLV ...................................17
7.2. RSVP Error Codes and Error Values .........................17
7.3. VCAT Elementary Signal Registry ...........................18
7.4. VCAT VCG Operation Actions ................................18
8. Security Considerations ........................................18
9. Contributors ...................................................19
10. Acknowledgments ...............................................19
11. References ....................................................19
11.1. Normative References .....................................19
11.2. Informative References ...................................201. Introduction ✨
GMPLS is a whole suite of protocols that automates control over different switching technologies, including SONET, SDH, OTN, and PDH 🌈. This document updates the procedures from [RFC4606] so you can support more applications of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism. VCAT is already standardized for SONET, SDH, OTN, and PDH [ANSI-T1.105] [ITU-T-G.707] [ITU-T-G.709] [ITU-T-G.7043], and its companion, the Link Capacity Adjustment Scheme (LCAS) [ITU-T-G.7042], comes along for the ride 🧚.
VCAT is a time-division multiplexing (TDM)-oriented byte striping inverse multiplexing method. It works with a wide range of existing and emerging TDM framed signals, including very-high-bit-rate OTN and SDH/SONET signals 💖. VCAT lets you pick an optimal signal server bandwidth (size) by using a group of server signals, and it makes efficient use of bandwidth in a mesh network. Pair it with LCAS and you get hitless dynamic resizing of bandwidth, plus fast graceful degradation when there are network faults 🔥. To get the full VCAT/LCAS experience, GMPLS signaling needs extra extensions so you can set up diversely routed signals that are members of the same VCAT group.
Note that the scope of this document is limited to scenarios where all member signals of a VCAT group are controlled using mechanisms defined in this document and related RFCs. Scenarios where only a subset of member signals are controlled by a management plane or a proprietary control plane are outside the scope of this document 🙈.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖.
2. VCAT/LCAS Scenarios and Specific Requirements 💅
There are a bunch of specific requirements for supporting VCAT/LCAS in GMPLS, and they come straight from the carriers' applications for using VCAT/LCAS. We lay them out in the following section 💼.
2.1. VCAT/LCAS Interface Capabilities
In general, a label switched router (LSR) can be the ingress or egress of one or more VCAT groups. VCAT and LCAS are data plane interface capabilities. For example, an LSR may have VCAT-capable interfaces that aren't LCAS-capable. At the same time, it may have interfaces that are neither VCAT-capable nor LCAS-capable 🌸.
2.2. Member Signal Configuration Scenarios
Here are the different scenarios. We use the [ITU-T-G.707] term "VCG" for the VCAT group, and the terms "set" and "subset" for how the group and its individual VCAT group member signals get subdivided 🦋. As mentioned above, these scenarios only cover cases where all member signals are controlled using mechanisms defined in this document.
The scenarios depend on the terms "co-routed" and "diversely routed". In this context, "co-routed" means a set of VCAT signals that all traverse the same sequence of switching nodes. Also, a co-routed set of signals between any pair of adjacent nodes uses a set of links that have similar delay characteristics. So "diversely routed" just means a set of signals that doesn't count as "co-routed" 🧩.
Fixed, co-routed: A fixed-bandwidth VCG, transported over a co-routed set of member signals. This is the case where the intended bandwidth of the VCG doesn't change and all member signals follow the same route to minimize differential delay 🎀. The application here is getting an amount of bandwidth close to what's required at the client layer.
Fixed, diversely routed: A fixed-bandwidth VCG, transported over at least two diversely routed subsets of member signals. In this case, the subsets are link-disjoint over at least one link of the route. The application here is more efficient use of network resources, e.g., when no unique route has the required bandwidth 🌈.
Fixed, member sharing: A fixed-bandwidth VCG, transported over a set of member signals that are allocated from a common pool of available member signals without requiring member connection teardown and setup. This document only covers the case where this pool of "potential" member signals has been established via mechanisms defined in this document. Member signals need not be co-routed or be guaranteed to be diversely routed. Note that, by the nature of VCAT, a member signal can only belong to one VCG at a time. To be used in a different VCG, a signal must first be removed from any VCG it may belong to 🔒.
Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or decreased via the addition or removal of member signals), transported over a co-routed set of members. The application here is dynamic resizing and resilience of bandwidth ⭐.
Dynamic, diversely routed: A dynamic VCG (bandwidth can be increased or decreased via the addition or removal of member signals), transported over at least two diversely routed subsets of member signals. The application here is efficient use of network resources, dynamic resizing, and resilience of bandwidth 👑.
Dynamic, member sharing: A dynamic-bandwidth VCG, transported over a set of member signals that are allocated from a common pool of available member signals without requiring member connection teardown and setup 🫧.
2.3. VCAT Operation with or without LCAS ✨
okay so VCAT can show up with LCAS or without it 🫶 LCAS is literally the bestie for flexible bandwidth services, but even when it's not around, VCAT is still a totally valid move 💅 So GMPLS mechanisms for VCAT operation are REQUIRED for both cases, LCAS available and LCAS not available. The GMPLS procedures for the two cases SHOULD be identical 🎀
- GMPLS signaling for LCAS-capable interfaces MUST support all scenarios described in Section 2.2 with no loss of traffic. 💖
- GMPLS signaling for non-LCAS-capable interfaces MUST support the
"fixed"scenarios described in Section 2.2. 🌸
To make all that happen, GMPLS signaling MUST carry the following info on behalf of the VCAT endpoints 👑
- The type of the member signal that the VCG will contain, e.g., VC-3, VC-4, etc. 🍓
- The total number of members to be in the VCG. This gives the endpoints in both the LCAS and non-LCAS cases something to decide whether to accept or reject the request with 🤔 and in the non-LCAS case it lets the receiving endpoint know when all members of the VCG have been established 🙌
- Identification of the VCG and its associated members. This helps the endpoints tell multiple VCGs apart and figure out which member label switched paths (LSPs) belong to which VCG 🧚
2.4. VCGs and VCG Members 🦋
The signaling solution SHOULD provide a mechanism to support these scenarios ✨
- VCG members (server-layer connections) may be set up prior to their use in a VCG. 🌷
- VCG members (server-layer connections) may exist after their corresponding VCG has been removed. 🫧
However, it is not required that any arbitrarily created server-layer connection be supported in the above scenarios, i.e., connections established without following the procedures described in this document. Not every random connection gets the VIP treatment 🙈
3. VCAT Data and Control Plane Concepts 🧚
okay so when we're using GMPLS with VCAT/LCAS, there's a bunch of control and data plane concepts we keep coming back to. Here's the squad 💜
- VCG - the group of data plane server-layer signals used to provide the bandwidth for the virtual concatenation link connection through a network ([ITU-T-G.7042]). 🌈
- VCG member - an individual data plane server-layer signal that belongs to a VCG ([ITU-T-G.7042]). 🎀
- Member set - one or more VCG members (or potential members) set up via the same control plane signaling exchange. Note that all members in a member set follow the same route 🛣️
- Data plane LSP - an individual VCG member. 🫶
- Control plane LSP - a control plane entity that can control multiple data plane LSPs. For our purposes here, this is equivalent to the member set. 👑
- Call - a control plane mechanism for providing association between endpoints and possibly key transit points. 💅
4. VCGs Composed of a Single Member Set (One LSP) 🎀
In this section and the next section, we're going to walk through the procedures for supporting the applications from Section 2. Let's go 🚀
This section covers a single VCG made up of a single member set, which supports both the fixed, co-routed application and the dynamic, co-routed application, using the existing GMPLS procedures in [RFC4606]. Note that this section is included for informational purposes only and does not modify [RFC4606]. It's just here to show how the existing GMPLS procedures may be used 🧁 [RFC4606] is the normative definition for GMPLS processing of VCGs composed of a single member set, so if this section and that document ever conflict, [RFC4606] takes precedence, no debate 💯
The existing GMPLS signaling protocols support a VCG composed of a single member set. Setup using the Number of Virtual Components (NVC) field is explained in Section 2.1 of [RFC4606]. In this case, one (single) control plane LSP is used to support the VCG 🫧
There are two options for setting up the VCG, depending on policy preferences: one-shot setup and incremental setup. Pick your fighter 🥊
The following sections explain the procedure using an example of setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v SONET VCAT group), which is made up of 7 virtually concatenated VC-4s (or STS-3c) 🌸
4.1. One-Shot VCG Setup 🚀
This section describes establishing an LSP that supports all VCG members as part of the initial LSP establishment. To set up an LSP like this, an RSVP-TE (Resource Reservation Protocol - Traffic Engineering) Path message is sent containing the SONET/SDH traffic parameters defined in [RFC4606]. For this example:
Elementary signalis set to6(forVC-4/STS-3c_SPE). 💖NVCis set to7(number of members). 🔢- Per [RFC4606], a
Multiplier Transformgreater than 1 (sayN > 1) may be used if the operator wants to set up N identical VCAT groups (for the same LSP). Multiplying the drama 🪄 - SDH or SONET labels have to be assigned for each member of the VCG and concatenated to form a single Generalized Label. That label is built as an ordered list of 32-bit timeslot identifiers in the same format as TDM labels. [RFC4606] requires that the order of the labels reflects the order of the payloads to concatenate, and not the physical order of timeslots. The order matters, bestie 🧵
- Refer to [RFC4606] for other traffic parameter settings. 📖
4.2. Incremental VCG Setup 🧩
In some cases, it may be necessary or desirable to set up the VCG members individually, or to add group members to an existing group 🫶
One example of this is when local policy requires that VCAT can only add VCAT members one at a time, or when the members can't be automatically matched at the ingress and egress for the purposes of inverse multiplexing. Serial or incremental setup solves this problem ✨
To pull off incremental setup, an iterative process is used to add group members. For each iteration, NVC is incremented up to the final value required. A successful iteration consists of the successful completion of Path and Resv signaling. At first, NVC = 1, and the label includes just one timeslot identifier 🌱
At each of the next iterations, NVC is set to (NVC + 1), and one more timeslot identifier is added to the ordered list in the Generalized Label (in the Path or Resv message). A node that receives a Path message containing changed fields will process the full Path message. Based on the new value of NVC, it adds a component signal to the VCAT group and switches the new timeslot based on the new label information 🔁
Once the new label (identifying the new member) is added to the LSP, LCAS may be used in the data plane to add the new member at the endpoints into the existing VCAT group. LCAS (data plane) signaling is described in [ITU-T-G.7042]. Look at that glow-up 🦋
4.3. Procedure for VCG Reduction by Removing a Member 🗑️
The procedure to remove a component signal is similar to the one used to add components, as described in Section 4.2. In the data plane, LCAS signaling is used first to take the component out of service from the group. LCAS signaling is described in [ITU-T-G.7042] 🫧
In this case, the NVC value is decremented by 1, and the timeslot identifier for the dropped component is removed from the ordered list in the Generalized Label 📉
Note that for interfaces that are not LCAS-capable, removing one component of the VCG will result in failure detection of the member at the endpoint and failure of the whole group. So this is a feature that only LCAS-capable VCAT interfaces can support without management intervention at the endpoints. Not the vibe for non-LCAS interfaces 😭
Note that if LCAS is being used, a VCG member can be temporarily removed from the VCG due to a failure of the component signal. The LCAS data plane signaling will take appropriate actions to adjust the VCG as described in [ITU-T-G.7042]. It's giving self-healing 🩹
4.4. Removing Multiple VCG Members in One Shot 💥
The procedure is similar to the one described in Section 4.3. In this case, the NVC value is changed to the new value, and all relevant timeslot identifiers for the components to be torn down are removed from the ordered list in the Generalized Label. This procedure is also not supported for VCAT-only interfaces without management intervention, since removing one or more components of the VCG will tear down the whole group 💀
4.5. Teardown of Whole VCG 🫧
The entire LSP is deleted in a single step (i.e., all components are removed in one go) using the deletion procedures described in [RFC3473]. Clean exit, no drama 👋
5. VCGs Composed of Multiple Member Sets (Multiple LSPs) 🌈
okay the reason VCGs with multiple member sets exist is that we need to support VCGs with diversely routed members. The initial GMPLS spec didn't support diversely routed signals using the NVC construct, which is so relatable 😩 [RFC4606] says:
[...] The standard definition for virtual concatenation allows each virtual concatenation component to travel over diverse paths. Within GMPLS, virtual concatenation components must travel over the same (component) link if they are part of the same LSP. This is due to the way that labels are bound to a (component) link. Note, however, that the routing of components on different paths is indeed equivalent to establishing different LSPs, each one having its own route. Several LSPs can be initiated and terminated between the same nodes, and their corresponding components can then be associated together (i.e., virtually concatenated).
So setting up diversely routed VCG members requires multiple VCG member sets, i.e., multiple control plane LSPs 🛤️
Supporting a VCG with multiple VCG member sets means being able to identify separate sets of control plane LSPs with a single VCG, and exchanging information about the VCG as a whole between the endpoints. This document updates the procedures described in [RFC4606] to provide this capability by using the call procedures and extensions described in [RFC4974]. The VCG makes use of one or more calls (VCAT calls) to associate control plane LSPs that support VCG server-layer connections (VCG members) in the data plane. Note that the trigger for the VCG (by the management plane or client layer) is outside the scope of this document. These procedures give the client layer and server layer autonomy with respect to their management 🙌
Also, by supporting the identification of a VCG (VCG ID) and a VCAT call identification (VCAT Call ID), we can support member-sharing scenarios, i.e., by explicitly separating the VCG ID from the VCAT call ID. Note that per [RFC4974], LSPs (connections) cannot be moved from one call to another. So, to support member sharing, the procedures in this document move call(s) and their associated LSPs from one VCG to another 🔄 Figure 1 below illustrates these relationships. Just keep in mind that VCAT calls can exist independently of a VCG (for connection pre-establishment), as will be described later in this document 🧠
+-------+ +-------------+ +-------+ +------------+
| |1 n| |1 n| |1 n| Data Plane |
| VCG |<>----| VCAT Call |<>----| LSP |<>----| Connection |
| | | | | | |(co-routed) |
+-------+ +-------------+ +-------+ +------------+
Figure 1. Conceptual Containment Relationship between VCG, VCAT
Calls, Control Plane LSPs, and Data Plane Connections5.1. Signaled VCG Service Layer Information ✨
okay so this part is all about the info that gets passed around at the VCG level 🎀, meaning between the VCG signaling endpoints, using the call procedures from [RFC4974]. to carry that info, a brand new TLV gets defined here for the CALL_ATTRIBUTES object [RFC6001], and it rides along in the Notify message [RFC4974]. the Notify message is a targeted message, so it doesn't have to follow the path of the LSPs through the network. no dependency on member signaling for establishing the VCAT call, and external call managers (see [RFC4974]) are still totally allowed 💅
the following info is needed:
- Signal type
- Number of VCG members
- LCAS requirements:
- (a) LCAS required
- (b) LCAS desired
- (c) LCAS not supported
- VCG Identifier, used to identify a particular VCG separately from the call ID, so call members can be reused with different VCGs per the requirements for member sharing and the requirements of Section 2.4. 🦋
5.2. CALL_ATTRIBUTES Object VCAT TLV 💖
this section defines the CALL_ATTRIBUTES object VCAT TLV for use in the CALL_ATTRIBUTES object [RFC6001], 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Members |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LCR| Reserved | Action | VCG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type, as defined in [RFC6001]. This field MUST be set to 2. 🌸
Length, as defined in [RFC6001]. This field MUST be set to 12. 🌸
Signal Type: 16 bits 🍓
the signal types can never be mixed in a VCG, so a VCAT call only ever has one signal type. this field can take the following values and MUST never change over the lifetime of a VCG [ANSI-T1.105] [ITU-T-G.707] [ITU-T-G.709] [ITU-T-G.7043]:
Value Type (Elementary Signal)
----- -------------------------
1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12
3 STS-1 SPE / VC-3
4 STS-3c SPE / VC-4
11 ODU1 (i.e., 2.5 Gbit/s)
12 ODU2 (i.e., 10 Gbit/s)
13 ODU3 (i.e., 40 Gbit/s)
21 T1 (i.e., 1.544 Mbps)
22 E1 (i.e., 2.048 Mbps)
23 E3 (i.e., 34.368 Mbps)
24 T3 (i.e., 44.736 Mbps)Number of Members: 16 bits 🧚
this is an unsigned integer that MUST indicate the total number of members in the VCG (not just the call). and it MUST be changed over the life of the VCG so it always shows the current number of members. 📈
LCR (LCAS Required): 2 bits 👑
this field can take the following values and MUST NOT change over the life of a VCG:
Value Meaning
----- ------------------
0 LCAS required
1 LCAS desired
2 LCAS not supportedAction: 8 bits 🎀
this field shows the relationship between the call and the VCG, and it has these values:
Value Meaning
----- -------------------------------------------------------
0 No VCG ID (set up call prior to VCG creation)
1 New VCG for Call
2 Modification of Number of Members (no change in VCG ID)
3 Remove VCG from CallVCG Identifier (ID): 16 bits 🦋
this is an unsigned integer that identifies a particular VCG within a session. the value MUST NOT change over the lifetime of a VCG, but it MAY change over the lifetime of a call. 🌈
5.3. Procedures for Multiple Member Sets 💅
making a VCG out of multiple member sets means setting up at least one VCAT-layer call. VCAT-layer calls and related LSPs (connections) MUST follow the procedures defined in [RFC4974], plus the addition of a CALL_ATTRIBUTES object containing the VCAT TLV. multiple VCAT-layer calls per VCG aren't required for member sets, but they're needed for certain member-sharing scenarios. ✨
the rest of this section covers the specific VCG signaling procedures. the procedures in [RFC4974] are only modified as discussed here.
when LCAS is supported, the data plane will add or decrease the members per [ITU-T-G.7042]. when LCAS isn't supported across LSPs, the data plane coordination across member sets is outside the scope of this document. 🙈
5.3.1. Setting Up a New VCAT Call and VCG Simultaneously 💖
to set up a VCAT call and tie it to a VCG at the same time, a CALL_ATTRIBUTES object containing the VCAT TLV MUST be included in the Notify message at call setup. the VCAT TLV Action field MUST be set to 1, which means this is a new VCG for this call. LSPs MUST then be added to the call until the number of members hits the number in the VCAT TLV. 🎀
5.3.2. Setting Up a VCAT Call and LSPs without a VCG 🦋
to pre-establish the server-layer connections for a VCG, a VCAT call MAY be set up without an associated VCG identifier. honestly this is how member-sharing works: a pool of VCAT calls with connections (LSPs) can be set up, and then one or more of those calls (with their connections) can get attached to a particular VCG using the VCG ID. multiple calls can be linked to a single VCG, but a call MUST NOT contain members used in more than one VCG. 🫶
to set up a VCAT call with no VCG association, a CALL_ATTRIBUTES object containing the VCAT TLV MUST be included at call setup in the Notify message. the VCAT TLV Action field MUST be set to 0, which means it's a VCAT call without an associated VCG. LSPs can be added to the call after that. the Number of Members parameter in the VCAT TLV has no meaning at this point, since it reflects the intended number of members in a VCG and not in a call. 🙃
5.3.3. Associating an Existing VCAT Call with a New VCG 🌸
a VCAT call that isn't already associated with a VCG may be associated with one. to make that happen, a Notify message MUST be sent with a CALL_ATTRIBUTES object containing a VCAT TLV. the TLV's Action field MUST be set to 1, and the VCG Identifier field MUST be set to correspond to the VCG. the Number of Members field MUST equal the sum of all LSPs associated with the VCG. 🍓
a node might have a limit on how many VCGs it supports, so when it gets any message with a change of VCG ID, this limit should be checked. and the sender of a message with a change of VCG ID MUST be prepared to get an error response. again, any error in a VCG may result in the failure of the complete VCG. 💀
5.3.4. Removing the Association between a Call and VCG 🧚
if you want to reuse the server-layer connections in a call for another VCG, the current association between the call and its VCG MUST first be removed. to do that, a Notify message MUST be sent with a CALL_ATTRIBUTES object containing a VCAT TLV. the TLV's Action field MUST be set to 3 (Remove VCG from Call). the VCG ID field is ignored and MAY be set to any value. the Number of Members field is also ignored and MAY be set to any value. once the association between a VCG and all existing calls has been removed, the VCG is considered torn down. 👑
5.3.5. VCG Bandwidth Modification 📈
these cases may happen when a VCG's bandwidth goes up or down:
- LSPs are added to or, in the case of a decrease, removed from a VCAT call already associated with a VCG.
- An existing VCAT call (and corresponding LSPs) is associated with a VCG or, in the case of a decrease, has its association removed. note that in the case of an increase, the call MUST NOT have any existing association with a VCG. 🫶
when you're changing the bandwidth of a VCG, the following sequence SHOULD be used:
- In both cases, prior to any other change, a
Notifymessage MUST be sent with aCALL_ATTRIBUTESobject containing a VCAT TLV for each of the existing VCAT calls associated with the VCG. TheActionfield of the TLV MUST be set to 2. TheVCG IDfield MUST be set to match the VCG. TheNumber of Membersfield MUST equal the sum of all LSPs that are anticipated to be associated with the VCG after the bandwidth change. TheNotifymessage is otherwise formatted and processed to support call establishment as described in [RFC4974]. If an error is encountered while processing any of theNotifymessages, the number of members is reverted to the pre-change value, and the increase is aborted. The reverted number of members MUST be signaled in aNotifymessage as described above. Failures encountered in processing theseNotifymessages are handled per [RFC4974]. 💅 - Once the existing calls have successfully been notified of the new number of members in the VCG, the bandwidth change can be made. The next step depends on the two cases defined above. In the first case, the bandwidth change is made by adding (in the case of an increase) or removing (in the case of a decrease) LSPs to or from the VCAT call per the procedures defined in [RFC4974]. In the second case, the procedure defined in Section 5.3.3 is followed for an increase, and the procedure defined in Section 5.3.4 is followed for a decrease. ✨
6. Error Conditions and Codes ✨
VCAT call and member LSP setup can get denied for a bunch of reasons. on top of the call procedures and error codes in [RFC4974], here's a list of error conditions you might run into with the procedures in this document. they all fall under RSVP error code 39. 🚨
these can come up when you're setting up a VCAT call or linking a VCG to a VCAT call:
Error Value
------------------------------------ --------
VCG signal type not supported 1
LCAS option not supported 2
Max number of VCGs exceeded 3
Max number of VCG members exceeded 4
LSP Type incompatible with VCAT call 5
Unknown LCR (LCAS required) value 6
Unknown or unsupported ACTION 7any failure in call or LSP setup MUST be treated as a failure of the VCG as a whole, and it MAY trigger the calls and LSPs tied to the VCG getting deleted. yikes, the whole VCG can go down with it 😭
7. IANA Considerations 🌈
7.1. RSVP Call Attribute TLV 💜
IANA has made the following assignments in the "Call Attributes TLV" section of the "RSVP PARAMETERS" registry available from http://www.iana.org. 🦋
IANA has made assignments from the Call Attributes TLV [RFC6001] portions of this registry. 🌸
this document introduces a new Call Attributes TLV:
TLV Value Name Reference
--------- ---------------------- ---------
4 VCAT TLV [RFC6344]7.2. RSVP Error Codes and Error Values 🚨
Okay so this is where the new RSVP error stuff gets registered, and it's giving organized 💅 A new RSVP Error Code and new Error Values are introduced. IANA assigned the following from the "RSVP Parameters" registry, using the sub-registry "Error Codes and Globally-Defined Error Value Sub-Codes" 🎀
Error Codes:
VCAT Call Management(39)
Error Values:
Meaning Value
------------------------------------ --------
VCG signal type not supported 1
LCAS option not supported 2
Max number of VCGs exceeded 3
Max number of VCG members exceeded 4
LSP Type incompatible with VCAT call 5
Unknown LCR (LCAS required) value 6
Unknown or unsupported ACTION 77.3. VCAT Elementary Signal Registry 🦋
IANA made a registry to keep track of the elementary signal types from Section 5.2, and it's obsessed with them 😭 New allocations are by "IETF Review" [RFC5226].
IANA keeps track of these fields:
- Value
- Type (Elementary Signal)
- RFC
The available range is 0 - 65535 🌈
The registry was started off with the values shown in Section 5.2 of this document. Value 0 is Reserved, and everything else is marked Unassigned 🌸
7.4. VCAT VCG Operation Actions 🧚
Same energy here: IANA made a registry for the VCAT VCG operation actions defined in Section 5.2 ✨ New allocations are by "IETF Review" [RFC5226].
IANA keeps track of these fields:
- Value
- Meaning
- RFC
The available range is 0 - 255 💜
The registry was initially filled with the values shown in Section 5.2 of this document. Everything else is marked Unassigned.
8. Security Considerations 🔐
Okay, serious bestie moment. This part is important, so read it carefully 🙈
This document introduces a specific use of the Notify message and ADMIN_STATUS object for GMPLS signaling, as originally specified in [RFC3473] and as modified by [RFC4974]. It does not introduce any new signaling messages, and it does not change the relationship between LSRs that are adjacent in the control plane. The call information attached to diversely routed control plane LSPs, if they get intercepted, may show that they are members of the same VCAT group taking a different route. It may also tell an interceptor that the VCG call wants increased reliability 👀
See [RFC5920] for additional information on GMPLS security.
9. Contributors 🫶
Wataru Imajuku (NTT)
1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847
Japan
Phone +81-46-859-4315
EMail: imajuku.wataru@lab.ntt.co.jp
Julien Meuric
France Telecom
2, avenue Pierre Marzin
22307 Lannion Cedex
France
Phone: +33 2 96 05 28 28
EMail: julien.meuric@orange-ft.com
Lyndon Ong
Ciena
PO Box 308
Cupertino, CA 95015
USA
Phone: +1 408 705 2978
EMail: lyong@ciena.com10. Acknowledgments 💖
The authors would like to thank Adrian Farrel, Maarten Vissers, Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li, Stephen Shew, Jonathan Saddler, and Dieter Beller for their extensive reviews and contributions to this document 👑
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606,
August 2006.
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions in Support of
Calls", RFC 4974, August 2007.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
Brungard, D., and JL. Le Roux, "Generalized MPLS
(GMPLS) Protocol Extensions for Multi-Layer and Multi-
Region Networks (MLN/MRN)", RFC 6001, October 2010.11.2. Informative References
[ANSI-T1.105] American National Standards Institute, "Synchronous
Optical Network (SONET) - Basic Description including
Multiplex Structure, Rates, and Formats", ANSI
T1.105-2001, May 2001.
[ITU-T-G.707] International Telecommunication Union, "Network Node
Interface for the Synchronous Digital Hierarchy
(SDH)", ITU-T Recommendation G.707, December 2003.
[ITU-T-G.709] International Telecommunication Union, "Interfaces for
the Optical Transport Network (OTN)", ITU-T
Recommendation G.709, March 2003.
[ITU-T-G.7042] International Telecommunication Union, "Link Capacity
Adjustment Scheme (LCAS) for Virtual Concatenated
Signals", ITU-T Recommendation G.7042, March 2006.
[ITU-T-G.7043] International Telecommunication Union, "Virtual
Concatenation of Plesiochronous Digital Hierarchy
(PDH) Signals", ITU-T Recommendation G.7043,
July 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.Authors' Addresses 🌟
Greg M. Bernstein (editor)
Grotto Networking
Fremont, CA
USA
Phone: (510) 573-2237
EMail: gregb@grotto-networking.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A 16153
Genoa Italy
Phone: +39 010 600 3736
EMail: diego.caviglia@ericsson.com
Richard Rabbat
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
EMail: rabbat@alum.mit.edu
Huub van Helvoort
Huawei Technologies, Ltd.
Kolkgriend 38, 1356 BC Almere
The Netherlands
Phone: +31 36 5315076
EMail: hhelvoort@huawei.com📦 where this page comes from
- ietf: rfc6344 2011-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms