Subject: Re: MPLS PID

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 25 Mar 2003 21:00:44 +0100

I agree too that the PID issue is more of an MPLS issue in general. As such, the 
I think the MPLS WG should be tasked with defining exactly what the PID looks 
like, and what internode behavior relying on the PID is allowed.

However, the PWE3 architecture cannot ignore this entirely. It is PWE3's direct 
use of MPLS as its own PSN more than anything else that is imposing this 
practical requirement now (though I suppose it has theoretically always been an 
issue), and any definition coming from the MPLS WG would likely be in the form 
of a requirement on any header definition that rides directly adjacent to the 
last MPLS label in a stack. We all know that this would probably look something 
like simply stating that the first four bits MUST be 4 for IPv4, 6 for IPv6, and 
up to IANA and the MPLS WG for future additions. Whether that means handing out 
values form the remaining 14 available under very tight control (at a minimum, 
via an RFC2434 Standards Action and the MPLS WGs blessing), or some other 
extended PID method, should be up to MPLS to ultimately decide and PWE3 to 
adhere to. This would all be done with PWE3's input of course, since there would 
be a lot of overlap in the folks making the decision.

Regarding whether the MPLS WG has discussed this before, Eric Rosen suggested at 
the microphone in SF that it had, but at that time the decision obviously was to 
not include a PID within MPLS. The bottom line is that perhaps we are seeing 
that in hindsight this was an error, and if so this should be openly resolved 
within the MPLS WG.

- Mark

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

---

From: George Swallow <[email-masked]>
Date: Tue, 25 Mar 2003 15:38:44 -0500

> that in hindsight this was an error, and if so this should be openly resolved 

For a few of us is was foresight, but that didn't carry the day.  I
would be most happy to have this discussed in MPLS.

It would seem that there three identified uses for the PID.

1.  Dealing with ECMP behavior
2.  Inband OAM flows
3.  Identifying flows for netmanagement applications.

The first seems fairly straightforward.

Define IPv4 and v6, reserve a few more values for possible future
versions of IP.  Figure out whether there is any ST left in the
world. 

For the second define a single PID for any OAM flow.  It would be
imprudent to had out pair of PIDs to apps that want inband OAM.
Something collecting flow information in the middle of the network
won't be able to identify the inband OAM, but that may be a good thing
as the result will be just counting the data.

The third is a bit tickier.  Given the resolution of (1&2) we'll have a
small number of PID values to play with to use for flow
identification.  What that small set should be needs to be resolved.
I look to operators of networks for input.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Shahriar Rahman <[email-masked]>
Date: Tue, 25 Mar 2003 12:54:05 -0800 (PST)

Hello,
Looking at draft-martini-ppp-hdlc-encap-mpls-00.txt (not sure if there is
a following version of the draft), the following sections-

4.1. HDLC

   HDLC mode provides port to port transport of HDLC encapsulated
   traffic. The HDLC PDU is transported in its entirety, including the
   HDLC address, control and protocol fields, but excluding HDLC flags
   and the FCS. ....

4.2. PPP

   PPP mode provides point to point transport of PPP encapsulated
   traffic, as specified in [3]. The PPP PDU is transported in its
   entirety, including the protocol field (whether compressed using PFC
   or not), but excluding any media-specific framing information, such
   as HDLC address and control fields or FCS.  ....

It occured to me why in one case HDLC address and control fields are
transported and in the other they are not. It wasn't obvious to me.

_thanks for any explanation.
regards_
Shahriar

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

---

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

W. Mark Townsley wrote:
> 
> I agree too that the PID issue is more of an MPLS issue in general. As 
> such, the I think the MPLS WG should be tasked with defining exactly 
> what the PID looks like, and what internode behavior relying on the PID 
> is allowed.

Yes, they should. Indeed if we continue as we were, and ignore the
requirement we risk it coming in from left field much later and
causing us to restart.

> 
> However, the PWE3 architecture cannot ignore this entirely. It is PWE3's 
> direct use of MPLS as its own PSN more than anything else that is 
> imposing this practical requirement now (though I suppose it has 
> theoretically always been an issue), and any definition coming from the 
> MPLS WG would likely be in the form of a requirement on any header 
> definition that rides directly adjacent to the last MPLS label in a 
> stack. 

Agreed.

> We all know that this would probably look something like simply 
> stating that the first four bits MUST be 4 for IPv4, 6 for IPv6, and up 
> to IANA and the MPLS WG for future additions. Whether that means handing 
> out values form the remaining 14 available under very tight control (at 
> a minimum, via an RFC2434 Standards Action and the MPLS WGs blessing), 
> or some other extended PID method, should be up to MPLS to ultimately 
> decide and PWE3 to adhere to. 

Agreed.

> This would all be done with PWE3's input 
> of course, since there would be a lot of overlap in the folks making the 
> decision.
> 
> Regarding whether the MPLS WG has discussed this before, Eric Rosen 
> suggested at the microphone in SF that it had, but at that time the 
> decision obviously was to not include a PID within MPLS. The bottom line 
> is that perhaps we are seeing that in hindsight this was an error, and 
> if so this should be openly resolved within the MPLS WG.
> 

Agreed.

>> TDM control word format; it only discussed the control word used for 
>> L2 encapsulations.
>>

---

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

> the PWE3 requirements draft.

OK, so we need to add the requirement.

>    following form for non-TDM encapsulations:

This is too soft. At a minimum we need to exclude value 4 and 6 in the
first nibble. However I don't think that PWE3 has the right to hog
all of the rest.

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

It seems OK to use the length for other objects such as structure
pointer and to change the size of the SN, but I don't see how you
can hog all the potential PID/version values. Also you don't
explicitly exclude first nibble 4 and 6.

How about the following:

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

<snip>

Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 26 Mar 2003 08:18:32 -0500

Stewart,

You seem fixated on only being able to identify IPv4, IPv6, and general 
PWE3 (without being able to further identify the packet contents).  The 
reason why is really beyond me.  And as Alia very rightly pointed out, your 
protocol identification is impossible without always requiring the control 
word - otherwise, are you going to mandate that Ethernet frames cannot use 
the values 4 or 6 in the upper nibble?  I think not ....

As I said in a previous email, if you REALLY want to be able to identify 
the contents of an MPLS packet, then ask the MPLS WG to put a REAL 
multiprotocol identifier, a la RFC 2427 or 2684, between the labels and the 
payload (where the payload in this case would be the PWE3 encapsulation). 
See, for example, draft-moreels-multiproto-mpls-00.txt for a much more 
general (and useful) method than just a four-bit hack that you can't use in 
all cases anyway.

Cheers,
Andy

-------

At 3/26/2003 11:20 AM +0000, Stewart Bryant wrote:

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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Mar 2003 14:12:58 +0000

Andrew G. Malis wrote:
> PWE3 (without being able to further identify the packet contents).  

That is the base-line, i.e. IP over MPLS remains unchanged and continues
to work.

My proposal was the minimum necessary that leaves some margin
for future development.

> The 
> reason why is really beyond me.  And as Alia very rightly pointed out, 
> your protocol identification is impossible without always requiring the 
> control word - otherwise, are you going to mandate that Ethernet frames 
> cannot use the values 4 or 6 in the upper nibble?  I think not ....

Whatever solution we use, we need some defined field after the bottom
label. Putting the PID in the CW conforms to the MPLS minimalist philosophy
and is consistent with the original design decision not to mandate
the extra 4 bytes needed for a PID. However I am equally happy with
mandating a PID longword and making the whole CW available for PW use.

> multiprotocol identifier, a la RFC 2427 or 2684, between the labels and 
> the payload (where the payload in this case would be the PWE3 
> encapsulation). 

Do these definitions have the property that operation of the existing
IP over MPLS falls out as a default?

> See, for example, draft-moreels-multiproto-mpls-00.txt 
> for a much more general (and useful) method 

This uses LLC/NLPID or LLC/SNAP directly over MPLS. Do these guarantee
never to alias with assigned (and future) IP versions?

In the case of SNAP, the use of 8 bytes seems to fly in the face
of the minimalist approach proposed elsewhere.

 > than just a four-bit hack that you can't use in all cases anyway.

You can always use it if the CW is present, and the alternative is to
always have a 4-byte field containing a PID.

As for the hack, I am OK with any reasonable proposal that is
consistent with the de-facto IP over MPLS NULL PID.

Stewart

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 26 Mar 2003 10:18:11 -0500

At 03:38 PM 3/25/2003 -0500, George Swallow wrote:
> suggested at

         It is a good thing from a counting/flow perspective because
it means that the PW traffic takes the same switching path(s)
as the OAM for that PW that might be used to test the PW.
OTOH, this will not work for tracing; however, there are other
tools that can be used for tracing the PSN already, so this
is not a big issue IMHO.

>I look to operators of networks for input.

         For the last point, wouldn't an option be to just have a
single PID for OAM and then have sub-types follow inside the
packet to identify the apps?  This only requires us to allocate
a single PID for OAM.  This is incidentally, how we have
defined VCCV.

         --Tom

>...George

http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X

---

From: Luca Martini <[email-masked]>
Date: Thu, 27 Mar 2003 17:50:43 -0700

> I look to operators of networks for input.

given that IP has inedeed been very successfull I do not think we need to 
actually differenciate between all these legacy layer2 protocols, as they will 
not become the majority of the internet traffic , as I can see in my crystal 
ball ;-)

I am happy with a simple class that identifies non ip traffic.

ECMP is very important for us , but I would like to point out that it might not 
be important in all network , hence some operators might decide that either 
reordering is not an issue ... or that they have no ECMPs in their network and 
therefore do not require the overhead of a control word.

Luca