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

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 21 Oct 2002 20:17:49 +0200

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.)

> -----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: Curtis Villamizar <[email-masked]>
Date: Mon, 21 Oct 2002 16:18:59 -0400

In message <AF5018AC03D1D411ABB70002A509132678E642@TLV1>, Sasha Vainshtein writ
> tel:       +972-3-7659993 (office)

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