CCAMP Working Group G. Bernstein (ed.) Internet Draft Grotto Networking Updates: RFC4606 D. Caviglia Category: Standards Track Ericsson Expires: January 2011 R. Rabbat Google H. van Helvoort Huawei July 12, 2010 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) draft-ietf-ccamp-gmpls-vcat-lcas-10.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 12, 2010. Copyright Notice Copyright (c) 2010 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 Bernstein Expires January 12, 2011 [Page 1]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 (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. Abstract This document describes requirements for, and 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) which 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 the procedures for supporting virtual concatenation in [RFC4606]. 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]. Table of Contents 1. Introduction...................................................3 2. VCAT/LCAS Scenarios and Specific Requirements..................4 2.1. VCAT/LCAS Interface Capabilities..........................4 2.2. Member Signal Configuration Scenarios.....................4 2.3. VCAT Operation With or Without LCAS.......................5 2.4. VCGs and VCG Members......................................6 3. VCAT Data and Control Plane Concepts...........................6 4. VCGs Composed of a Single Co-Signaled Member Set...............7 4.1. One-shot VCG Setup with Co-Signaled Members...............7 4.2. Incremental VCG Setup with Co-Signaled Members............8 4.3. Procedure for VCG Reduction by Removing a Member..........8 4.4. Removing Multiple VCG Members in One Shot.................9 4.5. Teardown of Whole VCG.....................................9 5. VCGs Composed of Multiple Co-Signaled Member Sets(Multiple LSPs)9 5.1. Signaled VCG Service Layer Information...................10 5.2. VCAT TLV.................................................11 5.3. Procedures for Multiple Co-signaled Member Sets..........13 Bernstein Expires January 12, 2011 [Page 2]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 5.3.1. Setting up a new VCAT call and VCG Simultaneously...13 5.3.2. Setting up a VCAT call + LSPs without a VCG.........13 5.3.3. Associating an existing VCAT call with a new VCG....14 5.3.4. Removing the association between a call and VCG.....14 5.3.5. VCG Bandwidth modification..........................14 6. Error Conditions and Codes....................................15 7. IANA Considerations...........................................16 7.1. RSVP CALL_ATTRIBUTE TLV..................................16 7.2. RSVP Error Codes and Error Values........................16 8. Security Considerations.......................................17 9. Contributors..................................................18 10. Acknowledgments..............................................18 11. References...................................................19 11.1. Normative References....................................19 11.2. Informative References..................................19 Author's Addresses...............................................20 Intellectual Property Statement..................................21 Disclaimer of Validity...........................................21 Acknowledgment...................................................21 1. Introduction The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols allows for the automated control of different switching technologies including Synchronous Optical Network (SONET)[ANSI- T1.105], Synchronous Digital Hierarchy (SDH)[ITU-T-G.707], Optical Transport Network (OTN)[ITU-T-G.709] and Plesiochronous Digital Hierarchy (PDH)[ITU-T-G.704]. This document updates the procedures of [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 [ITU-T-G.707, ITU-T- G.709, and ITU-T-G.7043] technologies along with its companion Link Capacity Adjustment Scheme (LCAS) [ITU-T-G.7042]. VCAT is a 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 Bernstein Expires January 12, 2011 [Page 3]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 where a subset of member signals are controlled by a management plane or a proprietary control plane are beyond the scope of this document. 2. VCAT/LCAS Scenarios and Specific Requirements There are a number of specific requirements for the support of VCAT/LCAS in GMPLS that can be derived from the carriers' applications for the use of VCAT/LCAS. These are set out in the following section. 2.1. VCAT/LCAS Interface Capabilities In general, an LSR can be ingress/egress of one or more VCAT groups. VCAT and LCAS are interface capabilities. An LSR may have, for example, VCAT-capable interfaces that are not LCAS-capable. It may at the same time have interfaces that are neither VCAT nor LCAS- capable. 2.2. Member Signal Configuration Scenarios We list in this section the different scenarios. Here we use the [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. 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. Bernstein Expires January 12, 2011 [Page 4]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 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. 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. 2.3. VCAT Operation With or Without LCAS VCAT capabilities may be present with or without the presence of LCAS. The use of LCAS is beneficial in the provisioning of services, but in the absence of LCAS, VCAT is still a valid technique. Therefore GMPLS mechanisms for the operation of VCAT are REQUIRED for both the case where LCAS is available and the case where it is not available. The GMPLS procedures for the two cases SHOULD be identical. . GMPLS signaling for LCAS-capable interfaces MUST support all scenarios of section 2.2. with no loss of traffic. . GMPLS signaling for non-LCAS-capable interfaces MUST support only the "fixed" scenarios of section 2.2. To provide for these requirements, GMPLS signaling MUST carry the following information on behalf of the VCAT endpoints: . The type of the member signal that the VCG will contain, e.g., VC-3, VC-4, etc. Bernstein Expires January 12, 2011 [Page 5]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 . 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. . Identification of the VCG and its associated members. This provides information that allows the endpoints to differentiate multiple VCGs and to tell what members (LSPs) to associate with a particular 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 of this document. 3. VCAT Data and Control Plane Concepts When utilizing GMPLS with VCAT/LCAS, we use a number of control and data plane concepts described below. VCG -- This is the group of data plane server layer signals used to provide the bandwidth. VCG member -- This is an individual data plane signal of one of the permitted SDH, SONET, OTN or PDH signal types. Co-signaled set -- One or more VCG members (or potential members) set up via the same control plane signaling exchange. Note that all members in a co-signaled set follow the same route. Co-routed set - One or more VCG members that follow the same route. Although VCG members may follow the same path, this does not imply that they were co-signaled. Data plane LSP -- This is an individual VCG member. Bernstein Expires January 12, 2011 [Page 6]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 Control plane LSP -- A control plane entity that can control multiple data plane LSPs. For our purposes here, this is equivalent to the co-signaled member set. Call - A control plane mechanism for providing association between endpoints and possibly key transit points. 4. VCGs Composed of a Single Co-Signaled Member Set In this section and the next section, we will describe the procedures for supporting the applications described in Section 2. This section describes the support of a single VCG composed of a single co-signaled 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. The existing GMPLS signaling protocols support a VCG composed of a single co-signaled member set. Setup using the 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 hardware capability or management 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). 4.1. One-shot VCG Setup with Co-Signaled Members An RSVP-TE Path message is used with the following parameters: . With regards to the traffic parameters, the elementary signal is set to 6 (for VC-4/STS-3c_SPE). The value of NVC is then set to 7 (number of members). . Per [RFC4606] a Multiplier Transform greater than 1 (say N>1) is used if the operator wants to set up N VCAT groups that will belong to, and be assigned to, the same LSP. Bernstein Expires January 12, 2011 [Page 7]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 . SDH or SONET labels in turn 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 time-slots. 4.2. Incremental VCG Setup with Co-Signaled Members 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 need is when the hardware that supports VCAT can only add VCAT elements one at a time or cannot automatically match the elements at the ingress and egress for the purposes of inverse multiplexing. Serial or incremental setup solves this problem. In order to accomplish 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), 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 that contains changed fields will process the full Path message and, based on the new value of NVC, it will add a component signal to the VCAT group, and switch the new timeslot based on the new label information. Following the addition of the new label (identifying the new member) to the LSP, in the data plane, LCAS may be used to add the new member into the existing VCAT group. LCAS (data plane) signaling is described in [ITU-T-G.7042]. 4.3. Procedure for VCG Reduction by Removing a Member The procedure to remove a component signal is similar to that used to add components as described in Section 4.1.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. Bernstein Expires January 12, 2011 [Page 8]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 Note that for interfaces that are not LCAS-capable, removing one component of the VCG will result in data plane errors and result in the teardown (failure) of the whole group. So, this is a feature that only LCAS-capable VCAT interfaces can support without management intervention at the end points. Note also that a VCG member can be temporary 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]. 4.4. Removing Multiple VCG Members in One Shot The procedure is similar to 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. 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 deletion procedures of [RFC3473]. 5. VCGs Composed of Multiple Co-Signaled Member Sets(Multiple LSPs) The motivation for VCGs composed of multiple co-signaled member sets comes from the requirement to support VCGs with diversely routed members. The initial GMPLS specification did not support diversely routed signals using the NVC construct. In fact, [RFC4606] says: [...] The standard definition for virtual concatenation allows each virtual concatenation components 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 co- signaled VCG member sets, i.e., multiple control plane LSPs. Bernstein Expires January 12, 2011 [Page 9]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 The support of a VCG with multiple co-signaled VCG members 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. This is provided by using the call procedures and extensions described in [RFC4974]. The VCG is a higher layer service that 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, the trigger for the VCG (by management plane or client layer) is outside the scope of this document. In addition, by supporting the identification of a VCG and VCAT call identification, 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, 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 Figure 1. Conceptual containment relationship between VCG, VCAT calls, control plane LSPs, and data plane connections. 5.1. Signaled VCG Service Layer Information In this section, we provide a list of information that will be communicated at the VCG level, i.e., between the VCG signaling endpoints. When a VCG is composed of multiple co-signaled member sets, none of the individual LSP's control plane signaling information can contain information pertinent to the entire VCG. To accommodate this information, additional objects or TLVs are incorporated into the Notify message as it is described for use in call signaling in [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 does not preclude the use of external call managers as described in [RFC4974]. VCG Call setup is signaled with a new CALL_ATTRIBUTES object TLV containing the following information: Bernstein Expires January 12, 2011 [Page 10]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 1. Signal Type 2. Number of VCG Members 3. LCAS requirements: a. LCAS required b. LCAS desired c. LCAS not desired (but acceptable) 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. 5.2. VCAT TLV In RFC4974 the general mechanisms and procedures for communicating call information via Notify messages is defined. In [MLN-Ext] the CALL_ATTRIBUTES object is defined for the conveyance of call related information during call establishment and updates. We define a new CALL_ATTRIBUTES object VCAT TLV for use in the CALL_ATTRIBUTES object 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 = TBA | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Number of Members | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCAS Req | Action | VCG ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type, as defined in [MLN-Ext]. This field MUST be set to TBA (by IANA). Length, as defined in [MLN-Ext]. This field MUST be set to 12. Signal Type: 16 bits 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]: Bernstein Expires January 12, 2011 [Page 11]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 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 OPU1 (i.e., 2.5 Gbit/s 12 OPU2 (i.e., 10 Gbit/s) 13 OPU3 (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. LCAS Required: 8 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 desired (but acceptable) Action: 8 bits This field is used to indicate the relationship between the call and the VCG and has the following values. Bernstein Expires January 12, 2011 [Page 12]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 Value Meaning ----- --------------------------------- 0 No VCG ID (set up call prior to VCG creation) 1 New VCG for Call 2 No Change in VCG ID (number of members may have changed) 3 Remove VCG from Call VCG Identifier (ID): 16 bit 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. 5.3. Procedures for Multiple Co-signaled Member Sets The creation of a VCG based on multiple co-signaled member sets requires the establishment of at least one VCAT layer call. VCAT layer calls and related LSPs (connections) MUST follow the the Procedures in Support of Calls and Connections as defined in [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 co-signaled member sets, but are needed to support certain member sharing scenario. The remainder of this section provides specific procedures related to VCG signaling. The procedures of [RFC4974] are only modified as discussed in this section. 5.3.1. Setting up a new VCAT call and VCG Simultaneously To simultaneously set up a VCAT call and identify it with an associated VCG, a CALL_ATTRIBUTES object containing the VCAT TLV MUST be included at the time of call setup. The VCAT TLV Action field MUST be set to 1, which indicates that this is a new VCG for this call. LSPs MUST then be added to the call until the number of members reaches the number specified in the VCAT TLV. 5.3.2. Setting up a VCAT call + LSPs without a VCG To provide for pre-establishment of the server layer connections for a VCG a VCAT call MAY be established without an associated VCG identifier. In fact, to provide for the member sharing scenario, a pool of VCAT calls with associated connections (LSPs) can be established, and then one or more of these calls (with accompanying connections) can be associated with a particular VCG (via the VCG Bernstein Expires January 12, 2011 [Page 13]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 ID). Note that multiple calls can be associated with a single VCG but that a call MUST NOT contain members used in more than one VCG. 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. 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. Note that signal types can never be mixed in a VCG and hence a VCAT call contains only one signal type. 5.3.3. Associating an existing VCAT call with a new VCG A VCAT call that is not otherwise associated with a VCG may be associated with a VCG. To establish such an association 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 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. The Notify message is otherwise formatted and processed as defined under Call Establishment in [RFC4974]. Note that the total number of VCGs supported by a piece of equipment may be limited and hence on reception of any message with a change of VCG ID this limit should be checked. Likewise the sender of a message with a change in VCG ID MUST be prepared to receive 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 To reuse the server layer connections in a call in another VCG, the current association between the call and a VCG MUST first be removed. To do this, a Notify message MUST be sent with a CALL_ATTRIBUTES object containing a VCAT TLV. The Action field of the TLV 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. When the association between a VCG and all existing calls has been removed then the VCG is considered torn down. The Notify message is otherwise formatted and processed as defined under Call Establishment in [RFC4974]. 5.3.5. VCG Bandwidth modification The following cases may occur when increasing or decreasing the bandwidth of a VCG: Bernstein Expires January 12, 2011 [Page 14]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 1. LSPs are added to or, in the case of a decrease, removed from a VCAT Call already associated with a VCG. 2. 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 increase case, the call MUST NOT have any existing association with a VCG. The following internal ordering SHOULD be used when modifying the bandwidth of a VCG in a hitless fashion when LCAS is supported: 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 as defined under Call Establishment 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. Any failures encountered in processing these Notify messages are ignored. 2. Once the existing calls have successfully been notified of the new number of members in the VCG, the bandwidth change can be made. In the case of a decrease, the internal LCAS entity at the endpoints MUST "deactivate" the VCG member(s). 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 increase) or removing (in the case of a decrease) LSPs to the VCAT call per the procedures defined in [RFC4974]. In the second case, the same procedure defined in Section 5.3.3. is followed for an increase, and the procedure defined in Section 5.3.4. is followed for an decrease. In the case of an increase, after the bandwidth change is successfully made, the internal LCAS entity at the endpoints MUST "activate" the new VCG member(s). 6. Error Conditions and Codes VCAT Call and member LSP setup can be denied for various reasons. In addition to the call procedures and related error codes described in [RFC4974], below is a list of error conditions that can be Bernstein Expires January 12, 2011 [Page 15]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 encountered during the procedures as defined in this document. These fall under RSVP error code TBA. 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 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. 7. IANA Considerations 7.1. RSVP CALL_ATTRIBUTE TLV IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters. We request that IANA make assignments from the CALL_ATTRIBUTES TLV [MLN-Ext] portions of this registry. This document introduces a new CALL_ATTRIBUTES TLV TLV Value Name Reference --------- ---------------------- --------- TBD (2) VCAT_TLV [This I-D] 7.2. RSVP Error Codes and Error Values A new RSVP Error Code and new Error Values are introduced. We request IANA make assignments from the "RSVP Parameters" registry using the sub-registry "Error Codes and Globally-Defined Error Value Sub-Codes". o Error Codes: - VCAT Call Management (value TBD) Bernstein Expires January 12, 2011 [Page 16]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 o 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 8. Security Considerations This document introduces a specific use of the Notify message and admin status object for GMPLS signaling as originally specified in [RFC4974]. It does not introduce any new signaling messages, nor 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. Otherwise, this document does not introduce any additional security considerations. Bernstein Expires January 12, 2011 [Page 17]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 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 United States of America Phone: +1 408 705 2978 Email: lyong@ciena.com 10. 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 extensive reviews and contributions to this draft. Bernstein Expires January 12, 2011 [Page 18]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 11. References 11.1. Normative References [MLN-Ext] Papadimitriou, D., Vigoureux M., Shiomoto, K. Brungard, D., Le Roux, JL., "Generalized Multi- Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", work in progress: draft-ietf-ccamp-gmpls-mln- extensions-09.txt, October, 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [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, December 2005. [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007. 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.7042] International Telecommunications Union, "Link Capacity Adjustment Scheme (LCAS) for Virtual Concatenated Signals", ITU-T Recommendation G.7042, March 2006. Bernstein Expires January 12, 2011 [Page 19]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 [ITU-T-G.7043] International Telecommunications Union, "Virtual Concatenation of Plesiochronous Digital Hierarchy (PDH) Signals", ITU-T Recommendation G.7043, July 2004. [ITU-T-G.704] International Telecommunications Union, " Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 kbit/s hierarchical levels", ITU-T Recommendation G.704, October 1998. [ITU-T-G.707] International Telecommunications Union, "Network Node Interface for the Synchronous Digital Hierarchy (SDH)", ITU-T Recommendation G.707, December 2003. [ITU-T-G.709] International Telecommunications Union, "Interfaces for the Optical Transport Network (OTN)", ITU-T Recommendation G.709, March 2003. Author's Addresses Greg M. Bernstein (ed.) Grotto Networking Fremont California, 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@(marconi.com, ericsson.com) Richard Rabbat Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043, USA Email: rabbat@alum.mit.edu Bernstein Expires January 12, 2011 [Page 20]
Internet-Draft Operating VCAT and LCAS with GMPLS July 2010 Huub van Helvoort Huawei Technologies, Ltd. Kolkgriend 38, 1356 BC Almere The Netherlands Phone: +31 36 5315076 Email: hhelvoort@huawei.com Intellectual Property Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Bernstein Expires January 12, 2011 [Page 21]
