Talk:Multiprotocol Label Switching

	Telecommunication portal This article is within the scope of WikiProject Telecommunications, a collaborative effort to improve the coverage of Telecommunications on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TelecommunicationsWikipedia:WikiProject TelecommunicationsTemplate:WikiProject TelecommunicationsTelecommunications articles
High	This article has been rated as High-importance on the project's importance scale.

Computing: Networking Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as High-importance).

Agnosticism

...protocol agnostic... Does that mean MPLS doesn't know if protocols exist? What a ridiculous phrase.
I would find useful to describle the differents transports protocols supported by MPLS (over IP, over GRE, over TRILL?...)

—Preceding unsigned comment added by 204.0.69.201 (talk) 16:04, 23 March 2011 (UTC)[reply]

Is MPLS a Protocol?

Is MPLS a protocol? Should the category be changed to Network protocols? - Sridev 21:05, 16 Aug 2004 (UTC)

Well, yes and no. MPLS is more of a packet format, along with some simple processing rules for forwarding packets in that format. Whether that makes it a protocol is kind of a theological question. The MPLS spec is mostly there to allow people to build compatible hardware. You also need (in most cases) a setup protocol - which you may or may not consider part of MPLS (there are several different alternatives) - before packets can flow. Noel 07:57, 25 Oct 2004 (UTC)

I would call it an framework (defining the need) and an architecture (rules for writing protocols and expected behavior). Protocols flow between machines, so the expected internal behavior of a Label Switched Router (LSR) in forwarding packets [Note 1] and the expected behavior of a Label Edge Router in assigning packets to an MPLS path is not strictly a protocol

[Note 1] For all practical purposes, the generation of MPLS we are discussing here forwards packets. Generalized MPLS (GMPLS) has a framework and architecture for forwarding non-packet information, such as optical wavelengths (i.e., lambdas) in a Wavelength-division multiplexing system, time slots in time-division multiplexing such as SONET, and coordinates of the desired in and out ports on cross-connect switches (e.g., Digital cross connect system oe DACS). For all these non-packet forwarding modes, there still must be path setup protocols that interact with IP routing.Howard C. Berkowitz 15:56, 22 September 2007 (UTC)[reply]

Wire format + Semantics = Protocol. --Koshua 03:19, 7 Jan 2005 (UTC)

"Label Lookup and Label Switching [...] can take place directly into fabric and not CPU."

It would be nice to provide some explanation of this statment... why is this so? And re: a few paragraphs earlier, *why* was it so challenging ("impossible") "to forward IP packets entirely in hardware"? These are offered as a motivation for why this subject is important, but it's not explained (or linked) well enough to be understood. DKEdwards 00:31, 21 October 2006 (UTC)[reply]

I agree. Also, the link associated with the word "fabric" does not appear to work at the moment. Simeon Williamson 14:49, 9 November 2006 (UTC)[reply]

See Switched fabric and Forwarding Plane The basic idea is that the CPU just has to worry about setting up and tearing down paths, and doing fault circumvention for the paths, and the forwarding itself can be done with more purpose-built hardware Howard C. Berkowitz 15:56, 22 September 2007 (UTC)[reply]

MPLS is now also used in Ethernet Switching

If the QOS experiment is successful will this see the end of telephone call charges? —Preceding unsigned comment added by 87.102.29.99 (talk) 13:46, 4 June 2009 (UTC)[reply]

A protocol is defined as an interactive algorithm, enabling two or more parties to communicate using common syntax and semantics. MPLS is a protocol by definition. It does not matter whether it's just implemented via an adaptation layer or not. Nageh (talk) 13:15, 12 September 2011 (UTC)[reply]

Historical notes

Historical note that I thought was a little too detailed to go into the article - Tag Switching was originally Cisco's response to Ipsilon's high-speed switching product. (This was back from when everyone "knew" that switches could run faster than routers, and Ipsilon's clever marketing of their system [which used ATM switches] was proving vey effective.)

Another detail note: the issue with queueing delays and voice is that for voice to work, it needs to have low jitter (i.e. delay variance). You can get this in one of two ways: i) Have a big playback buffer, which allows you to smooth out the jitter, but which is (or was) expensive, and also increased the delay across the channel - and human conversational mechanisms tend not to work well with high-delay channels, or ii) Build a system with low delay and low jitter, for which you have to have short queueing delays, for which you have to have cells (a la ATM) on slow (and T1 was common when ATM was done) links if you intend to also carry large datagrams. Noel 07:57, 25 Oct 2004 (UTC)

There's also a Frame Relay link fragmentation mechanism. Although ATM and Frame Relay unquestionably "lost" and there is no real reason to kick a dead horse, I find some of the language in the article to be a bit more reminiscent of the FUD from back when the PR battle still raged. Old FUD dies hard. At some point a definitive post-mortem on ATM must have been written by a responsible entity (i.e. someone other than a packet switching vendor.) It would be nice for historical content about legacy protocols to reflect reality there. (76.118.216.33 (talk) 02:56, 2 September 2010 (UTC))[reply]

Wiped all of that nonsense re: Schlumberger and Preston Poole. There was not a single citation and I couldn't find the guy in any RFCs. Looks like scene trolling. FlapjackShoestring (talk) 03:20, 10 March 2011 (UTC)[reply]

The contribution of the Schlumberger team lead by Poole and Chapellat is one of the most key events in early adoption of MPLS in the enterprise. Several years later this newtork was rebranded SPN (secure private network) and later SPINE, and I beleive sold to BT. This evolved into one of the delivery platforms for BT Radianz. In 2006, the BoD and VoD research and algorythims developed by Poole and the Schlumberger folks was adopted by most major telecommunications providers offering fee-based cable/entertainment services via MPLS or IP FrATM. —Preceding unsigned comment added by JCMccain2010 (talk • contribs) 21:54, 21 October 2010 (UTC)[reply]

GMPLS

In addition to MPLS, If I may suggest that a specific note be made on G-MPLS or Generalized MPLS. This is to basically to reflect the extension of MPLS into the time, wavelength, and fiber paradigm. The IETF common control and measurement plane (CCAMP) are working on standardizing the network plane across such multiple domains. http://www.ietf.org/html.charters/ccamp-charter.html

Suspicion of commercial unethical ad in external link section

I could not figure the interest of 3 differents links related to the same simulation product (NEST - QoSDesign) in the external link sections. At least I think negative impression should be balanced by providing links to Opnet and other broadly used simulation solutions.

Does the Experimental Bits section make sense?

I couldn't figure out that the Experimental Bits section made sense at all.

In the MPLS presentations I've seen, multiple tunnels between the same endpoints are used all the time - exactly because one can apply QoS differentiation to different tunnels. In fact, lots of the time, MPLS networks are sold as "this is the solution to the QoS problem". Delete section? --Alvestrand 08:23, 9 January 2006 (UTC)[reply]

Sad. It's documented here: [1]. --Alvestrand 15:51, 28 January 2006 (UTC)[reply]

The article lists the experimental bits as "QoS" bits. While Cisco (and likley other vendors too) use it for this purpose the RFC does not state a specific use for them. Should the article state they are QoS bits, or simply that its a common use of them? Theres nothing to say a vendor might use them for something else besides QoS. RFC 3032. - ML

I would take issue with the 'MPLS Deployment' and 'Competitor to MPLS' sections that refer to MPLS working in an IPv4 or IP-only environment as it is also supported in IS-IS environments.

I agree, MPLS doesnt care about L3 protocols when making forwarding decisions, it puts a 32 bit label in between the L2 and L3 headers. --Skydivemayday 03:01, 20 October 2006 (UTC)[reply]

Also, while ASICs have increased routing speed, they have done nothing to help with the fact that there are a variety of L2 transports deployed (ATM, Frame Relay, Ethernet, and SONET) which take a bit of work to interconnect every time you need to get from point 'A' to point 'B' and you would have to traverse these different types of L2 environments. MPLS adds an 'abstraction' layer which, when coupled with the VPN capability, reduces the amount of provisioning required.

If any comparisons to L2TPv3 are to be made, it should also be noted that MPLS supports both point-to-point and multipoint VPNs and L2TPv3 truly is IP-only and point-to-point. Joseph chapman 04:09, 24 April 2006 (UTC)[reply]

QoS topics missing

MPLS is everywhere described as being the ultimate solution to QoS problems by supporting Integrated Services (IntServ) and Differentiated Services (DiffServ) at the same time. It can also be used in traffic engineering for things like load balancing on ip-networks (because it's not using shortest path routing like ip always does) and defining backup paths in the case of network failure.

I think these things should be added because for a lot of internet service providers and other communication companies these are the main reasons for using mpls and, of course, as a replacement for atm. A lot of telco companies are now offering voice over ip and tv over ip so for them mpls is a way for ensuring QoS (which is of great importance for realtime services).

06:46, 01 October 2006 (UTC)

MPLS with non-IP protocols - clarification?

The first paragraph states that MPLS can be used to carry native ATM, SONET, and Ethernet frames. This contrasts with a late section which states MPLS cannot be compared to IP as a separate entity because it works in conjunction with IP and IP's IGP routing protocols. Could someone add a little more detail on the first point? In particular I find it puzzling that the MPLS header diagram does not show any indication of packet length, and so presumably depends on the IP packet length indicator. How does this work with non-IP content? Scottwh 13:33, 12 December 2006 (UTC)[reply]

MPLS vs Ethernet

There's a big debate about this (MPLS vs PBT Ethernet) at the moment. Can someone please add some OBJECTIVE, NON-RELIGIOUS, SCIENTIFIC info in about the main differences between the two formats? But are these protocols comparable with each other —The preceding unsigned comment was added by 61.222.209.68 (talk) 09:48, 2 April 2007 (UTC).[reply]

"Remember that a LER is not usually the one that pops the label. " is the first mention of popping. How can you remember anything? Perhaps a previous edit has removed the relevant pre-explanation?

IEEE 1355

IEEE 1355 is a completely unrelated technology that does something similar in hardware.

Sounds like a "deafening silence" aka Oxymoron. Can someone explain the sentence for non-native speakers? --80.136.108.252 (talk) 16:04, 5 April 2008 (UTC)[reply]

love to all —Preceding unsigned comment added by 202.165.243.2 (talk) 13:44, 31 July 2008 (UTC)[reply]

Yeah, but what is it?

I've reread the lead paragraph, and I still can't tell what the subject of the article is. A type of networking methodology? A particular implementation? A proprietary, trademarked system? Is the name Multiprotocol Label Switching or Multi Protocol Label Switching? Is it a proper name, or should the title be multiprotocol label switching? (Capitalize proper names, but not expanded acronyms.) Thanks. —Michael Z. 2008-11-18 21:09 z

Commercial Advertisement in article?

Under MPLS VPN there is a link to http://www.singtel.com/ipvpn Is this a commercial advertisement? I don't know enough about the subject to determine. 69.242.19.2 (talk) 12:13, 10 February 2009 (UTC)[reply]

Clearly spam. Removed. --EnOreg (talk) 09:32, 27 March 2009 (UTC)[reply]

History Dates

For historical context, please add some year references to the History section.

212.199.196.155 (talk) 08:00, 5 March 2009 (UTC)[reply]

Comparison of MPLS versus Frame Relay

I could be reading this wrong, but this paragraph doesn't read like a comparison to MPLS. 96.4.3.129 (talk) 13:51, 9 September 2009 (UTC)[reply]

Some of the material in the section on Comparison of MPLS versus Frame Relay makes reference to time frames without any clean anchor year. It looks like they may be old by now and someone should revisit them. They also lack sufficient references; the one reference given is a bad link.

The relevant text is pasted below:

"In more recent years, Frame Relay has acquired a bad reputation in some markets because of excessive bandwidth overbooking by these telcos.

Telcos often sell Frame Relay to businesses looking for a cheaper alternative to dedicated lines; its use in different geographic areas depended greatly on governmental and telecommunication companies' policies.

Many customers are likely to migrate from Frame Relay to MPLS over IP or Ethernet within the next two years, which in many cases will reduce costs and improve manageability and performance of their wide area networks.[21]"

Techguy95 (talk) 00:45, 1 May 2014 (UTC)[reply]

No mention of Security concerns

From other sources I found that MPLS is not considered a secure protocol. I came to Wikipedia hoping to find details but there is no mention of security or encryption concerns in this article. I think this article would benefit from so expert attention in this area. —Preceding unsigned comment added by 71.42.243.194 (talk) 01:41, 26 August 2010 (UTC)[reply]

Source? Because MPLS itself is nothing but a switching and routing mechanism, the security of the data within the packets is immaterial; data security would be left to the underlying Level3 protocol. Markneill (talk) 22:10, 20 November 2014 (UTC)[reply]

One header, multiple labels?

The article says: 'MPLS works by prefixing packets with an MPLS header, containing one or more "labels"'. Is this correct? According to a sample pcap trace (http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=view&target=mpls-twolevel.cap) and to the page 618 of the book "Network Routing" (by Deepankar Medhi and Karthikeyan Ramasamy) there is a separate MPLS header for each label. I think the sentence should be: 'MPLS works by prefixing packets with one or more MPLS header." What do you think? Nejko (talk) 13:49, 2 October 2010 (UTC)[reply]

It's debatable. You only have one mpls header normally- you don't end up with multiple headers unless you start tunneling mpls inside mpls. 69.145.252.198 (talk) 09:13, 27 February 2011 (UTC)[reply]

Benefits and Drawbacks

The first section contains the closing phrase "While the traffic management benefits of migrating to MPLS are quite valuable (better reliability, increased performance), there is a significant loss of visibility and access into the MPLS cloud for IT departments.[2]" This statement is misleading and the 'supporting' link is a blog with another link to the author's white paper which does not actually provide any justification or support for this claim. If this IT department has control of their network, mpls does not provide less visibility (and in some cases it provides more). The only way this claim can hold any truth is if we're referring to a 3rd party IT group attempting to view events on someone else's network. Even then, it's arguable as to whether there really is a visibility issue as the tools the linked resource mention are not designed to show the info he was expecting to see. (ping is an end-to-end test tool, and traceroute is only concerned with routing, it's already blind to the switchpath)

So I suggest either the complete removal of that line from the main section, or altering it to read "[...], there is a minor loss of visibility into the mpls cloud for 3rd party IT departments." at least until such point in time that the article provides some reasonable supporting evidence for the current statement. 69.145.252.198 (talk) 09:48, 27 February 2011 (UTC)[reply]

RFCs

I'm pretty sure the introduction should mention the IETF and the RFCs that define MPLS. RFC 3031 looks like a place to start. It would also be nice to get at least one date in the history section. RFC 3031 is date January 2001. —Darxus (talk) 17:10, 21 June 2011 (UTC)[reply]

RFC 3031 is mentioned in section "MPLS deployment" which probably is too late indeed. The lead section, on the other hand, is much too long the way it is IMHO. I wouldn't mind mentioning RFCs in the "History" section. More importantly, I advocate shortening the lead section. One way to go about this would be to move a large part of it to a new "Introduction" section. --EnOreg (talk) 22:06, 21 June 2011 (UTC)[reply]

I now created an "Introduction" section. --EnOreg (talk) 15:06, 17 September 2011 (UTC)[reply]

Define "label"

It is not clear from the article what the difference is between a label and a header. Does it do a different function is is it just another name for "header"? Rsduhamel (talk) 18:57, 16 September 2011 (UTC)[reply]

I don't know where the confusion comes from. The label can be viewed as a tag: every packet marked with the same value in the label field gets routed the same way in the MPLS network. The only valid comparison would be with an address: in comparison to the latter, the label identifies a virtual circuit and not an end-point, and upon evaluating the label an MPLS router immediately knows where to forward the packet to. Nageh (talk) 20:29, 16 September 2011 (UTC)[reply]

A header is just a container for information. The MPLS header contains one or more labels. The labels determine a packet's path through the network. Does that make it clear? --EnOreg (talk) 14:17, 17 September 2011 (UTC)[reply]

Ad hoc references

The following appeared at the end of the article. It was tagged for a year. I can't make sense of it so I have moved it here. --Kvng (talk) 15:34, 26 November 2011 (UTC)[reply]

IPv6 references:

IPv6 over MPLS, Cisco Systems 2001;

Juniper Networks IPv6 and Infranets White Paper;

Juniper Networks DoD's Research and Engineering Community White Paper.

Competitors to MPLS

This section originally started off "MPLS can exist in both an IPv4 environment (using IPv4 routing protocols) and an IPv6 environment (using IPv6 routing protocols)." This reads, to me, like an unusually wordy direct copy from a presentation. I've cleaned it up a little, but am preserving the original here, just in case there was some reason for this wording.--Roland (talk) 13:41, 11 January 2012 (UTC)[reply]

I think OpenFlow is also a competitor, since it can completely replace MPLS with OpenFlow. Other opinions? --danrl — Preceding unsigned comment added by 137.193.212.12 (talk) 15:59, 13 March 2012 (UTC)[reply]

Contested deletion

This page should not be speedy deleted as an unambiguous copyright infringement, because... (your reason here) --202.54.134.178 (talk) 12:29, 19 June 2012 (UTC)[reply]

Contested deletion

This article dates back to 2001, and the document it supposedly copies has a 2009 copyright notice. I suggest that the proposer takes a look at the article history, to see if the content on Wikipedia pre-dates the article on the other site.

See User talk:BigDwiki#Multiprotocol label switching. --The Anome (talk) 12:58, 19 June 2012 (UTC)[reply]

Terminology merge

I've proposed a couple merges of MPLS terminology, Label edge router and Label switch router into this article. There is no benefit of having individual articles for terminology associated exclusively with this topic. -—Kvng 16:28, 4 January 2013 (UTC)[reply]

Needs diagram

Something like http://ipcisco.com/wp-content/uploads/mpls/MPLS_Header_color.JPG. ~KvnG 10:27, 25 June 2013 (UTC)[reply]

Label indication

It's not clear to me from this article how the presence of the label is indicated in the various layer 2 protocols? For example, VLAN tags in ethernet frames are indicated by the value in the TPID field that looks like an ethertype. Anyone got and can add this info for MPLS?

Graham.Fountain | Talk 17:54, 12 March 2014 (UTC)[reply]

Okay, I found this information for myself: Ethertype values, 0x8847 and 0x8848. I'll see if I can add this to the article when I get a round tuit.

Graham.Fountain | Talk 11:30, 13 March 2014 (UTC)[reply]

IP/MPLS instead of MPLS

Large parts of this article are only specific for IP/MPLS, the MPLS version that is intended for core networks, and is based on dynamical MPLS routing.

The distinction between IP/MPLS and MPLS is lacking.

Another profile of MPLS is called MPLS-TP and is intended for transport networks. This relies on statically provisioned end-to-end paths (LSP and pseudowires) throughout the MPLS network.

Better would be to move large parts of this page to a new page concerning IP/MPLS, and have this MPLS-page to refer to it and to the existing MPLS-TP page.

déRahier ^talk⁺^contrib 14:04, 9 February 2015 (UTC)[reply]

Is this comparison with ATM right?

In particular, MPLS dispenses with the cell-switching and signaling-protocol baggage of ATM. MPLS recognizes that small ATM cells are not needed in the core of modern networks, since modern optical networks are so fast (as of 2008, at 40 Gbit/s and beyond) that even full-length 1500 byte packets do not incur significant real-time queuing delays (the need to reduce such delays — e.g., to support voice traffic — was the motivation for the cell nature of ATM).
I thought the size of ATM voice packets was not to reduce the transport queuing delay, but to reduce the queuing delay as the voice packet is generated or used, which is caused by the voice sample rate not the transport rate. For example, the 64 kb/s sampling rate of the standard G.711 voice codec, with packets at 6ms, gives a packet size of 48 bytes, which fits the ATM payload size of 48 octets per cell. This has nothing to do with the transport rate, just the sampling rate and the (old) latency requirements of the PSTN, so mentioning the speed of modern optical networks here is a bit misleading. What is relevant is that the fraction of traffic which is non-PSTN/voice is increasing. I have no references for this. There are no references in the quoted paragraph either. If someone who is an expert and who knows the references sees my point, perhaps they could edit the quoted paragraph in the article, and put in references even if I am mistaken. JustGonnaFixIt (talk) 17:17, 26 October 2015 (UTC)[reply]

its ok

I like Bangaja7 (talk) 08:14, 15 November 2015 (UTC)[reply]

Competitor Protocols

This line: "The major goal of MPLS development was the increase of routing speed. This goal is no longer relevant," appears dubious to me. The whole paragraph has had a cit request for nearly 3 years, and no one has provided any substantiation. It may be that something relevant is being said here, but the paragraph does not explain how a technology such as Application-specific integrated circuits obviates the MPLS goal of routing speed. Am I just missing the point here? Or can this go? -- Sirfurboy (talk) 14:49, 4 December 2019 (UTC)[reply]

Citations: added ✅. Symbol (talk) 17:36, 4 December 2019 (UTC)[reply]

GRE phone thanks for number

Thanks for number phone service 2600:1700:265A:A800:94A:8C39:FF9:607D (talk) 17:34, 18 May 2024 (UTC)[reply]