The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

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