Re: IP MPE payload

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

I think we're moving on to an interesting topic...

Let me try to clarify a few points - especially for those
who do not have a copy of the EN 301 192 being quoted.

The EN implements a partial MAC service, and seems rather poor
on defining the mapping of IP onto it. See in-line comments below. 

Gorry

----

Lloyd Wood wrote:
> 
> On Tue, 30 Oct 2001, Patrick Cipiere wrote:
> 
> > > In your previous mail, you were suggesting redefining the bit from
> > > indicating
> > > (LLC_SNAP encap)/(raw IP datagram) to indicating
> > > (raw IPv4 datagram)/(raw IPv6 datagram).
> >
> > By no way I want to redefine any bit. I just want to use it the
> > way the standard is designed.
> >
> > LLC_SNAP_flag == 0 means payload raw IPv4
> > LLC_SNAP_flag == 1 means whatever is in the AAL5 (see  RFC1483)
> >                    if AAL5 Ethertype == 0x86DD then IPv6
> 
> Ah, that's slightly clearer and I understand your previous mails
> better...
> 
> ...but then you wouldn't need the flag, since IPv4 has an Ethertype
> anyway. And if you used the flag this way you'd favour IPv6 rather
> than 4 - since IPv6 has bigger headers and MTU requirements, and
> benefits from the added space resulting from removing the encap.
> 

The EtherType is not carried in the normal MPE header (without LLC).

> ...but there is no mention of AAL5 in EN 301 192. Why would you want
> the additional overhead of AAL5 encapsulation/checksumming etc - and
> when you say 'the standard', which standard are you referring to?
> 

There isn't a reference in the EN to an RFC describing IP over LLC/SNAP!!

> ...but DVB != ATM... going through AAL5 doesn't get you anywhere near
> a decent IP over DVB encapsulation, and afaik DSM-CC doesn't have to
> use AAL5 as the broadcast type.

The EN also doesn't permit a MAC Ether-Type without LLC or 
a MAC source address.  

The latest rev of EN 301 192 that I have seen is V1.1.1 (1997-08) 
In Chapter 7 (Multiprotocol encapsulation) subsection  7.1 
(Data transport specification), this says:

"The semantics of the datagram_section are as follows:
<snip> 

LLC_SNAP_flag: this is a 1-bit flag. 
If this flag is set to "1" the payload carries an LLC/SNAP encapsulated 
datagram following the MAC_address_1 field. The LLC/SNAP structure 
shall indicate the type of the datagram conveyed. If this
flag is set to "0", the section shall contain an IP datagram without 
LLC/SNAP encapsulation."

When the LLC flag is 0, the payload is an "IP datagram",
I don't see anything here which says this is IPv4 ONLY, but the
lack of an Ethertype field suggests this. 

An arp frame could also (potentially) be sent, but this would
have to be encapsulated in LLC.
- But I'm not sure this was anticipated.

> 
> And EN 301 192 (V1.2.1 199-06) talks about IP, not IPv4.

This is a nuisance. The EN appears to only support IPv4 without LLC/SNAP,
but this is NEVER explicitly stated. Indeed it didn't differentiate IPv4
or IPv6. There isn't even a ref to an IP RFC!!!!

> 
> still puzzled,
> 
> L.
> 
> <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>