Network working Group W. Imajuku, M. Suzuki, K. Matsuda, NTT Internet-Draft K. Ogaki, T. Otani KDDI R&D Labs. Category: Informational November 12 2007 Expires May 2008 Requirements for Ethernet control with GMPLS draft-imajuku-ccamp-ethernet-gmpls-req-00.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 May 12, 2008. Abstract Generalized Multi-Protocol Label Switching (GMPLS) is applicable to Ethernet switches supporting Provider Backbone Bridge Traffic Engineering (PBB-TE) networks. The GMPLS controlled PBB-TE network not only automates creation and deletion of Eth-LSPs, but also provides sophisticated Eth-LSP recovery mechanisms such as protection and restoration of an Eth-LSP. This document describes the requirements for the set of solutions of GMPLS controlled PBB-TE networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 Imajuku, et al. Expires January 2008 [Page 1] draft-imajuku-ccamp-ethernet-gmpls-req-00.txt November 2007 3. Reference model . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Single-layer network . . . . . . . . . . . . . . . . . . . 3 3.2. Multi-layer network . . . . . . . . . . . . . . . . . . . 3 4. Requirements for Ethernet layer control . . . . . . . . . . . 4 4.1. Neighbor discovery mechanism . . . . . . . . . . . . . . . 4 4.2. In-band control plane channel . . . . . . . . . . . . . . 4 4.3. Prevention of Loops . . . . . . . . . . . . . . . . . . . 5 4.4. Egress Port Control . . . . . . . . . . . . . . . . . . . 5 4.5. Link Aggregation Group related functionalities . . . . . . 5 4.6. Inter-domain Ethernet LSP . . . . . . . . . . . . . . . . 6 5. Requirements for multi-layer control . . . . . . . . . . . . . 6 5.1. Dynamic formation of LAG . . . . . . . . . . . . . . . . . 6 5.2. Other requirements . . . . . . . . . .. . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative references . . . . . . . . . . . . . . . . . . 6 8.2. Informative references . . . . . . . . . . . . . . . . . . 8 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Copyright Statement. . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Scalability and manageability of Ethernet switched networks has continuously enhanced and the deployment of these switches supporting Provider Bridge (PB) [IEEE802.1ad] has became one of the solutions to provide enterprise WAN/LAN services. IEEE standardization activities of Provider Backbone Bridge (PBB) [IEEE 802.1ah] and PBB for Traffic Engineering (PBB-TE) [IEEE802.1Qay] provides an opportunity not only for enhancing the scalability, manageability, and controllability of the Ethernet service networks, but also for deploying access/metro transport infrastructure. Generalized Multi-Protocol Label Switching (GMPLS) is the framework which handles various types of switches, namely packet switching, Layer 2 switching, TDM switching, wavelength switching, and fiber Switching [RFC3945]. Therefore, combinational usage of the GMPLS and PBB-TE is a fairly suitable ?guse case?h and contributes to enhance flexibility of Ethernet Label Switched Path (Eth-LSP) over PBB networks without defining additional connection layers. This document describes requirements for GMPLS protocols to control PBB-TE networks which comprises mainly two parts. The first one is the requirements for GMPLS extension for controlling Ethernet layer. The second one includes the requirements for GMPLS extension to support multi-layer operation. Although a large portion of requirements in the second scope coincides with the description in [Interwk-req] and [MLN], some of important requirements are also described in this document. Imajuku, et al. Expires January 2008 [Page 2] draft-imajuku-ccamp-ethernet-gmpls-req-00.txt November 2007 In this version of the document, requirements for GELS [CCAMP-ETHERNET] are under study and this may be provided in future version of this document. 2. 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]. 3. Reference model 3.1 Single Layer This document describes requirements based on the reference models depicted in Fig. 1. The first reference model is an intra-domain and single layer GMPLS controlled PBB-TE network in which Eth-LSPs traverse over I-NNI between Back Bone Core Bridges (BCBs) or Back Bone Edge Bridges with I-comonents and B-components (IB-BEB). BCB/BEBs may interconnected by multiple links forming Link Aggregation Group (LAG) [IEEE802.3]. ---- -------- ----- ----- -------- ---- | |_| LSR1 |____|LSR2 |_____|LSR3 |_____| LSR4 |__| | |(PB)| |(IB-BEB)| |(BCB)|_____|(BCB)|_____|(IB-BEB)| |(PB)| | | | | | |_____| | LAG | | | | ---- -------- ----- LAG ----- -------- ---- (Option) (Option) | Eth-LSP (SVID) (Option) |<------------------------------------------------------>| | GMPLS Eth-LSP (BVID/BMAC) | |<---------------------------------->| Figure 1 Single layer GMPLS controlled PBB-TE network 3.2 Multi-layer The third reference model is PBB-TE and L1 (such as TDM, OTN, etc) multi-layer network. Each PBB-TE node behaves as a border node between the PBB-TE layer and optical Layers. Each BCB or BEB terminates Ethernet Port Label Switched Path (Eth-P-LSPs) and some Eth-P-LSPs dynamically form LAG. Thus, some Eth-LSPs traverse over multiple Eth-P-LSPs, while other Eth-LSPs traverse over single Eth-P-LSPs. Also, it is technically possible to form multiple layer PBB-TE networks. Namely, the reference model is defined as the case that PBB-TE network substitutes L1 network in Fig.2, and realizes BMAC in BMAC Ethernet transport. Imajuku, et al. Expires January 2008 [Page 3] draft-imajuku-ccamp-ethernet-gmpls-req-00.txt November 2007 The routing information of optical layer may be isolated (overlay model), shuffled (peer model), or virtualized with FA- LSPs(augmented model) for PBB-TE layer. ---- -------- ------ ------ -------- ---- | |_| LSR1 | | LSR2 | | LSR3 | | LSR4 |__| | |(PB)| |(IB-BEB)| | (BCB)| | (BCB)| |(IB-BEB)| |(PB)| | | | | | | | | | | | | ---- ---+---- ------ ------ -------- ---- (Option) | LAG||| LAG||| ||LAG LAG|| (Option) ..............|...........|||.........|||.||.........|| | ||| ||| || || ---+---- ----- ------ -------- | LSR A |____|LSR B |_____|LSR C |_____| LSR D | | (LSC) | |(LSC) | WDM |(BCB) | WDM |(IB-BEB)| -------- ------ ------ -------- | GMPLS Eth-LSP (BVID/BMAC) | |<------------------------------------->| | O-LSP | | O-LSP | | O-LSP | |<---------->| |<-------->| |<--------->| Figure 2 Multiple layer GMPLS controlled PBB-TE network 4. Requirements for Ethernet layer control This section describes requirements for single layer PBB-TE network based on the reference model from Fig.1. 4.1 Neighbor discovery mechanism The solution MUST be able to realize automatic neighbor discovery as realized in current PB or PBB networks. Namely, the solution MUST support a automatic negotiation mechanism to exchange information of Node ID, TE-Link ID, Data-link ID (in the case of link Bundling), and IP address of the control channel. The solution MUST include specification of inter-operable test mechanisms specified for TDM networks in [RFC4207]. On the other hand, the extension should be minimized by making use of [IEEE 802.1AB]. 4.2 In-band control plane channel The solution should be able to establish in-band control channel. Solution should include negotiation mechanism to specify bandwidth of control-channel between peers. Considering the robustness and manageability of control-channel, the in-band control channel itself should be Eth-LSP with high- priority. Imajuku, et al. Expires January 2008 [Page 4] draft-imajuku-ccamp-ethernet-gmpls-req-00.txt November 2007 4.3 Prevention of Loops The solution MUST have reliability to prevent creating loops of Eth-LSPs. Specifically if the solution supports numbered TE-Link addressing, it is essential to specify some new extension or new methodology to detect or prevent a loop. 4.4 Egress Port Control The solution MUST have solution not only to assign Egress Port, but also discriminate port types whether the port should be I-component or B-component. 4.5 Link Aggregation Group (LAG) related functionality The solution should include functionality to coordinate with Link Aggregation Group (LAG). Solution should include operational scenarios described in following sections. 4.5.1 Failure or deletion of LAG member link The solution should include functionality to prioritize Eth-LSPs, when one or more LAG member links fails and total bandwidth of Eth-LSPs exceeds total bandwidth of healthy LAG members. The solution should also include notification of the functionality of Eth-LSPs whose traffic was discarded by high-priority Eth-LSPs. The solution should be able to provide an option for operators to take some actions such as switchover to back-up Eth-LSPs as specified in [G-8031]. 4.5.2 Failure of LAG member link of Destination MAC Specifically, the solution should include functionality to reallocate Labels of Eth-LSPs, when failed LAG member link is the source or destination of the Eth-LSPs. 4.5.3 Recovery or addition of LAG member link The solution should include functionality to prioritize Eth-LSPs, when one or more LAG member links fails and the total bandwidth of Eth-LSPs exceeds the total bandwidth of healthy LAG members. The solution should include notification functionality to indicate recovery of bandwidth following to the recovery of LAG member link. The solution should be able to provide option for operators to take some actions such as reversion to primary Eth-LSPs which are transmitted over . Imajuku, et al. Expires January 2008 [Page 5] draft-imajuku-ccamp-ethernet-gmpls-req-00.txt November 2007 4.6 Inter-domain Ethernet LSP The solution should include functionality to control inter-domain Eth-LSPs. Here, the solution should support Eth-LSP traverses over demarcation points faced with B-component interfaces. 5. Requirements for multilayer network This section describes requirements for a single layer PBB-TE network based on the reference model of Fig.2. 5.1 Dynamic formation of LAG The solution should include dynamic formation of LAG following to creation or deletion of Eth-P-LSPs. The solution should be similar to that of dynamic formation of virtually concatenated group (VCG) in SDH/SONET or OTN networks [VCAT&LCAS]. On the other hand, the solution should provide reliability not to misconfigure LAG as links forming a loop. 5.2 Other requirements The architecture and requirements for MPLS-GMPLS inter-working are described in [Interwk-fwk] and [Interwk-req]. Some of the requirements described in [Interwk-req] are valid even for the case of GMPLS-GMPLS interworking between PBB-TE and L1 network layers. Namely, 1) End-to-End signaling of Eth-LSPs 2) Triggered establishment of L1 LSPs 3) Advertisement of PBB-TE information via L1 GMPLS networks 4) Selective Advertisement of PBB-TE information via a Border node 5) Avoiding complexity and risks. For more details, see [Interwk-req] and MPLS-TE client network written in the document should be understood as PBB-TE client network. 6. Security considerations TBD 7. IANA considerations TBD 8. References 8.1 Normative References Imajuku, et al. Expires January 2008 [Page 6] draft-imajuku-ccamp-ethernet-gmpls-req-00.txt November 2007 [RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [IEEE802.1ad] IEEE Computer Society, "Virtual Bridged Local Area Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0, Draft, Work in Progress [IEEE802.1ah] "IEEE standard for Provider Backbone Bridges", work in progress. [IEEE802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic Engineering", work in progress. [Interwk-frw] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Brungard, D., Kumaki, K., Ali, Z., Oki, E., Inoue, I., Otani, T., "Framework for MPLS-TE to GMPLS migration", draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in progress. [Interwk-req] Kumaki, K., Otani, T., Okamoto, S., Fujihara, K., Ikejiri, Y., "Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks", draft-ietf- ccamp-gmpls-mln-reqs, work in progress. [MLN] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, M., Brungard, D., "Requirements for GMPLS-based multi- region and multi-layer networks (MRN/MLN)", draft-ietf- ccamp-gmpls-mln-reqs, work in progress. [IEEE802.3] IEEE Computer Society, "Amendment to Carrier Sense Multiple Access with Collision Detection (CAMS/CD) Access Method and Physical Layer Specifications ? Aggregation of Multiple Link Segements, " P802.3ad, March 2000. [IEEE802.1ag] IEEE Computer Society, "Virtual Bridged Local Area Networks - Amendment 5 : Connectivity Fault Management", P802.1ag/D5.2, Draft, Work in Progress [RFC4207] Lang, J., Papadimitrious, D., "Synchronous Optical (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages?g, RFC4207, Oct. 2005. [IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity Discovery". [G-8031] ITU-T Draft Recommendation G.8031, Ethernet Protection Switching. Imajuku, et al. Expires June 2008 [Page 7] draft-imajuku-ccamp-ethernet-gmpls-req-00.txt November 2007 [VCAT&LCAS] Bernstein, G., Caviglia, D., Rabbat, R., H. van Helvoort, "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi- Protocol Label Switching (GMPLS)", draft-ietf-ccamp-gmpls- vcat-lcas, work in progress. 8.2 Informative References [CCAMP-ETHERNET] Papadimitriou, D. et.al, "A Framework for Generalized MPLS (GMPLS) Ethernet", internet draft, draft- papadimitriou-ccamp-gmpls-ethernet-framework-00.txt, June 2005. 9. Authors' Addresses Wataru Imajuku NTT Network Innovation Labs 1-1 Hikari-no-oka, Yokosuka, Kanagawa Japan Phone: +81-(46) 859-4315 Email: imajuku.wataru@lab.ntt.co.jp Muneyoshi Suzuki NTT Access Service System Labs 1-6 Nakase, Mihama-ku, Chiba Japan Phone: +81-(43) 211-8282 Email: suzuki.muneyoshi@lab.ntt.co.jp Kazuhiro Matsuda NTT Network Innovation Labs 1-1 Hikari-no-oka, Yokosuka, Kanagawa Japan Phone: +81-(46) 859-3177 Email: matsuda.kazuhiro@lab.ntt.co.jp Kenichi Ogaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino-shi Saitama, 356-8502 Japan Phone: +81-49-278-7897 Email: ogaki@kddilabs.jp Imajuku, et al. Expires June 2008 [Page 8] draft-imajuku-ccamp-ethernet-gmpls-req-00.txt November 2007 Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino-shi Saitama, 356-8502 Japan Phone: +81-49-278-7357 Email: otani@kddilabs.jp 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. Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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. Imajuku, et al. Expires January 2008 [Page 9]