Network Working Group Y. Rekhter
Internet Draft Juniper Networks
Expiration Date: September 2011
R. Aggarwal
Juniper Networks
T. Morin
France Telecom
I. Grosclaude
France Telecom
N. Leymann
Deutsche Telekom AG
S. Saad
AT&T
March 14, 2011
Inter-Area P2MP Segmented LSPs
draft-raggarwa-mpls-seamless-mcast-03.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.
Rekhter [Page 1]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
Copyright and License Notice
Copyright (c) 2011 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.
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 in the IGP area. 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-03.txt March 2011
Table of Contents
1 Specification of requirements ......................... 4
2 Introduction .......................................... 4
3 General Assumptions and Terminology ................... 5
4 Inter-area P2MP Segmented Next-Hop Extended Community . 6
5 Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 6
5.1 BGP MVPN .............................................. 6
5.2 BGP VPLS or LDP VPLS with BGP A-D ..................... 7
5.3 Internet Multicast .................................... 8
6 Egress PE Procedures .................................. 9
6.1 Determining the Upstream ABR/PE/ASBR .................. 9
6.2 Originating a Leaf Auto-Discovery Route ............... 10
6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 10
6.2.2 Leaf A-D Route for Internet Multicast ................. 11
6.2.3 Constructing the Rest of the Leaf A-D Route ........... 12
6.3 PIM-SM in ASM mode for Internet Multicast ............. 12
6.3.1 Option 1 .............................................. 12
6.3.1.1 Originating Source Active auto-discovery routes ....... 13
6.3.1.2 Receiving BGP Source Active auto-discovery route by PE ....13
6.3.1.3 Handling (S, G, RPTbit) state ......................... 14
6.3.2 Option 2 .............................................. 14
6.3.2.1 Originating Source Active auto-discovery routes ....... 14
6.3.2.2 Receiving BGP Source Active auto-discovery route ...... 15
6.3.2.3 Pruning Sources off the Shared Tree ................... 15
6.3.2.4 More on handling (S, G, RPTbit) state ................. 15
7 Egress ABR Procedures ................................. 16
7.1 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 18
7.1.1 RD of the received Leaf-AD route is not zero or all ones ..18
7.1.2 RD of the received Leaf A-D route is zero or all ones . 19
7.1.2.1 Internet Multicast and S-PMSI A-D Routes .............. 19
7.1.2.2 Internet Multicast and Wildcard S-PMSI A-D Routes ..... 19
7.1.3 Internet Multicast and the Expected Upstream Node ..... 19
7.1.4 P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area 20
7.1.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 20
7.2 Ingress Replication in the Egress Area ................ 20
8 Ingress ABR Procedures for constructing segmented inter-area P2MP LSP 21
8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 21
8.2 Ingress Replication in the Backbone Area .............. 22
9 Ingress PE/ASBR Procedures ............................ 22
9.1 P2MP LSP as the intra-area LSP in the ingress area .... 23
9.2 Ingress Replication in the Ingress Area ............... 23
10 Common Tunnel Type in the Ingress and Egress Areas .... 24
11 Placement of Ingress and Egress PEs ................... 24
Rekhter [Page 3]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
12 Data Plane ............................................ 25
12.1 Data Plane Procedures on an ABR ....................... 25
12.2 Data Plane Procedures on an Egress PE ................. 25
12.3 Data Plane Procedures on an Ingress PE ................ 26
12.4 Data Plane Procedures on Transit Routers .............. 27
13 IANA Considerations ................................... 27
14 Security Considerations ............................... 27
15 References ............................................ 27
15.1 Normative References .................................. 27
15.2 Informative References ................................ 28
16 Author's Address ...................................... 28
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].
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, potentially
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 or
P2P RSVP-TE LSPs may be used in the IGP area. 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. For instance this may be the case
when MPLS is pushed further to the metro edge and the metros are in
different IGP areas. This may also be the case when a Service
Provider's network comprises multiple IGP areas in a single
Autonomous System, with a large number of PEs. 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
Rekhter [Page 4]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
procedures for seamless MPLS.
It is to be noted that [BGP-MVPN], [VPLS-P2MP] 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-P2MP] where each
intra-AS segment is constructed using inter-area segmented P2MP LSPs
as specified in this document.
3. General Assumptions and Terminology
This document assumes BGP is used as an inter-area routing and label
distribution protocol for the unicast IPv4 /32 or IPv6 /128 routes
for the PEs. This document also assumes ABRs act as Route Reflectors
(RR) 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 or
instantiated using ingress replication.
When intra-area P2MP LSPs are used to instantiate the intra-area
segments there could be either 1:1 or n:1 mapping between intra-area
segments of the inter-area P2MP service LSP 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.
When intra-area segments of the inter-area P2MP service LSP are
instantiated using ingress replication, then multiple such segments
may be carried in the same P2P RSVP-TE or MP2P LDP LSP. This can be
achieved using downstream-assigned labels alone.
The ingress area segment of a P2MP service LSP is rooted at a PE (or
at an ASBR in the case where the P2MP service LSP spans multiple
ASes). The leaves of this segment are other PEs/ASBRs 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 its leaves ABRs that are connected to the egress area(s) or PEs in
the backbone area. 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 (the latter covers the case where the P2MP service
LSP spans multiple ASes). Note that for a given P2MP service LSP
there may be more than one backbone segment, each rooted at its own
Rekhter [Page 5]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
ingress ABR, and more than one egress area segment, each rooted at
its own egress ABR.
4. Inter-area P2MP Segmented Next-Hop Extended Community
This document defines a new BGP Extended Community "Inter-area P2MP
Next-Hop" extended community. This is an IP address specific Extended
Community, of an extended type and is transitive across AS boundaries
[RFC4360].
A PE or an ABR or an ASBR constructs the Inter-area P2MP Segmented
Next-Hop Extended Community as follows:
- The Global Administrator field MUST be set to an IP address of
the PE or ASBR or ABR that originates or advertises the route,
which carries the P2MP Next-Hop Extended Community. For example
this address may be the loopback address or the PE, ASBR or ABR
that advertises the route.
- The Local Administrator field MUST be set to 0.
The detailed usage of this extended community is described in the
following sections.
5. 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).
5.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], along
with modifications as described in this document. The NLRI of such
routes encodes the P2MP FEC. The procedures in this document require
that at least one ABR in a given IGP area act as Route Reflector for
MVPN auto-discovery (A-D) routes.
Rekhter [Page 6]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
The "Leaf Information Required" flag MUST be set in the P-Tunnel
attribute carried in such routes, when originated by the ingress PEs
or ASBRs. Before any Leaf auto discovery route is advertised by a PE
or ABR in the same area, as described in the following sections, an
I-/S-PMSI auto-discovery 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. When the
I/S-PMSI routes are re-advertised by an ABR, "Leaf Information
Required" flag MUST be set in the P-Tunnel attribute present in the
routes.
Note that the procedures in the above paragraph apply when intra-area
segments are realized by either intra-area P2MP LSPs or by ingress
replication.
When BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or
propagated to signal Inter-area P2MP service LSPs, they MUST carry
the Inter-area P2MP Segmented Next-Hop Extended Community. This
Extended Community MUST be included in the I/S-PMSI A-D route by the
PE or ASBR that originates such a route and the Global Administrator
field MUST be set to the advertising PE or ASBR's IP address. This
Extended Community MUST also be included by ABRs as they re-advertise
such routes. An ABR MUST set the Global Administrator field of the
P2MP Segmented Next-Hop Extended Community to its own IP address.
This allows ABRs and PEs/ASBRs to follow the procedures in this
document when these procedures differ from those in [BGP-MVPN].
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 Inter-AS I-PMSI A-D routes. For consitancy
this document requires ABRs to NOT modify BGP Next-Hop when re-
advertising both Intra-AS and Inter-AS I/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 propagation of C-multicast routes.
5.2. BGP VPLS or LDP VPLS with BGP A-D
Egress PEs discover the P2MP FEC of the service LSPs used by VPLS,
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 advertised by a PE or ABR in its own area, as described in
Rekhter [Page 7]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
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.
When VPLS A-D or S-PMSI A-D routes are advertised or propagated to
signal Inter-area P2MP service LSPs, they MUST carry the Inter-area
P2MP Segmented Next-Hop Extended Community. This Extended Community
MUST be included in the A-D route by the PE or ASBR that originates
such a route and the Global Administrator field MUST be set to the
advertising PE or ASBR's IP address. This Extended Community MUST
also be included by ABRs as they re-advertise such routes. An ABR
MUST set the Global Administrator field of the P2MP Segmented Next-
Hop Extended Community to its own IP address. This allows ABRs and
PEs/ASBRs to follow the procedures in this document when these
procedures differ from those in [VPLS-P2MP].
Note that the procedures in the above paragraph apply when intra-area
segments are realized by either intra-area P2MP LSPs or by ingress
replication.
The procedures in this document require that at least one ABR in a
given area act as Route Reflector for MVPN auto-discovery (A-D)
routes. These ABRs/RRs MUST NOT modify BGP Next Hop when re-
advertising these A-D routes.
5.3. Internet Multicast
This section describes how the egress PEs discover the P2MP FEC when
the application is internet multicast.
In the case where Internet multicast uses PIM-SM in ASM mode the
following assumes that an inter-area P2MP service LSP could be used
to either carry traffic on a shared (*,G), or a source (S,G) tree.
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.
For each (S/*,G) for which an inter-area P2MP service LSP is
instantiated, there may exist a distinct inter-area P2MP service LSP
or multiple inter-area P2MP service LSPs may be aggregated using a
wildcard (*, *) S-PMSI.
Note that this document does not require the use of (*, G) Inter-area
P2MP service LSPs when Internet multicast uses PIM-SM in ASM mode.
Infact PIM-SM in ASM mode may be supported entirely by using (S, G)
Rekhter [Page 8]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
trees alone.
6. Egress PE Procedures
This section describes egress PE procedures for constructing
segmented inter-area P2MP LSP. The procedures in this section apply
irrespective of whether the egress PE is in a leaf IGP area, or the
backbone area or even in the same IGP area as the ingress PE/ASBR.
In order to support Internet Multicast an egress PE MUST auto-
configure an import Route Target with the global administrator field
set to the AS of the PE and the local administrator field set to 0.
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. This propagation
uses BGP Leaf auto-discovery routes.
6.1. Determining the Upstream ABR/PE/ASBR
The egress PE discovers the P2MP FEC of an inter-area P2MP Segmented
Service LSP as described in section 5. When an egress PE discovers
this P2MP FEC it MUST first determine the upstream node to reach such
a FEC. If the egress PE is in the egress area and the ingress PE is
not in the that egress area, then this upstream node would be the
egress ABR. If the egress PE is in the backbone area and the ingress
PE is not in the backbone area, then this upstream node would be the
ingress ABR. If the egress PE is in the same area as the ingress PE
then this upstream node would be the ingress PE.
If the application is MVPN or VPLS then the upstream node's IP
address is the IP address determined from the Global Administrator
field of the Inter-area P2MP Segmented Next-hop Extended Community.
As described in section 5 this Extended Community MUST be carried in
the MVPN or VPLS A-D route from which the P2MP FEC of the inter-area
P2MP Segmented Service LSP is determined.
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 the PE or ASBR 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/RPs MUST be advertised using the multicast SAFI
Rekhter [Page 9]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
i.e. SAFI 2 and the VRF Route Import Extended Community MUST be
carried in such routes.
Further if the application is internet multicast then the BGP unicast
routes that advertise the route to the IP address of PEs or ASBRs or
ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop Extended
Community where the IP address in the Global Administrator field is
set to the IP address of the PE or ASBR or ABR advertising the
unicast route. The Local Administrator field of this community MUST
be set to 0. If it is not desirable to advertise the P2MP Segmented
Import Extended Community in BGP unicast routes, then unicast routes
to ABRs, ASBRs or PEs MUST be advertised using the multicast SAFI
i.e. SAFI 2 and the Inter-area P2MP Segmented Next-hop Extended
Community MUST be carried in such routes. The procedures for handling
the next-hop of SAFI 2 routes are the same as those of handling
regular Unicast routes and follow [SEAMLESS-MPLS].
In order to determine the upstream node address the egress PE first
determines the ingress PE. The egress PE determines the best route to
reach S/RP. The ingress PE address is the IP address determined from
the Global Administrator field of the VRF Route Import Extended
Community, that is present in this route. The egress PE now finds the
best unicast route to reach the ingress PE. The upstream node address
is the IP address determined from the Global Administrator field of
the Inter-area P2MP Segmented Next-Hop Extended Community, that is
present in this route.
6.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
upstream node's address is not the same as the egress PE, then the
egress PE MUST originate a Leaf auto-discovery (A-D) route.
6.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
route from which the P2MP FEC was derived. This follows procedures
for constructing Leaf A-D routes described in [BGP-MVPN, VPLS-P2MP].
Rekhter [Page 10]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
6.2.2. Leaf A-D Route for Internet Multicast
If the application is internet multicast then 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's 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).
The Ingress PE's IP address is determined as described in the section
"Determining the Upstream ABR/PE/ASBR".
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 entire 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) |
+-----------------------------------+
| Ingress PE's IP address |
Rekhter [Page 11]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
+-----------------------------------+
| Originating Router's IP address |
+-----------------------------------+
When the PE deletes (S,G)/(*,G) state that was created as a result of
receiving PIM or IGMP 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.
6.2.3. Constructing the 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.
When Ingress Replication is used to instantiate the egress area
segment then the Leaf A-D route MUST carry a downstream assigned
label in the P-Tunnel Attribute where the P-Tunnel type is set to
Ingress Replication. A PE MUST assign a distinct MPLS label for each
Leaf A-D route originated by the PE.
To constrain distribution of this route, the originating PE
constructs an IP-based Route Target community by placing the IP
address of the upstream node 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 upstream node's
address is as determined in section 6.1.
The PE then advertises this route to the upstream node.
6.3. PIM-SM in ASM mode for Internet Multicast
This specification allows two options for supporting Internet
Multicast with PIM-SM in ASM mode. The first option does not transit
IP multicast shared trees over the MPLS network. The second option
does transit shared trees over the MPLS network and relies on shared
tree to source tree switchover.
6.3.1. Option 1
This option does not transit IP multicast shared trees over the MPLS
network. Therefore, when an (egress) PE creates (*, G) state (as a
result of receiving PIM messages on one of its IP multicast
interfaces), the PE does not propagate this state using Leaf A-D
Rekhter [Page 12]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
routes.
6.3.1.1. Originating Source Active auto-discovery routes
Whenever as a result of receiving PIM Register or MSDP messages an RP
discovers a new multicast source the RP SHOULD originate a BGP Source
Active auto-discovery route. Similarly whenever as a result of
receiving MSDP messages a PE, that is not configured as a RP,
discovers a new multicast source the PE SHOULD originate a BGP Source
Active auto-discovery route. The BGP Source Active auto-discovery
route carries a single MCAST-VPN NLRI constructed as follows:
+ The RD in this NLRI is set to 0.
+ The Multicast Source field MUST be set to S. The Multicast
Source Length field is set appropriately to reflect this.
+ The Multicast Group field MUST be set to G. The Multicast Group
Length field is set appropriately to reflect this.
To constrain distribution of the Source Active auto-discovery route
to the AS of the advertising RP this route SHOULD carry the NO_EXPORT
Community ([RFC1997]).
Using the normal BGP procedures the Source Active auto-discovery
route is propagated to all other PEs within the AS.
Whenever the RP discovers that the source is no longer active, the RP
MUST withdraw the Source Active auto-discovery route, if such a route
was previousely advertised by the RP.
6.3.1.2. Receiving BGP Source Active auto-discovery route by PE
When as a result of receiving PIM messages on one of its IP multicast
interfaces an (egress) PE creates in its Tree Information Base (TIB)
a new (*, G) entry with a non-empty outgoing interface list that
contains one or more IP multicast interfaces, the PE MUST check if it
has any Source Active auto-discovery routes for that G. If there is
such a route, S of that route is reachable via an MPLS interface, and
the PE does not have (S, G) state in its TIB for (S, G) carried in
the route, then the PE originates a Leaf A-D routes carrying that (S,
G), as specified in Section "Leaf A-D Route for Internet Multicast".
When an (egress) PE receives a new Source Active auto-discovery
route, the PE MUST check if its TIB contains an (*, G) entry with the
same G as carried in the Source Active auto-discovery route. If such
Rekhter [Page 13]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
an entry is found, S is reachable via an MPLS interface, and the PE
does not have (S, G) state in its TIB for (S, G) carried in the
route, then the PE originates a Leaf A-D routes carrying that (S, G),
as specified in Section "Leaf A-D Route for Internet Multicast".
6.3.1.3. Handling (S, G, RPTbit) state
Creation and deletion of (S, G, RPTbit) state on a PE that resulted
from receiving PIM messages on one of its IP multicast interfaces
does not result in any BGP actions by the PE.
6.3.2. Option 2
This option does transit IP multicast shared trees over the MPLS
network. Therefore, when an (egress) PE creates (*, G) state (as a
result of receiving PIM messages on one of its IP multicast
interfaces), the PE does propagate this state using Leaf A-D routes.
6.3.2.1. Originating Source Active auto-discovery routes
Whenever a PE creates an (S, G) state as a result of receiving Leaf
A-D routes associated with Internet multicast service, if S is
reachable via one of the IP multicast capable interfaces, and the PE
determines that G is in the PIM-SM in ASM mode range, the PE MUST
originate a BGP Source Active auto-discovery route. The route carries
a single MCAST-VPN NLRI constructed as follows:
+ The RD in this NLRI is set to 0.
+ The Multicast Source field MUST be set to S. The Multicast
Source Length field is set appropriately to reflect this.
+ The Multicast Group field MUST be set to G. The Multicast Group
Length field is set appropriately to reflect this.
To constrain distribution of the Source Active auto-discovery route
to the AS of the advertising PE this route SHOULD carry the NO_EXPORT
Community ([RFC1997]).
Using the normal BGP procedures the Source Active auto-discovery
route is propagated to all other PEs within the AS.
Whenever the PE deletes the (S, G) state that was previously created
as a result of receiving a Leaf A-D route for (S, G), the PE that
deletes the state MUST also withdraw the Source Active auto-discovery
Rekhter [Page 14]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
route, if such a route was advertised when the state was created.
6.3.2.2. Receiving BGP Source Active auto-discovery route
Procedures for receiving BGP Source Active auto-discovery routes are
the same as with Option 1.
6.3.2.3. Pruning Sources off the Shared Tree
If after receiving a new Source Active auto-discovery route for (S,G)
a PE determines that (a) it has the (*, G) entry in its TIB, (b) the
incoming interface list (iif) for that entry contains one of the IP
interfaces, (c) a MPLS LSP is in the outgoing interface list (oif)
for that entry, and (d) the PE does not originate a Leaf A-D route
for (S,G), then the PE MUST transition the (S,G,rpt) downstream state
to the Prune state. [Conceptually the PIM state machine on the PE
will act "as if" it had received Prune(S,G,Rpt) from some other PE,
without actually having received one.] Depending on the (S,G,rpt)
state on the iifs, this may result in the PE using PIM procedures to
prune S off the Shared (*,G) tree.
Transitioning the state machine to the Prune state SHOULD be done
after a delay that is controlled by a timer. The value of the timer
MUST be configurable. The purpose of this timer is to ensure that S
is not pruned off the shared tree until all PEs have had time to
receive the Source Active A-D route for (S,G).
The PE MUST keep the (S,G,rpt) downstream state machine in the Prune
state for as long as (a) the outgoing interface list (oif) for (*, G)
contains a MPLS LSP, and (b) the PE has at least one Source Active
auto-discovery route for (S,G), and (c) the PE does not originate the
Leaf A-D route for (S,G). Once either of these conditions become no
longer valid, the PE MUST transition the (S,G,rpt) downstream state
machine to the NoInfo state.
Note that except for the scenario described in the first paragraph of
this section, in all other scenarios relying solely on PIM procedures
on the PE is sufficient to ensure the correct behavior when pruning
sources off the shared tree.
6.3.2.4. More on handling (S, G, RPTbit) state
Creation and deletion of (S, G, RPTbit) state on a PE that resulted
from receiving PIM messages on one of its IP multicast interfaces
does not result in any BGP actions by the PE.
Rekhter [Page 15]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
7. Egress ABR Procedures
This section describes Egress ABR Procedures for constructing
segmented inter-area P2MP LSP.
When an egress ABR receives a 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.
If the RD of the received A-D route is not set to all 0s or all 1s,
then the egress ABR MUST find a S-PMSI or I-PMSI route whose NLRI has
the same value as the Route Key field of the received Leaf A-D route.
If such a matching route is found then the Leaf A-D route MUST be
accepted else it MUST be discarded. If the Leaf A-D route is accepted
and if its the first Leaf A-D route update for the Route Key field in
the route or the withdrawl of the last Leaf A-D route for the Route
Key field then the following procedures will be executed.
If the RD of the received A-D route is set to all 0s or all 1s then
the received Leaf A-D route is for Internet Multicast. In that case
for the following procedure the Route Prefix is set to all fields of
the Route Key minus the Ingress PE address. If this is the first Leaf
A-D route update for this Route Prefix or the withdrawl of the last
Leaf A-D route for the Route Prefix then the following procedures
will be executed.
While generating a Leaf A-D route update, 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). In
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 egress ABR
constructs an IP-based Route Target community by placing the IP
address of the upstream node 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 upstream node's IP address is the IP address determined from the
Global Administrator field of the Inter-area P2MP Segmented Next-hop
Extended Community, where this Extended Community is obtained as
Rekhter [Page 16]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
follows. When the Leaf A-D route is for MVPN or VPLS then this
Extended Community is the one included in the I-S/PMSI A-D route that
matches the Leaf A-D route. When the Leaf A-D route is for Internet
Multicast then this Extended Community is obtained from the best
unicast route to the Ingress PE. The Ingress PE address is
determined from the received Leaf A-D route. The best unicast route
MUST first be determined from multicast SAFI i.e., SAFI 2 routes, if
present.
The ABR then advertises this Leaf A-D route to the upstream node
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.
When Ingress Replication is used to instantiate the backbone area
segment then the Leaf A-D route originated by the egress ABR MUST
carry a downstream assigned label in the P-Tunnel Attribute where the
P-Tunnel type is set to Ingress Replication. An ABR MUST assign a
distinct MPLS label for each Leaf A-D route originated by the ABR.
In order to support Internet Multicast an egress ABR MUST auto-
configure an import Route Target with the global administrator field
set to the AS of the ABR and the local administrator field set to 0.
When the Leaf A-D route is for Internet Multicast and if the
following conditions hold true:
- Its not the first Leaf A-D route for the Route Prefix,
where the Route Prefix is determined as described above
- The set of ingress PEs associated with the Route Prefix
changes as a result of the new Leaf A-D route.
- The ABR determines based on local policy to propagate
the Leaf A-D route towards a different ingress PE than
the one to which the Leaf A-D route is being currently
propagated.
Then the egress ABR MUST originate the Leaf A-D route as described in
this section.
If the received Leaf A-D route is the last Leaf A-D route for the
Route Key for MVPN or VPLS or for the Route Prefix, as described
above, for Internet Multicast, then the ABR must withdraw the
Rekhter [Page 17]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
previously advertised Leaf A-D route.
7.1. P2MP LSP as the Intra-Area LSP in the Egress Area
This section describes procedures for using intra-area P2MP LSPs in
the egress area. The procedures that are common to both P2MP RSVP-TE
and P2MP LDP are described first, followed by procedures that are
specific to the signaling protocol.
When P2MP LSPs are used as the intra-area LSPs, note that an existing
intra-area P2MP LSP may be used solely for a particular inter-area
P2MP service LSP, or for other inter-area P2MP 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.
7.1.1. RD of the received Leaf-AD route is not zero or all ones
When the RD of the received Leaf A-D route is not set to zero or all
ones 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 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 re-advertised route MUST carry the
Inter-area P2MP Segmented Next-Hop Extended Community.
The PMSI Tunnel attribute of the re-advertised route specifies either
an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP 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 segments of multiple MVPN or VPLS S-PMSI service LSPs are carried
over a given intra-area P2MP LSP, each of these segments MUST carry a
distinct upstream-assigned label, even 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
Rekhter [Page 18]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
the egress ABRs).
7.1.2. RD of the received Leaf A-D route is zero or all ones
When the RD of the received Leaf A-D route is set to zero or all ones
then this is the case of inter-area P2MP service LSP being associated
with the Internet multicast service. The procedures for this are
described below.
7.1.2.1. Internet Multicast and S-PMSI A-D Routes
This section applies only if it is desirable to send a particular
Internet Multicast flow to only those egress PEs that have receivers
in a particular (S, G) or a particular (*, G) multicast flow.
The egress ABR MUST originate a S-PMSI A-D route. The PMSI Tunnel
attribute of the route MUST contain 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 egress ABR MUST advertise this route into
the backbone area. The Route Target of this route is an AS specific
route-target with the AS set to the AS of the advertising ABR while
the local administrator field is set to 0.
7.1.2.2. Internet Multicast and Wildcard S-PMSI A-D Routes
It may be desirable for an ingress PE to aggregate Internet Multicast
routes over a single Inter-area P2MP LSP. This can be achieved using
wildcard, i.e., (*,*) S-PMSI A-D routes. An ingress PE MAY advertise
a wildcard S-PMSI route as described in section "Ingress PE
Procedures". If the ingress PE does indeed originate such a route the
egress ABR would receive this route from the ingress ABR and MUST re-
advertise it with the PMSI Tunnel Attribute containing the identifier
of the intra-area P2MP LSP in the egress area and an upstream
assigned label assigned to the inter-area wildcard S-PMSI.
7.1.3. Internet Multicast and the Expected Upstream Node
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
node. The expected node is the node towards which the Leaf A-D route
Rekhter [Page 19]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
is sent by the egress PE. Packets received from another upstream
node for that (S, G) MUST be dropped. To allow the egress PE to
determine the sender upstream node, 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.
Further the egress ABR MUST first push onto the label stack the
upstream assigned label advertised in the S-PMSI route, if the label
is not an Implicit NULL.
7.1.4. P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area
The procedures above are sufficient if P2MP LDP LSPs are used as the
Intra-area P2MP LSP in the Egress area.
7.1.5. 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).
When the RD of the received Leaf A-D route is zero or all ones, then
the procedures are as described in section 7.1.2 ("RD of the
received Leaf A-D route is zero or all ones").
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.
7.2. Ingress Replication in the Egress Area
When Ingress Replication is used to instantiate the egress area
segment then the Leaf A-D route advertised by the egress PE MUST
carry a downstream assigned label in the P-Tunnel Attribute where the
P-Tunnel type is set to Ingress Replication. We will call this the
egress PE downstream assigned label.
The egress ABR MUST forward packets received from the backbone area
intra-area segment, for a particular inter-area P2MP LSP, to all the
egress PEs from which the egress ABR has imported a Leaf A-D route
for the inter-area P2MP LSP. A packet to a particular egress PE is
Rekhter [Page 20]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
encapsulated, by the egress ABR, using a MPLS label stack the bottom
label of which is the egress PE downstream assigned label. The top
label is the P2P RSVP-TE or the MP2P LDP label to reach the egress
PE.
Note that these procedures ensures that an egress PE always receives
packets only from the expected upstream PE.
8. Ingress ABR Procedures for constructing segmented inter-area P2MP LSP
When an ingress ABR receives a 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.
These procedures are the same as in the section "Egress ABR
Procedures" with egress ABR replaced with ingress ABR, backbone area
replaced with ingress area and backbone area segment replaced with
ingress area segment.
In order to support Internet Multicast the ingress ABR MUST auto-
configure an import Route Target with the global administrator field
set to the AS of the ABR and the local administrator field set to 0.
8.1. P2MP 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 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 "Egress ABR Procedures" and sub-section "P2MP LSP
as the Intra-Area LSP in the Egress Area".
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 the procedures are the same as in section
"Egress ABR Procedures", and and sub-section "P2MP LSP as the Intra-
Area LSP in the Egress Area", with egress ABR replaced with the
ingress ABR. It is to be noted that if the backbone area uses
wildcard S-PMSI then the egress area also must use wildcard S-PMSI
for Internet Multicast or the ABRs must merge the wildcard S-PMSI
onto the egress area (S, G) or (*, G) S-PMSI. The procedures for such
merge require IP processing on the ABRs.
Rekhter [Page 21]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
8.2. Ingress Replication in the Backbone Area
When Ingress Replication is used to instantiate the backbone area
segment then the Leaf A-D route advertised by the egress ABR MUST
carry a downstream assigned label in the P-Tunnel Attribute where the
P-Tunnel type is set to Ingress Replication. We will call this the
egress ABR downstream assigned label. The egress ABR MUST assign a
distinct MPLS label for each Leaf A-D route originated by the ABR.
The ingress ABR MUST forward packets received from the ingress area
intra-area segment, for a particular inter-area P2MP LSP, to all the
egress ABRs from which the ingress ABR has imported a Leaf A-D route
for the inter-area P2MP LSP. A packet to a particular egress ABR is
encapsulated, by the inress ABR, using a MPLS label stack the bottom
label of which is the egress ABR downstream assigned label. The top
label is the P2P RSVP-TE or the MP2P LDP label to reach the egress
ABR.
9. Ingress PE/ASBR Procedures
This section describes Ingress PE/ASBR procedures for constructing
segmented inter-area P2MP LSP.
When an ingress PE/ASBR receives a Leaf auto-discovery route and the
Route Target extended community carried by the route contains the IP
address of this PE/ASBR, then the following procedures will be
executed.
If the RD of the received A-D route is not set to all 0s or all 1s,
then the egress ABR MUST find a S-PMSI or I-PMSI route whose NLRI has
the same value as the Route Key field of the received Leaf A-D route.
If such a matching route is found then the Leaf A-D route MUST be
accepted else it MUST be discarded. If the Leaf A-D route is accepted
then it MUST be processed as per MVPN or VPLS procedures.
If the RD of the received A-D route is set to all 0s or all 1s then
the received Leaf A-D route is for Internet Multicast. In that case
for the following procedure the Route Prefix is set to all fields of
the Route Key minus the Ingress PE address. If this is the first Leaf
A-D route update for this Route Prefix or the withdrawl of the last
Leaf A-D route for the Route Prefix then the following procedures
will be executed. 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 update. 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
Rekhter [Page 22]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
route withdrawl.
9.1. P2MP 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 LSP is
used as the the intra-area LSP in the ingress area, then the
procedures for binding the ingress area segment of the inter-area
P2MP LSP to the intra-area P2MP LSP in the ingress area, are the same
as in section "Egress ABR Procedures" and sub-section "P2MP LSP as
the Intra-Area LSP in the Egress Area".
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 the ingress PE may originate a S-PMSI route
with the RD, multicast source, multicast group fields being the same
as those in the received Leaf A-D route.
Further an ingress PE may originate a wildcard S-PMSI route as per
the procedures in [MVPN-WILDCARD-SPMSI] with the RD set to 0. This
route may be originated by the ingress PE based on configuration or
based on the import of a Leaf A-D route with RD set to 0. If an
ingress PE originates such a route, then the ingress PE may decide
not to originate (S, G) or (*, G) S-PMSI routes.
It is to be noted that if ingress area uses wildcard S-PMSI then the
backbone area also must use wildcard S-PMSI for Internet Multicast or
the ABRs must merge the wildcard S-PMSI onto the backbone area (S, G)
or (*, G) S-PMSI. The procedures for such merge require IP processing
on the ABRs.
9.2. Ingress Replication in the Ingress Area
When Ingress Replication is used to instantiate the ingress area
segment then the Leaf A-D route advertised by the ingress ABR MUST
carry a downstream assigned label in the P-Tunnel Attribute where the
P-Tunnel type is set to Ingress Replication. We will call this the
ingress ABR downstream assigned label. The ingress ABR MUST assign a
distinct MPLS label for each Leaf A-D route originated by the ABR.
The ingress PE/ASBR MUST forward packets received from the CE, for a
particular inter-area P2MP LSP, to all the ingress ABRs from which
the ingress PE/ASBR has imported a Leaf A-D route for the inter-area
P2MP LSP. A packet to a particular ingress ABR is encapsulated, by
the inress PE/ASBR, using a MPLS label stack the bottom label of
which is the ingress ABR downstream assigned label. The top label is
the P2P RSVP-TE or the MP2P LDP label to reach the ingress ABR.
Rekhter [Page 23]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
10. Common Tunnel Type in the Ingress and Egress Areas
For a given inter-area service P2MP LSP, the PE/ASBR that is the root
of that LSP controls the tunnel type of the intra-area P-tunnel that
carries the ingress area segment of that LSP. However, the tunnel
type of the intra-area P-tunnel that carries the backbone area
segment of that LSP may be different from the tunnel type of the
intra-area P-tunnels that carry the ingress area segment and the
egress area segment of that LSP. In that situation if for a given
inter-area P2MP LSP it is desirable/necessary to use the same tunnel
type for the intra-area P-tunnels that carry the ingress area segment
and the egress area segment of that LSP, then the following
procedures on the ingress ABR and egress ABR provide this
functionality.
When an ingress ABR re-advertises into the backbone area a BGP MVPN
I-PMSI, or S-PMSI A-D route, or VPLS A-D route, the ingress ABR
places the PMSI Tunnel attribute of this route into the ATTR_SET BGP
Attribute [L3VPN-IBGP], adds this attribute to the re-advertised
route, and then replaces the original PMSI Tunnel attribute with a
new one (note, that the Tunnel type of the new attribute may be
different from the Tunnel type of the original attribute).
When an egress ABR re-advertises into the egress area a BGP MVPN I-
PMSI or S-PMSI A-D route, or VPLS A-D route, if the route carries the
ATTR_SET BGP attribute [L3VPN-IBGP], then the ABR sets the Tunnel
type of the PMSI Tunnel attribute in the re-advertised route to the
Tunnel type of the PMSI Tunnel attribute carried in the ATTR_SET BGP
attribute, and removes the ATTR_SET from the route.
11. Placement of Ingress and Egress PEs
As described in earlier sections, procedures in this document allow
the placement of ingress and egress PEs in the backbone area. They
also allow the placement of egress PEs in the ingress area or the
placement of ingress PEs in the egress area.
For instance ABRs in the backbone area may act as ingress and egress
PEs for Internet Multicast, as per the ingress and egress PE
definition in this document. This may be the case if the service is
Internet Multicast and relies on Internet Multicast in the ingress
and egress areas and its desirable to carry Internet Multicast over
MPLS in the backbone area. This may also be the case if the service
is Multicast VPN and the P-tunnel technology in the ingress and
egress areas uses PIM based IP/GRE P-tunnels. As far as the ABRs are
concerned PIM signaling for such P-Tunnels is handled as per the
ingress/egress PE Internet Multicast procedures in this document. To
Rekhter [Page 24]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
facilitate this the ABRs may advertise their loopback addresses in
BGP using multicast-SAFI i.e., SAFI 2, if non-congruence between
unicast and multicast is desired.
12. Data Plane
This section describes the data plane procedures on the ABRs, ingress
PEs, egress PEs and transit routers.
12.1. Data Plane Procedures on an ABR
When procedures in this document are followed to signal inter-area
P2MP Segmented LSPs then ABRs are required to perform only MPLS
switching. When an ABR receives a MPLS packet from an "incoming"
intra-area segment of the inter-area P2MP Segmented LSP, it forwards
the packet, based on MPLS switching, onto another "outgoing" intra-
area segment of the inter-area P2MP Segmented LSP.
If the outgoing intra-area segment is instantiated using a P2MP LSP,
and if there is a one-to-one mapping between the outgoing intra-area
segment and the P2MP LSP, then the ABR MUST pop the incoming
segment's label stack and push the label stack of the outgoing P2MP
LSP. If there is a many-to-one mapping between outgoing intra-area
segments and the P2MP LSP then the ABR MUST pop the incoming
segment's label stack and first push the upstream assigned label
corresponding to the outgoing intra-area segment, if such a label has
been assigned, and then push the label stack of the outgoing P2MP
LSP.
If the outgoing intra-area segment is instantiated using ingress
replication then the ABR must pop the incoming segment's label stack
and replicate the packet once to each leaf ABR or PE of the outgoing
intra-area segment. The label stack of the packet sent to each such
leaf MUST first include a downstream assigned label assigned by the
leaf to the segment, followed by the label stack of the P2P or MP2P
LSP to the leaf.
12.2. Data Plane Procedures on an Egress PE
An egress PE must first identify the inter-area P2MP segmented LSP
based on the incoming label stack. After this identification the
egress PE must forward the packet using the application that is bound
to the inter-area P2MP segmented LSP.
Note that the application specific forwarding for MVPN service may
Rekhter [Page 25]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
require the egress PE to determine whether the packets were received
from the expected sender PE. When the application is MVPN then the
FEC of an inter-area P2MP Segmented LSP is at the granularity of the
sender PE. Note that MVPN intra-AS I-PMSI A-D routes and S-PMSI A-D
routes both carry the Originating Router IP Address. Thus an egress
PE could associate the data arriving on P-tunnels advertised by these
routes with the Originating Router IP Address carried by these routes
which is the same as the ingress PE. Since a unique label stack is
associated with each such FEC, the egress PE can determine the sender
PE from the label stack.
Likewise for VPLS service for the purposes of MAC learning the egress
PE must be able to determine the "VE-ID" from which the packets have
been received. The FEC of the VPLS A-D routes carries the VE-ID. Thus
an egress PE could associate the data arriving on P-tunnels
advertised by these routes with the VE-ID carried by these routes.
Since a unique label stack is associated with each such FEC, the
egress PE can perform MAC learning for packets received from a given
VE-ID.
When the application is Internet Multicast it is sufficient for the
label stack to include identification of the sender upstream node.
When P2MP LSPs are used this requires that PHP MUST be turned off.
When Ingress Replication is used the egress PE knows the incoming
downstream assigned label to which it has bound a particlar (S/*, G)
and must accept packets with only that label for that (S/*. G).
12.3. Data Plane Procedures on an Ingress PE
The Ingress PE must perform application specific forwarding
procedures to identify the outgoing inta-area segment of an incoming
packet.
If the outgoing intra-area segment is instantiated using a P2MP LSP,
and if there is a one-to-one mapping between the outgoing intra-area
segment and the P2MP LSP, then the ingress PE MUST encapsulate the
packet in the label stack of the outgoing P2MP LSP. If there is a
many-to-one mapping between outgoing intra-area segments and the P2MP
LSP then the PE MUST first push the upstream assigned label
corresponding to the outgoing intra-area segment, if such a label has
been assigned,
and then push the label stack of the outgoing P2MP LSP.
If the outgoing intra-area segment is instantiated using ingress
replication then the PE must replicate the packet once to each leaf
ABR or PE of the outgoing intra-area segment. The label stack of the
packet sent to each such leaf MUST first include a downstream
Rekhter [Page 26]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
assigned label assigned by the leaf to the segment, followed by the
label stack of the P2P or MP2P LSP to the leaf.
12.4. Data Plane Procedures on Transit Routers
When procedures in this document are followed to signal inter-area
P2MP Segmented LSPs then tansit routers in each area perform only
MPLS switching.
13. IANA Considerations
This document defines a new BGP Extended Community called "Inter-area
P2MP Segmented Next-Hop". This community is IP Address Specific, of
an extended type, and is transitive. A codepoint for this community
should be assigned both from the IPv4 Address Specific Extended
Community registry, and from the IPv6 Address Specific Extended
Community registry. The same code point should be assigned from both
registries.
14. Security Considerations
These will be spelled out in a future revision.
15. References
15.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
[L3VPN-IBGP] "Internal BGP as PE-CE protocol", Pedro Marques, et al.,
draft-ietf-l3vpn-ibgp, work in progress
Rekhter [Page 27]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
15.2. Informative References
[SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al.,
draft-leymann-mpls-seamless-mpls
16. 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
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
Nicolai Leymann
Deutsche Telekom AG
Winterfeldtstrasse 21
Berlin 10781
DE
Email: n.leymann@telekom.de
Samir Saad
AT&T
Email: ss2539@att.com
Rekhter [Page 28]
Internet Draft draft-raggarwa-mpls-seamless-mcast-03.txt March 2011
Rekhter [Page 29]