Subject: Re: MPLS PID

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 25 Mar 2003 01:18:14 -0500

I would just like to second Ron's questions below, and also add that 
there's no mention of the need for a protocol identification field in the 
PWE3 requirements draft.

Also, I noticed that the architecture draft had no recognition of the TDM 
control word format; it only discussed the control word used for L2 
encapsulations.

So, I would like to request the following change in 
draft-ietf-pwe3-arch-02.txt:

5.4.3. PW over MPLS Generic Control Word

    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-TDM 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   RSVD/Flags  |FRG|  Length   | Sequence Number               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 12 - MPLS Generic Control Word

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

        RSVD/Flags (bits 0 to 7):
            These bits are available for per payload signaling. Their
            definition is encapsulation specific.  If not all of the bits
            are required for flags, some may be reserved for future use.

        FRG (bits 8 and 9):
            These bits are used when fragmenting a PW payload. Their use
            is defined in [FRAG].

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

For TDM applications, it must use the following general forms.

Non-extended form:
     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 form:
     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       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Structure Pointer[0:12]: If used, the Structure Pointer contains the
    offset of the first byte of the payload structure.  Note that some
    TDM encapsulations do not require the use of a Structure Pointer,
    in which case this field may be reused for other uses.

    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.

Thanks,
Andy

-------

At 3/23/2003 10:04 AM +0200, Ron Cohen wrote:

>Stewart,
>
>I went over your SF arch presentation. I have doubts regarding the
>introduction of a requirement/suggestion for an all zero PID field
>within the PWE3 control word. My doubts relates both to the scope of
>this work as well as for the applications you are describing. Since I
>haven't been to the SF IETF, please forgive me in advance if these
>issues have already been discussed.
>
>
>MPLS PID scope:
>--------------
>In your presentation you describe a requirement/suggestion for an MPLS
>PID, that allows a network node to distinguish between an IPv4, IPv6 and
>PWE3 stream. The Multi-Protocol part of MPLS stands for carrying any
>network protocol on top of MPLS, including possibly IPX, CLNS, etc.
>Therefore, what you are proposing is introduction of an MPLS Protocol
>Identifier, which I believe has a much larger scope than just the PWE3
>WG.
>
>1. Would you agree that this is an MPLS WG item? Has this requirement
>(MPLS PID) been discussed in the MPLS WG before / are there any drafts
>written?
>
>2. If so, would 4 bits suffice for an MPLS PID?
>
>
>Applications:
>------------
>You list a number of applications that require IP flow recognition,
>including load balancing, billing, and protection against network abuse
>and attacks. I would like to better understand if these applications
>indeed require the introduction of the PID field. For example, are these
>applications edge applications? Do these applications run on all LSPs,
>or are sensitive to BE LSP vs. LSP with priority? Do you run these
>applications on TE paths?
>
>1. Are there any drafts that describe these applications?
>
>2. If not, could you elaborate on each application, its scope, etc?
>
>
>Thanks
>Ron
>
>Ron Cohen
>CTO
>Lycium Networks
>Desk: +972 9 7619004
>Mobile: +972 55 245104
>Fax: +972 9 7619022
>
>
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Mar 2003 11:08:24 +0000

Ron

> issues have already been discussed.

All this is correct, and the failure to include an MPLS PID was an
error that is apparent now that the IETF is standardizing payloads
other than IP over MPLS.

> (MPLS PID) been discussed in the MPLS WG before / are there any drafts

George notes that the MPLS WG has discussed this in the past, and rejected
the idea. However this appears to be a mistake.

> 2. If so, would 4 bits suffice for an MPLS PID?

Four bits is a compromise, that would probably work. We are stuck with
a situation where we have IPv4 and IPv6 carried directly in MPLS, so
the minimum is to just exclude from the first nibble of the MPLS payload
values that would alias with those payloads. To allow any MPLS payload
value other than 4 or 6 in the first nibble is messy and does not allow
us (the IETF) scope for future work.

After the meeting is was suggested that the right way forward would be
to use the term version

as in :

" Version:  4 bits

     "The Version field indicates the format of the internet header.  This
     "document describes version 4."

(RFC 791)

and

" Version              4-bit Internet Protocol version number = 6."

(RFC 1883)

Reclaiming version 0 allows us to co-exist with IP over MPLS, whilst
minimizing the amount of rework. How the other 13 values are
allocated is indeed an IANA issue, although there is a case for
reclaiming a further value for OAM. When we have used the
first 14, then we can use the last value as a version extension
identifier.

> indeed require the introduction of the PID field. 

There are no drafts that I am aware that call out this requirement, but
there are drafts that call out the need to analyze IP packets in the
network (i.e. the output of the ipfix and psamp WG). It seems unlikely
that these functions would not be required to operate correctly in an
MPLS network, but to do so they need to know the packet type.

The provision of flow based load balancing is a vendor feature that
is found in MPLS networks, that will missorder PWE3 flows without
appropriate payload type identification.

> For example, are these applications edge applications? 

Netflow is in the core routers of at least two vendors.

> Do these applications run on all LSPs,

As far as I know they run on all LSPs.

> 1. Are there any drafts that describe these applications? 

The drafts that I have seen assume that the router knows that it has
an IP packet, and this is the facility that I am keen to preserve.

> 2. If not, could you elaborate on each application, its scope, etc?

In the limit, the situation is that with all IETF payloads defined
to date we have the ability to accurately perform deep packet analysis,
and that this feature is increasingly used. I think that we discard this 
capability at out peril.

Stewart