One document matched: draft-rosen-l3vpn-mvpn-bidir-00.txt
Network Working Group Yiqun Cai
Internet Draft Eric C. Rosen (Editor)
Intended Status: Proposed Standard IJsbrand Wijnands
Expires: August 2, 2010 Cisco Systems, Inc.
Arjen Boers
February 2, 2010
MVPN: Using Bidirectional P-Tunnels
draft-rosen-l3vpn-mvpn-bidir-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
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
Rosen, et al. [Page 1]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
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.
Abstract
The documents specifying multicast support for BGP/MPLS IP VPNs allow
customer multicast data to be transported through a service
provider's network through a set multicast tunnels. Such tunnels are
advertised by BGP in a BGP attribute known as the "Provider Multicast
Service Interface (PMSI) Tunnel Attribute". The base specifications
allow the PMSI Tunnel Attribute to advertise bidirectional multicast
distribution trees as "PMSI Tunnels"; however, those document do not
provide all the necessary details for doing so. Those details are
provided in this document. These additional details are also
applicable when bidirectional PMSI Tunnels are advertised in the
datagram messages known as "S-PMSI Join Messages". This document
also specifies the procedures for assigning customer multicast flows
to specific bidirectional PMSI tunnels.
Rosen, et al. [Page 2]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
Table of Contents
1 Specification of requirements ......................... 3
2 Introduction .......................................... 4
3 Advertising Bidirectional P-tunnels ................... 5
3.1 BIDIR-PIM P-Tunnels with GRE Encapsulation ............ 5
3.2 MP2MP LSPs ............................................ 6
3.2.1 MP2MP LSPs without PE Distinguisher Labels ............ 6
3.2.2 MP2MP LSPs with PE Distinguisher Labels ............... 6
3.2.3 Default Tunnel Identifier for MP2MP LSPs .............. 7
4 Associating Received Packets with VRFs ................ 7
5 Data Transmission and Reception ....................... 8
5.1 Without PE Distinguisher Labels ....................... 8
5.1.1 Binding (C-S,C-G) to Bidirectional P-tunnels .......... 8
5.1.2 Binding (C-*,C-G) Flows from Unidirectional C-trees ... 8
5.1.3 Binding (C-*,C-G) Flows from Bidirectional C-trees .... 9
5.1.4 Binding (C-*,C-*) ..................................... 9
5.2 With PE Distinguisher Labels .......................... 11
6 IANA Considerations ................................... 12
7 Security Considerations ............................... 12
8 Authors' Addresses .................................... 12
9 Normative References .................................. 13
10 Informative References ................................ 13
1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Rosen, et al. [Page 3]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
2. Introduction
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. However,
those documents do not contain the full set of specifications
governing the use of the PTA to advertise bidirectional P-Tunnels.
Those specifications are provided in this document.
The base documents do define the way that bidirectional P-tunnels are
identified in the PTA, and the way in which the identifier of a
bidirectional P-tunnel is encoded in the PTA. The corresponding
encodings used in "S-PMSI Join Messages" [MVPN] are defined in
[MVPN_SPMSI_JOINS]. Those identifiers and encodings are not changed
by this specification.
This document also specifies the procedures for assigning customer
multicast flows to specific bidirectional PMSI tunnels.
Two kinds of bidirectional P-tunnels are discussed in this document:
- Multicast distribution trees that are created through the use of
BIDIR-PIM [BIDIR-PIM], and that use GRE to encapsulate packets
transmitted on the tunnels
- Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs),
created by Label Distribution Protocol (LSP) Multipoint-to-
Multipoint extensions [mLDP].
This document also specifies two different methods for using MP2MP
LSPs as P-tunnels:
- MP2MP LSPs with PE Distinguisher Labels
- MP2MP LSPs without PE Distinguisher Labels.
In the following, we will sometimes talk of a PE receiving traffic
from a PMSI and then discarding it. If PIM [PIM] is being used as
the multicast control protocol between PEs, this always implies that
the discarded traffic will not be seen by PIM on the receiving PE,
and thus will not cause PIM state changes on that PE.
In the following, we will sometimes speak of an S-PMSI A-D route
being "ignored". When we say the route is "ignored", we do not mean
that it's normal BGP processing is not done, but that the route is
not considered when determining which P-tunnel to use when sending
multicast data, and that the MPLS label values it conveys are not
used. We will generally use "ignore" in quotes to indicate this
Rosen, et al. [Page 4]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
meaning.
3. Advertising Bidirectional P-tunnels
In this specification, we consider the use of bidirectional P-tunnels
as advertised in the PTA of a BGP S-PMSI A-D route, or as advertised
in the P-Group field or the FEC Element field of an S-PMSI Join
message.
3.1. BIDIR-PIM P-Tunnels with GRE Encapsulation
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]). The P-group address for a BIDIR-PIM P-tunnel
must be configured at the PE that is to be the root of the P-tunnel.
Associated with each such P-group address is a "Rendezvous Point
Address" (RPA). Every PE that needs to join a particular BIDIR-PIM
P-tunnel must be able to determine the RPA that corresponds to the
P-tunnel's P-group address. This may be known through configuration,
or by some automated means of RPA discovery. The RPA for a given
P-group MUST uniquely identify the PE that is to be the root of the
BIDIR-PIM tunnel.
If a BIDIR-PIM P-tunnel is to be used, the path from each PE in the
tunnel to the RPA MUST consist entirely of point-to-point links.
In order to set up a BIDIR-PIM P-Tunnel, the P routers must also be
able to determine the RPA associated with the PE at the root of the
tunnel. If this is not known via some automated means of RP
discovery, it can be determined from the PIM Join messages
themselves, where the RPA is encoded in the source address field.
The advertisement of a BIDIR-PIM P-Tunnel MUST be originated by the
root of the tunnel. Any advertisement that is not originated by the
root MUST be "ignored". If the "ignored" advertisement is a BGP A-D
route, any MPLS label specified in its PTA MUST be ignored, and any
PE Distinguisher Labels [MVPN-BGP] specified in the route MUST be
ignored.
Rosen, et al. [Page 5]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
3.2. MP2MP LSPs
An MP2MP LSP is identified by an "MP2MP FEC element" [mLDP]. The FEC
element contains the IP address of the "root", followed by an "opaque
value" that identifies the MP2MP LSP uniquely in the context of the
root's IP address. This opaque value may be configured or
autogenerated, and within an MVPN, there is no need for different
roots to use the same opaque value.
Whether a particular VPN uses MP2MP LSPs with or without PE
Distinguisher Labels is determined by provisioning.
3.2.1. MP2MP LSPs without PE Distinguisher Labels
If an MP2MP LSP without PE Distinguisher Labels is being used, then
the PE Distinguisher Labels attribute [MVPN-BGP] MUST NOT be included
in any S-PMSI A-D route containing a PTA identifying that LSP.
The advertisement of an "MP2MP LSP without PE Distinguisher Labels"
P-tunnel MUST be originated by the PE that is the root (as specified
in the advertised "FEC element") of the MP2MP LSP. Any such
advertisement that is not originated by the root MUST be "ignored".
If the "ignored" advertisement is a BGP A-D route, any MPLS label
specified in its PTA MUST be ignored, and any PE Distinguisher Labels
specified in the route MUST be ignored.
3.2.2. MP2MP LSPs with PE Distinguisher Labels
If an MP2MP LSP with PE Distinguisher Labels is being used, it MUST
be advertised in the PTA of a BGP A-D route originated by the root of
the LSP. That route MUST include a "PE Distinguisher Labels"
attribute. The PE at the root of the LSP MUST use the PE
Distingusiher Labels attribute to bind an upstream-assigned MPLS
label to the IP address of each other PE that attaches to the same
MVPN (as determined by the RTs of the A-D route). That is, the PE at
the root of the P-tunnel assigns a distinct label to each of the
other PEs attaching to the same MVPN. This set of PEs is learned via
the reception of Intra-AS I-PMSI A-D routes.
An MP2MP LSP with PE Distinguisher Labels may also be advertised in
an S-PMSI A-D route by a PE that is not at the root of the LSP. In
this case, the PE Distinguisher Labels attribute MUST be omitted.
Rosen, et al. [Page 6]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
3.2.3. Default Tunnel Identifier for MP2MP LSPs
This section applies only to MP2MP LSPs without PE Distinguisher
Labels.
To identify a MP2MP LSP, the S-PMSI Join message or the PTA of a BGP
A-D route contains an MP2MP FEC Element [mLDP] in its "Tunnel
Identifier" field. This contains the IP address of the PE at the
root of the LSP, as well as an "opaque value" which is unique at that
PE. Each PMSI Tunnel is associated at its root PE with a particular
VRF, and each VRF in a given PE has a unique default RD. Therefore
one way to uniquely identify a MP2MP LSP is to use a MP2MP FEC
Element whose Opaque Value length is 8 and whose Opaque Value value
is the default RD of the associated VRF. This method of assigning a
Tunnel Identifier MUST be the default method for any PMSI Tunnel
which is bound to (C-*,C-*) traffic. Other methods MAY be available
as well.
Note that if aggregation of multiple VPNs onto a single default MP2MP
LSP is not being supported, this method of assigning the Tunnel
Identifier allows each PE to algorithmically determine the Tunnel
Identifier that has been assigned by a particular upstream PE. A PE
decides to join a particular MP2MP LSP because it has chosen that
LSP's root as the upstream PE for a particular VPN-IP address. The
RD of that VPN-IP address is the contents of the Opaque Value field
of the corresponding MP2MP LSP FEC Element.
4. Associating Received Packets with VRFs
When a packet is received from a bidirectional P-tunnel, the packet
is first associated one or more VRFs, and then processed in the
context of that VRF or VRFs. If the bidirectional P-tunnel was
advertised in an S-PMSI Join message or in the PTA of an A-D route
that did not specify an MPLS label, then all packets received from
the P-tunnel are associated with the same set of VRFs. If the
bidirectional P-tunnel was advertised in the PTA of an A-D route, and
the PTA does specify an MPLS label, then received packets will carry
a label that must be processed in order to determine the context. If
the P-tunnel is a MP2MP LSP, this label appears below the label that
identifies the LSP itself.
If the procedure of section 3.2.3 is being used, the association of a
received packet with a VRF can be determined algorithmically.
Rosen, et al. [Page 7]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
5. Data Transmission and Reception
5.1. Without PE Distinguisher Labels
The procedures in this section apply to P-tunnels on which PE
Distinguisher Labels are not used. See section 5.2 for the
specification of the use of P-tunnels on which PE Distinguisher
Labels are used.
5.1.1. Binding (C-S,C-G) to Bidirectional P-tunnels
When PE1 advertises an S-PMSI A-D route that binds a (C-S,C-G) flow
to a bidirectional P-tunnel, or when PE1 sends an S-PMSI Join message
that binds a (C-S,C-G) flow to a bidirectional P-tunnel, the
semantics are as follows. PE1 is stating that any (C-S,C-G) traffic
that it needs to transmit to other PEs will be transmitted on the
specified P-tunnel. Any other PE that needs to receive such traffic
from PE1 (i.e., any other PE that needs to receive (C-S,C-G) traffic
and which has selected PE1 as the upstream PE for C-S) MUST join that
P-tunnel.
If a PE has joined the P-tunnel, but does not need to receive the
(C-S,C-G) traffic, or if it needs to receive (C-S,C-G) traffic but
has not selected PE1 as the upstream PE for C-S, then the PE MUST
discard any such received traffic. Please note that if PIM is being
used as the multicast control protocol, any traffic that is discarded
will not be seen by PIM, and hence will not cause the generation of
Assert messages.
5.1.2. Binding (C-*,C-G) Flows from Unidirectional C-trees
When PE1 advertises an S-PMSI A-D route or sends an S-PMSI Join
message that binds (C-*,C-G) [MVPN_WILD] to a bidirectional P-tunnel,
where C-G is not a "Source-Specific Multicast" (SSM) group, and the
(C-*,C-G) traffic is traveling on a unidirectional shared C-tree, the
semantics are as follows. PE1 is stating that any traffic to C-G
that is traveling the shared C-tree and which PE1 needs to transmit
to other PEs will be transmitted on the specified P-tunnel.
Any other PE that needs to receive such traffic from PE1 (i.e., any
other PE that needs to receive (C-*,C-G) traffic and which has
selected PE1 as the upstream PE for the C-RP corresponding to the C-G
group) MUST join that P-tunnel.
If a PE has joined the P-tunnel, but does not need to receive the
(C-*,C-G) traffic, or if it needs to receive (C-*,C-G) traffic but
Rosen, et al. [Page 8]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
has not selected PE1 as the upstream PE for the C-RP that corresponds
to C-G, then the PE MUST discard any such received traffic. Please
note that if PIM is being used as the multicast control protocol,
traffic that is discarded will not be seen by PIM.
5.1.3. Binding (C-*,C-G) Flows from Bidirectional C-trees
When PE1 advertises an S-PMSI A-D route or sends an S-PMSI Join
message that binds (C-*,C-G) to a bidirectional P-tunnel, where C-G
is not an SSM group, and the (C-*,C-G) traffic is traveling on a
bidirectional shared C-tree, the semantics are as follows:
- PE1 is stating that any traffic to C-G that it (PE1) needs to
send downstream will be sent on the specified P-tunnel
- Any other PE that is interested in receiving (C-*,C-G) traffic
MUST join the specified P-tunnel
- Any other PE, say PE2, that (a) has traffic to C-G to send
upstream and (b) has selected PE1 as its upstream PE for the
C-RPA corresponding to C-G, MUST join the specified P-tunnel, and
MUST send such traffic on the specified P-tunnel.
- If a PE, say PE3, has joined the specified P-tunnel, but does not
need to receive the (C-*,C-G) traffic, or has not selected PE1 as
the upstream PE for the C-RPA corresponding to C-G, then PE3 MUST
NOT send any (C-*,C-G) traffic on that P-tunnel, and MUST discard
any (C-*,C-G) traffic it received on that P-tunnel.
These procedures implement, for S-PMSIs, the "partitioning" scheme
described in section 11.2 of [MVPN].
The specification given so far requires an S-PMSI A-D route or an
S-PMSI Join message to be sent for each (C-*,C-G) that is using a
bidirectional C-tree. A more efficient method is given in the next
section.
5.1.4. Binding (C-*,C-*)
When PE1 advertises an S-PMSI A-D route or sends an S-PMSI Join
message that binds (C-*,C-*) to a specified bidirectional P-tunnel of
which PE1 is the root, the semantics are as that the bidirectional
P-tunnel is to be used to carry C-multicast traffic in the following
sets of cases:
Rosen, et al. [Page 9]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
1. If PE1 has (C-S,C-G) traffic that is traveling on a
source-specific C-tree, and PE1 needs to transmit that data to
one or more other PEs, and PE1 has not bound (C-S,C-G) or
(C-*,C-G) to a different P-tunnel, then the (C-S,C-G) traffic
is sent by PE1 on the specified bidirectional P-tunnel.
2. If PE1 has (C-*,C-G) traffic that is traveling on a
unidirectional shared C-tree, and PE1 needs to transmit that
data to one or more other PEs, and PE1 has not bound (C-*,C-G)
to a different P-tunnel, then the (C-*,C-G) traffic is sent by
PE1 on the specified bidirectional P-tunnel.
3. If PE1 has (C-*,C-G) traffic that is traveling on a
bidirectional shared C-tree, and PE1 needs to transmit that
data to one or more other PEs, and PE1 has not bound (C-*,C-G)
to a different P-tunnel, then the (C-*,C-G) traffic is sent by
PE1 on the specified bidirectional P-tunnel.
4. Consider some other PE, PE2, that has received the S-PMSI A-D
route or S-PMSI Join message from PE1. If PE2 has (C-*,C-G)
traffic that is traveling on a bidirectional shared C-tree, and
PE2 needs to transmit that traffic UPSTREAM, and PE2 has
selected PE1 as the upstream PE for the C-RPA corresponding to
C-G, and PE1 has not bound (C-*,C-G) to any other P-tunnel,
then the (C-*,C-G) traffic is sent by by PE2 on the specified
bidirectional P-tunnel.
5. If a PE receives traffic from a particular bidirectional
P-tunnel, and the traffic is traveling a unidirectional
(C-*,C-G) or (C-S,C-G) tree, and the root of the bidirectional
P-tunnel is not the PE's selected upstream PE for the (C-*,C-G)
or (C-S,C-G), the PE MUST discard the traffic.
6. If a PE receives traffic from a particular bidirectional
P-tunnel, and the traffic is traveling a bidirectional
(C-*,C-G) tree, and the PE's selected upstream PE for the C-RPA
corresponding to C-G is not the root of the bidirectional
P-tunnel, then the PE MUST discard the traffic.
With respect to traffic traveling a bidirectional C-tree, these
procedures implement, for S-PMSIs, the "partitioning" scheme
described in section 11.2 of [MVPN], without the need to send an
S-PMSI A-D route for each (C-*,C-G) that is using a bidirectional
C-tree. Each PE becomes the root of a bidirectional P-tunnel, and
binds the double wildcard selector to it. The bidirectional
P-tunnels serve as the "partitions". The bidirectional P-tunnel
rooted at PE1 becomes the default P-tunnel for all traffic that PE1
needs to send downstream to other PEs. It also becomes the default
Rosen, et al. [Page 10]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
P-tunnel for all traffic that others PEs need to send upstream, as
long as those other PEs have selected PE1 as the upstream PE for the
C-RPA corresponding to that traffic.
Note that other PEs SHOULD NOT join the specified bidirectional
P-tunnel unless they have a need to send or receive data over it. A
PE knows when it needs to receive data by virtue of having certain
multicast state in its C-PIM instance. With regard to multicast data
traveling on a bidirectional (C-*,C-G) tree, a PE may not know
whether it has to send data until such data actually arrives over a
VRF interface; the PE may be on a "sender-only" branch. However, the
PE in this case would have to know, through provisioning or some
automatic procedure such as "Bootstrap Routing Protocol for PIM"
(BSR) [BSR], the set of C-RPAs that are being used to support
(C-*,C-G) traffic. For each C-RPA, the PE could join the
bidirectional P-tunnel advertised by its selected upstream PE for
that C-RPA. Alternatively the PE could defer joining the P-tunnel
until it actually has data to send.
5.2. With PE Distinguisher Labels
The procedures for transmitting data on an MP2MP LSP with PE
Distinguisher Labels differ from the procedures for transmitting data
on other bidirectional P-tunnels only in the following way. Let PE1
be the root of the P-tunnel. When a packet that is traveling on a
unidirectional C-tree is transmitted on the P-tunnel by a particular
PE, say PE2, PE2 must push on the packet's label stack the label that
PE1 assigned to PE2 via the procedure above. When a packet that is
traveling on a bidirectional C-tree is transmitted on the P-tunnel by
PE2, PE2 must push on the packet's label stack the label that PE1
assigned to PE3, where PE3 is the upstream PE that PE2 has selected
for the C-RPA corresponding to C-G.
For unidirectional flows, this allows the transmitter to be
identified, and for bidirectional flows, this allows the partition to
be identified. Packets received from the wrong upstream PE or from
the wrong partition MUST be discarded. (In effect, this is a case of
tunnel hierarchy, where the PE Distinguisher Labels represent a set
of MP2MP LSPs, each of which instantiates an MS-PMSI, but those LSPs
are all tunneled through a single bidirectional P-tunnel.)
If the PTA identifying the bidirectional P-tunnel contains an MPLS
label, then that label shall appear in the label stack immediately
preceding the label specified in the PE Distinguisher Labels
attribute.
Rosen, et al. [Page 11]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
There are no additional security considerations beyond those of
[MVPN] and [MVPN-BGP].
8. Authors' Addresses
Arjen Boers
E-mail: arjen@boers.com
Yiqun Cai
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
E-mail: ycai@cisco.com
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
E-mail: erosen@cisco.com
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a Diegem 1831
Belgium
E-mail: ice@cisco.com
Rosen, et al. [Page 12]
Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010
9. Normative References
[BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley,
Kouvelas, Speakman, Vicisano, RFC 5015, October 2007
[mLDP] "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", Minei, Kompella, Wijnands, Thomas,
draft-ietf-mpls-ldp-p2mp-08.txt, October 2009
[MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al.,
draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010
[MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", Aggarwal, Rosen, Morin, Rekhter,
draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009
[MVPN_WILD] "MVPN: S-PMSI Wild Card Selectors", Cai, Rosen, Wijnands,
draft-rosen-l3vpn-mvpn-wildcards-00.txt, February 2010
[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
10. Informative References
[BSR] "Bootstrap Router (BSR) Mechanism for PIM", N. Bhaskar, et.al.,
RFC 5059, January 2008
Rosen, et al. [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-20 17:19:53 |