draft-ietf-softwire-dslite-multicast-09.txt   draft-ietf-softwire-dslite-multicast-10.txt 
Softwire WG J. Qin Softwire WG J. Qin
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Boucadair Intended status: Standards Track M. Boucadair
Expires: September 10, 2015 C. Jacquenet Expires: March 3, 2016 C. Jacquenet
France Telecom France Telecom
Y. Lee Y. Lee
Comcast Comcast
Q. Wang Q. Wang
China Telecom China Telecom
March 09, 2015 August 31, 2015
Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6
Multicast Network Multicast Network
draft-ietf-softwire-dslite-multicast-09 draft-ietf-softwire-dslite-multicast-10
Abstract Abstract
This document specifies a solution for the delivery of IPv4 multicast This document specifies a solution for the delivery of IPv4 multicast
services to IPv4 clients over an IPv6 multicast network. The services to IPv4 clients over an IPv6 multicast network. The
solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme
and uses the IPv6 multicast distribution tree to deliver IPv4 and uses the IPv6 multicast distribution tree to deliver IPv4
multicast traffic. The solution is particularly useful for the multicast traffic. The solution is particularly useful for the
delivery of multicast service offerings to DS-Lite serviced delivery of multicast service offerings to DS-Lite serviced
customers. customers.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 September 10, 2015. This Internet-Draft will expire on March 3, 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
B.6. Static vs. Dynamic PIM Triggering . . . . . . . . . . . . 18 B.6. Static vs. Dynamic PIM Triggering . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
DS-Lite [RFC6333] is a technique that rationalizes the usage of the DS-Lite [RFC6333] is a technique that rationalizes the usage of the
remaining global IPv4 addresses during the transition period by remaining global IPv4 addresses during the transition period by
sharing a single IPv4 address with multiple users. A typical DS-Lite sharing a single IPv4 address with multiple users. A typical DS-Lite
scenario is the delivery of an IPv4 service to an IPv4 user over an scenario is the delivery of an IPv4 service to an IPv4 user over an
IPv6 network (denoted as a 4-6-4 scenario). [RFC6333] covers unicast IPv6 network (denoted as a 4-6-4 scenario). [RFC6333] covers unicast
services exclusively. A more generic problem statement is sketched services exclusively.
in [I-D.ietf-mboned-v4v6-mcast-ps].
This document specifies a generic solution for delivery of IPv4 This document specifies a generic solution for delivery of IPv4
multicast services to IPv4 clients over an IPv6 multicast network. multicast services to IPv4 clients over an IPv6 multicast network.
The solution was developed with DS-Lite in mind (see more discussion The solution was developed with DS-Lite in mind (see more discussion
below). The solution is however not limited to DS-Lite. below). The solution is however not limited to DS-Lite.
If customers have to access IPv4 multicast-based services through DS- If customers have to access IPv4 multicast-based services through DS-
Lite environment, Address Family Transition Router (AFTR) devices Lite environment, Address Family Transition Router (AFTR) devices
will have to process all the IGMP Report messages [RFC2236] [RFC3376] will have to process all the IGMP Report messages [RFC2236] [RFC3376]
that have been forwarded by the CPE into the IPv4-in-IPv6 tunnels. that have been forwarded by the CPE into the IPv4-in-IPv6 tunnels.
skipping to change at page 14, line 46 skipping to change at page 14, line 46
10. IANA Considerations 10. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<http://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>.
[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>.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605,
August 2006, <http://www.rfc-editor.org/info/rfc4605>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<http://www.rfc-editor.org/info/rfc4607>.
[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>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011. Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-mboned-multiaaa-framework]
Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H.
He, "AAA and Admission Control Framework for
Multicasting", draft-ietf-mboned-multiaaa-framework-12
(work in progress), August 2010.
[I-D.ietf-mboned-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T.,
and Q. Qiong, "IPv4-IPv6 Multicast: Problem Statement and
Use Cases", draft-ietf-mboned-v4v6-mcast-ps-04 (work in
progress), September 2013.
[I-D.ietf-softwire-multicast-prefix-option] [I-D.ietf-softwire-multicast-prefix-option]
Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6 Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", draft-ietf-softwire-multicast-prefix-option-07 Prefixes", draft-ietf-softwire-multicast-prefix-option-08
(work in progress), September 2014. (work in progress), March 2015.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997. 2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<http://www.rfc-editor.org/info/rfc2236>.
[RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and
M. Eubanks, "Multicast Addresses for Documentation", RFC M. Eubanks, "Multicast Addresses for Documentation",
6676, August 2012. RFC 6676, DOI 10.17487/RFC6676, August 2012,
<http://www.rfc-editor.org/info/rfc6676>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC "Special-Purpose IP Address Registries", BCP 153,
6890, April 2013. RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.
Appendix A. Use Case: IPTV Appendix A. Use Case: IPTV
IPTV generally includes two categories of service offerings: IPTV generally includes two categories of service offerings:
o Video on Demand (VoD) that unicast video content to receivers. o Video on Demand (VoD) that unicast video content to receivers.
o Multicast live TV broadcast services. o Multicast live TV broadcast services.
Two players intervene in the delivery of this service: Two players intervene in the delivery of this service:
o Content Providers, who usually own the contents that is multicast o Content Providers, who usually own the contents that is multicast
to receivers. Content providers may contractually define an to receivers. Content providers may contractually define an
agreement with network providers to deliver contents to receivers. agreement with network providers to deliver contents to receivers.
o Network Providers, who provide network connectivity services o Network Providers, who provide network connectivity services
(e.g., network providers are responsible for carrying multicast (e.g., network providers are responsible for carrying multicast
flows from head-ends to receivers). Refer to flows from head-ends to receivers).
[I-D.ietf-mboned-multiaaa-framework].
Note that some contract agreements prevent a network provider from Note that some contract agreements prevent a network provider from
altering the content as sent by the content provider for various altering the content as sent by the content provider for various
reasons. Under the contract, multicast streams should be delivered reasons. Under the contract, multicast streams should be delivered
unaltered to the requesting users. unaltered to the requesting users.
Many current IPTV contents are likely to remain IPv4-formatted and Many current IPTV contents are likely to remain IPv4-formatted and
out of control of the network providers. Additionally, there are out of control of the network providers. Additionally, there are
numerous legacy receivers (e.g., IPv4-only Set Top Boxes (STB)) that numerous legacy receivers (e.g., IPv4-only Set Top Boxes (STB)) that
can't be upgraded or be easily replaced to support IPv6. As a can't be upgraded or be easily replaced to support IPv6. As a
 End of changes. 19 change blocks. 
37 lines changed or deleted 37 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/