Subject: Re: Proposed changes to MPLS CW in arch draft

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 03 Apr 2003 11:20:57 -0500

Stewart,
I suggest to keep the specific OAM identification to a separate PW-OAM document.
There will be more than one type of OAM message we want a PE to identify. All
what I heard so far, was for the core routers to be able to distinguish between
a IPv4, IPv6, and the rest of the traffic. The OAM identification has no impact
on the core routers.

Regards,
Mustapha.
----------
Stewart Bryant wrote:

> 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
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 03 Apr 2003 13:01:50 -0500

Stewart,
It looks like only the SONET control word may have an issue with the
IP payload aliasing. The 1:1 and PDU encapsulations in the ATM draft
do not make use of the length field and the first byte following the
bottom label is always set to all zeros. I spoke to Matthew and Luca
and they are going to update the draft.

So, I really do not see the justification for a MPLS Payload
Identifier. We should ask the authors of the SONET draft come with a
proposal on how to fix the SONET encapsulation. Furthermore, the
control word is optional and I cannot see how we can have a Payload
Identifier in an optional field. This clearly does not address the
stated issue of IP aliasing.

If we really want to resolve the issue of payload identification
once for all, I would second Andy's suggestion to look into the
proposed multiprotocol encapsulation draft,
draft-moreels-multiproto-mpls-00.txt. 

Regards,
Mustapha.
---------