2.3.7 IP over DVB (ipdvb)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-28


Gorry Fairhurst <gorry@erg.abdn.ac.uk>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: ipdvb@erg.abdn.ac.uk
To Subscribe: majordomo@erg.abdn.ac.uk
In Body: subscribe ipdvb at majordomo@erg.abdn.ac.uk
Archive: http://www.erg.abdn.ac.uk/ipdvb/archive/

Description of Working Group:

The WG will develop new protocols and architectures to enable better
deployment of IP over MPEG-2 transport and provide easier interworking
with IP networks. Specific properties of this subnetwork technology
include link-layer support for unicast and multicast, large numbers of
down-stream receivers, and efficiency of transmission.

These properties resemble those in some other wireless networks. The
specific focus of the group is on the use of MPEG-2 transport (examples
include the Digital Video Broadcast (DVB) standards: DVB-RCS; DVB-S and
DVB-T and related ATSC Specifications) in next generation networks and
is not concerned with the development, replacement, or retention of
existing protocols on the existing generation of networks.

The WG will endeavour to reuse existing open standard technologies,
giving guidance on usage in IP networks, whenever they are able to
fulfill requirements. For instance, we acknowledge the existing
Multiprotocol Encapsulation (MPE) [ATSC A/90;ETSI EN 301192] and that
this will continue to be deployed in the future to develop new markets.
Any alternative encapsulation would need to co-exist with MPE.

Appropriate standards will be defined to support transmission of IPv4
and IPv6 datagrams between IP networks connected using MPEG-2 transport
subnetworks. This includes options for encapsulation, dynamic unicast
address resolution for IPv4/IPv6, and the mechanisms needed to map
routed IP multicast traffic to the MPEG-2 transport subnetwork. The
standards will be appropriate to both MPE and any alternative
encapsulation method developed. The developed protocols may also be
applicable to other multicast enabled subnetwork technologies
supporting large numbers of directly connected systems.

The current list of work items is:

Specify the requirements and architecture for supporting IPv4/IPv6 via
MPEG-2 transmission networks. Such requirements should consider the
range of platforms currently (or anticipated to be) in use. This draft
will be an Informational RFC.

Define a standards-track RFC defining an efficient encapsulation
method. The design will consider the need for MAC addresses, the
potential need for synchronisation between streams, support for a wide
range of IPv4/IPv6 and multicast traffic.

Provide an Informational RFC describing a framework for unicast and
multicast address resolution over MPEG-2 transmission networks. The
document will describe options for the address resolution process,
relating these to appropriate usage scenarios and suggesting
appropriate protocol mechanisms for both the existing Multi-Protocol
Encapsulation (MPE) and the efficient encapsulation (2). Consideration
will be paid to existing standards, and the cases for IPv6 and IPv4 will
be described.

Define standards-track RFC(s) to specify procedures for dynamic address
resolution for IPv4/IPv6. This will describe the protocol and syntax of
the information exchanged to bind unicast and multicast flows to the
MPEG-2 TS Logical Channels.  This will include specific optimisations
appropriate for networks reaching large numbers of down-stream systems.

Goals and Milestones:

Done  Draft of a WG Architecture ID describing usage of MPEG-2 transport for IP transmission.
Done  Draft of a WG ID on the new Encapsulation.
Jul 04  Draft of a WG ID on the AR Framework, specifying mechanisms to perform address resolution.
Jul 04  Submit Architecture to IESG
Oct 04  Draft of a WG ID or the AR Protocol, defining a protocol to perform IP address resolution.
Oct 04  Submit Encapsulation to IESG
Apr 05  Submit AR Framework to IESG
Aug 05  Submit AR Protocol to IESG
Aug 05  Progress the Encapsulation RFC along the IETF standards track


  • draft-ietf-ipdvb-ule-02.txt
  • draft-ietf-ipdvb-arch-01.txt

    No Request For Comments

    Current Meeting Report

    Minutes of the IPDVB WG (IETF-61)

    Chair: Gorry Fairhurst (gorry@erg.abdn.ac.uk)

    Notes by Carsten Bormann and J÷rg Ott

    1. Agenda Bashing (Gorry Fairhurst)

    The IPDVB WG met once at the 61st IETF for a two-hour slot. The meeting was attended by approximately 30 participants. The proposed agenda was accepted (with one addition made later during the meeting). Gorry noted that the IETF-hosted ftp archive of the mailing list for the IPDVB WG is now operational, as a backup to the existing WG archive.

    2. Working Group Status and Plans (Gorry Fairhurst)

    Gorry provided an overview of the current status of the documents and the working group as a whole. The two current WG drafts are nearing completion; the generic parts of the XULE draft were integrated into the ULE draft, but specific XULE features were left out (these are a possible item of future work within this group). The working group has successfully completed two milestones and is slightly lagging behind on four others. The main focus of the meeting is on new work items: address resolution and XML receiver configuration.

    3. Requirements/Framework (Marie-Jose Montpetit)

    Marie-JosÚ presented the status of the architecture document. Its main purpose is to establish terminology, define implementation scenarios (richer than just use cases), discuss the relationship to existing work (ATSC, DVB, ISO, etc.), and to establish requirements for the WG. She noted that the scope of the work has expanded from a focus on encapsulation to a rather complete system solution, and from satellite links to a broader coverage including terrestrial networks. After briefly reviewing the scenarios, Marie-JosÚ discussed the changes since the last revision and the comments raised during WGLC. Besides a few nits, only one technical open issue remains: Shall link security be mandatory or optional? Once this issue is resolved, the updated document will be posted and shall be considered for publication as Informational RFC.

    Comments from the group clearly indicated that security should not be mandated: Layer 3 security is available, so that specific link layer mechanisms are not needed in many cases. Also, security is highly application-dependent. Link-layer security would require key management to be defined. Gorry noted that those comments are in favor of the current text.

    The draft will be updated to incorporate all comments received on the list and during the meeting, and passed to the AD for review.

    4. Ultra Lightweight Encapsulation (Gorry Fairhurst)

    Gorry presented an update to the ULE specification ID and reviewed the -- largely minor -- changes to the document. The major technical modification is the inclusion of the ULE extension mechanisms in section 5. Gorry noted an issue in the processing rules: What to do when the CRC fails in a previous packed SNDU? Two options were available: a) discard corrupted SNDU and enter idle state (conservative - required in previous revisions of the ULE draft); b) discard corrupted SNDU and continue unpacking next (liberal). Commenters pointed out that this is a local implementation decision and that both can be allowed. The authors plan to look at the current text, to examine the implications on interoperability from relaxing the wording. There was also a request that the draft should be updated to to say why this issue needs consideration. This issue was taken to the list for further discussion.

    Known ULE implementations are listed at: http://www.erg.abdn.ac.uk/ipdvb/ipdvb-impl.html; information about other implementations is solicited so that the list can be updated.

    The IANA consideration section has been updated. The group needs to decide on the policy for registrations of new ULE extension headers: should an RFC suffice or should standards track be required? Comments were made that a strong specification level (i.e., standards track) should be required (only a few extensions are envisioned anyway, this should not be issue).

    It is planned to have a new revision of the draft available by the end of November. It should then be ready for WGLC.

    5. ULE Extension Headers (Gorry Fairhurst)

    Gorry briefly outlined the evolution of the ULE extension headers draft since the last IETF. Its main features were defining the extension header format that is now included in the base ULE spec. Hence, there is little reason to the draft around. Gorry proposed to simply let it expire -- which was accepted.

    6. Address Resolution (Marie-Jose Montpetit)

    Marie-JosÚ presents the draft on address resolution for IP/DVB. It is based on the requirements for address resolution described in the architecture draft. Table-based mechanisms for IP-to-MPEG-2 address and IP-to-MAC address mapping will be reviewed (including known/solved issues). The changes since the last revision include: splitting the document into two parts to strictly separate the review of existing stuff from a newly proposed protocol; adding another co-author (Hidetaka Izumiyama); adding the Wishnet experiments with IPv6; and various editorial changes.

    Marie-JosÚ solicits input from the working group on more specific implementations: INT usage for IP/PID; IP/MAC resolution; DHCP and NAT; DVB-RCS use cases (e.g. MMT); MHP/OpenCable use cases (AIT, etc.). A new revision of the document will be made available by the end of December 2004. A document in this area should become a WG item in the mid-term.

    IETF protocol dependencies and issues are important: DHCP, NAT, UDLR, ARP, and ND. In the discussion, one question asked why NATs were considered relevant to address resolution; the implications on other mechanisms needed to be considereted, but the address translation itself is a different issue. Marie-JosÚ said that, at this time, the authors were collecting information that may be relevant (and this may have an impact on how mapping tables are ultimately built). The potential relevance of the IETF BEHAVE WG was also mentioned, but the work in BEHAVE may be too specific.

    7. XML for Receiver AR Config (Martin Stiemerling)

    Martin presented an overview of the design space for configuring IPDVB receivers and particularly discussed the pros and cons of XML-based approaches. The problem space to be solved includes IP address and stack configuration, service-related configuration, among others. He identified three issues to discuss: the configuration scenarios, what exactly to configure, and which mechanisms to apply for a configuration. As related areas, Martin mentioned IPCDN, DOCSIS, and DVB (with SI tables) layer 2 and DHC, NETCONF, and basic IP mechanisms (such as neighbor discovery) at layer 3(+). Some discussion arose concerning why XML should be used and why tables are suggested instead of the existing IP mechanisms. Those issues are addressed later.

    Martin described two configuration scenarios: 1) in the IP configuration scenario, underlying (DVB) mechanisms are already up and running and configuration essentially comprises IP-layer parameters. 2) In the complete bootstrap case, the configuration must start from scratch and requires to configure the DVB layer as well.

    Martin also identified a set of issues to be discussed, including: Who is in control of the receiver? - several scenarios exist, some controlled by an operator, some configured by a user. Scale: The difference in scale (105 receivers) compared to a few for NETCONF and 103 for IPCDN. Martin concluded in stating that is too early to define parameters. Rather, usage scenarios need to be defined, then related techniques should be explored to learn from these.

    Commenters recommended that the WG first looked at how to use existing protocols (that may also be used in a uni-directional way), and see how much can be done using existing mechanisms (this may also depend on whether there is also Internet connectivity via other links, or only via a single link). Some changes may be needed to the existing protocols. It was noted that the information required can vary between scenarios.

    Comments were made that it is important to keep things simple. Some further debate arose around the merits of and issues with using XML (at this layer). Marie-JosÚ also pointed to a draft on address resolution and configuration based upon XML (which she presented later).

    A separation was suggested between "Address Resolution (identification of sender/receiver)" and "Address Mapping (to lower layers)".

    8. Receiver AR Config/Protocol (Gorry Fairhurst, Marie-JosÚ Montpetit, Joerg Ott)
    draft-mjm-ipdvb-config-00.txt (see mailing list)
    Later published as: draft-montpetit-ipdvb-config-00.txt

    Marie-JosÚ introduced an XML-based AR configuration protocol. This approach built upon existing table-based mechanisms, but used XML syntax. It defines a simple autoconf protocol for extended AR records and builds on existing protocols where possible. She discussed a number of requirements, including: extensible syntax (e.g., to represent future fields), optimizations for large-scale multicast, and support for source/destination scoping. The presentation suggested an XML syntax. Delivery mechanisms may comprise SOAP, UDP, and SIP. Marie-JosÚ said there w3as running code for the proposed solution and there is interest and participation from the different industries that make up the MPEG-2 community.

    Joerg Ott pointed to work on Internet Media Guides (IMG) that is on-going in MMUSIC (in the IETF Transport Area) that may be suitable for higher layer service announcement aspects. This was briefly presented in a -- dynamically added -- presentation after the one given by Marie-JosÚ.

    Joerg Ott presented an overview of the work on Internet Media Guides (IMGs) as presently undertaken in the MMUSIC WG (where it was started some 1.5 years ago). The work is motivated by the need to provide powerful generic mechanisms for disseminating content and service information in various networks (including DVB, UMTS, and plain IP networks, among others).

    The concept of IMGs defines mechanisms to communicate metadata (about content, services, and also configurations) from one or more IMG sender via zero, one, or more intermediaries (IMG transceivers) to any number of IMG receivers. IMG metadata -- formats for which are not defined in MMUSIC -- are encapsulated in IMG envelopes and transported using different IMG operations: ANNOUNCE for multicast/broadcast dissemination, QUERY/RESOLVE for receiver-side inquiries (polling) to a server, and SUBSCRIBE/NOTIFY for asynchronous notifications. These operations are realized using FLUTE, HTTP, and SIP, respectively. As IMGs are agnostic to the content format, (XML or otherwise encoded) high-level configuration information could be distributed via IMG mechanisms. The reliable multicast support appears particularly applicable for a DVB environment. Authentication of source is also important.

    Comments from the audience suggest that this may be very applicable, not necessarily at the IP layer (as Gorry pointed out). Joerg made the point that this is clearly not meant for IP stack configuration, but for higher layer information. Hence there is a "vertical" split between IMG and DVB/IP layer config -- which is well-recognized. Arguments were made that the address resolution mechanism should not reach too far up into higher layer aspects, but be very restrictive. Some intermediate MPEG-2 devices currently have no IP-stack, and simple clients would be needed. Higher layer aspects could be dealt with by work such as IMGs working with other IETF WGs.

    9. Review of Milestones (Gorry Fairhurst)

    Gorry reviewed the WG milestones. The two initial milestones have been met (for the architecture and the ULE document), but their completion is lagging behind. While the address resolution is progressing, the respective future milestones will likely need adjustment. These Charter changes will be agreed with our responsible Area Director (Margaret).


    IP over MPEG-2/DVB (ipdvb) WG