INTERNET DRAFT Alicja Celer expiration date: June 2001 Nortel Networks Interworking between IP VPN and shared backbone multicast domains Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026]. 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. Abstract This draft introduces an interworking function between shared backbone multicast domain and VPN multicast domain. The architecture that follows is similar to Multicast Border Router functionality, however the mapping is defined not as a mapping between two different multicast protocols, but two different multicast topologies the under assumption that the shared backbone multicast topology will be shared between VPNs for carrying the traffic. The main assumption made in this draft is that multicast packets are replicated on PE device (router) for scalability and performance reasons. However, it is possible to extend the solution and replicate packets on CE devices. The proposed mapping of addresses to topology solves the issue of scalability of multicast addresses to state knowledge in the core. This draft also identifies three types of multicast capabilities for the core. A. Celer [page 1] INTERNET DRAFT draft-celer-vpn-mcast-00.tx November 2000 1.0 Introduction Several solutions have been put forward to achieve different levels of network privacy when building Virtual Private Networks (VPNs) across a shared backbone. Most of these solutions require separate per VPN forwarding capabilities and make use of IP or MPLS based tunnels across the backbone [VPN-VR], [VPN-CORE], and [VPN-RFC2547]. In all proposed approaches, traffic tunneled via shared backbone is assumed to be unicast in nature. This draft introduces the ability to effectively transfer multicast traffic across a shared backbone. 2.0 Problem statement This draft addresses the issue of sending multicast traffic from one CE device to many CE devices which belong to the same VPN. Traffic is sent over shared backbone, hence the preservation of security of that traffic is a requirement. For the purpose of this draft the following terminology is used: * CE router : Customer Edge Router connects VPN site to shared backbone * PE router : Provider Edge Router connects many CE routers (each may belong to a separate VPN) to shared backbone network * P router : Provider Router does not have direct connectivity to CE router * VPN site : customer network connected to CE router * Multicast Domain Border Mapping : interworking function used to connect VPN and shared backbone multicast domains that do not propagate multicast topology information between each other Network Reference Model A VPN customer site is connected to the provider backbone by means of a connection between a CE device, (which can either be a bridge or a router) and a PE device. CE devices are preconfigured to connect to one PEs. +---+ +---+ | P |....| P | +---+ +---+ / \ +----+ +------+ +------+ +---+ | CEs|--| PE | | PE |--|CEs| +----+ +------+ +------+ +---+ \ / +---+ +---+ | P |....| P | +---+ +---+ Figure 1: Network Reference Model A. Celer [page 2] INTERNET DRAFT draft-celer-vpn-mcast-00.tx November 2000 Unicast routing tables associated with each CE router define the site-to-site reachability for each VPN. The internal backbone provider routers (P) are not VPN aware and do not keep VPN state. Each multicast capable CE router has at least one multicast routing table which contains multicast tree topology within VPN. Each multicast capable PE router has only one multicast routing table which contains multicast topology within the shared backbone. P router may or may not be multicast capable. VPN Multicast requirements are defined as follows: 1. Transfer multicast traffic between multiple CE sites within a VPN in a bandwidth efficient manner. 2. Discover active sources in remote VPN sites. 3. Discover receivers for multicast group within directly connected sites. In order not to propagate the multicast tree topology from one customer site to another, an assumption is made that each CE act as a multicast border router within VPN. Multicast border router transfer VPN multicast packets between customer site and multicast domain created between CE devices [MBR]. 3.0 Shared Backbone Multicast capabilities The shared backbone may exhibit one of three possible behaviours: none multicast capability, support for multicast relay points, fully enabled multicast core. Support for multicast could be one or combination of Layer 3 (IP) and Layer 2 capabilities (e.g. ATM, MPLS). Characteristics of all three network behaviours are described in the following sections. The nature of multicast support within a shared backbone does not have any impact on VPN network multicast capabilities. The mapping function is used to determine how VPN multicast traffic is distributed to CE routers over shared backbone. This mapping defines the following: encapsulation type, set of PE routers to receive the packet, and information used to determine receiving CE router at the receiving PE router. Once the mapping functions are chosen and deployed, the shared backbone can migrate between the above multicast capabilities in a manner transparent to the VPN CEs. A. Celer [page 3] INTERNET DRAFT draft-celer-vpn-mcast-00.tx November 2000 3.1 Non-Multicast Capable Shared Backbone Network A non-multicast capable shared backbone network is defined as one that does not support any form of IP or Layer 2 multicast. Packets are replicated to every destination using unicast encapsulation with PE router address as destination. From a bandwidth utilization perspective, this is the least effective method of transmitting multicast packets across the shared backbone network. It can be argued that in this type of shared backbone network, packet replication may be performed on CE as well as on PE router. In case that replication is performed on CE, no mapping function is required, since CE sends packets over tunnels starting and terminating on CEs. In case that replication is performed on PE, mapping is required. The former option is not discussed in this draft, since shared backbone does not participate in any way in effectively transferring multicast packets; i.e. from shared backbone perspective, multicast packets are the same as unicast ones. Below is a list of assumptions/rules related to mapping values and shared backbone network behaviour of non-multicast capable shared backbone: 1. Mapping value uniquely identifies set of PE routers in shared backbone network. 2. In order to obtain mapping value from shared backbone for multicast address in VPN domain, CE router provides list of unicast addresses {U_1, U_2, ..., U_N} for PE routers directly connected to CE routers with receivers for . 3. Mapping value is transferred with the multicast packet from CE to PE router. 4. PE replicates packets by sending them to the unicast addresses {U_1, ..., U_N} assigned to another PEs 3.2 Multicast Relay Points Multicast Relay Points (MRP), in shared backbone network, act as multicast packet replicators. Assumption is made that multicast packets are sent over tunnels connecting MRPs since not all routers within shared backbone network are multicast capable. Deployment of MRPs is the simplest way to introduce multicast distribution trees in shared backbone. Below is a list of assumptions/rules related to mapping values and shared backbone network behaviour for a network with MRP capable routers: 1. Multicast Relay Point may be created on PE or P router 2. Mapping between CE and PE is defined in the same way as in case of non-multicast enabled shared backbone 3. There may be CE router present on multicast relay point device A. Celer [page 4] INTERNET DRAFT draft-celer-vpn-mcast-00.tx November 2000 4. Tree topology associated with multicast group is created by statically provisioning relay points and assigning unicast tunnels across network (if required), otherwise multicast addresses are used 5. MRP may replicate packet over unicast tunnels The procedure to dynamically setup relay points within shared backbone is to be determined. 3.3 Multicast Capable Shared Backbone Network Multicasting capability of the shared backbone network can be based on IP multicast support, or Layer 2 support. In multicast capable network, Service Provider creates multicast topology using any of the intra- or inter-domain multicast protocols. The choice of the multicast protocol(s) is based on complexity of network's topology. This architecture allows for the most efficient bandwidth utilization within a shared backbone. Below is a list of assumptions/rules related to mapping values and shared backbone network behaviour for multicast capable network: 1. Multicast routing protocol can be run within shared backbone 2. Mapping between CE and PE multicast addresses is the same as in MRP architecture 4.0 Address Mapping This section contains rules used to obtain mapping between multicast address from VPN domain to mapping value (IP address or mpls label) from shared backbone. Mapping value uniquely identifies set of PE routers in shared backbone. 1. Mapping value can be represented as IP multicast address from the shared backbone address space, in case of mapping to Layer 3 topology. 2. Mapping value can be represented as MPLS Label which identifies set of LSPs in case of Layer 2 topology. 3. In order to obtain mapping value for multicast address within VPN domain, CE router provides list of unicast addresses associated with PE routers which will be directly connected to CE routers with receivers for . 4. Some form of encapsulation to transfer packet within shared backbone is required 5. Mapping value can have local meaning to PE site replicating customer's packet A. Celer [page 5] INTERNET DRAFT draft-celer-vpn-mcast-00.tx November 2000 5.0 Interworking between VPN multicast domain and shared backbone multicast domain Overlapping VPN multicast topologies over shared backbone requires introduction of specific mapping rules. It is assumed that mapping may require encapsulation in case that Layer 3 to Layer 3 mapping is defined. Without encapsulation address translation is required. However the latter option will consume a number of addresses in shared backbone (multicast or unicast) proportional to the number of multicast group which can be carried across that network. In order to keep the number of addresses assigned to carry multicast traffic low, and reuse them to allow connectivity to separate VPNs, Layer 3 to Layer 3 mapping was proposed. 5.1 Mapping IP address to IP address On receiving multicast packet from VPN site, mapping value is requested by CE router from attached PE router. This value will be used deliver VPN multicast traffic to appropriate set of PE devices (routers). In mapping request, CE specifies addresses of PE devices. The following describes the protocol which allows to set-up multicast connectivity across shared backbone: 1. CE_1 establishes/discovers topology mapping between CE_2 and associated PE_2 assuming that each VPN site (CE_N) is uniquely mapped to PE 2. Topology mapping is defined as tuple: {VPNID, VPN site ID} and {PE_ID}. In one particular case, VPN Site may have public IP address from shared backbone associated with it. In this case this IP address may be associated with public address of PE device. 3. This mapping is distributed between all VPN CE devices using any available mechanism; i.e. static provisioning, autodiscovery. This mapping is also distributed between all PE devices associated with VPN. 4. CE router runs any appropriate multicast protocol between all CE sites to discover tree topology. 5. Each PE router builds the trees to connect a set of its peers, and assigns a multicast address to the tree. 6. After determining the set of CE sites interested in receiving traffic destined to a particular multicast group and creating the list of PE addresses associated with those CE sites, PE_1 is requested to provide the mapping value associated with the set of PE devices to which packet will be delivered. 7. If the PE tree was already created, the mapping value is returned, otherwise tree creation process is started. There is no assumption made on how the mapping value (e.g. multicast address shared bacbone) is assigned to particular set of PEs. Any mechanism can be used. 8. Mapping information is stored in Multicast Routing Table of CE for sending into shared backbone. A. Celer [page 6] INTERNET DRAFT draft-celer-vpn-mcast-00.tx November 2000 9. Mapping information is stored in PE Multicast Routing Table on receiving site to associate SA in outer header with the receiving CE. 10. On the receiving CE router assists PE router in setting multicast tree within shared backbone 11. Assumption is made that CE devices do not serve as multicast relay points within VPN space. They only forward from customer site to shared backbone, and from shared backbone to connected VPN site(s). Following is an example of distributing IP multicast packet from one VPN site across shared backbone to receivers in remote sites: 1. When CE receives packet destined to particular multicast address, it performs look-up in its multicast routing table to obtain forwarding information. This information contains a multicast address in shared backbone. Assuming IP in IP encapsulation, this IP multicast address is placed in DA, and CE public address is placed in SA. This address may be used to identify peer on the receiving side (PE-CE). 2. Once packet is transferred to PE for forwarding, a decision is made based on IP multicast address in outer IP header. 3. Based on tree structure (tree or broadcast, unicast with multicast relay points) packet is delivered to all identified PEs. 4. Since PE is the ultimate destination (receiver) for packet with multicast address in IP header, it will decapsulate IP packet and based on source IP address in the header will identify CE device. 5. CE device will process inner IP header, and identify distribution tree to forward packet to VPN site. 5.2 Mapping IP to layer 2 technology It is possible to map directly from Layer 3 (IP Multicast address in VPN domain) to Layer 2. In case of MPLS it would require at least two labels to provide the mapping. One label used for identifying CE device on the destination PE, and outer label to identify topology within MPLS core. Assuming that CE device does not replicate a packet but simply encapsulates it and forwards to attached PE device both labels need to be associated with IP Multicast address within VPN on CE. PE device, after it receives the packet analyzes outer most label and maps it to distribution tree. This tree may be one of three types: unicast branches to receivers, based on relay topology (assumes labels stacking is possible), or MPLS multicast tree. On the receiving PE, outermost label is removed and based on the next label CE is identified. On CE device, lookup on IP destination address is performed, and packet is replicated on appropriate interfaces to VPN site. IP multicast address can be mapped to ATM multicast topology. A. Celer [page 7] INTERNET DRAFT draft-celer-vpn-mcast-00.tx November 2000 6.0 Security associated with mapping There could be issues associated with preserving confidentiality of the mapping. Those issues are the same as for unicast traffic. In the next release of the draft more information will be included. 7.0 Scalability issues There is number of reasons why most of the multicast protocols do not scale. Some of the issues are related to the nature of the multicast routing protocols: 1. i.e. in case of 'flood-prune' model source based trees are used, so each intermediate router needs to store state information for 2. in case of core based trees; there is an overhead associated with control traffic, possibility to congest the core (all packets are first delivered to core), or ability to send over SPT trees Above reasons for scalability problems are internal to VPN multicast domain, as well to shared backbone multicast domain. They should be treated as separate issues to handle. The point on which the scalability issue arise is on device which stores mapping information. Each CE stores mapping of VPN to shared backbone Encapsulation info. The nature of that mapping in Many-to-Many; i.e. many VPN <*,G> map to the same encapsulation information. From CE perspective, all other CEs in the same VPN are just 'one-hop-away'. Each PE device stores (1) information associated with CE to demultiplex the traffic, and (2) mapping between information in outer-most encapsulation header to multicast tree. With proposed mapping (domain interworking), there is no need to build separate distribution trees to same PE devices for different VPNs. Proposed solution does not change address scalability in VPN and shared backbone characteristics. 8.0 Future work In this draft we attempted to present general framework for mapping between VPN multicast space and shared backbone multicast space. In following drafts, more work will be done to specify the following: * Security consideration * QoS mapping * Direct layer 3 to layer 2 mapping A. Celer [page 8] INTERNET DRAFT draft-celer-vpn-mcast-00.tx November 2000 9.0 References [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [VPN-CORE] Muthukrishnan, K., Malis, A., "Core MPLS IP VPN Architecture", Work in Progress [VPN-VR] Ould-Brahim, H., et al., "Network based IP VPN Architecture using Virtual Routers", work in progress, January 2001. [MBR], Cain B., "Connecting Multicast Domains", work in progress, August 2000 [VPN-RFC2547bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress. [VPN-RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [VPN-RFC2764] Gleeson, B., et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. 10.0 Intellectual Property Considerations Nortel Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Nortel Networks, Nortel intends to disclose those patents and license them on reasonable and non-discriminatory terms. 11.0 Author's address Alicja Celer Nortel Networks e-mail: aceler@nortelnetworks.com phone : 1-613-763-8146 A. Celer [page 9]