draft-ietf-mboned-multrans-addr-acquisition-03.txt   draft-ietf-mboned-multrans-addr-acquisition-04.txt 
Internet Engineering Task Force T. Tsou Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational A. Clauberg Intended status: Informational A. Clauberg
Expires: September 5, 2014 Deutsche Telekom Expires: March 6, 2015 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
March 4, 2014 September 2, 2014
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-03 draft-ietf-mboned-multrans-addr-acquisition-04
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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 5, 2014. This Internet-Draft will expire on March 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 8, line 40 skipping to change at page 8, line 40
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, http:// Finally, the Open Mobile Alliance (OMA,
www.openmobilealliance.org/) has defined a series of specifications http://www.openmobilealliance.org/) has defined a series of
relating to broadcast services over wireless networks. The source specifications relating to broadcast services over wireless networks.
and multicast group addresses used to acquire a given program The source and multicast group addresses used to acquire a given
instance are provided in SDP fragments either directly embedded in program instance are provided in SDP fragments either directly
the primary electronic program guide or pointed to by it. The OMA embedded in the primary electronic program guide or pointed to by it.
architecture provides functionality to adapt access information The OMA architecture provides functionality to adapt access
within the program guide to the requirements of the transport network information within the program guide to the requirements of the
to which the user is attached, but this functionality appears to be transport network to which the user is attached, but this
primarily directed toward overcoming differences in technology rather functionality appears to be primarily directed toward overcoming
than a general capability for modification. differences in technology rather than a general capability for
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.
 End of changes. 5 change blocks. 
15 lines changed or deleted 16 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/