Last Modified: 2005-02-25
|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|
|Jan 05||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|
Minutes of the IPDVB WG
Notes and minutes prepared by Joerg Ott <firstname.lastname@example.org>
The IPDVB WG met once at the 62nd IETF. The meeting was chaired by Gorry Fairhurst <email@example.com>. The Chair presented the agenda which was accepted as proposed (see slides).
The Chair briefly reviewed the working group and document status. At this point, there are no documents in working group last call. The framework and architecture document is in AD review, the ULE specification had just been sent to the AD. No documents are in the RFC Editor queue and there are no published RFCs so far. The Chair also pointed to the list of individual I-D submissions intended for the working group, some of which will be addressed in the end of the session. The Chair finally reviewed the WG's milestones
Marie-Jose Montpetit, presented on her behalf by the Chair
The Chair briefly reviewed the changes in -03 that were mostly minor (sees slides for details). The most significant change was to update the terminology so that it aligns well with the current ULE draft. The document is currently in IESG evaluation (for publication as an Informational RFC) and has received some requests for discussion on the Security Considerations.
Ultra Lighweight Encapsulation (ULE)
Gorry presented the changes to the draft that followed comments received during the working group last call. For version -04, as in the architecture document, the terminology was updated. Some sections were rearranged and various clarifications were made: to align better with ISO 13818-1 and the NPA address was explicitly positioned before the extension headers.
A second WGLC was issued after which version -05 was submitted. The title was changed, test and bridge extension headers are now required to be last in the extension header chain. The IANA procedures were updated to REQUIRE the proper specification of new extensions, an NPA mapping for multicast was introduced and lots of nits were fixed. The document is now resubmitted to the AD for publication as standards track RFC.
Another current issue is how to identify ULE streams. ULE does not define SI/PSI information to identifiy the stream. Lack of a Stream_ID has two issues: 1) it can prevent (re)multiplexers from forwarding a "stream" and 2) receivers cannot identify the stream type using SI/PSI tables. ATSC has made an offer that we can obtain a Stream_ID from their space. It was decided to ask ATSC and DVB simultaneously as soon as we have an RFC number, and include this in the Address Resolution I-D. To bypass having to wait for an RFC number, it was suggested to allocate the code point early enough so that it can go into the RFC. Other standards bodies should understand the IETF process well enough to be able to allocate based upon the progress right now. Gorry agreed to ask those with inputs on this topics, and then to take this to the WG email list.
Gorry noted also that an updated list of ULE implementations is available from http://www.erg.abdn.ac.uk/ipdvb/ipdvb-impl.html.
ULE Security Extension
No current ID (Slides had been sent to WG mailing list).
The presentation motivated the use of security at the ULE "layer" and suggested an ULE extension header for this purpose. The approach is generic and decouples the encapsulation from future security extensions. He pointed out that this is considered an additional security mechanism to IP, transport, and application layer security, not a replacement. It provides similar functions as IPsec, but in addition provides link confidentiality. The proposed approach suggests a new extension header for a security association id (similar to the IPsec SPI). Encryption algorithms, key lengths, etc. will be defined making use of the standard IPsec suites (i.e. work in msec). The focus is on encryption, (link layer authentication is not considered critical for ULE). Haitham finally illustrated the location of security extension headers within the ULE mechanisms.
Numerous comments were received from group: the requirements should be worked out first before a solution is presented. Concern was raised about the additional complexity incurred at the link layer, particularly as security mechanisms are available above and below. When used with IPsec, encrypting packets twice does not necessarily provide any increase in security. IPsec may simply not work on the scenario presented. Transport-Stream encryption needs also to be compared with the proposed methods.
In response to the discussion, Carsten Bormann presented some summary slides dealing with L2 security, highlighting the aspects that should be considered prior to developing a L2 security scheme:
* Security objectives and the threats should be clearly defined and so need key management in relation to the link, specific requirements on crypto algorithms should be identified, and an example should be worked out.
* There needs to be a statement saying why existing security mechanisms cannot be used.
* A motivation for and an "applicability statement" of the L2 mechanism should be provided in an I-D.
As a result of the discussion, Haitham (and co-authors) are encouraged to submit a new Internet Draft that should clearly describe what he wants to achieve rather than what he wants to do (and why this must be done at the ULE "layer"). This would be a welcome input to the IETF-63 meeting. (Mark Townsley, Internet AD, noted this was not within the current Charter.)
ipdvb and RObust Header Compression
Carsten gave a quick introduction to the development of header compression technology in the IETF and the role of the ROHC set of specifications. He then introduced the current work on ROHC-over-802, which needs to cope with layer 2 paths that might contain Ethernet, WiFi, WiMax and other IEEE 802 networks, possibly including ULE-encapsulated DVB. Due to the need to protect the compressed packets from any padding an Ethernet segment might introduce for packets below 46 bytes (and to provide a way for APs to remove this padding before sending the packet on to a wireless segment), the current proposal is to use LLC encapsulation for compressed ROHC packets on 802 networks.
The current ULE specification only allows for LLC frames together with MAC addresses (ULE type 0x0001). This negates part of the efficiencies provided by ROHC header compression -- uncompressed IPv4 and IPv6 packets can (and will often) be sent without MAC addresses. On the mailing list, a proposal was made to introduce a ULE extension header 0x0002 for encapsulating LLC packets without MAC addresses. In the discussion, no other use for LLC packets without MAC addresses was identified. Therefore, a preference was expressed for defining a ULE extension header specifically for ROHC (0x0003), which would also save the redundant three bytes of the LLC header, but would require ROHC-specific implementation work in a ULE implementation.
Problem Statement: IP Address Configuration for IPDVB
Martin discussed the requirements of configuration/provisioning of IP addresses and related parameters to DVB receivers for different scenarios. He pointed out that future IPDVB networks are likely to require powerful IP address configuration because, unlike now when they ae often viewed as "dedicated" links, DVB links will be much more embedded in IP networks in the future and DVB receivers will no longer be pure receivers.
Martin presented three scenarios:
1. Basic network configuration: asymmetric routing via a satellite (downlink) forward and a terrestrial uplink (back) channel.
2. DVB-only configuration: both uplink and downlink via DVB.
3. DVB-based IP broadcast: no uplink, just unidirectional downlink
Two scenarios can be considered for these: in one case, the IP address is readily available (pre-configured by the service provider or the user) but the remaining stack parameters still need to be conveyed, including DNS servers, proxies, and other services, multicast and routing configuration, broadcast configuration, and security information. In another case, a complete bootstrap is needed including IP addresses and maybe even lower layer parameters.
Martin raised numerous questions for the way ahead:
* What are the configuration scenarios?
* What exactly should be configured?
* How to configure?
* Who is in control of the receiver?
He finally noted that the scale of configuration is significantly different from other technologies: while 1K (maybe 10K) hosts may need to be configured per cable headend, IPDVB must consider at least one order of magnitude more. Comments received pointed out that the common characteristics of the scenarios described before should be worked out (so that the scenarios can be removed later). The case for DHCP as _the_ common configuration mechanism should be considered (for the bi-directional case).
There were no direct conclusions. Martin to continue (with inputs from the IPDVB WG) and intended to submit a revised I-D. One aspect related to configuration, address resolution, is addressed in the next presentation.
Marie-Jos Montpetit/Hidetaka Izumiyama
Hidetaka had submitted slides with an update of the case study for Neighbor discovery with UDLR (introduced in IETF-61). UDLR uses a L2 tunnelling mechanism over IP to create a virtually bidirectional satellite link. Case study 1 discussed the address resolution for the feed and case study 2 for the receiver. For details including diagrams see the slides. The Chair requested Izu to write some text on this topic and send this to the list.
The Internet Draft is based upon the IPDVB architecture document: it reviews the table mechanisms to resolve IP addresses to MPEG-2 Transport Stream IDs and IP addresses to MAC addresses. It also reviews known implementations issues as well as solutions to implementing DHCP, ARP, and ND in a table based environment. It finally attempts to provide a basis for a coherent view of address resolution in MPEG-2 networks. The present revision of the draft (-03) is still an individual submission. Recent changes include descriptions of use cases from the OpenCable and MHP communities; also, the implementation section was rewritten, and the overall structure was updated. Future work calls out for WG input on the usage of INT for IP-to-PID and IP-to-MAC resolution, DHCP and NAT issues, and DVB-RCS use cases.
There was no current text on existing mechanisms on PSIP in ATSC. A few short paragraphs in the same style as currently submitted for DVB-based mechanisms would be welcome. Input text is also needed on existing DVB-RCS mechanisms.
A revised I-D would be submitted after the meeting. In the next revision, the document would be restructured. A section on the experience with ND will be added, and references to ULE updated.
Protocols for MPEG-2 network configuration
Gorry Fairhurst presented on behalf of the author. The idea behind this work is to define a simple autoconfiguration protocol based upon the requirements from the architecture document for address resolution. The approach builds upon the table-based (INT, AIT, MMT) mechanisms. A simple autoconfiguration protocol shall be defined based upon the common semantics of these mechanisms. The protocol shall use XML as the common language for defining the extended AR records for unicast and multicast addresses. It should further build on mechanisms above the IP layer.
The draft needs to be updated to align with similar work in other WGs. Input is solicited from the WG on how to configure MPEG-2 devices with XML.
A question was raised about what shall be standardized to achieve these goals. The work targets an XML definition of the relevant information as well as a transport protocol to convey this information. It is noted that, with XML, many people come up with (potentially endless) different ideas that may not converge (easily). It was also recommended to work on the requirements first and not presume a certain solution before the problem is well-defined. The Chair noted that the immediate work should be focused on what is really needed (as opposed to what would be nice to have).
ARIB broadcast program resource identifier
Kirilka gave a short introduction to the draft and the general organization of the way content identification works with ARIB. The envisioned service is to be able to retrieve TV/radio program contents a user is interested in, e.g. via the Internet. Among transport protocols to convey the contents and metadata to describe it, an identification mechanisms is needed that allows to uniquely identify a piece of contents independent of the distribution channel. The draft presented introduces a URI scheme, the arib: URI, for this purpose. It comprises two parts: the broadcaster domain and a component path relative to the domain. For the former, a more fine-grained structure is proposed, comprising the original_network_id, transport_stream_id, service_id, content_id, and event_id. Kirilka outlined an example of how the respective parts would be used. ARIB can also be used to identify IP data streams in a broadcast stream. In summary, this would support the convergence of radio/television and Internet, although this did not fall within the Charter of the IPDVB WG (the authors were recommended to liaise with the MMUSIC WG Chairs and IETF Transport ADs to determine the appropriate way forward).
Review of Milestones
Finally, the Chair reviewed the working group's milestones. (1) The architecture/requirements work is complete, as is (2) the ULE spec. The address resolution (AR) mechanisms for IPv4/IPv6 should go to Informational, the corresponding protocol specs should be aimed at Standards Track. Work should proceed in two stages: 1a) Identify what exists and what is needed for IP traffic in broadcast scenarios and 1b) to ask for experience on how to make IETF protocols work (ARP and ND operation). This should be documented in different parts -- as is already in progress. Next, 2a) An AR syntax should be defined for 1a, followed by 2b) an transport for this syntax (presumably UDP-based and multicast-capable). Answering a question, the Chair confirmed that this should be workable also in the case of multiple DVB providers sharing the same path (at the IP layer, below, and maybe above). An important further problem is to enable multicast reception without full IP configuration so that passive IPDVB receivers can be put to work without significant effort.