Talk:Multiprotocol Label Switching

message: ...protocol agnostic...  Does that mean MPLS doesn't know if protocols exist?  What a ridiculous phrase.<BR>
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)
thread_title:  Agnosticism 

message: 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)
replies: text:   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)
thread_title:  Historical notes 

message: 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)
replies: text: Sad. It's documented here: . --Alvestrand 15:51, 28 January 2006 (UTC)
thread_title: Does the Experimental Bits section make sense?

message: 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)
thread_title: QoS topics missing

message: 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)
thread_title:  MPLS with non-IP protocols - clarification? 

message: 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)
thread_title:  MPLS vs Ethernet 

message: 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)
thread_title:  IEEE 1355 

message: 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)
replies: text: Clearly spam. Removed. --EnOreg (talk) 09:32, 27 March 2009 (UTC)
thread_title:  Commercial Advertisement in article? 

message: For historical context, please add some year references to the History section.
212.199.196.155 (talk) 08:00, 5 March 2009 (UTC)
thread_title:  History Dates 

message: 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)
thread_title:  Comparison of MPLS versus Frame Relay 

message: 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)
replies: text: 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)
thread_title:  No mention of Security concerns 

message: 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)
thread_title:  One header, multiple labels? 

message: 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)
thread_title:  Benefits and Drawbacks 

message: 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)
replies: text: 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)
replies: text: I now created an "Introduction" section. --EnOreg (talk) 15:06, 17 September 2011 (UTC)
thread_title:  RFCs 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Define "label" 

message: 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)
thread_title: Competitors to MPLS

message: 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)
thread_title:  Contested deletion 

message: 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)
thread_title:  Contested deletion 

message: 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)
thread_title:  Terminology merge 

message: Something like http://ipcisco.com/wp-content/uploads/mpls/MPLS_Header_color.JPG. ~KvnG 10:27, 25 June 2013 (UTC)
thread_title:  Needs diagram 

message: 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)
thread_title:  IP/MPLS instead of MPLS 

message: 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)
thread_title:  Is this comparison with ATM right? 

message: I like Bangaja7 (talk) 08:14, 15 November 2015 (UTC)
thread_title:  its ok 

message: 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)
thread_title:  Competitor Protocols 

message: Thanks for number phone service 2600:1700:265A:A800:94A:8C39:FF9:607D (talk) 17:34, 18 May 2024 (UTC)
thread_title:  GRE phone thanks for number