The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: About RSVP-TE scalability - please help
Srihari, > 2. RSVP-TE, by contrast, is ONLY used to set up CRLSPs or ERLSPs and not > 'flows' like that as MPLS 'traffic trunks'. Because, the number of LSPs (CR > or ER) can be far less than the number of traffic flows through it, RSVP-TE > is more scalable? Correct. > 3. Running diffserv with MPLS, am I right in saying that ERLSPs or CRLSPs > are set up by RSVP-TE with preset labels choosing different levels of QoS > guaranteed LSPs and diffserv running at Ingress, decides which LSP to choose > by appending labels to the incoming packets based on their DSCPs? That would be the case of L-LSPs. I don't know of any implementation supporting L-LSPs today. Most customers seems to be happy with 8 classes of diffserv information transported and retrived at each LSR in 3 bits in EXP field in the lable header. Also diffserv aware TE is yet another mechanism for providing tighter guarantees then regular diffserve for traffic flowing via such LSPs. That is available today - I was just not sure which of those two yr item 3 was refering to. R. > Srihari Raghavan wrote: > > Hi all, > I have some questions regarding RSVP/RSVP-TE. Can anyone please help me > with it? > > Am I right in saying the following things about RSVP/RSVP-TE when used > for MPLS traffic engineering at the core/backbone networks? > > 1. RSVP in its original form is used to set up per-flow (data traffic) > state at each intermediate router. Is this found not scaleable because of > the 'soft state', potential large number of data flows and non usage of > reliable protocols like TCP? > > 2. RSVP-TE, by contrast, is ONLY used to set up CRLSPs or ERLSPs and not > 'flows' like that as MPLS 'traffic trunks'. Because, the number of LSPs (CR > or ER) can be far less than the number of traffic flows through it, RSVP-TE > is more scalable? > Or, is it the case that the 'labels' being distributed by the egress > using RSVP-TE defines the traffic across the LSP and since 'labels' and LSPs > can be subject to label merging and LSP aggregation, RSVP-TE is scalable in > the core? Or is there anything that I am missing here about RSVP-TE > scalability? > > I think what i am trying to understand is how RSVP-TE is scalable while > there are some concerns about RSVP not being so. Is it because of > scalability extensions like like message_id extension, Bundle message > extension, summary refresh extension and hello protocol extension? or is it > any of the reasons above? > > 3. Running diffserv with MPLS, am I right in saying that ERLSPs or CRLSPs > are set up by RSVP-TE with preset labels choosing different levels of QoS > guaranteed LSPs and diffserv running at Ingress, decides which LSP to choose > by appending labels to the incoming packets based on their DSCPs? > > Can any one please confirm the above ideas about RSVP-TE, as its > understanding is very important to my work. > > Thank you for your time > > Srihari Raghavan > Graduate student > Dept. of Computer Science > Virginia Tech > ========================= > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|