INTERNET-DRAFT Peter Kao Network Working Group IP Infusion, Inc. Intended Status: Standards Track Expiration Date: July 9, 2011 January 9, 2011 BGP/PBB IP Virtual Private Networks (VPNs) draft-kao-pbb-l3vpn-00.txt Abstract This document describes a method by which a Service Provider may use an IEEE 802.1ah PBBN (Provider Backbone Bridge Network) to provide IP Virtual Private Network Service for its customers. This method extends the BGP/MPLS IP VPN service to allow IP VPN service to be offered using a PBN instead. This document specifies the way in which this is done. Status of this Memo This Internet-Draft is submitted in full conformance with the 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 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Kao Expires July 9, 2011 [Page 1] Internet-Draft draft-kao-pbb-l3vpn-00.txt January 9, 2011 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ....................................................2 1.1. Customer Edge and Provider Edge Route Exchange .............3 1.2. Internal Route Distribution Among Provider PEs .............3 1.3. Backbone Core Bridges ......................................4 2. Customer VPN Route Distribution .................................4 3. Control Plane Connectivity ......................................4 3.1. Internal Route Distribution ................................4 3.2. VPN Route Distribution .....................................5 3.3. Use of Route Reflectors ....................................5 4. Forwarding ......................................................5 4.1. VPN Packet Format ..........................................5 4.2. Ingress PE Processing ......................................6 4.3. Egress PE Processing .......................................6 5. Carriers' Carriers and Multi-AS Backbones .......................7 6. Quality of Service ..............................................8 7. Scalability .....................................................8 8. OAM&P ...........................................................8 9. Contributors ....................................................8 10. Normative References ...........................................8 11. Informative References .........................................9 1. Introduction This document describes a method by which a Service Provider may use an IEEE 802.1ah PBN (Provider Backbone Bridge Network) to provide IP Virtual Private Network (VPN) Service for its customers. This method follows the same "peer model" as described in [BGP-MPLS-VPN], in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers). Border Gateway Protocol (BGP) [BGP, BGP-MP] is then used by the Service Provider to exchange the routes of a particular VPN among the PE routers which are attached to that VPN. In this method, normal [BGP-MPLS-VPN] operations will be followed for attachment circuit, VRF, and VPN route distribution. However, MPLS LSP is replaced by a PBB B-VLAN. This transport decoupling allows BGP/VPN to run over a PBBN instead of a MPLS network. Before a customer data packet passes through the Provider's PBBN, a B-VLAN Kao Expires July 9, 2011 [Page 2] Internet-Draft draft-kao-pbb-l3vpn-00.txt January 9, 2011 path will be selected that corresponds, in the customer's VPN, to the transport path that is the best match to the packet's destination address. Thus, the PBBN core bridges do not have to know the VPN routes. 1.1. Customer Edge and Provider Edge route exchange Each VPN site must contain one or more Customer Edge (CE) devices. Each CE device is attached to one or more Provider Edge (PE) devices known as Provider Backbone Edge Bridge (IB-BEB) via attachment circuit. An IB-BEB high-level architectural view is shown in Figure 1. [IB-BEB-A] ------- ------ CE ------| [I] |-------| [B] |-----| CNP| |PIP CBP| |PNP | ------- ------- | | | |-------| | | ------- | BCB | ------- | [IB-BEB-B] | ------- ------- |-----| [B] |-------| [I] |------ CE PNP| |CBP PIP| |CNP ------- ------- Figure 1. IB-BEB High-Level Bridge Architecture Bridges in the SP's network that do not attach to CE devices are known as "Provider Backbone Core Bridges" (BCB). CE devices exchange routes with PE devices using static routes, OSPF , or eBGP. CE devices can be hosts or routers. 1.2. Internal Route Distribution Among Provider PEs In this method, instead of using IGP for internal route distibution, PATH MP-IBGP [BGP-PATH-BINDING] is used to distibute a Link Layer piggybacked on NLRI, along with the usual Network Layer BGP Next Hop for each internal network route advertised by a Path MP-IBGP speaker. In this manner, within an autonomous switching domain, each PE can reach the next hop of an internal network route directly using Ethernet switching over a PBB B-VLAN. Kao Expires July 9, 2011 [Page 3] Internet-Draft draft-kao-pbb-l3vpn-00.txt January 9, 2011 The Path_Next_Hop field piggybacked in NLRI of a BGP Update message should be the MAC address of a CBP (Customer Backbone Port) on the IB-BEB which is advertising the internal routes. There can be one or more CBP resource(s) on a IB-BEB. 1.3. Provider Backbone Core Bridges In a PBN, the Provider Backbone Core Bridges (BCB) switches frames only based on B-DA, and B-VID. BCB can rely on STP, RSTP, MSTP, RPVSTP, TRILL, SPB (Shortest Path Bridging), or manual provisioning to resolve network topology. 2. Customer VPN Route Distribution Customer VPN-IPv4 route distribution is still done using Labeled VPN MP-IBGP as in [BGP-MPLS-VPN]. On each PE, the VPN-IPv4 BGP Next Hop (RD=0) it advertises for its customer VPN-IPv4 routes has to resolve to the same BGP Next Hop advertised in Path MP-IBGP. This way, internal link layer path connectivity remains consistent both internal network and external customer VPN routes. 3. Control Plane connectivity 3.1. Interal Route Distribution Path MP-IBGP speakers talk to each other through a common control B-VLAN with an unique, reserved I-SID by configuration. The Path MP- IBGP packets should be encapsulated as payload in a PBB frame. In that PBB frame, the C-DA and C-SA fields should be set to zero and the NCA bit in I-tag should be set to 1. There should be no S-TAG or C-TAG in the frame. Referring to Figure 1, architecturally speaking, a BGP speaker resides in the I-COMP of a BEB. eBGP traffic comes in from attachment circuit and iBGP traffic comes in from the PIP which has the same B-MAC as its associated CBP. Each iBGP speaker on a IB-BEB needs to be associated with one or more CBP MAC address by configuration. An associated CBP MAC address should be used as the B-SA in frames the iBGP speaker originates and should match the Path_Next_Hop advertised in the BGP Update message. This enables an iBGP speaker to manage multiple CBP resources for purposes such as load balancing. Kao Expires July 9, 2011 [Page 4] Internet-Draft draft-kao-pbb-l3vpn-00.txt January 9, 2011 Path MP-IBGP |----------------------------------| | SP's Internal Routes | |--------v-| |-v--------| | Path | | Path | | MP-IBGP |<---------------------------->| MP-IBGP | |----------|[CBP] control B-VLAN [CBP]|----------| PE PE 3.2. VPN Route Distribution Labeled VPN MP-IBGP speakers talk to each other using the default forwarding table after the internal routes have been established with bindings installed. Labeled VPN MP-IBGP |----------------------------------------------------| | Customer's VPN Routes | | |-v--------| |--------v-| | | | Labeled | | Labeled | | v | VPN | | VPN | v ----| MP-IBGP |<------------------------>| MP-IBGP |----- |----------| |----------| PE PE This is done to ensure that a single unified VPN peer PE reachability method is used by the various hierarchical/recursive VPN interworking applications. The external customer VPN routes are distributed as labeled VPN-IPv4 routes as in [BGP-MPLS-VPN]. 3.3. Use of Route Reflectors Rather than having a complete IBGP mesh among the PEs, BGP Route Reflectors [BGP-RR] can be used to improve scalability. Within a BGP/PB VPN switching domain, one or more RR can be used. The only requirement specific to BGP/PB VPN is that if a RR participates in Path MP-IBGP sessions then it must have control VLAN connectivity to all the PEs which are its clients. 4. VPN IP Packet Forwarding 4.1 VPN Packet Format Since labeled VPN IPv4 routes are used for external customer VPN route distribution, this addressing information needs to be preserved among peering VPN PEs. In this method, this is done by carrying the VPN label stack generated at each PE, per [BGP-MPLS-VPN], inside a PBB-VIF (PBB-VPN Interworking Frame) format. In particular: Kao Expires July 9, 2011 [Page 5] Internet-Draft draft-kao-pbb-l3vpn-00.txt January 9, 2011 - PBB-VIF (PBB-VPN Interworking Frame) Within a PBBN, the VPN traffic transported should use the following format: |DA|SA|B-Tag|I-TAG|0x8847|Label|IP Payload|FCS| For the most part, this is a Mac-in-Mac Provider Backbone Bridge Frame. An additional MPLS Label field is inserted before the usual frame payload position. The Label field contains a label stack of one or more labels depending on the hierarchy of the interworking VPN networks. The specifications of all fields are as defined in their respective specifications. There is no S-VLAN, C-VLAN, or custom MAC address in the frame. The I-tag NCA bit should be set. 4.2. Ingress PE Processing When an ingress PE receives a user IP packet on an attachment circuit, it first follows the normal BGP/MPLS operation right before the point when an egress PE to LSP mapping needs to be resolved. At this point, instead of resolving to a LSP, the ingress PE uses an egress PE to Path_Next_Hop mapping to resolve the transport path. In a PBB-VIF frame with user IP packet in the payload, the ingress PE will then form a PBB-VIF frame with the usual BGP/MPLS VPN label stack in the label stack field, use the as B-DA , use the I-SID associated with the ingress attachment circuit to lookup a CBP and B-VLAN mapping, use the CBP port MAC as B-SA, put customer IP packet in the payload, and forward the PBB-VIF frame onto the B-VLAN, out of the CBP. Note that, the I-SID to attachment circuit association is by configuration. The association is also by configuration. When PBB-TE Linear APS is used, the I-SID to B-VLAN mapping may be updated by PBB-TE Linear APS to put the packet on a different path across a PBBN. 4.3. Egress PE processing When a PBB-VIF packet reaches the egress PE, it extracts the IP payload and the VPN label stack carried in the PBB-VIF then proceeds with normal BGP/MPLS operation as specified in [BGP-MPLS-VPN]. With respect to the forwarding path through the PBBN, the following should be noted: - Determined by B-VLAN ID; Kao Expires July 9, 2011 [Page 6] Internet-Draft draft-kao-pbb-l3vpn-00.txt January 9, 2011 - DOES NOT require that the B-VLAN be point-to-point; multipoint- multipoint can be used; - DOES NOT require that there be any VLAN-specific signaling; - DOES NOT require any IGP. Can work with manual provisioning, GVRP, STP, RSTP, MSTP, RPVSTP, SPB, or TRILL. 5. Carriers' Carriers and Maulti-AS Backbones With an embedded VPN stack, a PBB-VIF can be used to preserve the VPN interworking processing specified in [BGP-MPLS-VPN] for both single- AS and Multi-AS applications. In particular, - An MPLS interface should always be used at VPN network boundaries. This enables the end-to-end customer VPN PE route identification to be preserved across a hierarchical/recursive VPN network. - A PBB/VPN network uses Path MP-IBGP to distribute internal network routes and use Labeled VPN MP-IBGP to distribute external customer VPN routes. As an example, per Multi-AS VPN interworking option c) [BGP-MPLS-VPN] , two MPLS/VPN providers are interconnected via a PBB/VPN transit VPN provider in this recursive VPN example. Provider A (AS 1) |Transit Provider (AS 2)| Provider B (AS 3) |-----------------Labeled VPN Multi-hop MP-EBGP------------------| | | | Labeled VPN MP-IBGP | | |---------------------| | | | | | | | | | | IGP+LDP EBGP | PATH MP-IBGP | EBGP IGP+LDP | v v v v |A-PE|---|A-CE|------|T-PE-L|---------|T-PE-R|------|B-CE|-----|B-PE| [ MPLS/VPN ][MPLS][ PBB/VPN ][MPLS ][ MPLS/VPN ] |-> MPLS <-|-> PBB-VIF <-|-> MPLS <-| Figure 2. MPLS/VPN Provider with PBB/VPN Transit Provider The key point here is that, at T-PE-L and T-PE-R, a PBB-VIF preserves the VPN label stack hierarchy resulted from the two independent Labeled VPN MP-xBGP sessions allowing the noraml GBP/MPLS PE label operations to be applied such that MPLS path connectivity can be preserved end-to-end. Within the BGP/PBB VPN, the IGP/RSVP T-PE-L to T-PE-R label path can then be replaced by a transport path without impacting the VPN label hierarchy. Kao Expires July 9, 2011 [Page 7] Internet-Draft draft-kao-pbb-l3vpn-00.txt January 9, 2011 6. Quality of Service In BGP/PBB VPNs, existing L2 QoS capabilities can be applied to B-VLAN tagged packets as specified in IEEE 802.1ah. 7. Scalability In a BGP/PBB VPN network, the Service Provider backbone network consists of (a) BGP/PBB IB-BEB edge switchs, (b) BGP Route Reflectors , (c) BCB core switches, and, in the case of multi-provider VPNs with MPLS/VPN [BGP-MPLS-VPN] or PB/VPN [BGP-PB-VPN] interworking, (d) ASBRs. BCBs do not maintain any Internal or VPN routes. In order to properly forward VPN traffic, the BCBs need only maintain backbone MAC address and VLAN information. A BGP/PB PEB switch maintains VPN routes, but only for those VPNs to which it is directly attached. For inter-provider VPNs with MPLS interworking, the route distribution model specified in [BGP-MPLS-VPN] is preserved in order to maintain the scalability. As a result, scalability is achieved by ensuring that every individual component within a single-AS or Multi-AS network, with or without MPLS/VPN, or PB/VPN interworking, only has to maintain directly attached VPN routes. 8. OAM&P For VLAN continuity and Performance Monitoring among PEs, ITU-T Y.1731 should be used. Multicast CCM should be used whenever there are more than two Path_Next_Hop end-points reachable on a B-VLAN, otherwise Unicast CCM should be used. 9. Contributors 10. Normative References [BGP-PATH-BINDING] Kao, P., "Carrying Path-Binding information in BGP-4", draft-kao-path-binding-bgp4-00.txt, January 2011. [BGP-MPLS-VPN] Rosen, E. and Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. Kao Expires July 9, 2011 [Page 8] Internet-Draft draft-kao-pbb-l3vpn-00.txt January 9, 2011 [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 11. Informative References [BGP-PB-VPN] Kao, P., "BGP/PB IP Virtual Private Networks (VPNs)", draft-kao-pb-l3vpn-00.txt, January 2011. [BGP-AS4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet AS Number Space", Work in Progress, March 2004. [BGP-ORF] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, March 2004. [BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000. [BGP-RR] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Acknowledgements This documents is heavily based on RFC 4364, whose authors - E. Rosen and Y. Rekhter - are cordially acknowledged. Authors' Addresses Peter Kao IP Infusion, Inc. 1188 East Arques Avenue Sunnyvale, CA 94085 Email: peterk@ipinfusion.com Kao Expires July 9, 2011 [Page 9]