draft-ietf-mboned-multrans-addr-acquisition-01.txt   draft-ietf-mboned-multrans-addr-acquisition-02.txt 
Internet Engineering Task Force T. Tsou Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies (USA) Internet-Draft Huawei Technologies (USA)
Intended status: Informational A. Clauberg Intended status: Informational A. Clauberg
Expires: July 7, 2013 Deutsche Telekom Expires: January 06, 2014 Deutsche Telekom
M. Boucadair M. Boucadair
France Telecom France Telecom
S. Venaas S. Venaas
Cisco Systems Cisco Systems
Q. Sun Q. Sun
China Telecom China Telecom
January 3, 2013 July 05, 2013
Address Acquisition For Multicast Content When Source and Receiver Address Acquisition For Multicast Content When Source and Receiver
Support Differing IP Versions Support Differing IP Versions
draft-ietf-mboned-multrans-addr-acquisition-01 draft-ietf-mboned-multrans-addr-acquisition-02
Abstract Abstract
Each IPTV operator has their own arrangements for pre-provisioning Each IPTV operator has their own arrangements for pre-provisioning
program information including addresses of the multicast groups program information including addresses of the multicast groups
corresponding to broadcast programs on the subscriber receiver. corresponding to broadcast programs on the subscriber receiver.
During the transition from IPv4 to IPv6, scenarios can occur where During the transition from IPv4 to IPv6, scenarios can occur where
the IP version supported by the receiver differs from that supported the IP version supported by the receiver differs from that supported
by the source. This memo examines what has to be done to allow the by the source. This memo examines what has to be done to allow the
receiver to acquire multicast address information in the version it receiver to acquire multicast address information in the version it
supports in such scenarios. supports in such scenarios.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 7, 2013. This Internet-Draft will expire on January 06, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 18 skipping to change at page 2, line 19
(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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Which Problem Are We Solving? . . . . . . . . . . . . . . . . . 3 2. Which Problem Are We Solving? . . . . . . . . . . . . . . . . 3
3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 4 3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . 3
3.1. The Reactive Strategy . . . . . . . . . . . . . . . . . . . 4 3.1. The Reactive Strategy . . . . . . . . . . . . . . . . . . 4
3.2. Dynamic Modification . . . . . . . . . . . . . . . . . . . 5 3.2. Dynamic Modification . . . . . . . . . . . . . . . . . . 4
3.3. Administrative Preparation . . . . . . . . . . . . . . . . 5 3.3. Administrative Preparation . . . . . . . . . . . . . . . 5
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 6
Appendix A. Some Background On Program Guides . . . . . . . . . . 8 Appendix A. Some Background On Program Guides . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Discussion of the multicast transition problem has focussed on the Discussion of the multicast transition problem has focussed on the
case of broadcast delivery of program content. Within this scenario, case of broadcast delivery of program content. Within this scenario,
the operation of viewing a program follows a well-defined sequence. the operation of viewing a program follows a well-defined sequence.
For the sake of reducing channel switching delay, the list of For the sake of reducing channel switching delay, the list of
multicast addresses is generally pre-provisioned to the receiver as multicast addresses is generally pre-provisioned to the receiver as
part of the program guide. Each operator has their own solution for part of the program guide. Each operator has their own solution for
achieving this delivery, despite the attempts at standardization achieving this delivery, despite the attempts at standardization
skipping to change at page 7, line 29 skipping to change at page 7, line 4
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T.,
and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and
Use Cases (Work in Progress)", May 2012. Use Cases (Work in Progress)", May 2012.
[ID.softwire-multicast-prefix-option] [ID.softwire-multicast-prefix-option]
Qin, J., Boucadair, M., Tsou, T., and X. Deng, "DHCPv6 Qin, J., Boucadair, M., Tsou, T., and X. Deng, "DHCPv6
Options for IPv6 DS-Lite Multicast Prefix (Work in Options for IPv6 DS-Lite Multicast Prefix (Work in
Progress)", March 2012. Progress)", March 2012.
[MPEG-7_DDL] [MPEG-7_DDL]
"Information technology - Multimedia content description , "Information technology - Multimedia content description
interface - Part 2: Description definition language", ISI/ interface - Part 2: Description definition language", ISI/
IEC 15938-2 (2002), 2002. IEC 15938-2 (2002), 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4078] Earnshaw, N., Aoki, S., Ashley, A., and W. Kameyama, "The [RFC4078] Earnshaw, N., Aoki, S., Ashley, A., and W. Kameyama, "The
TV-Anytime Content Reference Identifier (CRID)", RFC 4078, TV-Anytime Content Reference Identifier (CRID)", RFC 4078,
May 2005. May 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
[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. October 2010.
Appendix A. Some Background On Program Guides Appendix A. Some Background On Program Guides
Numerous organizations have been involved in the development of Numerous organizations have been involved in the development of
specifications for IPTV. Those specifications and the requirements specifications for IPTV. Those specifications and the requirements
of individual providers have influenced the development of existing of individual providers have influenced the development of existing
skipping to change at page 9, line 9 skipping to change at page 8, line 34
model. The receiver obtains the actual access information for a model. The receiver obtains the actual access information for a
given program, including the multicast group address and possibly a given program, including the multicast group address and possibly a
unicast source address, from XML-encoded program information unicast source address, from XML-encoded program information
following the Open IPTV Forum schema. The receiver uses SIP (Session following the Open IPTV Forum schema. The receiver uses SIP (Session
Initiation Protocol [RFC3261]) signalling to obtain authorization and Initiation Protocol [RFC3261]) signalling to obtain authorization and
resources for a session, before signalling at the multicast level to resources for a session, before signalling at the multicast level to
acquire the program. The SIP signalling conveys the multicast group acquire the program. The SIP signalling conveys the multicast group
address and the unicast source address, if available, in the form of address and the unicast source address, if available, in the form of
an SDP (Session Description Protocol [RFC4566]) session description. an SDP (Session Description Protocol [RFC4566]) session description.
Finally, the Open Mobile Alliance (OMA, Finally, the Open Mobile Alliance (OMA, http://
http://www.openmobilealliance.org/) has defined a series of www.openmobilealliance.org/) has defined a series of specifications
specifications relating to broadcast services over wireless networks. relating to broadcast services over wireless networks. The source
The source and multicast group addresses used to acquire a given and multicast group addresses used to acquire a given program
program instance are provided in SDP fragments either directly instance are provided in SDP fragments either directly embedded in
embedded in the primary electronic program guide or pointed to by it. the primary electronic program guide or pointed to by it. The OMA
The OMA architecture provides functionality to adapt access architecture provides functionality to adapt access information
information within the program guide to the requirements of the within the program guide to the requirements of the transport network
transport network to which the user is attached, but this to which the user is attached, but this functionality appears to be
functionality appears to be primarily directed toward overcoming primarily directed toward overcoming differences in technology rather
differences in technology rather than a general capability for than a general capability for modification.
modification.
In conclusion, it appears that there are at least two extant sources In conclusion, it appears that there are at least two extant sources
of specifications for the receiver interface, each providing its own of specifications for the receiver interface, each providing its own
data model, XML data schema, and detailed architecture. In the OMA data model, XML data schema, and detailed architecture. In the OMA
case, the access information including the source and multicast group case, the access information including the source and multicast group
addresses is embedded as an SDP fragment within a larger set of XML- addresses is embedded as an SDP fragment within a larger set of XML-
encoded program metadata. The OMA metadata can be supplied to the encoded program metadata. The OMA metadata can be supplied to the
receiver in multiple segments, through multiple channels. This receiver in multiple segments, through multiple channels. This
complicates the task of intercepting that metadata and modifying it complicates the task of intercepting that metadata and modifying it
in a particular transport network. in a particular transport network.
skipping to change at page 10, line 28 skipping to change at page 10, line 4
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Stig Venaas Stig Venaas
Cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: stig@cisco.com Email: stig@cisco.com
Qiong Sun Qiong Sun
China Telecom China Telecom
Room 708 Room 708
No.118, Xizhimennei Street No.118, Xizhimennei Street
Beijing, 100035 Beijing 100035
P.R.China P.R.China
Phone: +86-10-58552936 Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn Email: sunqiong@ctbri.com.cn
 End of changes. 12 change blocks. 
36 lines changed or deleted 33 lines changed or added

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