Internet Engineering Task Force Qian. Wang
Internet-Draft Qiong. Sun
Intended status: Standards Track China Telecom
Expires: April 11, 2011 Jacni. Qin
Peng. Sun
ZTE
October 8, 2010
Extensions to DS-Lite for Multicast Deployment
draft-qin-softwire-dslite-multicast-00
Abstract
DS-Lite enables broadband service providers to provide IPv4 unicast
service following IPv4 exhaustion by combining two mechanisms: NAT
(for IPv4 address sharing) and IPv4-in-IPv6 tunnel(a bridging link,
for carrying IPv4 traffic). Meanwhile, native IPv6 services, both
unicast and multicast can be provided. This document describes
extensions to DS-Lite to support IPv4 multicast.
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 11, 2011.
Copyright 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
Wang, et al. Expires April 11, 2011 [Page 1]
Internet-Draft DS-Lite Multicast October 2010
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Wang, et al. Expires April 11, 2011 [Page 2]
Internet-Draft DS-Lite Multicast October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Tunnel encapsulation for Multicast . . . . . . . . . . . . 5
2.2. IPv4-embedded IPv6 address prefixes . . . . . . . . . . . . 5
2.3. Multicast Distribution Tree . . . . . . . . . . . . . . . . 6
2.4. Multicast Forwarding . . . . . . . . . . . . . . . . . . . 6
2.5. BNG with AFTR integrated . . . . . . . . . . . . . . . . . 7
3. Operation Details . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. B4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. AFTR . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Multicast Traffic Optimization . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Wang, et al. Expires April 11, 2011 [Page 3]
Internet-Draft DS-Lite Multicast October 2010
1. Introduction
If DS-Lite is used for IPv4 multicast, there will be some problems.
AFTR MUST work as the multicast replication point where all the IGMP
reports are terminated. Especially when centralized AFTR is
implemented, it will be a great challenge for AFTR to process the
protocol messages and data forwarding. Meanwhile, the downstream
bandwidth will be vastly consumed.
In practice, similar issue exists in native IPv4 networks for
multicast. To deal with it, mechanisms like IGMP snooping, multicast
VLAN, are introduced into distributed Access Network Nodes (e.g.
Aggregation Switches, xPON devices) which then occupy the role of
terminating IGMP requests and replicating multicast traffic. In this
way, the multicast replication point can be moved downward and closer
to the subscribers, so the bandwidth consumption and the great
pressure of the layer 3 gateway is reduced substantially.
While in DS-Lite, IGMP snooping does NOT work on Access Network Nodes
due to the current tunnel encapsulation.
In this document, we try to extend DS-Lite and make it more feasible
for IPv4 multicast. While the key characteristic of this proposal is
exactly the same as DS-Lite: communications stay within their address
family.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. Overview
The overall process is described in this section based on the example
below where AFTR is a standalone box apart from the IPv6 BNG(there
may be multiple hops in between), and PIM Sparse Mode is used for
multicast routing.
Wang, et al. Expires April 11, 2011 [Page 4]
Internet-Draft DS-Lite Multicast October 2010
+----------+ +-----------+
-------| AFTR | | v6 Router |-------
+----------+ +-----------+
| \ / |
| \ / |
| \ / |
| +-----------+ |
| | v6 BNG | |
| +-----------+ |
IPv4-embedded | | | Native
IPv6 Multicast | | | IPv6 Multicast
| | |
| +----------+ |
| | B4 | |
| +----------+ |
| / \ |
V / \ V
+------+ +------+
| v4 | | v6 |
| Host | | Host |
+------+ +------+
Figure 1
2.1. Tunnel encapsulation for Multicast
In the original DS-Lite, IPv4-in-IPv6 tunnel encapsulation is used to
carry the bidirectional IPv4 unicast traffic between B4 and AFTR.
Here we would like to use IPv6 Multicast address(IPv4-embedded) as
the destination of tunnel encapsulation to carry the unidirectional
IPv4 multicast from AFTR to B4. The IPv4 address of multicast source
will be mapped to IPv6 address using special IPv6 prefix.
2.2. IPv4-embedded IPv6 address prefixes
One special IPv6 multicast prefix(here we name it, Dedicated mPrefix)
is needed for constructing IPv6 multicast addresses, with IPv4
multicast address embedded. Meanwhile, the addresses of IPv4
multicast source(also RP of shared tree) should be mapped to IPv6
addresses, so an IPv6 unicast prefix(here we name it Dedicated
uPrefix) is needed for constructing IPv6 unicast addresses with IPv4
unicast address embedded(the multicast source or RP's address).
The length of the IPv6 prefixes should be less than 96, with no other
restrictions(except for the source-specific multicast, since IANA has
assigned special ranges of group addresses for that). The exact
policy of address format is controlled by service provider.
Wang, et al. Expires April 11, 2011 [Page 5]
Internet-Draft DS-Lite Multicast October 2010
These two prefixes can be configured onto B4 through DHCPv6 options
or some out-of-band mechanism.
2.3. Multicast Distribution Tree
Suppose that an IPv4 host has acquired the address of IPv4 multicast
group which it is interested in, then the host will send an IGMP
Report to B4 joining that group. After receiving IGMP message from
the host, B4 performs the "IGMP Proxying" function similarly as
described in [RFC4605], but translates the IGMP message to MLD
message when sending upwards this membership report. In the MLD
message, the IPv6 address of multicast group to be joined is
constructed using Dedicated mPrefix, and with IPv4 multicast address
embedded. If the source-specific multicast is deployed, the IPv6
address of the multicast source can be constructed in the same way
(using Dedicated uPrefix, with IPv4 multicast source embedded).
Receiving this MLD membership report on the BNG may trigger the PIM
join up to RP or the multicast source. Make sure the calculated RPF
interface for sending PIM join be on the path up to AFTR. This can
be easily achieved by making AFTR advertise the route of Dedicated
uPrefix throughout the service provider's IPv6 Network. To send PIM
join triggered by native IPv6 MLD membership report, the RPF
interface calculation can be done based on native IPv6 unicast
routing information.
After receiving the PIM join, AFTR will add the IPv6 interface
receiving the join message to the Out Interface List of corresponding
entry in the IPv4 multicast routing table(indicated by the IPv4
multicast address embedded). If the entry for this IPv4 multicast
group doesn't exist, a new entry will be created and a PIM join
message will be sent up further towards the source.
Till now, the multicast distribution tree from B4 up to AFTR is
established in service provider's IPv6 network.
2.4. Multicast Forwarding
Whenever a IPv4 multicast packet is received on AFTR, a search of
multicast routing table is performed, and probably an IPv6 interface
will be found in the Out-Interface-List of the matching entry, this
IPv6 interface was added into Out-Interface-List in the process of
multicast distribution tree establishment as described previously.
Then AFTR should encapsulate the IPv4 multicast packet into IPv6
tunnel using the "IPv4-embedded" multicast address as the destination
of the IPv6 tunnel. The new IPv6 multicast packet will then be sent
out of the IPv6 interface and flow down the multcast distribution
Wang, et al. Expires April 11, 2011 [Page 6]
Internet-Draft DS-Lite Multicast October 2010
tree to B4 through service provider's IPv6 network.
When receiving the IPv6 multicast packet sent to this special group,
B4 should decapsulate the IPv6 tunnel and pass the original IPv4
multicast packet to the IPv4 host in LAN.
?? to trigger the tunnel decapsulation operation, should B4 join this
special IPv6 group itself?
2.5. BNG with AFTR integrated
If the AFTR function is integrated into BNGs(have to be dual stack),
the multicast distribution tree will be much simpler, and the
multicast forwarding is the same as described above.
3. Operation Details
3.1. B4
To be added...
3.2. AFTR
To be added...
4. Multicast Traffic Optimization
To be added...
5. Acknowledgements
The authors would like to thank Dan Wing for his guidance during the
discussions which initiated this work. We also appreciate Jie Hu,
Lizhong Jin for their valuable input.
6. IANA Considerations
This document includes no request to IANA.
7. Security Considerations
8. References
Wang, et al. Expires April 11, 2011 [Page 7]
Internet-Draft DS-Lite Multicast October 2010
8.1. Normative References
[I-D.ietf-behave-address-format]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-10 (work in progress),
August 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 2010.
[I-D.venaas-behave-mcast46]
Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
IPv4 - IPv6 multicast translator",
draft-venaas-behave-mcast46-01 (work in progress),
July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[TR-101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL
Aggregation", 2006.
8.2. Informative References
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
Wang, et al. Expires April 11, 2011 [Page 8]
Internet-Draft DS-Lite Multicast October 2010
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific
Protocol Independent Multicast in 232/8", BCP 120,
RFC 4608, August 2006.
Authors' Addresses
Qian Wang
China Telecom
No.118, Xizhimennei
Beijing, 100035
China
Phone: +86 10 5855 2177
Email: wangqian@ctbri.com.cn
Qiong Sun
China Telecom
No.118, Xizhimennei
Beijing, 100035
China
Phone: +86 10 5855 2116
Email: sunqiong@ctbri.com.cn
Jacni Qin
ZTE
Shanghai,
China
Phone: +86 1391 8619 913
Email: jacniq@gmail.com
Wang, et al. Expires April 11, 2011 [Page 9]
Internet-Draft DS-Lite Multicast October 2010
Peng Sun
ZTE
Shanghai,
China
Phone: +86 21 6889 7101
Email: sun.peng@zte.com.cn
Wang, et al. Expires April 11, 2011 [Page 10]