The MPLS WG Archive

[Danny McPherson <danny@tcb.net>]

[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