The MPLS WG Archive

[Alia Atlas <aatlas@avici.com>]

How does requiring a PID in the PWE3 L2 control word solve or handle the 
case where a control word is not mandatory?

There are pseudo-wires, such as ethernet, where a control word is not 
mandatory.  This would imply that the first nibble (which would be 
identified as the suggested PID) would be that from the ethernet frame.

Alia

At 01:53 PM 3/25/2003 -0700, Danny McPherson wrote:

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