Subject: RE: MPLS PID

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 25 Mar 2003 20:51:33 +0200

Andy, 

As you will remember I brought this issue up in Atlanta.

I don't see why TDM should be any different from the other PW types,
and don't see how it obviates the need for IPv4/IPv6/PW identification 
and can afford to use the first nibble for flags.

However, if people really DO think that SONET/SDH is a special case, 
there is still no reason to require the low rate TDM drafts
which do not require the pointer to use the CEP header instead
of the standard PWE3 control word.

So, please amend to 

 <snip>
 When a control word is used, it MUST have the
 following form for non-SONET encapsulations: 
 <snip>
 
If at a later date the WG decides on a TDM draft that indeed
uses the CEP header (e.g. the Johnson draft)
then this could be changed back.

Y(J)S

> -----Original Message-----
> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Tuesday, March 25, 2003 8:59 AM
> To: [email-masked]
> Subject: Re: [PWE3] MPLS PID
> 
> 
> 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
>