IP over MPEG-2 Transport (IP-DVB) BoF Minutes, 14 July, IETF-57 Chairs: Gorry Fairhurst (gorry@erg.abdn.ac.uk) and Bernhard Collini Nocker (bnocker@cosy.sbg.ac.at) Mailing list: ip-dvb@erg.abdn.ac.uk http://www.erg.abdn.ac.uk/ip-dvb/ The AD for this BOF was Thomas Narten. 4 drafts were presented: draft-fair-ipdvb-req-03.txt draft-clausen-ipdvb-enc-01.txt draft-fair-ipdvb-ule-00.txt draft-fair-ipdvb-ar-00.txt The agenda was bashed and asked the audience for any suggestions or modification. Minute taker was Haitham Cruickshank from the University of Surrey UK. 1. Bernhard conducted the first presentation on why this is an IETF activity and presented a summary of the IP over MPEG-2 requirements. He spoke about the existing standards from DVB, including MPE (which has been deployed) and the needs for new protocols. [Copies of slides are in the proceedings.] Q: AD) Is this activity only for satellite? A: Bernhard) Satellite is an important application. There is also some interesting opportunities in the case of terrestrial transmission. A: Gorry) This WG intends to produce protocols for transporting IP over MPEG2 and DVB transmission networks, which are defined by ISO. Satellite services are important examples, as are digital terrestrial TV systems, some cable networks, etc. Q: Dino) Sending multicast packets is efficient, but unicast packets are not efficient in a broadcast network such as this. A: Gorry) Multicast is an important service, but both need to be addressed by this list. A: Bernhard) There are people building access networks using this technology too. Q: AD) Is this for IPv6 or IPv4 or both? A: Gorry) The focus should be IPv6, but we need to find a solution that will work with IPv4 as well. 2. Bernhard conducted the second presentation of the simple encapsulation of IP over DVB. He mentioned that the European Space Agency (ESA) is sponsoring this work. [Copies of slides are in the proceedings.] Q: Michael Schmidt) Does this encapsulation work for cable? A: Gorry) Yes, if it uses MPEG-2 Transmission. Q:?) There is a problem with data services using MPEG-2 transmission over IP. There can be packet re-ordering resulting in loss/reordering of TS Packets, which video can accommodate, but data services suffer. A: Gorry) The intended activity is IP-over MPEG-2 only. The WG does not address MPEG over IP issues. A discussion followed about issues with IP services over DVB over IP networks. AD: This problem was important, however the focus of the work was IP services over MPEG-2, not vice versa. Q:?) Give some examples of unicast applications A: Bernhard) Access networks, Skyplex and VPN over satellites. 3. Gorry presented the third draft on Ultra Light Encapsulation (ULE). This was an alternative to the Simple encapsulation, The main difference was an alternate framing mechanism that placed IP packets directly into MPEG-TS payload. [Copies of slides are in the proceedings.] There followed an open discussion of things raised on the list and options for implementing the framing. This discussion mostly applies to both the proposed encapsulation formats (Simple, ULE) - that is, the discussion was independent of the way in which the SNDUs were framed in the MPEG-2 Transport Stream. Q: Gorry) When are destination and source MAC addresses needed? Q:?) In the presentation the ordering for the MAC addresses was (Destination, Source) why not (Source, Destination)? A: GF:) This was a mistake, we intend to do the same as Enet. Q: ??) Do we need a 3MAC address2 for IP routing? A: GF) Yes - unicast routers NEED to filter packets sent directly to them A: AD) You can1t do unicast routing without this. A: Dino) The MAC destination address is more efficient for multicast filtering, this is even more the case for IPv6 multicast filters Q: Gorry) Also need to discuss what happens with bridging, can the IETF define a L2 forwarding operation? A: AD) Yes, if it complements the work for IP. Q: ?) It is easier for hardware can recognise MAC addresses in a fixed place and they are always present A: GF) We could look at this on the list. Q: GF) Apart from bridging, who needs a source MAC address? A: Dino) IS-IS expects a MAC source address A: Gorry) We should discuss this on the mailing list to get a good feedback on this issue. A:AD) The list needs to consider Pros/Cons very carefully and must document the reasons why decisions are made. Q: AD) Is the Ethernet type sufficient? - It may be, and would not require a separate IANA registry. A: Gorry) Yes for now. Q: ?) Ether types include a subset of LLC/SNAP - Do you need LLC/SNAP as well? Q: Gorry) Does anything rely on this? A: Dino) LLC-SNAP is used by Spanning Tree A: Gorry) Yes, and by some discovery protocols too. A: AD) The ID needs to specify the behaviour, one way or the other Q:Dino) Are the lessons of ATM fragmentation learnt here? A: Gorry) Yes, the draft addresses these issues clearly, any other observations are welcome. Q: Sebastien) What about MPLS? A: Gorry) This is not part of the base spec, we could add later. A: AD) keep the door open, but start simple. Q: ???) Should receivers know about the type of encapsulation (MPE, SIMPLE or ULE)? A: Gorry) I think it may be possible to find a way to let receivers know which is being used. We1d need to take this to the list. Q: Gorry?) Is there a desire to have two standards for two cases or one? A: AD) One is always very much better, More design details should be put into SIMPLE and ULE and merge them if needed. 4. Gorry presented the address resolution draft and emphasized the need to translate IP addresses to MPEG PID and physical media ID. He mentioned 3 methods: Manual configuration, SI tables (e.g INT method) and a dynamic IP-level approach (re-using IPv6 ND address resolution). [Copies of slides are in the proceedings.] Q: AD) What is the size of the INT table, how many systems do you expect in a satellite network really? A: Bernhard) For satellite, due to costs of the satellite transponder many end systems will share it and, hence, the INT may get huge. Q: Dino) How large is the PID space? A: Bernhard) 13 bits Q: Dino) Is this fixed? (could we have more than the current 13 bits) A: Gorry) Yes, thats given, defined by the ISO spec for MPEG-2. 5. Gorry presented the WG road map for standard RFC for encapsulation and [Copies of slides are in the proceedings.] Q: AD) Why security. This was not part of the Charter? A: Gorry) Security poses issues for flat networks, this may provide useful inputs for the requirements, but is unlikely to be a work item of this group. Sebastein presented 2 slides on Alcatel1s work on securing satellite DVB by adopting a similar approach to GDOI from the MSEC group. (see draft-duquer-fmke-00.txt). [Copies of slides are in the proceedings.] Q:AD) You mention MIBs - what are these used for? IP functions? or something esle? A: Gorry) I think it's mainly to identify how the IP level is functioning for the encapsulation / address resolution. A: Bernhard) You may also wish to set / view the tuning parameters that identify which TS Multiplex the receiver is receiving. Q: AD) Security does not work with ARP - Do we need security for address resolution? A: Haitham) Securing IPv6 ND is not resolved yet in the IETF and we should wait for their results (SEND WG). Haitham mentioned that IPSEC and MSEC work can be adopted here. A: AD) Any security issues should be addressed to other security WGs. A: Gorry) We should discuss the specific needs on the mailing list. WRAP UP: The AD asked for show of hands from people who will support this work. More that half the audience showed interest. The AD asked for a show of hands from new people who think they will benefit from this work. There was a group of IETF attendees interested in developing these as IETF work items beyond those who authored the current individual drafts. |