Last Modified: 2004-07-23
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.
| 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 |
|
IP over Digital Video Broadcast Networks WG (ipdvb)
Thursday, August 5 at 1300-1500 =============================== CHAIR: Gorry Fairhurst <gorry@erg.abdn.ac.uk> Minutes recorded by Joerg Ott. Checked by Gorry Fairhurst and Joerg Ott. 1. Agenda Bashing (5 minutes) - Chair The agenda was accepted as is. 2. Working Group Status and Plans (15 minutes) - Chair This was the first IPDVB WG meeting. The name of the group was "ipdvb" rather than "ip-dvb", to match IETF naming policy. Note the change of the mailing list to: ipdvb@erg.abdn.ac.uk (although for the moment the old name continues to work). The ipdvb milestones were reviewed. - See slides, a few milestones are slipping, but nothing serious. 3. Requirements/Framework (20 minutes) Marie-Jose Montpetit http://www.ietf.org/internet-drafts/draft-ipdvb-arch-00.txt - See slides. Marie-Jose described progress since last version. The document had evolved and now contained more than just a ULE requirements specification, rather a full framework is described. This major revision is reflected in the name change. The focus of the revised document was on "efficient and flexible" delivery of IP via MPEG-2 transport streams providing compatibility with services on DVB and ATSC (and different physical links). There was new text describing the various scenarios. Open issues included e2e management of IP flows. Various possibilities were described: - Should address resolution be used to map specific addresses to PIDs with special features? - Should extension headers can carry e2e info about the cell content? A question was raised about the meaning of e2e (end-to-end). It was clarified that the intended meaning is "edge-to-edge", essentially speaking of the satellite link or, more general, an MPEG-2 Transmission Network. Obviously, end-to-end should not be used as it has a different meaning in the IETF. A comment was made that even the term edge-to-edge might be too close. In any case, the document should make clear how this term is used and end-to-end should be avoided. Another question was raised whether the document can be advanced to Wroking Group Last Call (WGLC). It was found that further edits are still necessary, including - removing redundant AR info and clarify AR reqs. - removing AR appendix - add "e2e" management reqs - fix last inconsistencies Marie-Jose proposed it should be resubmitted to the list with the intention of a fast WGLC of rev -01. The chair asked that any further questions to be mailed to the list. 4. Ultra Lightweight Encapsulation (15 minutes) - Bernhard Collini-Nocker http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-01.txt - See slides. B-CN outlined the changes since -01, including improvements of clarity, refinement of the text on CRC generation to be unambiguous. The text had been updated with revised CC processing at the encapsulator and receiver. The MPEG-2 specification allowed duplicate packets in a Transport Stream. MPEG is clear about this: duplicate packets are to be discarded. There has been various updates to improve clarity and correctnes, and a hex-code example had been included to help implementors verify correct CRC operation. Several open issues were identified: - There had been a request for optional non-default CC processing. There had been little discussion of this and the doc now conforms to the MPEG-2 spec. The question was raised whether anyone would have a strong motivation to change the ULE spec on this. As no inputs were received, it was concluded to keep the spec as is. - Another issue was whether Adaptation Field usage should be supported. The proposal was that the document stays as is. One comment from the audience indicated that Performance Enhancing Proxies (PEPs) may benefit from such signaling feature. It was noted, however, that those cannot be assumed to be right at the "edge" and that they should be using higher layer signaling (i.e. above IP) anyway. - IP related: What was the correct code point value for Ethernet bridging? The IEEE format for bridging has extra padding inserted, so the document stays as is. Regarding the general ULE spec, a question was raised about packing: Are there any timers associated with the packing process? It was confirmed that there are. A variable can be set according to the needs of an operator - there is no "one size fits all" solution. The parameter was defined, and could be settable e.g. via SNMP. A sensible threshold may be 100ms, but this depends on the higher layer protocols and such a packing threshold may also be influenced by overall b/w constraints be a matter of policy, e.g. when trying use left over pieces from TV. In this context, some further discussion arose around the scope of the encapsulation: does this just cover IP-over-DVB or other protocols (e.g. Ethernet bridging) as well. The latter is perceived to be within the charter, was also explicitly mentioned at the BoF in Vienna. Similarly, other L3 protocols are allowed; even some experiments using MPLS over ULE were reported. Because of timing issues of other protocols, many scenarios become much more interesting over DVB-T/C/H rather than -S. The issue of carrying ULE over an arbitrary Internetwork was also brought up. But this is outside the scope of ULE. ULE is just for transmission over MPEG TS. The AVT WG is a place where one could talk about MPEG-TS over RTP. The document was now consided stable and there were several existing implementations. The authors would like to produce one more rev and move to WGLC. 5. ULE Extension Headers (10 minutes) - Bernhard Collini-Nocker http://www.ietf.org/internet-drafts/draft-collini-xule-00.txt - See slides. The draft described optional headers for encyrption, FEC, etc. This followed much discussion on the list about _HOW_ to do extensions, how to know there are extensions, how to encode them, how much overhead, how many may be used, etc. This draft came out of this debate and includes ideas and points raised by various people. It was intended to move the core of the document to the ULE Spec and to leave the encryption to a separate document (FEC could also go to a separate document). Discussion on including encryption was controversial. People seem to have different assumptions about which level of security to provide at which layer. Following a statement that encryption should be supported, there was much discussion of what was required, could be implemented, should be implemented, etc. It was observed that security is non-trivial and that IPDBV is a group doing a mapping (and may not understand well enough the actual security requirements). If encryption is supported at the link-layer (which is the case, e.g. for pay TV), an ecnryption specification may as well be done by the link layer folks. It was noted, however, that the appropriateness of this depends on the scenario in which you are operating. The discussion was inconclusive and is to be taken to the list. Within this slot, some discussion of XULE (next agenda item) surfaced. The current wording of XULE ID proposes just one IANA registry, using 12 bits. This was observed to be fairly complicated. It was also noted that, while extensibility of ULE is a desirable goal, its flexibility should not the simplicity requirement -- since people may want/need to implement this in hardware in the end. It may be conceivable to consider a simpler design but, for the time being, people do not feel uncomfortable. 6. Outstanding ULE Issues to progress to a WGLC (10 minutes) - Chair Many issues of XULE were already covered in the context of the previous slot and were not repeated. There was tentative agreement to merge the basic spec with that of ULE. 7. Address Resolution (15 minutes) - Marie-Jose Montpetit http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-01.txt - See slides. Marie-Jose reviewed progress since -00. She noted that this was still an the individual draft, and that much of the work was to introduce new material, and closer coordination with the ARCH draft. The focus of this document was on "what exists" and "what is needed". New approaches are necessary to make the assignment more easily integrated in ISPs configuration and provisioning. Marie-Jose asked for inputs (via the mailing list) on topics relevant to this draft - how should systems determine IP to PID mapping? - are there issues concerning QoS or use of MPEG-2 transmission networks as one part of a larger network? - At this stage offers of text, ideas, and discussion would be very welcome to understand who can contribute. The next version will also look for inputs from the working group on the following: - how-to guides for DHCP over ULE - how-to guides for ND or ARP over ULE For the time being, this is not a WG document? After the next revision, the authors will ask the list whether not to adapt. 8. Address Resolution with UDLR (10 minutes) - Hidetaka Izumiyama - See slides. The presentation described IP address mapping dynamically. It followed the current address resolution standard, and described how these mapped on UDLR mechanisms to turn a unidirectional-link into a bidirectional one. The group welcomed the inputs and the author promised to send some text to assist in preparing the next rev of the WG documents. 9. Other Issues / Future Work There was a brief discussion of the text that had been posted to the ipdvb mailing list 14/7/04 Art Allison describing ATSC and the way in which IP multicast was supported. Slides were presented by Gorry Fairhurst describing progress of various implementations. Gorry Fairhurst promised to build a web page to summarise the status of ULE implementations. |