2.3.15 IP over MPEG-2/DVB Transport (ip-dvb) Bof

Current Meeting Report

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

The AD for this BOF was Thomas Narten.

4 drafts were presented:

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 

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 
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 
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, 
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 
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 

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 
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. 


IP over MPEG-2/DVB Transport BOF