Talk:Asynchronous Transfer Mode.html |
| | | ca | | | de | | | en | | | es | | | fr | | | it | | | nl | | | no | | | pl | | | pt | | | ru | | | ro | | | fi | | | sv | | | tr | | | vo | | |
| |  |
| WikiProject Computing | |
|---|---|
 |
This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion. |
| ??? | This article has not yet received a rating on the quality scale. |
| ??? | This article has not yet received a rating on the importance scale. |
 |
This article is supported by the WikiProject Computer networking, an attempt to build a comprehensive and detailed guide to Computer networking on Wikipedia. |
| WikiProject Telecommunications | |||||
|---|---|---|---|---|---|
|
 |
This article may be too technical for a general audience. Please help improve the article by providing more context and better explanations of technical details, even for subjects that are inherently technical. |
|
Contents |
Virtual Channel Identifiers
This article constantly refers to ATM using virtual circuits. In ATM, "VC" stands for "Virtual Channel", not "Virtual Circuit" (although of course they are an example of the generic concept of virtual circuits). LachlanA 03:15, 31 January 2007 (UTC)
Cell/payload size
This seems like a typo, but as I know next to nothing about ATM myself I'm checking here first: The para on the choice of payload size, 32 v. 64, ends with 53 bytes was chosen as a compromise between the two sides - this seems to conflate the payload and total cell size - would it better be "48 bytes was chosen..."? The following text then mentions the 5-byte routing and total of 53 - Royan 22:41, 13 February 2007 (UTC)
Jitter not the only reason for small fixed-sized packets (cells)
When engineers were developing X.25 some were already working on digital voice. They realized that time was being lost while the first codec was converting analog data into digial, and that this time loss was proportional to packet size. So the ideal packet size for voice was somewhere between one bit and one byte but the pragmatic demands of the day set it to 128 bytes. Also at that time, pressure from the computer industry demanded larger packets so packet size grew to 4096 (I don't recall it being higher but may be wrong). Jumping back to ATM, certain networks with larger variable-length packets (like Ethernet) made network environments very unpredictable. So just switching to samll fixed size packets (called cells) made ATM networks much more deterministic. Of course, engineers added lots of other stuff to the technology like non-blocking fabrics and QOS to make these networks even more useful. --Neilrieck 13:41, 4 March 2007 (UTC)قاقا باقا
P-NNI is link state but not necessarily shortest-path
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)
Call admission
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)
Too technical
Christ, this article is an extreme example of articles written way too technically. From the lead section alone, I as a layman on the subject cannot even see what the article is about (aside from the word "technology"). SalaSkan 18:08, 8 June 2007 (UTC)
What a stupid comment. This is a technical article. If you're lazy and ignorant it's your fault, not the writer's. —Preceding unsigned comment added by 201.212.143.7 (talk) 23:29, 6 March 2008 (UTC)
also operate at OC-192 (STM64) rates
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)
Standards
ATM is based on the efforts of the International Telecommunication Union-Telecommunications Standards Section (ITU-T) Broadband Integrated Services Digital Network (B-ISDN) standard. It was originally conceived as a high-speed transfer technology for voice, video, and data over public networks. The ATM Forum extended the ITU-T's vision of ATM for use over public and private networks. The ATM Forum has released work on the following specifications:
•User-to-Network Interface (UNI) 2.0
•UNI 3.0
•UNI 3.1
•UNI 4.0
•Public-Network Node Interface (P-NNI)
•LAN Emulation (LANE)
•Multiprotocol over ATM —Preceding unsigned comment added by Mohanchander (talk • contribs) 06:22, 17 August 2008 (UTC)
Archive
I have archived the pre-2007 discussion to Talk:Asynchronous Transfer Mode/Archive 1, not so much because of the volume of the material, but because the discussion was outdated, and the loose format might tend to discourage focused discussions on this talk page. --Bejnar (talk) 20:26, 4 January 2009 (UTC)
Hatnote
Currently this page has a hatnote which reads: Not to be confused with Automated Teller Machine. Since ATM no longer redirects here, is this hatnote still useful, or is it a distraction? --Bejnar (talk) 20:29, 4 January 2009 (UTC)