Internet Draft
INTERNET DRAFT Alicja Celer
expiration date: June 2001 Nortel Networks
Interworking between IP VPN and shared backbone multicast domains
<draft-celer-vpn-mcast-00.txt>
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]