Talk:Asynchronous Transfer Mode

message: The P-NNI standard specifies the exchange of link state information, similar to what IS-IS and OSPF do.  It has more levels of hierarchy, and more metrics, but the basic approach is similar.
However, it does not specify the routing algorithm, i.e., the algorithm that picks the path for a particular destination.  The reason is that this is not necessary; SVC setup uses source routing, so there is no need for the switches to agree on what the chosen route will be for a given destination.  Connectionless switches require agreement to avoid loops, but ATM SVC setup does not.  So the standard leaves this aspect open to implementers' choice.
Obviously, it's to be expected that some algorithm similar to Dijkstra's algorithm will be used to determine the path for a particular connection, but it's not correct to say that the standard "uses the same shortest path algorithm used by OSPF..." Paul Koning 17:01, 2 May 2007 (UTC)
replies: text: I have made corrections to clear this up. ~Kvng (talk) 13:46, 22 May 2020 (UTC)
thread_title:  P-NNI is link state but not necessarily shortest-path 

message: The article says "To admit a call first a VPC has to be established. This will guarantee the correct routing from end to end."  This is incorrect.  In the signaling for SVC setup, the route is specified (see my comment above on P-NNI).  It does not require a pre-existing VPC, for routing or for any other purpose.  A call is admitted if the admission control algorithm decides to admit the call, normally because the resources the call asks for (in the signalling messages) are available.
A network implementer can certainly use a VPC as a trunk, and route a new SVC over such a trunk if the source route allows it, but there's no requirement to do so; if a network does that, it's an internal matter that is invisible to the user. Paul Koning 17:06, 2 May 2007 (UTC)
replies: text: Mentioned text is no longer in the article. There is not even an instance of VPC' which apparently stands for virtual path connection. ~Kvng (talk) 14:29, 22 May 2020 (UTC)
thread_title:  Call admission 

message: There doesn't appear to be a clear reason for the statement "ATM switches can also operate at OC-192 (STM64) rates." to be part of a paragraph dealing with ATM over IP and IP routing (not ATM switching). The relevance of this statement should either be qualified with additional information, or if it is indeed dealing with an unrelated issue, put into a seperate paragraph and elaborated upon. I have removed it for the moment. --Het 02:02, 2 October 2007 (UTC)
thread_title: also operate at OC-192 (STM64) rates

message: Some call this protocol "A Terrible Mistake". See http://www.clock.org/~fair/opinion/atm-is-bad.html Emersion (talk) 11:17, 15 December 2017 (UTC)
replies: text: Well, it is 20 years old (note the comment on the upcoming gigabit ethernet).  But otherwise, ATM was designed for telephone companies, not for LAN or WAN use. VoIP isn't quite closing down the telephone companies yet, though.  But yes, LANe isn't a good way to run a LAN. Leave ATM to the phone companies. Gah4 (talk) 14:31, 15 December 2017 (UTC)

text: That looks like a WP:SPS. See #ATM (Another Technical Mistake) discussion above. ~Kvng (talk) 14:29, 22 May 2020 (UTC)
thread_title:  A Terrible Mistake 

message: :The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion. 
The result of the move request was: Not Moved: A rough concensus not to move the article  Megan☺️ Talk to the monster 18:16, 23 September 2020 (UTC)
replies: text: Asynchronous Transfer Mode →  – See discussion 10 years ago, in Talk:Asynchronous Transfer Mode# lowercase correct about whether or not have the title with capital letters. Anthony Appleyard (talk) 09:24, 16 September 2020 (UTC)

text: Please don't start this bizarre talk again. It was the consensus of the technically knowledgeable editors that this is a proper noun, supported by the vast majority of topic literature, including dozens of IETF RFCs. In addition, WP uppercases all specific protocol names. kbrose (talk) 12:36, 16 September 2020 (UTC)

text: Oppose – proper name, just been corrected --Zac67 (talk) 16:57, 16 September 2020 (UTC)

text: Oppose. This is a proper name and thus should be capitalised. JIP | Talk 17:47, 16 September 2020 (UTC)

text: Neutral – at the last RM discussion at Talk:Asynchronous_Transfer_Mode/Archive_2#Requested_move_4_June_2018 there wasn't much input, but it was left at lowercase where Tony1 had put it earlier.  I supported the removal of the parenthetical and didn't look into the case much.  I agree it's a named protocol, so probably caps are OK. Dicklyon (talk) 23:02, 17 September 2020 (UTC)

text: And see earlier discussion above this, if this comes up again.  A great deal of evidence has been presented for this being a proper name, and basically nothing for the opposite other than it was spelled wrong in a handful of old RfCs.  — SMcCandlish ☏ ¢ 😼  15:45, 26 October 2020 (UTC)
thread_title:  Requested move 16 September 2020