The MPLS WG Archive

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

I still aggree that i shall be possible to signal EXP->PHB mapping table in the 
signalling protocol, as today, but that IETF could define a default mapping of the 
known PHB type (AF etc) and that IETF could recommand the signalling initiator to
use this mapping (but do not requeire).

Like saying "you have the freedom to write your language, but we recommmend 
                   proposals to IETF to be written in english"  :-) 

There is a default mapping for  IP DS field to AF PHBs, it would be nice with that
for EXPs also. 

Per

----- Original Message ----- 
From: "Iren, Sami" <Sami.Iren@marconi.com>
To: "'Per F Hansen'" <perfhans@worldonline.dk>; "Iren, Sami" <Sami.Iren@marconi.com>; "'Vishal M'" <vishal_study@yahoo.com>; <mpls@UU.NET>
Sent: Wednesday, November 07, 2001 2:15 PM
Subject: RE: EXP<=>PHBID maps in DIFFSERV Object 


> I agree about the complexity of this thing
> for the asic designers. However, having a fixed
> set of mappings would mean limiting the number
> of PHBs that can be used to the standard PHBs only.
> DiffServ architecture allows user defined PHBs
> as well and we would like to be able to support these
> PHBs in E-LSPs.
> Furthermore, as I stated before, in practice we can
> limit the number of tables to a small number that can
> be supported by hw. For example the following 
> tables will suffice for most cases:
> 
> Table#   Supported PHBs/Classes
> ------   ----------------------
> 1        AF1, AF2, EF, BE
> 2        AF3, AF4, EF, BE
> 3        AF1, AF3, EF, BE
> 4        AF2, AF4, EF, BE
> 5        AF1, AF4, EF, BE
> 6        AF2, AF3, EF, BE
> 
> These tables are not exhaustive (e.g., they 
> exclude the CS PHBs). My point is that in
> practice, the possibilities are limited and
> asic designers can take advantage of that.
> If I'm given an asic that can handle six tables,
> I would use the above configuration to support
> E-LSPs and would reject those E-LSPs with any
> other mappings.
> 
> Regards,
> --Sami
>  
> 
> > -----Original Message-----
> > From: Per F Hansen [mailto:perfhans@worldonline.dk]
> > Sent: Tuesday, November 06, 2001 11:55 PM
> > To: Iren, Sami; 'Vishal M'; mpls@UU.NET
> > Subject: Re: EXP<=>PHBID maps in DIFFSERV Object 
> > 
> > 
> > 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
> > > > 
> > > 
> > 
>