Re: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt

["Kearney" <clausen@cosy.sbg.ac.at>]

From: "Patrick Cipiere" <Patrick.Cipiere@udcast.com>
Sent: Wednesday, April 24, 2002 5:20 AM
Subject: Re: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt


> I am pretty much OK with what is said about the packing, but today,
> the mpeg2 transport packets I am dealing with, do not use the
> adaptation field, but just use the first byte of the transport packet
> payload as an offset if PUSI bit is 1.
> Of course doing this, breaks the 32 bits alignment.
> If we think we need to respect this alignment, having this offset == 3
> might do the job.
> I am not sure we have to use the 32 bits AFC in all cases.
> If saving bits is the goal, let's keep a single byte offset.
>
This is an important point. If you look at my draft - I had indicated that
using the standard adaptation field format of four bytes might be required
due to compatibility with the MPEG-2 standard.  I have looked very carefully
at the 13818-1 document but nowhere could I find an indication of how the
AFC bits have to be treated or can be treated for "private data". Tables
2.2, 2.5  and 2.6 of this document seem to require that the syntax of the
adaptation field be adhered to - and this would mean we have to insert all 4
bytes. If this is NOT the case, we are free to make a different choice.
Looking at 2.4.3.5 - where the semantics for adaptation fields used in PES
packets is defined one could interpret this as allowing to override the
4-byte form - how else would you carry 2 or 3 padding bytes ?  And a little
later (several paragraphs below table 2.6) is a remark saying if the
transport_private_data_flag is set, the rest of the adaptation field is
private data; one byte with the length (possibly ==0) and then ...?

WE REALLY NEED TO GET AN ANSWER FROM THE PEOPLE WHO "OWN" MPEG-2 AND CAN
TELL US WHETHER IT IS OK FOR "PRIVATE DATA" to make use of the AFC bits and
the adaptation field in a different way i.e. in a way which deviates from
Table 2.2, 25 and Table 2.6. Ssure, you can always do this inside a
"private" network but when you have to interoperate with other equipment you
might run into serious incompatibilities. For example, TS packets with
AFC=="00" shall be discarded by standard decoders - what will they do if
they get a TS packet which can not be parsed according to 2.2, 2.5 and 2.6 -
will they trop the packet or forward it?

Is there anybody reading this list who can help???


> I have a lot of concerns about the lack of layer 2 adresses in the new
> design.
> I think there are a lot of situations where we need layer 2 MAC
> addresses in the datagram:
> Without layer 2 destination address, the filtering has to be done at
> layer 3.
> Without layer 2 destination address, what will be the behaviour of a
> router receiving a layer 3 packet.
> Without layer 2 source address, how do we recognize our own datagrams,
> when we get them back on the link several ms after sending them.
> ...
I agree with you but I have on purpose left an address field out of the
encapsulation, assuming that it will follow inside as a part of the
encapsulated structure. Of course this address will have to be bound to an
IP address (in case we carry an IP datagram) on the one side and then it
will have to be mapped to a PID on the other side.
In a way similar to PPP which also leaves this open and there are standards
for doing PPP over ATM or PPP over SDH/Sonet. I am still convinced that for
an MPEG-2 system it is better to assume flow "labels" instead of datagram
addresses.

>
> If we are really convinced that in some cases either the destination
> and/or source MAC address are uneeded, and if the goal is to save some
> bits not having them, we could use 2 bits out of the length field
> The length field would then be 14 bits ([0,16383])
> MAC_FLAG
>
> 00 : no dst MAC, no src MAC
> 01 : dst MAC, no src MAC
> 10 : src MAC, no dst MAC
> 11 : dst MAC, src MAC
>
> MAC is IEEE 48 bits
> no dst MAC is equivalent to a broadcast: ff:ff:ff:ff:ff:ff
>
I do believe that you need a link-level "address/label" but it is NOT your
typical IEEE MAC address. MAC addresses are globally unique identifiers
carrying, for example 3 bytes of "manufacturer prefix" and the 3 bytes of a
manufacturer assigned serial number. Binding an IP address to an Ethernet
address is done by an ARP and the frame carries both address field = 32 + 48
bits; but you couild also bind a 32-bit address to any other "label" and the
label could have >32 bits (e.g. IPv6 addresses), ==32 bits (not very
sensible) or <32 bits. In that latter case you ought to know how many IP
addresses your network will maximally use in order to find out how long your
"label" should be.

If we carry IP datagrams we have in that packet the source and the
destination address; if we consider the MPEG-2 system a subnetwork, we can
look at it as either a connectionless network in which case we would have to
carry a source and a destination local address (taking Ethernet MAC
addresses for this is not very efficient) or we look at it as a connection
oriented network in which case we could use a single connection_ID - and the
PID could be a subfield of this.
Thte length of this field depends on your requirements: if you feel that
65000 individual stations AND/OR multicast groups are sufficient, then 16
bits are enough. And remenber, for satellites this applies for one footprint
only.


> +--+--------------+----------------+----------
> |00|    length    |      type      |Payload
> +--+--------------+----------------+----------
>
> +--+--------------+----------------+-----------  --+----------
> |01|    length    |      type      |48 bits dst ~  | Paylaod
> +--+--------------+----------------+-----------  --+----------
>
> +--+--------------+----------------+-----------  --+----------
> |10|    length    |      type      |48 bits src  ~ | Paylaod
> +--+--------------+----------------+-----------  --+----------
>
>
--+--------------+----------------+-----------  --+-----------  --+---------
> |11|    length    |      type      |48 bits dst ~  |48 bits src ~
|Payload
>
--+--------------+----------------+-----------  --+-----------  --+---------
>
>
> Patrick.

If you want to do on-board switching of TS packets, then, of course, this
"label" has to be in every cell - as outlined in Ghassane's messages. But
this is a separate subject - it has more to tdo with the segmentation and
reassembly strategy but the label field must come from "above" i.e. the next
higher layer.

Sorry this got so long but I hope it helps in our discussion.

--Horst