Re: Adaptation field - what is it for?

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

Abigail,

I'll try to rpovide some background to your questions....

First a little context, ISO/IEC 13818-1 defines two ways of padding
variable sized 
IP packets to fixed sized TSA Packet payloads. ETSI TR 101 202 & EN 301
192 (that
define MPE, etc) seem to allow both options. The "Simple" encapsulation currently
seems to allow both options, and this is probably the source of the confusion.

I think we need to get answers to the question, but before we debate the meaning
of bits, it would be good to identify whether we need this approach, and
what it
would be used for.

************

The question I have is to all on the list:

Do you see a need for an encapsulation that will allow for an
adapatation field?

(1) If so - what is the application, and what (adaptation) headers do
you expect to use?

(2) Also if an adaption field is used, would it be wiser to use only the
adaption field
for padding (alignment of the end of a Subnetwork PDU,  i.e.IP packet)
to the end
of the last byte of a TS Packet.

(3) Is there a need for EVERY SNDU to carry at least a minimal
adapatation field?


Thoughts..... on design, implemenation needs, compatibility with
systems, etc

Gorry


"Surtees, Abigail" wrote:
> 
> Hi Gorry,
> 
> Thanks for your reply.  I have eventually read the two new drafts and the diagrams have clarified things.
> 
> I think the ULE draft is clear but I do still have a couple of questions about the Simple Encapsulation.
> 
> On page 7, under the definitions for the sender of the AFC bits, it states
> 
> '00, and 10, MUST NOT be used for transport of an encapsulated SNDU'
> 
> but then on page 14 it says
> 
> 'In case the SNDU or its final portion exactly fits into one TS Packet no adaptation field (0/00 PUSI/AFC) shall be used.'
> 
> Which of these is correct?
> 
> It is also not quite clear exactly when an adaptation header should be included.
> 
> Page 12 states that 'The TS Packet that carries the last byte of the SNDU MUST carry an adaptation field.'
> 
> This is a clear statement but does not seem to be consistent with the statements on P14 that follow the examples.
> 
> I found it simplest to consider the cases.  Please correct me if I have something wrong.
> 
> PUSI            AFC
> 1               01              first byte of SNDU, no adaptation field so new SNDU                             begins immediately after TS header and the SNDU is                              longer than 184 bytes
>              -------- -------------------------------------
>                 | header | start of SNDU                       |
>                  -------- -------------------------------------
> 
> 0               01              no start or end of SNDU - just 184 bytes of                                     continuation
> 
>              -------- -------------------------------------
>                 | header | continuation of SNDU                |
>                  -------- -------------------------------------
> 
> 1               11              contains both the end of a SNDU and the beginning of                            one as shown in figures 7 and 8
> 
> 0               11              contains the end of an SNDU but no new one (with or                             without padding)
> 
>              -------- -------------------------------------
>                 | header | adap hdr | end of SNDU              |
>                  -------- -------------------------------------
> 
>              -------- -------------------------------------
>                 | header | adap hdr | end of SNDU | padding FF |
>                  -------- -------------------------------------
> 
> However, the statement above about exactly fitting the SNDU in and not sending the adaptation field doesn't agree with this.
> 
> Nor does the statement
> 'When there are no more SNDUs read for encapsulation the TS Packet (0.01 PUSI/AFC) shall be padded with stuffing bytes of value FF'
> 
> Surely there should be an adaptation header because it is the end of an SNDU?
> 
> Am I missing something?
> 
> Another thought is what happens if there are exactly 184 bytes of SNDU left to go in a packet?
> If no adaptation header is included, then they fit in one packet, the end of the SNDU is in that packet, so an adaptation header should be included.
> However, if the adaptation header is included then the end of the SNDU doesn't fit in the packet and there is no need for the adaptation field.
> 
> Best regards,
> 
> Abbie
> 
> >>
> >> I've just started looking ip-over-dvb and have a question
> >about part of
> >> draft-clausen-ipdvb-enc-00.txt which I hope someone can answer.
> >>
> >> On page 10 there is a table showing the meaning of the PUSI
> >and AFC bits in
> >> the TS packet header, followed by 2 paragraphs of explanation.
> >> The second paragraph says:
> >> "
> >>         The TS Packet that carries the last byte of a SNDU
> >MUST always have
> >>         an adaptation field. In case this was the last SNDU
> >(0/11 PUSI/AFC)
> >>         the TS Packet is filled with stuffing bytes. In case
> >another SNDU
> >>         starts in this TS Packet, another 4-byte adaptation field is
> >>         inserted before the next SNDU. "
> >>
> >> I think this means that the adaptation field is used as
> >stuffing bytes
> >> when there are no more SNDUs, so there will be 184 - x bytes
> >of stuffing
> >> where x is the length of the last part of
> >> the SNDU.  Is this correct?
> >
> >Yes, the adaption field could also be used as a part of the
> >framing, to tell
> >the receiver that an MPEG-2 TS Packet contains the start of a
> >new SNDU. If
> >the receiver happens to loose synch this is how it resynchs.
> >
> >>
> >> If there is another SNDU does 'another 4-byte adaptation
> >field' mean the
> >> one that is always carried or another one on top of that?
> >In other words, do you get
> >>   ________________ ____________ ______________
> >>   ... end of SNDU | adap field | next SNDU ...
> >>   ________________ ____________ ______________
> >>
> >> or
> >>   ________________ ____________ ____________ _____________
> >>   ... end of SNDU | adap field | adap field | next SNDU...
> >>   ________________ ____________ ____________ _____________
> >>
> >> ?
> >
> >Well, neither really.  The adpoation field comes directly after the
> >MPEG-2 TS Packet
> >header. So, Bernhard has drawn some diagrams in the latest version of
> >this draft,
> >to try and get things clearer.
> >
> >
> >
> >The new rev of the draft will hopefully be clearer, but I'd still like
> >you to follow
> >up on your question and reply, if it applies also to the new rev of the
> >draft (-01).
> >
> >Gorry
> >
> 
> --
> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments is confidential to
> Roke Manor Research Ltd and must not be passed to any third party without
> permission. This communication is for information only and shall not create or
> change any contractual relationship.