Re: Encspulation Methods : Some questions.

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

On 16/7/03 11:14 am, "alain.ritoux@6wind.com" <alain.ritoux@6wind.com>
wrote:

> Hi all,
> 
> 1) Precision about byte ordering
> About the encapsulation methods (both), a precision should be
> added in the SNDU format, about byte order telling that :
>  - length is in network order
>  - type is in network order
> network order being MSB first, hence a 1000 bytes IPv4 packet
> encapsulation would begin with :
>  0x03 0xE8 0x08 0x00 0x45 ...

Yes, good point, we need to add this in the next revision.

> 2) The length field itself
> In description of IPv4/v6 SNDU it is said
> "the payload shall be a complete IPv4 datagram"
> My understanding (correct me if I'm wrong) is that it can be IPv4/v6
> fragments, not necesseraly re-assembled IP datagrams, for it would
> introduce :
> - latency
> - work on both sides (re-ass in the sending, and frag on the
>   recv side before IP processing)
> 
> So, indeed IP packet may be up to 64Ko, BUT IP provides fragmentation
> and it will be IP fragments that will flow through the DVB-link, so
> what should be decided is what is the optimal MTU value for the DVB
> link. Maybe something like 1500 (a-la ethernet), or 4096 ??
> 
> In such case Length field could be limited to 12 bits (leaving 4
> more bits for any other stuff)

I meant that an IP Packet should be read the same as IP Datagram. See,
draft-ietf-pilc-link-design-13.txt

  "IPv4 packets (datagrams) vary in size from 20 bytes (the size of the
   IPv4 header alone) to a maximum of 65535 bytes. Subnetworks need not
   support maximum-sized (64KB) IP packets, as IP provides a scheme that
   breaks packets that are too large for a given subnetwork into
   fragments that travel as independent IP packets and are reassembled
   at the destination. The maximum packet size supported by a subnetwork
   is known as its Maximum Transmission Unit (MTU)."

Why do you want a small MTU?

> 
> 3) The CRC
> 
> Where is the exact CRC-32 defined ?
>

We will need to specify this in a later revision, I assumed the Ethernet
CRC-32.

> 
> More over, is tehr some CR/whatever mechansim at TS(or below) level,
> ensuring that TS frames are OK ?

Which part of MPEG-2 TS do you mean?

> If yes, then is raly a CRC needed in
> the encapsulation, for IP checksum will be check by end user, and so
> maybe we don't need extr checks (and overhead), in the same p^hilosophy
> that lead the IPv6 header to not have checksum anymore.
> 

Arguably a design mistake.

IPv6 REQUIRES a strong link checksum. For discussion, see
draft-ietf-pilc-link-design-13.txt


> 
> Thanks for all
> Regards.
> 
> Alain.

gorry