The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [PWE3] MPLS PID
Alia Atlas wrote: > How does requiring a PID in the PWE3 L2 control word solve or handle the > case where a control word is not mandatory? > some networks might not care. Lcua > 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 > > >
|
|