L3VPN Working Group Yiqun Cai
Internet Draft Eric C. Rosen (Editor)
Intended Status: Proposed Standard IJsbrand Wijnands
Expires: January 29, 2011 Cisco Systems, Inc.
July 29, 2010
MVPN: S-PMSI Wild Card Selectors
draft-rosen-l3vpn-mvpn-wildcards-01.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-01.txt July 2010
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
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 ................................ 4
4 Binding Wild Cards to Unidirectional P-Tunnels ........ 5
4.1 Binding (C-*,C-G) to a Unidirectional P-Tunnel ........ 5
4.2 Binding (C-*,C-*) to a Unidirectional P-Tunnel ........ 6
5 Use of Wild Cards with Bidirectional P-Tunnels ........ 6
6 IANA Considerations ................................... 6
7 Security Considerations ............................... 6
8 Acknowledgments ....................................... 6
9 Authors' Addresses .................................... 6
10 Normative References .................................. 7
11 Informative References ................................ 7
Rosen, et al. [Page 2]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-01.txt July 2010
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].
Another useful feature would be a way of using 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.
The Wild Card Selectors specified in this document provide additional
Rosen, et al. [Page 3]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-01.txt July 2010
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.
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].
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.
3. Encoding of Wild Cards
This specification therefore establishes the following conventions:
- In an S-PMSI A-D route, the use of a zero length source or group
field is to be interpreted as specifying a wild card value for
the respective field. A single wild card represents all Multicast
Source or Multicast Group values of all address families; there
is no need to use a different wild card for IPv4 addresses than
is used for IPv6 addresses.
- In an S-PMSI Join message, 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.
Rosen, et al. [Page 4]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-01.txt July 2010
When wildcards are used, the following two combinations MUST BE
supported:
- (C-*,C-G): Source Wildcard, Group specified.
- (C-*,C-*): Source Wildcard, Group Wildcard.
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 5]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-01.txt July 2010
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 for many helpful discussions.
9. Authors' Addresses
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
Rosen, et al. [Page 6]
Internet Draft draft-rosen-l3vpn-mvpn-wildcards-01.txt July 2010
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
[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
11. Informative References
[MVPN_BIDIR] "MVPN: Using Bidirectional P-Tunnels", Cai, Rosen,
Wijnands, draf-rosen-l3vpn-mvpn-bidir-01.txt, July 2010
Rosen, et al. [Page 7]