One document matched: draft-raggarwa-mpls-seamless-mcast-01.txt
Differences from draft-raggarwa-mpls-seamless-mcast-00.txt
Network Working Group Y. Rekhter
Internet Draft Juniper Networks
Expiration Date: April 2011
R. Aggarwal
Juniper Networks
T. Morin
France Telecom
I. Grosclaude
France Telecom
October 25, 2010
Inter-Area P2MP Segmented LSPs
draft-raggarwa-mpls-seamless-mcast-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright and License Notice
Copyright (c) 2010 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
Rekhter [Page 1]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract
This document describes procedures for building inter-area point-to-
multipoint (P2MP) segmented service LSPs by partitioning such LSPs
into intra-area segments and using BGP as the inter-area routing and
label distribution protocol. Within each IGP area the intra-area
segments are either carried over intra-area P2MP LSPs, using P2MP LSP
hierarchy, or instantiated using ingress replication. The intra-area
P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress
replication is used in an IGP area then MP2P LDP LSPs or P2P RSVP-TE
LSPs may be used. The applications/services that use such an inter-
area service LSP may be BGP MVPN, VPLS multicast or Internet
multicast over MPLS.
Rekhter [Page 2]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
Table of Contents
1 Specification of requirements ......................... 3
2 Introduction .......................................... 4
3 General Assumptions and Terminology ................... 4
4 Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 5
4.1 BGP MVPN .............................................. 5
4.2 BGP VPLS or LDP VPLS with BGP A-D ..................... 6
4.3 Internet Multicast .................................... 6
5 Procedures for constructing segmented inter-area P2MP LSP .6
5.1 Egress PEs ............................................ 7
5.1.1 Determining the Ingress PE/ASBR ....................... 7
5.1.2 Originating a Leaf Auto-Discovery Route ............... 7
5.1.2.1 Leaf A-D Route for MVPN and VPLS ...................... 7
5.1.2.2 Leaf A-D Route for Internet Multicast ................. 8
5.1.2.3 Constructing Rest of the Leaf A-D Route ............... 9
5.2 Egress ABR ............................................ 9
5.2.1 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 10
5.2.2 P2MP mLDP LSP as the intra-area LSP in the egress area ....12
5.3 Ingress ABR ........................................... 13
5.3.1 P2MP RSVP-TE LSP as the intra-area LSP in the backbone area 13
5.3.2 P2MP mLDP LSP as the intra-area LSP in the backbone area ..13
5.4 Ingress PE/ASBR ....................................... 14
5.4.1 P2MP RSVP-TE LSP as the intra-area LSP in the ingress area 14
5.4.2 P2MP mLDP LSP as the intra-area LSP in the ingress area ...14
6 IANA Considerations ................................... 15
7 Security Considerations ............................... 15
8 References ............................................ 15
8.1 Normative References .................................. 15
9 Author's Address ...................................... 15
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].
Rekhter [Page 3]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
2. Introduction
This document describes procedures for building inter-area point-to-
multipoint (P2MP) segmented service LSPs by partitioning such LSPs
into intra-area segments and using BGP as the inter-area routing and
label distribution protocol. Within each IGP area the intra-area
segments are either carried over intra-area P2MP LSPs, using P2MP LSP
hierarchy, or instantiated using ingress replication. The intra-area
P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress
replication is used in an IGP area then MP2P LDP LSPs or P2P RSVP-TE
LSPs may be used. The applications/services that use such an inter-
area service LSP may be BGP MVPN, VPLS multicast or Internet
multicast over MPLS.
The primary use case of such segmented P2MP service LSPs is when the
PEs are in different areas but in the same AS and thousands or more
of PEs require P2MP connectivity. This may be the case when MPLS is
pushed further to the metro edge and the metros are in different
areas. Seamless MPLS is the industry term to address this case
[SEAMLESS-MPLS]. Thus one of the applicabilities of this document is
that it describes the multicast procedures for seamless MPLS.
It is to be noted that [BGP-MVPN], [VPLS-MCAST] already specify
procedures for building segmented inter-AS P2MP service LSPs. This
document complements those procedures as it extends the segmented
P2MP LSP model such that it is applicable to inter-area P2MP service
LSPs as well. Infact an inter-AS deployment could use inter-AS
segmented P2MP LSPs as specified in [BGP-MVPN, VPLS-MCAST] where each
intra-AS segment is constructed using inter-area segmented P2MP LSPs
as specified in this document.
3. General Assumptions and Terminology
Assume BGP is used as an inter-area routing and label distribution
protocol for unicast /32 routes for the PEs. Assume ABRs act as Route
Reflectors for these routes. Futhermore, assume ABRs set BGP Next Hop
to self for these routes.
Within an AS a P2MP service LSP is partitioned into 3 segments:
ingress area segment, backbone area segment, and egress area segment.
Within each area a segment is carried over an intra-area P2MP LSP.
There could be either 1:1 or n:1 mapping between segments and a given
intra-area P2MP LSP. The latter is realized using P2MP LSP hierarchy
with upstream-assigned labels [RFC5331]. For simplicity we assume
that P2MP LSP hierarchy is used even with 1:1 mapping, in which case
the upstream-assigned label could be an implicit NULL.
Rekhter [Page 4]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
The ingress area segment of a P2MP service LSP is rooted at PE (or at
ASBR in the case where the P2MP service LSP spans multiple ASes).
The leaves of this segment are other PEs and ABRs in the same area as
the root PE. The backbone area segment is rooted at an ABR that is
connected to the ingress area (ingress ABR), and has as it leaves
ABRs that are connected to the egress area(s). The egress area
segment is rooted at an ABR in the egress area (egress ABR), and has
as its leaves PEs and ASBR in that egress area. Note that for a given
P2MP service LSP there may be more than one backbone segment, each
rooted at its own ingress ABR, and more than one egress area segment,
each rooted at its own egress ABR.
4. Discovering the P2MP FEC of the Inter-Area P2MP Service LSP
The P2MP FEC identifies the inter-area P2MP service LSP. The egress
PEs need to learn this P2MP FEC in order to initiate the creation of
the egress area segment of the P2MP inter-area service LSP.
The P2MP FEC of the inter-area P2MP LSP is learned by the egress PEs
either by configuration, or based on the application-specific
procedures (e.g., MVPN-specific procedures, VPLS-specific
procedures).
4.1. BGP MVPN
Egress PEs discover the P2MP FEC of the service LSPs used by BGP MVPN
using the I-PMSI or S-PMSI A-D routes that are originated by the
ingress PEs or ASBRs following the procedures of [BGP-MVPN]. The
NLRI of such routes encodes the P2MP FEC. The procedures in this
document assume all ABRs act as Route Reflectors for MVPN auto-
discovery (A-D) routes. The "Leaf Information Required" flag MUST be
set in the P-Tunnel attribute carried in such routes. Before any
Leaf auto discovery route is avertised by a PE or ABR in the same
area, as described in the following sections, an I-/S-PMSI
autodiscovery route is advertised either with an explicit Tunnel Type
and Tunnel Identifier in the PMSI Tunnel Attribute, if the Tunnel
Identifier has already been assigned, or with a special Tunnel Type
of "No tunnel information present" otherwise.
To avoid requiring ABRs to participate in the propagation of C-
multicast routes, this document requires ABRs NOT to modify BGP Next
Hop when re-advertising I-PMSI/S-PMSI A-D routes. The egress PEs may
advertise the C-multicast routes to RRs that are different than the
ABRs. However ABRs still can be configured to be the Route Reflectors
for C-multicast routes, in which case they will participate in the
Rekhter [Page 5]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
propagation of C-multicast routes.
4.2. BGP VPLS or LDP VPLS with BGP A-D
Egress PEs discover the P2MP FEC of the service LSPs used by VPLS,
using using the VPLS A-D routes that are originated by the ingress
PEs [BGP-VPLS, VPLS-AD] or S-PMSI A-D routes that are originated by
the ingress PE [VPLS-P2MP]. The NLRI of such routes encodes the P2MP
FEC. The "Leaf Information Required" flag MUST be set in the P-Tunnel
attribute carried in such routes. Before any Leaf auto discovery
route is avertised by a PE or ABR in its own area, as described in
the following sections, an VPLS/S-PMSI autodiscovery route is
advertised either with an explicit Tunnel Type and Tunnel Identifier
in the PMSI Tunnel Attribute, if the Tunnel Identifier has already
been assigned, or with a special Tunnel Type of "No tunnel
information present" otherwise.
The procedures in this document assume all ABRs act as Route
Reflectors for VPLS auto-discovery (A-D) routes. These ABRs/RRs do
NOT modify BGP Next Hop when re-advertising these A-D routes.
4.3. Internet Multicast
This section describes how the egress PEs discover the P2MP FEC when
the application is internet multicast.
An egress PE learns the (S/*, G) of a multicast stream as a result of
receiving IGMP or PIM messages on one of its IP multicast interfaces.
This (S/*, G) forms the P2MP FEC of the inter-area P2MP service LSP.
This document assumes that for each (S/*,G) we have a distinct inter-
area P2MP service LSP.
5. Procedures for constructing segmented inter-area P2MP LSP
This section applies to the scenario where the egress PE and the
ingress PE/ASBR are in different IGP areas.
Rekhter [Page 6]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
5.1. Egress PEs
Once an egress PE discovers the P2MP FEC of an inter-area segmented
P2MP service LSP, it MUST propagate this P2MP FEC in BGP in order to
construct the segmented inter-area P2MP service LSP.
5.1.1. Determining the Ingress PE/ASBR
The egress PE discovers the P2MP FEC of an inter-area P2MP Segmented
Service LSP as described in section 3. When an egress PE discovers
this P2MP FEC it MUST first determine the ingress PE/ASBR of such a
FEC as follows.
If the application is MVPN or VPLS the ingress PE/ASBR's address is
the BGP next-hop of the MVPN or VPLS A-D route from which the P2MP
FEC is derived.
If the application is internet multicast then the unicast routes to
multicast sources/RPs SHOULD carry the VRF Route Import Extended
Community [BGP MVPN] where the IP address in the Global Administrator
field is set to the IP address of PE advertising the unicast route.
The Local Administrator field of this community MUST be set to 0. If
it is not desirable to advertise the VRF Route Import Extended
Community in unicast routes, then unicast routes to multicast sources
MUST be advertised using the multicast SAFI i.e. SAFI 2 and the VRF
Route Import Extended Community MUST be carried in such routes. The
ingress PE address as determined by the egress PE is the IP address
determined from the VRF Route Import Extended community, that is
present in the best route to reach S/RP.
5.1.2. Originating a Leaf Auto-Discovery Route
If the P2MP FEC was derived from a MVPN or VPLS A-D route then the
egress PE MUST originate a Leaf auto-discovery (A-D) route if the
MVPN or VPLS A-D route carries a P-Tunnel Attribute with the "Leaf
Information Required" flag set.
If the P2MP FEC was derived from an Internet Multicast S/*, G and the
ingress PE's address is not the same as the egress PE, then the
egress PE MUST originate a Leaf auto-discovery (A-D) route.
5.1.2.1. Leaf A-D Route for MVPN and VPLS
If the P2MP FEC was derived from MVPN or VPLS A-D routes then the
Route Key field of the Leaf A-D route contains the NLRI of the A-D
Rekhter [Page 7]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
route from which the P2MP FEC was derived. This follows procedures
described in [BGP-MVPN, VPLS-P2MP].
5.1.2.2. Leaf A-D Route for Internet Multicast
If the application is internet multicast than the the MCAST-VPN NLRI
of the Leaf A-D route is constructed as follows:
The Route Key field of MCAST-VPN NLRI has the following format:
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
| Ingress PE IP Address |
+-----------------------------------+
RD is set to 0 for (S,G) state and all 1s for (*,G) state, Multicast
Source is set to S for (S,G) state or RP for (*,G) state, Multicast
Group is set to G, Multicast Source Length and Multicast Group Length
is set to either 4 or 16 (depending on whether S/RP and G are IPv4 or
IPv6 addresses), and Ingress PE IP Address is set to the address
carried in the BGP Next Hop of the route to S/RP.
The Originating Router's IP address field of MCAST-VPN NLRI is set to
the address of the local PE (PE that originates the route).
Thus the whole MCAST-VPN NLRI of the route has the following format:
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
Rekhter [Page 8]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
| Ingress PE IP Addr |
+-----------------------------------+
| Originating Router's IP address |
+-----------------------------------+
When the PE deletes (S,G)/(*,G) state that was created as a result of
receiving PIM messages on one of its IP multicast interfaces, if the
PE previousely originated a Leaf auto-discovery route for that state,
then the PE SHOULD withdraw that route.
The support of PIM-SM in ASM mode requires further details and they
will be provided in the next revision.
5.1.2.3. Constructing Rest of the Leaf A-D Route
The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
be set to the same IP address as the one carried in the Originating
Router's IP Address field of the route.
To constrain distribution of this route, the originating PE
constructs an IP-based Route Target community by placing the IP
address of the egress ABR in the Global Administrator field of the
community, with the Local Administrator field of this community set
to 0. The originating PE then adds this Route Target Extended
Community to this Leaf auto-discovery route. The egress ABR's address
is the BGP next-hop of the BGP route to reach the ingress PE/ASBR.
The PE then advertises this route to the (egress) ABR/RR.
5.2. Egress ABR
When an egress ABR receives a Leaf auto-discovery route, or a
withdraw of a previousely received Leaf auto-discovery route, and the
Route Target extended community carried by the route contains the IP
address of this ABR, then the following procedures will be executed.
The egress ABR originates a Leaf A-D route, whose MCAST-VPN NLRI is
constructed as follows.
The Route Key field of MCAST-VPN NLRI is the same as the Route Key
field of MCAST-VPN NLRI of the received Leaf A-D route. The
Originating Router's IP address field of MCAST-VPN NLRI is set to the
address of the local ABR (the ABR that originates the route).
The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
be set to the same IP address as the one carried in the Originating
Rekhter [Page 9]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
Router's IP Address field of the route.
To constrain distribution of this route, the originating PE
constructs an IP-based Route Target community by placing the IP
address of the ingress ABR in the Global Administrator field of the
community, with the Local Administrator field of this community set
to 0, and sets the Extended Communities attribute of this Leaf auto-
discovery route to that community. The ingress ABR is the BGP Next
Hop of the route to the ingress PE/ASBR. If the RD of the received
Leaf A-D route is 0, then the Ingress PE address is determined from
the the received Leaf A-D route. If the RD of the received Leaf A-D
route is not 0, the ABR finds an MVPN I-PMSI/S-PMSI A-D route or VPLS
A-D or S-PMSI A-D route whose NLRI has the same value as the Route
Key field of the the Leaf A-D route. The BGP next-hop of this NLRI is
the address of the ingress PE.
To carry information identifying the upstream PE/ABR that has to
process this Leaf Auto-Discovery route, the originating PE constructs
an IP-based Route Target community by placing the IP address of the
ingress ABR in the Global Administrator field of the community, with
the Local Administrator field of this community set to 0, and sets
the Extended Communities attribute of this Leaf auto-discovery route
to that community. The ingress ABR is the BGP Next Hop of the route
to the ingress PE/ASBR. If the RD of the received Leaf A-D route is
0, then the Ingress PE address is determined from the the received
Leaf A-D route. If the RD of the received Leaf A-D route is not 0,
the ABR finds an MVPN I-PMSI/S-PMSI A-D route or VPLS A-D or S-PMSI
A-D route whose NLRI has the same value as the Route Key field of the
the Leaf A-D route. The BGP next-hop of this NLRI is the address of
the ingress PE. The ABR then advertises this Leaf A-D route to the
ABRs in the backbone area.
Mechanisms specific in RFC4684 for constrained BGP route distribution
can be used along with this specification to ensure that only the
needed PE/ABR will have to process a said Leaf auto-discovery route.
5.2.1. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area
If P2MP RSVP-TE LSP is used as the the intra-area LSP in the egress
area, then the egress ABR can either (a) graft the leaf (whose IP
address is specified in the received Leaf auto-discovery route) into
an existing P2MP LSP rooted at the egress ABR, and use that LSP for
carrying traffic for the inter-area segmented P2MP service LSP, or
(b) originate a new P2MP LSP to be used for carrying (S,G).
Note that an existing intra-area P2MP LSP may be used solely for that
particular inter-area P2MP service LSP, or for other inter-area P2MP
Rekhter [Page 10]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
service LSPs as well. The choice between the two options is purely
local to the egress ABR. The first option provides one-to-one mapping
between inter-area P2MP service LSPs and intra-area P2MP LSPs; the
second option provides many-to-one mapping, thus allowing to
aggregate forwarding state.
When the RD of the received Leaf A-D route is not set to zero then
the ABR MUST re-advertise in the egress area the MVPN/VPLS A-D route,
that matches the Leaf A-D route to signal the binding of the intra-
area P2MP RSVP-TE LSP to the inter-area P2MP service LSP. This must
be done ONLY if a) such a binding hasn't already been advertised or
b) The binding has changed. The PMSI Tunnel attribute of the re-
advertised route specifies an intra-area P2MP RSVP-TE LSP rooted at
the ABR and MUST also carry an upstream assigned MPLS label. The
upstream-assigned MPLS label MUST be set to implicit NULL if the
mapping between the inter-area P2MP service LSP and the intra-area
P2MP LSP is one-to-one. If the mapping is many-to-one the intra-area
segment of the inter-area P2MP service LSP (referred to as the
"inner" P2MP LSP) is constructed by nesting the inter-area P2MP
service LSP in an intra-area P2MP LSP (referred to as the "outer"
intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream-
assigned MPLS labels [RFC 5332].
If the RD of the received Leaf A-D route is zero, then the egress ABR
need not advertise any auto-discovery routes. As this is the case of
inter-area P2MP service LSP being associated with the Internet
multicast service. In this case the the egress PEs do not require
the binding of the intra-area P2MP LSP to the inter-area P2MP service
LSP. If an egress PE receives multicast packets over an intra-area
P2MP LSP, with no MPLS label in the stack to identify the inter-area
P2MP service LSP, the egress PE must forward the packets using its
internet multicast forwarding table.
If the mapping between the inter-area P2MP service LSP for Internet
multicast service and the intra-area P2MP LSP is many-to-one then an
egress PE must be able to determine whether a given multicast packet
for a particular (S, G) is received from the "expected" upstream
PE/ABR. The expected PE/ABR is the PE/ABR to which the Leaf A-D route
is sent by the egress PE. Packets received from another PE/ABR for
that (S, G) MUST be dropped. To allow the egress PE to determine the
sender, the intra-area P2MP LSP must be signaled with no PHP, when
the mapping between the inter-area P2MP service LSP for Internet
multicast service and the intra-area P2MP LSP is many-to-one.
This document assumes that a single S-PMSI service LSP carries only a
single (C-S,C-G). Thus if segments of multiple MVPN or VPLS S-PMSI
service LSPs are carried over a given intra-area P2MP LSP, each of
these segments would require a distinct upstream-assigned label, even
Rekhter [Page 11]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
if all these service LSPs are for (C-S, C-G)s from the same
MVPN/VPLS. Therefore, an ABR maintains an LFIB state for each of the
(C-S, C-G)s carried over S-PMSIs traversting this ABR (that applies
to both the ingress and the egress ABRs).
Note also that the SESSION object that the egress ABR would use for
the intra-area P2MP LSP need not encode the P2MP FEC from the
received Leaf auto-discovery route.
5.2.2. P2MP mLDP LSP as the intra-area LSP in the egress area
If P2MP mLDP LSP is used as the intra-area LSP in the egress area,
and the RD of the received Leaf A-D route is set to 0 then the egress
ABR constructs an S-PMSI A-D. The PMSI Tunnel attribute of the route
contains the identity of the intra-area P2MP LSP. Note that the PMSI
Tunnel attribute does not carry an upstream assigned label. The RD,
Multicast Source Length, Multicast Source, Multicast Group Length (1
octet), and Multicast Group fields of the NLRI of this route are the
same as of the Leaf A-D route. The egress ABR advertises this route
into the egress area. The forwarding considerations including the
determination of whether packets are received from an expected sender
are the same as the ones above with P2MP RSVP-TE.
If P2MP mLDP LSP is used as the intra-area LSP in the egress area,
and the RD of the received Leaf A-D route is not set to 0, ABR MUST
re-advertise the MVPN/VPLS A-D route, that matches the Leaf A-D route
to signal the binding of the intra-area P2MP RSVP-TE LSP to the
inter-area P2MP service LSP. This must be done ONLY if a) such a
binding hasn't already been advertised or b) The binding has changed.
The PMSI Tunnel attribute of the re-advertised route specifies an
intra-area P2MP RSVP-TE LSP rooted at the ABR and MUST also carry an
upstream assigned MPLS label. The upstream-assigned MPLS label MUST
be set to implicit NULL if the mapping between the inter-area P2MP
service LSP and the intra-area P2MP LSP is one-to-one.
The egress PEs MUST join the intra-area P2MP LDP LSP that is encoded
in the PMSI Tunnel Attribute of the A-D routes that carry the binding
of the inter-area P2MP service LSP to the intra-area P2MP LDP LSP.
Rekhter [Page 12]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
5.3. Ingress ABR
When an ingress ABR receives a Leaf auto-discovery route, or a
withdraw of a previousely received Leaf auto-discovery route from an
(egress) ABR, and the Route Target extended community carried by the
route contains the IP address of this ABR, then the following
procedures will be executed.
The ingress ABR originates a Leaf A-D route towards the ingress
PE/ASBR, whose MCAST-VPN-NLRI is constructed using procedures in
section 4.2 with the difference that the IP based RT contains the
ingress PE/ASBR address and not the ingress ABR address.
5.3.1. P2MP RSVP-TE LSP as the intra-area LSP in the backbone area
If the RD of the received Leaf A-D route is not zero, and P2MP RSVP-
TE LSP is used as the the intra-area LSP in the backbone area, then
the procedures for binding the backbone area segment of the inter-
area P2MP LSP to the intra-area P2MP LSP in the backbone area, are
the same as in section 4.2.1.
When the RD of the received Leaf A-D route is zero, as is the case
where the inter-area service P2MP LSP is associated with the Internet
multicast service, then in addition to the procedures in section
4.2.1 the ingress ABR MUST originate a S-PMSI A-D route. The PMSI
Tunnel attribute of the route contains the identity of the intra-area
P2MP LSP and a distinct upstream assigned MPLS label. The RD,
Multicast Source Length, Multicast Source, Multicast Group Length (1
octet), and Multicast Group fields of the NLRI of this route are the
same as of the Leaf A-D route. The ingress ABR advertises this route
into the backbone area.
5.3.2. P2MP mLDP LSP as the intra-area LSP in the backbone area
If the RD of the received Leaf A-D route is not zero, and P2MP mLDP
LSP is used as the the intra-area LSP in the backbone area, then the
procedures for binding the backbone area segment of the inter-area
P2MP LSP to the intra-area P2MP LSP in the backbone area, are the
same as in section 4.2.2.
When the RD of the received Leaf A-D route is zero then in addition
to the procedures in section 4.2.2 the S-PMSI A-D route's PMSI Tunnel
Attribute MUST carry an upstream assigned MPLS label.
Rekhter [Page 13]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
5.4. Ingress PE/ASBR
When an ingress PE/ASBR receives a Leaf auto-discovery route, or a
withdraw of a previously received Leaf auto-discovery route, and the
Route Target extended community carried by the route contains the IP
address of this PE, then the following procedures will be executed.
If the RD of the received Leaf A-D route is 0, as is the case when
the inter-area service P2MP LSP is associated with the Internet
multicast service, the information carried in the MCAST-VPN NLRI of
the route MUST be decoded. The PIM implementation should set its
upstream (S/RP,G) state machine in Joined state for the (S/RP, G)
received via a Leaf auto-discovery route. Likewise, the PIM
implementation should set its upstream (S/RP, G) state machine in
Pruned state for the (S/RP, G) received via a Leaf auto-discovery
route.
If the RD of the received Leaf A-D route is not 0, the ingress
PE/ASBR finds an MVPN I-PMSI/S-PMSI A-D route or VPLS A-D or S-PMSI
A-D route whose NLRI has the same value as the Route Key field of the
the Leaf A-D route.
5.4.1. P2MP RSVP-TE LSP as the intra-area LSP in the ingress area
If the RD of the received Leaf A-D route is not zero, and P2MP RSVP-
TE LSP is used as the the intra-area LSP in the ingress area, then
the procedures for binding the ingress segment of the inter-area P2MP
LSP to the intra-area P2MP LSP in the ingress area, are the same as
in section 4.2.1.
When the RD of the received Leaf A-D route is zero than in addition
to the procedures in section 4.2.1 the ingress PE MUST originate a S-
PMSI A-D route. The PMSI Tunnel attribute of the route contains the
identity of the intra-area P2MP LSP and an upstream assigned MPLS
label. The RD, Multicast Source Length, Multicast Source, Multicast
Group Length (1 octet), and Multicast Group fields of the NLRI of
this route are the same as of the Leaf A-D route. The ingress PE
advertises this route into the ingress area.
5.4.2. P2MP mLDP LSP as the intra-area LSP in the ingress area
If the RD of the received Leaf A-D route is not zero, and P2MP RSVP-
TE LSP is used as the the intra-area LSP in the ingress area, then
the procedures for binding the ingress segment of the inter-area P2MP
LSP to the intra-area P2MP LSP in the ingress area, are the same as
in section 4.2.2.
Rekhter [Page 14]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
When the RD of the received Leaf A-D route is zero than in addition
to the procedures in section 4.2.2 the S-PMSI A-D route's PMSI Tunnel
Attribute MUST carry an upstream assigned MPLS label.
6. IANA Considerations
These will be spelled out in the next revision.
7. Security Considerations
These will be spelled out in a future revision.
8. References
8.1. Normative References
[RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
[MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, draft-ietf-
l3vpn-2547bis-mcast-bgp
[[VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang,
draft-ietf-l2vpn-vpls-mcast
9. Author's Address
Yakov Rekhter
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: yakov@juniper.net
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Rekhter [Page 15]
Internet Draft draft-raggarwa-mpls-seamless-mcast-01.txt October 2010
Phone: +1-408-936-2720
Email: rahul@juniper.net
Thomas Morin
France Telecom R & D
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: thomas.morin@francetelecom.com
Irene Grosclaude
France Telecom R & D
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: irene.grosclaude@orange-ftgroup.com
Rekhter [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 09:32:08 |