CCAMP Working Group W. Imajuku Internet-Draft Y. Tsukishima Expires: January 2006 NTT Y. H. Kim ETRI June 11, 2005 GMPLS extension requirements for virtual concatenation and link aggregation control 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 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 a "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 January 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This draft describes requirements of GMPLS extension to be supported in dynamic or static inter-working Generalized Multi-protocol Label Switching (GMPLS) protocol and multi-link technologies such as virtual concatenation (VCAT), link capacity adjustment scheme (LCAS) and link aggregation (LAGR). Conventions used in this document In this document the steps for walking a pull-down tree are indented on subsequent lines. This allows abbreviation rather than a barrage of 'then click' or 'select' strings in a paragraph form. Example: Imajuku, Tsukishima and Kim Expires - January 2006 1 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 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 Abstract 1. Introduction...................................................1 2. Need for VCAT & LCAS and LAGR & LACP Control Support in GMPLS..2 3. Problem Statement..............................................6 4. Requirements for GMPLS Extension...............................6 5. FA Considerations..............................................7 6. Security Considerations........................................9 7. IANA Considerations............................................9 8. Normative References...........................................9 9. Informative References........................................10 Author's Addresses...............................................10 Intellectual Property Statement..................................11 1. Introduction The Generalized Multi-Protocol Label Switching (GMPLS) control plane has been expected to unify the control scheme of networks with multiple switching capabilities and achieve fast provisioning and dynamic control of Label Switched Paths (LSPs). Dynamic LSP control includes not only protection and restoration, but also capacity control of the LSPs. As for the capacity control of the LSPs, fast control of the LSP capacity can enhance the degree of resiliency against unexpected traffic surges, which can be caused by a Label Switch Router (LSR) failure and so on, and enhance the capacity control of a higher order LSP such as the SDH/SONET from a lower- order LSP such as the Ethernet LSP. The combined usage of virtual concatenation (VCAT) [ITU-T G.707-SDH], [ITU-T G.707-SONET] and the link capacity adjustment scheme (LCAS) [ITU-T G.7042] provides dynamic capacity control of the LSP in the SDH/SONET network. The LCAS achieves hitless bandwidth modification via signaling in the H4 byte of the SDH/SONET link (Here, "hitless" means no packet loss). Analogous to the VCAT & LCAS in the SDH/SONET link, link aggregation (LAGR) and the link aggregation control protocol (LACP) [IEEE 802.3ad] can be applied to the capacity control of LSPs. Although the capacity for each packet flow cannot exceed the capacity of the component links, by using LAGR the total capacity of the LSP can exceed the limit of the interface speed. Typically, network management systems (NMSs) are required to manage the physical structure, i.e. bay, shelf, and slot, of each network Imajuku, Tsukishima and Kim Expires - January 2006 2 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 element (NE) to set the VCAT group or the LAGR group at each LSP termination point. The VCAT and LAGR technologies require manual setting to form the group LSP at both LSP termination points. This can be an obstacle in achieving autonomous control of the LSP capacity. This document describes the requirements for GMPLS support of VCAT & LCAS and LAGR & LACP control. First, this document clarifies the problems in applying GMPLS to the VCAT & LCAS and LAGR & LACP control. Then, this document describes the GMPLS extension requirements and considers the VCAT group and the LAGR group as forwarding adjacency (FA). The following abbreviations are used in this document: FA: Forwarding Adjacency GFP: Generic Framing Procedure GMPLS: Generalized Multi-Protocol Switching LACP: Link Aggregation Control Protocol LAGR: Link Aggregation LCAS: Link Capacity Adjustment Scheme LSP: Label Switched Path LSR: Label Switch Router PSC: Packet Switch Capable SDH: Synchronous digital hierarchy SONET: Synchronous optical network STS-N: Synchronous Transport Signal-Level N (SONET) VC: Virtual Container VC-n: Virtual Container-n (SDH) VCAT: Virtual Concatenation 2. Need for VCAT & LCAS and LAGR & LACP Control Support in GMPLS This section describes the need for GMPLS functionality to control VCAT & LCAS and LAGR & LACP. Figure 1 shows the assumed GMPLS network comprising the SDH/SONET switch capable nodes achieving STS-3n/VC-n LSP cross-connection and packet switch capable (PSC) nodes. The links amongst SDH/SONET nodes are SDH/SONET links. All of the PSC nodes are accommodated by the SDH/SONET nodes via multiple Ethernet links. The SDH/SONET nodes of T1, T3, and T4 in the SDH/SONET region have the Generic Framing Procedure (GFP), VCAT, and LCAS capabilities. In other words, these nodes cannot only terminate multiple component VC-n LSPs to form a VC-n LSP group, i.e., virtually concatenated VC-n-xv LSP, with the VCAT functionality, but also "hitlessly" change the component VC-n LSPs in the VC-n LSP group with the LCAS functionality. Therefore, these nodes can provide a "flexible bandwidth" to their clients. Imajuku, Tsukishima and Kim Expires - January 2006 3 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 The PSC nodes P1, P2, and P3 have the LAGR and LACP capabilities. Therefore, P1, P2, and P3 can establish an Ether-LSP with multi -link capacity. When the PSC nodes establish the LAGR group LSPs, the PSC nodes start to exchange LACP packets in the LSP. In this document, we call this LSP the LAGR group LSP. Although the capacity for each packet flow cannot exceed the capacity of the component LSPs, by using LAGR the total capacity of the LAGR group LSP can exceed the limit of the interface speed. PSC region #A | SDH/SONET region | PSC region #B | | +------+ GbE x2 +---------+ +---------+ | |P1,PSC|----------|T1,TDM-SC|-------|T2,TDM-SC| | | |----------|VCAT&LCAS| | | | +------+ | +---------+ +---------+ | | | | | | | | | | | | | | | | | +------+ GbE x2 +---------+ +---------+ GbE x2 +------+ |P2,PSC|----------|T3,TDM-SC|-------|T4,TDM-SC|----------|P3,PSC| | |----------|VCAT&LCAS| |VCAT&LCAS|----------| | +------+ | +---------+ +---------+ | +------+ Figure 1: SDH/SONET-SC and PSC interoperable network 2.1 Need for VCAT & LCAS control The creation and deletion of virtually concatenated LSPs such as VC-n-xv LSP are achieved under GMPLS control. GMPLS signaling can perform not only direct creation and deletion of a VC-n-xv LSP, but also the step-by-step creation and deletion of its component VC-n LSP to form the VC-n-xv LSP. The route of the component VC-n LSPs of the VC-n-xv LSP may be unique or node diverse. For example, the LSP group, i.e. the VC-4-7v LSP, between T1 and T4 may comprise seven component VC-4 LSPs with the route of T1, T2, and T4. In this case, the "bandwidth modification" of the VC-4-xv LSP may be achieved by modifying SUKLM LABEL and SDH/SONET SENDER TSPEC [RFC 3946] of the VC-4-xc LSP. Alternatively, the VC-4-7v LSP may comprise four component VC-4 LSPs with the route of T1, T2, and T4, and three component VC-4 LSPs with the route of T1, T3, and T4. The SDH/SONET nodes with the VCAT functionality absorb the differential delay amongst the component VC-4 LSPs. In this case, the "bandwidth modification" of the LSP group, i.e. the VC-4-7v LSP, is achieved by the "connection association modification" of the component VC-4 LSPs. The GMPLS signaling should include the group ID information clarifying to which VC-4-7v LSP the component VC-4 LSP belongs. Imajuku, Tsukishima and Kim Expires - January 2006 4 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 The LCAS signaling is utilized to reconfigure the VC-n-xv LSP without the loss of the client signal. The control packets of the LCAS signaling are proactively sent to inform the receiver of the changes in status at the transmitter using the H4 bite of the SDH/SONET superframe and to achieve dynamic reconfiguration of the LSP group. The control of the LCAS signaling is uni-directional. Therefore, both termination nodes of the VC-n-xv LSP should initiate the LCAS signaling by inter-working with the GMPLS signaling [GMPLS-LCAS]. The GMPLS signaling should be interoperable with LCAS signaling for both the "bandwidth modification" and the "connection association modification" cases. The success or failure of the LCAS signaling to add or delete the VC-n bandwidth should be reflected on the GMPLS control plane. This is especially important considering the "make- before-break" procedure [RFC3209]. Consider the case of "bandwidth modification" by creating a new session of the VC-n-xv LSP, the ingress node should recognize whether all of the component VC-n LSPs are successfully reconfigured to form a new VC-n-xv LSP. The ingress node should initiate a "break" with the old signaling session after that recognition. 2.2 The necessity of the LAGR&LACP control The creation and deletion of the LAGR group LSP such as a multi- gigabit Ether LSP can be achieved under GMPLS control. GMPLS signaling can perform not only direct creation and deletion of the LAGR group LSP, but also the step-by-step creation and deletion of its component Ether LSPs to form the LAGR group LSP. GMPLS signaling controls the "aggregators" at both LSP termination points. The aggregators collect or distribute packets amongst component LSPs so as to act as a single LSP for the client. The LACP is utilized in the component LSPs in order to synchronize the status of the "aggregator" at both LSP termination points. Different from the LCAS signaling, LACP does not have the remote control capability of a peer interface. The LACP simply provides notifies the aggregator of the group ID information for the component LSPs and other status information, which helps it to determine whether or not to attach or detach component LSPs. GMPLS signaling should include the group ID information to clarify to which LAGR group LSP the component LSP belongs. 2.3 Need for VCAT&LCAS and LAGR&LACP control in hierarchical case In a hierarchical network, the creation and deletion of the VC-n-xv LSP between T1 and T4 may be initiated by the creation of an Ether LSP between P1 and P4 with inter-domain TE signaling [INTER-DOMAIN- RSVP-TE]. In such a case, "bandwidth modification" and "connection Imajuku, Tsukishima and Kim Expires - January 2006 5 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 association modification" of the VC-n-xv LSP between T1 and T4 may be initiated by the signaling of the Ether LSP. The failure of the LCAS signaling between T1 and T4 should result in the issuing of an error notification from T1 to P1. 3. Problem Statement 3.1 Problem statement in routing aspect One of the advantageous features of VCAT focuses on the upgradeability from non-VCAT&LCAS nodes or networks. As shown in Fig.1, T2 only provides the switching and termination capabilities of VC-n LSP. In such a case, T1, T3, and T4 should confirm the VCAT & LCAS capability when calculating the route and termination points of the VC-n-xv LSPs. Therefore, each TDM node should advertise its VCAT and LCAS capabilities. Analogous to the VCAT & LCAS case, the PSC nodes should advertise the LAGR capability, if they want to discrimate the LAGR capability. 3.2 Problem statement in signaling aspect The LCAS signaling in the SDH/SONET data-plane is used for grouping uni-directional virtual containers. Therefore, both the ingress and egress nodes of the VC-n-xv LSP should initiate LCAS signaling as described in the previous section. In order for the egress node to set appropriately the component VC-n LSPs to form the VC-n-xv LSP, GMPLS signaling should provide the capability to signal the group ID for each component VC-n LSP. The above problem statement can be commonly applied to the control of the LAGR group LSPs. GMPLS signaling of component LSPs should include the group ID in order for the egress PSC nodes to set the LAGR group among Ethernet interfaces. Also, the LCAS signaling in an upstream path of VC-n-xv LSP is launched from the egress node. Therefore, the ingress node should have the capability to control LCAS signaling of the bandwidth modification or connection association modification from the egress node. The explicit control and the confirmation of success in LCAS signaling enhance the reliability of the "make-before-break" procedure. In particular, the tearing down of the component VC-n LSPs from the VC-n-xv LSP should be initiated after confirming successful decomposition of the component VC-n LSPs. 4. Requirements for GMPLS Extension The following extensions for the VCAT & LCAS and the LAGR & LACP support are introduced in this document. 4.1 Extension for Routing Protocol Imajuku, Tsukishima and Kim Expires - January 2006 6 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 The ingress node should identify the VCAT, LCAS, or LAGR capability of the egress node before the route calculation of the VC-n-xv LSP or the LAGR LSP (group LSP). Every node having the VCAT, LCAS, and LAGR capabilities are required to advertise the termination capability considering a mixed environment of non-VCAT and LCAS capable SDH/SONET nodes or non-LAGR PSC nodes. The VCAT and LCAS capable SDH/SONET nodes are required to advertise the interface switching capability descriptor [GMPLS-ROUTING] indicating VCAT capable TDM or VCAT & LCAS capable TDM. Similarly, the LAGR capable PSC nodes are required to advertise the interface switching capability descriptor indicating LAGR capable PSC. 4.2 Extension for Signaling Protocol 4.2.1 Support for Group ID The ingress node should include the group ID in the signaling of each component LSP intending to participate in a certain group LSP. The concepts of grouping and associating connections have been discussed in relation to automatically switched optical network (ASON) support [ASON-REQ] or protection and restoration support [E2E-RESTORATION], respectively. Therefore, support for the group ID may not require a new extension for signaling protocols rather the extension of existing protocols. This version of the document does not specify which objects should be in use. However, the following notes should be taken into consideration. Note1: ASON requires call and connection separation. The Call ID, the long format Call ID specified in [RFC3474] and short format Call ID proposed in [ASON-RSVP-TE], can be used as the group ID of the group LSP. The short format Call ID requires an extension in the SESSION Object. Therefore, the usage of the short format Call ID should be static. In other words, connection association modification cannot be achieved by simply modifying the short format Call ID. The connection association modification using the short format Call ID shall be on the "make-before-break" basis only. Note 2: Protection and restoration require that the ASSOCIATION object be associated with working and back-up connections. In addition, n back-up connections are associated to one working connection. For the VCAT & LCAS or the LAGR & LACP control, all of the n connections should be associated to one virtual connection, i.e. the group ID. 4.2.2 Support for Explicit Control of LCAS Signaling Imajuku, Tsukishima and Kim Expires - January 2006 7 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 The ingress nodes should include L bits in the SDH/SONET SENDER TSPEC object to initiate the LCAS signaling of the upstream path from the egress node. In addition, the egress node should include L bits in the SDH/SONET FLOWSPEC object as a successful response. 5. FA Considerations This section considers the case in which the group LSP is used for FA in the network. 5.1 Routing aspects This section considers the case in which the group LSP is used for FA in the network. The guideline for advertising the traffic engineering extension of the FA-LSP is described in [HIERARCHY]. In addition, the case in which FA is induced from the group LSP should be considered analogous to link bundling [LINK-BUNDLING]. (1) Maximum Bandwidth [RFC3630] This parameter is not used. The maximum LSP Bandwidth (as described below) replaces the Maximum Bandwidth for the FA of the group LSP. (2) Maximum LSP Bandwidth [GMPLS-ROUTING] The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. The Maximum LSP Bandwidth of the FA at priority p is defined to be the maximum of the Maximum LSP Bandwidth at priority p of all component LSPs. (3) Max Reservable Bandwidth [RFC3630] The FA advertisement of the group LSP is configured using the sum of the Maximum Reservable Bandwidths of all component LSPs associated with the group LSP or the FA advertisement of the group LSP is configured with the Maximum Reservable Bandwidth of the component LSPs. The case that should be employed may depend on the switching capability of the network. However, the FA advertisement of the VC- n-xv LSP in the PSC network may be the former case. On the other hand, the FA advertisement of the link aggregation LSPs in the PSC network may be the latter case. (4) Link Protection Type [GMPLS-ROUTING] The link protection type of the FA advertisement for the group LSP should be unprotected unless all of the component LSPs are protected. (5) Shared Risk Link Group (SRLG) [GMPLS-ROUTING] SRLG of the FA advertisement for the group LSP should include all of the SRLGs of the component LSPs. 5.2 Signaling aspects Imajuku, Tsukishima and Kim Expires - January 2006 8 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 If an LSR that originates a group LSP advertises this group LSP as an unnumbered FA, or the LSR uses the FA formed by this LSP as an unnumbered component LSP of a group LSP, the LSR MUST allocate an identifier to that FA. Moreover, the Path message used for establishing the LSP that forms the FA MUST contain the LSP TUNNEL_INTERFACE_ID object as described in [RFC3477]. Whether or not the component LSP of the group LSP should set the same LSP_TUNNEL_INTERFACE_ID depends on the policy of the LSRs at the ingress and egress nodes of the group LSP. Discussion on this policy is outside the scope of this document. However, the policy should be consistent with the advertisement of the Max Reservable Bandwidth. If the Max Reservable Bandwidth is the sum of the Maximum Reservable Bandwidths of all component LSPs associated with the group LSP, the component LSPs of the group LSP should be set to the same LSP_TUNNEL_INTERFACE_ID. Otherwise, the component LSPs of the group LSP should be set to a different LSP_TUNNEL_INTERFACE_ID. 6. Security consideration Security consideration will be discussed in a future version. This requirement will not change the underlying security issues. 7. IANA Considerations This document does not contain any IANA actions. 8. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [ITU-T G.707-SDH] International Telecommunications Union, "Network node interface for the synchronous digital hierarchy (SDH)", ITU-T Recommendation G.707, 2003. [ITU-T G.707-SONET] American National Standards Institute, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates, and Formats", 2001. [ITU-T G.7042] International Telecommunications Union, "Link Adjustment Scheme (LCAS) for virtual concatenated signals", ITU-T Recomendation G.7042, 2004. [IEEE802.3ad] "Information Technology I Local and Metropolitan Area Networks I Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Standard 802.3, March 2002. Imajuku, Tsukishima and Kim Expires - January 2006 9 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 [RFC3946] "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004. [RFC3209] Awduche D. et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels" RFC 3209, December 2001. [INTER-DOMAIN-RSVP-TE] Ayyangar A. et al, "Inter domain MPLS Traffic Engineering - RSVP-TE extensions", (work in progress). [GMPLS-ROUTING] Kompella K. et al., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", (work in progress). [ASON-REQ] Papadimitriou D. et al, "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", (work in progress). [E2E-RESTORATION] Lang J. P. et al "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery", (work in progress). [RFC3474] Lin Z. and Pendarakis D., "Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)" , (work in progress). [ASON-RSVP-TE] Drake J. et al, "Generalized MPLS (GMPLS) RSVP-TE Signaling in support of Automatically Switched Optical Network (ASON)", (work in progress). [HIERARCHY] Kompella K., "LSP Hierarchy with Generalized MPLS TE", (work in progress). [LINK-BUNDLING] Kompella K. et al., "Link Bundling in MPLS Traffic Engineering", (work in progress). [RFC3630] Katz D. et al., "Traffic Engineering (TE) Extensions to OSPF Version 2". [RFC3477] Kompella K. et al., "Signaling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. 9. Informative references [GMPLS-LCAS] Y. H. Kim et al, "Interaction between GMPLS RSVP-TE and LCAS", draft-kim-ccamp-interaction-grsvpte-lcas-01.txt Author's Addresses: Wataru Imajuku Imajuku, Tsukishima and Kim Expires - January 2006 10 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 NTT Network Innovation Laboratories 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 Japan Email: imajuku.wataru@lab.ntt.co.jp Yukio Tsukishima NTT Network Innovation Laboratories 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 Japan Email: tsukishima.yukio@lab.ntt.co.jp Young Hwa Kim ETRI 61 Gajeong-dong Yuseong-gu Daejeon 305-350 Korea E-mail: yhwkim@etri.re.kr 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 Imajuku, Tsukishima and Kim Expires - January 2006 11 draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005 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 (2004). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Imajuku, Tsukishima and Kim Expires - January 2006 12