DRAFT MINUTES: IETF-57 BOF, Vienna

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

The following minutes are DRAFT. Please do read and check.

Send any corrections to me (chair).

I intend to submit the final minutes in one week.

Thank you Haitham for volunteering to be minute taker!

gorry@erg.abdn.ac.uk
IP-DVB Chair

----

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)

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. 

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.

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.

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. 
    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 ³MAC address² for IP routing?
A: GF) Yes - unicast routers NEED to filter packets sent directly to them
A: AD) You can¹t 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. We¹d 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).

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
informational RFCs for architecture and address resolution and security.
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 Alcatel¹s work on securing satellite DVB by
adopting a similar approach to GDOI from the MSEC group. (see
draft-duquer-fmke-00.txt)

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:  AD asked for show of hands from people who will support this work.
More that half the audience showed interest.

AD asked for show of hand from new people who think they will benefit from
this work.  There were a group of IETF attendees interested in developing
these drafts.

Minutes were taken by Haitham Cruickshank, University of Surrey UK.