Subject: RE: EXP<=>PHBID maps in DIFFSERV Object

From: "Iren, Sami" <[email-masked]>
Date: Tue, 6 Nov 2001 15:27:46 -0500

Vishal,

You are correct with the statement that this
poses a scalability issue. And forwarding
asics have to do the translation when pushing/poping
a label. I don't know any specific vendor supporting
this at the moment, however, one can limit the number
of EXP<=>PHBID tables to a value his hw can support
and reject LSPs that signal any other combination.

To give you an idea, consider the case where you would
like to send traffic of the following types from 
point A to point B: AF1, AF2, AF3, AF4, EF, BE
If we don't have signalled mappings (i.e., we have only
default per LSR/domain EXP<=>PHBID mapping) then
we have to create at least 3 LSPs: 1 E-LSP to carry
AF1, AF2, EF, and BE traffic, 1 L-LSP to carry AF3 traffic,
and another L-LSP to carry AF4 traffic.
On the other hand, with the signalled EXP<=>PHBID mappings
we can do the same thing with TWO E-LSPs.
(Note that AF classes consume three EXP values, one for each
drop precedence).

Another point I would like make is that, maybe the term "per-LSR"
EXP<=>PHBID mapping table is incorrect. Although, we configure
these default tables per LSR, the configuration should be the
same for all the LSRs in a domain, otherwise it will not work.

I would also be interested in hearing from other people who actually
implemented this.

Regards,
--Sami

> -----Original Message-----
> From: Vishal M [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 2:50 PM
> To: Iren, Sami; [email-masked]
> Subject: RE: EXP<=>PHBID maps in DIFFSERV Object 
> 
> 
> 
> Hi Sami,
> 
> If the EXP<=>PHBID mapping are per-LSP instead of
> per-LSR, doesn't that pose a scalablity issue. 
> As it is, a core router (LSR) has to maintain states
> for each LSP in RSVP. With this solution (of DiffServ)
> it would have to maintain these additional mappings
> for each LSP.
> 
> Some followup questions:
> ========================
> 1. Has someone really implemented this ? Does it
> really scale well ? Not sure if we can go into
> vendor-specifics here...
> 
> 2. How about the forwarding ASIC ? It would have to
> program inLabel<=>EXP <=mapto=> outLabel<=>EXP for
> each label*numberOfEXPSupported.
> 
> 3. This could be an issue during Fast-Reroute.
> While re-routing, LSR would have to do a lot more work
> to find the alternate route. 
> 
> If all the above are real issues, could someone please
> comment on why was this mapping (EXP<=>PHBID) done on
> per-LSP and not per-LSR basis? 
> 
> Thanks for your time,
> Vishal.
> 
> -- "Iren, Sami" <[email-masked]> wrote:
> > Vishal:
> > The mappings you mentioned in your message is per
> > LSP,
> > not per LSR. So, for every LSP the mapping could be
> > different. The inconsistency between the LSRs is not
> > an issue here.
> > 
> > When these mappings are not signalled, a default
> > mapping
> > is used per LSR. The draft states that, unless
> > configured
> > otherwise by the operator, the default mapping is
> > that all 
> > EXP values refer to Best effort service.
> > 
> > The inconsistency between LSRs is an issue only when
> > the
> > mappings are not signalled and default per LSR
> > mappings
> > are inconsistent among the LSRs in a domain.
> > 
> > Regards,
> > --Sami
> > 
> > > -----Original Message-----
> > > From: Vishal M [mailto:[email-masked]]
> > > Sent: Monday, November 05, 2001 11:04 PM
> > > To: [email-masked]
> > > Subject: EXP<=>PHBID maps in DIFFSERV Object 
> > > 
> > > 
> > > 
> > > Hello,
> > > 
> > > The DIFFSERV Object defined in "MPLS Support for
> > > DiffServ, version 09.txt", Section 5.2 defines MAP
> > > sub-fields that carries EXP <==> PHBID mappings
> > for a
> > > given LSP.
> > > 
> > > Are these mappings specified anywhere ? What EXP
> > value
> > > would map to what PHBID ?
> > > 
> > > Is it network administrator's responsibility for
> > > guarantee the uniqueness/consistancy of such
> > mappings
> > > ? 
> > > 
> > > Consider the following:
> > > 
> > >       ----LSR1 ----> LSR 2 <----- LSR3-----
> > > 
> > > LSR1 advertises EXP 4 ==> PHB AF12 map to LSR2
> > > LSR3 advertises EXP 4 ==> PHB CS2 map to LSR2
> > > 
> > > How would LSR 2 handle these ? 
> > > 
> > > Only way one could guarantee this is if the LSP is
> > > within a particular domain, in which case
> > consistency
> > > can be guaranteed (by a single network admin). 
> > > 
> > > But if LSP is crossing domain boundaries, it could
> > be
> > > an issue. Not sure if network operators are really
> > > into these inter-domain LSPs at this point...
> > > 
> > > Could someone please comment on this.
> > > 
> > > Thanks,
> > > Vishal.
> > > 
> > > 
> > > 
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Find a job, post your resume.
> > > http://careers.yahoo.com
> > > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
>

---

From: "Per F Hansen" <[email-masked]>
Date: Wed, 7 Nov 2001 05:55:17 +0100

Another angle:

If  your scalability discussions are combined with (pushing and popping) and then with

  uniform diffserv. model
  pipe diffserv model
  short pipe diffserv model.

That gives a lot of stuff to think about for an ASIC designer, when having completely
different EXP -> PHB  mapping sets for each signalled LSP.

Having a recommended mapping set of  EXP ->  PHB ( PSC and drop precendence)  for the 
different AF types in signalling messages, when signalling L-LSPs and E-LSPs would make a lot
of sense in the scalability discussions. Because if IETF define a recommended mapping set 
for all AF1x, AF2x, AF3x and AF4x, then there would be a chance in practise
that the current usage of different mapping sets can be limited in an LSR, and thereby 
be more practical for an ASIC implementation.

Per Flemming Hansen (tpack.net,  a startup company)