MVPN: Using Bidirectional P-Tunnels
draft-ietf-l3vpn-mvpn-bidir-04
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-01-07 | ||
| 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-04
L3VPN Working Group Eric C. Rosen (Editor)
Internet Draft IJsbrand Wijnands
Intended Status: Proposed Standard Cisco Systems, Inc.
Expires: July 7, 2013
Yiqun Cai
Microsoft
Arjen Boers
January 7, 2013
MVPN: Using Bidirectional P-Tunnels
draft-ietf-l3vpn-mvpn-bidir-04.txt
Abstract
The RFCs providing multicast support for BGP/MPLS IP VPNs allow
customer multicast data to be travel across a service provider's
backbone network through a set multicast tunnels. These tunnels are
advertised by BGP in a BGP attribute known as the "Provider Multicast
Service Interface (PMSI) Tunnel Attribute". Encodings have been
defined that allow the PMSI Tunnel Attribute to specify bidirectional
(multipoint-to-multipoint) multicast distribution trees. However,
the prior RFCs do not provide all the necessary details for using
bidirectional tunnels to support multicast VPNs. These details are
provided in the current document. This document also specifies the
procedures for assigning customer multicast flows to specific
bidirectional tunnels in the provider backbone.
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."
Rosen, et al. [Page 1]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
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-04.txt January 2013
Table of Contents
1 Introduction .......................................... 3
1.1 Terminology ........................................... 4
1.2 Overview .............................................. 6
1.2.1 Bidirectional P-tunnel Technologies ................... 7
1.2.2 PMSI Instantiation Methods ............................ 7
2 The All BIDIR-PIM Wild Card ........................... 9
3 Using Bidirectional P-Tunnels ......................... 9
3.1 Procedures Specific to the Tunneling Technology ....... 9
3.1.1 BIDIR-PIM P-Tunnels ................................... 9
3.1.2 MP2MP LSPs ............................................ 10
3.2 Procedures Specific to the PMSI Instantiation Method .. 11
3.2.1 Flat Partitioning ..................................... 11
3.2.1.1 When an S-PMSI is a 'Match for Transmission' .......... 12
3.2.1.2 When an S-PMSI is a 'Match for Reception' ............. 13
3.2.2 Hierarchical Partitioning ............................. 14
3.2.2.1 When an S-PMSI is a 'Match for Transmission' .......... 15
3.2.2.2 When an S-PMSI is a 'Match for Reception' ............. 16
3.2.3 Unpartitioned ......................................... 17
3.2.3.1 When an S-PMSI is a 'Match for Transmission' .......... 18
3.2.3.2 When an S-PMSI is a 'Match for Reception' ............. 18
4 IANA Considerations ................................... 19
5 Security Considerations ............................... 19
6 Acknowledgments ....................................... 19
7 Authors' Addresses .................................... 19
8 Normative References .................................. 20
9 Informative References ................................ 21
1. Introduction
The RFCs that specify multicast support for BGP/MPLS IP VPNs ([MVPN],
[MVPN-BGP]) allow customer multicast data to be transported across a
service provider's network though a set of multicast tunnels. Such
tunnels are advertised by BGP in a BGP attribute known as the
"Provider Multicast Service Interface (PMSI) Tunnel Attribute".
Bidirectional multicast distribution trees are allowed by the base
specifications, and those specifications describe how to encode the
identifiers for bidirectional trees in the PMSI Tunnel attribute.
However, those specifications do not provide all the necessary
details for using bidirectional tunnels. These details are provided
Rosen, et al. [Page 3]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
in this document.
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.
- MP2MP
Multipoint-to-multipoint.
- P-tunnel
A tunnel through the network of one or more Service Providers
(SPs).
- 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.
Rosen, et al. [Page 4]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
- C-multicast flow or C-flow
A customer multicast flow. Each C-flow is identified by the
ordered pair (source address, group address), where each address
is in the customer's address space. The identifier of a
particular C-flow is usually written as (C-S,C-G).
- 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.
- 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.
Rosen, et al. [Page 5]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
- 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 particular C-flows are bound to (i.e.,
are traveling through) particular P-tunnels.
- PE Distinguisher Labels
These are upstream-assigned MPLS labels that can be used, in the
context of a MP2MP LSP, to denote a particular PE that can send
to or receive from that LSP. By putting a PE Distinguisher label
on a packet, before transmitting that packet on a MP2MP LSP, the
transmitter indicates that the PE denoted by the label has a
special relationship to the packet.
- PE Distinguisher Labels Attribute
A BGP path attribute, defined in [MVPN-BGP], that is used for
advertising PE Distinguisher Labels, and binding each PE
Distinguisher Label to a particular PE address.. The attribute
is a set of <label, IP address> bindings.
We say that the NLRI ("Network Layer Reachability Information") of a
BGP S-PMSI A-D route or Source Active A-D route contains (C-S,C-G) if
its "Multicast Source" field contains C-S and its "Multicast Group"
field contains C-G. If either or both of these fields is encoded as
a wildcard, we will say that the NLRI contains (C-*,C-*) (both fields
encoded as wildcard), (C-*,C-G) (multicast source field encoded as
wildcard) or (C-S,C-*) (multicast group field encoded as wildcard).
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 appearing in all caps, are to be interpreted as
described in [RFC2119].
1.2. Overview
The base documents for MVPN, [MVPN] and [MVPN-BGP], define a "PMSI
Tunnel Attribute" (PTA) that may be carried in the BGP "I-PMSI A-D
routes" and BGP "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
Rosen, et al. [Page 6]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
use of the PTA to advertise bidirectional P-tunnels; rather, those
documents declare those specifications to be "out of scope."
Similarly, the use of bidirectional P-tunnels advertised in S-PMSI
A-D routes with wildcards is declared by [MVPN-WILDCARDS] to be "out
of scope." This document provides the necessary specifications to
allow the use of bidirectional P-tunnels, including the procedures
for assigning customer multicast flows to specific bidirectional P-
tunnels.
This document does not specify any new data encapsulations for
bidirectional P-tunnels. Section 12 of [MVPN] applies unchanged.
1.2.1. Bidirectional P-tunnel Technologies
This document covers two different technologies for creating and
maintaining bidirectional P-tunnels:
- Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs),
created by Label Distribution Protocol (LDP)
Multipoint-to-Multipoint extensions [mLDP].
- Multicast distribution trees that are created through the use of
BIDIR-PIM [BIDIR-PIM].
Other bidirectional tunnel technologies are outside the scope of this
document.
1.2.2. PMSI Instantiation Methods
This document specifies two methods for using bidirectional P-tunnels
to instantiate PMSIs:
- Partitioned Method
In the Partitioned Method, a particular PMSI is instantiated by a
set of bidirectional P-tunnels. These P-tunnels may be
aggregated 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. However, for each
such P-tunnel (each "inner" P-tunnel, in the case of hierarchical
partitioning) there is one PE that is the "distinguished PE" for
that P-tunnel. Thus when a packet is received on a given
P-tunnel, it can be associated with the P-tunnel's distinguished
PE. This association plays an important role in the treatment of
Rosen, et al. [Page 7]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
the packet, as specified later on in this document.
As specified later in this document, the hierarchical partitioned
method (but not the flat 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.
- Unpartitioned Method
In the Unpartitioned Method, a particular PMSI is 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
know the tunnel on which the packet was transmitted, but they do
not associate the packet with any particular "distinguished PE".
If a bidirectional P-tunnel is used to instantiate an I-PMSI, the
Unpartitioned Method MUST be used.
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 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 all their
S-PMSIs. If the partitioned method is used, all the VRFs of a single
MVPN MUST be provisioned to use the same 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.
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 specify procedures for every possible combination
of tunnel technology and PMSI instantiation method.
Rosen, et al. [Page 8]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
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 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.
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.
Rosen, et al. [Page 9]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
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.
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 route SHOULD NOT have a PE
Distinguisher Labels attribute. If it does, that attribute MUST be
ignored. (PE Distinguisher Labels are used for the hierarchical
partitioning method, but this document does not provide support 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.
Rosen, et al. [Page 10]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
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
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. It does not require the
use of upstream-assigned labels, and does not use the PE
Distinguisher Labels attribute.
The flat partitioning method MUST NOT be used to instantiate an
I-PMSI; it is only used to instantiate S-PMSIs. It may however be
used to instantiate a (C-*,C-*) S-PMSI or a (C-*,C-BIDIR) S-PMSI.
When the flat partitioning method is used, an S-PMSI A-D route SHOULD
NOT contain a PE Distinguisher Labels attribute; if such an attribute
is present in a received S-PMSI A-D route, it MUST be ignored.
When the flat partitioning method is used to instantiate a (C-*,C-*)
S-PMSI, a (C-*,C-BIDIR) S-PMSI, or a (C-*,C-G) S-PMSI where C-G is a
BIDIR group, each of a "selected set" (see below) of PEs in a given
MVPN MUST originate an S-PMSI A-D route with a PTA identifying a
bidirectional P-tunnel. The PE originating the route MUST be the
root node of the identified bidirectional 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 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 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.
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".
If MP2MP LSPs are used, each P-tunnel MUST have have a distinct MP2MP
Rosen, et al. [Page 11]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
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.
A PE is considered to be in the "selected set" if at least one of the
following conditions hold:
- The "Partitioned Sets of PEs" method of supporting C-BIDIR
traffic is being used, and the PE's route to the Customer's
Rendezvous Point Address (C-RPA) for one or more C-BIDIR groups
is via a VRF interface.
- The "Partitioned Sets of PEs" method of supporting C-BIDIR
traffic is being used, it is desired to transmit some or all of
the customer's unidirectional multicast traffic (for the given
MVPN) on the same LSPs used for carrying C-BIDIR traffic, and the
PE has customer multicast traffic to transmit to other PEs.
There may be other conditions under which a PE is considered to be in
the "selected set"; these are outside the scope of this document.
When the flat partitioning 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 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.
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, 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
Rosen, et al. [Page 12]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
* 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
PE1 MUST transmit the C-flow on the P-tunnel identified in the PTA of
the matching S-PMSI A-D route.
3.2.1.2. 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
determined that PE2 is the "upstream PE" [MVPN] for the C-RPA of C-G.
Rosen, et al. [Page 13]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
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 a customer multicast data packet addressed to C-G is received on a
P-tunnel that was not advertised in an S-PMSI A-D route matching
(C-*,C-G), the packet MUST be discarded.
3.2.2. Hierarchical Partitioning
This document provides support for this method only when MP2MP LSPs
are being used as the P-tunnels. When this method is used, the
bidirectional P-tunnel advertised in the PTA of an S-PMSI A-D route
is the "outer" P-tunnel. A PE advertising a bidirectional P-tunnel
in the PTA of an S-PMSI A-D route does not need to be the root of the
P-tunnel. However, each P-tunnel MUST be advertised by its root, and
the root MUST include a PE Distinguisher Labels attribute.
This method is discussed in [MVPN], section 11.2.2. This method
provides the same functionality as the flat partitioning method, but
requires less 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
platforms. The upstream-assigned labels are used to provide an LSP
hierarchy, in which an "outer" MP2MP LSP carries multiple "inner"
MP2MP LSPs. P routers only maintain state for the outer MP2MP LSP.
In the hierarchical partitioned method, 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 MUST NOT be used to instantiate
an I-PMSI; it is only used to instantiate S-PMSIs. It may however be
Rosen, et al. [Page 14]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
used to instantiate a (C-*,C-*) S-PMSI or a (C-*,C-BIDIR) S-PMSI.
When the hierarchical partitioned method is used to instantiate a
(C-*,C-*) S-PMSI, a (C-*,C-BIDIR) S-PMSI, or a (C-*,C-G) S-PMSI where
C-G is a BIDIR group, each of a "selected set" of PEs in a given MVPN
MUST originate an S-PMSI A-D route with a PTA identifying the outer
bidirectional P-tunnel. A PE is considered to be in the "selected
set" if the "Partitioned Sets of PEs" method of supporting C-BIDIR
traffic is being used, and the PE is provisioned to originate a
(C-*,C-*) or (C-*,C-BIDIR) S-PMSI A-D route, and to use an MP2MP LSP
to instantiate that S-PMSI.
When the hierarchical partitioned method is used to instantiate an
S-PMSI, it may be 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
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.
In addition, a PE, say PE1, that desires to transmit multicast data
packets of a unidirectional C-flow on a MP2MP LSP MUST originate an
S-PMSI A-D route with an NLRI matching the C-flow (according to the
specification of [MVPN-WILDCARDS] Section 3.1). PE1 need not be the
root node of the MP2MP LSP, but if it is not, the same LSP MUST have
been advertised in the PTA of an S-PMSI A-D route originated by its
root node, and the root node MUST include a PE Distinguisher Labels
attribute that assigns a label to the IP address of PE1.
If any VRF of a given MVPN uses this method when instantiating an
S-PMSI with a bidirectional P-tunnel, all VRFs of that MVPN must use
this method.
3.2.2.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, 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 15]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 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.
PE1 MUST transmit the C-flow on the P-tunnel identified in the PTA of
the matching S-PMSI A-D route. 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.2. 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:
Rosen, et al. [Page 16]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
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
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.3. Unpartitioned
When a particular MVPN uses a bidirectional P-tunnel to instantiate
an I-PMSI, every VRF of that MVPN that originates an Intra-AS I-PMSI
A-D route MUST include a PTA with that route. All such PTAs MUST
identify the same P-tunnel. The reception of an Intra-AS I-PMSI A-D
route that does not meet these conditions signifies a configuration
error; the route SHOULD be ignored and the error logged. The
identity of this P-tunnel is known by provisioning.
When a particular MVPN uses a bidirectional P-tunnel to instantiate a
(C-*,C-*) S-PMSI, every VRF of that MVPN that originates an S-PMSI
A-D route whose NLRI contains (C-*,C-*) must include a PTA with that
route. All such PTAs MUST identify the same P-tunnel. The reception
of a (C-*,C-*) S-PMSI A-D route that does not meet these conditions
signifies a configuration error; the route SHOULD be ignored and the
error logged. The identity of this P-tunnel is known by
provisioning. (This requirement ensures that, given a particular
packet, the algorithms of sections 3.2.2.1 and 3.2.2.2 will always
choose a unique P-tunnel.)
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.
When the Unpartitioned Method is used, the root node of the
Rosen, et al. [Page 17]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
bidirectional P-tunnel does not need to be a PE router, and does not
need to originate any BGP routes.
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.
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:"
Rosen, et al. [Page 18]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
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:"
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 19]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 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 20]
Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013
9. Informative References
[RFC6517] "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN
Solution", Morin, Niven-Jenkins, Kamite, Zhang, Leymann, Bitar, RFC
6517, February 2012
Rosen, et al. [Page 21]