2.3.9 IP over DVB (ipdvb)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27


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

Internet Area Director(s):

Mark Townsley <townsley@cisco.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
include the Digital Video Broadcast (DVB) standards: DVB-RCS; DVB-S
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
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
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
be described.

Define standards-track RFC(s) to specify procedures for dynamic
resolution for IPv4/IPv6. This will describe the protocol and syntax
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.
Done  Submit Architecture to IESG
Done  Draft of a WG ID on the AR Framework, specifying mechanisms to perform address resolution.
Done  Submit Encapsulation to IESG
Feb 05  Draft of a WG ID or the AR Protocol, defining a protocol to perform IP address resolution.
Oct 05  Submit AR Framework to IESG
Dec 05  Submit AR Protocol to IESG
Dec 05  Progress the Encapsulation RFC along the IETF standards track


  • draft-ietf-ipdvb-ule-06.txt
  • draft-ietf-ipdvb-arch-04.txt
  • draft-ietf-ipdvb-ar-00.txt

    No Request For Comments

    Current Meeting Report

    Minutes of IP over Digital Video Broadcast WG (ipdvb)

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

    Minutes reported by Jörg Ott <jo@netlab.hut.fi>.

    The IPDVB WG met once at the 63rd IETF (3 August 2005, 1030-1230). The meeting was chaired by Gorry Fairhurst. The proposed agenda was accepted, no additions were made. A tentatively scheduled presentation from Fraunhofer Gesellschaft (draft-miloucheva-udlr-mipv6-00.txt ) was cancelled, because no presenter was available.

    Document Status

    The chair reported on the document status: Two documents are in the RFC Editor queue: draft-ietf-ipdvb-ule-06 (for Proposed Standard) and draft-ietf-ipdvb-arch-04 (for Informational). No other documents are in the IETF process beyond discussion in the WG.

    There is one active WG draft, draft-ietf-ipdvb-ar-00.txt which had superseded draft-fair-ipdvb-ar-03.txt.

    Further drafts to be discussed at the meeting include
    draft-cantillo-ipdvb-s2encaps-00.txt, and

    On the ROHC draft, Carsten Bormann noted that only one minor problem still remains to be solved for the Ethernet case: to get a number assigned. Then one can define a protocol to negotiate the context. A future draft could potentially address both ULE and Ethernet, and for ULE this could piggyback on whatever config approach IPDVB will take. The present draft -01 will remain active.

    Volunteers are required to progress the address resolution protocol and perhaps to to revive draft-montpetit-ipdvb-config-00.txt, expired.

    Gorry reviewed the WG milestones noting a new WG draft on AR process, but that there was currently no WG document for address resolution protocol (was supposed to be available as -00 in Feb 2005). The deadline has been postponed with agreement from the Area Director.

    Uni-directional Lightweight Encapsulation

    Gorry Fairhurst present a brief update on the ULE spec. Revision -05 was submitted to the IESG. Revision -06, that was published recently, has the comments of the IESG review folded in. Refer to the slides for a detailed list of changes. Gorry pointed out a substantial change regarding the IANA registration procedures. He also noted the new document title, which had changed from "Ultra-Lightweight Encapsulation" to "Uni-directional Lightweight Encapsulation". A comment was made that ULE should also applicable to DVB-RCS and is thus not limited to uni-directional communications. There were suggestions on finding a better expansion of the letter "U" in the spec's title, but this is not felt to be serious and the new name was accepted.

    Gorry noted also that until recently, ULE had not defined a "format_identifier" that would be needed in the context of an MPEG TS multiplex to identify the ULE stream in the SI signalling. The value 0x554C4531 has now been assigned for use with ULE by SMPTE (the ISO registry for SI values). Similar registration requests could be made for a "Stream_Type" where registries are maintained by DVB, and ATSC. It was also possible to consider allocating a "Data_broadcast_ID", although this was normally used with table sections, and therefore was necessarily appropriate to ULE. If there is a strong desire for a "Data_broadcast_ID", this should be taken to the list.

    Finally, Gorry provided an update on ULE implementations: various commercial and open source receivers are available at this point but only commercial gateways (i.e., senders). Some at the meeting noted that the European IST project Daidalos is developing an implementation with work from Fraunhofer Gesellschaft; however, Gorry was unable to say whether or not the result will be open source. Information about known implementations can be found at http://www.erg.abdn.ac.uk/ipdvb/ipdvb-impl.html and implementers are encouraged to provide additional/updated information regarding this page.

    Address Resolution

    Gorry briefly reported on AR on behalf of Marie-José Montpetit. Address resolution is about associating IPv4/IPv6 addresses with an MPEG-2 TS.The draft was adopted as a WG document and recent changes reflect much previous input from the UDLR WG, various nits, and a major reorganisation of the the sections. Further details are in the slides.

    Gorry strongly encouraged input from the group on a number of intended future changes (also listed in the slides).

    IP Address Configuration for ipdvb

    Martin Stiemerling gave a short intro to the draft's history and then proceeded to summarise changes to the draft (see slides). He rehashed the problem space as well as the network and configuration scenarios (already introduced at the last IETF). Agreement within the group is needed on these issues and so he solicits feedback in order to proceed. One question from the audience was raised: why not simply use IPv6 autoconfig? Martin responded that there is a potential stability issue as IPDVB may be faced with 10s of thousands of receivers, and that other parameters (not currently specified by the NDP) may be required. Martin concluded, stating that a new draft will be available in the Sep/Oct timeframe.

    ULE Security Extension

    Haitham Cruikshank presented some proposed security extensions for ULE, a subject that was already raised at the last IETF, but no feedback was received on the list afterwards. He noted that there had been a parallel presentation in the MSEC WG (which could provide appropriate review for the key-management functions). He briefly reviewed comments received on this matter at the last IETF meeting (see slides and minutes from the 62nd IETF) and gave an overview of the changes. He proceeded with a motivation for ULE security and requirements for IP over MPEG-2 TS (see slides 3 and 4). In particular, he stated that the ULE security shall not be a replacement for security at other layers and shall help to maintain transparency with Performance Enhancing Proxies (PEPs). Haitham went ahead to discuss the proposed approach (see slides 5-8) and then suggested future plans for the next revision (slide 9).

    There was discussion about the number of keys that would need to be managed, and Haitham was asked if all entities shared a single key? - Haitham noted that the proposal could live with a only single key at each receiver for all unicast flows sent to a receiver, and perhaps one key per flow (as in msec) for multicast flows. There was discussion about whether one key for all receivers was possible, which provoked doubt in the audience that this was really advantageous.

    Looking at the proposed packet format and the presentation, Steve Bellovin noted that authentication of the source of data was essential. In practice, this required at least a sequence number and a crypto integrity check. He affirmed that using only a single key for all the network traffic was a mistake as this would make attacks on confidentiality much easier.

    With reference to the sample ULE packet format a question was raised which part of it would be encrypted. Haitham responded that this is the "SNDU payload", potentially including arbitrary inner extension headers.

    Haitham noted that the chosen approach allows also non-IP packets to be secured by ULE. A comment from the MSEC WG was made: whether or not IP-based key management could also be used for non-IP packets -- which Haitham confirmed: this was explicitly included in the current requirements.

    Steve Bellovin asked if there was a method defined that would allow the IPsec to be applied to non-IP traffic, because current IPsec relies on port numbers, etc to define the flows within the Security Policy Database (SPD). New entries/methods would be required if layer 2 frames were be to encrypted. He also urged caution regarding multicast traffic. In particular, he argued that a good justification is needed for doing non-IP traffic security in the IETF, and that this would need input and review from the Security Area. Modifications to the SPD and its use shouldn't be done in an Internet Area working group.

    He went on to state that the ULE security designers should not make simplifying assumptions about capabilities of attackers (hinting at the missing HMACs). He further noted that HMACs are pretty much free (in terms of processing, but not protocol overhead) at data rates around 100 Mbit/s.

    Joerg Ott raised concerns that the case for the inclusion of security at the ULE layer is still not really motivated. He noted that TCP PEPs could well work with IPsec (if just applied at the right point which also applied to ULE security). He encouraged the authors to perform at least a detailed analysis of why IPsec cannot/should not be used.

    During the discussion, it was noted that two things can be bought by L2 encryption: some degree of medium access control and prevention of traffic analysis (the latter only partially, however, since there is other information available).

    Margaret Wasserman stated that she was concerned that if the non-IP traffic required a new infrastructure, then this may not be appropriate work for the group. If the group decided to go with IP traffic only, IPsec key management may be appropriate. She also noted that the authors seemed to be looking for something in between - were bridging and IP traffic equally important? At the moment, she is not sure whether there is something to work on.

    People are encouraged to look into this problem since it requires a broad analysis, and a separate requirements document (as an I-D) would be the best way forward, so that the WG can understand the issues to be addressed. This also will allow the ADs to understand the motivation/needs/objectives. Steve volunteered to help understand the threat analysis and would send some references as a starting point to the authors.

    IP Encapsulation for DVB-S.2

    Juan Cantillo presented some requirements for transmission of IP datagrams over DVB-S2 (see slides). He gave a quick overview of DVB-S2 and particularly the available framing formats. Besides MPEG TS, DVB-S2 will also allow for "generic streams" that are IP friendly and no longer requires fixed-size frames. While, for IP encapsulation, IP over ULE/PPoE via MPEG TS over DVB-S2 is possible, no choice had been made for an adaptationlayer using the Generic Stream. Moreover, the capabilities of generic streams suggest the development of a new adaptation layer. He presented some basic ideas and issues to that end (see slides).

    Joerg Ott remarked that TU Braunschweig is working on an all-IP encapsulation (without ULE/PPoE) for DVB. Gorry said a number of other people had also voiced interest and on-going projects in this area to the ipdvb list. Rod Walsh said that the definition of such an adaptation layer would require coordination with DVB to avoid conflicts in the future. Instead of pursuing this work in the IETF, it may be possible to provide input to DVB.

    Gorry Fairhurst said that he was aware of the parallel work within DVB-GBS, and the work in an ad-hoc WG on the design of a new encapsulation. There was a good liaison with this group. He said this work had proved more difficult than first envisaged, and that there were complex dependencies between the physical layer needs and the IP network functions. These were not yet well understood, and a clear definition of the requirements would be good for all. The ad-hoc group responsible for this work were aware of this draft, and of the discussions within the ipdvb list.

    Gorry Fairhurst asked whether a DVB-S2 mechanism should be something completely different or some adaptation of ULE? Juan does not see a necessity for a completely different approach, but also indicates that ULE is not directly applicable for cases with no MPEG-2 TS, as in DVB-S2.

    An inquiry from the chair showed that few in the room had read (or was aware) of the draft. He urged the group to read and comment on it. The draft will be updated in September.

    Review of Milestones

    Finally, Gorry Fairhurst returned to the status of the milestones (see above) and strongly urged the group to provide input on the address resolution as this is now the most pressing work item.


    Agenda and Presentations