A Simple Method for Segmenting Multicast Tunnels for Multicast VPNs
draft-rosen-l3vpn-mvpn-segments-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Maria Napierala , Eric C. Rosen | ||
| Last updated | 2012-04-20 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rosen-l3vpn-mvpn-segments-03
L3VPN Working Group Maria Napierala
Internet Draft AT&T
Intended Status: Proposed Standard
Expires: October 20, 2012 Eric C. Rosen
IJsbrands Wijnands
Cisco Systems, Inc.
April 20, 2012
A Simple Method for Segmenting Multicast Tunnels for Multicast VPNs
draft-rosen-l3vpn-mvpn-segments-03.txt
Abstract
To provide Multicast VPN (MVPN) Service, Service Providers (SPs) need
to instantiate multicast tunnels (known as "P-tunnels") that enable
the Provider Edge (PE) routers of a given VPN to transmit multicast
packets to each other. Some SPs organize their networks in a
hierarchical manner, with the PE routers in "edge areas", and the
edge areas connected to each other via a "core area". A P-tunnel that
connects PE routers in different edge areas can be thought of as
having three segments: a segment through one edge area, a segment
through the core area, and a segment through the second edge area.
It is desirable to preserve the independence of the core area by
allowing it to use a different tunneling technology than that used in
the edge areas. However, it is not desirable for the core area
Border Routers (BRs) to participate in the MVPN-specific signaling,
or even to have any knowledge of which MVPNs are in the edge areas
that attach to it. This document specifies a simple method for
segmenting MVPN P-tunnels at the BRs, subject to these constraints.
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
Napierala, et al. [Page 1]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Napierala, et al. [Page 2]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
Table of Contents
1 Introduction .......................................... 4
1.1 Specification of requirements ......................... 4
1.2 MVPN through Core and Edge Areas ...................... 4
2 Procedures ............................................ 7
2.1 Choosing the Upstream BR .............................. 7
2.2 When the P-tunnel uses mLDP in the Edge Areas ......... 8
2.3 When the P-tunnel uses PIM in the Edge Areas .......... 9
2.3.1 Source-Specific Trees ................................. 9
2.3.2 Shared Trees when the BR is not the RP ................ 9
2.3.3 Shared Trees when each BR is an RP .................... 9
3 Aggregation Strategies ................................ 10
4 Preventing Aggregation ................................ 10
4.1 mLDP P-Tunnels ........................................ 11
4.2 PIM P-Tunnels ......................................... 11
5 IANA Considerations ................................... 12
6 Security Considerations ............................... 12
7 Acknowledgments ....................................... 12
8 Authors' Addresses .................................... 13
9 Normative References .................................. 13
10 Informational References .............................. 14
Napierala, et al. [Page 3]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
1. Introduction
1.1. Specification of requirements
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 [RFC2119].
1.2. MVPN through Core and Edge Areas
Consider a Service Provider (SP) network that consists of a number of
"edge areas", along with a "core area". Each edge area contains some
number of Provider Edge (PE) routers. At the boundary of the "core
area" are "Border Routers" (BRs). Each BR has a number of "edge-
facing" interfaces that lead into edge areas, and a number of "core-
facing" interfaces that lead to the core. Any data packet that needs
to travel from one edge area to another must traverse the core (going
through at least one BR) to do so.
We assume that some set of PEs are offering Multicast Virtual Private
Network (MVPN) service according to [MVPN]. This requires the PEs of
a given VPN to create one or more multicast tunnels through the SP
network ("P-tunnels"). Each such tunnel will have a single "root PE"
and a number of "leaf PEs". Any P-tunnel that has a leaf PE that is
in a different edge area than the root PE will have to traverse the
core area, passing through one or more BRs.
When a P-tunnel traverses one or more BRs, one of them is the ingress
BR and one is the egress BR. The procedures of this document are
applicable whenever the egress BR for a particular P-tunnel can
determine the identity of the ingress BR for that P-tunnel. This
will be the case if (though not necessarily only if) at least one of
the following two conditions holds:
- The BRs use BGP to distribute to each other the routes to the PE
routers. (We do not assume that the core area is in a different
Autonomous System (AS) than the edge areas; this may or may not
be the case.)
- The BRs are fully meshed by a set of point-to-point RSVP-TE
tunnels.
That is, the procedures of this document are applicable whenever the
procedures of [TMLDP] section 1.3 ("Targeted mLDP and the Upstream
LSR") can be applied. Even if neither of the two conditions above
holds, there may be other methods that an egress BR can use to
determine the identity of the egress BR. This document does not
Napierala, et al. [Page 4]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
place any restrictions on the method used.
There are a number of different multicast tunneling technologies that
the PEs can use for setting up the P-tunnels. The tunneling
technology need not be the same in the core area as in the edge area,
and the tunneling technology need not be the same in both edge areas.
In this document, we focus on two particular edge area technologies:
PIM [PIM-SM] and Multipoint LDP (mLDP) [mLDP]. Generalization to the
use of other P-tunnel technologies in the edge areas is
straightforward. It is even possible to use unicast replication,
rather than a true multicast tunneling technology. Furthermore, if
the core area does use multicast tunnels, it can aggregate a number
of P-tunnels from the edge areas into a single tunnel through the
core. In this case, a set of P-tunnels are aggregated upon entry
into the core, and deaggregated upon exit from the core.
Let us consider the following topology:
PE1 --- Edge Area 1 --- BR1 ---------- BR3 --- Edge Area 3 --- PE3
| |
PE2 -------| |
Core Area
|
|----- BR4 --- Edge Area 4 --- PE4
Suppose there is some MVPN to which PE1, ..., PE4 are attached.
Suppose that there are two P-tunnels for that MVPN. Tunnel T1 is
rooted at PE1 and has PE3 as a leaf. Tunnel T2 is rooted at PE2 and
has both PE3 and PE4 as leaf nodes.
If no segmentation is done, the creation of tunnel T1 begins at PE3
with PIM or mLDP signaling. This signaling passes along through edge
area 3 to BR3, and passes through the core to BR1. "Passing through
the core" means passing through each intermediate core router on the
path from BR3 to BR1. The signaling then passes through edge area 1
to PE1.
If segmentation is done, the creation of tunnel T1 begins in exactly
the same way, at PE3, and passes through Edge Area 3 to BR3 in
exactly the same manner. However, the signaling through the core is
different. No signaling passes through the intermediate nodes in the
core area. Rather, BR3 does mLDP signaling over a Targeted LDP
Session to BR1 [TMLDP]. BR3 passes enough information in this
Targeted mLDP signaling to enable BR1 to reinitiate the necessary PIM
Napierala, et al. [Page 5]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
or mLDP signaling in Edge Area 1. Within the core area, the Border
Routers decide what sort of tunneling technology to use, and the core
tunneling technology is transparent to the PEs and to any other
systems in the edge areas.
The BRs may, for example, decide to use Unicast Replication. In this
case, when BR1 receives, from Edge Area 1, a packet traveling on the
Area 1 segment of tunnel T1, it encapsulates it and unicasts it to
BR3. The encapsulation carries enough information to inform BR3 that
the packet needs to be put on the Area 3 segment of tunnel T1. If
BR1 receives, from Edge Area 1, a packet traveling on the Area 1
segment of T2, BR1 makes two copies of the packet, encapsulates each,
and then unicasts one copy to BR3 and one copy to BR4. Based on
information carried in the encapsulation, BR3 and BR4 each know that
the packet must be forwarded on the segment of T2 in their respective
Edge Areas.
Alternatively, the BRs may decide to aggregate T1 and T2 into a
single core multicast tunnel. Suppose, for example, that there is an
RSVP-TE P2MP LSP whose head-end is BR1, and that has BR3 and BR4 as
leaf nodes. Then when BR1 receives, from Edge Area 1, a packet
traveling on tunnel T1, it encapsulates it and sends it through this
core tunnel. When BR1 receives, from Edge Area 1, a packet traveling
on P-tunnel T2, it again encapsulates it and sends it through this
same core tunnel. Both packets will be received by BR3 and BR4. The
packet traveling on P-tunnel T2 will be forwarded by BR3 and BR4 on
the Edge Area 3 and Edge Area 4 segments of T2 respectively. The
packet traveling on P-tunnel T1 will be forwarded by BR3 on the Edge
Area 3 segment of T1. However, BR4 will drop that packet, because
BR4 there is no Edge Area 4 segment of T1. Naturally, the
encapsulation used by the head-end of the core tunnel must enable the
leaf nodes of the core tunnel to determine whether a given packet is
traveling on a P-tunnel that passes through that leaf node, and if
so, which P-tunnel.
It is worth noting that in the following topology:
Napierala, et al. [Page 6]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
PE1 --- Edge Area 1 --- BR1 --------- BR3 --- Edge Area 3 --- PE3
| | |
PE2 -------| | |
|--- BR2 --- Core
|
|---- BR4 --- Edge Area 4 --- PE4
|
|---- BR5 --- Edge Area 5 --- PE5
it is possible to combine unicast replication by the PEs with unicast
replication by the BRs. For instance, if PE2 has a multicast packet
to be sent to PE4 and PE5, it is possible for PE2 to unicast one copy
of the packet to BR2 and then for BR2 to unicast a copy to BR4 and a
copy to B5. This can be done if the PEs have Targeted LDP sessions
to the BRs, and the BRs have Targeted LDP sessions to each other.
This is a straightforward generalization of the procedures described
in section 2.1 below.
2. Procedures
The Border Routers of the core area must know that they are core area
Border Routers. This is known either by provisioning, or by some
other method that is outside the scope of this document.
2.1. Choosing the Upstream BR
It is assumed that the Border Routers have routes to the PE routers.
It is also assumed that the procedures of [TMLDP] section 1.3
("Targeted mLDP and the Upstream LSR") can be applied. Suppose, for
example, that the path from a given PE, PE1, and a second PE, PE2,
enters the core through BR1 and exits the core through BR2. Then BR1
is to consider BR2 to be the "upstream BR" on its path to PE2. The
procedures used to select the "upstream BR" for a particular PE may
be one of the following:
- If BR1 finds that its route to PE1 is a BGP-distributed route
whose next hop is another BR, say BR2, then BR2 may be considered
to be the "upstream BR".
- If the core contains a full mesh of RSVP-TE P2P tunnels among the
BRs, and if BR1's "next hop interface" to PE1 is a tunnel leading
to BR2, then BR2 may be considered to be the "upstream BR".
Other methods of finding the "upstream BR" MAY be used; the decision
Napierala, et al. [Page 7]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
to use a particular method belongs to the SP. However, if given BR
cannot determine the core area's exit point on the path to a given
PE, then the procedures of this document are not applicable.
2.2. When the P-tunnel uses mLDP in the Edge Areas
The creation of an mLDP P-tunnel begins at a PE router, call it PE2,
that is one of the egress nodes of the P-tunnel. In order to use
mLDP to set up the P-tunnel, PE2 must specify the PE that is the root
of the P-tunnel. We will call the root PE1. If it is necessary for
the given P-tunnel to pass through a particular BR, say BR1, then BR1
will receive an LDP Label Mapping Message for that P-tunnel. This
message will be received on an LDP session over one of BR1's edge-
facing interfaces. This message specifies an identifier for the P-
tunnel and also specifies the P-tunnel's root node, PE1.
BR1 then looks up its path to PE1. If BR1's path to PE1 is via one
of BR1's edge-facing interfaces, the procedures of this document do
not apply. Otherwise, BR1 must find the "upstream BR".
If BR2 is selected as the upstream BR towards PE1, then BR1 sets up a
Targeted LDP session to BR2. (If such a Targeted LDP session to BR2
already exists, a new session is not set up; rather the existing one
is used.) BR1 then executes the procedures specified in [TMLDP].
In order to execute the procedures specified in [TMLDP], a downstream
BR must know whether the technique for carrying a P-tunnel in the
core is unicast replication or whether it is multicast tunneling.
This is known either by provisioning, or by some method that is
outside the scope of this document. If multicast tunneling is used
in the core, the upstream BR must know what kind of tunnel is to be
used. If aggregation of multiple P-tunnels into a single core tunnel
is used, all the BRs must support MPLS upstream-assigned labels.
In the above procedure, PE2 does not necessarily have any a priori
knowledge of the identity of the BR. In networks where PE2 does have
such a priori knowledge, PE2 could send an mLDP Label Mapping message
containing a "Recursive Forwarding Equivalence Class (FEC)", as
described in [LDP-RECURS]. The recursive FEC would explicitly
identify PE1 as the root of the "outer" tree and BR1 as the root of
the "inner" tree. If BR1 receives such a message, it follows the
procedures of [LDP-RECURS], to obtain a new root. If its route to
the new root is a BGP route whose next hop is another BR, the
procedures of [TMLDP] are followed.
Napierala, et al. [Page 8]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
2.3. When the P-tunnel uses PIM in the Edge Areas
The creation of a PIM P-tunnel begins when a PE router sends a PIM
Join message specifying either (*,G) or (S,G). We first consider the
case where the P-tunnel is a source-specific multicast tree. Then we
consider two different options that may be used when the P-tunnel is
a PIM shared tree. The first option may be used by a BR which is not
itself the Rendezvous Point (RP) for the shared tree. The second
option is useful if all the BRs function as RPs for the shared trees
within their attached edge areas.
2.3.1. Source-Specific Trees
In this case, a BR, say BR1, will receive a Join(S,G) over one of its
edge-facing interfaces. BR1 looks up its path to S, and determines
the "upstream BR" on that path. BR1 sets up a Targeted mLDP session
to the "upstream BR" (or uses an existing Targeted mLDP session to
it). BR1 then uses the encoding specified in [LDP-INBAND] to derive
an LDP multipath FEC from the (S,G). From this point on, the
procedures of [TMLDP] are used, precisely as described in the
previous section.
2.3.2. Shared Trees when the BR is not the RP
If the PIM P-tunnel is a shared tree (*,G), and if the PEs are
configured so that they never switch to source-specific trees for G,
then a similar procedure can be used. BR1 looks up its route to the
RP [PIM-SM] of the shared tree, and determines the "upstream BR" for
that P-tunnel. BR1 uses a Targeted mLDP session to the upstream BR,
and uses the encoding specified in [LDP-INBAND-SHARED] to derive an
LDP multipath FEC from the (*,G). Then the procedures of [TMLDP] are
used.
2.3.3. Shared Trees when each BR is an RP
If G is a non-SSM PIM group address, and if there are sources for G
in a particular edge area, it is possible to configure the BRs of
that area to function as RPs for G. However, each such BR then needs
to discover all the other BRs that are also functioning as RPs for G.
This can be done by having the BRs originate and receive "Source
Active BGP A-D routes". The procedures for generating and receiving
these routes, and the mLDP procedures for setting up P2MP LSPs based
on these routes, are specified in described in [LDP-INBAND-SHARED].
However, the LDP signaling described therein would take place over
Targeted LDP sessions.
Napierala, et al. [Page 9]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
Each such Source Active A-D route refers to a particular group G. It
is RECOMMENDED that each such Source Active A-D route carry an IPv4
Address specific Route Target or an IPv6 Address specific Route
Target (as appropriate)[RFC4360, RFC5701], with the address G in the
"global administrator" field. This allows BRs that have no interest
in group G to filter out the Source Active A-D routes that are about
G.
3. Aggregation Strategies
If it is desired to aggregate multiple P-tunnels into a single core
area multicast tunnel, the choice of P-tunnels to map into which core
area multicast tunnels is made by the upstream Border Router. The
procedures for performing the aggregation are described in [TMLDP].
When the P-tunnels are MP-LSPs, It is RECOMMENDED that an upstream
Border Router be able to aggregate all P-tunnels whose FECs begin
with the same bit string (i.e., aggregate the set of FECs that are
identical under a mask, where the mask consists of a sequence of ones
followed by a sequence of zeroes). If the PEs have been configured
to use MP FECs with type 2 opaque values (as defined in [MLDP-OV]),
this technique allows all MP-LSPs of a given MVPN to be aggregated
together.
Selection of an aggregation strategy is outside the scope of this
document.
Note that PIM P-Tunnels and mLDP P-Tunnels may be aggregated in the
same core tunnel.
4. Preventing Aggregation
It may be desirable to prevent certain P-tunnels from being
aggregated into a single core multicast tunnel. This is done by
configuration at the PEs. The PEs convey this information to the BRs
by including certain TLVs in the mLDP or PIM messages used to set up
the P-tunnels.
Napierala, et al. [Page 10]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
4.1. mLDP P-Tunnels
When a P-tunnel is instantiated as an MP-LSP, and the PEs of that P-
tunnel have been configured to disallow aggregation of that P-tunnel,
the PEs indicate this fact in their MLDP signaling. When the PEs
send a label mapping message that includes the corresponding FEC
element, the PEs will also include an LDP MP Status TLV [mLDP] that
carries the "Do Not Aggregate" status code (to be assigned by IANA).
This TLV MUST be passed along with FEC element by any upstream LSR
that sends a label mapping message or label request message
containing the FEC element. If an mLDP node receives label mapping
messages for a given FEC from more than one downstream neighbor, and
some of those messages have the "Do Not Aggregate" status code while
others do not, the "Do Not Aggregate" status code MUST be passed
upstream.
When a BR receives a label mapping message for an MP FEC element and
a MP Status TLV containing the "Do Not Aggregate" status code, the BR
knows that the MP-LSP corresponding to the FEC element SHOULD NOT be
aggregated into a core multicast tunnel.
If some PEs are configured to disallow aggregation for a given P-
tunnel, but others are not, the results are unpredictable. For a
given P-tunnel, the upstream BR MAY make its decision to aggregate or
not based on the first mLDP label mapping message it sees for that P-
tunnel.
4.2. PIM P-Tunnels
When a P-tunnel is instantiated as a PIM multicast tree, the the PEs
of that P-tunnel have been configured to disallow aggregation of that
P-tunnel, the PEs indicate this fact in their PIM signaling. When
the PEs send a PIM Join message for the corresponding (S,G) or (*,G),
the PEs will include the "Do Not Aggregate" PIM Join Attribute. This
is a PIM Join Attribute as specified in [PIM-JA]. The value of the
Attr_Type field of this Join Attribute is to be assigned by IANA.
The Length field of this Join Attribute is set to 0, and the F bit is
set to 1. This attribute MUST be passed upstream in the PIM Join
messages for the given (S,G) or (*,G). If a PIM node receives
Join(S,G) or Join(*,G) from more than one downstream neighbor, and
some of those Joins have the "Do Not Aggregate" Join Attribute while
others do not, the attribute MUST be passed upstream. The conflict
resolution procedure in [PIM-JA] is not used.
When a BR receives a PIM Join message containing the "Do Not
Aggregate" Join Attribute, the BR knows that the corresponding
Napierala, et al. [Page 11]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
multicast distribution tree SHOULD NOT be aggregated into a core
multicast tunnel.
If some PEs are configured to disallow aggregation for a given P-
tunnel, but others are not, the results are unpredictable. For a
given P-tunnel, the upstream BR MAY make its decision to aggregate or
not based on the first PIM Join it sees for that P-tunnel.
If a BR uses the procedures of [LDP-INBAND] to map a PIM tree into a
MP-LSP, and if the PIM tree has been set up with the "Do Not
Aggregate" Join Attribute, the corresponding LDP messages SHOULD
carry the "Do Not Aggregate" status code. If a BR using the
procedures of [LDP-INBAND] needs to map an MP-LSP to a PIM tree, and
the corresponding LDP messages carry the "Do Not Aggregate" status
code, the corresponding PIM messages SHOULD carry the "Do Not
Aggregate" PIM Join Attribute.
5. IANA Considerations
[mLDP] creates a registry known as "LDP MP Status Value Element
Types". This document requests IANA to assign a value from this
registry for "Do Not Aggregate".
[PIM-JA] creates a registry known as "PIM Join Attributes Types".
This document requests IANA to assign a value from this registry for
"Do Not Aggregate".
6. Security Considerations
This document raises no new security considerations beyond those
discussed in [LDP], [LDP-UP], and [RFC5331].
7. Acknowledgments
The authors wish to thank Don Heidrich for his contribution to this
work. Thanks to Eric Rosenberg for his comments and review.
Napierala, et al. [Page 12]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
8. Authors' Addresses
Maria Napierala
AT&T Labs
200 Laurel Avenue, Middletown, NJ 07748
E-mail: mnapierala@att.com
Eric C. Rosen
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
9. Normative References
[LDP] Loa Andersson, Ina Minei, Bob Thomas, editors, "LDP
Specification", RFC 5036, October 2007
[LDP-INBAND] IJsbrand Wijnands, Toerless Eckert, Maria Napierala,
Nicolai Leymann, "Multipoint LDP In-Band Signaling for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-
ietf-mpls-mldp-in-band-signaling-05.txt, December 2011
[LDP-RECURS] IJsbrand Wijnands, Eric Rosen, Maria Napierala, Nicolai
Leymann, "Using Multipoint LDP When the Backbone Has No Route to the
Root", RFC 6512, February 2012
[LDP-UP] Rahul Aggarwal, Jean-Louis Le Roux, "MPLS Upstream Label
Assignment for LDP", RFC 6389, November 2011
[mLDP] IJsbrand Wijnands, Ina Minei, Kireeti Kompella, Bob Thomas,
"Label Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November
2011
Napierala, et al. [Page 13]
Internet Draft draft-rosen-l3vpn-mvpn-segments-03.txt April 2012
[MVPN] Eric Rosen, Rahul Aggarwal (editors), "Multicast in MPLS/BGP
IP VPNs", RFC 6513, February 2012
[PIM-JA] Arjen Boers, IJsbrand Wijnands, Eric Rosen, "The PIM Join
Attribute Format", RFC 5384, November 2008
[PIM-SM] "Protocol Independent Multicast - Sparse Mode (PIM-SM)",
Fenner, Handley, Holbrook, Kouvelas, August 2006, RFC 4601
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
[RFC5331] Rahul Aggarwal, Yakov Rekhter, Eric Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", RFC 5331, August
2009
[TMLDP] Maria Napierala, Eric Rosen, IJsbrands Wijnands, "Using LDP
Multipoint Extensions on Targeted LDP Sessions", draft-napierala-
mpls-targeted-mldp-03.txt, April 2012
10. Informational References
[LDP-INBAND-SHARED] Yakov Rekhter, Rahul Aggarwal, Nicolai Leymann,
"Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", draft-
rekhter-mpls-pim-sm-over-mldp-00.txt, January 2012
[MLDP-OV] Sandeep Bishnoi, Pranjal Kumar Dutta, IJsbrand Wijnands,
"LDP Multipoint Opaque Value Element Types", draft-bishnoi-mpls-mldp-
opaque-types-01.txt, October 2009
[RFC4360] Srihari R. Sangli, Dan Tappan, Yakov Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006
[RFC5701] Yakov Rekhter, "IPv6 Address Specific BGP Extended
Community Attribute", RFC 5701, November 2009
Napierala, et al. [Page 14]