Mark Tinka 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.
No, of course, because, as we agreed, RSVP has a lot of problems.
Was "S-RSVP" ever implemented, and deployed?
It was implemented and some technology was used by commercial router from Furukawa (a Japanese vendor selling optical fiber now not selling routers).
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.
GMPLS, you are using, is the mechanism to guarantee QoS by reserving wavelength resource. It is impossible for GMPLS not to offer QoS. Moreover, as some people says they offer QoS with MPLS, they should be using some prioritized queueing mechanisms, perhaps not poor WFQ.
I should probably point out, also, that RSVP (or RSVP-TE) is not MPLS.
They are different, of course. But, GMPLS is to reserve bandwidth resource. MPLS, in general, is to reserve label values, at least.
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.
I didn't say scaling problem caused by QoS. But, as you are avoiding to extensively use MPLS, I think you are aware that extensive use of MPLS needs management of a lot of labels, which does not scale. Or, do I misunderstand something?
If I understand this correctly, would this be the IntServ QoS model?
No. IntServ specifies format to carry QoS specification in RSVP packets without assuming any specific model of QoS.
I didn't attempt to standardize our result in IETF, partly because optical packet switching was a lot more interesting.
Still is, even today :-)?
No. As experimental switches are working years ago and making it work >10Tbps is not difficult (switching is easy, generating 10Tbps packets needs a lot of parallel equipment), there is little remaining for research. https://www.osapublishing.org/abstract.cfm?URI=OFC-2010-OWM4
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.
SDN, maybe. Though I'm not saying SDN scale, it should be no worse than MPLS.
I can't say I've ever come across that scenario running MPLS since 2004.
I did some retrospective research. https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching History 1994: Toshiba presented Cell Switch Router (CSR) ideas to IETF BOF 1996: Ipsilon, Cisco and IBM announced label switching plans 1997: Formation of the IETF MPLS working group 1999: First MPLS VPN (L3VPN) and TE deployments 2000: MPLS traffic engineering 2001: First MPLS Request for Comments (RFCs) released as I was a co-chair of 1994 BOF and my knowledge on MPLS is mostly on 1997 ID: https://tools.ietf.org/html/draft-ietf-mpls-arch-00 there seems to be a lot of terminology changes. I'm saying that, if some failure occurs and IGP changes, a lot of LSPs must be recomputed, which does not scale if # of LSPs is large, especially in a large network where IGP needs hierarchy (such as OSPF area). Masataka Ohta