CCAMP Working Group G. Bernstein (ed.) Internet Draft Grotto Networking Updates: RFC 3946 D. Caviglia Category: Standards Track Ericsson Expires:
AprilAugust 2008 R. Rabbat Google H. van Helvoort Huawei October 3, 2007February 5, 2008 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) draft-ietf-ccamp-gmpls-vcat-lcas-03.txtdraft-ietf-ccamp-gmpls-vcat-lcas-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 October 3, 2007.August 5, 2008. Abstract This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing 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. 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. Revision History...............................................3 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........3draft-ietf-ccamp-gmpls-vcat-lcas-03..........3 2.2. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........3draft-ietf-ccamp-gmpls-vcat-lcas-02..........4 2.3. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4 2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........4 3. VCAT/LCAS Scenarios and Specific Requirements..................4Requirements..................5 3.1. VCAT/LCAS Interface Capabilities..........................4Capabilities..........................5 3.2. Member Signal Configuration Scenarios.....................4Scenarios.....................5 3.3. VCAT Operation With or Without LCAS.......................5LCAS.......................6 3.4. VCGs and VCG Members......................................7 4. GMPLS Mechanisms in Support of VCGs............................6VCGs............................7 4.1. VCGs Composed of a Single Co-Signaled Member Set..........7Set..........8 4.1.1. One-shot VCG Setup with Co-Signaled Members..........7Members..........8 4.1.2. Incremental VCG Setup with Co-Signaled Members.......8 4.1.3. Procedure for VCG Reduction by Removing a Member.....8Member.....9 4.1.4. Removing Multiple VCG Members in One Shot............9 4.1.5. Teardown of Whole VCG................................9VCG...............................10 4.2. VCGs Composed of Multiple Co-Signaled Member Sets.........9Sets........10 4.2.1. Signaled VCG Layer Information......................10 126.96.36.199.3. Call Data Object.........................................11 4.4. VCAT TLV Object..........................................11 4.5. Procedures for VCG Control withMultiple Co-signaled Member Sets................................................10 4.3. Member Sharing -- Multiple VCGs per Call.................11Sets..........13 4.5.1. Setting up a VCAT call and VCG......................14 4.5.2. Setting up a VCAT call + LSPs with no VCG...........14 4.5.3. Associating an existing VCAT call with a VCG........15 4.5.4. Removing the association between a call and VCG.....15 5. IANA Considerations...........................................13Error Conditions and Codes....................................16 6. Security Considerations.......................................13IANA Considerations...........................................16 7. Contributors..................................................14Security Considerations.......................................16 8. Acknowledgments...............................................14Contributors..................................................17 9. References....................................................15 9.1.Acknowledgments...............................................17 10. References...................................................18 10.1. Normative References.....................................15 9.2.References....................................18 10.2. Informative References...................................15References..................................18 Author's Addresses...............................................16Addresses...............................................19 Intellectual Property Statement..................................16Statement..................................19 Disclaimer of Validity...........................................17Validity...........................................20 Copyright Statement..............................................17 Acknowledgment...................................................17Statement..............................................20 Acknowledgment...................................................20 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), Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN) and Plesiochronous Digital Hierarchy (PDH). This document describes extensions to RSVP-TE to support the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism that has been standardized for SONET, SDH, OTN and PDH technologies along with its companion Link Capacity Adjustment Scheme (LCAS). 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. Other than member signal skew compensation this layer 1 inverse multiplexing mechanism adds minimal additional signal delay. VCAT enables the selection of an optimal signal bandwidth (size), extraction of bandwidth from a mesh network, and, when combined with LCAS, hitless dynamic resizing of bandwidth and fast graceful degradation in the presence of network faults. To take full advantage of VCAT/LCAS functionality extensions to GMPLS signaling are given that enable the setup of diversely routed circuits that are members of the same VCAT group. 2. Revision History 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03 o Added requirements on pre-existing members. o Slightly modified solution for member sharing to constrain calls to a maximum of one VCG. o Introduced the CALL_DATA object. o Detailed coding of new TLV for VCAT to be included in the CALL_DATA object. o Modified and expanded procedures to deal with new requirements and modified solution methodology. o Added a list of error conditions. 2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02 o Grammar and punctuation fixes. Updated references with newly published RFCs. 188.8.131.52. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01 o Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint" to "VCAT/LCAS Interface Capability" to improve clarity. o Changed terminology from "component" signal to "member" signal where possible (not quoted text) to avoid confusion with link bundle components. o Added "Dynamic, member sharing" scenario. o Clarified requirements with respect to scenarios and the LCAS and non-LCAS cases. o Added text describing needed signaling information between the VCAT endpoints to support required scenarios. o Added text to describe: co-signaled, co-routed, data plane LSP, control plane LSP and their relationship to the VCAT/LCAS application. o Change implementation mechanism from one based on the Association object to one based on "Call concepts" utilizing the Notify message. 184.108.40.206. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00 o Updated reference from RFC3946bis to issued RFC4606 o Updated section 3.2 based on discussions on the mailing list 3. 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' application-specific demands for the use of VCAT/LCAS and from the flexible nature of VCAT/LCAS. These are set out in the following section. 3.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. 3.2. Member Signal Configuration Scenarios We list in this section the different scenarios. Here we use the term "VCG" to refer to the entire VCAT group and the terminology "set" and "subset" to refer to the collection of potential VCAT group member signals. o 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 intent here is the capability to allocate an amount of bandwidth close to that required at the client layer. o 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 intent here is more efficient use of network resources, e.g., no unique route has the required bandwidth. o 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. o 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 intent here is dynamic resizing and resilience of bandwidth. o 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 intent here is efficient use of network resources, dynamic resizing and resilience of bandwidth. o 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. 3.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 to the provision 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. o GMPLS signaling for LCAS-capable interfaces MUST support all scenarios of section 3.2. with no loss of traffic. o GMPLS signaling for non-LCAS-capable interfaces MUST support only the "fixed" scenarios of section 3.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 member 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 members (LSPs) to associate with a particular VCG. 3.4. VCGs and VCG Members o VCG members (server layer connections) may be set up prior to their use in a VCG. o VCG members (server layer connections) may exist after their corresponding VCG has been removed. The signaling solution SHOULD provide a mechanism to support the previous scenarios. However, it is not required that arbitrarily created server layer connections be supported in the above scenarios. 4. GMPLS Mechanisms in Support of VCGs We describe in this section the signaling mechanisms that already exist in GMPLS using RSVP-TE [RFC3473] and [RFC4328], and the extensions needed to completely support the requirements of section 3. When utilizing GMPLS with VCAT/LCAS we utilize a number of control and data plane concepts that we describe below. 1. VCG member -- This is an individual data plane signal of one of the permitted SDH, SONET, OTN or PDH signal types. 2. Co-signaled 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 co-signaled set follow the same route. 3. Co-routed member 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. 4. Data plane LSP -- for our purposes here, this is equivalent to an individual VCG member. 5. Control plane LSP -- A control plane entity that can control multiple data plane LSPs. For our purposes here this is equivalent to our co-signaled member set. Section 4.1 is included for informational purposes only. It describes existing GMPLS procedures that support a single VCG composed of a single co-signaled member set. Section 4.2 describes new procedures to support VCGs composed of more than one co-signaled member sets. This includes the important application of a VCG composed of diversely routed members. Where possible it reuses applicable existing procedures from section 4.1. 4.1. VCGs Composed of a Single Co-Signaled Member Set Note that this section is 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). 4.1.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 chosen (6 for VC-4/STS-3c_SPE). The value of NVC is then set to 7. 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, one LSP. 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.1.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. The 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 to the LSP, LCAS may be used in-band to add the new label into the existing VCAT group. LCAS signaling for this function is described in [ITU-T-G.7042]. 4.1.3. Procedure for VCG Reduction by Removing a Member A VCG member can be permanently removed from the VCG either as the result of a management command or following a temporary removal (due to a failure). The procedure to remove a component signal is similar to that used to add components as described in Section 4.1.2. The LCAS in-band signaling step is taken 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 errors in the inverse- multiplexing procedure of VCAT and result in the teardown of the whole group. So, this is a feature that only LCAS-capable VCAT interfaces can support without management intervention at the end points. 4.1.4. Removing Multiple VCG Members in One Shot The procedure is similar to 4.1.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.1.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]. 4.2. VCGs Composed of Multiple Co-Signaled Member Sets 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. To support a VCG with multiple co-signaled VCG members sets requires being able to identify separate control plane LSPs with a single VCG and exchange information pertaining to the VCG as a whole. This is very similar to the "Call" concept described in [RFC4974]. We can think of our VCAT/LCAS connection, e.g., our VCG, as a higher layer service that makes use of multiple lower layer (server) connections that are controlled by one or more control plane LSPs. 4.2.1. Signaled VCG Layer Information When a VCG is composed of multiple co-signaled member sets, none of the control plane LSP's signaling information can contain information pertinent to the entire VCG. In this section we give a list of information that should be communicated at what we define as the VCG Call layer, i.e., between the VCG signaling endpoints. To accommodate this information additional objects or TLVs would need to beare incorporated into the Notify message as it is described for use in call signaling in [RFC4974]. VCG Call setup information signaled via the Notify message with the Call management bit (C-bit) set: 1. Signal Type 2. Number of VCG Members 3. LCAS requirements: a. LCAS required b. LCAS desired c. LCAS not desired (but acceptable) d. LCAS not acceptable 4. Maximum Number ofVCG Identifier - Used to identify a particular VCG separately from the call ID so that call members can be reused with different VCGs per Call-- This is a hook to supportthe requirements for member sharing scenario. In the non-member sharing case the value is one. 4.2.2. Procedures for VCG Control with Multiple Co-signaled Member Sets This section deals only withand the caserequirements of one VCG per (VCG) Call. To establish a VCG,section 3.4. 4.3. Call Data Object In RFC4974 the general mechanism for communicating call information of section 4.2.1.via notify messages is exchangedgiven. In general different types of calls will need to convey call related information during call establishment and agreed upon with the corresponding VCG signaling endpoint. Since only one VCG is being signaled by this call, all control plane LSPs used with this call establish membersupdates. We define a general CALL_DATA object for this VCGinclusion in call related notify messages and there is no ambiguity as to which VCGdefine a potential member belongs. Proceduresspecific class type (C-Type) for addition and removal of bandwidth are the same asVCAT calls. 4.4. VCAT TLV Object For use in the single co- signaled case except that a VCG Call layer message should precede any of those changes and indicateCALL_DATA object (of VCAT-Call C-Type) in Notify messages we define the new total numberfollowing VCAT TLV: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Number of VCG members. In generalMembers | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCAS Req | Action | VCG ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signal Type can take the following order is used to establishvalues and increaseMUST never change over the bandwidth inlifetime of a VCG: 1. VCG Call layer informationValue 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 Gbps) 12 OPU2 (i.e., 10 Gbps) 13 OPU3 (i.e., 40 Gbps) 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 is conveyed. Note that duringa "bandwidth" change onlynon-negative integer that indicates the total number of VCGmembers is allowed to change. 2. Control Plane LSPs are used to add data plane LSPs (members) toin the VCG. 3. If LCAS is supported on thisVCG call it should(not just the call)and MUST be instructed bychanged over the endpointslife of the VCG to "activate"indicate the member. In generalcurrent number of members. LCAS Required can take the following order is used when decreasingvalues and MUST NOT change over the bandwidth inlife of a VCG: 1. VCG Call layer information is conveyed concerning the decreased number of VCG members. 2. IfValue Meaning ----- --------------------------------- 0 LCAS required 1 LCAS desired 2 LCAS not desired (but acceptable) 3 LCAS not acceptable Action is supported on this VCGused to indicate the relationship between the call it should be instructed byand the endpoints to "deactivate"VCG and takes the membersfollowing values. Value Meaning ----- --------------------------------- 0 No VCG ID (set up call prior to be removed. 3. Existing control plane LSPs areVCG creation) 1 New VCG for Call 2 No Change in VCG ID (number of members may have changed) 3 Remove VCG from Call VCG ID: A 16 bit non-negative integer used to remove the data plane LSPs (members). Note that when LCAS is not used or unavailable theidentify a particular VCG will be in an unknown state between the timewithin a session. This number MUST NOT change over the lifetime of a VCG call level information is updated andbut can change over the actual data plane LSPs are added or removed. 4.3. Member Sharing -- Multiple VCGs per Calllifetime of a call. To support the member sharing scenario of section 3.2. we allow multiple VCGs withinand the contextrequirements of section 3.4. we allow the VCG Call defined here. This is partially dueIdentifier within a call to be changed. In this way the requirement in reference [RFC4974] that LSPs areconnections associated with a singlecall over their lifetime. Hence we propose using the VCG Call mechanism previously describedcan be dedicated to establish the common member poola new VCG (allowing for all the VCGs to be included in the scope of this particulara priori connection establishment and connection persistence after a VCG Call. Note that the maximum numberhas been removed). 4.5. Procedures for Multiple Co-signaled Member Sets To establish a VCG a CALL_DATA object containing a VCAT TLV is exchanged as part of VCGs percall isestablishment or update. A VCG can be established at the same time as a key parameter tonew call acceptanceor rejection sinceassociated with an existing call that currently has not VCG association. When modifying the bandwidth of a VCG a CALL_DATA object containing a VCAT equipment typically puts limits onTLV MUST precede any of those changes and indicate the new total number of VCGs thatVCG members. The following mechanisms can be simultaneously supported. To assign a data plane LSPused to be a memberincrease the bandwidth of a particular VCG orVCG. o LSPs are added to removea data plane LSP from beingVCAT Call associated with a memberVCG (Action = 2). o A VCG is associated with an existing VCAT call containing LSPs (Action = 1). The following internal ordering is used when increasing the bandwidth of a particular VCG, requires additionalVCG layer communications.in a hitless fashion when LCAS [ITU-T-G.7042] cannot provide such signaling since it does notis supported: 1. A CALL_DATA Object containing a VCAT TLV indicating the new number of members after the proposed increase is sent. If an error is returned from the receiver the VCG state remains the same prior to providethe attempted increase. 2. Either: (a) New LSPs are set up within a waycall associated with the VCG, or (b) LSPs in an existing call are now associated with the VCG. 3. The internal LCAS entity is instructed by the endpoints to indicate which"activate" the new VCG outmember(s). The following mechanisms can be used to decrease the bandwidth of multiple betweena source and destinationVCG. o LSPs are removed from a member should belong.VCAT Call associated with a VCG (Action = 2). o A VCG association is removed from existing VCAT call containing LSPs (Action = 3). In particular, although, it seemsgeneral the following internal ordering is used when decreasing the bandwidth of a VCG in a hitless fashion when LCAS is supported: 1. A CALL_DATA Object containing a VCAT TLV indicating the new number of members after the proposed decrease is sent. If an error is returned from the receiver the VCG state remains the same prior to the attempted decrease. 2. The LCAS entity is instructed by the endpoints to "deactivate" the members to be removed from the VCG. 3. Either: (a) An LSP is removed from a call associated with a VCG; or (b) All the LSPs of a call are removed from the VCG when the association between the VCG and VCAT call is removed. Note that LCAS' Group Identification (GID) bit shouldwhen LCAS is not used or unavailable the VCG will be in an unknown state between the time the VCG call level information is updated and the actual data plane LSPs are added or removed. Note that the incremental setup procedure of section 4.1.2. can be usefulapplied to any of the above procedures. 4.5.1. Setting up a VCAT call and VCG Arguably the most common operation will be simultaneously setting up a VCAT call and its associated VCG at the same time. To do this when one sets up a new VCAT call in the VCAT TLV one sets Action = 1 indicating that this is a new VCG for this purpose reference [ITU-T-G.7042] specifically states: "The GID providescall. LSPs would then be added to the receivercall until the number of members reaches the number specified in the VCAT TLV. Note that any other bandwidth modifications to the VCG whether up or down will require a new VCAT call message with an appropriately modified TLV reflecting the new number of members. 4.5.2. Setting up a meansVCAT call + LSPs with no VCG To provide for pre-establishment of verifying that allthe arriving members originated fromserver layer connections for a VCG one transmitter. The contents are pseudo- random,can establish a VCAT call without an associated VCG. In addition, to provide for member sharing a pool of calls with connections can be established, then one or more of these calls (with accompanying connections) can be associated with a particular VCG (via the VCG ID). Note that multiple calls can be associated with a single VCG but that no call contains members used in more than one VCG. To establish a VCAT call with no VCG association when one sets up a new VCAT call in the receiverVCAT TLV one sets Action = 0 indicating that this is not requireda VCAT call without an associated VCG. LSPs can then be added to synchronize withthe incoming stream." Incall. The number of members parameter in the following we sketchVCAT TLV has no meaning at this point since it reflects the outlineintended number of suchmembers in a high levelVCG layer signaling procedure that could make use of the Notify message asand not in reference [RFC4974]. Aftera call. A call will know via the containment hierarchy about its associated data plane LSPs. However, the signal type does matter since signal types can never be mixed in a VCG and hence a VCAT call has been established,should only contain one signal type. 4.5.3. Associating an existing VCAT call with a signaling endpoint of theVCG Given a VCAT call for would then: 1. Choosewithout an identifier for eachassociated VCG such as that will use member signals fromset up in section 4.5.2. one associates it with a VCG as follows. In the common pool. Note that these identifiers only need to be uniqueVCAT call a new notify message is sent with ina CALL_DATA object with a VCAT TLV with Action = 1, a VCG ID, and the contextcorrect number of theVCG Call. 2. Assign member signals frommembers specified based on adding all of the common poolcalls data plane LSPs to each ofthe VCG utilizingas members. Note that the previously defined VCG IDs. Member signals are identifiedtotal number of VCGs supported by their tunnel id, LSP id,a piece of equipment may be limited and label ordinal (labels for control plane LSPshence on reception of any message with multiple members are strictly ordered so we can specifya change of VCG ID this limit should be checked. Likewise the sender of a message with a change in VCG ID should be prepared to receive an individual signal from its label order). Similarly forerror response. To take a particular VCG out of service, rather than just removing all its member, a member signal fromspecial flag element is included. 4.5.4. Removing the association between a VCGcall and returning it toVCG To reuse the common pool. 3. Coordinate with LCASserver layer connections in thata member signal iscall in another VCG one first addedneeds to a VCG fromremove the pool before LCAS is notified to "activate" that signal incurrent association between the call and a VCG. Similarly LCASTo do this, in the VCAT call a new notify message is notified to "deactivate"sent with a CALL_DATA object with a VCAT TLV with Action = 3, a member signal prior to removing it from theVCG ID, and returning it tothe pool. 4. Note that before any LSPs orcorrect number of VCG members specified based on removing all of an LSP can be removedthe calls data plane LSPs from the (overall)VCG Call,as members. When the originator must ensure that signals haveassociation between a VCG and all existing calls has been removed from any of the VCGs. This is the situation wherethen the entire pool sizeVCG is lowered. The exact objectsconsidered torn down. 5. Error Conditions and formats to carry this information is to be determined. Once again the Notify mechanism wouldCodes VCAT Call and member LSP setup can be appropriate since thisdenied for various reasons. Below is information toa list of error conditions that can be transferred between theencountered during these procedures. These fall under RSVP error code TBD. These can occur when setting up a VCAT call or associating a VCG Call endpoints and iswith a VCAT call. Error Subcode ------------------------------------ -------- VCG signal type not relevant to the intermediate switches. 5.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 6. IANA Considerations This document requests from IANA the assignment of ... (Don't know yet whata new RSVP-TE Object for CALL_DATA and a C-Type within that class for a VCAT call. Within this VCAT C-Type are a set of code points for permissible signal types. In addition, we may want) 6.request a new RSVP error code for use with VCAT call and define a number of corresponding error sub-codes. 7. 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 there 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. 7.8. Contributors Wataru Imajuku (NTT) 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 Japan Phone +81-46-859-4315 Email: email@example.com Julien Meuric France Telecom 2, avenue Pierre Marzin 22307 Lannion Cedex France Phone: + 33 2 96 05 28 28 Email: firstname.lastname@example.org Lyndon Ong Ciena PO Box 308 Cupertino, CA 95015 United States of America Phone: +1 408 705 2978 Email: email@example.com 8.9. 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. 9.10. References 220.127.116.11. Normative References [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. 18.104.22.168. 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. [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.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 Bernstein Grotto Networking Phone: +1-510-573-2237 Email: firstname.lastname@example.org 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 Email: email@example.com Huub van Helvoort Huawei Technologies, Ltd. Kolkgriend 38, 1356 BC Almere The Netherlands Phone: +31 36 5315076 Email: firstname.lastname@example.org Intellectual Property Statement The IETF 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 this 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. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR 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 this standard. Please address the information to the IETF at email@example.com. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007).(2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.