Subject: RE: DiffServ MPLS over Ethernet (L-LSP vs E-LSP)

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 22 Oct 2002 09:27:18 +0100

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:[email-masked]] 
>> Sent: 21 October 2002 22:19
>> To: Sasha Vainshtein
>> Cc: [email-masked]'; 'Vishal M'; [email-masked]; 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:     [email-masked] <mailto:[email-masked]> 
>> > 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:[email-masked]]
>> > > Sent: Monday, October 21, 2002 7:37 PM
>> > > To: Sasha Vainshtein
>> > > Cc: [email-masked]'; 'Vishal M'; [email-masked]; 
>> 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
>> > > 
>> > 
>> 
>>

---

From: "mark seery" <[email-masked]>
Date: Tue, 22 Oct 2002 05:47:33 -0700

Thanks Francois,

>> [snip] PS:  A few clarifications, addressing some comments in the thread:
- the Shim header is absolutely always used on Ethernet <<

So to answer the original question, if a shim is always used, then both
E-LSP and L-LSP can be supported. In a non-shim scenario, E-LSP could only
be supported if the equivalent (shim header) bits were available in
existing/other (layer2?) headers.

-mark

-------------------------------------------
Introducing NetZero Long Distance
Unlimited Long Distance only $29.95/ month!
Sign Up Today! www.netzerolongdistance.com