Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 Network Working Group Internet Draft Ping Pan Intended status: Standards Track (Hammerhead Systems) Expiration Date: December 2007 Shane Amante Nasser El-Aawar (Level-3) June 2007 Setup and Manage PBB-based Tunnels with PWE3 Mechanism draft-pan-pwe3-pbb-tunnel-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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a mechanism that enables providers to setup point-to-point tunnels over PBB networks for the purpose of aggregating customer flows. The interior network nodes will not be disturbed with this mechanism. [Page 1]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 Table of Contents 1. Specification of Requirements .................................2 2. Introduction ..................................................2 2.1. Assumptions ..............................................3 2.2. Perspectives .............................................3 3. Background ....................................................4 3.1. PWE3 .....................................................4 3.2. PBB ......................................................4 3.3. PBT ......................................................5 3.4. PBB-based Tunnels ........................................6 4. Operation Outline .............................................6 5. Protocol Extensions ...........................................8 5.1. Generalized ID FEC .......................................8 5.2. AII Type: PBB-based Tunnels ..............................8 5.3. Pseudowire Status ........................................9 5.4. OAM ......................................................9 6. Applications ..................................................9 6.1. Interconnection PBB Domains with PW MHOP .................9 6.2. Carrying multi-service traffic over PBB-based tunnels ....9 6.3. Interworking with PBT ....................................9 7. Intellectual Property Statement ..............................10 8. Full Copyright Statement .....................................10 9. IANA Considerations ..........................................10 10. Normative References .......................................10 11. Informative References .....................................11 12. Author Information .........................................11 1. Specification of Requirements 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. 2. Introduction With the proliferation of Ethernet deployment in metro and backbone networks, managing Ethernet connections becomes increasingly important. Despite the popularity of MPLS, many carriers continue to build-out Ethernet-only networks, where no MPLS switching takes place at data plane inside the network. To make the deployment scalable, the carriers have been deploying Q- in-Q [Q-in-Q] whereby each Ethernet frame can be encapsulated with multiple VLAN tags. [Page 2]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 As the metro network continues to expand, the carriers need to improve scalability beyond Q-in-Q VLAN tagging. PBB (Provider Backbone Bridges) [PBB], also known as MAC-in-MAC, is a technique that encapsulates Ethernet frames with another Ethernet MAC and VLAN header. It therefore increases Ethernet framing hierarchy at data- plane. Generally, the scaling improvement at data-plane needs to be coupled with the scalability at control-plane. One simple yet popular application is to aggregate VLAN-tagged flows from customer locations into point-to-point tunnels from PBB backbone edge. It requires the network operators to be able to dynamically provision, monitor and manage the PBB-based tunnels, as well as mapping of customer VLAN flows into PBB-based tunnels. PBT (Provide Bridge Transport) [PBT] has been proposed as the solution for the above application. However, PBT inherently has two shortcomings: First, the currently defined PBT proposal has no dynamic provisioning mechanism, and wont scale for large scale backbone with static configuration. Second, the currently defined PBT proposal requires the internal nodes to be programmed for tunnel setup. It is debatable if it will bring the justification for control-plane simplicity. In this document, we first define PBB-based tunnels, as the virtual tunnels between PBB edge nodes. We then propose of using the well- defined PWE3 protocols to setup and manage the PBB-based tunnels. The proposal does not require the changes on the internal nodes. 2.1. Assumptions Our proposal is based on the following assumptions: 1. The Ethernet metro/core network is relatively stable. The network will not experience frequent link and node failures, or subsequent long converging and looping problems introduced by STP. 2. Network providers will over-provision the network to overcome per- flow QoS issues. 2.2. Perspectives There should be little doubt on the effectiveness of MPLS/IP protocols in establishing data tunnels - point-to-point, and point- [Page 3]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 to-multi-point alike. In particular, PWE3 is a well-defined and widely deployed mechanism in setting up and managing edge-to-edge data connections. In particular, the PWE3 control-plane can operate over just about any type of networks. There should also be obvious that the carriers have incentive in deploying PBB (Provider Backbone Bridges, or, MAC-in-MAC) to expand their Ethernet-only networks. Inside the PBB networks, the carriers have the option of using spanning tree protocols to interconnect nodes. It should be noted that the MAC-in-MAC mechanism itself is a data-plane function. Hence, instead of operating the networks with either MPLS or PBB/PBT, we believe that an alternative is to deploy MPLS/PWE3 protocols at places where they fit (such as, network edge), while using PBB for simple and cheap Ethernet packet transport within the backbone. In our proposal, we define the protocol extension in using target LDP (PWE3) at network edge to exchange MAC-in-MAC and VLAN information between network edges. The backbone network itself will operate with PBB only. 3. Background In this section, we will outline some of the relevant technologies that we work with. 3.1. PWE3 PWE3 [RFC3985] is to create edge-to-edge connections between two edge nodes, and has been widely deployed to interconnect user traffic over the MPLS/IP backbone. It comes with a number of important features: VCCV [VCCV] provides an efficient OAM capability for PWs, and MHOP [MHOP] and PW switching [PW Switching] enable the PWE3 to be deployed over multiple networks. Further, Pseudo-wire itself is a very flexible concept, and can operate over any data network, including MPLS, TDM and Ethernet (a.k.a. dry-martini). 3.2. PBB PBB extends the Ethernet stacking as shown in Figure-1: +-------+ +-------+ +-------+ +---------+ | Data | | Data | | Data | | Data | +-------+ +-------+ +-------+ +---------+ |Src MAC| ---> | VID | ---> | C-VID | ---> | C-VID | +-------+ +-------+ +-------+ +---------+ [Page 4]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 |Dst MAC| |Src MAC| | S-VID | | S-VID | +-------+ +-------+ +-------+ +---------+ |Dst MAC| |Src MAC| |Src MAC | 802.1 +-------+ +-------+ +---------+ |Dst MAC| |Dst MAC | 802.1q +-------+ +---------+ | I-SID | VID = VLAN ID 802.1ad +---------+ C-VID = Customer VID | B-VID | S-VID = Service VID +---------+ I-SID = Service ID |B-Src MAC| B-VID = Backbone VID +---------+ B-Src MAC = Backbone Source MAC |B-Dst MAC| B-Dst MAC = Backbone Destination MAC +---------+ 802.1ah (PBB) Figure 1: A brief history of Ethernet Stacking As mentioned previously, Q-in-Q (or 802.1ad) has been widely deployed. PBB leads to a reasonable evolution for Ethernet backbone expansion. Since PBB is to encapsulate a new MAC header to each packet, the network intermediate nodes can be constructed with any out-of-shelf Ethernet switches and employee STP or other means for connectivity. In summary, if the carriers have already adapted native Ethernet services, the deployment of PBB should not introduce much overhead and cost. 3.3. PBT By definition, PBB offers a bridged network, where each node can communicate with other nodes simultaneously (a.k.a. any-to-any connectivity). This may not be a desirable behavior for some of the backbone applications. One important backbone application is to create point-to-point tunnels between edge nodes to aggregate user flows. PBT (Provider Bridge Transport) is designed to support point-to-point tunnels over PBB networks. Instead of using STP to interconnect edge nodes, PBT defines one or multiple B-VID bits in the PBB stack for the purpose of tunneling functionality. The intermediate nodes will not perform STP flooding on the frames that have the special B-VID bits. To setup the PBT tunnels, PBT requires all the intermediate nodes to manage the B-VID entries. It has been proposed of using GMPLS to setup and maintain the PBT tunnels. [Page 5]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 The advantage here is that it enables the operators to run traffic engineering on every PBT tunnel. Also the PBT path setup can be independent from STP, therefore, is immune from the undesirable long convergence problems. The disadvantages in PBT are that each PBB nodes need to be provisioned, and the lack of dynamic provisioning mechanism. 3.4. PBB-based Tunnels If the PBB backbone is over-provisioned and relatively stable, and the carrying data is best-effect, then it does not seem necessary to provision all the nodes, as recommended in PBT. In the context of our proposal, we define PBB-based tunnels as the following: If two edge nodes have connectivity over the PBB backbone, then the operators can establish bi-directional virtual tunnels between two nodes for the purpose of aggregating user traffic flows. Such tunnels are called PBB-based tunnels. Note that the interior nodes do not need to do anything special. The connectivity between edge nodes can be achieved by dynamic protocols, such as STP, or static configuration, or other means. 4. Operation Outline The objective here is to establish PBB-based tunnels over the PBB core, and aggregate customer flows through the point-to-point tunnels. | | |<----- PBB-based Tunnel -------->| | | Customer | | Customer VLANs +------+ +------+ VLANs | | ------------ | | <-------->| | ( ) | |<--------> <-------->| PE-A | { } | PE-B |<--------> ... | |====( PBB )====| | ... <-------->| | ( Network ) | |<--------> | | ( ) | | +------+ ------------ +------+ ^ ^ | | | | [Page 6]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 IP-A IP-B MAC-A MAC-B I-SID-A I-SID-B B-VID-A B-VID-B Figure 2: Operation example The operation is illustrated in Figure 2. The service provider needs to transport multiple customer VLAN flows between PE-A and PE-B. The PBB backbone may apply STP or other means to discover the connectivity between PE-A and PE-B. The operators will configure IP address to both PE nodes. ARP will resolve the MAC addresses, that is, MAC-A and MAC-B. The operators will need the I-SID and B-VID information to aggregate customer flows with MAC-in-MAC encapsulation. We propose of using RFC4447 [PWE3-LDP] to exchange I-SDI and B-VID information. Essentially, we will use the mechanism for setting up PWs to create PBB-based tunnels between PE-A and PE-B. Specifically, the tunnel setup is based on the Generalized ID (GID) FEC (type 129). This enables the operators setting up and managing the tunnels from local PEs. The PBT-based tunnels will use a new AII to identify PBB-based tunnels, which contains MAC, B-VID and I-SID information. In the example, the operators at PE-A will send a LDP mapping message with SAII = {MAC-A, I-SID-A, B-VID-A}, and TAII = {MAC-B, I-SID-B, B- VID-B} to PE-B. Upon successful reception, PE-A and PE-B will install the PBB information on data path. When a VLAN packet from a customer site arrives on PE-A, PE-A will encapsulate a backbone Ethernet header with the appropriated MAC, I-SID and B-VID. Upon the reception, PE-B will remove the header, and continue to the native Ethernet switching. Each PBB-based tunnel can carry traffic from multiple customer sources. When a PBB-tunnel is no longer in use, the operator will apply the standard PWE3 procedure to remove it. For OAM support, the operators have the option to apply either native Ethernet OAM schemes (802.3ah, 802.1ag) or VCCV (LSP-ping, BFD), or both. For protection support, the operators can either rely on STP to converge, or statically establish backup connections between PE-1 and [Page 7]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 PE-2. The method in establishing backup Ethernet connections is beyond the scope of this draft. In terms of QoS, we adapt the most common practice in Ethernet networks, over-provisioning. Finally, other than the PE nodes need to be IP-enabled to support ARP and target LDP, the rest of the network can remain Ethernet-only. 5. Protocol Extensions The document specifies the protocol requirements and definitions for setting up PBB-based tunnels from network edge. 5.1. Generalized ID FEC RFC4447 defines the mechanism for setting up point-to-point Pseudowires between two PE nodes. During Pseudowire setup, the PE nodes will exchange messages containing information about the PW type and an endpoint identifier used in the selection of the packet forwarder. Endpoint identifier can be represented in two formats: PWid FEC (type 128) and Generalized ID (GID) FEC (type 129). The PWid FEC requires to be configured on the local and remote PE prior to PW setup. The GID FEC defines each PW as a combination of Source and Destination Attachment Individual Identifiers (AII). Each AII is globally unique. This arrangement enables GID to be used for individual configuration, as well as provisioning models where the local PEs can learn (or discover) about the remote PEs prior to launching PWs. For sizeable PBB-based tunnel deployment, the GID FEC presents a more flexible and scalable solution. We require GID to be used in setting up PBB-based tunnels. 5.2. AII Type: PBB-based Tunnels We define a new AII Type for PPB-based Tunnels. The encoding is shown in Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=xx | Length | B-MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Page 8]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 | B-MAC (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B-VID | I-SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-SID (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: AII Type: PBB-based Tunnel B-MAC: Backbone MAC address B-VID: Backbone VLAN ID I-SID: Service Instance ID All above parameters have been defined in [PBB]. 5.3. Pseudowire Status We will use the defined Pseudowire Status [PWE3-IANA] for PBB-based tunnels. 5.4. OAM We believe that VCCV needs to specific the OAM types. Other than LSP- ping and BFD, VCCV may need to expand to advertise 802.1ag and 802.3.ah as capabilities [VCCV]. 6. Applications 6.1. Interconnection PBB Domains with PW MHOP (TBD) 6.2. Carrying multi-service traffic over PBB-based tunnels (TBD) 6.3. Interworking with PBT (TBD) [Page 9]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 7. 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. 8. Full 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. 9. IANA Considerations This document has defined an AII type for PBB-based tunnels. 10. Normative References [Page 10]
Internet Draft draft-pan-pwe3-pbb-tunnels-00.txt June 2007 [PBB] IEEE 802.1ah, " Virtual Bridged Local Area Networks Amendment 6: Provider Backbone Bridges" [PBT] IEEE 802.1Qay, Provider Backbone Bridge Traffic Engineering [PWE3-LDP] L. Martini, et al., Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC4447, April 2006 [PWE3-IANA] L. Martini, IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3), RFC4446, April 2006 11. Informative References [Q-in-Q] IEEE 802.1ad, "Virtual Bridged Local Area Networks: Provider Bridges" [RFC3985] Bryant, et al., "PWE3 Architecture", RFC3985, March 2005. [VCCV] T. Nadeau, et al., Pseudo Wire Virtual Circuit Connectivity Verification (VCCV), March 2007. [PW Switching] L. Martini, et al., Pseudo Wire Switching, February 2007. [MHOP] L. Martini, et al., Dynamic Placement of Multi Segment Pseudo Wires, October 2006. 12. Author Information Ping Pan Hammerhead Systems ppan@hammerheadsystems.com Shane Amante Level 3 Communications Shane.Amante@Level3.com Nasser El-Aawar Level 3 Communications Nasser.El-Aawar@Level3.com [Page 11]