The MPLS WG Archive

["Per F Hansen" <perfhans@worldonline.dk>]

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)




----- Original Message ----- 
From: "Iren, Sami" <Sami.Iren@marconi.com>
To: "'Vishal M'" <vishal_study@yahoo.com>; "Iren, Sami" <Sami.Iren@marconi.com>; <mpls@UU.NET>
Sent: Tuesday, November 06, 2001 9:27 PM
Subject: RE: EXP<=>PHBID maps in DIFFSERV Object 


> 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:vishal_study@yahoo.com]
> > Sent: Tuesday, November 06, 2001 2:50 PM
> > To: Iren, Sami; mpls@UU.NET
> > 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" <Sami.Iren@marconi.com> 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:vishal_study@yahoo.com]
> > > > Sent: Monday, November 05, 2001 11:04 PM
> > > > To: mpls@UU.NET
> > > > 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
> > 
>