2.3.17 IP over DVB (ipdvb) Bof

Current Meeting Report

IP over MPEG-2/DVB Transport BOF (ipdvb)

Wednesday, November 12 at 0900-1130
===================================

CHAIR:  Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Note Taker: Carsten Bormann

0) AGENDA
---------
Chair starts with Agenda bashing (no comments), mandatory "note well" 
slide.

1) Introduction to the planned work
-----------------------------------
draft-fair-ipdvb-req-03.txt

Chair presents background: how to better integrate IP network using
links provided by MPEG-2 transport technology.

The most common use of the technology is as a broadcast technology to 
distribute TV to people's homes...
Leaders: DVB; ASTC in US
Focus: Link technology, not the audio/video aspect
Links could be unidirectional, bidirectional; p2p and p2mp
Observed that Path MTU is increasing.

Receiver structure: Tuner (hardware), demux (select PID, could be 
hw/usually sw in PCs), decaps (usually sw). Some form of Address 
Resolution is needed to configure these three boxes.

Key needs: To separate requirements and framework;
Scenarios are important to see way ahead.

For the next rev of the ID the authors would like to receive inputs to 
help:
	define scenarios, e.g.:
		DVB-RCS (Alcatel presentation last IETF)
		satellite TV (they have a scheme)
		satellite/terrestrial UDLR
		satellite to ADSL
		further scenarios?

Q: Are we going to split out requirements and framework?
GF: I'd like to, but we need to take advice as the text comes in.


2) Lightweight Encapsulation
----------------------------
draft-fair-ipdvb-ule-01.txt

Two alternative encapsulations were presented at the Vienna IETF.
Since then, there has been no further revisions of the other draft 
brought to the IETF 
(draft-clausen-ipdvb-enc-02.txt). This is not currently being 
progressed  by the authors; ULE has a subset of similar features, and 
satisfies most of the intended applications currently being 
considered.

The existing MPE encapsulation (defined by DVB and also used by ATSC, etc) is 
widely implemented. This uses the MPEG-2 control plane; it is based on 
DSM-CC (signaling for DVB and ATSC) and usage is expected to continue; 
particular application for data transmission to set-top boxes, and the use of 
DSM-CC data carousels.

ULE is layered direct on transport stream. This approach is known as Data 
Piping (DVB and ATSC term).
Minimum implementation effort is required: usually driver change only. MPE 
implementers won't find it hard to do ULE.
ULE differs from MPE, therefore there would be deployment issues for 
existing networks.

ULE vs. MPE:
Packing, CRC are mandatory in ULE - ULE avoids options.
Addition of Ethertype
Extension headers (e.g., for Bridging, and other future uses).
Large MTU (< 32KB), PMTUD friendly, could reduce the need to do 
TCP-PEP...

10 % better efficiency for *some* specific apps, niche scenarios (e.g. 
bridging, VoIP).

Receiver address can be omitted (needed for routing).
In ULE nothing is 32-bit aligned.

Itojun: Can we put a multicast MAC address in the receiver 
destination address?
GF: The spec does not say anything. My intention: should have MAC 
address semantics, without implying you need to use IEEE-assigned 
addresses.
GF: The receiver can filter using either a MAC or an IP address.
Itojun: IPv6 removed broadcast in order not to wake up the 
non-receivers, it would be nice to filter on receiver MAC address.
GF: Yes could be so. But if the MAC filter is based in software, the 
processing differences may be very small between matching an IP address and a 
MAC address. The receiver is going to do a uni/multi-cast filter at the IP 
level anyway. Operators can choose to not include them , if they know how to 
deal with this.

Changes to ULE since Vienna:
CRC-32 same as ISO DSM-CC CRC spec
stuff/pad must be 0xff
minor changes to clarify wording
discussion on mailing list of what do you do if 1..4 bytes left in a 
TS-Packet.
The type field was split: 
< 1500 for IANA-registered extension headers, 
>= 1500 IANA assigned EtherType values (using the current registry)

Itojun: What about 9KB Ethernet frames - these will be common in the 
future? This may be a problem?
GF: No, this MTU is fine. This is about the *type* field...
Itojun: Is there an IEEE definition here?
GF: Yes. The original Ethernet came from DIX, they used all type fields;
IEEE took the values <1500 (and moved a few to >1500) and used <1500  to 
indicate this was an LLC frame, the value indicated the frame length.
ULE has a length field already; so values <1500 are effectively unused.

Which bit should be used for address present? This is not defined now; 
authors propose to use the reserved bit (R) in the length field.

ULE -02, not yet announced, will go to mailing list soon and send to ID 
archive when this re-opens after the IETF.
Key issued to be addressed:
Harmonize wording with ISO MPEG-2, MUST use 0xFF for Stuff/PAD; 
clarifications of various other things.

3) Feedback on implementation of ULE 1
--------------------------------------
Two implementators provided presentations:

GF presents on behalf of GCS, Salzburg:
Linux driver, Technotrend PCI card, www.linuxtv.org GPL drivers
- ULE Implementation for GPL driver.
Their observations went into draft rev -02

4) Feedback on implementation of ULE 2
--------------------------------------
Vladimir Ksinant from 6wind/also speaking for Wolfgang Fritsche from
IABG on "ULE for IPv4/IPv6"
Rationale: Optimize
Support IPv6 in an efficient and standard way; implement ROHC later,
standard ND, standard stateless autoconf -- need protocol type field
Hardware: DVB with SCPC return channel

ULE -01 issues:
-- last byte management -- contradictions in text, current proposed
text fixed that
-- CRC ambiguities
Length field:
Use reserved bit; but we may need to reserve another bit!
Plan to run code in emulator in 12/2003, and a real DVB environment in 
02/2004.  Plan to take part in interop in Salzburg with GCS in 02/2004, to be 
sponsored by ESA.

GF: How keen are you on reserving one more bit in the header, reducing 
length to 14 bits, when we also now the new extension types...
Vladimir: Not so important, if we have an alternate way to add new 
features.
GF: OK, and I can see the need for the D-bit to be visible to any 
hardware processing, but we need a good case to take another length bit.

Vladimir described planned interoperability testing.

GF: Are there any other implementers who are trying to make this work at 
this time? -- please tell the list. The ESA Interop tests will also 
produce packet hex dumps that will help confirm if other 
implementations conform. Details will be posted to mailing list

5) Address Resolution
---------------------
draft-fair-ipdvb-ar-01.txt

GF presented on behalf of Marie-Jose Montpetit (the main author) who 
couldn't travel to the IETF - she sent these slides.
Although ULE was main topic on mailing list so far, AR may be even more 
interesting for the IETF. The draft is still at -00

AR procedures is not just finding a MAC address: TS PHY (different for each 
type of network), TS PID, Receiver ID/Address (if present). This type of AR 
is different, but not a unique problem: one-to-many network.
Three modes:
1) Pre-assigned, configured by user or oob; Set up some kind of arp cache 
entry.
2) Announced (send out tables for the mapping, a number of them have
been proposed, in DVB this is the Internet Notification Table = INT)
DV-RCS have MMT, MHP have yet another approach, ATSC has not yet 
decided.
All of these are part of MPEG transport network, not on IP level
3) Dynamic schemes working at the IP level.

Any new solution will need to take INT into account; influence DVB 
community as well as progressing our own work There is related Work at ETSI 
which the authors know: Virtual Access Interface; technology agnostic 
layer (without layers, you need to communicate frequency, FEC 
settings, ...)

If we do this right, we could reuse this technology in other networks with 
large number of clients...

Should this be Informational or PS?

open issues:
AR for Multicast?
technology agnostic
treatment for link-local, broadcast
Security

Tom Petch ?: From the CCAMP experience: ownership of standards can be an 
issue, how far down the stack can we go. There are  problems with 
interactions between standardization bodies with very different 
backgrounds and procedures...
GF: The basic technology is an ISO spec; There are other players out there 
that are using the ISO  standards to build different systems (DVB, ETSI 
ATSC) -- We are prepared to interact with these groups, in fact we are 
currently is  in contact with ETSI and via ESA with DVB-RCS. 

6) Proposed Roadmap & Charter
-----------------------------
GF presented the charter proposals, followed by an open mic session.

Mailing list started in 2001, 200 people (many just readers)
Bar-BOF at Salt Lake City IETF.
IETF BOF at Vienna IETF.
The AD to look after BOF process is now Margaret Wassermann.
The charter is now in IESG review.

Proposed deliverables from the WG:
1 Info RFC: Architecture Requirements
2 Std RFC: Encapsulation for mpeg-2 TS.
3 Info RFC; address resolution mechanisms for ipv4/v6.
4 Std RFC(s); on address resolution protocol dynamic 
unicast/multicast AR.

4 would follow 3, so details are not known, but 4 will be close to IETF 
protocols such as ND and ARP.

GF shows some new text for possible charter discussion: intention is that 
this work is longer-term, although immediately addressing niche 
markets.

7) Open mic discussion
----------------------

Tom Narten: What would be very useful is to hear from people who raised 
issues on the charter.

Rod Walsh: This new text is extremely helpful. It sets aside that this is 
not a replacement for existing solutions that have a long expected 
lifetime. If something like this did not appear in the charter, it might 
seem that the new encapsulation is a  competing solution to MPE; if that 
didn't appear in the charter, there would be an impression of 
conflict.

Tom Narten: At least two parties have raised concerns. Are there other 
people wanting to comment on the proposed Charter?
Margaret Wassermann: Is Greg White here?
No.
Margaret Wassermann: Any other objections?
GF: I noted that ipcdn wanted to make sure this work would not conflict 
with their charter, and IPv6 wanted to be clear about the way ND could be 
impacted.
Rod Walsh: Hard to discuss details of the charter before it is public ...
GF: The charter milestones contains both requirements and protocol 
milestones, this should have been clearer in the charter text itself.
Rod Walsh: The progress in the framework must be prioritized over the 
protocol work. There have been protocol-related milestones should follow 
this.

Margaret Wassermann: Are we now mostly talking about the wording of the 
charter, or are there objections to chartering at all?
Rod Walsh: There was a very real chance that the original charter could be 
taken in the wrong way, this is much better.

Tom Narten: I want to know of any fundamental issues that have not been 
resolved. Charter wording is not necesarily the right thing to do here.  
Let's revise the Charter and then use the mailing list to see if we 
covered the issues.

GF: How do we take this forward?
Margaret Wassermann: The three of you should come up with some wording; no 
philosophical difference, just make sure the wording reflects the 
consensus.

GF: Any general comments or anything that would be useful to ask?
Tom Edge?: If we look at the shift to the new world; much of this is 
US/EU; is there work in the far east?  Should they be involved?
GF: Jun Takei of JSAT is trying to help and sent some information to the 
mailing list. There is a Japanese variant ISDB-T which is different; but no 
other direct input apart from JSAT. We'd welcome any inputs from people who 
would like to use these protocols.

Slides

Agenda
Introduction to the planned work
Lightweight Encapsulation:
ULE Implementation ULE Implementation Status
Using ULE for IPv4 / v6 in MPEG-2 encapsulation
Address Resolution For IP Datagrams Over MPEG-2 Networks
Roadmap & Charter