Internet DRAFT - draft-cao-mcast-for-ipv6-ppvpn
draft-cao-mcast-for-ipv6-ppvpn
Network Working Group Wei Cao
Internet Draft Hui Liu
Huawei
Qiang He
Expires: August 2006 February 24, 2006
Multicast in MPLS/BGP IPv6 VPNs
draft-cao-mcast-for-ipv6-ppvpn-00.txt
Status of this Memo
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is an Internet-Draft and is in full conformance with
all provisions of RFC 3978/3979 .
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.
Abstract
This document describes a method by which a Service Provider may
deploy IPv6 multicast service in BGP/MPLS IPv6 VPNs. Multicast in
IPv4 BGP/MPLS VPN has been in operation for several years and related
drafts are on RFC standard track . IPv6 infrastructure is under
construction and new application based on IPv6 is being developing
Cao, et al. Expires August 24, 2006 [Page 1]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
now. Multicast will act an important role in the future IPv6
environment. This document reuses and extends the method defined in
draft-ietf-l3vpn-2547bis-mcast-01 to support multicast traffic in
IPv6 VPNs. Specially, both IPv6 core and IPv4 core are considered in
this document.
The inter-working between an IPv4 site and an IPv6 sited is
outside the scope of this document.
Table of Contents
1. Introduction................................................3
1.1. Motivations............................................3
1.2. Overview...............................................3
1.3. Scope and target of this document.......................4
2. Protocols and PMSI..........................................4
2.1. Multicast Protocol supported in IPv6 VPN................4
2.2. PMSI to Transmit IPv6 Multicast Traffic.................4
2.3. Auto discovery of MVPN Members..........................5
2.4. <Sub-section 2.1 heading as appropriate>...
3. Extension for BGP and PIM messages...........................5
3.1. MDT SAFI...............................................5
3.2. BGP Connector Attribute.................................6
3.3. PIM RPF Vector.........................................6
3.4. Extensions for MTD TLV..................................7
3.5. Extensions for MDT Join TLV.............................8
4. Encapsulation...............................................8
4.1. Encapsulating IPv6 Traffic In IPv4 Multicast Packet......9
4.2. Encapsulating IPv6 Traffic In IPv6 Multicast Packet......9
5. Security Considerations......................................9
6. IANA Considerations........................................10
7. Acknowledgments............................................10
7.1. Normative References...................................11
7.2. Informative References.................................11
Author's Addresses............................................11
Intellectual Property Statement................................12
Disclaimer of Validity........................................12
Copyright Statement...........................................12
Cao, et al. Expires August 24, 2006 [Page 2]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
1. Introduction
This document describes a method by which a Service Provider may
deploy IPv6 multicast service in BGP/MPLS IPv6 VPNs. This document
reuses and extends the method defined in [MVPN] and [ROSEN] to
support multicast traffic in IPv6 VPNs. Specially, both IPv6 core and
Ipv4 core are discussed in this document. This document adopts the
definitions, acronyms and mechanisms defined in [MVPN], the details
of MVPN will not be re-described unless necessary.
1.1. Motivations
With the mature of techniques and more available devices IPv6 has
attracted more and more attention than before. BGP/MPLS VPN solution,
which is widely accepted and deployed in IPv4 network, has its
extension in IPv6 network and called as 6VPN. [6VPN] describes the
details of the method. Now several device vendors are planning to
provide 6VPN in near future.
IP multicast is accepted and used by more and more VPN customers
in their private infrastructures. Naturally, 6VPN customer may need
deploy multicast in their VPNs as they do in IPv4 VPNs. But in up-to-
date documents, there are still little discussions pertaining to
multicast in 6VPN.
As it is known that implementation of IPv4 MVPN is provided before
related specification had been specified, several problems (which are
mentioned in [MVPN-EXP]) appeared in deployment. So it is better to
pay some attention prior to the commencement of the deployment of
IPv6 MVPN.
1.2. Overview
[MVPN], as well as early "rosen-drafts", specifies the method to
provide multicast service in BGP/MPLS VPNS. The same method can be
used to enable multicast traffic transmitted between different IPv6
VPN sites. And form both the Service Provider and the customer
perspectives, the multicast service in IPv6 VPN should be identical
to that supported in IPv4 VPNs. The PE routers exchange the IPv6
reachability information for IPv6 VPN sites and PMSI is established
to transmit IPv6 Multicast traffic through core network. Customers
don't care and need not to know the network topology out their
private networks. It should be noted that IPv6 6VPN needs to support
both IPv4 and IPv6 core network that connect different IPv6 VPN Sites.
So IPv6 multicast traffic may be encapsulated in IPv6 or IPv4 packet
in the core network. In near future, using IPv4 core network seems
Cao, et al. Expires August 24, 2006 [Page 3]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
more attractive to the Service Providers. If IPv4 core network is
used all PE devices have to support IPv4/IPv6 dual stack.
1.3. Scope and target of this document
This document hopes to be helpful to the product vendors who plan to
support multicast in 6VPN, it mainly concerns the most general
problems to the implementations. This document tries to clarify some
issues that need to be updated to adapt to IPv6 environment.
Methods described in [MVPN] and [ROSEN] will not be re-stated here.
The solution details already been discussed in earlier documents,
such as RPF determination and spanning multi-as backbones, will be
accepted here. New techniques are being discussed such as reducing
PIM Join/Prune massages in backbone, using P2MP LSP as MDT tunnel are
out of the scope of this document. They will be included in later
version of this draft when needed.
2. Protocols and PMSI
2.1. Multicast Protocol supported in IPv6 VPN
Currently in IPv6 environment, PIM-SM and PIM-SSM have been widely
adopted while DVMRP and PIM-DM lost their position. Other protocols
such as Bidir-PIM and multicast MPLS have few implementations in IPv6.
No matter which multicast protocol will be widely accepted in IPv6
environment, implementation of IPv6 MVPN should not limit the
customers' choices.
2.2. PMSI to Transmit IPv6 Multicast Traffic
PMSI, also known as MDT, is used to transmit customer's multicast
traffic in IPv4 MVPNs. In theory, many techniques can be taken to
create PMSI, such as unicast tunnels (e.g. GRE tunnel) and P2MP LSP
tunnels. But in real world PMSI created by PIM-SM/PIM-SSM dominate
the available implementation. If IPv4 network is taken as 6VPN's core,
all current method to create PMSI can be used in 6VPN. As to IPv6,
since currently PIM-SM and PIM/SSM are the best candidates in IPv6
environment, this document suggests implementation chose PIM-SM or
PIM-SSM to create PMSI ( MDT ) to transmit IPv6 VPNs' multicast
traffic if IPv6 core is used. Of cause other method can be adopted
with the evolvement of related techniques.
The scenarios to create PMSI are same to that in IPv4 MVPN. If IPv6
core is used, multicast traffic packets are encapsulated in IPv6
packet ( multicast packet). If Ipv4 core is used, PE has to
Cao, et al. Expires August 24, 2006 [Page 4]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
encapsulate IPv6 multicast traffic in IPv4 packet at ingress and de-
capsulate those IPv6 packets at PMSI egress.
When PMSI is created by IPv4 protocol, in the view of IPv6 multicast
VPN VRF, the PMSI is an IPv6 multicast interface. But in the view of
public VRF of PE, the PMSI is a common IPv4 tunnel interface.
Both I-PMSI and S-PMSI should be supported in IPv6 Multicast PPVPN.
Packet encapsulation is discussed at section 4
2.3. Auto discovery of MVPN Members
The principle of finding MVPN Members by BGP has been described in
[MVPN]. No matter which protocol is used to establish PMSI, neighbor
relationship through PMSI can be established by sending PIM HELLO
message. However, packet loss may affect the reliability and
periodically sending PIM HELLO messages to PMSI lowers the efficiency
of the protocol. So this draft recommends BGP-based auto discovery in
IPv6 MVPN, other methods are optional. The details of auto discovery
will be discussed in later version of this draft.
3. Extension for BGP and PIM messages
Several protocol messages' format have been defined in earlier
related drafts to support MVPN. Extension of these protocol messages
is described bellow.
3.1. MDT SAFI
MDT SAFI is defined in [SAFI]. MDT SAFI contains the address of
the nexthop which will be used by the multicast source PE to send PIM
Join message for the I-PMSI ( default MDT ) address to. It is
extended to support IPv6 AFI in this draft.
The IPv6 NLRI has similar format with IPv4 NLRI, which is 8-byte-
RD: PE-Address followed by the MDT group address.
+-------------------------------+
| |
| RD:PE-Address (variable) |
| |
+-------------------------------+
| MDT Group-address (16 octets)|
+-------------------------------+
Cao, et al. Expires August 24, 2006 [Page 5]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
Route-Distinguisher: is the RD of the VRF to which this MDT
attribute belongs.
PE-Address : is the nexthop address. It may be an IPv6 address or
an IPv4 address corresponding to SP backbone network. Whether it is
IPv6 or IPv4 can be deduced by the length of NLRI, e.g. a length of
28 octets means IPv4 while a length of 40 octets means IPv6.
MDT Group Address : is the Group-address of the MDT-Group that a
VRF is associated to. It's length is 16 octets.
The usage is the same as of IPv4 MDT SAFI described in [SAFI].
3.2. BGP Connector Attribute
The format and usage in MVPN of BGP Connector attribute is defined
in [CONNECTOR] and [SAFI]. It is used to transport the address of the
originating PE router to the remote PE router in the same MVPN.
The attribute used in IPv6 MVPN contains one or more tuples of the
form :
+------------------------------+
| |
| Type (2 octets) |
+------------------------------+
| |
| Value (Variable) |
| |
+------------------------------+
Type : 0x0001 for IPv4 address and 0x8001 for IPv6 address.
Value : is an IPv4 address or IPv6 address defined by the Type.
If the SP backbone is an IPv4 networks, the Type field is 0x0001
with the Value field contain an IPv4 address. Or if the SP
backbone is IPv6, the Type field should be 0x8001 with an IPv6
address in the Value field. Other usage and guidelines of this
attribute is the same as defined in [BGP-CONN] and[MDT SAFI].
3.3. PIM RPF Vector
PIM RPF Vector TLV is defined in [RPF-VECTOR]. It is used in an
environment when the network's IGP does not have a route to the
source of the multicast tree. It consists of a single Vector which
Cao, et al. Expires August 24, 2006 [Page 6]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
identifies the exit point of the network. The usage of PIM RPF Vector
in IPv4 MVPN is pointed out in section 5.6 of [ROSEN]. Here we extend
the TLV for usage in IPv6 MVPN.
The format of PIM RFP Vector in IPv6 MVPN is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|S| Type | Length | IP address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......
F bit: Forward Unknown TLV. If this bit is set the TLV is forwarded
regardless if the router understands the Type.
S bit: Bottom of Stack. If this bit is set then this is the last TLV
in the stack.
Type: The Vector Attribute type is 0 for IPv4 and 1 for IPv6.
Length: Length in bytes is 4 for IPv4 and 16 for IPv6.
Value: An IPv4 address or an IPv6 address.
3.4. Extensions for MTD TLV
"MDT TLV" has the following format. It uses port 3232.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits):
the type of the MDT TLV. Currently, 1 is used in IPv4 MVPN MDT Join
TLV . For IPv6 MVPN, the filed is to be defined ( 2? );
Length (16 bits):
the total number of octets in the TLV for this type, including
both the Type and Length field.
Cao, et al. Expires August 24, 2006 [Page 7]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
Value (variable length): the content of the TLV.
3.5. Extensions for MDT Join TLV
"MDT Join TLV" has the following format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 C-source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 C-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4/IPv6 P-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits):
as defined above. For MDT Join TLV in IPv6 VPN, the value of the
field is 2.
Length (16 bits):
as defined above.
Reserved (8 bits):
for future use.
IPv6 C-Source (128 bits):
the IPv6 address of the traffic source in the IPv6 VPN.
IPv6 C-Group (128 bits):
the IPv6 address of the multicast traffic destination address
in the IPv6 VPN. IPv4/IPv6 P-Group (32/128 bits): the IPv4/IPv6
group address that the PE router is going to use to encapsulate the
traffic flow (C-Source, C-Group).
4. Encapsulation
IPv6 multicast traffic is encapsulated in PMSI which can be created
by different method. With different core networks used and different
Cao, et al. Expires August 24, 2006 [Page 8]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
protocols chosen, different encapsulation formats need to be defined.
As in IPv4 MVPN, GRE encapsulation is recommended method to send
multicast through PMSI.
4.1. Encapsulating IPv6 Traffic In IPv4 Multicast Packet
If the core network is based on IPv4, the encapsulation format should
be:
----------------------------------------------------------------
| P-IPv4 Header | GRE | C-IPv6 Header | C-Payload |
----------------------------------------------------------------
In IPv4 MVPN, the Protocol Number field in the P-IPv4 header must be
set to 47 and Protocol Type field of the GRE Header is set to be
0x800 .When IPv6 packet is encapsulated in IPv4 MGRE, the same number
may be used.
It seems that filling the GRE Header with different number may bring
some benefit. Current devices generally have control plane and packet
forwarding plane. It is easy for control plane to distinguish whether
it is IPv6 packet or IPv4 packet that is encapsulated in GRE because
the IPv4 group address (or LSP label or other tunnel identifier) used
for P-IPv4 Header is determined before the PMSI is created. But for
packet forwarding plane, distinguishing which kind of packets are
encapsulated may require looking up table or looking deeper in GRE
packet content and consume more hardware resource. This should be
discussed in latter version of this draft.
4.2. Encapsulating IPv6 Traffic In IPv6 Multicast Packet
If the core network is based on IPv6, the encapsulation format should
be:
----------------------------------------------------------------
| P-IPv6 Header | GRE | C-IPv6 Header | C-Payload |
----------------------------------------------------------------
The Protocol Number filed in the P-IPv6 head must be set to 47 and
Protocol Type field of the GRE Header must be set to be 0x800.
5. Security Considerations
This document has no known security implications.
Cao, et al. Expires August 24, 2006 [Page 9]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
6. IANA Considerations
This document creates no new requirements on IANA namespaces.
7. Acknowledgments
We'd like to thank Hongfei Chen for his feedback on this draft.
Cao, et al. Expires August 24, 2006 [Page 10]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
References
7.1. Normative References
[2547bis] "BGP/MPLS VPNs", Rosen, Rekhter, et. al., September 2003,
draft-ietf-l3vpn-rfc2547bis-01.txt
[MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, May 2005,
draft-ietf-l3vpn-2547bis-mcast-03.txt
7.2. Informative References
[ROSEN-8] E. Rosen, Y. Cai, I. Wijnands, "Multicast in MPLS/BGP IP
VPNs", draft-rosen-vpn-mcast-08.txt
[MVPN-PIM] R. Aggarwal, A. Lohiya, T. Pusateri, Y. Rekhter, "Base
Specification for Multicast in MPLS/BGP VPNs", draft-
raggarwa-l3vpn-2547-mvpn-00.txt
[RAGGARWA-MCAST] R. Aggarwal, et. al., "Multicast in BGP/MPLS VPNs
and VPLS", draft-raggarwa-l3vpn-mvpn-vpls-mcast--01.txt".
[RP-MVPN] S. Yasukawa, et. al., "BGP/MPLS IP Multicast VPNs", draft-
yasukawa-l3vpn-p2mp-mcast-00.txt
[MDT SAFI] G. Nalawade, et. al., "MDT SAFI", draft-nalawade-idr-mdt-
safi-03.txt
[RPF-VECTOR ]draft-ietf-pim-rpf-vector-01
[MVPN-EXP] Yiqun Cai, Mike McBride, Chris Hall. ''Experience With
Multicast VPN'', draft-ycai-mvpn-experience-00
[BGP-CONN] Gargi Nalawade, Ruchi Kapoor, David Ward. ''BGP Connector
Attribute'', draft-nalawade-l3vpn-bgp-connector-00.txt
Author's Addresses
Wei Cao
Huawei Technologies Co., Ltd.
Email: caowayne@huawei.com
Hui Liu
Huawei Technologies Co., Ltd.
Email: liuhui47967@huawei.comm
Cao, et al. Expires August 24, 2006 [Page 11]
Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006
Qiang He
Email: heqiangc@hotmail.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Cao, et al. Expires August 24, 2006 [Page 12]
