Internet Working Group P. Unbehagen Internet Draft Alcatel-Lucent Date Created: July 6, 2009 R.Lapuh Expiration Date: January 2010 Nortel Intended Status: Informational S.Hares Green Hills Software IP/IPVPN services with IEEE 802.1aq SPBB networks draft-unbehagen-spbb-ip-ipvpn-00.txt Status of this Memo This Internet-Draft is submitted to IETF 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. This Internet-Draft will expire on January 6, 2009. Copyright Notice Copyright (c) 2009 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 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. Unbehagen, et. al Expires January 6, 2010 [Page 1] Internet-Draft IP & IPVPN services w/ SPBB July 2009 Abstract This document describes a compact method of using a IEEE 802.1aq Shortest Path Backbone Bridging SPBB network to natively enable and carry IP and IPVPN services for both unicast and multicast traffic on native Ethernet links. Further this documents the extensions to SPBB's control protocol, IS-IS, required to allow it to be a single mechanism for providing all these services types. On its own SPBB provides virtual Ethernet networks; utilizing IS-IS to create loop free Ethernet topologies that forward Ethernet traffic using a standard Ethernet header. This document shows how the same SPBB network can also be leveraged to provide IP based services. Table of Contents 1. Terminology....................................................2 2. Introduction...................................................3 2.1. SPBB control of BMAC forwarding...........................4 3. IP Shortcut with SPBB..........................................6 3.1. IP Unicast................................................6 3.2. IP Multicast..............................................7 3.2.1. IP multicast Operation...............................7 3.2.2. IP/SPBB IP Multicast TLV.............................8 4. IPVPN & mVPN services with SPBB................................9 4.1.1. Route Propagation Techniques.........................9 4.2. mVPN model...............................................11 4.3. I-TAG Encapsulation......................................11 4.4. IP VPN Deployment Scenarios..............................14 4.4.1. Any to Any VPN......................................14 4.4.2. Hub and Spoke VPN...................................15 5. Interworking with MPLS based Networks.........................16 6. OAM...........................................................17 7. Security Considerations.......................................17 8. IANA Considerations...........................................17 9. References....................................................17 9.1. Normative References.....................................17 9.2. Informative References...................................18 10. Acknowledgments..............................................18 1. Terminology [IEEE802.1aq] defines a technology for providing a link state protocol for the control of a common Ethernet switching layer. [IEEE802.1ah] Provider Backbone Bridging is a set of architecture and protocols for transporting of a customer network traffic over a provider's network Unbehagen, et. al Expires January 6, 2010 [Page 2] Internet-Draft IP & IPVPN services w/ SPBB July 2009 BCB - Backbone Core Bridge BDA - Backbone Destination Address BEB - Backbone Edge Bridge BMAC - Backbone MAC Address BSA - Backbone Source Address BVID - Backbone VLAN ID ESP - Ethernet Switched Path ISID - Service Identifier MDT - Multicast Distribution Tree mVPN - Multicast IPVPN SPF - Shortest Path Forwarding SPBB - Shortest Path Backbone Bridging TLV - Type Length Value 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]. 2. Introduction The IEEE is defining a method of leveraging IS-IS to efficiently control the BMAC layer of the 802.1ah PBB encapsulation. This method provides an efficient manner of learning topology and EVPN membership information using link state. SPBB enables Ethernet switches to participate in the construction of Ethernet forwarding tables based on a combined unicast/multicast SPF algorithm while forwarding with a standard Ethernet header, enabling backward compatibility to today's deployed network infrastructures. The combination of Ethernet and SPBB/IS-IS enables an Ethernet based network to provide for numerous services beyond Ethernet VPNs, while providing a significant simplification of the operational models behind them as well. As both Ethernet and IS-IS natively enable the announcement and encapsulation of numerous protocols, this is a logical fit. Also Ethernet's inherent multicast capability combined with its deterministic forwarding of Ethernet Switched Paths (ESPs) Unbehagen, et. al Expires January 6, 2010 [Page 3] Internet-Draft IP & IPVPN services w/ SPBB July 2009 allow for a seamless way of providing any of IP, IPVPN and EVPN services by leveraging Ethernets underling bridging capabilities. SPBB uses the terms Backbone Core Bridge (BCB) and Backbone Edge Bridge (BEB) to describe the functions of network nodes in the network. These terms describe features that are similar in function to the PE and P nodes in a MPLS network. 2.1. SPBB control of BMAC forwarding SPBB enables a loop free construction of Ethernet switched paths between every SPBB enabled node by reusing some existing components of IS-IS and by adding a small set of new IS-IS TLVs. SPBB nodes use a standard IS-IS mechanism of operation for neighbor discovery and database distribution. SPBB utilize an IS-IS based on IS-IS Ethernet link level peering protocol so it does not depend on IP addressing. Also, due to the fact that the links are forwarding on the source and destination information in the Ethernet header, there is no requirement to verify that each node can do IP routing. Multicast Forwarding entries (BMAC FDB or FIB) on each node are constructed based on a combination of a nodal unique identifier and a administratively controlled service identifier providing PBB tunnels that can be adjusted to match a desired service granularity. This entry is used a locally administered BMAC in a standard PBB frame. Each node uses standard IS-IS methods of sharing link state PDU's. Those PDUs contain the System-ID of each node, the attached neighbors and information such as EVPN ISIDs for SPBB. A unicast SPF process runs on each switch to construct the unicast connectivity of each switch to every other switch based on these nodal MAC's (BMACs) derived from the System-ID. Each node that is on the shortest path between any other given nodes will install corresponding FDB entries only on their associated ports. This has the added benefit that Ethernet FDB entries exist only on nodes that are the source, root, or tandem point for a give SPF ESP between any given set of nodes. Any node that does not need to participate in the tandem calculations may use the IS-IS overload bit to exclude tandem paths and behave as only the root or source for any given service traffic. Unbehagen, et. al Expires January 6, 2010 [Page 4] Internet-Draft IP & IPVPN services w/ SPBB July 2009 +---+ +---+ | A |-----------------| B | +---+ +---+ | \ / | | \ / | | \ / | | \ / | | \ / | | \ / | | +---+ | | | C | | | +---+ | | / | \ | | / | \ | | / | \ | | / | \ | | / | \ | | / | \ | +---+ +---+ +---+ | D |------| E |------| F | +---+ +---+ +---+ Figure 1 Reference Network Diagram Figure 1 provides an example topology for showing the distributed nature of the Ethernet FDB. For any traffic sourced from node A and destined to nodes B or D will a standard Ethernet FDB entry on A pointing to the directly connected neighbor. No other SPBB node will have the FDB entries for the connectivity of A to either B or D. While connectivity from node A to nodes E or F may exist on node C depending on the results of a SPF calculation, but the FIB entries will only exist on node C after it verifies that it is on the shortest path between A and either/or E and F. It is important to note that the network is truly providing a Minimum Cost Tree from each node to every other based on link costs and SPF calculations. This allows for the more efficient use of network bandwidth. This base control enabling a configurable Virtual Service LAN forms the building block for many services. Unbehagen, et. al Expires January 6, 2010 [Page 5] Internet-Draft IP & IPVPN services w/ SPBB July 2009 3. IP Shortcut with SPBB IP unicast and multicast can leverage this base BMAC switching layer by mapping IP to the Ethernet service points. The standard mechanisms of IS-IS IP route propagation can be used to associate remote IP networks to the far end nodal Ethernet address to forward towards for unicast traffic. For IP multicast traffic a new TLV is proposed that allows reuse of IS-IS and SPBB to provide for a native IP multicast protocol that utilizing the same BMAC forwarding abilities used to build EVPNs. The encapsulation of IP unicast packets would use the standard method to include an Ethertype of 0x800 behind the BMAC header. Packets received Packets in transit Packets forwarded at ingress BEB in the network by egress BEB +============+ +=============+ +============+ | IP Header | | IP Header | | IP Header | +============+ >>>>> +=============+ >>>>> +============+ | C-MAC | | B-MAC | | C-MAC | +============+ +=============+ +============+ 3.1. IP Unicast The native unicast entries SPBB constructs, provide a simple way of enabling end to end switching of IP packets along a deterministic Ethernet Switched Path (ESP). Knowledge of the location of IP subnets is achieved by utilizing the existing functionality of IS-IS TLVs for IPv4 and IPv6. The operation becomes one of creating FDB entries that coincides with the IP points of presence. In other words a utilizing SPBB LAN specific to the IP service is created and IP addresses are mapped to the appropriate BMACs for unicast forwarding. For IP subnet awareness the existing IS-IS TLVs are used to propagate routing tables. The forwarding is the standard IP in Ethernet encapsulation. To enable this behavior, this document specifies an efficient learning and forwarding operation where an edge BEB provides a standard IP interface to its attached IP devices. The BEB performs a route lookup on the destination IP addresses which will resolve to a remote BMAC to forward towards on the SPBB portion of the network, and then encapsulates the IP packet in a Ethernet header using the unicast BMAC operation with a standard IPv4 or IPv6 ethertype. In essence this is IP over Ethernet where the Ethernet is a BMAC based Ethernet. Unbehagen, et. al Expires January 6, 2010 [Page 6] Internet-Draft IP & IPVPN services w/ SPBB July 2009 3.2. IP Multicast For IP multicast, again the operation becomes one of creating FDB entries that coincides with the IP points of presence, but this time the topology can be controlled to a multicast (source, destination) level of granularity. Similar to MPLS, a edge device (BEB) can take over tandem switching functionality (BCB).In the SPBB network the BEB is responsible for announcing ISIDs for which it has access ports. This Link State announcement informs all IS-IS nodes running SPBB about the group membership. After learning about group members, each BEB and BCB node calculates the Multicast FDB State. They then populate Multicast FDB state for this service instance if they are on the minimum cost path between a set of nodes announcing membership to the same ISID. These actions establish full multicast connectivity between all BEB's sharing this ISID in common. This method of calculation and installation allows SPBB to provide a powerful technique for adding and removing endpoints in an EVPN service efficiently with single endpoint provisioning models. Note that once the shortest path tree has been computed for a BVLAN all multicast Virtual services are a pruned subtree of the complete shortest path tree. Therefore each ISID produces a pruned set of trees simply by populating the FDB with multicast MACs computed as described earlier. This function can also be used to provide for an inherent and complete multicast protocol function within the SPBB domain. This removes the need to run other multicast protocols over the SPBB domain. Allowing IP/SPBB to provide a fully functional IP Multicast routing protocol. 3.2.1. IP multicast Operation Only three pieces of information are required to be sent to enable IP/SPBB to operate as an IP multicast protocol with in the SPBB domain. The three pieces are: IP source, the IP group destination, and the ISID for the SPBB network to use for Multicast tree construction. As new multicast receivers or senders are configured or learned in the SPBB network, either dynamically via IGMP or by manual configuration, the IP S,G is mapped to an ISID for the tandem SPBB nodes to construct the appropriate multicast state in their FDB's To facilitate this operation a new TLV is required in order to propagate S,G state with the network. This TLV contains information about the Source IP address (optional), the IP Multicast Group Unbehagen, et. al Expires January 6, 2010 [Page 7] Internet-Draft IP & IPVPN services w/ SPBB July 2009 Address, and the ISID value that the S,G pair is associated with for the multicast forwarding. 3.2.2. IP/SPBB IP Multicast TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| MT-ID |E|U|S|R| VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP MC Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R|S| Resv | ISID Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 IP Multicast TLV - MT-ID is used to identify which SPB logical topology instance this TLV belongs to.[MT] - E is used to signify if the route is an internal or external route - U signifies a UP/Down bit for knowledge - VID - Metric provides a method for conveying the metric from another IP multicast protocol in or through the IP/SPBB IP multicast domain. Allowing it to carry metric information between multiple IP multicast protocols. - IP Source Address of a sender - IP MC Group Address - T is used to signify if the connected devices are senders for this multicast group. Setting this bit will trigger the SPBB domain to construct a multicast tree rooted at this node based on the ISID address that follows - R signifies that the node is a receiver and triggers the SPPB nodes to add this node to a multicast tree for this group if it already exists. - S signifies if sub-TLVs are being carried for this TLV, with up to 250 octets of sub-TLVs that may be present. - ISID Value is used to map to a Ethernet multicast address for tree construction through SPBB portion of the network. Multiple IP S,G pairs may be announced with the same ISID value, providing a Unbehagen, et. al Expires January 6, 2010 [Page 8] Internet-Draft IP & IPVPN services w/ SPBB July 2009 method of aggregation of multicast traffic onto a common multicast address. 4. IPVPN & mVPN services with SPBB Using the TLV extensions described below it is possible to extend SPBB to not only provide EVPN and the above described IP connectivity, but also provide virtualized solutions for IP services such as IPVPNs and mVPNs. The next sections will outline the route propagation techniques for two different deployment models. Two common modes of carrying information are: BGP or ISIS [ISIS]. The IS-IS method will be described in this version of the draft. The control plane encapsulation of VRF routes passed in BGP is similar to the method used here with ISIS. 4.1.1. Route Propagation Techniques The ability to share routes within a network can be provided within IS-IS. To accomplish this flexibility the use of a new IPVPN TLV and optional sub-TLV is proposed. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| MT-ID |U|Resv | VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R| Resv |S| ISID Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 IPVPN TLV The TLV MAY appear any number of times (including none) within a Link State PDU. the up/down bit used for notification if this TLV has been leaked down into a L1. The T bit and R bit are used to signal to the other nodes whether to construct Multicast trees to and from this announcing node depending on the combination of bits set to 1. If neither the T nor R bit is set, then the IPVPN service is unicast only. The next 4 bits are reserved and the S bit is used to signify that the VPN-Route Sub-TLVs are present. Sub-TLVs may be set to carry specific routes for each VPN within IS- IS. This allows for routes from multiple VPNs to be carried under their respective VPN ISID IDs and allow for overlapping IP subnets. Unbehagen, et. al Expires January 6, 2010 [Page 9] Internet-Draft IP & IPVPN services w/ SPBB July 2009 IP/SPBB VPN ISIDs are comparable to RFC4346s Route distinguishers and separate VPN traffic in the control plane. VPN routes are exchanged through IS-IS and can be distinguished by the individual ISID they are associated with. In order to form different types of IP VPNs on BEB's, routes can be exported into ISID's or imported from ISID's. This document also defines the following new sub-TLV types that need to be reflected in the IS-IS sub-TLV registry for the spbb ipvpn TLV: Sub-Type Description ------- ------------------------------ 1 IPv4 Prefix information 2 IPv6 Prefix information 3 IPv4 Multicast Prefix information The encapsulation is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Sub-TLV model The sub-TLVs are designed to mimic the top level TLVs for IP reachability within the VPN. Allowing for a given VRF to support multiple IP service models within a single VPN-ID Sub-TLV 1 is similar as the Extended IPv4 TLV 135 and MAY appear multiple times in the same TLV with a data structure consisting of: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | Resv |S| Prefix Ln | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 IPv4 sub-TLV Sub-TLV 2 is similar to the IPv6 TLV 236 and MAY appear multiple times in the same TLV with a data structure consisting of: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unbehagen, et. al Expires January 6, 2010 [Page 10] Internet-Draft IP & IPVPN services w/ SPBB July 2009 | Type | Length | Resv |E|S| Prefix Ln | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 IPv6 sub-TLV Sub-TLV 3 is to propagate IP multicast information within a VPN. The presence of the ISID values here allow a network to set up more specific multicast distribution trees for a given set of Multicast group addresses. It MAY also appear multiple times in the same TLV with a data structure consisting of: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |S| Resv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP MC Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R| Resv |S| ISID Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 IP Multicast sub-TLV 4.2. mVPN model A default MDT can be created automatically by the use of the IPVPN ISID transmit and receive bits by setting both the T and R bits to 1. The converse is also true where setting both to 0 causes the L3VPN to be unicast only. In order to construct more constrained trees for particular IP multicast streams or group of steams the IP Multicast TLV MAY be reused as a sub-TLV for the IPVPN TLV. Data MDT's are created using the IP Multicast sub TLV for the IPVPN ISID TLV. 4.3. I-TAG Encapsulation For the forwarding of IPVPN traffic the use of the standard 802.1ah I-TAG would require the encapsulation of a nulled out CMAC address, since the traffic is IP and routed at each BEB there is no need for a CMAC. Therefore the more optimal encapsulated method used for IPVPN traffic within the SPBB network is to use the ISID portion of the I- TAG without a CMAC header, called the short I-TAG. This allows the Unbehagen, et. al Expires January 6, 2010 [Page 11] Internet-Draft IP & IPVPN services w/ SPBB July 2009 network to carry forward the benefits of the global label/VPN ID purpose of the ISID without enforcing unnecessary header overhead. The encapsulation of IP packets, unicast and multicast, being forwarded for a IPVPN would use a short I-Tag (ISID with no CMAC) behind the BMAC header. Unbehagen, et. al Expires January 6, 2010 [Page 12] Internet-Draft IP & IPVPN services w/ SPBB July 2009 Packets received Packets in transit Packets forwarded at ingress BEB VRF in the network by egress BEB VRF +=============+ | IP Header | +============+ +=============+ +============+ | IP Header | | Short I-TAG | | IP Header | +============+ >>>>> +=============+ >>>>> +============+ | C-MAC | | B-MAC | | C-MAC | +============+ +=============+ +============+ Figure 8 Short I-TAG encapsulation of IPVPN Packets Where the ISID encapsulation is as follows. .1ah I-TAG TCI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P/DE |R1 |R2 | I-SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 Short I-Tag P/DE 3 Bits Priority, 1 bit Drop Eligible R1 Res1 R2 Res2 a) priority - This 3 bit field carries the customer priority (I-PCP) associated with this frame. The provider network operates on the priority associated with the B-TAG. b) drop_eligible - This 1 bit field carries the customer drop eligibility (I-DEI) associated with this frame. The provider network operates on the drop eligibility associated with the B-TAG. c) res1 - This 2 bit field is used for any future format variations. The res2 field is zero on transmit and is ignored on receipt. d) res2 - This 2 bit field is used for any future format variations. The res1 field is zero on transmit and if set on reception the frame is discarded. e) I-SID - This 24 bit field carries the service instance identifier associated with this frame. Unbehagen, et. al Expires January 6, 2010 [Page 13] Internet-Draft IP & IPVPN services w/ SPBB July 2009 4.4. IP VPN Deployment Scenarios 4.4.1. Any to Any VPN Deployment Scenario 1 any to any connectivity may for example consists of 3 nodes participating in the same IPVPN. BEB B +-------+ | ,-, |--- Subnet B | |VRF| | | | 1 | | |/ `'' | ,,..--..,,,+-------+ ,-'` / `'-, .` / `' ,' / `. / / , | IP/SPBB Core | \ / ` `. ------ISID-100------- ` ', / \_-` +------/-,, _,-,-\-----+ | ,-,/ | ``'''--'''`` | ,\--, | | |VRF| | | |VRF| |--- Internet Subnet A --- | | 0 | | | | 2 | | | `|' | | `|' | +-,--,,-+ +--,--,,+ BEB A BEB C Figure 10 IPVPN Model BEB Node A is connecting to subnet A/VRF0, node B to subnet B/VRF1 and node C to the Internet/VRF2. In order to provide IP connectivity all three nodes import their routes into ISIS into a common ISID (i.e. 100). For this node A exports VRF0 routes into ISID 100, node B exports VRF1 routes into ISID 100 and node C exports VRF2 routes into ISID 100. Vice versa all 3 nodes import routes from IS-IS ISID 100 into their respective VRFs. Unbehagen, et. al Expires January 6, 2010 [Page 14] Internet-Draft IP & IPVPN services w/ SPBB July 2009 4.4.2. Hub and Spoke VPN Deployment Scenario 2 hub and spoke topology consists of 3 nodes. BEB bode A is the hub and BEB nodes B and C are the spokes. In this deployment there should be no direct connectivity between the spokes. BEB B +-------+ | ,-, |--- Subnet B | |VRF| | | | 1 | | |/ `'' | ,,..--..,,,+--/----+ ,-'` / `/-, .` / / `' , ------ISID-200------ ` / / / \ , | / IP/SPBB Core \ | \ / / \ ` `. /------ISID-100------- \ ` /, / \_-\ +---/--/-,, _,-,-\--\--+ | ,-,/ | ``'''--'''`` | ,\--, | | |VRF| | | |VRF| |--- Internet Subnet A --- | | 0 | | | | 2 | | | `|' | | `|' | +-,--,,-+ +--,--,,+ BEB A BEB C Figure 11 IPVPN Hub and Spoke Model In order to achieve this connectivity two ISIDs are used (100 & 200). ISID 200 is the hub transmit ISID where node A is exporting the routes into and the spokes are listening (i.e. learning routes). On ISID 100 only the hub node A is listening (learning routes) and spoke nodes B and C are exporting their routes into. In order to keep full separation between the spoke nodes IP/SPBB learnt routes are not redistributed back into IP/SPBB in a Split Horizon mechanism. In order to achieve partial mesh topologies any node can be configured to export into or import from ISID 100 resp. 200. As a local Inter-VRF forwarding option a local ISID can be configured on a BEB and two VRFs on the same node can import and export from/to this ISID, thus achieve same device inter-VRF route propagation. Unbehagen, et. al Expires January 6, 2010 [Page 15] Internet-Draft IP & IPVPN services w/ SPBB July 2009 5. Interworking with MPLS based Networks Any IP/SPBB and/or IPVPN SPBB network may exist on its own or may be part of a larger network. For example be attached to a standard IP or IP/MPLS. This section will define a use case for using an SPBB base network as a method of extending IPVPNs from a IP/MPLS core network. A similar model exists for the ELAN service that may span both a SPBB and VPLS portions of the network as defined in [PBBVPLS] The scale and size of the SPBB portion of the network and network devices can then be utilized more efficiently as a single protocol will drain less resources and thereby allow the IPVPN VRFs extend closer to the end customer. Another benefit is that unicast and multicast traffic that is destined within the SPBB network can be forwarded directly in the SPBB portion of the domain without needing to be processed by the MPLS PE. _,,..--..,,, ,-'` `'-, .` `' ,' `. / , | IP MPLS Core | \ ` `. ` ', _-` +------/-,, _,-,-\-----+ | ,-,/ | ``'''--'''`` | ,\-, | MPLS-PE1 | |VRF| | | |VRF| |MPLS-PE2 | | | | BC-PEs | | | | | `|' | | `|' | +-,--,,-+ +--,--,,+ ,' \ ,' \ / \ / \ | SPBB | | SPBB | | Network | | Network | | | | | \ / \ / `. / `. / +------`-,,+-------+ +-------+'-'+-------+ | ,-, | | ,-, | | ,-, | | ,-, | | |VRF| | | |VRF| | | |VRF| | | |VRF| | | | | | | | | | BEBs | | | | | | | | | `'' | | `'' | | `'' | | `'' | +-------+ +-------+ +-------+ +-------+ BEB1 BEB2 BEB3 BEB4 Figure 12 MPLS Interworking A vrf does Service Address to Encapsulation on a VPN basis with some entries of the VRF having MPLS labels and some have IPVPN SPBB entries based on the direction from which the route was learned. The VRF also gets information from different topologies. Routes learned Unbehagen, et. al Expires January 6, 2010 [Page 16] Internet-Draft IP & IPVPN services w/ SPBB July 2009 via BGP have FIB entries pointing to the appropriate next hop and Label set. While routes learned from the IPVPN ISID SPBB domain have FDB entries for the appropriate BMAC address and ISID. Route propagation to and from each domain happens naturally via the protocol interaction within a given VRF. Routes learned from the SPBB domain are automatically announced into the BGP domain or may have policies applied and routes learned from other PE's from BGP are automatically propagated towards the CE's by injecting them into the SPBB domain as a sub-TLV under the VRF's IPVPN ISID TLV. 6. OAM Various techniques exist within the Ethernet standards space for scalable management of Ethernet based networks. For example OAM techniques defined in the IEEE 802.ag and the ITU Y.1731 can be used for the IP based services simillaryly as they are defined for the EVPNs 7. Security Considerations The extensions defined in this document do not incur any additional security considerations. Any IS-IS SPBB network may utilize the security enhancements already defined within the IS-IS working group. 8. IANA Considerations IP/SPBB requires that IANA/ISO allocate these new numbers. 1. From ISIS-TLV Codepoints - IPMC TLV 2. From ISIS-TLV Codepoints - IPVPN TLV 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MT] M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs), RFC 5120, February 2008. [IEEE802.1aq] "IEEE draft Standard for Local and Metropolitan Networks, Virtual Bridged Local Area Networks, Amendment 9: Shortest Path Bridging", IEEE 802.1aq D2.0, June 2009 Unbehagen, et. al Expires January 6, 2010 [Page 17] Internet-Draft IP & IPVPN services w/ SPBB July 2009 9.2. Informative References [IEEE802.1ah] ""IEEE Standard for Local and Metropolitan Networks, Virtual Bridged Local Area Networks, Amendment 7: Provider Backbone Bridges" IEEE Std 802.1ah - 2008 amendment to IEEE 802.Q - 2005. [ISIS] ISO/IEC 10589:2002, "Intermediate system to Intermediate system routing information exchange protocol," ISO/IEC10589:2002. [PBBVPLS] Extensions to VPLS PE model for Provider Backbone Bridging, IETF, Internet Draft, draft-ietf-l2vpn-pbb-vpls-pe-model- 00.txt, Work in Progress, May 12 2009 10. Acknowledgments The authors would like to thank Don Fedyk for input into the contents of this document. And also Peter Ashwood-Smith, Dave Allan, Nigel Bragg, Gautam Khera, and Harish Sankaran for their detailed review of larger work that is behind this memo. This document was prepared using 2-Word-v2.0.template.dot. Unbehagen, et. al Expires January 6, 2010 [Page 18] Internet-Draft IP & IPVPN services w/ SPBB July 2009 Authors' Addresses Sue Hares Green Hills Software, Inc. 825 Victors Way Ann Arbor, MI 48108 Phone: +1 734 222 1610 Email: shares@ghs.com Roger Lapuh Nortel Flughofstrasse 54 8152 Glattbrugg Switzerland Email: roger.lapuh@nortel.com Paul Unbehagen Alcatel-Lucent 2301 Sugar Bush Rd Raleigh, NC 27612 Email: paul.unbehagen@alcatel-lucent.com Unbehagen, et. al Expires January 6, 2010 [Page 19]