CCAMP Working Group G. Bernstein Internet Draft Grotto Networking Updates: RFC 3946 D. Caviglia Category: Standards Track Ericsson Expires: April 2007 R. Rabbat (ed.) Fujitsu H. van Helvoort Huawei October 20, 2006 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) draft-ietf-ccamp-gmpls-vcat-lcas-01.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 April 20, 2007. Abstract This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction Bernstein Expires April 20, 2007 [Page 1] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 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 the 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. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-03..........3 3. VCAT/LCAS Scenarios and Specific Requirements..................3 3.1. Multiple VCAT Groups per GMPLS Endpoint...................3 3.2. Component Signal Configuration Requirements...............3 3.3. VCAT Operation With or Without LCAS.......................4 4. GMPLS Mechanisms for Signaling VCAT/LCAS.......................4 4.1. Co-Routed Signals.........................................5 4.1.1. One-shot Setup of Co-Routed Signal...................5 4.1.2. Incremental Setup of Co-Routed Signal................5 4.1.3. Removing a Component Signal..........................6 4.1.4. Removing Multiple Component Signals in One Shot......6 4.1.5. Use of multiple LSPs for Co-Routed Signals...........7 4.1.6. Teardown of Whole VCG................................7 4.2. Diversely Routed Signals..................................7 4.2.1. Associating Diversely Routed Signals.................7 4.2.2. Procedures for VCG Setup Using Diversely Routed Components..................................................8 4.2.3. Procedures for VCG Reduction/Teardown Using Diversely Routed Components...........................................9 4.2.4. Update of Already Established LSPs...................9 4.2.5. One LSP per Circuit..................................9 5. IANA Considerations...........................................10 6. Security Considerations.......................................10 7. Contributors..................................................11 8. Acknowledgments...............................................11 9. References....................................................12 9.1. Normative References.....................................12 9.2. Informative References...................................12 Author's Addresses...............................................13 Bernstein Expires April 20, 2007 [Page 2] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................14 Copyright Statement..............................................14 Acknowledgment...................................................15 1. Introduction The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols allows the automated control of different switching technologies including SONET/SDH. This document describes extensions to RSVP-TE to support the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS). These extensions enable the setup of diversely routed circuits that are members of the same VCAT group. 2. 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. Multiple VCAT Groups per GMPLS Endpoint 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. Component Signal Configuration Requirements We list in this section the different scenarios that SHOULD be supported. 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. Bernstein Expires April 20, 2007 [Page 3] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 Note that LCAS-capable interfaces can support all scenarios with no loss of traffic. 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 and 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 (no unique route has the required bandwidth). 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. 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. 4. GMPLS Mechanisms for Signaling VCAT/LCAS We describe in this section the signaling mechanisms that already exist in GMPLS using RSVP-TE [RFC3473] and the extensions needed, for diversely routed paths and in support of the LCAS procedure. Section 4.1 is included for informational purposes only. It describes existing procedures and makes no changes. Bernstein Expires April 20, 2007 [Page 4] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 Section 4.2 describes new procedures to support diversely routed VCAT groups. Where possible it reuses applicable existing procedures from section 4.1. 4.1. Co-Routed Signals Note that this section is for informational purposes only. The existing signaling protocols support co-routed signal setup using the NVC field as explained in section 2.1 of [RFC4606]. In this case, one single LSP is set up in support of the VCAT group. There are two options for setting up the VCAT group, 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 Setup of Co-Routed Signal 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 Setup of Co-Routed Signal 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. Bernstein Expires April 20, 2007 [Page 5] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 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 Component Signal 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 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 Component Signals 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 Bernstein Expires April 20, 2007 [Page 6] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 VCAT-only interfaces without management intervention as removing one or more components of the VCG will tear down the whole group. 4.1.5. Use of multiple LSPs for Co-Routed Signals Co-routed signals may also be supported by distinct LSPs signaled separately using exactly the techniques described for diversely routed signals in Section 4.2. 4.1.6. 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. Diversely Routed Signals 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). Diverse routing of signals can be a useful capability but requires the extensions identified in this document. 4.2.1. Associating Diversely Routed Signals The feature that needs to be added is the functionality to associate the components of the same VCG. For this purpose, we use the Association Object that was defined in [E2E-RECOVERY] to associate working and recovery LSPs. A diversely routed VCG uses a number of routes R <= VCG size, as some routes may be the same for several components. A number of LSPs, L (VCG >= L >= R) are used with each LSP establishing at least one component of the VCG, and at most all of the co-routed members of the group. For a set of c components using the same route, we set up the LSP with NVC = c exactly as explained in section 4.1.1. Therefore, Bernstein Expires April 20, 2007 [Page 7] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 the association of group members or of sub-groups to form the VCG requires the association of the LSPs used to establish the group members. To be able to distinguish the LSPs in the VCG each must have a unique identifier. LSPs are identified by the combination of Session and Sender Template fields. It is common practice when make-before-break [RFC3209] is supported to allow LSPs with the same Session, but different Sender Templates (specifically with different LSP IDs) to share resources. Since resource sharing between VCG members must not be allowed (because we want each LSP to contribute capacity to the VCG), but since we want to continue to support make-before-break for each group member, it is necessary to distinguish the LSPs in the VCG by varying the fields in the Session object. Specifically, a different Tunnel ID is used to identify each LSP in the VCG. Thus, VCG members cannot be associated through the Session object, and the Association object is used instead. The assignment of the Association ID is outside the scope of GMPLS but MUST be unique for each VCAT group. Note that the use of the Association object to associate members of a VCG does not preclude the use of another instance of the object with a different Association ID to indicate the association of working and recovery LSPs, as [E2E-RECOVERY] allows the use of multiple Association objects. We differentiate between the Association objects used for the VCAT group and other Association objects through the definition of a new association type to indicate that this is a VCG association. Association Type: 16 bits Value Type ----- ---- 3 VCAT group See [E2E-RECOVERY] for the definition of other fields and values of the Association object. 4.2.2. Procedures for VCG Setup Using Diversely Routed Components For every route R, use the procedure outlined in section 4.1.1 or 4.1.2 depending on the capability of the equipment or local policy. The Path message MUST include the Association object with type set to 3, and each Path message MUST use the same Association ID. Bernstein Expires April 20, 2007 [Page 8] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 Following the addition of each new LSP (i.e., once the RESV message has been received by the ingress LSR), LCAS signaling is used in-band to hitlessly add the new label into the existing group [ITU-T- G.7042]. 4.2.3. Procedures for VCG Reduction/Teardown Using Diversely Routed Components To remove the component circuits on any route, LCAS in-band signaling is used to remove the labels associated with the LSP from the group. LCAS signaling is defined in [ITU-T-G.7042]. In addition, the procedures outlined in section 4.1.3 or 4.1.4 are used to tear down the unwanted LSP. Again, this can only be done on LCAS-capable interfaces. If the procedure is attempted on VCAT-only interfaces, then the whole VCG is torn down (this is not a graceful teardown so ingress/egress initiate a Path Tear/Resv Tear) on all routes. 4.2.4. Update of Already Established LSPs Established co-routed VCAT groups currently do not support the Association object. If a co-routed VCAT Group size is to be increased with new diversely routed members, we use the LSP modification procedure described in [RFC2205]. An Association object is added to the Path message for the existing LSP(s). That Association object can then be used to set up new diversely routed group members. The same applies to SONET/SDH LSPs. An operator may decide to use an already cross-connected SONET/SDH LSP for diversely-routed VCAT. In this case the modification procedure described in [RFC2205] is used as well. 4.2.5. One LSP per Circuit These procedures can support the use of as many LSPs as there are circuits in the VCG. This can be done when each circuit is separately routed, or when some of the circuits are co-routed, and each LSP will be used to set up one element of the VCG. The Association object is used to indicate the VCG association. Bernstein Expires April 20, 2007 [Page 9] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 5. IANA Considerations This document requests from IANA the assignment of a new Association Type within the Association object. This object was defined in [E2E- RECOVERY]. The value 3 "VCAT group" is suggested in section 4.2.1. 6. Security Considerations This document introduces a new use of the Association object for GMPLS signaling [RFC3473] to associate diversely routed VCAT group members. It does not introduce any new signaling messages, nor change the relationship between LSRs that are adjacent in the control plane. This association information 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 network may be more robust. Otherwise, this document does not introduce any additional security considerations. Bernstein Expires April 20, 2007 [Page 10] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 7. 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 8. Acknowledgments The authors would like to thank Maarten Vissers, Trevor Wilson and Adrian Farrel for extensive reviews and contributions to this draft. Bernstein Expires April 20, 2007 [Page 11] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, December 2005. [E2E-RECOVERY] Lang, J.P., Rekhter, Y., and D. Papadimitriou (eds.), "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)- based Recovery", IETF draft, work in progress, April 2005. 9.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 April 20, 2007 [Page 12] Internet-Draft Operating VCAT and LCAS with GMPLS October 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: 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 Fujitsu Laboratories of America 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085 United States of America Phone: +1 408-530-4537 Email: richard@us.fujitsu.com Bernstein Expires April 20, 2007 [Page 13] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 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 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 ietf-ipr@ietf.org. 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 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 Internet Society (2006). Bernstein Expires April 20, 2007 [Page 14] Internet-Draft Operating VCAT and LCAS with GMPLS October 2006 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. Bernstein Expires April 20, 2007 [Page 15]