draft-ietf-softwire-mesh-multicast-09.txt   draft-ietf-softwire-mesh-multicast-10.txt 
Network Working Group M. Xu Network Working Group M. Xu
Internet-Draft Y. Cui Internet-Draft Y. Cui
Expires: July 26, 2015 J. Wu Expires: February 5, 2016 J. Wu
S. Yang S. Yang
Tsinghua University Tsinghua University
C. Metz C. Metz
G. Shepherd G. Shepherd
Cisco Systems Cisco Systems
January 22, 2015 August 4, 2015
Softwire Mesh Multicast Softwire Mesh Multicast
draft-ietf-softwire-mesh-multicast-09 draft-ietf-softwire-mesh-multicast-10
Abstract Abstract
The Internet needs to support IPv4 and IPv6 packets. Both address The Internet needs to support IPv4 and IPv6 packets. Both address
families and their related protocol suites support multicast of the families and their related protocol suites support multicast of the
single-source and any-source varieties. As part of the transition to single-source and any-source varieties. During IPv6 transition,
IPv6, there will be scenarios where a backbone network running one IP there will be scenarios where a backbone network running one IP
address family internally (referred to as internal IP or I-IP) will address family internally (referred to as internal IP or I-IP) will
provide transit services to attached client networks running another provide transit services to attached client networks running another
IP address family (referred to as external IP or E-IP). It is IP address family (referred to as external IP or E-IP). It is
expected that the I-IP backbone will offer unicast and multicast expected that the I-IP backbone will offer unicast and multicast
transit services to the client E-IP networks. transit services to the client E-IP networks.
Softwire Mesh is a solution to E-IP unicast and multicast support Softwire Mesh is a solution to E-IP unicast and multicast support
across an I-IP backbone. This document describes the mechanisms for across an I-IP backbone. This document describes the mechanisms for
supporting Internet-style multicast across a set of E-IP and I-IP supporting Internet-style multicast across a set of E-IP and I-IP
networks supporting softwire mesh. networks supporting softwire mesh.
skipping to change at page 1, line 47 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 July 26, 2015. This Internet-Draft will expire on February 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 3, line 19 skipping to change at page 3, line 19
7. Data Plane Functions of AFBR . . . . . . . . . . . . . . . . 17 7. Data Plane Functions of AFBR . . . . . . . . . . . . . . . . 17
7.1. Process and Forward Multicast Data . . . . . . . . . . . 17 7.1. Process and Forward Multicast Data . . . . . . . . . . . 17
7.2. Selecting a Tunneling Technology . . . . . . . . . . . . 18 7.2. Selecting a Tunneling Technology . . . . . . . . . . . . 18
7.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 18 7.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Internet needs to support IPv4 and IPv6 packets. Both address The Internet needs to support IPv4 and IPv6 packets. Both address
families and their related protocol suites support multicast of the families and their related protocol suites support multicast of the
single-source and any-source varieties. As part of the transition to single-source and any-source varieties. During IPv6 transition,
IPv6, there will be scenarios where a backbone network running one IP there will be scenarios where a backbone network running one IP
address family internally (referred to as internal IP or I-IP) will address family internally (referred to as internal IP or I-IP) will
provide transit services to attached client networks running another provide transit services to attached client networks running another
IP address family (referred to as external IP or E-IP). IP address family (referred to as external IP or E-IP).
The preferred solution is to leverage the multicast functions The preferred solution is to leverage the multicast functions
inherent in the I-IP backbone, to efficiently and scalably forward inherent in the I-IP backbone, to efficiently forward client E-IP
client E-IP multicast packets inside an I-IP core tree, which roots multicast packets inside an I-IP core tree, which roots at one or
at one or more ingress AFBR nodes and branches out to one or more more ingress AFBR nodes and branches out to one or more egress AFBR
egress AFBR leaf nodes. leaf nodes.
[RFC4925] outlines the requirements for the softwires mesh scenario [RFC4925] outlines the requirements for the softwires mesh scenario
including the multicast. It is straightforward to envisage that including the multicast. It is straightforward to envisage that
client E-IP multicast sources and receivers will reside in different client E-IP multicast sources and receivers will reside in different
client E-IP networks connected to an I-IP backbone network. This client E-IP networks connected to an I-IP backbone network. This
requires that the client E-IP source-rooted or shared tree should requires that the client E-IP source-rooted or shared tree should
traverse the I-IP backbone network. traverse the I-IP backbone network.
One method to accomplish this is to re-use the multicast VPN approach One method to accomplish this is to re-use the multicast VPN approach
outlined in [RFC6513]. MVPN-like schemes can support the softwire outlined in [RFC6513]. MVPN-like schemes can support the softwire
skipping to change at page 9, line 35 skipping to change at page 9, line 35
In this case it is incumbent upon the AFBR routers to perform PIM In this case it is incumbent upon the AFBR routers to perform PIM
message conversions in the control plane and IP group address message conversions in the control plane and IP group address
conversions or mappings in the data plane. It becomes possible to conversions or mappings in the data plane. It becomes possible to
devise an algorithmic one-to-one IPv4-to-IPv6 address mapping at devise an algorithmic one-to-one IPv4-to-IPv6 address mapping at
AFBRs. AFBRs.
4.2. Group Address Mapping 4.2. Group Address Mapping
For IPv4-over-IPv6 scenario, a simple algorithmic mapping between For IPv4-over-IPv6 scenario, a simple algorithmic mapping between
IPv4 multicast group addresses and IPv6 group addresses is supported. IPv4 multicast group addresses and IPv6 group addresses is supported.
[I-D.ietf-mboned-64-multicast-address-format] has already defined an [RFC7371] has already defined an applicable format. Figure 4 is the
applicable format. Figure 4 is the reminder of the format: reminder of the format:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96-----------127| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MPREFIX64 |group address | | MPREFIX64 |group address |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 4: IPv4-Embedded IPv6 Multicast Address Format Figure 4: IPv4-Embedded IPv6 Multicast Address Format
The MPREFIX64 for SSM mode is also defined in The MPREFIX64 for SSM mode is also defined in [RFC7371] :
[I-D.ietf-mboned-64-multicast-address-format] :
o ff3x:0:8000::/96 ('x' is any valid scope) o ff3x:0:8000::/96 ('x' is any valid scope)
With this scheme, each IPv4 multicast address can be mapped into an With this scheme, each IPv4 multicast address can be mapped into an
IPv6 multicast address (with the assigned prefix), and each IPv6 IPv6 multicast address (with the assigned prefix), and each IPv6
multicast address with the assigned prefix can be mapped into IPv4 multicast address with the assigned prefix can be mapped into IPv4
multicast address. multicast address.
4.3. Source Address Mapping 4.3. Source Address Mapping
There are two kinds of multicast --- ASM and SSM. Considering that There are two kinds of multicast --- ASM and SSM. Considering that
skipping to change at page 12, line 33 skipping to change at page 12, line 33
possible, one possible solution to this problem is to limit the scope possible, one possible solution to this problem is to limit the scope
of the E-IPv6 source addresses for mapping, such as applying a "Well- of the E-IPv6 source addresses for mapping, such as applying a "Well-
Known" prefix or an ISP-defined prefix. Known" prefix or an ISP-defined prefix.
5.2. Group Address Mapping 5.2. Group Address Mapping
To keep one-to-one group address mapping simple, the group address To keep one-to-one group address mapping simple, the group address
range of E-IP IPv6 can be reduced in a number of ways to limit the range of E-IP IPv6 can be reduced in a number of ways to limit the
scope of addresses that need to be mapped into the I-IP IPv4 space. scope of addresses that need to be mapped into the I-IP IPv4 space.
A recommended multicast address format is defined in A recommended multicast address format is defined in [RFC7371]. The
[I-D.ietf-mboned-64-multicast-address-format]. The high order bits high order bits of the E-IPv6 address range will be fixed for mapping
of the E-IPv6 address range will be fixed for mapping purposes. With purposes. With this scheme, each IPv4 multicast address can be
this scheme, each IPv4 multicast address can be mapped into an IPv6 mapped into an IPv6 multicast address(with the assigned prefix), and
multicast address(with the assigned prefix), and each IPv6 multicast each IPv6 multicast address with the assigned prefix can be mapped
address with the assigned prefix can be mapped into IPv4 multicast into IPv4 multicast address.
address.
5.3. Source Address Mapping 5.3. Source Address Mapping
There are two kinds of multicast --- ASM and SSM. Considering that There are two kinds of multicast --- ASM and SSM. Considering that
I-IP network and E-IP network may support different kind of I-IP network and E-IP network may support different kind of
multicast, the source address translation rules could be very complex multicast, the source address translation rules could be very complex
to support all possible scenarios. But since SSM can be implemented to support all possible scenarios. But since SSM can be implemented
with a strict subset of the PIM-SM protocol mechanisms [RFC4601], we with a strict subset of the PIM-SM protocol mechanisms [RFC4601], we
can treat I-IP core as SSM-only to make it as simple as possible, can treat I-IP core as SSM-only to make it as simple as possible,
then there remains only two scenarios to be discussed in detail: then there remains only two scenarios to be discussed in detail:
skipping to change at page 19, line 12 skipping to change at page 19, line 12
AFBRs can complete the mapping procedure correctly. The IPv6 prefix AFBRs can complete the mapping procedure correctly. The IPv6 prefix
for translation can be unified within only the transit core, or for translation can be unified within only the transit core, or
within global area. In the later condition, the prefix should be within global area. In the later condition, the prefix should be
assigned by IANA. assigned by IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A.
Problem Statement", RFC 4925, July 2007. Durand, Ed., "Softwire Problem Statement", RFC 4925,
DOI 10.17487/RFC4925, July 2007,
<http://www.rfc-editor.org/info/rfc4925>.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009. Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009,
<http://www.rfc-editor.org/info/rfc5565>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
VPNs", RFC 6513, February 2012. BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-mboned-64-multicast-address-format] [RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and Multicast Addressing Architecture", RFC 7371,
M. Xu, "IPv6 Multicast Address With Embedded IPv4 DOI 10.17487/RFC7371, September 2014,
Multicast Address", draft-ietf-mboned-64-multicast- <http://www.rfc-editor.org/info/rfc7371>.
address-format-05 (work in progress), April 2013.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Wenlong Chen, Xuan Chen, Alain Durand, Yiu Lee, Jacni Qin and Stig Wenlong Chen, Xuan Chen, Alain Durand, Yiu Lee, Jacni Qin and Stig
Venaas provided useful input into this document. Venaas provided useful input into this document.
Authors' Addresses Authors' Addresses
Mingwei Xu Mingwei Xu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: xmw@cernet.edu.cn Email: xmw@cernet.edu.cn
Yong Cui Yong Cui
 End of changes. 21 change blocks. 
39 lines changed or deleted 47 lines changed or added

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