On 20/Jun/20 14:41, Masataka Ohta wrote:
There are many. So, our research group tried to improve RSVP.
I'm a lot younger than the Internet, but I read a fair bit about its history. I can't remember ever coming across an implementation of RSVP between a host and the network in a commercial setting. If I missed it, kindly share, as I'd be keen to see how that went.
Practically, the most serious problem of RSVP is, like OSPF, using unreliable link multicast to reliably exchange signalling messages between routers, making specification and implementations very complicated.
So, we developed SRSVP (Simple RSVP) replacing link multicast by, like BGP, link local TCP mesh (thanks to the CATENET model, unlike BGP, there is no scalability concern). Then, it was not so difficult to remove other problems.
Was "S-RSVP" ever implemented, and deployed?
However, perhaps, most people think show stopper to RSVP is lack of scalability of weighted fair queueing, though, it is not a problem specific to RSVP and MPLS shares the same problem.
QoS has nothing to do with MPLS. You can do QoS with or without MPLS. I should probably point out, also, that RSVP (or RSVP-TE) is not MPLS. They collaborate, yes, but we'd be doing the community a disservice by interchanging them for one another.
Obviously, weighted fair queueing does not scale because it is based on deterministic traffic model of token bucket model and, these days, people just use some ad-hoc ways for BW guarantee implicitly assuming stochastic traffic model. I even developed a little formal theory on scalable queueing with stochastic traffic model.
Maybe so, but I still don't see the relation to MPLS. All MPLS can do is convey IPP or DSCP values as an EXP code point in the core. I'm not sure how that creates a scaling problem within MPLS itself. If you didn't have MPLS, you'd be encoding those values in IPP or DSCP. So what's the issue?
So, we have specification and working implementation of hop-by-hop, scalable, stable unicast/multicast interdomain QoS routing protocol supporting routing hierarchy without clank back.
See
http://www.isoc.org/inet2000/cdproceedings/1c/1c_1.htm
for rough description of design guideline.
If I understand this correctly, would this be the IntServ QoS model?
I didn't attempt to standardize our result in IETF, partly because optical packet switching was a lot more interesting.
Still is, even today :-)?
That should be a reasonable way of practical operation, though I'm not very interested in OCS (optical circuit switching) of GMPLS
Design goals are often what they are, and then the real world hits you.
For IP layer, that should be enough. For ASON, so complicated GMPLS is actually overkill.
When I was playing with ATM switches, I established control plain network with VPI/VCI=0/0 and assign control plain IP addresses to ATM switches. To control other VCs, simple UDP packets are sent to switches from controlling hosts.
Similar technology should be applicable to ASON. Maintaining integrity between wavelength switches is responsibility of controllers.
Well, GMPLS and ASON is basically skinny OSPF, IS-IS and RSVP running in a DWDM node's control plane.
No, I just explained what was advertised to be MPLS by people around Cisco against Ipsilon.
According to the advertisements, you should call what you are using LS or GLS, not MPLS or GMPLS.
It takes a while for new technology to be fully understood, which is why I'm not rushing on to the SR bandwagon :-). I can't blame the sales droids or the customers of the day. It probably sounded like dark magic.
Assuming a central controller (and its collocated or distributed back up controllers), we don't need complicated protocols in the network to maintain integrity of the entire network.
Well, that's a point of view, I suppose. I still can't walk into a shop and "buy a controller". I don't know what this controller thing is, 10 years on. IGP's, BGP and label distribution protocols have proven themselves, in the interim.
What if, an inner label becomes invalidated around the destination, which is hidden, for route scalability, from the equipments around the source?
I can't say I've ever come across that scenario running MPLS since 2004. Do you have an example from a production network that you can share with us? I'd really like to understand this better.
No, as "the destination expected to pop the label" is located somewhere around the final destination end-host.
If, at the destination site, connectivity between a router to pop nested label and the fine destination end-host is lost, we are at a loss, unless source side changes inner label.
Maybe a diagram would help, as I still don't get this failure scenario. If a host lost connectivity with the service provider network, getting label switching to work is pretty low on the priority list. Again, unless I misunderstand.
If you are using intra-domain hierarchical routing for scalability within the domain, you still suffer from lack of scalability of MPLS.
And, VRF is, in a sense, a form of intra-domain hierarchical routing with a lot of flexibility, which means a lot of unnecessary complications.
I don't think stuffing your VRF's full of routes is an intrinsic problem of MPLS. MPLS works whether you run l3vpn's or not. That MPLS provides a forwarding paradigm for VRF's does not put it and the potential poor scalability VRF's in the same WhatsApp group. Mark.