Subject: Re: Padding for ATM cell relay in PW

From: Shahriar Rahman <[email-masked]>
Date: Mon, 6 Jan 2003 14:29:29 -0800 (PST)

Hi Eric,
Thanks for the elaborate response. Please read inline....

> > 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.

This is exactly what I was pointing at. My observation is that sending a
non-zero length field will help extracting the L2 packet at the egress
PE device. It doesn't really facilitate detecting padding alone. Another
minor thing is control word is 4 bytes.

one more thing is that there will almost certainly be PW header(s) added,
e.g. MPLS labels, which will make 48 (or 46 for that matter) no longer a
safe number to assume.

> 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.

Agreed, as I explained above.

> 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 ;-)

Hmmmm.... looks like it.

> 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.

I believe so with the correction of 4 bytes control word. The PW header
can be ignored for all practical purposes as it may be variable. For
example, we may not know how may labels (in MPLS case) could always be
there to traverse the PW.

regards,
Shahriar

---

From: "Peter Reed" <[email-masked]>
Date: Mon, 6 Jan 2003 15:26:06 -0800

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

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3