Subject: Length Field def. & Padding for ATM cell relay in PW

From: "Peter Reed" <[email-masked]>
Date: Tue, 7 Jan 2003 07:21:42 -0800

Hi Shahriar:

I didn't answer your email well.

I don't care if the Length Field is 6 or 8-bits long. What I do care about
is consistency in length, bit ordering and use of the fields. It is this
consistency that I was arguing for in my previous email posting, plus some
best practice examples to assist in uniform implementation.

Regards,
Peter Reed

-----Original Message-----
From: Peter Reed [mailto:[email-masked]]
Sent: Monday, January 06, 2003 4:38 PM
To: Shahriar Rahman
Subject: RE: [PWE3] Padding for ATM cell relay in PW

Hi Shahriar:

Totally agree that 6 bits is all that is required.

My concern is how the length field is parsed, since the word is 32-bits long
and contains other fields. I like fields on nibble/octet boundaries - so if
I had a vote I'd say make length 8-bits long, even though the two MSBs will
always be zero. But the Martini drafts already set the 6-bit paradigm.

In draft-ietf-pwe3-atm-encap-00.txt fragmentation is discussed in the AAL5
modes. Below is a cut and paste from page 29 of that document.

<begin>
The AAL5 transparent VCC service is OPTIONAL.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pseudo Wire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Optional Length and Sequence Number        |M|V|Res|Frg|E|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +                             "                                 |
   |                        AAL5 CPCS-PDU                          |
   |                      (n * 48 bytes)                           |
   |                             "                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 10: AAL5 transparent service encapsulation

   The first octet following the Pseudo Wire Header carries control
   information.  The M, V, Res, and C bits are as defined earlier for
   VCC cell mode.

     * Frg (Fragmentation) Bits

       This field is used to support the fragmentation functionality
       described later in this section.
     - 11 Single Segment Message (Beginning and End of Message)
     - 10 Beginning of Message
     - 00 Continuation of Message
     - 01 End of Message

<end>

Cheers,
Peter Reed

-----Original Message-----
From: Shahriar Rahman [mailto:[email-masked]]
Sent: Monday, January 06, 2003 4:17 PM
To: Peter Reed
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] Padding for ATM cell relay in PW

Hi Peter,
Thanks for digging the detailed on various drafts. I would say that the
size of 'length' field in control word is probably none of our concern
given that 6 bits all that is needed to rep < 64B. We were trying get to
the usage of this field for padding removal/stripping.

Regarding the issues you raised, I think the WG is on top of all of them.
I can only comment on the last one. I've not seen any reference regarding
fragmentation in PW drafts. If you've, please let me know where.

regards,
Shahriar

On Mon, 6 Jan 2003, Peter Reed wrote:

> I think a general re-write of the 'Length' field may be in order. In
> "draft-ietf-pwe-atm-encap-0.txt", Section 6.5 it states:
>
> <begin> "The one-octet Length indicates length of the packet payload that
> includes, length of length field, Sequence number length, the ATM specific
> header length and the payload length. ...
>
> If the PW traverses a network link that requires a minimum frame size such
> as Ethernet as a practical example, with a minimum frame size of 64
octets,
> then such links will apply padding to the PW PDU to reach its minimum
> size...." <end>
>
>
>
>
> Issues:
>
> 1) draft-ietf-pwe-atm-encap-0.txt, Section 6.5 states the Length Field is
> one-octet in length not 6 bits, as indicated in
> "draft-ietf-pwe3-protocol-layer-00.txt" and other IETF drafts. Page 6 of
> "draft-ietf-pwe-atm-encap-0.txt" shows the Length field as 6-bits longs,
> which is in conflict with Section 6.5 et al of the same document.
>
> 2) In the "draft-ietf-pwe-atm-encap-00.txt" on page 6 the un-titled
control
> word figure shows the Length Field starting in bit position 10 (consistent
> with draft-ietf-pwe3-protocol-layer-00.txt), while Figures 2, 3, 4, 5, 6,
10
> indicates a different bit ordering. Is the length field 6 or 8 bits in
> length for these modes? What is the ordering (e.g. length/sequence/flag or
> sequence/length/flag)?
>
> 3) Figure 8, draft-ietf-pwe-atm-encap-0.txt, is indeterminate about the
> structure of the control word. Given that this section looks very similar
to
> the Cell Mode description in "draft-martini-l2circuit-encap-mpls-04.txt"
my
> guess is the length field is 6-bits long and the bit ordering is same as
> shown on page 6. But as there are multiple structures of the control word
> shown in this document it would be best to spell this out.
>
> 4) The email thread by authors of the IETF draft conflict with the
> information contained within it, which gives me concern about a consistent
> industry implementation.
>
> 5) P.S. - Another possible occurrence of a non-zero length field is during
> Fragmentation. True?
>
>
> Suggestion: Make the control word and its information elements consistent
> with "draft-ietf-pwe3-protocol-layer-00.txt" across all PWE3
> implementations. And provide examples within this umbrella document on
it's
> proper use and best practices.
>
>
>
> Thanks. :-)
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
> Rosen
> Sent: Monday, January 06, 2003 1:12 PM
> To: Shahriar Rahman
> Cc: [email-masked]
> Subject: Re: [PWE3] Padding for ATM cell relay in PW
>
>
>
> > Perhaps making it explicit that the length field should be non-zero when
> > (L2 payload + control word length < 64B) && (padding is added) would
> > clarify it.
>
> The  problem is  that you  set the  length field  when you  create  the
PWE3
> packet, and  you don't know for sure  whether padding will have  to be
added
> somewhere down the line.   But it's safe to set it to  zero if you know
that
> padding will never have to be  added.  Your observation, I think, is that
it
> is safe  to set it  to zero if  (L2 payload length  >= 48 bytes),  since
two
> bytes of  control word plus a minimum  ethernet header would result  in a
64
> byte ethernet frame, and padding wouldn't be needed.
>
> In any event, when decapsulating,  you can't assume that padding is
present,
> even if  the length  field is  non-zero, but you  don't really  care
whether
> padding is present, you only care about the length of the payload.
>
> Probably the length field should have  been defined as "if the length of
the
> L2 payload is 48 or more bytes,  then 0, else the length of the L2
payload".
> However, the  current definition (which is  really "if the length  of the
L2
> payload is 62 or more bytes, then 0, else 2 + the length of the L2
payload",
> I think) does work.  I think your real question was:
>
> > So, I  conclude that  there was  no padding even  though the  control
word
> > length field  is non-zero. My  question is, what  should egress LSR  do
in
> > this case? Ignore the 'length'  value or still apply pad removal
procedure
> > assuming pad is added when 'length' is non-zero?
>
> If the length field, is non-zero,  it does allow you to correctly deduce
the
> length of  the L2  payload, whether padding  is present  or not, so  I
don't
> think this is an issue.
>
> Note that what I am saying here is slightly different than what I said in
my
> previous message ;-)
>
> Perhaps the length field should be  defined as follows: If the L2 payload
is
> 48 bytes or greater, the length field MAY  be set to 0; if the L2 payload
is
> 62 bytes or greater, the length field MUST be set to 0; otherwise the
length
> field  is set  to  2 plus  the length  of  the L2  payload.  This
preserves
> interoperability with  the Martini docs while  allowing the use of  0 in
ATM
> cell mode.
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>
>
>