Network Working Group W. Imajuku,
Ed., NTTEd. Internet-Draft Otani, Ed., KDDINTT Com Intended status: Informational T. Otani, Ed. Expires: December 14, 2009 KDDI N. Bitar, Ed.,Ed. Verizon Expires:June 13,12, 2009 December 10, 2008Service Provider Requirements for Ethernet control with GMPLS draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txtdraft-ietf-ccamp-ethernet-gmpls-provider-reqs-02.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 sheThis Internet-Draft is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF in accordancefull conformance with Section 6the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 13,December 14, 2009. Abstract Generalized Multi-Protocol Label Switching (GMPLS) is applicable to Ethernet switches supporting Provider Backbone Bridge Traffic Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label switch network not only automates creation of Ethernet Label Switched Paths(Eth-LSPs), it 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 Ethernet label switch networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Reference model . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Single Layer . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Multi Layer . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Control plane architecture and functionality . . . . . . . 7 4.1.1. In-band control channel . . . . . . . . . . . . . . . 7 4.1.2. Neighbor discovery mechanism . . . . . . . . . . . . . 7 4.1.3. Addressing . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Ethernet LSP control . . . . . . . . . . . . . . . . . . . 7 4.2.1. Prevention of Loops . . . . . . . . . . . . . . . . . 7 4.2.2. Service control . . . . . . . . . . . . . . . . . . . 7 4.2.3. P2MP and MP2MP requirements . . . . . . . . . . . . . 8 4.2.4. Asymmetric bandwidth . . . . . . . . . . . . . . . . . 8 4.2.5. QoS control . . . . . . . . . . . . . . . . . . . . . 8 4.3. OA&M related functionality . . . . . . . . . . . . . . . . 89 4.4. Protection and Restoration related functionality . . . . . 89 4.5. Link Aggregation Group (LAG) related functionality . . . . 9 4.5.1. Failure or deletion of LAG member link . . . . . . . . 9 4.5.2. Recovery or addition of LAG member link . . . . . . . 9 4.6. Inter-domain Ethernet LSP . . . . . . . . . . . . . . . . 9 4.7. Multi-layer network . . . . . . . . . . . . . . . . . . . 10 4.7.1. Dynamic formation of LAG . . . . . . . . . . . . . . . 10 4.7.2. Other requirements . . . . . . . . . . . . . . . . . . 10 4.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . 1011 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19 1. Introduction Scalability and manageability of Ethernet switch networks has continuously improved, and the deployment of Ethernet switches supporting Provider Bridging (PB) [IEEE802.1ad] has became one of the solutions for service providers to provide enterprise WAN/LAN services. IEEE standardization activities of Provider Backbone Bridge(PBB) [IEEE802.1ah] and PBB for Traffic Engineering (PBB-TE) [IEEE802.1Qay] provide an opportunity not only for enhancing the scalability, manageability, and controllability of the Ethernet service networks, but also for more efficiently deploying access/ metro access networks. Generalized Multi-Protocol Label Switching (GMPLS) provides the framework for handling and controlling various types of connection- oriented switching technologies, namely packet switching with various label formats TDM switching, and wavelength switching [RFC3945]. Therefore, the combined use of GMPLS and PBB-TE is a fairly suitable "use case" that contributes to enhancing the flexibility of Ethernet Label Switched Path (Eth-LSP) over Ethernet switch networks without defining additional connection layers. This document describes requirements for GMPLS protocols to control Ethernet label switch networks and 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 extensions to support multi-layer operation. Although a large portion of requirements in the second scope coincides with the description in [RFC5145] and [RFC5146], some of important requirements are also described in 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 [RFC2119]. 3. Reference model 3.1. Single Layer This document describes requirements based on the reference model depicted in Fig.1. The first reference model is an intra-domain and single layer GMPLS controlled Ethernet label switching network in which Eth-LSPs traverse over between Back BoneBackbone Core Bridges (BCBs) or Back BoneBackbone Edge Bridges (BEBs). -------- | LSR3 |__ P-based IF ------------- _____|(IB-BEB)|__ S-tagged IF-------- P-based IF |--| LSR1 |____|LSR2 | | |__ I-tagged|_____| LSR3 |-- P-based IF S-tagged IF |(IB-BEB)|--|(IB-BEB)| |(BCB)| --------|(IB-BEB)|-- S-tagged IF I-tagged IF --| | | | |_____ -------- -------- ----- | LSR4 | | (B-BEB)|| |__|-- I-tagged IF -------- ----- -------- | GMPLS Eth-LSP | | (BVID/BMAC) | |<---------------||<-------------->| Figure 1 Single layer GMPLS controlled PBB-TE network The BEBs provide mainly three types of service interfaces, namely Port based service interface (P-based IF), S-tagged service interface (S-tagged IF), and I-tagged service Interface (I-tagged IF) [IEEE802.1ah]. The "P-based IF" and "S-tagged IF" are connected to the I-component of a BEB (I-BEB), while the I-tagged IF is connected to the B-component of a BEB (B-BEB). "S-tagged IF" can perform various types of mapping between Service VLAN ID (S-VID) and Backbone instance Service Identifier (I-SID). Here, S-VID is assigned within customer network domain or Provider Bridge (PB) domain. On the other hand, I-SID is defined between I-components of BEBs. 3.2. Multi Layer The second reference model is Ethernet and L1 (such as TDM, OTN, etc) multi-layer network. Each Ethernet switch node behaves as a border node between the Ethernet layer and optical Layers. Each BCB or BEB terminates Optical Label Switched Path (O-LSPs) with Ethernet encoding type and some O-LSPs dynamically form LAG. Thus, some Eth- LSPs traverse over multiple O-LSPs, while other Eth-LSPs traverse over single O-LSPs. Also, it is technically possible to form multiple layer Ethernet switch networks. Namely, the reference model is defined as the case that Ethernet switch network substitutes L1 network in Fig.2, and realizes MAC in MAC Ethernet transport. The routing information of optical layer may be isolated (overlay model), shuffled (peer model), or virtualized with FA-LSPs (augmented model) for Ethernet switch layer. -------- ------ -------- P-based IF __|--| LSR1 | | LSR2 | | LSR3 |__|-- P-based IF S-tagged IF __|(IB-BEB)|--|(IB-BEB)| | (BCB)| |(IB-BEB)|__|(IB-BEB)|-- S-tagged IF I-tagged IF __|--| | | | | |__|-- I-tagged IF -------- ------ -------- | | ||LAG LAG|| ..................|...........|..||..........||................... | | || || ---+---- ------ ------ | LSR A |_____|LSR B |_____|LSR C | | (LSC) | |(LSC) | WDM |(LSC) | -------- ------ ------ | GMPLS Eth-LSP (BVID/BMAC)| |<------------------------>| | O-LSP | | O-LSP | |<--------->| |<-------->| Figure 2 Multi-layer GMPLS controlled Ethernet label switched network 4. Requirements Section 4.1 to 4.6 describe requirements for single layer Ethernet label swicth network based on the reference model from Fig.1. In addition, section 4.7 describes requirements for multiple layer network with Ethernet layer and circuit switch layer (such as wavelength switched layer and so on). Finally, section 4.8 describes generic requirements applicable to single and multiple layer networks. 4.1. Control plane architecture and functionality 4.1.1. In-band control channel The solution should be able to establish in-band control channel, while preserving the solution of out-band control channel. The solution should include negotiation mechanism to specify bandwidth and priority of control-channel between peer Ethernet switches. 4.1.2. Neighbor discovery mechanism The solution MUST be able to realize automatic neighbor discoverdiscovery as realized in current PB or PBB networks. Namely, the solution MUST support an 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.channel for these configuration between neighbors. On the other hand, the extension should be minimized by making use of [RFC4394] and [IEEE802.1AB]. 4.1.3. Addressing TBDAll service interfaces, TE-Link IDs and Data-link IDs MUST be able to be indicated by standard IEEE MAC address format, but Node ID should be with IP addresses. 4.2. Ethernet LSP control 4.2.1. Prevention of Loops The solution should have reliability to prevent creating loops of Eth-LSPs. Specifically if the solution supports numbered TE-Link addressing, the solution should define a methodology and protocol extensions if needed to detect or prevent loops. 4.2.2. Service control The solution should control various types of service interfaces defined in [IEEE802.1ah]. The service types of Egress port 1) Port based service interface 2) S-tagged service interface a) one-to-one mapping of S-VIDs to I-SIDs b) bundled mapping of S-VIDs to I-SIDs such as many-to-one, all-to- one, transparent mapping 3) I-tagged service interface should be controllable in addition to assignment of Egress port itself. Also, the solution should be flexible to following operational scenarios, 1) Any change of mapping of S-VIDs to I-SIDs 2) Flexibility to nest or stitch higher layer Eth-LSPs. 3) Any change of bandwidth of Eth-LSPs. Here, the solution of bandwidth modification scenario may include bundling of multiple Eth- LSPs. 4.2.3. P2MP and MP2MP requirements To provide the service such as a content distribution, the creation of uni-directional P2MP Eth-LSPs should be supported. Also, to provide E-tree type services with multicast traffic, the creation of bi-directional P2MP/MP2PP2MP Eth-LSPs should be supported. The MP2MP requirement is under discussion.for further study. 4.2.4. Asymmetric bandwidth To provide the service which has asymmetric traffic pattern such as a kind of E-tree type services, the creation of asymmetric bandwidth bi-directional Eth-LSPs should be supported. The bandwidth modification of Eth-LSPs in operation should be also supported. 4.2.5. QoS control The routing and signaling extensions to control QoS based on Ethernet traffic parameters defined in [MEF10.1] should be supported. Unused bandwidth per CoS should be exhanged by routing extensions like [RFC4124] and the CoS and bandwidth profile such as CIR, CBS, EIR and EBS for a requested LSP should be carried by signaling extensions for bandwidth accounting and traffic control at a local level. 4.3. OA&M related functionality OAM mechanisms must be defined for GMPLS controlled E-LSPs. Since the data plane is still Ethernet based, the mechanisms should capitalize on existing [IEEE802.1ag] and [Y.1731] mechanisms. Also, the solution should provide admin status control mechanism to coordinate with Connectivity Fault Management (CFM) functionality [IEEE802.1ag]. 4.4. Protection and Restoration related functionality 1:1 protection, Shared protection and dynamic restoration should be supported. Protection and Restoration may be triggered by Ethernet OA&M function such as CC, AIS and RDI [IEEE802.1ag] , [Y.1731]. 4.5. Link Aggregation Group (LAG) related functionality Link Aggregation is beneficial functionality to realize flexible reconfiguration of logical link bandwidth and reliable Ethernet label switched networks. The availability of connectionlink bandwidth between peer Ethernet switches can be enhanced in the case of single link failure, if member links of the LAG are diversely routed. In this operational scenario, LAG provides for link protection functionality.enhanced. The solution should include methodologysupport Link Bundling mechanism described in [RFC4201] to explicitly assign the links forming LAG a desired link type (which is similar sense to assign link protection type described in [RFC3471]).LAG. 4.5.1. Failure or deletion of LAG member link The solution should include functionality to prioritize Eth-LSPs, specifically when total bandwidth of Eth-LSPs exceeds total bandwidth of healthy LAG members after the failure of one or more LAG member links. The solution should provide for rerouting an Eth-LSP setup over a failed member link in a LAG to another member link in the LAG. 4.5.2. Recovery or addition of LAG member link The solution should include functionality to re-optimize Eth-LSP paths after the addition of a LAG member link, i.e. reversion of failed Eth-LSPs after the failure of the LAG member link, or reallocation of other Eth-LSPs traversing congested Links after the addition of LAG member link. 4.6. Inter-domain Ethernet LSP The solution should take into account possible future extension to control inter-domain Eth-LSPs. Here, the possible extensions are Eth-LSPs traverse over 1) I-tagged service interfaces 2) S-tagged service interfaces, and 3) C-tagged service interfaces. 4.7. Multi-layer network 4.7.1. Dynamic formation of LAG The solution should include dynamic formation of a LAG after the creation or deletion of optical LSPs which interconnect ports of Ethernet switches. It should use the existing Link Bundling mechanism to assign bandwidth to dynamically formulated LAG. 4.7.2. Other requirements The architecture and requirements for MPLS-GMPLS inter-working are described in [RFC5145] and [RFC5146]. Some of the requirements described in [RFC5146] are valid even for the case of GMPLS-GMPLS interworking between Ethernet label switched network and L1 network. In other words, 1) End-to-End signaling of Eth-LSPs 2) Triggered establishment of L1 LSPs 3) Avoiding complexity and risks. should be satisfied even for GMPLS control plane for Ethernet. For more details, see [Interwk-req][RFC5146] and MPLS-TE client network written in the document should be understood as Ethernet client network. Regarding to routing issue, 1) Advertisement of Ethernet label switch network information via L1 GMPLS networks 2) Selective Advertisement of Ethernet label switched network information via a Border node should be satisfied even in the case of GMPLS-GMPLS inter-working. Note that there is significant difference between MPLS-TE and GMPLS controlled Ethernet from the view point of methodology to create control channel. 4.8. Scalability The solution MUST be designed to scale according to following metrics. - Number of nodes - Number of TE-Links - Number of LSPs - Number of service ports - Number of bundled S-VLANs mapped to I-SID and Eth-LSPs.Eth-LSPs - Number of advertised VLANs - Number of MEPs and MIPs. 5. Security Considerations The extension for GMPLS controlled Ethernet label switching should be considered under the same security as current work. This extension will not change the underlying security issues. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements The authors would like to thank Mr. Allan McGuire, Mr. Jullien Meuric, Mr. Lou Berger andBerger, Mr. Don Fedyk and Mr. Attila Takacs for their valuable comments. 8. References 8.1. Normative References [IEEE802.1AB] IEEE"IEEE Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity DiscoveryDiscovery". [IEEE802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic Engineering", work in progress.progress.". [IEEE802.1ad] IEEE"IEEE Computer Society, "Virtual Bridged Local Area Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0, Draft, Work in Progress.Progress". [IEEE802.1ag] IEEE"IEEE Computer Society, "Virtual Bridged Local Area Networks - Amendment 5 : Connectivity Fault Management", P802.1ag/D5.2, Draft, Work in Progress.Progress". [IEEE802.1ah] "IEEE standard for Provider Backbone Bridges", work in progress.progress.". [IEEE802.3] IEEE"IEEE Computer Society, "Amendment to Carrier Sense Multiple Access with Collision Detection (CAMS/CD) Access Method and Physical Layer Specifications.Specifications". [MEF10.1] MEF,"MEF, "Ethernet Services Attributes Phase2(MEF10.1)," http ://www.metroethernetforum.org/PDF_Documents/MEF10-1.pdf, Nov. 2006.2006.". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [Y.1731] "ITU-T Y.1731". 8.2. Informative References [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., and D. Papadimitriou, "A Transport Network View of the Link Management Protocol (LMP)", RFC 4394, February 2006. [RFC5145] Shiomoto, K., "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March 2008. [RFC5146] Kumaki, K., "Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks", RFC 5146, March 2008. Authors' Addresses Wataru Imajuku (editor) NTT Network Innovation Labs 1-1 Hikari-no-oka Yokosuka, KanagawaCommunications Corporation 1-1-6 Uchisaiwai-cho Chiyoda-ku, Tokyo Japan Phone: +81-(46) 859-4315 Email: firstname.lastname@example.org Yoshiaki Sone NTT Network Innovation Labs 1-1 Hikari-no-oka Yokosuka, Kanagawa Japan Phone: +81-(46) 859-2456 Email: email@example.com Muneyoshi Suzuki NTT Access Service System Labs 1-6 Nakase Mihama-ku, Chiba Japan Phone: (43) 211-8282 Email: firstname.lastname@example.org Kazuhiro Matsuda NTT Network Innovation Labs 1-1 Hikari-no-oka Yokosuka, Kanagawa Japan Phone: (46) 859-3177 Email: email@example.com Tomohiro Otani (editor) KDDI Corporation 2-3-2 Nishi-shinjukuOharaNishi-shinjuku Shinjuku-ku, Tokyo 163-8003 Japan Phone: +81-(3) 3347-6006 Email: firstname.lastname@example.org Kenichi Ogaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka, Saitama 356-8502 Japan Phone: +81-(49) 278-7897 Email: email@example.com Nabil Bitar (editor) Verizon 40 Sylvan Road Waltham, MA 02451 USA Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The(c) 2009 IETF Trust (2008).and the persons identified as the document authors. All rights reserved. This document is subject to the rights, licenses and restrictions contained inBCP 78,78 and except as set forth therein,the authors retain all their rights. ThisIETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. All IETF Documents and the information contained hereintherein 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 HEREINTHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this documentany IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.Copies of IPRIntellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.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.any standard or specification contained in an IETF Document. Please address the information to the IETF at email@example.com. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution.