Network Working Group Eric C. Rosen (Editor)
Internet Draft Arjen Boers
Intended Status: Informational Yiqun Cai
Expires: May 9, 2008 IJsbrand Wijnands
Cisco Systems, Inc.
November 9, 2007
MVPN Profiles Using PIM Control Plane
draft-rosen-l3vpn-mvpn-profiles-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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The MVPN (Multicast Virtual Private Network) architecture, as
specified in [MVPN], is divided into a number of functional "layers".
At each layer, multiple options are allowed. It is necessary to
allow multiple options at each layer because "one size doesn't fit
all." However, it is not expected that any particular implementation
will support all the possible combinations of options. To ensure
multi-vendor interoperability, it is useful to specify "profiles",
where each profile is a particular combination of options. The
number of specified profiles will be much less than the total number
Rosen, et al. [Page 1]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
of possible combination, and a given implementation can be
characterized by saying which profiles it supports. This document
describes three profiles that use a PIM control plane.
Rosen, et al. [Page 2]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
Table of Contents
1 Introduction .......................................... 4
2 The PIM+GRE Profile ................................... 5
2.1 Auto-discovery ........................................ 5
2.2 MI-PMSI Instantiation ................................. 6
2.2.1 Source Specific Mode .................................. 6
2.2.2 Sparse Mode ........................................... 7
2.2.3 Bidir ................................................. 7
2.3 Distribution of C-Multicast Routing Information ....... 7
2.3.1 Legacy Issues ......................................... 7
2.4 Encapsulation ......................................... 8
2.5 S-PMSIs ............................................... 8
2.6 Inter-AS support ...................................... 8
2.7 Upstream Multicast Hop Determination .................. 9
2.8 Specification of Pre-Standard Fields .................. 9
2.8.1 Connector Attribute ................................... 9
2.8.2 MDT-SAFI .............................................. 10
2.9 The PIM MVPN Join Attribute ........................... 10
2.9.1 Definition ............................................ 10
2.9.2 Usage ................................................. 11
3 The PIM+MPLS/MP2MP Profile ............................ 12
3.1 Distribution of C-multicast routing information ....... 12
3.2 Auto-discovery ........................................ 12
3.3 MI-PMSI Instantiation ................................. 12
3.4 Encapsulation ......................................... 14
3.5 S-PMSIs ............................................... 14
3.6 Inter-AS Support ...................................... 14
3.7 Upstream Multicast Hop Determination .................. 15
3.8 Extensions of this Profile ............................ 15
4 The PIM+RSVP-TE Profile ............................... 15
4.1 Distribution of C-multicast routing information ....... 15
4.2 Auto-discovery ........................................ 16
4.3 MI-PMSI instantiation ................................. 16
4.4 Encapsulation ......................................... 16
4.5 S-PMSIs ............................................... 16
4.6 Inter-AS Support ...................................... 16
4.7 Upstream Multicast Hop Determination .................. 17
4.8 Extensions of this Profile ............................ 17
5 IANA Considerations ................................... 17
6 Security Considerations ............................... 17
7 Authors' Addresses .................................... 18
8 Normative References .................................. 18
9 Informative References ................................ 19
Rosen, et al. [Page 3]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
10 Full Copyright Statement .............................. 19
11 Intellectual Property ................................. 20
1. Introduction
The MVPN (Multicast Virtual Private Network) architecture, as
specified in [MVPN], allows Service Providers (SPs) to offer IP
multicast service over the sort of Virtual Private Networks (VPNs)
that are specified in [VPN]. The MVPN architecture contains a number
of functional layers, and at each layer, multiple options are
allowed.
For example, one of the "functional layers" is the control protocol
which a Provider Edge (PE) router uses to distribute Customer-
multicast (C-multicast) routing to other PE routers.Two options are
allowed for this: (a) PIM and (b) BGP. Several different variations
of PIM are accommodated by the architecture as well.
Another functional layer is the encapsulation which a PE router uses
to transmit a customer's multicast data to other PE routers. Both
MPLS and IP-based encapsulations are allowed by the architecture.
When MPLS encapsulation is used, transmission of user data is done
over Multipoint LSPs. There are however three very different kinds
of Multipoint LSPs that can be used. The LSPs can be MP2MP
(Multipoint-to-multipoint) LSPs set up by mLDP [MLDP], P2MP (Point-
to-Multipoint) LSPs set up by mLDP, or P2MP LSPs set up by RSVP-TE
[MP-RSVP-TE].
Although the architecture allows any option at one layer to be used
with any option at another, it is not expected that any given
implementation will actually support the full set of options at each
layer, and in fact not all arbitrary combinations of options are
sensible. It is useful therefore to describe a set of MVPN
"Profiles", where each profile contains a single option at each
layer. Implementations can then be characterized by the set of
profiles they support.
The intention is that each profile be fully conformant to the [MVPN]
standard. In one case, however, there are deployments of "pre-
standards" versions of a profile. This document specifies just how
the pre-standard version differs from the standard version, in enough
detail to allow interoperability with the pre-standards version.
Rosen, et al. [Page 4]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
The profiles are described in the terminology of [MVPN], which is
presupposed by this document.
At the present time, all existing deployments of MVPN are based on
the "PIM+GRE" profile (most precisely, on a pre-standards version of
that profile). The use of PIM for distributing C-multicast routes
has thus been proven in deployment. Issues have been raised about
whether this will be adequate in the future if MVPN deployments
greatly increase in scale. However, the alternative of using BGP for
distributing C-multicast routes has not been proven in deployment,
and the authors believe that there are a number of scaling issues and
functional issues with that alternative that are not yet fully
understood. Until those are better understood, it does not seem
prudent to migrate quickly from PIM to BGP for distributing C-
multicast routes. The authors also believe that the ability to
deploy MPLS encapsulation for multicast VPN traffic should not be
gated by the need to deploy BGP as the C-multicast routing control
plane.
Therefore we specify in this document the "PIM+GRE Profile", in its
pre-standard (but deployed today) and in its standard forms, as well
as two "PIM+MPLS" profiles.
2. The PIM+GRE Profile
The PIM+GRE Profile corresponds closely to the "pre-standards" MVPN
deployments from Cisco Systems, that have existed for many years.
2.1. Auto-discovery
Auto-discovery is done by means of BGP, using the Intra-AS A-D routes
described in section 4 of [MVPN] and sections 4.1 and 8.1 of [MVPN-
BGP]. Each PE attached to a particular MPVN is configured with a PIM
group address for that MVPN. The group address with which a given PE
is configured is carried in the PMSI Tunnel Attribute (see [MVPN]
section 4 and [MVPN-BGP] section 5) of the Intra-AS A-D route
originated by that PE. This PIM group address is used to create the
P-tunnels that instantiate the MVPN's MI-PMSI (see section 2.2).
There are deployments based on pre-standard implementations which use
a type of route known as "MDT-SAFI" for this purpose, rather than
using the intra-AS A-D routes. The intra-AS A-D routes which are
specified in [MVPN] and [MVPN-BGP] are a generalization of the "pre-
standard" MDT-SAFI. The generalization was necessary in order to
allow the use of non-PIM P-tunnels (e.g., multipoint LSPs) in other
profiles. Also, the intra-AS AD routes, unlike the MDT-SAFI, carry
Rosen, et al. [Page 5]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
Route Targets, and so may be distributed inter-AS in the same manner
as unicast routes. (Inter-AS distribution of "intra-AS A-D routes"
is necessary in some cases, see below.)
The specification of the legacy MDT-SAFI route is given in section
2.8.2.
Note that there are some legacy implementations that do not provide
BGP-based auto-discovery. Those implementations are restricted to
the use of PIM-SM as the sole means of instantiating P-tunnels (see
next section), and those implementations cannot provide any support
for inter-AS VPNs that are constructed according to option b of
section 10 of [VPN].
2.2. MI-PMSI Instantiation
In the PIM+GRE profile, the PEs attached to a given MVPN are
connected via an MI-PMSI (see [MVPN] sections 3.3.1 and 3.3.2). MI-
PMSIs are instantiated as multicast distribution trees ("P-tunnels"
in the language of [MVPN}) constructed by means of PIM. Source
Specific Mode (SSM), Sparse Mode (SM), and Bidirectional Mode (BIDIR)
are all supported. The Intra-AS A-D route (or, in legacy
deployments, the MDT-SAFI routes) sent by each PE specify the MVPN
PIM group address. Other PEs use PIM to join the specified group,
thereby creating the P-tunnels. The P-tunnels are thus created
automatically as a result of the auto-discovery process.
This profile does NOT support aggregation of multiple VPNs onto a
single set of P-tunnels.
Note that if the group address G used for the P-tunnels is a sparse
mode group or a bidirectional group, the BGP-based auto-discovery
process is not strictly needed; each PE can join the requisite set of
P tunnels just by joining the (*,G) tree. However, for consistency,
the auto-discovery process always take place, no matter whether the
PIM group address is a "sparse mode" address, a "source specific
mode" address, or a "bidirectional mode" address. (But see the note
about some legacy implementations at the end of the previous
section.)
2.2.1. Source Specific Mode
Consider the set of PEs that support a given MVPN. Each <PE, MVPN>
pair is associated with a source specific mode PIM group address. If
the set of PEs supporting the given MVPN is PE1, ..., PEn, and the
corresponding set of group addresses is G1, ..., Gn, then PEk joins
Rosen, et al. [Page 6]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
each <PEi, Gi> source tree for which 1 <= i <= n and i != k. That
is, the MI-PMSI is instantiated as a "full mesh" (i.e., containing
all the PEs attached to the MVPN) of source trees. The normal PIM
procedures specified in [PIM-SM] are used.
There are pre-standard implementations that require the same SSM
group address to be assigned to all the PEs. Interoperability with
those implementations requires conformance to this restriction.
2.2.2. Sparse Mode
Each MVPN is associated with a sparse mode PIM group address. Each PE
attached to the MVPN joins the group, using the PIM sparse mode
procedures. If there are n PEs, the MI-PMSI is thus instantiated as
a shared tree plus a set of up to n source trees. The normal PIM
procedures specified in [PIM-SM] are used.
2.2.3. Bidir
Each MVPN is associated with a bidirectional mode PIM group address.
Each PE attached to the MVPN joins the group, using the BIDIR-PIM
procedures. If there are n PEs, the MI-PMSI is thus instantiated as
a shared tree plus a set of up to n source trees. The procedures for
setting up a BIDIR-PIM tree are specified in [PIM-BIDIR].
2.3. Distribution of C-Multicast Routing Information
An MI-PMSI is automatically created, containing all the PEs belonging
to a VPN. C-multicast routing information is distributed by running
PIM over the MI-PMSI, using standard PIM LAN procedures. See
sections 3.4.1.1, 5.1, and 5.2 of [MVPN].
2.3.1. Legacy Issues
Section 5.1.2 [MVPN} specifies:
Every route which is eligible for UMH (Upstream Multicast Hop)
selection MUST carry a VRF Route Import Extended Community [MVPN-
BGP]. This attribute identifies the PE that originated the
route.
Pre-standards deployments of the PIM+GRE profile do not use the "VRF
Route Import Extended Community" attribute, but instead use the
"Connector" attribute to identify the PE that originated a route.
Rosen, et al. [Page 7]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
The specification of the connector attribute as used for this purpose
is given in section 2.8.1.
2.4. Encapsulation
All C-multicast data messages, and all C-PIM messages (i.e., PIM
messages carrying C-multicast routing information) are encapsulated
in GRE [GRE], precisely as specified in section 11.1.1 of the [MVPN].
2.5. S-PMSIs
This profile supports non-aggregated S-PMSIs, where each S-PMSI is
instantiated as a PIM source tree in SSM mode.
The assignment of a particular C-multicast data stream to a
particular S-PMSI is done via the protocol specified in section 7.2.1
of [MVPN].
2.6. Inter-AS support
Inter-AS support is provided via the non-segmented inter-as tunnels
described in section 8.1 of [MVPN]. Intra-AS AD routes must be
distributed across AS boundaries.
To set up the inter-AS P-tunnels instantiating a PMSI, it is
necessary for a PE in one AS to send PIM control messages which
identify PEs in other ASes. In order to construct the multicast
distribution trees, P routers processing these messages need to
determine the (IGP) route to the identified PE router. However, in
inter-AS VPNs constructed according to option b of section 10 of RFC
4364, a given AS does not necessarily have routes to PEs in the other
ASes. Therefore, the PIM messages contain the "PIM MVPN Join
Attribute". This allows the multicast distribution tree to be
properly constructed even if routes to PEs in other ASes do not exist
in the given AS's IGP, and even if the routes to those PEs do not
exist in BGP. The use of an PIM MVPN Join Attribute in the PIM
messages allows the inter-AS trees to be built. The basic format of
a PIM Join Attribute is specified in [PIM-ATTRIB]. The details of
the PIM MVPN Join Attribute are specified in section 2.9.
Rosen, et al. [Page 8]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
2.7. Upstream Multicast Hop Determination
According to section 5 of [MVPN], where the selected UMH route is the
installed UMH route. The procedures of section 5 for single
forwarder selection are not applied. However, since PIM LAN
procedures are run over the MI-PMSI, the standard PIM "Assert" will
result in a single choice of forwarder. Packet duplication is
possible during the Assert convergence period.
Section 5.1.2 of [MVPN] requires each unicast route that is a
potential UMH route to carry a VRF Route Import Extended Community.
In pre-standards implementations, this attribute may be absent, in
which case the backwards compatibility procedures of section 5.2.3
apply. Some pre-standards implementation may use a non-standard
"connector attribute" instead of the VRF Route Import Extended
Community.
Because Assert processing is done, a given source will end up having
a single PE as forwarder. Load balancing is possible within that
constraint. That is, if S1 and S2 are two different sources, and
each source has both PE1 and PE2 as an eligible UMH, and if PE3 needs
to join the C-trees (S1, G1) and (S2, G2), a form of load balancing
can be providing by having PE3 join (S1, G1) via PE1 but having it
join (S2, G2) via PE2. As long as every PE uses the same UMH for a
given source, Assert processing about that source does not get
invoked.
2.8. Specification of Pre-Standard Fields
2.8.1. Connector Attribute
The Connector Attribute is an optional transitive attribute. It is
formatted as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv4 Address of PE |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rosen, et al. [Page 9]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
2.8.2. MDT-SAFI
BGP messages in which AFI=1 and SAFI=66 are "MDT-SAFI" messages.
The NLRI format is 8-byte-RD:IPv4-address followed by the MDT group
address. i.e. The MP_REACH attribute for this SAFI will contain one
or more tuples of the following form :
+-------------------------------+
| |
| RD:IPv4-address (12 octets) |
| |
+-------------------------------+
| Group Address (4 octets) |
+-------------------------------+
The IPv4 address identifies the PE that originated this route, and the
RD identifies a VRF in that PE. The group address must be a multicast
group address, and is used to build the P-tunnels. All PEs attached to
a given MVPN must specify the same group-address, even if the group is
an SSM group. MDT-SAFI routes do not carry RTs, and the group address
is used to associated a received MDT-SAFI route with a VRF.
2.9. The PIM MVPN Join Attribute
2.9.1. Definition
In [PIM-ATTRIB], the notion of a "join attribute" is defined, and a
format for included join attributes in PIM Join/Prune messages is
specified. We now define a new join attribute, which we call the
"MVPN Join Attribute".
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 | Proxy IP address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
The Type field of the MVPN Join Attribute is set to 1.
Rosen, et al. [Page 10]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
The F bit is set to 0.
Two information fields are carried in the MVPN Join attribute:
- Proxy: The IP address of the node towards which the PIM Join/Prune
message is to be forwarded. This will either be an IPv4 or an IPv6
address, depending on whether the PIM Join/Prune message itself is
IPv4 or IPv6.
- RD: An eight-byte RD. This immediately follows the proxy IP
address.
The PIM message also carries the address of the upstream PE.
In the case of an intra-AS MVPN, the proxy and the upstream PE are the
same. In the case of an inter-AS MVPN, proxy will be the ASBR which is
the exit point from the local AS on the path to the upstream PE.
2.9.2. Usage
When a PE router creates a PIM Join/Prune message in order to set up
an inter-AS I-PMSI, it does so as a result of having received a
particular Intra-AS A-D route. It includes an MVPN Join attribute
whose fields are set as follows:
- If the upstream PE is in the same AS as the local PE, then the
proxy field contains the address of the upstream PE. Otherwise,
it contains the address of the BGP next hop on the route to the
upstream PE.
- The Rd field contains the RD from the NLRI of the Intra-AS A-D
route.
- The upstream PE field contains the address of the PE that
originated the Intra-AS A-D route (obtained from the NLRI of that
route).
When a PIM router processes a PIM Join/Prune message with an MVPN
Join Attribute, it first checks to see if the proxy field contains
one of its own addresses.
If not, the router uses the proxy IP address in order to determine
the RPF interface and neighbor. The MVPN Join Attribute must be
passed upstream, unchanged.
If the proxy address is one of the router's own IP addresses, then
the router looks in its BGP routing table for an Intra-AS A-D route
Rosen, et al. [Page 11]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
whose NLRI consists of the upstream PE address prepended with the RD
from the Join attribute. If there is no match, the PIM message is
discarded. If there is a match the IP address from the BGP next hop
field of the matching route is used in order to determine the RPF
interface and neighbor. When the PIM Join/Prune is forwarded
upstream, the proxy field is replaced with the address of the BGP
next hop, and the RD and upstream PE fields are left unchanged.
3. The PIM+MPLS/MP2MP Profile
In this profile, as in the PIM+GRE profile, the PEs use PIM to convey
multicast routing information to each other. However, PIM is not
used to instantiate the P-tunnels. Rather, mLDP is used to create
Multipoint-to-multipoint (MP2MP, or bidirectional) P-tunnels.
3.1. Distribution of C-multicast routing information
An MI-PMSI is automatically created, containing all the PEs belonging
to a VPN. C-multicast routing information is distributed by running
PIM over the MI-PMSI.
3.2. Auto-discovery
Auto-discovery is done by means of BGP, using the Intra-AS A-D routes
described in section 4 of [MVPN]. Each PE attached to a particular
MPVN is configured with an mLDP FEC (Forwarding Equivalence Class)
value. The mLDP FEC value with which a given PE is configured is
carried in the PMSI Tunnel Attribute of the Intra-AS A-D route
originated by that PE. This mLDP FEC value is used to create the P-
tunnels that instantiate the MVPN's MI-PMSI (see below.)
If the PEs are not all within the same AS, the "inter-AS A-D routes"
must be distributed across AS boundaries.
3.3. MI-PMSI Instantiation
The PEs attached to a given MVPN are connected via an MI-PMSI. MI-
PMSIs are instantiated as MP2MP LSPs created by mLDP. The Intra-AS
A-D route sent by each PE in the MVPN specifies a FEC value. If PE1
distributes the FEC value F, other PEs in the MVPN can then use mLDP
to join a MP2MP LSP whose root is PE1 and whose FEC value is F.
However, a given PE, say PE2, does not join the MP2MP LSP whose root
is PE1 unless PE2 actually needs to send PIM control traffic PE1.
Rosen, et al. [Page 12]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
More precisely, at any given time, PE2 SHOULD be a member of the
MP2MP LSP whose root is PE1 IF AND ONLY IF, at that time, PE2 is
maintaining state for some (C-S, C-G) or (C-*, C-G) tree for which
PE2 has selected PE1 as the upstream multicast hop (see section 5.1
of [MVPN]).
The number of P-tunnels needed to instantiate the MI-PMSI for a given
MVPN is thus equal to the number of PEs that serve as ingress PEs for
some multicast transmitter of that MVPN. In an MVPN which has its
multicast transmitters at a single site, only one P-tunnel would be
required. The number of P-tunnels used to instantiate the MI-PMSI
may also change from time to time, as needed.
Since the LSPs instantiating the MI-PMSI are MP2MP, any PE can
transmit to any of those LSPs. However, there are precise rules for
which of the LSPs a given PE uses to transmit a given message.
When a PE needs to send a PIM Hello on the MI-PMSI, it sends it on
the LSP for which it is the root.
When a PE needs to send a PIM Join/Prune on the MI-PMSI, it sends it
on the LSP whose root is the PE to which the Join/Prune is directed.
When a PE receives multicast data from a CE, it may need to forward
that data to the MI-PMSI. If the data belongs to an SM or SSM group,
the PE sends the data on the LSP for which it is the root. When a PE
receives SM or SSM data on one of the LSPs, it discards the data
(without PIM processing) if the root of the LSP on which the data was
received is not the PE from which the data was expected.
If a PE needs to send data belonging to a Bidirectional PIM group to
the MI-PMSI, it does so using the procedures specified in [MVPN]
section 12.2.3. The procedures specified therein also detail the
conditions under which a PE must discard data from a bidirectional
group when that data is received on the MI-PMSI.
Since data arriving from an unexpected PE is always discarded, Assert
processing will never occur. Since Assert processing does not occur,
"single forwarder selection" need not be used (see sections 9 and 5.1
of [MVPN]). That is, PE1 can receive, e.g., (S,G) traffic from PE2
while PE3 receives (S,G) traffic from PE4. This enables the use of
enhanced load balancing procedures when compared to the PIM+GRE
profile. Also, unlike the PIM+GRE profile, this profile can support
the use of anycast source address (e.g., anycast-RP).
The Join Suppression and Prune Override procedures still operate as
they normally do on LANs.
Rosen, et al. [Page 13]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
3.4. Encapsulation
The encapsulation specified in [MVPN] section 11.1.3 is used. (See
also [MPLS-MCAST-ENCAPS]). Aggregation of multiple VPNs onto a
single set of P-tunnels is not supported.
3.5. S-PMSIs
This profile supports S-PMSIs, where each S-PMSI is instantiated as a
instantiated as an mLDP-created P2MP or MP2MP LSP.
P2MP LSPs are used for carrying traffic from Sparse Mode or Source
Specific Mode streams. MP2MP LSPs are used for carrying traffic from
BIDIR trees.
Multiple data streams can be aggregated on a single MP2MP LSP, but
data streams from different VPNs cannot be so aggregated.
The assignment of a particular C-multicast data stream to a
particular S-PMSI is done via the protocol specified in section 7.2.1
of [MVPN]. The protocol will be suitably extended so that it can
identify an mLDP-created MP2MP LSP.
3.6. Inter-AS Support
Inter-AS support is provided via the non-segmented inter-as tunnels
described in section 8.1 of [MVPN]. Intra-AS AD routes must be
distributed across AS boundaries.
To set up the inter-AS P-tunnels instantiating a PMSI, it is
necessary for a PE to send mLDP control messages which identify PEs
in other ASes. In order to construct the multicast distribution
trees, P routers processing these messages need to determine the
(IGP) route to the identified PE router. However, In inter-AS VPNs
constructed according to option b of section 10 of RFC 4364, a given
AS does not necessarily have routes to PEs in the other ASes.
Therefore, the mLDP messages will be extended along the lines of the
"PIM MVPN Join Attribute" discussed in section 2.9. This allows the
multicast distribution tree to be properly constructed even if routes
to PEs in other ASes do not exist in the given AS's IGP, and even if
the routes to those PEs do not exist in BGP.
Rosen, et al. [Page 14]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
3.7. Upstream Multicast Hop Determination
Upstream multicast hop determination in the PIM+MPLS/MP2MP profile is
as specified in section 5 of [MVPN].
3.8. Extensions of this Profile
This profile may be extended in the future to add the following
options:
1. Aggregation of traffic from multiple VPNs onto a single S-PMSI.
This requires support for MPLS upstream-assigned labels [MPLS-
UPSTREAM-LABEL].
2. Support for Segmented Inter-AS P-Tunnels, as described in
section 8.2 of [MVPN]. This will require support for the
"Inter-AS A-D Routes" described in section 8.2.1 of [MVPN].
3. The use of RSVP-TE P2MP LSPs for instantiating S-PMSIs carrying
Sparse Mode or Source Specific Mode traffic. (With support of
MPLS upstream-assigned labels, BIDIR-PIM traffic from the
customer could also be carried.)
4. The PIM+RSVP-TE Profile
In this profile, the PEs use unicast PIM ([MVPN], section 3.4.1.3) to
convey multicast routing information to each other. Data traffic is
always sent over an S-PMSI which is instantiated as an RSVP-TE P2MP
LSP.
The description of this profile is more preliminary than the
description of the previous two profiles.
4.1. Distribution of C-multicast routing information
As in [MVPN], section 3.4.1.3.
Rosen, et al. [Page 15]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
4.2. Auto-discovery
As in section 3.2, or alternative, 2.1.
4.3. MI-PMSI instantiation
No MI-PMSI is used.
4.4. Encapsulation
The encapsulation specified in [MVPN] section 11.1.3 is used.
Aggregation of multiple VPNs onto a single set of P-tunnels is not
supported.
4.5. S-PMSIs
This profile supports S-PMSIs, where each S-PMSI is instantiated as
an RSVP-TE P2MP LSP. All data is sent on an S-PMSI. Multiple
customer data streams may travel on the same S-PMSI, but traffic from
two different VPNs may not travel on the same S-PMSI.
The assignment of a particular C-multicast data stream to a
particular S-PMSI is done via the protocol specified in section 7.2.1
of [MVPN], suitably extended to allow the control messages to refer
to an RSVP-TE P2MP LSP.
4.6. Inter-AS Support
Inter-AS support is provided via the non-segmented inter-as tunnels
described in section 8.1 of [MVPN]. Intra-AS AD routes must be
distributed across AS boundaries.
To set up the inter-AS P-tunnels instantiating a PMSI, it is
necessary for a PE to send RSVP-TE control messages which identify
PEs in other ASes. In order to construct the multicast distribution
trees, P routers processing these messages need to determine the
(IGP) route to the identified PE router. However, In inter-AS VPNs
constructed according to option b of section 10 of RFC 4364, a given
AS does not necessarily have routes to PEs in the other ASes.
Therefore, the RSVP-TE messages will be extended along the lines of
the "PIM MVPN Join Attribute" discussed in section 2.9. This allows
the multicast distribution tree to be properly constructed even if
routes to PEs in other ASes do not exist in the given AS's IGP, and
Rosen, et al. [Page 16]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
even if the routes to those PEs do not exist in BGP.
4.7. Upstream Multicast Hop Determination
Upstream multicast hop determination in the PIM+RSVP-TE profile is as
specified in section 5 of [MVPN].
4.8. Extensions of this Profile
This profile may be extended in the future to add the following
options:
1. Aggregation of traffic from multiple VPNs onto a single S-PMSI.
This requires support for MPLS upstream-assigned labels [MPLS-
UPSTREAM-LABEL].
2. Support for Segmented Inter-AS P-Tunnels, as described in
section 8.2 of [MVPN]. This will require support for the
"Inter-AS A-D Routes" described in section 8.2.1 of [MVPN].
5. IANA Considerations
To be supplied.
6. Security Considerations
[VPN] discusses in general the security considerations that pertain
to when the RFC4364 type of VPN is deployed.
[PIM-SM] discusses the security considerations that pertain to the
use of PIM.
[MLDP] discusses the security considerations that pertain to the use
of LDP.
When the PIM+GRE profile is used, the security considerations of
[MPLS-in-GRE] and [VPN-GRE] also apply. However, the use of IPsec
does not apply, as there are no established procedures for using
IPsec to protect multicast traffic.
Rosen, et al. [Page 17]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
7. Authors' Addresses
Arjen Boers
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
E-mail: aboers@cisco.com
Yiqun Cai
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
E-mail: ycai@cisco.com
Eric C. Rosen (Editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
E-mail: erosen@cisco.com
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
E-mail: ice@cisco.com
8. Normative References
[GRE] RFC 2784, D. Farinacci, et. al., "Generic Routing
Encapsulation", March 2000
[MLDP] "LDP Extensions for P2MP and MP2MP LSPs", I. Minei, IJ.
Wijnands, draft-ietf-mpls-ldp-p2mp-03.txt, July 2007
[MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter,
"MPLS Multicast Encapsulations", draft-ietf-mpls-multicast-
encaps-07.txt, November 2007
[MPLS-UPSTREAM-LABEL] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS
Rosen, et al. [Page 18]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
Upstream Label Assignment and Context Specific Label Space", draft-
ietf-mpls-upstream-label-02.txt, March 2007
[MVPN] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP IP
VPNs", draft-ietf-l3vpn-2547bis-mcast-05.txt, July 2007
[MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C. Kodeboniya,
draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt, July 2007
[PIM-ATTRIB] A. Boers, IJ. Wijnands, E. Rosen, "Format for Using TLVs
in PIM Messages", draft-ietf-pim-join-attributes-03, May 2007
[PIM-BIDIR] RFC 5015, "Bidirectional Protocol Independent Multicast
(BIDIR-PIM)", M. Handley, I. Kouvelas, T. Speakman, L. Vicisano,
October 2007
[PIM-SM] RFC 4601 "Protocol Independent Multicast - Sparse Mode (PIM-
SM)", Fenner, Handley, Holbrook, Kouvelas, August 2006
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
[VPN] RFC 4364, "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February
2006
9. Informative References
[MP-RSVP-TE] RFC 4875, "Extensions to RSVP-TE P2MP TE LSPs" R.
Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. May 2007
[MPLS-in-GRE] RFC 4023, "Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", T. Worster, Y. Rekhter, E. Rosen, March 2005
[VPN-GRE] RFC 4797, "Use of PE-PE GRE or IP in BGP/MPLS IP VPNs", Y.
Rekhter, R. Bonica, E. Rosen, January 2007
10. 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
Rosen, et al. [Page 19]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007
"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.
11. Intellectual Property
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.
Rosen, et al. [Page 20]