The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] DiffServ MPLS over Ethernet (L-LSP vs E-LSP)
Hello, Here's my take on "MPLS Diff-Serv over Ethernet" (includes paraphrasing some of what has been said already): There are indeed different cases to consider: - Two adjacent LSRs are interconnected via a pt-to-pt Ethernet segment. MPLS Diff-Serv works beautifully. You can use preconfigured mapping E-LSPs, Signalled E-LSPs, L-LSPs. LSRs would be doing PHB enforcement (queuing/drop) based on EXP (or EXP+label). 802.1 Q does not really have any role to play in that case and 802.1 Q markings need not be used. - Two adjacent LSRs are interconnected via 802.1Q-capable Ethernet Switch. MPLS Diff-Serv works beautifully. You can use preconfigured mapping E-LSPs, Signalled E-LSPs, L-LSP. LSRs would be doing PHB enforcement (queuing/drop) based on EXP (or EXP+label). LSRs would be doing a PHB-->802.1Q mapping (eg RFC3270 section 3.4.4 and 3.4.5). This mapping has actually nothing to do with MPLS per say (you should be using the same mapping as used when doing non-MPLS Diff-Serv IP over 802.1Q. In general it is desirable to have a configurable mapping because there are less 802.1Q values than potential PHBs, different network may support differnet subset of PHBs, differnet 802.1Q switches may have differnet capabilities (eg 2/4/8 queues),...etc. The Etherent switch is completely unaware of the MPLS-Shim header and of EXP bits and of course does its scheduling/dropping based on 802.1Q values. (note that an ethernet switch which would be running and MPLS control plane, is an LSR so it is covered by the previous case). - Two adjacant LSRs are interconnected via Ethernet switch which is not 802.1Q capable (bought it second-hand, I guess ;^) or the LSR is not capable of doing PHB-->802.1Q mapping. Then, your Diff-Serv is jeopardised (unless you can be sure by capacity planning that you will never see any congestion on an egress port of the LAN switch, of course). Cheers Francois PS: A few clarifications, addressing some comments in the thread: - the Shim header is absolutely always used on Ethernet - DSTE is not the same thing as MPLS Diff-Serv (RFC3270). RFC3270 defines how to support Diff-Serv over MPLS (which are data path mechanisms independent of Path computation). DSTE refers to Diff-Serv-aware MPLS Traffic Engineering (see draft-tewg-diff-te-reqts and draft-tewg-diff-te-proto) which deals with control plane mechansism for Diff-Serv aware Path computation. >> -----Original Message----- >> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] >> Sent: 21 October 2002 22:19 >> To: Sasha Vainshtein >> Cc: 'curtis@fictitious.org'; 'Vishal M'; mpls@UU.NET; Shahram Davari >> Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) >> >> >> >> In message <AF5018AC03D1D411ABB70002A509132678E642@TLV1>, >> Sasha Vainshtein writ >> es: >> > Curtis and all, >> > Can you please explain what you mean when you say >> > that mapping EXP-->802.1q is straighforward? >> > >> > The only reference I have found in RFC 3270 states: >> > <quote> >> > 3. Detailed Operations of E-LSPs >> > ... skipped ... >> > 3.4 Populating the `Set of PHB-->Encaps mappings' for an >> outgoing E-LSP >> > ... skipped ... >> > 3.4.4 `PHB-->802.1 mapping' >> > >> > If the LSP is egressing over a LAN interface on which >> multiple 802.1 >> > Traffic Classes are supported as per [IEEE_802.1], then one >> > `PHB-->802.1 mapping' is added to the `Set of >> PHB-->Encaps mappings' >> > for this outgoing LSP. This `PHB-->802.1 mapping' is >> populated in >> > the following way: >> > >> > - it is a function of the PHBs supported on this LSP, >> and uses the >> > relevant mapping entries for these PHBs from the >> Preconfigured >> > `PHB-->802.1 mapping' defined in section 3.4.4.1. >> > >> > Notice that the `Set of PHB-->Encaps mappings' then >> contains both a >> > `PHB-->EXP mapping' and a `PHB-->802.1 mapping'. >> > >> > 3.4.4.1 Preconfigured `PHB-->802.1 Mapping' >> > >> > At the time of producing this specification, there are no >> > standardized mapping from PHBs to 802.1 Traffic Classes. >> > Consequently, an LSR supporting multiple 802.1 Traffic >> Classes over >> > LAN interfaces must allow local configuration of a `PHB-->802.1 >> > mapping'. This mapping applies to all the outgoing >> LSPs established >> > by the LSR on such LAN interfaces. >> > <end quote> >> > >> > It seems to me that the use case is exactly one you have mentioned >> > (i.e. EXP-->802.1q for unsignaled E-LSPs), but no >> standardized mapping >> > is defined, and a local defintion is left to the network >> administrator. >> > >> > One can probably add some limitations, e.g., AF<x><y> for a fixed x >> > MUST be mapped to the same 802.1q traffic class since >> AF<x><y> is an >> > ordered aggregate for any given x. CS<n> should be >> > probably mapped to Pri = n for n=1, ..., 7, and the default >> > PHB should be mapped to the Pri = 0. >> > >> > Is there anything beyound these (and some other, equally >> > naive) considerations? >> > >> > With best regards, >> > Sasha Vainshtein >> > email: sasha@axerra.com <mailto:sasha@axerra.com> >> > tel: +972-3-7659993 (office) >> > +972-8-9254948 (res.) >> > +972-58-674833 (cell.) >> >> >> Someone building an LSR just implements the ability to enable a >> default E-LSP EXP->802.1q mapping and offers the ability to configure >> mappings. Whether this proves adequate and if so, the configuration >> is up to the ISP (or other user). >> >> Curtis >> >> >> > > -----Original Message----- >> > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] >> > > Sent: Monday, October 21, 2002 7:37 PM >> > > To: Sasha Vainshtein >> > > Cc: 'curtis@fictitious.org'; 'Vishal M'; mpls@uu.net; >> Shahram Davari >> > > Subject: Re: DiffServ MPLS over Ethernet (L-LSP vs E-LSP) >> > > >> > > >> > > >> > > In message <AF5018AC03D1D411ABB70002A509132678E63C@TLV1>, >> > > Sasha Vainshtein writ >> > > es: >> > > > Curtis and all, >> > > > Can you provide any suggestions/pointers as to how >> DiffServ and >> > > > 802.1q markings should be mapped? >> > > > Because, IMHO, just having 802.1q is not enough, you >> should decide >> > > > how to use it. >> > > >> > > I'm not a big fan of 802.1q. >> > > >> > > Mapping EXP into 802.1q signaling is straightforward. >> This mapping is >> > > sufficient for unsignaled E-LSP. >> > > >> > > The mapping of 802.1q priorities to packet treatment is not >> > > straightforward. I'd argue that what most switches are >> capable of >> > > doing with 802.1q priorities does not support diffserv, >> particularly >> > > AF, L-LSPs, or signaled E-LSPs. For AF service, the EXP >> bits must be >> > > modified even for unsignaled E-LSPs so any switch >> relying solely on >> > > 802.1q signaling is inherently broken wrt AF service. >> > > >> > > > With best regards, >> > > > Sasha Vainshtein >> > > >> > > I haven't kept up with what ethernet switches are doing in this >> > > regard. Shahram may be better able to answer this. >> > > >> > > Curtis >> > > >> > >> >>
|
|