Last Modified: 2004-09-28
| 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 |
|
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) draft-ietf-arch-01.txt 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) draft-ietf-ule-02.txt 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) draft-collini-xule-00.txt 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) draft-fair-ipdvb-ar-02.txt 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 draft-ietf-mmusic-img-req-07.txt draft-ietf-mmusic-img-framework-08.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). |