Subject: Proposed changes to MPLS CW in arch draft

From: Stewart Bryant <[email-masked]>
Date: Thu, 03 Apr 2003 14:00:13 +0100

This is the text that I propose for sections 5.4.2, 5.4.3 and the
new 5.4.4 in draft-pwe3-arch-03.txt

In section 5.4.2 the MPLS payload type identifier is shown in the
relation to the PW label and the CW.

In section 5.4.3 the issue of IP packet aliasing is introduced,
and the generic and the SONET CWs are defined. It is noted that
the "Martini" style of CW does not have this aliasing issue.

The new section 5.4.4 includes the MPLS payload type identifier for
reference and shows how IP packets can be multiplexed over the PW
for management purposes.

Stewart

5.4.2. PWE3 over an MPLS PSN

    The MPLS ethos places importance on wire efficiency.  By using a
    control word, some components of the PWE3 protocol layers can be
    compressed to increase this efficiency.

    +---------------------+
    |      Payload        |
    /=====================\
    H Payload Convergence H-----+
    H---------------------H     |
    H       Timing        H------------------------+
    H---------------------H     |                  |
    H     Sequencing      H-----|                  |
    \=====================/     |                  |
    |  PW Demultiplexer   |---+ |                  v
    +---------------------+   | |  +--------------------------------+
    |  PSN Convergence    |-----|  .                                .
    +---------------------+   | |  .              RTP               .
    |        PSN          |-+ | |  |                                |
    +---------------------+ | | |  +--------------------------------+
    |      Data-link      | | | +->| Flags, Frag, Len, Seq #, etc   |
    +---------------------+ | |    +--------------------------------+
    |       Physical      | | |    |    MPLS Payl'd Type Indent     |
    +---------------------+ | |    +--------------------------------+
                            | +--->|           PW Label             |
                            |      +--------------------------------+
                            +----->| Outer Label or MPLS-in-IP encap|
                                   +--------------------------------+

    Figure 11: PWE3 over an MPLS PSN using a control word

    Figure 11 shows the protocol layering for PWE3 over an MPLS PSN.  An
    inner MPLS label is used to provide the PW demultiplexing function.
    A control word is used to carry most of the information needed by the
    PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact
    format.  The flags in the control word provide the necessary payload
    convergence.  A sequence field provides support for both in-order
    payload delivery and (supported by a fragmentation control method) a
    PSN fragmentation service within the PSN Convergence Layer.  Ethernet
    pads all frames to a minimum size of 64 bytes. The MPLS header does
    not include a length indicator. Therefore to allow PWE3 to be carried
    in MPLS to correctly pass over an Ethernet data-link, a length
    correction field is needed in the control word. Where the design of
    the control word would alias an IP packet, an MPLS Payload Type
    Identifier should be interposed between the PW label and the control
    word (see 5.4.4).  As with an IP PSN, where appropriate, timing is
    provided by RTP [RFC1889].

    In some networks it may be necessary to carry PWE3 over MPLS over IP.
    In these circumstances, the PW is encapsulated for carriage over MPLS
    as described in this section, and then a method of carrying MPLS over
    an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the
    resultant PW-PDU.

5.4.3. PW over MPLS Generic Control Word

    To allow accurate packet inspection in an MPLS PSN, and to operate
    correctly over MPLS PSNs that have deployed equal-cost multiple-path
    load-ballancing a PW packet MUST NOT alias an IP packet.  IP packets
    are carried in MPLS label stacks without any protocol identifier.
    Historic values of the IP version number [RFC791] [RFC1881] are
    therefore used to distinguish between IP and non-IP MPLS payloads.

    A PW SHOULD employ either the generic PW control word or an MPLS
    payload type identifier to disambiguate the PW from an IP flow.

    The PW set-up protocol determines whether a particular PW uses a
    control word.  When a control word is used, it MUST have the
    following form for non-SONET encapsulations:

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |0 0 0 0| Flags |FRG|  Length   | Sequence Number               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 12: MPLS Generic Control Word (non-SONET)

    Note that a with packet bits 0..3 = 4 indicates an IPv4 MPLS payload
    and a packet with bits 0..3 = 6 indicates an IPv6 MPLS playload.

    The meaning of the fields of the MPLS Generic Control Word (non-
    SONET) (Figure 12) is as follows:

        Flags (bits 4 to 7):
            These bits are available for per payload signaling.  Their
            definition is encapsulation specific.

        FRG (bits 8 and 9):
            These bits are used when fragmenting a PW payload.  Their use
            is defined in [FRAG].  When the PW is of a type that will never
            need payload fragmentation, these bits may be used as general
            purpose flags.

        Length (bits 10 to 15):
            The length field is used to determine the size of a PW
            payload that might have been padded to the minimum Ethernet
            MAC frame size during its transit across the PSN.  If the
            MPLS payload (defined as the CW + the PW payload + any
            additional PW headers is less than 46 bytes, the length MUST
            be set to the length of the MPLS payload.  If the MPLS
            payload is between 46 bytes and 63 bytes the implementation
            MAY either set to the length to the length of the MPLS
            payload, or it MAY set it to 0.  If the length of the MPLS
            payload is greater than 63 bytes the length MUST be set to 0.

        Sequence number (Bit 16 to 31):
            If the sequence number is not used, it is set to zero by
            the sender and ignored by the receiver.  Otherwise it
            specifies the sequence number of a packet.  A circular list
            of sequence numbers is used.  A sequence number takes a value
            from 1 to 65535 (2**16-1).  If the payload is an OAM packet
            the sequence number MAY be used to mark the position in the
            sequence, in which case it has the same value as the last
            data PDU sent.  The use of the sequence number is optional
            for OAM payloads.

    The PW control word used in SONET applications must use the following
    general forms.

         Non-extended:
          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |0| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Extended:
          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |1| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Additional encapsulation-specific header fields       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 13: MPLS Generic Control Word (SONET)

    The meaning of the fields of the MPLS Generic Control Word (SONET)
    (Figure 13) is as follows:

        Structure Pointer[0:12]:
            If used, the Structure Pointer contains the offset of the
            first byte of the payload structure.

        Sequence Number[0:13]:  This is a packet sequence number, which
            continuously cycles from 0 to 0x3FFF.  It is generated and
            processed in accordance with the rules established in [RFC1889].
            When the RTP header is used, this sequence number MUST match the
            LSBs of the RTP sequence Number.

5.4.4. MPLS Payload Identifier

    Where the PW control word may alias an IP packet (for example the
    MPLS Generic Control Word (SONET)), the control word SHOULD be
    preceeded by an MPLS payload type identifier.

    For reference the MPLS payload type identifier [TBD] is defined as
    follows:

           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
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |0 0 0 1|  reserved             | PPP DLL Protocol Number       |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |           As defined by PPP DLL protocol definition           |
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 14: MPLS Payload Type Identifier

        PPP DLL Protocol Number [16:31]:
            These numbers are assigned by IANA.

    Some PW management messages such as OAM and LSP ping may require IP
    packets to be multiplexed onto the PW. These are carried over the PW
    using the IP MPLS payload type indicator, show in Figure 15:

           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
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |0 0 0 1|  reserved             |  IPv4 = 0x21, or IPv6 = 0x57  |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                IP packet and management payload               |
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 15: MPLS Payload Type Identifier

---

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 4 Apr 2003 21:38:09 +0200

Stewart (and all),
Thank you for presenting the proposed text for review.
This, by itself, is most commendable.

I also have a (hopefully, minor) issue with the proposed text.
Section 5.4.2 explicitly allows presence of an RTP header 
immediately after the PW demutiplexer and, indeed, the SONET 
and (most of) the TDM drafts by default place this header 
in the prescribed position. However, in this case the first 
word of the RTP header is placed exactly where, in all the 
rest of the cases, the PW control word would be. On the other 
hand, Section 5.4.4 opens with words:

<quote>
	Where the PW control word may alias an IP packet... 
<end quote>

So, first of all, the consequent text does not seem to cover the
case when the RTP header is present between the PW demultiplexer
and the PW control word.

Second, it is not clear whether an MPLS payload type identifier
should be inserted between the MPLS PW demultiplexer and RTP header:

a) This header cannot alias an IPv4 or IPv6 packet.
   In fact, its first nibble is always '1000' in all known proposals
   and we may probably enforce that by specifying that, when RTP 
   is used in conjunction with PWs, neither RTP header extensions 
   nor padding can be used. 
b) However, if we rely exclusively on the first nibble of the RTP header
   for not aliasing IP packets, we de-facto reserve one more 4-bit value 
   (8) for the use of PWs. So if we go for this approach, this fact IMO
   should be mentioned in the "IANA Considerations" section of the draft.

Personally I think that it would be quite safe to allow an RTP header 
directly between the MPLS PW demultiplexer (aka VC label) and the PW CW,
and I hope that the WG would accept that.

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: Stewart Bryant [mailto:[email-masked]]
> Sent: Thursday, April 03, 2003 3:00 PM
> To: [email-masked]
> Subject: [PWE3] Proposed changes to MPLS CW in arch draft
> 
> 
> 
> 
>           0                   1                   2           
>         3
>           0                   1                   2           
>         3
>           0                   1                   2           
>         3
>            0                   1                   2          
>          3
>           |                                                   
>             |
>            0                   1                   2          
>          3
>           |                                                   
>             |
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Apr 2003 10:58:37 -0800

Sasha,

Why don't you put RTP header after the CW?

-Shahram

>From: Sasha Vainshtein [mailto:[email-masked]]
>Sent: Friday, April 04, 2003 2:38 PM
>To: [email-masked]'
>Cc: [email-masked]
>Subject: RE: [PWE3] Proposed changes to MPLS CW in arch draft
>
>
>Stewart (and all),

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 6 Apr 2003 16:26:47 +0200

Shahram and all,
I follow the design presented in the Architecture 
draft (Section 5.4.2). IMO, this design complies with
the recommendations of RFC 2736 as required by the PWE3 Charter.

Note also that, if you use IP and UDP as your transport and
demultiplexing, existing infrastructure can compress 
IP/UDP/RTP headers in a very effective way.

With best regards,
                                   Sasha Vainshtein

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Friday, April 04, 2003 8:59 PM
> To: Sasha Vainshtein; [email-masked]'
> Cc: [email-masked]
> >>     |        PSN          |-+ | |  |                       
> >>                             | +--->|           PW Label

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 7 Apr 2003 10:01:05 +0300

> the recommendations of RFC 2736 as required by the PWE3 Charter.

That is beggin the question.

You assumption is that PW is an RTP payload type,
and thus subject to 2736 recommendations.

You could just as easily say that the main type is PW,
and that RTP should fit "inside" the PW protocol.

> IP/UDP/RTP headers in a very effective way.
 
This header "compression" is not yet very widely 
deployed, and some parts are protected by IPR.

Incidentally, as someone who has spent many years
in image, audio, and speech compression,
I find it ridiculous to call these methods "compression".

In any case, no-one was asking about the overhead here, 
merely about the "first nibble" problem.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 7 Apr 2003 10:54:50 +0200

Yaakov and all,
Please see some comments inline.
With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Monday, April 07, 2003 9:01 AM
> To: Sasha Vainshtein; Shahram Davari
> Cc: [email-masked]; [email-masked]
This is not my personal assumption but, rather, an explicit
requirement in the PWE3 WG Charter:

<quote>
  PWE3 will use RTP where necessary to perform clock recovery and
  other real-time signaling functions.  This work will be
  coordinated with the AVT WG and payloads will follow RFC 2736.
<end quote>

If you think that this statement should be out of the WG 
charter, please raise this issue explicitly with the WG 
Chairs and the ADs. 

... snipped to the end ...

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 7 Apr 2003 11:25:12 +0300

> charter, please raise this issue explicitly with the WG 

Although I don't really see the need for RTP
(and as you know almost none of the encapsulation drafts
use it), this was not my point here.

Yes, go ahead and use RTP if you think it is needed
for your payload.

And yes, go ahead and encapsulate your PAYLOAD
according to 2736 ideas (e.g. separately decodable, etc).

But no-where does it say that the PW itself has to be 
encapsulated as an RTP payload.

The difference between the PW and the payload
is precisely the control word, and that is where
the question lies.

Using reductio ad absurdum on your argument, 
you might claim that the charter requires the
MPLS labels to be inside the RTP payload too.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 7 Apr 2003 11:41:54 +0200

Yaakov and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, April 07, 2003 10:25 AM
> To: Sasha Vainshtein
>
... snipped ...
> according to 2736 ideas (e.g. separately decodable, etc).
Please read 2736. It explains what is and what is not part
of the RTP payload. It is only 10 pages long, and very well
written. It is also an IETF Best Current Practice document.
... snipped ...
> is precisely the control word, and that is where
What about PWs that do not use (or, rather, do not mandate)
Control words? Do you claim that they are NOT PWs just
by this fact? And, by the way, please try to use common
terminology (as defined in the Architecture document).
This would probably help to make your objections
more coherent. 
> MPLS labels to be inside the RTP payload too.
I have expected something better from you. Please
re-read the architecture document.

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Apr 2003 07:09:27 -0700

Sasha,

>the recommendations of RFC 2736 as required by the PWE3 Charter.

I don't think so. The Arch draft section 5.4.2 shows the following figure:

   +---------------------+
   |      Payload        |
   /=====================\
   |       Physical      | | +--->|           PW Label             |
   +---------------------+ |      +--------------------------------+

In which RTP is after the control word. In other words the header is:

Outer Label->PW label->Control word-> RTP 

-Shahram