< draft-rosen-l3vpn-mvpn-bier-01.txt   draft-rosen-l3vpn-mvpn-bier-02.txt >
Internet Engineering Task Force E. Rosen, Ed. Internet Engineering Task Force E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track M. Sivakumar Intended status: Standards Track M. Sivakumar
Expires: April 19, 2015 IJ. Wijnands Expires: June 7, 2015 IJ. Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
S. Aldrin S. Aldrin
Huawei Technologies Huawei Technologies
A. Dolganow A. Dolganow
Alcatel-Lucent Alcatel-Lucent
T. Przygienda T. Przygienda
Ericsson Ericsson
October 16, 2014 December 4, 2014
Multicast VPN Using BIER Multicast VPN Using BIER
draft-rosen-l3vpn-mvpn-bier-01 draft-rosen-l3vpn-mvpn-bier-02
Abstract Abstract
The Multicast Virtual Private Network (MVPN) specifications require The Multicast Virtual Private Network (MVPN) specifications require
the use of multicast tunnels ("P-tunnels") that traverse a Service the use of multicast tunnels ("P-tunnels") that traverse a Service
Provider's backbone network. The P-tunnels are used for carrying Provider's backbone network. The P-tunnels are used for carrying
multicast traffic across the backbone. A variety of P-tunnel types multicast traffic across the backbone. A variety of P-tunnel types
are supported. Bit Index Explicit Replication (BIER) is a new are supported. Bit Index Explicit Replication (BIER) is a new
architecture that provides optimal multicast forwarding through a architecture that provides optimal multicast forwarding through a
"multicast domain", without requiring intermediate routers to "multicast domain", without requiring intermediate routers to
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2015. This Internet-Draft will expire on June 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4 2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4
3. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 6 3. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 6
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
[RFC6513] and [RFC6514] specify the protocols and procedures that a [RFC6513] and [RFC6514] specify the protocols and procedures that a
Service Provider (SP) can use to provide Multicast Virtual Private Service Provider (SP) can use to provide Multicast Virtual Private
Network (MVPN) service to its customers. Multicast tunnels are Network (MVPN) service to its customers. Multicast tunnels are
created through an SP's backbone network; these are known as created through an SP's backbone network; these are known as
"P-tunnels". The P-tunnels are used for carrying multicast traffic "P-tunnels". The P-tunnels are used for carrying multicast traffic
across the backbone. The MVPN specifications allow the use of across the backbone. The MVPN specifications allow the use of
several different kinds of P-tunnel technology. several different kinds of P-tunnel technology.
skipping to change at page 3, line 25 skipping to change at page 3, line 28
MVPN traffic must sometimes traverse more than one IGP domain, MVPN traffic must sometimes traverse more than one IGP domain,
whereas BIER only carries multicast traffic within a single IGP whereas BIER only carries multicast traffic within a single IGP
domain. However, the MVPN specifications allow P-tunnels to be domain. However, the MVPN specifications allow P-tunnels to be
"segmented", where the segmentation points may either be Autonomous "segmented", where the segmentation points may either be Autonomous
System Border Routers (ASBRs), as described in [RFC6514], or Area System Border Routers (ASBRs), as described in [RFC6514], or Area
Border Routers (ABRs), as described in [SEAMLESS_MCAST]. As long as Border Routers (ABRs), as described in [SEAMLESS_MCAST]. As long as
the segmentation points are capable of acting as BFIRs and BFERs, the segmentation points are capable of acting as BFIRs and BFERs,
BIER can be used to provide some or all of the segments of a BIER can be used to provide some or all of the segments of a
P-tunnel. P-tunnel.
This revision of the document does not specify the procedures
necessary to support MVPN customers that are using BIDIR-PIM. Those
procedures will be added in a future revision.
This document uses the following terminology from [BIER_ARCH]: This document uses the following terminology from [BIER_ARCH]:
o BFR: Bit-Forwarding Router. o BFR: Bit-Forwarding Router.
o BFIR: Bit-Forwarding Ingress Router. o BFIR: Bit-Forwarding Ingress Router.
o BFER: Bit-Forwarding Egress Router. o BFER: Bit-Forwarding Egress Router.
This document uses the following terminology from [RFC6513]: This document uses the following terminology from [RFC6513]:
o MVPN: Multicast Virtual Private Network -- a VPN [L3VPN] in which o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in
multicast service is offered. which multicast service is offered.
o P-tunnel. A multicast tunnel through the network of one or more o P-tunnel. A multicast tunnel through the network of one or more
SPs. P-tunnels are used to transport MVPN multicast data SPs. P-tunnels are used to transport MVPN multicast data
o C-S: A multicast source address, identifying a multicast source o C-S: A multicast source address, identifying a multicast source
located at a VPN customer site. located at a VPN customer site.
o C-G: A multicast group address used by a VPN customer. o C-G: A multicast group address used by a VPN customer.
o C-flow: A customer multicast flow. Each C-flow is identified by o C-flow: A customer multicast flow. Each C-flow is identified by
skipping to change at page 4, line 37 skipping to change at page 4, line 44
identify the particular P-tunnel to which one or more multicast flows identify the particular P-tunnel to which one or more multicast flows
are being assigned. are being assigned.
The PMSI Tunnel attribute (PTA)contains the following fields: The PMSI Tunnel attribute (PTA)contains the following fields:
o "Tunnel Type". IANA is requested to assign a new tunnel type o "Tunnel Type". IANA is requested to assign a new tunnel type
codepoint for "BIER". This codepoint will be used to indicate codepoint for "BIER". This codepoint will be used to indicate
that the PMSI is instantiated by BIER. that the PMSI is instantiated by BIER.
o "Tunnel Identifier". When the "tunnel type" field is "BIER", this o "Tunnel Identifier". When the "tunnel type" field is "BIER", this
field contains the BFR-Prefix (see [BIER_ARCH]) of the originator field contains two subfields:
of the route that is carrying the PMSI Tunnel attribute. This
will either be a /32 IPv4 address or a /128 IPv6 address. Whether 1. The first subfield is a single octet, containing the sub-
the address is IPv4 or IPv6 can be inferred from the total length domain-id of the sub-domain to which the BFIR will assign the
of the PMSI Tunnel attribute. packets that it transmits on the PMSI identified by the NLRI
of the BGP I-PMSI or S-PMSI A-D route that contains this PTA.
(How that sub-domain is chosen is outside the scope of this
document.)
2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the
originator of the route that is carrying this PTA. This will
either be a /32 IPv4 address or a /128 IPv6 address. Whether
the address is IPv4 or IPv6 can be inferred from the total
length of the PMSI Tunnel attribute.
o "MPLS label". This field contains an upstream-assigned MPLS o "MPLS label". This field contains an upstream-assigned MPLS
label. It is assigned by the router that originates the BGP route label. It is assigned by the router that originates the BGP route
to which the PTA is attached. Constraints on the way in which the to which the PTA is attached. Constraints on the way in which the
originating router selects this label are discussed below. originating router selects this label are discussed below.
o "Leaf Info Required Bit". The setting of this bit depends upon o "Leaf Info Required Bit". The setting of this bit depends upon
the type of route and the NLRI of the route that carries the PTA. the type of route and the NLRI of the route that carries the PTA.
* In an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D route, the bit * In an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D route, the bit
skipping to change at page 6, line 7 skipping to change at page 6, line 23
BIER.. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS BIER.. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS
label, UNLESS both of the following conditions hold: label, UNLESS both of the following conditions hold:
o R1 and R2 have the same "originating router" in their respective o R1 and R2 have the same "originating router" in their respective
NLRIs. NLRIs.
o R1 and R2 specify the same MPLS label in their respective PTAs. o R1 and R2 specify the same MPLS label in their respective PTAs.
3. Explicit Tracking 3. Explicit Tracking
[Editor's note: The procedures of this section are still under
discussion, and significant changes may be expected in the next
revision.]
When using BIER to transport an MVPN data packet through a BIER When using BIER to transport an MVPN data packet through a BIER
domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The
BFIR must determine the set of BFERs to which the packet needs to be BFIR must determine the set of BFERs to which the packet needs to be
delivered. This is done by using the explicit tracking mechanism delivered. This is done by using the explicit tracking mechanism
specified in [RFC6513] and [RFC6514]. specified in [RFC6513] and [RFC6514].
To determine the set of BFERs to which a given MVPN data packet needs To determine the set of BFERs to which a given MVPN data packet needs
to be delivered, the BFIR originating an S-PMSI A-D route sets the to be delivered, the BFIR originating an S-PMSI A-D route sets the
LIR bit in the route's PTA. Per [RFC6514], the BFERs will respond LIR bit in the route's PTA. Per [RFC6514], the BFERs will respond
with Leaf A-D routes. By matching the received Leaf A-D routes to with Leaf A-D routes. By matching the received Leaf A-D routes to
skipping to change at page 6, line 45 skipping to change at page 7, line 19
To transmit an MVPN data packet, an ingress PE follows the rules of To transmit an MVPN data packet, an ingress PE follows the rules of
[RFC6625] to find the S-PMSI A-D route or I-PMSI A-D route that is a [RFC6625] to find the S-PMSI A-D route or I-PMSI A-D route that is a
"match for transmission" for that packet. (In applying the rules of "match for transmission" for that packet. (In applying the rules of
[RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel [RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel
information" is ignored.) If the matching route has a PTA specifying information" is ignored.) If the matching route has a PTA specifying
a "BIER", the (upstream-assigned) MPLS label from that PTA is pushed a "BIER", the (upstream-assigned) MPLS label from that PTA is pushed
on the packet's label stack. Then the packet is forwarded according on the packet's label stack. Then the packet is forwarded according
to the procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially to the procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially
Section 4, "Imposing and Processing the BIER Encapsulation", of Section 4, "Imposing and Processing the BIER Encapsulation", of
[BIER_ENCAPS].) Since the "payload" (as defined in [BIER_ENCAPS]) is [BIER_ENCAPS].)
an MPLS packet with an upstream-assigned label, the BIER header MUST
have the "I bit" set, and the BFIR-id MUST be included in the BIER
header.
When a BFER receives an MVPN multicast data packet that has been When a BFER receives an MVPN multicast data packet that has been
BIER-encapsulated, the BIER layer passes the following information to BIER-encapsulated, the BIER layer passes the following information to
the multicast flow layer: the multicast flow layer:
o The BFR-prefix corresponding to the BFR-id in the BIER header. o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in
the BIER header.
o The "payload", which is an MPLS packet whose top label is an o The "payload", which is an MPLS packet whose top label is an
upstream-assigned label. The BFR-prefix provides the "context" in upstream-assigned label. The BFR-prefix provides the "context" in
which the upstream-assigned label is interpreted. which the upstream-assigned label is interpreted.
5. IANA Considerations Note that per [RFC5331], the context for an upstream-assigned
label is the IP address of the label assigner, which in this case
is the BFR-prefix of the BFIR.
5. Acknowledgments
The authors wish to thank Jeffrey Zhang for his ideas and
contributions to this work.
6. IANA Considerations
IANA is requested to assign a value for "BIER" from the "P-Multicast IANA is requested to assign a value for "BIER" from the "P-Multicast
Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The
reference should be this document. reference should be this document.
6. Security Considerations 7. Security Considerations
The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513] The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513]
and [RFC6514] are applicable. and [RFC6514] are applicable.
7. References 8. References
7.1. Normative References 8.1. Normative References
[BIER_ARCH] [BIER_ARCH]
Wijnands, IJ., "Multicast using Bit Index Explicit Wijnands, IJ., "Multicast using Bit Index Explicit
Replication Architecture", internet-draft draft-wijnands- Replication Architecture", internet-draft draft-wijnands-
bier-architecture-00, September 2014. bier-architecture-02, December 2014.
[BIER_ENCAPS] [BIER_ENCAPS]
Wijnands, IJ., "Multicast using Bit Index Explicit Wijnands, IJ., "Multicast using Bit Index Explicit
Replication Architecture", internet-draft draft-wijnands- Replication Architecture", internet-draft draft-wijnands-
mpls-bier-encapsulation-00, September 2014. mpls-bier-encapsulation-02, December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", RFC
5331, August 2008.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012. VPNs", RFC 6513, February 2012.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, February 2012.
[RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu,
"Wildcards in Multicast VPN Auto-Discovery Routes", RFC "Wildcards in Multicast VPN Auto-Discovery Routes", RFC
6625, May 2012. 6625, May 2012.
7.2. Informative References 8.2. Informative References
[EXTRANET] [EXTRANET]
Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP
MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet- MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet-
05, July 2014. 05, July 2014.
[SEAMLESS_MCAST] [SEAMLESS_MCAST]
Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I.,
Leymann, N., and S. Saad, "Inter-Area P2MP Segmented Leymann, N., and S. Saad, "Inter-Area P2MP Segmented
LSPs", internet-draft draft-ietf-mpls-seamless-mcast-14, LSPs", internet-draft draft-ietf-mpls-seamless-mcast-14,
 End of changes. 19 change blocks. 
30 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/