Subject: Padding for ATM cell relay in PW

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

Hi,
I'm trying to understand padding and usage of the length field of ATM
control word in PWE3. The original(and the subsequent drafts) specify
that-

  "The next 6 bits provide a length field, which is used as follows: If
   the packet's length (defined as the length of the layer 2 payload
   plus the length of the control word) is less than 64 bytes, the
   length field MUST be set to the packet's length. Otherwise the length
   field MUST be set to zero. The value of the length field, if non-
   zero, can be used to remove any padding. When the packet reaches the
   service provider's egress router, it may be desirable to remove the
   padding before forwarding the packet."

in Section "3.1. The Control Word" of
draft-martini-l2circuit-encap-mpls-04.txt. Now, an ATM cell is 52B
(without HEC), adding control word makes it 56B, which is still under 64B.
This means, logically, I would populate the length field in control word
on the ingress LSR. I would then use this value to remove any padding
added by the PW on the egress LSR.

I'm trying to find some scenario when PW will be adding padding. The
drafts give Ethernet as an example. However, adding 14B of Ethernet header
would mean the L2-header + Control word + Payload would make it more than
64B, which is the minimum frame size for Ethernet (plus the labels for
MPLS). 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? Is there any
mechanism to detect whether any padding has really been added by the PW?
Or may be there is something I'm missing here.

What could be an example scenario where the control word will have a
positive 'length' value and padding would be added by PW in cell relay?

Finally, if we assume that there are scenarios where padding is definitely
added by the PW, how can we detect that at the egress LSR when there is
no control word (since it is optional for cell mode AToM)?

Thanks & regards,
Shahriar

=================================================================
Shahriar Rahman                             ||        ||
Software Engineer                          ||||      ||||
c7600 Toaster Development              ..:||||||:..:||||||:..
(408) 525 1351                        ------------------------

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 6 Jan 2003 20:57:56 +0200

Shahriar and all,
Several comments to your message:
1. In the "general" case, the ingress PE should not take into 
   account either the L2-specific header size or the transport
   header size (which may change, e.g., if you use a transport LSP 
   with PHP) for filling the Length field in the CW (because changes 
   from hop to hop), and padding may occur at any hop. 
   Hence, formally speaking, a packet containing just one cell should
   carry the payload Length (52) in its Length field.
2. However, it is worth noting that, in case of ATM cell relay, 
   the packet payload size can only change by steps of 52 (or 49 
   in alternative encapsulation modes). 
   In other words, IMHO, as long as padding occurs only 
   for packets that do not exceed 64 bytes, you can always know 
   how many ATM cells your packet contains without referring to the Length
   field - even if the packet has been padded in transit. And of course,
   if we ever encounter a L2 that pads larger packets (say, less than 128
   bytes), the Length field in the Martini CW will not work either.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Shahriar Rahman [mailto:[email-masked]]
> Sent: Monday, January 06, 2003 8:22 PM
> To: [email-masked]
> Subject: [PWE3] Padding for ATM cell relay in PW
> 
> 
> 
> Hi,
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

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

Agreed. But it is part of the frame that goes out on the wire in an
Ethernet network. And the requirement is to be this number (the entire
frame) to be 64B or greater.

thanks,
Shahriar

On Mon, 6 Jan 2003, Lloyd Wood wrote:

> On Mon, 6 Jan 2003, Shahriar Rahman wrote:
>
>                  ^^^^^^^^^
> The L2 header is not part of the L2 payload.
>
> L.
>
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 06 Jan 2003 15:13:51 -0500

> However, adding 14B of Ethernet  header would mean the L2-header + Control
> word +  Payload would make  it more than  64B, which is the  minimum frame
> size for  Ethernet (plus the labels  for MPLS). So, I  conclude that there
> was no padding even though the control word length field is non-zero.

If it  is not necessary to  add padding when transmitting  on ethernet, then
the control word's  length field should be  set to zero.  It is  an error if
the  documents state  otherwise.  In  particular,  I think  the length  word
should be zero in ATM cell mode, since, as you point out, if you're carrying
an entire ATM cell you won't have to add any padding for ethernet.

---

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

Hi Eric,
My concern was regarding the fact that control word's length field
contains the L2 payload + control word length. However, in several cases,
padding is added to a frame if the entire frame going out on the wire
doesn't meet the minimum requirement imposed by the network in question.
Ethernet for example. This implies that you would have to compare the
packet length with control word's length field on egress LSR in order to
detect if any padding has been added.

In ATM cell mode, if the length field should be zero when the entire ATM
cell is carried in a single frame and the network is Ethernet, then that
means you would have to unconditionally make is zero in cell mode ATM
when this condition is detected. I don't think the 'spec' states this
explicitly as I see cell mode ATM as a special case for control word
length field when compared to the frame mode ATM or frame relay.

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.

regards,
Shahriar

---

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

Hi Sasha,
Please read inline...

>    carry the payload Length (52) in its Length field.

This contradicts with Eric's response. If padding occurs in any
intermediate hop on the PW, it shouldn't be reflected in the CW length
field. This field should be touched by ingress and egress edge devices
only. Though you are right to say that L2 header should not be included in
the length field (and the spec makes it clear), control word length should
be included since it is carried across the PW. Hence, the length field
could contain 56 according to the spec. However, as Eric pointed out, I
think single ATM cell mode is a special case and it should be stated
explicitly in the draft.

Currently, draft-martini-frame-encap-mpls-01.txt describes the padding
procedure in detail.

>    bytes), the Length field in the Martini CW will not work either.

For multiple cells, the length field will certainly be zero. So, I don't
see any need to use this for that case. Is there any L2 network that pads
128B or less packets?

regards,
Shahriar

---

From: Eric Rosen <[email-masked]>
Date: Mon, 06 Jan 2003 16:12:02 -0500

> (L2 payload + control word length < 64B) && (padding is added) would

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.

---

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

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