Subject: [PWE3] Inconsistencies of the field "LENGTH" in the Control Word (CW)

From: Javi <[email-masked]>
Date: Wed, 13 Jan 2010 18:43:11 +0100

I have found some inconsistencies regarding the definition of the field 
"LEN" (6 bits) in the control word:

a) RFC 4553 (SAToP), RFC 5086 (CESoPSN): if length of PW packet (CW + 
RTP header + PW Payload) is:
     * "<  64 octets": then, LEN = "length of PW packet", and padding is 
employed.
     * ">= 64 octets": then, LEN = 0.

b) RFC 5087 (TDMoIP): if length of total packet (PSN header + CW + RTP 
header + PW Payload) is:
     * "<  64 octets": then, LEN = "length of PW packet" (CW + RTP 
header + PW Payload), and padding is employed to meet MTU requirements 
of the PSN.
     * ">= 64 octets": then, LEN = 0.

c) ITU-T Y.1453: if length of IP packet payload (common interworking 
indicators=control word, optional timing information=RTP, payload) is:
     * "<  64 octets": then, LEN = "length of IP packet payload", and 
padding is employed to meet minimum Ethernet packet size (64 octets).
     * ">= 64 octets": then, LEN = 0.

In addition to the discrepancies, I do not share the reason for some 
criteria:

1) The limit of 64 bytes is intended to ensure the minimum frame size 
when PW is transported over a Ethernet path. According to IEEE Std 
802.3-2005, the size of Ethernet header is 18 octets. So, strictly, the 
minimum size of the Ethernet payload must be 46 octets, not 64 octets. I 
agree PW payload must be a integer multiple of 4 octets but, why 64 
octets and not 48, for example?

2) I agree the size of PSN header may not be known by ingress PE (for 
example, a stack of MPLS labels) and, therefore, it is not considered in 
calculating the length of PW packet. However, why is PW Label not 
included?. Indeed, ITU-T Y.1453 indicates "IP packet payload" and the 
UDP header (=PW Label) is part of that IP packet payload.

3) Why length field is used to indicate the length of PW packet, and not 
to directly indicate the padding added?.

I think it would be more logical the next one: if PW Label + CW + RTP 
header + PW Payload is:
     * "<  64 octets" (why not 48?): then, LEN = "padding added to PW 
Payload".
     * ">= 64 octets": then, LEN = 0 (non padding).

Regards,

Javi

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 13 Jan 2010 18:35:57 +0000

Padding is outside the scope of PWE3 and MPLS. It is added by the datalink.

Note that PWE3 does not know what the datalink layer is, so its use of 
the length field is precautionary.

The only reason that padding is discussed in the drafts is to explain 
why these precautions are needed.

I can't remember why we use 64, but it goes all the way back to 
draft-Martini and is consistent across all PW types.

Stewart

Javi wrote:
> I have found some inconsistencies regarding the definition of the 
> field "LEN" (6 bits) in the control word:
>
>     * "<  64 octets": then, LEN = "length of PW packet", and padding 
> is employed.
> 802.3-2005, the size of Ethernet header is 18 octets. So, strictly, 
> the minimum size of the Ethernet payload must be 46 octets, not 64 
> octets. I agree PW payload must be a integer multiple of 4 octets but, 
> why 64 octets and not 48, for example?
>
> example, a stack of MPLS labels) and, therefore, it is not considered 
> in calculating the length of PW packet. However, why is PW Label not 
> 3) Why length field is used to indicate the length of PW packet, and 
> not to directly indicate the padding added?.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 13 Jan 2010 15:26:49 -0500

Javi,

Even though you may only need a 46-octet packet to meet the minimum
Ethernet frame length requirement, as I recall we chose 64 rather than
48 or 46 just because it's easier/more convenient to do the math. You
are right that 48 or 46 could have worked as well. It was just a
design decision at the time.

Cheers,
Andy

On Wed, Jan 13, 2010 at 1:35 PM, Stewart Bryant <[email-masked]> wrote:
> Note that PWE3 does not know what the datalink layer is, so its use of the
> length field is precautionary.
>
> The only reason that padding is discussed in the drafts is to explain why
> these precautions are needed.
>
>> a) RFC 4553 (SAToP), RFC 5086 (CESoPSN): if length of PW packet (CW + RTP
>> header + PW Payload) is:
>>    * "<  64 octets": then, LEN = "length of PW packet" (CW + RTP header +
>> PW Payload), and padding is employed to meet MTU requirements of the PSN.
>> 1) The limit of 64 bytes is intended to ensure the minimum frame size when
>> PW is transported over a Ethernet path. According to IEEE Std 802.3-2005,
>> the size of Ethernet header is 18 octets. So, strictly, the minimum size of
>> the Ethernet payload must be 46 octets, not 64 octets. I agree PW payload
>> must be a integer multiple of 4 octets but, why 64 octets and not 48, for
>> example?
>>
>> calculating the length of PW packet. However, why is PW Label not included?.
>> Indeed, ITU-T Y.1453 indicates "IP packet payload" and the UDP header (=PW
>> Label) is part of that IP packet payload.
>>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 13 Jan 2010 22:47:57 +0200

Javi,
Andy has already explained the considerations resulting in the design decision in the IETF PWE3 WG.
I can only add that that:

 1.  The rules for setting the LEN field are common for all PWs using the "preferred" CW
 2.  The current design has been deployed in the field for several years and has passed multiple interoperability tests, including some public ones. Hence there is no justification for changing it now in a way that is not backward-compatible.

Regards,
      Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi
Sent: Wednesday, January 13, 2010 7:43 PM
To: [email-masked]
Subject: [PWE3] Inconsistencies of the field "LENGTH" in the Control Word (CW)

I have found some inconsistencies regarding the definition of the field "LEN" (6 bits) in the control word:

a) RFC 4553 (SAToP), RFC 5086 (CESoPSN): if length of PW packet (CW + RTP header + PW Payload) is:
    * "<  64 octets": then, LEN = "length of PW packet", and padding is employed.
    * ">= 64 octets": then, LEN = 0.

b) RFC 5087 (TDMoIP): if length of total packet (PSN header + CW + RTP header + PW Payload) is:
    * "<  64 octets": then, LEN = "length of PW packet" (CW + RTP header + PW Payload), and padding is employed to meet MTU requirements of the PSN.
    * ">= 64 octets": then, LEN = 0.

c) ITU-T Y.1453: if length of IP packet payload (common interworking indicators=control word, optional timing information=RTP, payload) is:
    * "<  64 octets": then, LEN = "length of IP packet payload", and padding is employed to meet minimum Ethernet packet size (64 octets).
    * ">= 64 octets": then, LEN = 0.

In addition to the discrepancies, I do not share the reason for some criteria:

1) The limit of 64 bytes is intended to ensure the minimum frame size when PW is transported over a Ethernet path. According to IEEE Std 802.3-2005, the size of Ethernet header is 18 octets. So, strictly, the minimum size of the Ethernet payload must be 46 octets, not 64 octets. I agree PW payload must be a integer multiple of 4 octets but, why 64 octets and not 48, for example?

2) I agree the size of PSN header may not be known by ingress PE (for example, a stack of MPLS labels) and, therefore, it is not considered in calculating the length of PW packet. However, why is PW Label not included?. Indeed, ITU-T Y.1453 indicates "IP packet payload" and the UDP header (=PW Label) is part of that IP packet payload.

3) Why length field is used to indicate the length of PW packet, and not to directly indicate the padding added?.

I think it would be more logical the next one: if PW Label + CW + RTP header + PW Payload is:
    * "<  64 octets" (why not 48?): then, LEN = "padding added to PW Payload".
    * ">= 64 octets": then, LEN = 0 (non padding).

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Thu, 14 Jan 2010 10:46:07 +0100

Alexander and Andrew,

I agree not to change now the value of 64 bytes. However, choosing 64 
instead of 48, although it is easier/more convenient to do the math, 
also it is less efficient (it requires adding padding in circumstances 
where it is not necessary).

Besides, what do you think about other matters?:

1) Discrepancies between RFC 4553 (SAToP)/RFC 5086 (CESoPSN) and RFC 
5087 (TDMoIP).

2) I agree the size of PSN header may not be known by ingress PE (for 
example, with a stack of MPLS labels) and, therefore, it is not 
considered in calculating the length of PW packet. However, why is PW 
Label not included?. Indeed, ITU-T Y.1453 indicates "IP packet payload" 
and the UDP header (=PW Label) is part of that IP packet payload.

3) Why does this length field indicate the length of PW packet, and not 
directly the padding added?.

I think it would be more logical the next one: if PW Label + CW + RTP 
header + PW Payload is:
     * "<  64 octets": then, LEN = "padding added to PW Payload".
     * ">= 64 octets": then, LEN = 0 (non padding).

Regards,

Javi

El 13/01/2010 21:47, Alexander Vainshtein escribió:
>    2. The current design has been deployed in the field for several
>       years and has passed multiple interoperability tests, including
>       some public ones. Hence /there is no justification for changing
>       it now in a way that is not backward-compatible./
>
> Regards,
>       Sasha
>
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Javi
>     *Sent:* Wednesday, January 13, 2010 7:43 PM
>     *To:* [email-masked]
>     *Subject:* [PWE3] Inconsistencies of the field "LENGTH" in the
>     Control Word (CW)
>
>     header + PW Payload), and padding is employed to meet MTU
>     requirements of the PSN.
>     c) ITU-T Y.1453: if length of IP packet payload (common
>     interworking indicators=control word, optional timing
>     information=RTP, payload) is:
>         * "<  64 octets": then, LEN = "length of IP packet payload",
>     and padding is employed to meet minimum Ethernet packet size (64
>     octets).
>     1) The limit of 64 bytes is intended to ensure the minimum frame
>     size when PW is transported over a Ethernet path. According to
>     IEEE Std 802.3-2005, the size of Ethernet header is 18 octets. So,
>     strictly, the minimum size of the Ethernet payload must be 46
>     octets, not 64 octets. I agree PW payload must be a integer
>     multiple of 4 octets but, why 64 octets and not 48, for example?
>
>     2) I agree the size of PSN header may not be known by ingress PE
>     (for example, a stack of MPLS labels) and, therefore, it is not
>     considered in calculating the length of PW packet. However, why is
>     PW Label not included?. Indeed, ITU-T Y.1453 indicates "IP packet
>     payload" and the UDP header (=PW Label) is part of that IP packet
>     payload.
>
>     3) Why length field is used to indicate the length of PW packet,
>     and not to directly indicate the padding added?.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Jan 2010 12:08:28 +0200

Javi,
It seems you've missed Stewart's explanation.
Padding is not added by the PW encapsulation. It is part of the specific data link functionality.
This means  unnecessary padding NEVER will be added.

As for discrepancies between Y.1453 and the standards developed in the PWE3 WG: IMHO and FWIW such discrepancies are the inevitable result of standardizing essentially the same topic in several SDOs in parallel.

Regards,
     Sasha

________________________________
From: Javi [mailto:[email-masked]]
Sent: Thursday, January 14, 2010 11:46 AM
To: [email-masked]
Cc: Alexander Vainshtein; Andrew G. Malis
Subject: Re: [PWE3] Inconsistencies of the field "LENGTH" in the Control Word (CW)

Alexander and Andrew,

I agree not to change now the value of 64 bytes. However, choosing 64 instead of 48, although it is easier/more convenient to do the math, also it is less efficient (it requires adding padding in circumstances where it is not necessary).

1) Discrepancies between RFC 4553 (SAToP)/RFC 5086 (CESoPSN) and RFC 5087 (TDMoIP).

2) I agree the size of PSN header may not be known by ingress PE (for example, with a stack of MPLS labels) and, therefore, it is not considered in calculating the length of PW packet. However, why is PW Label not included?. Indeed, ITU-T Y.1453 indicates "IP packet payload" and the UDP header (=PW Label) is part of that IP packet payload.

3) Why does this length field indicate the length of PW packet, and not directly the padding added?.

Regards,

Javi

Regards,
      Sasha

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Javi
Sent: Wednesday, January 13, 2010 7:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [PWE3] Inconsistencies of the field "LENGTH" in the Control Word (CW)

Regards,

Javi

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Jan 2010 10:51:37 +0000

Javi

See my earlier note on padding.

Javi wrote:
> Label not included?. Indeed, ITU-T Y.1453 indicates "IP packet 
> payload" and the UDP header (=PW Label) is part of that IP packet payload.
>

It was an arbitrary decision - one of many - it works - we live with it.

Stewart

---

From: Javi <[email-masked]>
Date: Thu, 14 Jan 2010 12:35:52 +0100

Javi,
> It seems you've missed Stewart's explanation.
[Javi] I missed it.

Padding is not added by the PW encapsulation. It is part of the specific 
data link functionality. Discrepancies are the inevitable result 
of standardizing essentially the same topic in several SDOs in parallel.

[Javi] Ok.

The rules for setting the LEN field are common for all PWs using the 
"preferred" CW

[Javi] But there is a different:
     * RFC 4553/RFC 5086: if "             CW + RTP header + PW Payload"
     * RFC 5087:          if "PSN header + CW + RTP header + PW Payload"
     is "<  64 octets", then LEN = "CW + RTP header + PW Payload".

     I think that "PSN header" would not be in RFC 5087.

     And, also, I think "PW Label" would be considered in that calculation:
if "PW Label + CW + RTP header + PW Payload" is "<64 octets", then LEN = 
"PW Label + CW + RTP header + PW Payload".

     Why not?

Regards,

Javi

> As for discrepancies between Y.1453 and the standards developed in the 
> PWE3 WG: IMHO and FWIW such discrepancies are the inevitable result 
> of standardizing essentially the same topic in several SDOs in parallel.
> Regards,
>      Sasha
>
>     *From:* Javi [mailto:[email-masked]]
>     *Sent:* Thursday, January 14, 2010 11:46 AM
>     *To:* [email-masked]
>     *Cc:* Alexander Vainshtein; Andrew G. Malis
>     *Subject:* Re: [PWE3] Inconsistencies of the field "LENGTH" in the
>     Control Word (CW)
>
>     Alexander and Andrew,
>
>     I agree not to change now the value of 64 bytes. However, choosing
>     64 instead of 48, although it is easier/more convenient to do the
>     math, also it is less efficient (it requires adding padding in
>     circumstances where it is not necessary).
>
>     (for example, with a stack of MPLS labels) and, therefore, it is
>     not considered in calculating the length of PW packet. However,
>     why is PW Label not included?. Indeed, ITU-T Y.1453 indicates "IP
>     packet payload" and the UDP header (=PW Label) is part of that IP
>     packet payload.
>
>>        2. The current design has been deployed in the field for
>>           several years and has passed multiple interoperability
>>           tests, including some public ones. Hence /there is no
>>           justification for changing it now in a way that is not
>>           backward-compatible./
>>
>>     Regards,
>>           Sasha
>>
>>         *From:* [email-masked] [mailto:[email-masked]]
>>         *On Behalf Of *Javi
>>         *Subject:* [PWE3] Inconsistencies of the field "LENGTH" in
>>         the Control Word (CW)
>>
>>         I have found some inconsistencies regarding the definition of
>>         the field "LEN" (6 bits) in the control word:
>>
>>         a) RFC 4553 (SAToP), RFC 5086 (CESoPSN): if length of PW
>>         packet (CW + RTP header + PW Payload) is:
>>             * "<  64 octets": then, LEN = "length of PW packet" (CW +
>>         RTP header + PW Payload), and padding is employed to meet MTU
>>         requirements of the PSN.
>>             * "<  64 octets": then, LEN = "length of IP packet
>>         payload", and padding is employed to meet minimum Ethernet
>>         packet size (64 octets).
>>         1) The limit of 64 bytes is intended to ensure the minimum
>>         frame size when PW is transported over a Ethernet path.
>>         According to IEEE Std 802.3-2005, the size of Ethernet header
>>         is 18 octets. So, strictly, the minimum size of the Ethernet
>>         payload must be 46 octets, not 64 octets. I agree PW payload
>>         must be a integer multiple of 4 octets but, why 64 octets and
>>         not 48, for example?
>>
>>         2) I agree the size of PSN header may not be known by ingress
>>         PE (for example, a stack of MPLS labels) and, therefore, it
>>         is not considered in calculating the length of PW packet.
>>         However, why is PW Label not included?. Indeed, ITU-T Y.1453
>>         indicates "IP packet payload" and the UDP header (=PW Label)
>>         is part of that IP packet payload.
>>
>>         3) Why length field is used to indicate the length of PW
>>         packet, and not to directly indicate the padding added?.
>>

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 14 Jan 2010 18:25:33 +0200

Javi

The decision tried to avoid counting the precise overhead of the packet headers,
because there are many possibilities before you get to Ethernet (which is where the padding is performed).

For example, you could have a PW with
a CW + a PW label and no MPLS label (PHP'ed or "dry")
a CW + a PW label + a single MPLS label
a CW + a PW label + two MPLS labels
a CW + a PW label + an MPLS label + RFC4023 IP header
a CW + a PW label + an MPLS label + RFC 4023 GRE + IP header
a CW + RTP header + …
no CW + …

And of course the number of MPLS labels and the IP headers can change over the path of the packet.

I think you see why we avoided going into all that,
and why the different drafts/SDOs made different wording choices, but they still all interwork.

Y(J)S

From: Javi [mailto:[email-masked]]
Sent: Thursday, January 14, 2010 13:36
To: [email-masked]
Cc: Alexander Vainshtein; Andrew G. Malis; 'Stewart Bryant'; Yaakov Stein
Subject: Re: [PWE3] Inconsistencies of the field "LENGTH" in the Control Word (CW)

Javi,

Padding is not added by the PW encapsulation. It is part of the specific data link functionality. Discrepancies are the inevitable result of standardizing essentially the same topic in several SDOs in parallel.

[Javi] Ok.

The rules for setting the LEN field are common for all PWs using the "preferred" CW

    And, also, I think "PW Label" would be considered in that calculation:
    if "PW Label + CW + RTP header + PW Payload" is "<64 octets", then LEN = "PW Label + CW + RTP header + PW Payload".

    Why not?

Regards,

Javi

Regards,
     Sasha

Regards,

Javi

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Thu, 14 Jan 2010 18:08:09 +0100

Yaakov,

Please, see inline.

> a CW + a PW label + an MPLS label + RFC 4023 GRE + IP header

[Javi] Should PW label (UDP Port, L2TP Session, MPLS Label, ...) not 
always be present in a PW?. So I think it should have been taken in the 
calculation.
> over the path of the packet.

[Javi] Exactly. Due to this, the size of PSN header may not be known by 
ingress PE. So, I think that RFC 5087 would not include "PSN header" to 
determine the value of the field "length", as do all other RFCs.

Regards,

Javi

> *Sent:* Thursday, January 14, 2010 13:36
> *To:* [email-masked]
> *Cc:* Alexander Vainshtein; Andrew G. Malis; 'Stewart Bryant'; Yaakov 
> Stein
> Padding is not added by the PW encapsulation. It is part of the 
> specific data link functionality. Discrepancies are the inevitable 
> result of standardizing essentially the same topic in several SDOs in 
> parallel.
>
> [Javi] Ok.
>
> if "PW Label + CW + RTP header + PW Payload" is "<64 octets", then LEN 
> = "PW Label + CW + RTP header + PW Payload".
>
>     Why not?
>
> Regards,
>
> Javi
>