MVPN: Using Bidirectional P-Tunnels
draft-ietf-l3vpn-mvpn-bidir-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Eric C. Rosen , IJsbrand Wijnands , Yiqun Cai , Arjen Boers | ||
| Last updated | 2013-04-10 | ||
| Replaces | draft-rosen-l3vpn-mvpn-bidir | ||
| Replaced by | draft-ietf-bess-mvpn-bidir, RFC 7582 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-l3vpn-mvpn-bidir-05
L3VPN Working Group Eric C. Rosen (Editor)
Internet Draft IJsbrand Wijnands
Intended Status: Standards Track Cisco Systems, Inc.
Expires: October 10, 2013
Updates: 6513,6625
Yiqun Cai
Microsoft
Arjen Boers
April 10, 2013
MVPN: Using Bidirectional P-Tunnels
draft-ietf-l3vpn-mvpn-bidir-05.txt
Abstract
A set of prior RFCs specify procedures for supporting multicast in
BGP/MPLS IP VPNs. These procedures allow customer multicast data to
travel across a service provider's backbone network through a set of
multicast tunnels. The tunnels are advertised in certain BGP "auto-
discovery" routes, by means of a BGP attribute known as the "Provider
Multicast Service Interface (PMSI) Tunnel attribute". Encodings have
been defined that allow the PMSI Tunnel attribute to identify
bidirectional (multipoint-to-multipoint) multicast distribution
trees. However, the prior RFCs do not provide all the necessary
procedures for using bidirectional tunnels to support multicast VPNs.
This document updates RFCs 6513 and 6625 by specifying those
procedures. In particular, it specifies the procedures for assigning
customer multicast flows (unidirectional or bidirectional) to
specific bidirectional tunnels in the provider backbone, for
advertising such assignments, and for determining which flows have
been assigned to which tunnels.
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.
Rosen, et al. [Page 1]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
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) 2013 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.
Rosen, et al. [Page 2]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
Table of Contents
1 Introduction .......................................... 4
1.1 Terminology ........................................... 4
1.2 Overview .............................................. 8
1.2.1 Bidirectional P-tunnel Technologies ................... 9
1.2.2 Reasons for Using Bidirectional P-tunnels ............. 9
1.2.3 Knowledge of Group-to-RP and/or Group-to-RPA Mappings . 11
1.2.4 PMSI Instantiation Methods ............................ 11
2 The All BIDIR-PIM Wild Card ........................... 13
3 Using Bidirectional P-Tunnels ......................... 14
3.1 Procedures Specific to the Tunneling Technology ....... 14
3.1.1 BIDIR-PIM P-Tunnels ................................... 14
3.1.2 MP2MP LSPs ............................................ 15
3.2 Procedures Specific to the PMSI Instantiation Method .. 15
3.2.1 Flat Partitioning ..................................... 15
3.2.1.1 When an S-PMSI is a 'Match for Transmission' .......... 17
3.2.1.2 When an I-PMSI is a 'Match for Transmission' .......... 19
3.2.1.3 When an S-PMSI is a 'Match for Reception' ............. 19
3.2.1.4 When an I-PMSI is a 'Match for Reception .............. 20
3.2.2 Hierarchical Partitioning ............................. 21
3.2.2.1 Advertisement of PE Distinguisher Labels .............. 22
3.2.2.2 When an S-PMSI is a 'Match for Transmission' .......... 23
3.2.2.3 When an I-PMSI is a 'Match for Transmission' .......... 24
3.2.2.4 When an S-PMSI is a 'Match for Reception' ............. 25
3.2.2.5 When an I-PMSI is a 'Match for Reception .............. 26
3.2.3 Unpartitioned ......................................... 27
3.2.3.1 When an S-PMSI is a 'Match for Transmission' .......... 28
3.2.3.2 When an S-PMSI is a 'Match for Reception' ............. 29
3.2.4 Minimal Feature Set for Compliance .................... 29
4 IANA Considerations ................................... 30
5 Security Considerations ............................... 30
6 Acknowledgments ....................................... 30
7 Authors' Addresses .................................... 30
8 Normative References .................................. 31
9 Informative References ................................ 32
Rosen, et al. [Page 3]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
1. Introduction
The RFCs that specify multicast support for BGP/MPLS IP VPNs ([MVPN],
[MVPN-BGP], [MVPN-WILDCARDS]) allow customer multicast data to be
transported across a service provider's network though a set of
multicast tunnels. These tunnels are advertised in BGP "auto-
discovery" (A-D) routes, by means of a BGP attribute known as the
"Provider Multicast Service Interface (PMSI) Tunnel attribute". The
base specifications allow the use of bidirectional
(multipoint-to-multipoint) multicast distribution trees, and describe
how to encode the identifiers for bidirectional trees into the PMSI
Tunnel attribute. However, those specifications do not provide all
the necessary detailed procedures for using bidirectional tunnels;
the full specification of these procedures was considered to be
outside the scope of those documents. The purpose of this document
is to provide all the necessary procedures for using bidirectional
trees in a service provider's network to carry the multicast data of
VPN customers.
1.1. Terminology
This document uses terminology from [MVPN] and, in particular, uses
the prefixes "C-" and "P-", as specified in Section 3.1 of [MVPN], to
distinguish addresses in the "customer address space" from addresses
in the "provider address space". The following terminology and
acronyms are particularly important in this document:
- MVPN
Multicast Virtual Private Network -- a VPN [L3VPN] in which
multicast service is offered.
- VRF
VPN Routing and Forwarding table [L3VPN].
- PE
A Provider Edge router, as defined in [L3VPN].
- LSP
An MPLS Label Switched Path.
Rosen, et al. [Page 4]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
- P2MP Point-to-Multipoint.
- MP2MP
Multipoint-to-multipoint.
- Unidirectional
Adjective for a multicast distribution tree in which all traffic
travels downstream from the root of the tree. Traffic can enter
a unidirectional tree only at the root. A P2MP LSP is one type
of unidirectional tree. Multicast distribution trees set up by
PIM-SM [PIM] are also unidirectional trees.
- Bidirectional
Adjective for a multicast distribution tree in which traffic may
travel both upstream (towards the root) and downstream (away from
the root). Traffic may enter a bidirectional tree at any node.
A MP2MP LSP is one type of bidirectional tree. Multicast
distribution trees created by BIDIR-PIM [BIDIR-PIM] are also
bidirectional trees.
- P-tunnel
A tunnel through the network of one or more Service Providers
(SPs). In this document, the P-tunnels we speak of are are
instantiated as bidirectional multicast distribution trees.
- C-S
Multicast Source. A multicast source address, in the address
space of a customer network.
- C-G
Multicast Group. A multicast group address (destination address)
in the address space of a customer network.
- C-multicast flow or C-flow
A customer multicast flow. A C-flow travels through VPN customer
sites on a multicast distribution tree set up by the customer.
These trees may be unidirectional or bidirectional, depending
upon the multicast routing protocol used by the customer. A
C-flow travels between VPN customer sites by traveling through
P-tunnels.
Rosen, et al. [Page 5]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
A C-flow from a particular customer source is identified by the
ordered pair (source address, group address), where each address
is in the customer's address space. The identifier of such a
C-flow is usually written as (C-S,C-G).
If a customer uses the "Any Source Multicast" (ASM) model, the
some or all of the customer's C-flows may be traveling along the
same "shared tree". In this case, we will speak of a "(C-*,C-G)"
flow to refer to a set of C-flows that travel along the same
shared tree in the customer sites.
- C-BIDIR flow or bidirectional C-flow
A C-flow that, in the VPN customer sites, travels along a
bidirectional multicast distribution tree. The term "C-BIDIR
flow" indicates that the customer's bidirectional tree has been
set up by BIDIR-PIM.
- RP
A "Rendezvous Point", as defined in [PIM].
- C-RP
A Rendezvous Point whose address is in the customer's address
space.
- RPA
A "Rendezvous Point Address", as defined in [BIDIR-PIM].
- C-RPA
An RPA in the customer's address space.
- P-RPA
An RPA in the Service Provider's address space
- Selective P-tunnel
A P-tunnel that is joined only by Provider Edge (PE) routers that
need to receive one or more of the C-flows that are traveling
through that P-tunnel.
- Inclusive P-tunnel
A P-tunnel that is joined by all PE routers that attach to sites
of a given MVPN.
Rosen, et al. [Page 6]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
- Intra-AS I-PMSI A-D route
Intra Autonomous System Inclusive Provider Multicast Service
Interface Auto-Discovery route. Carried in BGP Update messages,
these routes can be used to advertise the use of Inclusive
P-tunnels. See [MVPN-BGP] section 4.1.
- S-PMSI A-D route
Selective Provider Multicast Service Interface Auto-Discovery
route. Carried in BGP Update messages, these routes are used to
advertise the fact that a particular C-flow or a particular set
of C-flows is bound to (i.e., is traveling through) a particular
P-tunnel. See [MVPN-BGP] section 4.3.
- (C-S,C-G) S-PMSI A-D route
An S-PMSI A-D route whose NLRI ("Network Layer Reachability
Information") contains C-S in its "Multicast Source" field and
C-G in its "Multicast Group" field.
- (C-*,C-G) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its
"Multicast Source" field and C-G in its "Multicast Group" field.
See [MVPN-WILDCARDS].
- (C-*,C-*) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains the wildcard C-* in its
"Multicast Source" field and the wildcard C-* in its "Multicast
Group" field. See [MVPN-WILDCARDS].
- (C-*,C-*) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains the wildcard C-* in its
"Multicast Source" field and the wildcard C-* in its "Multicast
Group" field. See [MVPN-WILDCARDS].
- (C-*,C-BIDIR) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains the wildcard C-* in its
"Multicast Source" field and the wildcard "C-BIDIR" in its
"Multicast Group" field. See section 2 of this document.
Rosen, et al. [Page 7]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
- (C-S,C-*) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains C-S in its "Multicast
Source" field and the wildcard C-* in its "Multicast Group"
field. See [MVPN-WILDCARDS].
- Wildcard S-PMSI A-D route
A (C-*,C-G) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route, or
a (C-S,C-*) S-PMSI A-D route, or a (C-*,C-BIDIR) S-PMSI A-D
route.
- PTA
PMSI Tunnel attribute, a BGP attribute that identifies a
P-tunnel. See [MVPN-BGP] section 8.
The terminology used for categorizing S-PMSI A-D routes will also be
used for categorizing the S-PMSIs advertised by those routes. E.g.,
the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will be known
as a "(C-*,C-G) S-PMSI".
Familiarity with multicast concepts and terminology [PIM] is also
presupposed.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document, when and only when appearing in all caps, are to be
interpreted as described in [RFC2119].
1.2. Overview
The base documents for MVPN ([MVPN], [MVPN-BGP]) define a "PMSI
Tunnel Attribute" (PTA) that may be carried in the BGP "I-PMSI A-D
routes" and "S-PMSI A-D routes" that are defined therein. The base
documents define the way in which the identifier of a bidirectional
P-tunnel is encoded in the PTA. However, those documents do not
contain the full set of specifications governing the use
bidirectional P-tunnels; rather, those documents declare the full set
of specifications for using bidirectional P-tunnels to be outside
their scope. Similarly, the use of bidirectional P-tunnels
advertised in wildcard S-PMSI A-D routes by [MVPN-WILDCARDS] to be
"out of scope."
This document provides the necessary specifications to allow the use
of bidirectional P-tunnels to provide MVPN support. This includes
Rosen, et al. [Page 8]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
the procedures for assigning C-flows to specific bidirectional
P-tunnels, for advertising the fact that a particular C-flow has been
assigned to a particular bidirectional P-tunnel, and for determining
the bidirectional P-tunnel on which a given C-flow may be expected.
The C-flows carried on bidirectional P-tunnels may themselves be
either unidirectional or bidirectional. Procedures are provided for
both cases.
This document does not specify any new data encapsulations for
bidirectional P-tunnels. Section 12 of [MVPN] applies unchanged.
With regard to the procedures for using bidirectional P-tunnels to
instantiate PMSIs, if there is any conflict between the procedures
specified in this document and the procedures of [MVPN], [MVPN-BGP],
or [MVPN-WILDCARDS], the procedures of this document take precedence.
The use of bidirectional P-tunnels in extranets [MVPN_XNET] is
outside the scope of this document. The use of bidirectional
P-tunnels as "segmented P-tunnels" (see [MVPN] section 8 and various
sections of [MVPN-BGP] is also outside the scope of this doucment.
1.2.1. Bidirectional P-tunnel Technologies
This document supports two different technologies for creating and
maintaining bidirectional P-tunnels:
- Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that
are created through the use of the Label Distribution Protocol
(LDP) Multipoint-to-Multipoint extensions [mLDP].
- Multicast distribution trees that are created through the use of
BIDIR-PIM [BIDIR-PIM].
An implementation may be considered compliant with this document if
it provides either one of these tunneling technologies. Other
bidirectional tunnel technologies are outside the scope of this
document.
1.2.2. Reasons for Using Bidirectional P-tunnels
Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or
S-PMSIs. An SP may decide to use bidirectional P-tunnels to
instantiate certain I-PMSIs and/or S-PMSIs in order to provide its
customers with C-BIDIR support, using the "Partitioned Set of PEs"
technique discussed in [MVPN] section 11.2 and [RFC6517] section 3.6.
Rosen, et al. [Page 9]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
This technique can be used whether the C-BIDIR flows are being
carried on an I-PMSI or an S-PMSI.
An SP that does not need to provide C-BIDIR support may still decide
to use bidirectional P-tunnels, in order to save state in the
network's transit nodes. For example, if an MVPN has n PEs attached
to sites with multicast sources, and there is an I-PMSI for that
MVPN, instantiating the I-PMSI with unidirectional P-tunnels (i.e.,
with P2MP multicast distribution trees) requires n multicast
distribution trees, each one rooted at a different PE. If the I-PMSI
is instantiated by a bidirectional P-tunnel, a single multicast
distribution tree can be used. (It must be noted though that this
particular use of bidirectional P-tunnels is not compatible with the
duplicate prevention scheme of [MVPN] section 9.1.1, and thus would
only be used if the duplication prevision schemes of [MVPN] sections
9.1.2 or 9.1.3 are suitable.)
An SP may decide to use bidirectional P-tunnels for either or both of
these reasons.
These two reasons for using bidirectional P-tunnels are somewhat in
conflict with each other, since (as will be seen in subsequent
sections), the use of bidirectional P-tunnels for C-BIDIR support may
require multiple bidirectional P-tunnels. Each such P-tunnel is
associated with a particular "distinguished PE", and can only carry
those C-BIDIR flows whose C-RPAs are reachable through its
distinguished PE. However, on platforms that support MPLS
upstream-assigned labels [RFC5331], "PE Distinguisher Labels" can be
used to aggregate multiple bidirectional P-tunnels onto a single
"outer" bidirectional P-tunnel, thereby allowing one to provide
C-BIDIR support with minimal state at the transmit nodes.
Since there are two fundamentally different reasons for using
bidirectional P-tunnels, and since many deployed router platforms do
not support upstream-assigned labels at the current time, this
document specifies several different methods of using bidirectional
P-tunnels to instantiate PMSIs. We refer to these as "PMSI
Instantiation Methods". The method or methods deployed by any
particular SP will depend upon that SP's goals and engineering
tradeoffs, and upon the set of platforms deployed by that SP.
The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D
routes are not exactly the same as the rules for using unidirectional
P-tunnels, and the rules are also different for the different PMSI
instantiation methods. Subsequent sections of this document specify
the rules in detail.
Note that even if the reason for using bidirectional P-tunnels is to
Rosen, et al. [Page 10]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
provide C-BIDIR support, the same P-tunnels can also be used to carry
unidirectional C-flows, if that is the choice of the SP.
1.2.3. Knowledge of Group-to-RP and/or Group-to-RPA Mappings
If a VPN customer is making use of a particular "Any Source
Multicast" (ASM) group address, the PEs of that VPN generally need to
know the group-to-RP mappings that are used within the VPN. If a VPN
customer is making use of BIDIR-PIM group addresses, the PEs need to
know the group-to-RPA mappings that are used within the VPN.
Commonly, the PEs obtain this knowledge either through provisioning
or by participating in a dynamic "group-to-RP(A) mapping discovery
protocol" that runs within the VPN. However, the way in which this
knowledge is obtained is outside the scope of this document.
The PEs also need to be able to forward traffic towards the C-RPs
and/or C-RPAs, and to determine whether the next hop "interface" of
the route to a particular C-RP(A) is a VRF interface or a PMSI. This
is done by applying the procedures of [MVPN] section 5.1.
1.2.4. PMSI Instantiation Methods
This document specifies three methods for using bidirectional
P-tunnels to instantiate PMSIs: the Flat Partitioned Method, the
Hierarchical Partitioned Method, and the Unpartitioned Method.
- Partitioned Methods
In the Partitioned Methods, a particular PMSI is instantiated by
a set of bidirectional P-tunnels. These P-tunnels may be
aggregated (as "inner" P-tunnels) into a single "outer"
bidirectional P-tunnel ("Hierarchical Partitioning"), or they may
be unaggregated ("Flat Partitioning"). Any PE that joins one of
these P-tunnels can transmit a packet on it, and the packet will
be received by all the other PEs that have joined the P-tunnel.
For each such P-tunnel (each "inner" P-tunnel, in the case of
Hierarchical Partitioning) there is one PE that is its
"distinguished PE". When a PE receives a packet from a given
P-tunnel, the PE can determine from the packet's encapsulation
the P-tunnel is has arrived on, and can thus infer the identity
of the distinguished PE associated with the packet. This
association plays an important role in the treatment of the
packet, as specified later on in this document.
The number of P-tunnels needed (the number of "inner" P-tunnels
needed, if Hierarchical Partitioning is used) depends upon a
Rosen, et al. [Page 11]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
number of factors that are described later in this document.
The Hierarchical Partitioned Method requires the use of
upstream-assigned MPLS labels ("PE Distinguisher Labels"), and
requires the use of the PE Distinguisher Labels attribute in BGP.
The Flat Partitioned Method requires neither of these.
The Partitioned Method is a pre-requisite for implementing the
"Partitioned Sets of PEs" technique of supporting C-BIDIR, as
discussed in [MVPN] section 11.2.
The Flat Partitioned Method is a pre-requisite for implementing
the "Partial Mesh of MP2MP P-tunnels" technique for carrying
customer bidirectional (C-BIDIR) traffic, as discussed in [MVPN]
Section 11.2.3.
Note that a particular deployment may choose to use the
Partitioned Method for carrying the C-BIDIR traffic on
bidirectional P-tunnels, while carrying other traffic either on
unidirectional P-tunnels, or on bidirectional P-tunnels using the
Unpartitioned Method.
- Unpartitioned Method
In the Unpartitioned Method, a particular PMSI can be
instantiated by a single bidirectional P-tunnel. Any PE that
joins the tunnel can transmit a packet on it, and the packet will
be received by all the other PEs that have joined the tunnel.
The receiving PEs can determine the tunnel on which the packet
was transmitted, but they cannot determine which PE transmitted
the packet, nor can they associate the packet with any particular
"distinguished PE".
When the Unpartitioned Method is used, this document does not
mandate that only one bidirectional P-tunnel be used to
instantiate each PMSI. It allows for the case where more than
one P-tunnel is used. In this case, the transmitting PEs will
have a choice of which such P-tunnel to use when transmitting,
and the receiving PEs must be prepared to receive from any of
those P-tunnels. The use of multiple P-tunnels in this case
provides additional robustness, but no additional functionality.
I-PMSIs may be instantiated by bidirectional P-tunnels using either
the Partitioned (either Flat or Hierarchical) or the Unpartitioned
Method. The method used for a given MVPN is determined by
provisioning. It SHOULD be possible to provision this on a per-MVPN
basis, but all the VRFs of a single MVPN MUST be provisioned to use
the same method for the given MVPN's I-PMSI.
Rosen, et al. [Page 12]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
If a bidirectional P-tunnel is used to instantiate an S-PMSI
(including the case of a (C-*,C-*) S-PMSI), either the Partitioned
Method (either Flat or Hierarchical) or the Unpartitioned Method may
be used. The method used by a given VRF used is determined by
provisioning. It SHOULD be possible to provision this on a per-MVPN
basis, but all the VRFs of a single MVPN MUST be provisioned to use
the same method for those of their S-PMSIs that are instantiated by
bidirectional P-tunnels.
If the Partitioned Method is used, all the VRFs of a single MVPN MUST
be provisioned to use the same variant of the Partitioned Method,
i.e., either they must all use the Flat Partitioned Method, or they
must all use the Hierarchical Partitioned Method.
It is valid to use the Unpartitioned Method to instantiate the
I-PMSIs, while using one of the Partitioned Methods to instantiate
the S-PMSIs.
It is valid to instantiate some S-PMSIs by unidirectional P-tunnels
and others by bidirectional P-tunnels.
The procedures for the use of bidirectional P-tunnels, specified in
subsequent sections of this document, depend on both the tunnel
technology and on the PMSI instantiation method. Note that this
document does not necessarily specify procedures for every possible
combination of tunnel technology and PMSI instantiation method.
2. The All BIDIR-PIM Wild Card
When an MVPN customer is using BIDIR-PIM, it is useful to be able to
advertise an S-PMSI A-D route whose semantics are: "by default, all
BIDIR-PIM C-multicast traffic (within a given VPN) that has not been
bound to any other P-tunnel is bound to the bidirectional P-tunnel
identified by the PTA of this route". This can be especially useful
if one is using a bidirectional P-tunnel to carry the C-BIDIR flows,
while using unidirectional P-tunnels to carry other C-flows. To do
this, it is necessary to have a way to encode a (C-*,C-*) wildcard
that is restricted to BIDIR-PIM C-groups.
We therefore define a special value of the group wildcard, whose
meaning is "all BIDIR-PIM groups". The "BIDIR-PIM groups wildcard"
is encoded as a group field whose length is 8 bits and whose value is
zero. That is, the "multicast group length" field contains the value
0x08, and the "multicast group" field is a single octet containing
the value 0x00. We will use the notation (C-*,C-BIDIR) to refer to
the "all BIDIR-PIM groups" wildcard.
Rosen, et al. [Page 13]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
3. Using Bidirectional P-Tunnels
A bidirectional P-tunnel may be advertised in the PTA of an Intra-AS
I-PMSI A-D route or in the PTA of an S-PMSI A-D route. The
advertisement of a bidirectional P-tunnel in the PTA of an Inter-AS
I-PMSI A-D route is outside the scope of this document.
3.1. Procedures Specific to the Tunneling Technology
This section discusses the procedures that are specific to a given
tunneling technology (BIDIR-PIM or MP2MP mLDP), but that are
independent of the method (Unpartitioned, Flat Partitioned, or
Hierarchical Partitioned) used to instantiate a PMSI.
3.1.1. BIDIR-PIM P-Tunnels
Each BIDIR-PIM P-Tunnel is identified by a unique P-group address
[MVPN, section 3.1]. (The P-group address is called a "P-Multicast
Group" in [MVPN-BGP]). Section 5 of [MVPN-BGP] specifies the way to
identify a particular BIDIR-PIM P-tunnel in the PTA of an I-PMSI or
S-PMSI A-D route.
Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM
P-tunnels. A BIDIR-PIM P-group address is always associated with a
unique "Rendezvous Point Address" (RPA) in the SP's address space.
We will refer to this as the "P-RPA". Every PE needing to join a
particular BIDIR-PIM P-tunnel must be able to determine the P-RPA
that corresponds to the P-tunnel's P-group address. To construct the
P-tunnel, PIM Join/Prune messages are sent along the path from the PE
to the P-RPA. Any P routers along that path must also be able to
determine the P-RPA, so that they too can send PIM Join/Prune
messages towards it. The method of mapping a P-group address to an
RPA may be static configuration, or some automated means of RPA
discovery that is outside the scope of this specification.
If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an
S-PMSI, it is RECOMMENDED that the path from each PE in the tunnel to
the RPA consist entirely of point-to-point links. On a
point-to-point link, there is no ambiguity in determining which
router is upstream towards a particular RPA, so the BIDIR-PIM
"Designated Forwarder Election" is very quick and simple. Use of a
BIDIR-PIM P-tunnel containing multiaccess links is possible, but
considerably more complex.
The use of BIDIR-PIM P-tunnels to support the Hierarchical
Partitioned Method is outside the scope of this document.
Rosen, et al. [Page 14]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route
identifies a BIDIR-PIM tunnel, the originator of the route SHOULD NOT
include a PE Distinguisher Labels attribute. If it does, that
attribute MUST be ignored. When we say the attribute is "ignored",
we do not mean that its normal BGP processing is not done, but that
the attribute has no effect on the data plane. It MUST however be
treated by BGP as if it were an unsupported optional transitive
attribute. (PE Distinguisher Labels are used for the Hierarchical
Partitioning Method, but this document does not provide support for
the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.)
3.1.2. MP2MP LSPs
Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding
Equivalence Class) element" [mLDP]. The FEC element contains the IP
address of the "root node", followed by an "opaque value" that
identifies the MP2MP LSP uniquely in the context of the root node's
IP address. This opaque value may be configured or autogenerated,
and within an MVPN, there is no need for different root nodes to use
the same opaque value. The mLDP specification supports the use of
several different ways of constructing the tunnel identifiers. The
current specification does not place any restriction on the type of
tunnel identifier that might be used. However, a given
implementation might not support every possible type of tunnel
identifier.
Section 5 of [MVPN-BGP] specifies the way to identify a particular
MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route.
Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP
LSP.
3.2. Procedures Specific to the PMSI Instantiation Method
3.2.1. Flat Partitioning
The procedures of this section and its sub-sections apply when (and
only when) the Flat Partitioned Method is used. This method is
introduced in [MVPN] Section 11.2.3, where it is called "Partial Mesh
of MP2MP P-tunnels". This method can be used with MP2MP LSPs or with
BIDIR-PIM P-tunnels.
The Flat Partitioned Method may be used to instantiate the following
types of PMSI: I-PMSI, (C-*,C-*) S-PMSI, (C-*,C-BIDIR) S-PMSI, or
(C-*,C-G) S-PMSI where C-G is a bidirectional C-group.
Rosen, et al. [Page 15]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
When a PE originates an I-PMSI or S-PMSI A-D route whose PTA
specifies a bidirectional P-tunnel, the PE MUST be the root node of
the specified P-tunnel. It follows that two different PEs may not
advertise the same bidirectional P-tunnel. Any PE that receives a
packet from the P-tunnel can infer the identity of the P-tunnel from
the packet's encapsulation. Once the identity of the P-tunnel is
known, the root node of the P-tunnel is also known. The root node of
the P-tunnel on which the packet arrived is treated as the
"distinguished PE" for that packet.
If MP2MP LSPs are used, each P-tunnel MUST have have a distinct MP2MP
FEC (i.e., distinct combination of "root node" and "opaque value").
The PE advertising the tunnel MUST be the same PE identified in the
"root node" field of the MP2MP FEC that is encoded in the PTA.
If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a
distinct P-group address. The PE advertising the tunnel will be
considered to be the root node of the tunnel. Note that this creates
a unique mapping from P-group address to "root node".
The Flat Partitioned Method does not use upstream-assigned labels in
the data plane, and hence does not use the BGP PE Distinguisher
Labels attribute. When this method is used, I-PMSI and/or S-PMSI A-D
routes SHOULD NOT contain a PE Distinguisher Labels attribute; if
such an attribute is present in a received I-PMSI or S-PMSI A-D
route, it MUST be ignored. (When we say the attribute is "ignored",
we do not mean that its normal BGP processing is not done, but that
the attribute has no effect on the data plane. It MUST however be
treated by BGP as if it were an unsupported optional transitive
attribute.)
When the Flat Partitioned Method is used to implement the
"Partitioned Sets of PEs" method of supporting C-BIDIR, as discussed
in section 11.2 of [MVPN] and section 3.6 of [RFC6517], a C-BIDIR
flow MUST be carried only on an I-PMSI or on a (C-*,C-G),
(C-*,C-BIDIR), or (C-*,C-*) S-PMSI. A PE MUST NOT originate a
(C-S,C-G) S-PMSI A-D route for any C-G that is a C-BIDIR group.
Packets of a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI.
When the Flat Partitioned Method is used to instantiate the I-PMSIs
of a given MVPN, every PE in that MVPN that originates an Intra-AS
I-PMSI A-D route MUST include a PTA that specifies a bidirectional
P-tunnel. If the intention is to carry C-BIDIR traffic on the
I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one if
its VRF interfaces is the next hop interface on its best path to the
C-RPA of any bidirectional C-group of the MVPN.
When the Flat Partitioned Method is used to instantiate a (C-*,C-*)
Rosen, et al. [Page 16]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
S-PMSI, a (C-*,C-BIDIR) S-PMSI, or a (C-*,C-G) S-PMSI, a PE that
originates the corresponding S-PMSI A-D route MUST include in that
route a PTA specifying a bidirectional P-tunnel. Per the procedures
of [MVPN] and [MVPN-BGP], a PE will originate such an S-PMSI A-D
route only if one of the PE's VRF interfaces is the next hop
interface of the PE's best path to the C-RPA of a C-BIDIR group that
is to be carried on the specified S-PMSI.
PMSIs that are instantiated via the Flat Partitioned Method may carry
customer bidirectional traffic AND customer unidirectional traffic.
The rules of sections 3.2.1.1 and 3.2.1.2 determine when a given
customer multicast packet is a "match for transmission" to a given
PMSI. However, if the "Partitioned Set of PEs" method of supporting
C-BIDIR traffic is being used, the PEs must be provisioned in such a
way that packets from a C-BIDIR flow never match any PMSI that is not
instantiated by a bidirectional P-tunnel. (For example, if the
(C-*,C-*) S-PMSI were not instantiated by a bidirectional P-tunnel,
one could meet this requirement by carrying all C-BIDIR traffic on a
(C-*,C-BIDIR) S-PMSI.)
When a PE receives a customer multicast data packet from a
bidirectional P-tunnel, it associates that packet with a
"distinguished PE". The distinguished PE for a given packet is the
root node of the tunnel from which the packet is received. The rules
of section 3.2.1.1 and 3.2.2.2 ensure that:
- If the received packet is part of a unidirectional C-flow, its
"distinguished PE" is the PE that transmitted the packet onto the
P-tunnel.
- If the received packet is part of a bidirectional C-flow, its
"distinguished PE" is not necessarily the PE that transmitted it,
but rather the transmitter's "upstream PE" for the C-RPA of the
bidirectional C-group.
The rules of sections 3.2.1.3 and 3.2.1.4 allow the receiving PEs to
determine the expected distinguished PE for each C-flow, and ensure
that a packet will be discarded if its distinguished PE is not the
expected distinguished PE for the C-flow to which the packet belongs.
This prevents duplication of data for both bidirectional and
unidirectional C-flows.
3.2.1.1. When an S-PMSI is a 'Match for Transmission'
Given the need for a PE, say PE1, to transmit multicast data packets
of a particular C-flow, [MVPN-WILDCARDS] Section 3.1 gives a
four-step algorithm for determining the S-PMSI A-D route, if any,
Rosen, et al. [Page 17]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
that "matches" that C-flow for transmission.
If the C-flow is not a BIDIR-PIM C-flow, these rules apply unchanged.
If the C-flow is a BIDIR-PIM C-flow, the rules as applied by a
particular PE, say PE1, are given below:
- If the C-RPA for C-G is a C-address of PE1, or if PE1's route to
the C-RPA is via a VRF interface, then:
* if there is an S-PMSI A-D route, currently originated by PE1,
whose NLRI contains (C-*,C-G) and whose PTA identifies a
bidirectional P-tunnel, then the C-flow matches that route
* otherwise, if there is an S-PMSI A-D route, currently
originated by PE1, whose NLRI contains (C-*,C-BIDIR) and
whose PTA identifies a bidirectional P-tunnel, then the
C-flow matches that route
* otherwise, if there is an S-PMSI A-D route, currently
originated by PE1, whose NLRI contains (C-*,C-*) and whose
PTA identifies a bidirectional P-tunnel, then the C-flow
matches that route
- If PE1 determines the upstream PE for C-G's C-RPA to be some
other PE, say PE2, then the following rules apply:
* if there is an installed S-PMSI A-D route, originated by PE2,
whose NLRI contains (C-*,C-G) and whose PTA identifies a
bidirectional P-tunnel, then the C-flow matches that route
* otherwise, if there is an installed S-PMSI A-D route,
originated by PE2, whose NLRI contains (C-*,C-BIDIR) and
whose PTA identifies a bidirectional P-tunnel, then the
C-flow matches that route
* otherwise, if there is an S-PMSI A-D route, currently
originated by PE2, whose NLRI contains (C-*,C-*) and whose
PTA identifies a bidirectional P-tunnel, then the C-flow
matches that route
If there is an S-PMSI A-D route that matches a given C-flow, and if
PE1 needs to transmit packets of that C-flow or other PEs, then it
MUST transmit those packets on the P-tunnel identified in the PTA of
the matching S-PMSI A-D route.
Rosen, et al. [Page 18]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
3.2.1.2. When an I-PMSI is a 'Match for Transmission'
If a PE needs to transmit packets of a given C-flow (of a given MVPN)
to other PEs, and if, according to the conditions of section 3.2.1.1,
that C-flow does not match any S-PMSI A-D route, then the packets of
the C-flow need to be transmitted on the MVPN's I-PMSI.
If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the
C-flow MUST be transmitted is the one identified in the PTA of the
Intra-AS I-PMSI A-D route originated by the PE for the given MVPN.
If the C-flow is a BIDIR-PIM C-flow, the rules as applied by a
particular PE, say PE1, are given below:
- If the C-RPA for C-G is a C-address of PE1, or if PE1's route to
the C-RPA is via a VRF interface, then if there is an I-PMSI A-D
route, currently originated by PE1, and whose PTA identifies a
bidirectional P-tunnel, then the C-flow MUST be transmitted on
that P-tunnel
- If PE1 determines the upstream PE for C-G's C-RPA to be some
other PE, say PE2, then if there is an installed I-PMSI A-D
route, originated by PE2, whose PTA identifies a bidirectional
P-tunnel, then the C-flow MUST be transmitted on that P-tunnel
Note that if a VRF is configured to provide C-BIDIR support using the
Flat Partitioned Method, but there is no matching S-PMSI A-D route
(according to section 3.2.1.1) and there is no such I-PMSI A-D route
meeting the conditions of this section, then a provisioning error has
occurred, and the C-flow will not be transmitted.
3.2.1.3. When an S-PMSI is a 'Match for Reception'
Given the need for a PE to receive multicast data packets of a
particular C-flow, [MVPN-WILDCARDS] Section 3.2 specifies procedures
for determining the S-PMSI A-D route, if any, that "matches" that
C-flow for reception. Those rules apply unchanged for C-flows that
are not BIDIR-PIM C-flows.
For BIDIR-PIM C-flows, the rules of [MVPN-WILDCARDS] Section 3.2.1 do
not apply.
The rules of [MVPN-WILDCARDS] Section 3.2.2 are replaced by the
following rules.
Suppose that a PE router (call it PE1) needs to receive (C-*,C-G)
traffic, where C-G is a C-BIDIR group. Suppose also that PE1 has
Rosen, et al. [Page 19]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
determined that PE2 is the "upstream PE" [MVPN] for the C-RPA of C-G.
Then:
- if PE1 has an installed S-PMSI A-D route originated by PE2, whose
NLRI contains (C-*,C-G), then (C-*,C-G) matches this route.
- otherwise, if PE1 has an installed (C-*,C-BIDIR) route from PE2,
then (C-*,C-G) matches this route.
- otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D route
from PE2, then (C-*,C-G) matches this route.
If there is an S-PMSI A-D route matching (C-*,C-G), according to
these rules, its PTA must specify a bidirectional P-tunnel. The root
node of that P-tunnel is considered to be the "distinguished PE" for
the (C-*,C-G) flow. If a (C-*,C-G) packet is received on a P-tunnel
whose root node is not the distinguished PE for the C-flow, the
packet MUST be discarded.
3.2.1.4. When an I-PMSI is a 'Match for Reception
If a PE needs to receive packets of a given C-flow (of a given MVPN)
from another PE, and if, according to the conditions of Section
3.2.1.3, that C-flow does not match any S-PMSI A-D route, then the
packets of the C-flow need to be received on the MVPN's I-PMSI.
If the C-flow is not a BIDIR-PIM C-flow, the rules for determining
the P-tunnel on which packets of the C-flow are expected are given in
[MVPN].
Suppose that a PE router (call it PE1) needs to receive (C-*,C-G)
traffic from other PEs, where C-G is a C-BIDIR group. Suppose also
that PE1 has determined that PE2 is the "upstream PE" [MVPN] for the
C-RPA of C-G. PE2 is considered to be the "distinguished PE" for
(C-*,C-G). If PE1 has an installed Intra-AS I-PMSI A-D route
originated by PE2, PE1 will expect to receive packets of the C-flow
from the tunnel specifies in that route's PTA. (If all VRFs of the
MVPN have been properly provisioned to use the Flat Partitioned
Method for the I-PMSI, the PTA will specify a bidirectional
P-tunnel.)
If a (C-*,C-G) packet is received on a P-tunnel whose root node is
not the distinguished PE for the C-flow, the packet MUST be
discarded.
Rosen, et al. [Page 20]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
3.2.2. Hierarchical Partitioning
The procedures of this section and its sub-sections apply when (and
only when) the Hierarchical Partitioned Method is used. This method
is introduced in [MVPN] Section 11.2.2. This document only provides
procedures for using this method when using MP2MP LSPs as the
P-tunnels.
The Hierarchical Partitioned Method provides the same functionality
as the Flat Partitioned Method, but requires a smaller amount of
state to be maintained in the core of the network. However, it
requires the use of upstream-assigned MPLS labels ("PE Distinguisher
Labels"), which are not necessarily supported by all hardware
platforms. The upstream-assigned labels are used to provide an LSP
hierarchy, in which an "outer" MP2MP LSP carries multiple "inner"
MP2MP LSPs. Transit routers along the path between PE routers then
only need to maintain state for the outer MP2MP LSP.
When this method is used to instantiate a particular PMSI, the
bidirectional P-tunnel advertised in the PTA of the corresponding
I-PMSI or S-PMSI A-D route is the "outer" P-tunnel. When a packet is
received from a P-tunnel, the PE that receives it can infer the
identity of the outer P-tunnel from the MPLS label that has risen to
the top of the packet's label stack. However, the packet's
"distinguished PE" is not necessarily the root node of the the outer
P-tunnel. Rather, the identity of the packet's distinguished PE is
inferred from the PE Distinguisher Label further down in the label
stack. (See [MVPN] Section 12.3.) The PE Distinguisher Label may be
thought of as identifying an "inner" MP2MP LSP whose root is the PE
corresponding to that label.
The Hierarchical Partitioned Method may be used to instantiate an
I-PMSI, a (C-*,C-*) S-PMSI, or a (C-*,C-BIDIR) S-PMSI. In this case,
every PE that originates an Intra-AS I-PMSI A-D route, a (C-*,C-*)
S-PMSI A-D route, or a (C-*,C-BIDIR) S-PMSI A-D route MUST be
provisioned with the mLDP FEC of the outer P-tunnel that is to be
used to instantiate the PMSI in question, and the A-D route
advertising that PMSI MUST be originated with a PTA that identifies
the the outer bidirectional P-tunnel.
The PEs that are required to originate the routes mentioned in the
previous paragraph are those that satisfy one of the following
conditions:
- There is a C-BIDIR group for which the best path from the PE to
the C-RPA of that C-group is via a VRF interface, or
Rosen, et al. [Page 21]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
- The PE might have to transmit customer multicast traffic on the
PMSI identified in the route,
- The PE is the root node of the MP2MP LSP that is used to
instantiate the PMSI.
If (and only if) C-G is a C-BIDIR group, the Hierarchical Partitioned
method may be used to instantiate the (C-*,C-G) S-PMSI. In this
case, when a (C-*,C-G) S-PMSI A-D route is originated, it is
originated only by a PE whose best path to the C-RPA for C-G is via a
VRF interface, and that PE MUST be the root node of the MP2MP LSP
identified in the PTA of the A-D route.
As in [MVPN] and [MVPN-BGP], an S-PMSI A-D route does not need to be
originated by a particular PE, say PE1, until PE1 has received a
"join" indicating that some other PE is interested in receiving
customer multicast traffic forwarded from PE1.
The Hierarchical Partitioned method MUST NOT be used to instantiate a
(C-S,C-G) or a (C-S,C-*) S-PMSI.
If the "partitioned sets of PEs" method of supporting C-BIDIR is
used, as discussed in section 11.2 of [MVPN] and section 3.6 of
[RFC6517], C-BIDIR flows MUST NOT be carried on a P-tunnel specified
in the PTA of a (C-S,C-G) or a (C-S,C-*) S-PMSI.
If any VRF of a given MVPN uses this method TO instantiate an S-PMSI
with a bidirectional P-tunnel, all VRFs of that MVPN must use this
method.
3.2.2.1. Advertisement of PE Distinguisher Labels
A PE Distinguisher Label is an upstream-assigned MPLS label [RFC5331]
that can be used, in the context of a MP2MP LSP, to denote a
particular PE that either has joined or may in the future join that
LSP.
In order to use upstream-assigned MPLS labels in the context of an
"outer" MP2MP LSP, there must be a convention that identifies a
particular router as the router that is responsible for allocating
the labels and for advertising the labels to the PEs that may join
the MP2MP LSP. This document REQUIRES that the PE Distinguisher
Labels used in the context of a given MP2MP LSP be allocated and
advertised by the router that is the root node of the LSP.
This convention accords with the rules of section 7 of [RFC5331].
Note that according to section 7 of [RFC5331], upstream-assigned
Rosen, et al. [Page 22]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
labels are unique in the context of the IP address of the root node;
if two MP2MP LSPs have the same root node IP address, the upstream-
assigned labels used within the two LSPs come from the same label
space.
A PE Distinguisher Labels attribute SHOULD NOT be attached to an
I-PMSI or S-PMSI A-D route unless that route also contains a PTA that
specifies an MP2MP LSP. (While PE Distinguisher Labels could in
theory also be used if the PTA specifies a BIDIR-PIM P-tunnel, such
use is outside the scope of this document.)
The PE Distinguisher Labels attribute specifies a set of <MPLS label,
IP address> bindings. Each IP address is the IP address of a PE
router that is expected to receive the route that contains the
attribute. Within a given PE Distinguisher Labels attribute, each IP
address MUST appear only once, and each MPLS label MUST appear only
once.
When a PE Distinguisher Labels attribute is included in a given
I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address
of each of the following sets of PEs:
- The root node of the MP2MP LSP identified in the PTA of the
route,
- Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP
LSP identified in the PTA of the route. This requirement can be
met by assigning a label to every PE that has originated an
Intra-AS I-PMSI A-D route. However, if it is known apriori that
all the non-C-BIDIR sources are in sites attached to only a
subset of the PEs, PE Distinguisher labels can be specified for
that subset alone.
3.2.2.2. When an S-PMSI is a 'Match for Transmission'
Given the need for a PE, say PE1, to transmit multicast data packets
of a particular C-flow, [MVPN-WILDCARDS] Section 3.1 gives a
four-step algorithm for determining the S-PMSI A-D route, if any,
that "matches" that C-flow for transmission.
If the C-flow is not a BIDIR-PIM C-flow, these rules apply unchanged.
Once PE1 finds the matching S-PMSI (if any), PE1 may transmit a
packet of that C-flow on the P-tunnel advertised in that route. The
packet MUST carry the PE Distinguisher Label assigned by the root
node of that P-tunnel to the IP address of PE1.
If the C-flow is a BIDIR-PIM C-flow, the rules are given below.
Rosen, et al. [Page 23]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
Assume PE1 determines that the upstream PE for C-G's C-RPA is PE2.
- If there is an installed S-PMSI A-D route, or an S-PMSI A-D route
originated by PE1 itself, whose NLRI contains (C-*,C-G) and whose
PTA identifies a bidirectional P-tunnel, then the C-flow matches
that route.
- Otherwise, if there is an installed S-PMSI A-D route, or an
S-PMSI A-D route currently originated by PE1 itself, whose NLRI
contains (C-*,C-BIDIR) and whose PTA identifies a bidirectional
P-tunnel, then the C-flow matches that route.
- Otherwise, if there is an installed S-PMSI A-D route (or an
S-PMSI A-D route currently originated by PE1 itself) whose NLRI
contains (C-*,C-*) and whose PTA identifies a bidirectional
P-tunnel, then the C-flow matches that route.
If there is a matching S-PMSI A-D route, PE1 MUST transmit the C-flow
on the P-tunnel identified in its PTA. In constructing the packet's
MPLS label stack, it must use the PE Distinguisher Label that was
assigned by the P-tunnel's root node to the IP address of PE2.
(Note: the PE Distinguisher Label is the one assigned to the address
of PE2, not the one assigned to the address of PE1.)
3.2.2.3. When an I-PMSI is a 'Match for Transmission'
If a PE, say PE1, needs to transmit packets of a given C-flow (of a
given MVPN) to other PEs, and if, according to the conditions of
section 3.2.2.1, that C-flow does not match any S-PMSI A-D route,
then the packets of the C-flow need to be transmitted on the MVPN's
I-PMSI.
If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the
C-flow MUST be transmitted is the one identified in the PTA of the
Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. Each
packet of the C-flow MUST carry the PE Distinguisher Label assigned
by the root node of that P-tunnel to the IP address of PE1.
If the C-flow is a BIDIR-PIM C-flow, the rules as applied by a
particular PE, say PE1, are given below:
- If the C-RPA for C-G is a C-address of PE1, or if PE1's route to
the C-RPA is via a VRF interface, then if there is an I-PMSI A-D
route, currently originated by PE1, and whose PTA identifies a
bidirectional P-tunnel, then the C-flow MUST be transmitted on
that P-tunnel. Each packet of the C-flow MUST carry the PE
Distinguisher Label assigned by the root node of that P-tunnel to
Rosen, et al. [Page 24]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
the IP address of PE1.
- If PE1 determines the upstream PE for C-G's C-RPA to be some
other PE, say PE2, then if there is an installed I-PMSI A-D
route, originated by PE2, whose PTA identifies a bidirectional
P-tunnel, then the C-flow MUST be transmitted on that P-tunnel.
Each packet of the C-flow MUST carry the PE Distinguisher Label
assigned by the root node of that P-tunnel to the IP address of
PE2.
Note that if a VRF is configured to provide C-BIDIR support using the
Flat Partitioned Method, but there is no matching S-PMSI A-D route
(according to section 3.2.2.1) and there is no such I-PMSI A-D route
meeting the conditions of this section, then a provisioning error has
occurred, and the C-flow will not be transmitted.
3.2.2.4. When an S-PMSI is a 'Match for Reception'
Given the need for a PE, say PE1, to receive multicast data packets
of a particular C-flow, [MVPN-WILDCARDS] Section 3.2 specifies
procedures for determining the S-PMSI A-D route, if any, that
"matches" that C-flow for reception. Those rules require that the
matching S-PMSI A-D route has been originated by the upstream PE for
the C-flow. These rules are modified in this section, as follows.
Consider a particular C-flow. Suppose either:
- the C-flow is unidirectional, and PE1 determines that its
upstream PE is PE2, or
- the C-flow is bidirectional, and PE1 determines that the upstream
PE for its C-RPA is PE2.
Then the C-flow may match an installed S-PMSI A-D route that was not
originated by PE2, as long as:
1. the PTA of that A-D route identifies an MP2MP LSP, and
2. there is an installed S-PMSI A-D route originated the root node
of that LSP, or PE1 itself the root node of the LSP and there
is a currently originated S-PMSI A-D route from PE1 whose PTA
identifies that LSP, and
Rosen, et al. [Page 25]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
3. the latter S-PMSI A-D route (the one identified in 2 just
above) contains a PE Distinguisher Labels attribute that
assigned an MPLS label to the IP address of PE2.
However, a bidirectional C-flow never matches an S-PMSI A-D route
whose NLRI contains (C-S,C-G).
If a multicast data packet is received over a matching P-tunnel, but
does not carry the value of the PE Distinguisher Label that has been
assigned to the upstream PE for its C-flow, then the packet MUST be
discarded.
3.2.2.5. When an I-PMSI is a 'Match for Reception"
If a PE needs to receive packets of a given C-flow (of a given MVPN)
from another PE, and if, according to the conditions of section
3.2.3.3, that C-flow does not match any S-PMSI A-D route, then the
packets of the C-flow need to be received on the MVPN's I-PMSI. When
the Hierarchical Partitioned Method is used, each Intra-AS I-PMSI A-D
routes of the MVPN will have a PTA, and all such PTAs will specify
the same bidirectional P-tunnel. This is the "outer P-tunnel" that
carries all packets that are transmitted on the I-PMSI. This
determines the top label that packets of that C-flow will be carrying
when received. A PE that needs to receive packets of a given C-flow
must determine the expected value of the second label for packets of
that C-flow. This will be the value of a PE Distinguisher Label,
taken from the PE Distinguisher Labels attribute of the Intra-AS
I-PMSI A-D route of the root node of that outer tunnel. The expected
value of the second label on received packets (corresponding to the
"inner tunnel") of a given C-flow is determined according to the
following rules.
First, the "distinguished PE" for the C-flow is determined:
- If the C-flow is not a BIDIR-PIM C-flow, the "distinguished PE"
for the C-flow is its "upstream PE", as determined by the rules
of [MVPN].
- If the C-flow is a BIDIR-PIM C-flow, the "distinguished PE" for
the C-flow is its "upstream PE" of the C-flow's C-RPA, as
determined by the rules of [MVPN].
The expected value of the second label is the value that the root PE
of the outer tunnel has assigned, in the PE Distinguisher Labels
attribute of its Intra-AS I-PMSI A-D route, to the IP address of the
"distinguished PE".
Rosen, et al. [Page 26]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
Packets addresses to C-G that arrive on other than the expected inner
and outer P-tunnels (i.e., that arrive with unexpected values of the
top two labels) MUST be discarded.
3.2.3. Unpartitioned
When a particular MVPN uses the Unpartitioned Method of instantiating
an I-PMSI with a bidirectional P-tunnel, it MUST be the case that at
least one VRF of that MVPN originates an Intra-AS I-PMSI A-D route
that includes a PTA specifying a bidirectional P-tunnel. The
conditions under which an Intra-AS I-PMSI A-D route must be
originated from a given VRF are as specified in [MVPN-BGP]. This
document allows all but one of such routes to omit the PTA. However,
each such route MAY contain a PTA. If the PTA is present, it MUST
specify a bidirectional P-tunnel. As specified in [MVPN] and
[MVPN-BGP], every PE that imports such an Intra-AS I-PMSI A-D route
into one of its VRFs MUST join the P-tunnel, specified in the route's
PTA, if the route has a PTA.
Packets received on any of these P-tunnels are treated as having been
received over the I-PMSI. The disposition of a received packet MUST
NOT depend upon the particular P-tunnel over which it has been
received.
When a PE needs to transmit a packet on such an I-PMSI, then if that
PE advertised a P-tunnel in the PTA of an Intra-AS I-PMSI A-D route
that it originated, the PE SHOULD transmit the on that P-tunnel.
However, any PE that transmits a packet on the I-PMSI MAY transmit it
on any of the P-tunnels advertised in any of the currently installed
Intra-AS I-PMSI A-D routes for its VPN.
This allows a single bidirectional P-tunnel to be used to instantiate
the I-PMSI, but also allows the use of multiple bidirectional
P-tunnels. There may be a robustness advantage in having multiple
P-tunnels available for use, but the number of P-tunnels used does
not impact the functionality in any way. If there are, e.g., two
P-tunnels available, these procedures allow each P-tunnel to be
advertised by a single PE, but they also allow each P-tunnel to be
advertised by multiple PEs. Note that the PE advertising a given
P-tunnel does not have to be the root node of the tunnel. The root
node might not even be a PE router, and might not originate any BGP
routes at all.
In the Unpartitioned Method, packets received on the I-PMSI cannot be
associated with a distinguished PE, so duplicate detection using the
techniques of [MVPN] section 9.1.1 is not possible; the techniques of
[MVPN] 9.1.2 or 9.1.3 would have to be used instead. Support for
Rosen, et al. [Page 27]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
C-BIDIR using the "Partitioned set of PEs" technique ([MVPN] section
11.2 and [RFC6517] section 3.6) is not possible when the
Unpartitioned Method is used. If it is desired to use that technique
to support C-BIDIR, but also to use the Unpartitioned Method of
instantiate the I-PMSI, then all the C-BIDIR traffic would have to be
carried on an S-PMSI, where the S-PMSI is instantiated using one of
the Partitioned Methods.
When a PE, say PE1, needs to transmit multicast data packets of a
particular C-flow to other PEs, and PE1 does not have an S-PMSI that
is a "match for transmission for that C-flow (see section 3.2.3.1),
PE1 transmits the packets on one of the P-tunnel(s) that instantiates
the I-PMSI. When a PE, say PE1, needs to receive multicast data
packets of a particular C-flow from another PE, and PE1 does not have
an S-PMSI that is a "match for reception for that C-flow (see section
3.2.3.2), PE1 expect to receive the packets on any of the P-tunnel(s)
that instantiates the I-PMSI.
When a particular MVPN uses the Unpartitioned Method to instantiate a
(C-*,C-*) S-PMSI using a bidirectional P-tunnel, the same conditions
apply as when an I-PMSI is instantiated via the Unpartitioned Method.
The only difference is that a PE need not join a P-tunnel that
instantiates the S-PMSI unless that PE needs to receive multicast
packets on the S-PMSI.
When a particular MVPN uses bidirectional P-tunnels to instantiate
other S-PMSIs, different S-PMSI A-D routes that do not contain
(C-*,C-*), originated by the same or by different PEs, MAY have PTAs
that identify the same bidirectional tunnel, and they MAY have PTAs
that do not identify the same bidirectional tunnel. See sections
3.2.3.1 and 3.2.3.3.
While the Unpartitioned Method MAY be used to instantiate an S-PMSI
to which one or more C-BIDIR flows are bound, it must be noted that
the "Partitioned Set of PEs" method discussed in [MVPN] section 11.2
and [RFC6517] section 3.6 cannot be supported using the Unpartitioned
Method. C-BIDIR support would have to be provided by the procedures
of [MVPN] section 11.1.
3.2.3.1. When an S-PMSI is a 'Match for Transmission'
Given the need for a PE to transmit multicast data packets of a
particular customer C-flow, [MVPN-WILDCARDS] Section 3.1 gives a
four-step algorithm for determining the S-PMSI A-D route, if any,
that "matches" that C-flow for transmission. When referring to that
section, please recall that BIDIR-PIM groups are also "Any Source
Multicast" (ASM) groups.
Rosen, et al. [Page 28]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
When bidirectional P-tunnels are used in the Unpartitioned Method,
the same algorithm applies, with one modification, when the PTA of an
S-PMSI A-D route identifies a bidirectional P-tunnel. One additional
step is added to the algorithm. This new step occurs before the
fourth step of the algorithm, and is as follows:
- Otherwise, if there is an S-PMSI A-D route currently originated
by PE1, whose NLRI contains (C-*,C-BIDIR), and if C-G is a BIDIR
group, the (C-S,C-G) C-flow matches that route.
3.2.3.2. When an S-PMSI is a 'Match for Reception'
Given the need for a PE to receive multicast data packets of a
particular customer C-flow, [MVPN-WILDCARDS] Section 3.2 specifies
the procedures for determining the S-PMSI A-D route, if any, that
advertised the P-tunnel on which the PE should expect to receive that
C-flow.
When bidirectional P-tunnels are used in the Unpartitioned Method,
the same procedures apply, with one modification.
The last paragraph of Section 3.2.2 of [MVPN-WILDCARDS] begins:
"If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from
PE2, but PE1 has an installed (C-*,C-*) S-PMSI A-D route from
PE2, then (C-*,C-G) matches the (C-*,C-*) route if one of the
following conditions holds:"
This is changed to:
"If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from
PE2, but C-G is a BIDIR group and PE1 has an installed
(C-*,C-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that
route. Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D
route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one
of the following conditions holds:"
3.2.4. Minimal Feature Set for Compliance
A PE that does not provide C-BIDIR support using the "partitioned set
of PEs" method may be deemed compliant to this specification if it
supports the Unpartitioned Method, using either MP2MP LSPs or
BIDIR-PIM multicast distribute trees as P-tunnels.
A PE that does provide C-BIDIR support using the "partitioned set of
PEs" method, MUST, at a minimum, be able to provide C-BIDIR support
Rosen, et al. [Page 29]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
using the "Partial Mesh of MP2MP P-tunnels" variant of this method
(see section 11.2 of [MVPN]). An implementation will be deemed
complaint to this minimum requirement if it can carry all of a VPN's
C-BIDIR traffic on a (C-*,C-BIDIR) S-PMSI that is instantiated by a
bidirectional P-tunnel, using the flat partitioned method.
4. IANA Considerations
This document has no actions for IANA.
5. Security Considerations
There are no additional security considerations beyond those of
[MVPN] and [MVPN-BGP], or any that may apply to the particular
protocol used to set up the bidirectional tunnels ([BIDIR-PIM],
[mLDP]).
6. Acknowledgments
The authors wish to thank Karthik Subramanian, Rajesh Sharma, and
Apoorva Karan for their input. We also thank Yakov Rekhter for his
valuable critique.
Special thanks go to Jeffrey Zhang for his careful review, probing
questions, and useful suggestions.
7. Authors' Addresses
Arjen Boers
E-mail: arjen@boers.com
Yiqun Cai
Microsoft
1065 La Avenida
Mountain View, CA 94043
E-mail: yiqunc@microsoft.com
Rosen, et al. [Page 30]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
E-mail: erosen@cisco.com
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a Diegem 1831
Belgium
E-mail: ice@cisco.com
8. Normative References
[BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley,
Kouvelas, Speakman, Vicisano, RFC 5015, October 2007
[L3VPN], "BGP/MPLS IP Virtual Private Networks", Rosen, Rekhter
(editors), RFC 4364, February 2006
[mLDP] "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", Wijnands, Minei, Kompella, Thomas, RFC 6388, November 2011
[MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., RFC
6513, February 2012
[MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", Aggarwal, Rosen, Morin, Rekhter, RFC 6514, February 2012
[MVPN-WILDCARDS] "Wild Cards in Multicast VPN Auto-Discovery Routes",
Rosen, Rekhter, Hendrickx, Qiu, RFC 6625, May 2012
[PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", Fenner, Handley, Holbrook,
Kouvelas, RFC 4601, August 2006
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
Rosen, et al. [Page 31]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-05.txt April 2013
9. Informative References
[RFC5331] "MPLS Upstream Label Assignment and Context-Specific Label
Space", Aggarwal, Rekhter, Rosen, RFC 5331, August 2008
[RFC6517] "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN
Solution", Morin, Niven-Jenkins, Kamite, Zhang, Leymann, Bitar, RFC
6517, February 2012
[MVPN_XNET] "Extranet Multicast in BGP/IP MPLS VPNs", Rekhter, Rosen
(editors), draft-ietf-l3vpn-mvpn-extranet-00.txt, January 2013
Rosen, et al. [Page 32]