Subject: RE: MPLS PID

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

Yaakov,

See the other message I just sent regarding protocol identification.

However, that said, your proposed change to the architecture draft wording 
is fine.

Thanks,
Andy

-------

At 3/25/2003 08:51 PM +0200, Yaakov Stein wrote:

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