Internet DRAFT - draft-wang-mboned-glo-ipv6-mcast-reachability
draft-wang-mboned-glo-ipv6-mcast-reachability
Mboned WG C. Wang
Internet-Draft W. Meng
Intended status: Standards Track ZTE Corporation
Expires: April 14, 2014 B. Khasnabish
ZTE USA,Inc
J. Hu
China Telecom
October 11, 2013
Interconnecting IPv6 Multicast Islands over IPv4 Using IPv6 Multicast
Provider Edge Routers
draft-wang-mboned-glo-ipv6-mcast-reachability-01
Abstract
This draft presents a method to interconnect IPv6 multicast islands
over an IPv4 cloud. This method relies on IPv6 Multicast Provider
Edge routers (6MPE), which support Dual-Stack and in order to connect
IPv6 multicast islands to the IPv4 core. The 6MPE routers extend the
Multiprotocol Border Gateway Protocol(MP-BGP), define a new Network
Layer Reachability Information(NLRI) called MCAST-IPv6 NLRI, and
exchange the IPv6 multicast reachability information transparently
over the IPv4 core using the MP-BGP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 14, 2014.
Copyright 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
Wang, et al. Expires April 14, 2014 [Page 1]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Keywords and Terminology . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology, and Definition of Terms . . . . . . . . . . . 5
3. MCAST-IPv6 NLRI . . . . . . . . . . . . . . . . . . . . . . . 6
4. Tunnel Attribute . . . . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Wang, et al. Expires April 14, 2014 [Page 2]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
1. Introduction
There is already an approach for providing IPv6 connectivity over an
IPv4 core network named Softwire Mesh Multicast, however, this
approach results in inefficient bandwidth and resource utilization.
And there is also already an approach for providing IPv4/IPv6
connectivity over VPN core network name MVPN[RFC6513] and MVPN-
BGP[RFC6514], however, this approach just provides VPN service over
IPv4/IPv6 network. The approach used in this document named IPv6
Multicast Provider Edge (6MPE) is a MVPN-like solution which connects
non-VPN IPv6 multicast islands over IPv4 core network.
The 6MPE approach specified in this document requires that the edge
routers (the 6MPE routers) be connected to IPv6 multicast islands and
support Dual-Stack Multiprotocol-BGP, and the core routers run IPv4
only. And can be used for customers that already have an IPv4
multicast service from the network provider and additionally require
an IPv6 multicast service, as well as for customers that require only
IPv6 connectivity.
The 6MPE approach specified in this document defines a new Network
Layer Reachability Information (NLRI)[RFC4760], MCAST-IPv6 NLRI. The
MCAST-IPv6 NLRI is used for 6MPE routers auto-discovery, advertising
IPv6 islands multicast routing information exchange among 6MPE
routers.
Note that the 6MPE approach specified in this document provides
global IPv6 reachability. Deployment of the 6MPE approach over an
existing IPv4 cloud does not require an introduction of new
mechanisms in the core. Configurations and operations of the 6MPE
approach have a lot of similarities with the configurations and
operations of an IPv4 MVPN service or IPv6 MVPN service ([RFC6513]
and [RFC6514]). However, the configuration and operations of the
6MPE approach are somewhat simpler, since it does not involve all the
VPN concepts such as Virtual Routing and Forwarding (VRFs) tables,RD
and aggregation etc.
This document cites the format of Route Type defined in MCAST-VPN
NLRI and modifies the format to adapt MCAST-IPv6 NLRI, which
discussed in following sections in details.
This document cites the PMSI Tunnel Attribute defined in MVPN-BGP
(RFC6514) and modifies the format to adapt tunnel attribute defined
in 6MPE approach, which discussed in following section in details.
This document cites a BGP Extended Communities defined in MVPN: the
source Autonomous System (AS) Extended Community.
Wang, et al. Expires April 14, 2014 [Page 3]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
In this document an "IPv6 multicast island" is a network running
native IPv6 multicast. A typical example of an IPv6 multicast island
would be a customer's IPv6 site connected via its IPv6 Customer Edge
(CE) to one (or more) Dual-Stack Multicast Provider Edge router(s) of
a Service Provider. These IPv6 Multicast Provider Edge routers
(6MPE) are connected to an IPv4 core network. Corresponding scenario
sees figure 1.
+--------+
|site A CE---+ +--------------------+
+--------+ | | | +---------+
6MPE-+ IPv4 core +-6MPE-- CE site C |
+--------+ | | | +---------+
|site B CE---+ +--------------------+
+--------+
IPv6 islands IPv4 network IPv6 islands
<-------------> <---------------------> <-------------->
Figure 1: A Framework for IPv6 Multicast Interconnect over IPv4
Network
Wang, et al. Expires April 14, 2014 [Page 4]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
2. Keywords and Terminology
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.1. Terminology, and Definition of Terms
In the context of this document, we will refer to the 6MPE auto-
discovery/binding information carried in BGP as "6MPE A-D routes".
And there are the following types of 6MPE A-D routes:
+ Intra-AS 6MPE A-D route;
+ Inter-AS 6MPE A-D route;
+ 4-MSI 6MPE A-D route;
+ Leaf 6MPE A-D route;
+ Source Active 6MPE A-D route;
In the context of this document, we will refer to the 6MPE customers
multicast routing information carried in BGP as "IPv6-multicast
routes". And there are the following types of IPv6-multicast routes:
+ (*,G) Join route;
+ (S,G) Join route;
Wang, et al. Expires April 14, 2014 [Page 5]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
3. MCAST-IPv6 NLRI
This document defines a new BGP NLRI, called the MCAST-IPv6 NLRI.
The format of the MCAST-IPv6 NLRI is the same as MCAST-VPN NLRI and
the Route Types for 6MPE A-D routes are as follow:
+1 Intra-AS 6MPE A-D route;
+2 Inter-AS 6MPE A-D route;
+3 4-MSI 6MPE A-D route;
+4 Leaf 6MPE A-D route;
+5 Source Active 6MPE A-D route;
+6 (*,G) Join route;
+7 (S,G) Join route;
The MCAST-IPv6 NLRI is carried in BGP using BGP Multiprotocol
Extensions with Address Family Identifier(AFI) of 2 and a Subsequent
AFI(SAFI) of MCAST-IPv6.
In order for two BGP speakers to exchange MCAST-IPv6 NLRIs, they must
use a BGP Capabilities Advertisement to ensure that they both are
capable of properly processing such an NLRI. This is done as
specified in [RFC4760], by using capability code 1 with an AFI of 2
and an SAFI of MCAST-IPv6.
The format of the Route Type specific MCAST-IPv6 NLRI for various
Route Types defined in this document cite from MVPN, except remove
the RD field in each Route Type and replace the Originating Router's
IP Addr with 6MPE Router-ID.
6MPE Router-ID uniquely identifies a 6MPE router.
Wang, et al. Expires April 14, 2014 [Page 6]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
4. Tunnel Attribute
This document can define and use a new BGP attribute called the
"IPv4-Multicast Service Interface Tunnel (4-MSI) attribute" which is
like PMSI Tunnel Attribute defined in MVPN but remove the MPLS Label
field or reuse PMSI Tunnel Attribute but set the MPLS Label field
invalid value.
The Tunnel Type and the usage are the same as the Tunnel Type in PMSI
Tunnel attribute.
Wang, et al. Expires April 14, 2014 [Page 7]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
5. Protocol Overview
Interconnection of IPv6 multicast islands over an IPv4 network is
achieved by executing the following steps:
1. The 6MPE routers MUST have auto-discovery/binding
mechanism[RFC6513 and RFC6514] to discovery other 6MPE routers, and
trigger IPv4 cloud to build inclusive IPv4-multicast service tunnel
as necessary.
2. Exchange IPv6 multicast routing reachability information among
6MPE routers.
3. Trigger IPv4 cloud to build selective IPv4-multicast service
tunnel.
In executing step 1-3, the 6MPE routers convey the IPv4 address of
6MPE Router-ID as the BGP Next Hop for the advertised A-D routes.
And the IPv4 address MUST be encoded as an IPv4-mapped IPv6 address
in the BGP Next Hop field. This encoding is consistent with the
definition of an IPv4-mapped IPv6 address in [RFC4291].
4. Binding IPv6 multicast islands' multicast tree to selective IPv4-
multicast service tunnel.
5. Transport IPv6 multicast packets from the ingress 6MPE router
which is nearby the IPv6 multicast source to the egress 6MPE routers
which are nearby the multicast receivers over IPv4-multicast service
tunnel.
Wang, et al. Expires April 14, 2014 [Page 8]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
6. Security Considerations
The security considerations documented in [RFC6513] and [RFC6514] are
to be considered. Additional requirements may be added in the future
version of this draft.
Wang, et al. Expires April 14, 2014 [Page 9]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
7. IANA Considerations
This document defines a new NLRI, called "MCAST-IPv6", to be carried
in BGP.
Wang, et al. Expires April 14, 2014 [Page 10]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012.
Wang, et al. Expires April 14, 2014 [Page 11]
Internet-Draft connect IPv6 Multicast Islands over IPv4 October 2013
Authors' Addresses
Cui Wang
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: wang.cui1@zte.com.cn
Wei Meng
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: meng.wei2@zte.com.cn,vally.meng@gmail.com
Bhumip Khasnabish
ZTE USA,Inc
55 Madison Avenue, Suite 160
Morristown, NJ 07960
USA
Email: bhumip.khasnabish@zteusa.com,vumip1@gmail.com
Jie Hu
China Telecom
No.118, Xizhimennei
Beijing 100035
China
Email: huj@ctbri.com.cn
Wang, et al. Expires April 14, 2014 [Page 12]
