L3VPN Working Group Yiqun Cai
Internet Draft Eric C. Rosen (Editor)
Intended Status: Proposed Standard IJsbrand Wijnands
Expires: August 3, 2011 Cisco Systems, Inc.
February 3, 2011
MVPN: S-PMSI Wild Card Selectors
draft-rosen-l3vpn-mvpn-wildcards-05.txt
Abstract
In the procedures for Multicast Virtual Private Networks, individual
customer multicast flows can be assigned to specific multicast
tunnels through a service provider network. This document specifies
the encoding and semantics of "wild card selectors", which can be
used to assign certain sets of customer multicast flows as a group to
specific multicast 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.
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.
Rosen, et al. [Page 1]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-05.txt February 2011
Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Specification of requirements ......................... 3
2 Introduction .......................................... 3
3 Encoding of Wild Cards ................................ 5
4 Binding Wild Cards to Unidirectional P-Tunnels ........ 6
4.1 Binding (C-*,C-G) to a Unidirectional P-Tunnel ........ 6
4.2 Binding (C-*,C-*) to a Unidirectional P-Tunnel ........ 7
5 Use of Wild Cards with Bidirectional P-Tunnels ........ 7
6 IANA Considerations ................................... 7
7 Security Considerations ............................... 7
8 Acknowledgments ....................................... 7
9 Authors' Addresses .................................... 7
10 Normative References .................................. 8
11 Informative References ................................ 9
Rosen, et al. [Page 2]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-05.txt February 2011
1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
Note: this document uses terminology from [MVPN], and in particular
uses the prefixes "C-" and "P-" as specified in section 3.1 of
[MVPN].
As specified in [MVPN] and [MVPN-BGP], one can use an S-PMSI A-D
route or an S-PMSI Join Message to assign a particular C-multicast
flow, identified as (C-S,C-G), to a particular S-PMSI.
However, [MVPN-BGP] does not specify any means of encoding wild cards
("*", in multicast terminology) in the Source or Group fields.
Similarly, [MVPN] does not specify any means of encoding wild cards
in the C-Source or C-Group fields of the S-PMSI Join messages.
This omission makes it difficult to provide optimized multicast
routing for customers that use ASM ("Any Source Multicast")
multicasts, in which flows may be traveling along "shared" C-trees.
We use the term "shared C-trees" to refer both to the the
unidirectional "RPT trees" used in "PIM sparse mode" [PIM], and to
the bidirectional trees used in BIDIR-PIM [BIDIR-PIM].
When a customer is using ASM multicast, it is useful to be able to
select the set of flows that are traveling along a shared C-tree, and
to bind that entire set of flows to a specified P-tunnel.
Conceptually, we would like to have a way to express that we want
(C-*,C-G) traffic bound to the specified P-tunnel. A multicast data
packet whose source address is C-S and whose destination address is
an ASM group address is said to be traveling a shared C-tree from the
perspective of a given router if that router's decision to forward
the packet is based upon (C-*,C-G) state rather than upon (C-S,C-G)
state. Creation and use of these multicast states is specified in
[PIM] and/or [MVPN-BGP].
It is also useful to be able to use an S-PMSI A-D route to say "by
default, all multicast traffic (within a given VPN) that has not been
bound to any other P-tunnel is bound to the specified P-tunnel". To
do this we, need to have a way to express that we want (C-*, C-*)
traffic bound to the P-tunnel.
When an MVPN customer is using BIDIR-PIM, it is useful to be able to
Rosen, et al. [Page 3]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-05.txt February 2011
use an S-PMSI A-D route to say "by default, all BIDIR-PIM multicast
traffic (within a given VPN) that has not been bound to any other
P-tunnel is bound to the specified P-tunnel". To do this we, need to
have a way to express a (C-*, C-*) wildcard that is restricted to
BIDIR-PIM C-groups.
The Wild Card Selectors specified in this document provide additional
functionality:
- One can send an S-PMSI A-D route or S-PMSI Join Message whose
semantics are "assign all the traffic traveling the (C-*,C-G)
tree to this S-PMSI".
- One can send an S-PMSI A-D route or S-PMSI Join Message whose
semantics are "use this S-PMSI as the default method for carrying
any (C-S,C-G) or (C-*,C-G) traffic that isn't assigned to a
different S-PMSI". That is, it allows for the use of S-PMSIs as
the default PMSIs for carrying data traffic. It is also possible
to separately assign BIDIR-PIM C-groups by default to a
particular P-Tunnel.
This document specifies the encoding of the wild card selectors, and
provides rules for their usage and interpretation when S-PMSIs are
instantiated as unidirectional P-tunnels. Rules for their usage and
interpretation when S-PMSIs are instantiated as bidirectional
P-tunnels may be found in [MVPN-BIDIR].
Note that, per [MVPN-BGP], an S-PMSI A-D route is carried in the
Network Layer Reachability Information (NLRI) field of an
MP_REACH_NLRI attribute (see [BGP-MP]). Every S-PMSI A-D route has a
particular address family (IPv4 or IPv6), as specified in the Address
Family Information AFI field of the MP_REACH_NLRI attribute. A wild
card selector in a particular S-PMSI A-D route always refers only to
multicast flows of that same address family.
In the following, we will sometimes talk of a PE receiving traffic
from a PMSI and then discarding it. If 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.
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 its 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
meaning.
Rosen, et al. [Page 4]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-05.txt February 2011
3. Encoding of Wild Cards
Per [MVPN-BGP] section 4.3, the MCAST-VPN NLRI in an S-PMSI A-D route
is encoded as follows:
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
| Originating Router's IP Addr |
+-----------------------------------+
In S-PMSI A-D routes, the wild card selectors are encoded as follows:
- A source wildcard is encoded as a zero-length source field. That
is, the "multicast source length" field contains the value 0x00,
and the "multicast source" field is omitted.
- A group wildcard is encoded as a zero-length group field. That
is, the "multicast group length" field contains the value 0x00,
and the "multicast group" field is omitted.
- We also define a special value of the group wildcard, whose
meaning is "all BIDIR-PIM groups". The "BIDIR-PIM group
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.
In S-PMSI Join messages, the use of an all-zero C-Source or C-Group
field is to be interpreted as specifying a wild card value for the
respective field. A wild card represents all C-Source or C-group
values of a particular address family (IPv4 or IPv6), as specified by
the S-PMSI Join message type. A "BIDIR-PIM group wildcard" for the
S-PMSI Join message is not defined in this document.
An implementation that supports wildcards at all MUST support the
following two uses of wildcards:
Rosen, et al. [Page 5]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-05.txt February 2011
- (C-*,C-G): Source Wildcard, Group specified.
- (C-*,C-*): Source Wildcard, Group Wildcard.
Additionally, if support for customer BIDIR-PIM flows is being
provided, support for the "all BIDIR-PIM groups" wildcard is also
REQUIRED. With regard to the procedures of section 4.2, the "all
BIDIR-PIM groups" wildcard is treated identically to the (C-*,C-*)
wildcard, except that it applies only to BIDIR-PIM groups.
This specification does not provide support for the combination of a
specified source and a group wildcard. A received S-PMSI A-D route
or S-PMSI Join message specifying this combination will be "ignored".
4. Binding Wild Cards to Unidirectional P-Tunnels
4.1. Binding (C-*,C-G) to a Unidirectional P-Tunnel
Consider an S-PMSI A-D Route whose NLRI specifies (C-*,C-G), and that
contains a PMSI Tunnel Attribute (PTA) [MVPN-BGP] that specifies a
unidirectional P-tunnel. The P-tunnel may be a P2MP LSP, or it may
be a unidirectional PIM-created multicast distribution tree specified
either as (P-*,P-G) or as (P-S,P-G).
Alternately, consider an S-PMSI Join message, whose C-Source and
C-Group fields specify (C-*,C-G), and that specifies a unidirectional
P-tunnel (either a P2MP LSP or a unidirectional PIM-created multicast
distribution tree.)
If C-G is known to be an SSM group address, the S-PMSI A-D route or
S-PMSI Join message is "ignored".
The semantics of binding (C-*,C-G) to a unidirectional P-tunnel are
the following: the originator of the S-PMSI A-D route or S-PMSI Join
message is saying that if it receives, over a VRF interface, any
traffic that is traveling on the (C-*,C-G) shared tree, and if it is
to forward such traffic to other PEs, then it will transmit such
traffic on the specified P-tunnel. Any PE interested in receiving
(C-*,C-G) traffic from the originator (i.e., if the originator is
PE's upstream multicast hop for the (C-*,C-G) state) MUST join that
P-tunnel.
Rosen, et al. [Page 6]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-05.txt February 2011
4.2. Binding (C-*,C-*) to a Unidirectional P-Tunnel
The originator of an S-PMSI A-D Route or an S-PMSI Join message that
binds (C-*,C-*) to a unidirectional P-tunnel is saying that by
default, if it is required by its C-PIM instance to forward multicast
traffic to any other PE, then by default it will send the traffic on
the specified tunnel. The default applies to any traffic that has
not been explicitly assigned to another P-tunnel.
5. Use of Wild Cards with Bidirectional P-Tunnels
The specification for the use of wild cards with bidirectional
P-Tunnels can be found in [MVPN_BIDIR].
6. IANA Considerations
This document requires no actions of IANA.
7. Security Considerations
There are no additional security considerations beyond those of
[MVPN] and [MVPN-BGP].
8. Acknowledgments
The authors wish to thank Arjen Boers, Dongling Duan, Apoorva Karan,
Keyur Patel, and Karthik Subramanian for many helpful discussions.
9. Authors' Addresses
Yiqun Cai
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
E-mail: ycai@cisco.com
Rosen, et al. [Page 7]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-05.txt February 2011
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
10. Normative References
[BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley,
Kouvelas, Speakman, Vicisano, RFC 5015, October 2007
[BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra,
D. Katz, Y. Rekhter, RFC 4760, January 2007
[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, Kodeboniya,
draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009
[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 8]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-05.txt February 2011
11. Informative References
[MVPN-BIDIR] "MVPN: Using Bidirectional P-Tunnels", Cai, Rosen,
Wijnands, draft-rosen-l3vpn-mvpn-bidir-02.txt, January 2011
Rosen, et al. [Page 9]