The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: [PWE3] MPLS PID

MPLS issue or IP/IANA issue? This is v4 and v6 headers we're discussing.

Similarly I would want to consider what the inherent ability to protocol multiplex traffic on any LSP "means". Previously payload was negotiated via signalling and explicitly fixed for any specific label. Now we'll be into policy as to what PIDs are acceptable. Whereas before we had the simplicity of one label<->one protocol, in the future that will no longer be true.

IMHO we shouldn't rush to codify the ECMP hack.

cheers
Dave

> -----Original Message-----
> From: Danny McPherson [mailto:danny@tcb.net]
> Sent: Tuesday, March 25, 2003 3:53 PM
> To: pwe3@ietf.org; mpls@uu.net
> Subject: Re: [PWE3] MPLS PID
>
>
>
> [Note the cross-post, let's try to move this to MPLS please]
>
> I tend to agree with Mark & George (and others) that it should
> be addressed in the MPLS WG, with feedback from PWE3.
>
> PWE3 Architecture and perhaps Requirements (ugh!) work should be
> added as appropriate, please send your comments on what needs to
> be done there ASAP, if you haven't already.
>
> -danny
>
>
> >
> > 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
> > >> pwe3@ietf.org
> > >> https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> > >
> > > _______________________________________________
> > > pwe3 mailing list
> > > pwe3@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
>
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>