Subject: END of WGLC draft-ietf-ipdvb-ule-04.txt

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 27 Jan 2005 19:49:56 +0000

This note ends the WG Last-Call for comments for the WG document
named below:

http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-04.txt

The document will now progress to Area Director review, a copy of the
emailin requesting publication will be sent to this mailing list.

Best wishes,

Gorry Fairhurst
(ipdvb WG Chair)

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 31 Jan 2005 02:44:02 +0100

I apologize for being late with reviewing this draft.
I have a couple (63, to be precise) editorial comments that I have sent 
to the authors.
No big problems in here, but some language that the authors may or may 
not want to improve (and some minor contradictions that have an obvious 
resolution).
I'll leave it to the discretion of the authors how to use these 
comments.

One question though: Why is it that ethertype frames can be sent 
without MAC but length (LLC) frames can't?
Is the assumption that all LLC protocols need full MAC addresses?
I don't know all existing LLC protocols, but I know at least one 
proposal for one that probably doesn't.
It would be easy to introduce a mandatory extension header 2, which is 
like 1 (i.e., does not allow chaining) but leaves out the 14 bytes of 
(DA, SA, Type -- the latter is redundant with the LLC length), leading 
to:

	   0                   1                   2                   3
	   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	  |1|        Length  (15b)        |         Type = 0x0002         |
	  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	  |                                                               |
	  =                           LLC payload                         =
	  |                                                               |
	  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	  |                             (CRC-32)                          |
	  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(and the obvious equivalent for D=0).

Oh, and I'm a bit confused about the IANA policies (why do the specs 
only have to define name, value, need, and intent? Wouldn't semantics 
be nice?).

Gruesse, Carsten

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 31 Jan 2005 11:46:02 +0000

Thanks Carsten!!!!!

> I apologize for being late with reviewing this draft.

That was just in time:-)

> I'll leave it to the discretion of the authors how to use these comments.
> 
Detailed reviews by others are always most useful. The authors will work 
through the NiTs and minor issues. I'll make sure any difficult/ambiguos 
issues are brought back to this list.

> One question though: Why is it that ethertype frames can be sent without 
> MAC but length (LLC) frames can't?

Yes we should talk about this on the list. I've made a separate thread on LLC

<SNIP of LLC question>

> only have to define name, value, need, and intent? Wouldn't semantics be 
> nice?).
> 

Yes, indeed you shouldn't be confused - the Specifications of ExtensionHeaders 
MUST also DEFINE the symantics/procedures to be used for the extensions. This 
should be made clear in the next draft!

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 31 Jan 2005 13:16:52 +0000

So, I'd like to ask the group as a whole, what they see as the usage of LLC 
within DVB, ATSC, or any MPEG-2 based transmission network?

Carsten Bormann wrote:

<snip - see response in separate email>
> MAC but length (LLC) frames can't?

So the WG did discuss this, but it seems worthwhile checking again that we 
have got this correct.

The history as I recall is:

(i) Do we need LLC?
Yes (discussed at both ipdvb BoF as well as at other times), we should 
supportLLC, because of it use/potential use for OSPF;
Bridging; L2 Management/devcice discovery

(ii) Non-issues for ULE.
LLC is also used:
  - To raise the ETnerenet frame size above that of traditional Ethernet
  - To provide a Type field (not present in basic MPE header).
Both of these are supported natively within ULE without the need for LLC/SNAP

> Is the assumption that all LLC protocols need full MAC addresses?

So, yes that was it.

- My understanding was that because this was an IEEE protocol, and much of the 
use of LLC reflected use in a bridged network, then it was best to include 
both a source and destination MAC address.

> I don't know all existing LLC protocols,

Nor me --- can anyone else on this list help?

 > but I know at least one

Aha - Do tell more...

> (DA, SA, Type -- the latter is redundant with the LLC length), leading to:
> 
>        0                   1                   2                   3

I'm keen to understand first the intended usage....

<snip - see response in separate email>

Best wishes,

Gorry Fairhurst

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 31 Jan 2005 14:31:43 +0100

> Bridging; L2 Management/devcice discovery

LLC is also the basis for SNAP.

> Both of these are supported natively within ULE without the need for 

SNAP can be used for protocols other than those that have an ethertype.
Again, I don't know all protocols...

> - My understanding was that because this was an IEEE protocol, and 
> much of the use of LLC reflected use in a bridged network, then it was 
> best to include both a source and destination MAC address.

I'd say leave this for the encapsulator to decide.
Assuming that ROHC over 802  goes the LLC route, it is not a given to 
me that we always need MAC addresses.

>> It would be easy to introduce a mandatory extension header 2, which 
>> is like 1 (i.e., does not allow chaining) but leaves out the 14 bytes 
>> of (DA, SA, Type -- the latter is redundant with the LLC length), 
>> leading to:
>>        0                   1                   2                   3
>>       |                                                               
>> |
>>       =                           LLC payload                         
>> =
>>       |                                                               
>> |
>>       |                             (CRC-32)                          
>> |

This would be used for compressed voice in a ROHC/RTP scenario.
The LLC payload would contain the necessary glue, a ROHC header (which 
has a context ID useful for demultiplexing), and the voice payload 
(say, 10 bytes).
Adding MAC addresses and another (redundant) type/length field makes 
this SNDU significantly larger.
An NPA may or may not be necessary, depending on the specific use.

Gruesse, Carsten

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 31 Jan 2005 15:05:49 +0000

Right, I (personally) do think it would be good to explore ROHC requirements 
for ipdvb. Perhaps we should point this list to the ROHC draft?

1) MPE+LLC/SNAP+ROHC

To support ROHC over MPE would need LLC/SNAP - which has overhead/processing 
drawbacks. This mitigates the benefit from performing ROHC in this case.

2) ULE+Bridging+LLC+ROHC

I can see why an LLC-based method could serve ROHC well when ROHC may have to 
cross a L2 Ethernet subnetwork - especially when some of the L2 devices act as 
bridges (such as Wireless APs). To support ROHC over ULE using LLC would 
currently also require the Bridging Extension. If the ULE gateway is operating 
in a Bridging mode, this seems rather like the case for an 802.11 AP. So I'd 
have expected it to work with LLC bridging - but there is an overhead.

3) Other Options?

If the ULE-capable device is a router, you could have saved bytes by 
suppressing some fields. If you intend to use a L2 code point (LLC-Type), but 
at the same time do not need the L2 end point identifier (MAC Addresses), I 
think I need to understand more.

Clearly it would be posisble to define a header of this sort - but then it 
creates more Receiver de-multiplexing options...

One thought: If the WG envisages only one or a small number of uses for an LLC 
without MAC mode, would it make sense to think of a separate IANA 
assignment(s) for a Mndatory Type value from the ULE Registry? And what would 
the protocol dependices be on ROHC --- would the same ROHC methods still work?

Gorry

Carsten Bormann wrote:

> Assuming that ROHC over 802  goes the LLC route, it is not a given to me 
> that we always need MAC addresses.
> 
> has a context ID useful for demultiplexing), and the voice payload (say, 
> 10 bytes).