Internet Engineering Task Force (IETF) G. Bernstein, Ed. Request for Comments: 6344 Grotto Networking Updates: 4606 D. Caviglia Category: Standards Track Ericsson ISSN: 2070-1721 R. Rabbat Google H. van Helvoort Huawei August 2011 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
AbstractThis document describes requirements for, and the use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS). LCAS can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. This document updates RFC 4606 by making modifications to 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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 ...................................20 RFC4606] to allow supporting additional
applications of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism that has been standardized for SONET, SDH, OTN, and PDH [ANSI-T1.105] [ITU-T-G.707] [ITU-T-G.709] [ITU-T-G.7043] technologies, along with its companion Link Capacity Adjustment Scheme (LCAS) [ITU-T-G.7042]. VCAT is a time-division multiplexing (TDM)-oriented byte striping inverse multiplexing method that works with a wide range of existing and emerging TDM framed signals, including very-high-bit-rate OTN and SDH/SONET signals. VCAT enables the selection of an optimal signal server bandwidth (size) utilizing a group of server signals and provides for efficient use of bandwidth in a mesh network. When combined with LCAS, hitless dynamic resizing of bandwidth and fast graceful degradation in the presence of network faults can be supported. To take full advantage of VCAT/LCAS functionality, additional extensions to GMPLS signaling are needed that enable the setup of 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 a subset of member signals are controlled by a management plane or a proprietary control plane are outside the scope of this document. RFC2119].
ITU-T-G.707] term "VCG" to refer to the VCAT group and the terminology "set" and "subset" to refer to the subdivision of the group and the individual VCAT group member signals. As noted above, the scope of these scenarios is limited to scenarios where all member signals are controlled using mechanisms defined in this document. The scenarios listed here are dependent on the terms "co-routed" and "diversely routed". In the context of this document, "co-routed" refers to a set of VCAT signals that all traverse the same sequence of switching nodes. Furthermore, a co-routed set of signals between any pair of adjacent nodes utilizes a set of links that have similar delay characteristics. Thus, "diversely routed" means a set of signals that are not classed 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 does not change and all member signals follow the same route to minimize differential delay. The application here is the capability to allocate an amount of bandwidth close to that 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., 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 to which it may belong. 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. Section 2.2 with no loss of traffic. o GMPLS signaling for non-LCAS-capable interfaces MUST support the "fixed" scenarios described in Section 2.2. To provide for these requirements, GMPLS signaling MUST carry the following information on behalf of the VCAT endpoints: o The type of the member signal that the VCG will contain, e.g., VC-3, VC-4, etc. o The total number of members to be in the VCG. This provides the endpoints in both the LCAS and non-LCAS case with information on which to accept or reject the request, and in the non-LCAS case will let the receiving endpoint know when all members of the VCG have been established. o Identification of the VCG and its associated members. This provides information that allows the endpoints to differentiate multiple VCGs and to tell what member, label switched paths (LSPs), to associate with a particular VCG.
ITU-T-G.7042]). VCG member - This is 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 - This is 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.
Section 2. This section describes the support of a single VCG composed of a single member set (in support of the fixed, co-routed application and the dynamic, co-routed application) using existing GMPLS procedures [RFC4606]. Note that this section is included for informational purposes only and does not modify [RFC4606]. It is provided to show how the existing GMPLS procedures may be used. [RFC4606] provides the normative definition for GMPLS processing of VCGs composed of a single member set, and in the event of any conflict between this section and that document, [RFC4606] takes precedence. 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 in support of the VCG. There are two options for setting up the VCG, depending on policy preferences: one-shot setup and incremental setup. The following sections explain the procedure based on an example of setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v SONET VCAT group), which is composed of 7 virtually concatenated VC-4s (or STS-3c). RFC4606]. In the case of this example: o Elementary signal is set to 6 (for VC-4/STS-3c_SPE). o NVC is set to 7 (number of members). o Per [RFC4606], a Multiplier Transform greater than 1 (say N > 1) may be used if the operator wants to set up N identical VCAT groups (for the same LSP).
o SDH or SONET labels have to be assigned for each member of the VCG and concatenated to form a single Generalized Label constructed as an ordered list of 32-bit timeslot identifiers of the same format as TDM labels. [RFC4606] requires that the order of the labels reflect the order of the payloads to concatenate, and not the physical order of timeslots. o Refer to [RFC4606] for other traffic parameter settings. ITU-T-G.7042]. 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. Note that if using LCAS, 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]. 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, as removing one or more components of the VCG will tear down the whole group. RFC3473]. 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). The setup of diversely routed VCG members requires multiple VCG member sets, i.e., multiple control plane LSPs.
The support of a VCG with multiple VCG member sets requires being able to identify separate sets of control plane LSPs with a single VCG and exchange information pertaining to 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 in support of VCG server-layer connections (VCG members) in the data plane. Note that the trigger for the VCG (by management plane or client layer) is outside the scope of this document. These procedures provide for autonomy of the client layer and server layer with respect to their management. In addition, by supporting the identification of a VCG (VCG ID) and VCAT call identification (VCAT Call ID), support can be provided for the 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; hence, to support member sharing, the procedures in this document provide support by moving call(s) and their associated LSPs from one VCG to another. Figure 1 below illustrates these relationships; however, note 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 Connections RFC4974]. To accommodate the VCG information, a new TLV is defined in this document for the CALL_ATTRIBUTES object [RFC6001] for use in the Notify message [RFC4974]. The Notify message is a targeted message and does not need to follow the path of LSPs through the network; i.e., there is no dependency on the member signaling for establishing the VCAT call, and the use of external call managers as described in [RFC4974] is not precluded.
The following information is needed: 1. Signal type 2. Number of VCG members 3. LCAS requirements: a. LCAS required b. LCAS desired c. LCAS not supported 4. VCG Identifier - Used to identify a particular VCG separately from the call ID so that call members can be reused with different VCGs per the requirements for member sharing and the requirements of Section 2.4. RFC6001] as follows: 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; hence, a VCAT call contains only 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 field is an unsigned integer that MUST indicate the total number of members in the VCG (not just the call). This field MUST be changed (over the life of the VCG) to indicate 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 supported Action: 8 bits This field is used to indicate the relationship between the call and the VCG and has the following 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 Call
VCG Identifier (ID): 16 bits This field carries an unsigned integer that is used to identify a particular VCG within a session. The value of the field MUST NOT change over the lifetime of a VCG but MAY change over the lifetime of a call. RFC4974], with the addition of the inclusion of a CALL_ATTRIBUTES object containing the VCAT TLV. Multiple VCAT layer calls per VCG are not required to support member sets, but are needed to support certain member-sharing scenarios. The remainder of this section provides specific procedures related to VCG signaling. The procedures described in [RFC4974] are only modified as discussed in this section. When LCAS is supported, the data plane will add or decrease the members per [ITU-T-G.7042]. When LCAS is not supported across LSPs, the data plane coordination across member sets is outside the scope of this document.
To establish a VCAT call with no VCG association, a CALL_ATTRIBUTES object containing the VCAT TLV MUST be included at the time of call setup in the Notify message. The VCAT TLV Action field MUST be set to 0, which indicates that this is a VCAT call without an associated VCG. LSPs can then be added to the call. 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.
The following sequence SHOULD be used when modifying the bandwidth of a VCG: 1. In both cases, prior to any other change, a Notify message MUST be sent with a CALL_ATTRIBUTES object containing a VCAT TLV for each of the existing VCAT calls associated with the VCG. The Action field of the TLV MUST be set to 2. The VCG ID field MUST be set to match the VCG. The Number of Members field MUST equal the sum of all LSPs that are anticipated to be associated with the VCG after the bandwidth change. The Notify message is otherwise formatted and processed to support call establishment as described in [RFC4974]. If an error is encountered while processing any of the Notify messages, 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 a Notify message as described above. Failures encountered in processing these Notify messages are handled per [RFC4974]. 2. 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 is dependent on the two cases defined above. In the first case defined above, 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. RFC4974], below is a list of error conditions that can be encountered while using the procedures defined in this document. These fall under RSVP error code 39. These can occur when setting up a VCAT call or associating a VCG with 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 7
Any failure in call or LSP establishment MUST be treated as a failure of the VCG as a whole and MAY trigger the calls and LSPs associated with the VCG being deleted. 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]
Section 5.2. New allocations are by "IETF Review" [RFC5226]. IANA maintains the following information: - Value - Type (Elementary Signal) - RFC The available range is 0 - 65535. The registry has been initially populated with the values shown in Section 5.2 of this document. Value 0 is Reserved. Other values are marked Unassigned. Section 5.2. New allocations are by "IETF Review" [RFC5226]. IANA maintains the following information: - Value - Meaning - RFC The available range is 0 - 255. The registry has been initially populated with the values shown in Section 5.2 of this document. Other values are marked Unassigned. RFC3473] and as modified by [RFC4974]. It does not introduce any new signaling messages, nor does it change the relationship between LSRs that are adjacent in the control plane. The call information associated with diversely routed control plane LSPs, in the event of an interception, may indicate that these are members of the same VCAT group that take a different route, and may indicate to an interceptor that the VCG call desires increased reliability. See [RFC5920] for additional information on GMPLS security.
[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. [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.