Talk:Asynchronous Transfer Mode

Archives Untitled /Archive 1:November 2001 to December 2006

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)

See Peter. See Jane. See Jane run. See Peter run. Is this what you're after? If the article has to cover an introduction for numpties then it'll really no longer be much good as an article. Did you get to this page from the "Random article" link or something? —Preceding unsigned comment added by 128.40.46.110 (talk) 09:04, 1 September 2010 (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)

Golden 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)

Lost sentence

At the end of section Why Cells?, there's an open ended sentence:

5-byte headers were chosen because

Does anyone know where the rest of this sentence has gone, or what it should mean? -- 80.136.127.209 (talk) 12:53, 27 January 2009 (UTC)

No, but as a developer I really want to know, because the 5-byte headers are a pain from a word-alignment point of view! 195.188.241.12 (talk) 15:40, 3 February 2009 (UTC)

physical layer

Other than being multiplexed into SONET, what other choices exist for a PHY layer for ATM? I couldn't find out what standard the NIC in that pic of an ATM NIC follows. I sorta read the ATM standard (UNI 3.1) and it talks about ATM running over STP 150 ohm Token Ring cabling @ 155 with 9 pin DIN connector, FDDI fiber @100, "DS3" at @45, MM fiber with ST connector (BFOC/2.5) @155, and "SONET" STS-3c @ 155 (ANSI T1E1.2/94-002R1) with a reference to ANSI T1E1.2/94-002R1 for what PHY layers those are. Next issue, many things are defined in standards, whether they were commercialized and ever used is a different story, so what are the most common ways to the move an ATM stream other than a DSL modem and multiplexing into SONET? What about P2P non-SONET situations? Patcat88 (talk) 23:48, 14 June 2009 (UTC)

One, I think you're confusing layers 1 and 2. Two, talk pages are for discussing ways to improve the article, not a general forum for conversation about the topic. //Blaxthos ( t / c ) 01:15, 15 June 2009 (UTC)

No 53 T-shirts

would be nice to have a photo of someone wearing one of those T-shirts with the number 53 in a red circle with red slash (international prohibition sign). AnonMoos (talk) 12:19, 31 December 2009 (UTC)

lowercase correct

Dgtsyb, you're confused about and confusing several completely different issues in this reasoning of yours: I.150 only uses lower case in the title which is simply ITU-T's house style for titles.

1. As you can see at the ITU link, asynchronous transfer mode is also used on p.2.
2. Carefully edited reference works and publications such as Britannica also use lowercase when explaining acronyms like ATM.
3. Some organizations (including Wikipedia) do not capitalise common nouns in titles, but they never lowercase proper nouns in titles or in text. If something is lowercase in an ITU title, you can be sure it's definitely a common noun, and carefully edited publications like Britannica also lowercase it.
4. Please do not revert again while the issue is being discussed here. --Espoo (talk) 12:53, 1 January 2010 (UTC)

• The second page of I.150 is a list of titles. Page i, 1 and 11 (the body of the text) has it capiltalized everywhere. It is a proper noun and it why it was moved on 24 December 2009 from Asynchronous transfer mode to Asynchronous Transfer Mode. I would consider ATM Theory and Applications, part of the McGraw Hill Signature Series on Telecommunications, to be a carefully edited work. The same is true of Integrated Services Digital Network,, Broadband Integrated Services Digital Network, and Public Switched Telephone Network and many other topic areas in the field of communications, a handful of which from your recent edits you appear to wish to somehow make common nouns. For example, your move of Broadband Integrated Services Digital Network, to Broadband integrated services digital network is quite inappropriate: the only cited work in that article capitalizes ISDN, B-ISDN as well as ATM in their long forms throughout.

• You might find it useful to think whether ATM (or any of these) are properly preceded by any or some. In telecommunications, we neither refer to any ATM nor some ATM; not any B-ISDN and not some B-ISDN. Where it is obvious that we can say any telephone network, or some transport protocol, naturally. Common nouns refer to a class. ATM is not a class. As a counter-example, consider cyclic redundancy code. CRC is not a proper noun. It is a class of algorithms. CRC-32c is a proper noun. Another example: Stream Control Transmission Protocol is a proper noun.

• Another example: You will see that in the articles and in I.150 on ATM, ATM is written out capitalized as Asynchronous Transfer Mode and yet asynchronous time-division switching is not. Asynchronous time-division switching is a common noun referring to the class of protocols of which ATM is a standardized, specific and particular instance.

• You appear upset that I reverted your changes. Once ever so often an editor goes stomping though these pages changing all of the proper nouns to lower case, causing an effort to change them all back. To avoid bother, it is common to simply revert these without much comment. Please consider all such changes as controversial and discuss your intended changes before making them to avoid causing unnecessary work for the regular contributors to these articles. Please also consider reducing that work load by reverting your own recent changes to these articles. Thank you. — Dgtsyb (talk) 14:12, 1 January 2010 (UTC)

1. I.150 would not lowercase "asynchronous transfer mode" anywhere if it were a proper noun. The uppercase use on the other pages is always next to the acronym, as an explanation, and it's a widespread (bad) habit to explain acronyms of common nouns using uppercase. (Bad because it makes people believe these nouns are proper nouns.) Many if not most ITU webpages use lowercase. Even many if not most of those ITU webpages with uppercase are using it when explaining the acronym (and then the non-professional writers/editors, who are only trained as engineers, often get confused and think they should do so elsewhere too). The very fact that carefully edited publications like Britannica use lowercase proves that ATM is a common noun.
2. Believe me, professional editors of encyclopedias know a lot more about grammar and spelling than engineers, and professional editors of reference works have extensive databases of citations at their disposal, on which they base their decisions. When they see, for example, that engineers use both lowercase and uppercase, professional editors use professional methods not at our disposal to decide which is more common and weight these based on whether these are well-edited "important" texts meant for the public or for internal use / colleagues / other engineers. You're right that some carefully edited technical (and legal) publications follow those professions' predilection for the baroque (18th century) practice of uppercasing Important Words even when they are common nouns, but MOS clearly says to avoid unnecessary capitalisation, in other words when other reliable sources use lowercase. Any attempts to use tests like "any" or "some" to decide whether something is a common noun amount to OR and are hopelessly amateurish. I hope you'll agree that it is quite common in English to uppercase words unnecessarily, even when they are not proper nouns. I hope you'll also agree that it is much less common for even amateur writers to erroneously lowercase proper nouns. This will perhaps help you realise how improbable is the idea that Britannica's editors with their training and huge citation database would erroneously lowercase a proper noun.

This has to be interpreted as an attack on the editors that revert your versions. You certainly don't show this 'professional editor' attribute, as you simply ignore the well founded reasoning that make nouns proper or common in technology. Kbrose (talk) 16:55, 1 January 2010 (UTC)

You are once again defending OR as better than following usage in reliable sources. If these use both uppercase and lowercase, MOS clearly states we should use lowercase, especially when general reference works like Britannica also use lowercase (not to mention most ITU and IEC webpages). Your aggressive removal of information is an attack, not my pointing out that we are not even supposed to try to be professional editors and definitely not try to be above them. (I am a professional editor BTW, but that is not why we should follow what I feel is clearly correct.)--Espoo (talk) 17:09, 1 January 2010 (UTC)

1. Your comments about some editors "stomping through" and others being "regular" indicate you have not understood one of the main ideas of WP and that you have a tendency to try to own articles. One of the reasons WP is so good is because people who spend a lot of time reading and writing about a topic may be blind to major problems, including general English spelling "rules" (habits) and to usage in general reference works and even on specialist websites like IEC and ITU. Infrequent visitors, especially when they provide reliable sources, should definitely not be simply shrugged off, reverted, and driven out. It's an especially bad idea to remove well sourced info. I would not have been so upset if you'd changed my edits instead of simply reverting all of them and thereby removing the info that ITU, IEC, Wired Magazine, and Britannica use lowercase. --Espoo (talk) 15:57, 1 January 2010 (UTC)

It is quite obvious that User:Dgtsyb is not confused about these issues, as the editor just laid out explicitly and correctly the very good reasons that are used to establish proper and common noun usage not only in telecommunications, but the English language. The editor's explanations also carry weight based on his substantial and knowledgeable contributions to many of these articles. Not following these criteria is absurd and would be controversial no matter what some reference text might use. It should be noted that many publications, for example, also incorrectly don't capitalize Internet out of some principle, but we still insist on proper usage on WP. The capitalization of ATM and ISDN fully spelled out titles is very notable and in-line with all of our proper noun usage on WP. Kbrose (talk) 16:06, 1 January 2010 (UTC)

With your ridiculous comment "no matter what some reference text might use" you just inadvertently disqualified yourself and put your aggressive reverts into an even worse light because WP policy is very clearly that edits are to be based on reliable sources and specifically general reference sources such as Britannica and to a lesser degree on use in specialist literature and not at all on analyses by any editor, no matter how "substantial and knowledgeable" his contributions have been.

Your comments are simply absurd for other reasons too. There may be reasons for using uppercase, but Dgtsyb was clearly confused in using the illogical and erroneous reasoning "lower case in the title which is simply ITU-T's house style for titles." Re-read this a few times:

Some organizations (including ITU and Wikipedia) do not capitalise common nouns in titles, but they never lowercase proper nouns in titles (or in text). If something is lowercase in an ITU title, you can be sure it's definitely a common noun.'

Stop removing valuable, well-sourced information - that's clearly vandalism. If you feel strongly about having uppercase, change that but don't remove reliable sources showing widespread lowercase use by distinguished organisations and publishers. --Espoo (talk) 16:34, 1 January 2010 (UTC)

It is very interesting that you only consider *your* source as reliable. When the proper usage was documented with reliable sources of equal stature you dismissed them with your own interpretation and choice of citation. This documents your attempts of owning the version you like to see. Kbrose (talk) 16:40, 1 January 2010 (UTC)

Actually, I think that the non-introductory university level textbooks published by McGraw Hill and Prentice Hall (pillars with John Wiley in Engineering texts), are more reliable than ITU-T, ISO/IEC and Encyclopedia Britannica. Of these, the text books are, I believe, secondary sources; ITU-T and ISO/IEC, primary sources; Encyclopedia Britannica, a tertiary source: per WP:PRIMARY. The EB entry, as a clear tertiary source cannot be used to support a position on whether the noun is common or proper as that is certainly not the topic of the EB entry. The primary sources cannot be analyzed to determine a part of speech. Therefore, it appears that Espoo's conclusions should be considered original research. I do not believe that the removed mis-cited sources can be considered reliable sources for the conclusions advanced by Espoo. — Dgtsyb (talk) 00:01, 2 January 2010 (UTC)

I specifically did not dismiss the single reliable source provided supporting uppercase. I simply pointed out that reference works like Britannica base their choices on a comprehensive view of usage whereas the editor of the McGraw Hill book is only one person's or a small group's personal preference. And MOS clearly says to avoid unnecessary uppercase, which is clearly the case when both are used by reliable sources. Since your view is fighting the combined windmills of Britannica, ITU, and IEC, the case is especially clear. --Espoo (talk) 16:50, 1 January 2010 (UTC)

Where is Britannica's extensive research on the usage documented? This sounds more like personal research to me. ITU, except in titles which is a different matter (house style), does what other sources on topic do: namely expand it once, capitalized in the introduction and then simply use the acronym throughout the remainder of the document. It saves both paper and ink that way. This is what ITU-T Recommendation I.150 does, as does ATM Theory and Applications, McGraw Hill, ATM Volume III, Internetworking with ATM, Prentice Hall. ISO/IEC does the same thing in, for example, ISO/IEC 13246:1997(E) and ISO/IEC 13247:1997(E). So I don't think that ITU and ISO/IEC documents support your conclusion.

I do recall from earlier working papers on both ISDN and ATM that, before they were standardized, we used to refer to them in all lower case and after standardization in upper case. Perhaps Britannica is following this arcane usage.

The RFC database is a good way to ferret out common usage. In the following RFCs it is always capitalized as Asynchronous Transfer Mode: RFC 1167, RFC 1340, RFC 1391, RFC 1392, RFC 1483, RFC 1539, RFC 1573, RFC 1577, RFC 1599, RFC 1607, RFC 1679, RFC 1680, RFC 1700, RFC 1705, RFC 1709, RFC 1718, RFC 1754, RFC 1821, RFC 1983, RFC 2071, RFC 2225, RFC 2226, RFC 2233, RFC 2299, RFC 2381, RFC 2400, RFC 2502, RFC 2600, RFC 2626, RFC 2684, RFC 2761, RFC 2799, RFC 2863, RFC 2885, RFC 2955, RFC 2999, RFC 3015, RFC 3031, RFC 3035, RFC 3038, RFC 3094, RFC 3116, RFC 3133, RFC 3134, RFC 3175, RFC 3199, RFC 3215, RFC 3292, RFC 3293, RFC 3294, RFC 3295, RFC 3299, RFC 3300, RFC 3336, RFC 3337, RFC 3353, RFC 3355, RFC 3386, RFC 3441, RFC 3471, RFC 3496, RFC 3499, RFC 3525, RFC 3600, RFC 3700, RFC 3809, RFC 3815, RFC 3819, RFC 4048, RFC 4110, RFC 4221, RFC 457, RFC 4294, RFC 4297, RFC 4364, RFC 4365, RFC 4368, RFC 4381, RFC 4447, RFC 4454, RFC 4542, RFC 4553, RFC 4603, RFC 4638, RFC 4679, RFC 4710, RFC 4717, RFC 4766, RFC 4779, RFC 4782, RFC 4803, RFC 4816, RFC 4821, RFC 4840, RFC 4842, RFC 4905, RFC 4906, RFC 4949, RFC 5000, RFC 5070, RFC 5085, RFC 5254, RFC 5287, RFC 5494, and the list goes on... Only once in one RFC that I can find is it referred to as asynchronous transfer mode: RFC 3819, and in that RFC it also appears once as Asynchronous Transfer Mode. This list spans 20 years of common usage. 156 occurrences of Asynchronous Transfer Mode and 1 occurence of asynchronous transfer mode.

The ITU Q-Series breaks down this way: Asynchronous Transfer Mode, Q.1201, Q.2010, Q.2100, Q.2110, Q.2120, Q.2130, Q.2140, Q.2144, Q.2761, Q.2762, Q.2763, Q.2764, Q.2971; asynchronous transfer mode, none. I-Series: Asynchronous Transfer Mode, I.150, I.312, I.326, I.361, I.364, I.365-1, I.365-2, I.365-3, I.374, I.555, I.731, I.751; asynchronous transfer mode, I.321, I.327. Perhaps a confusion to some is that some documents talk of the general aspects of an asynchronous transfer mode. This is because this usage is as a common noun. At the time we knew that an asynchronous transfer mode would eventually be standardized but it was not certain which specific proposals would be adopted. (We didn't even known the cell size, for example). But once the general aspects were decided and all of the specifics standardized, it became commonly referred to as the Asynchronous Transfer Mode, as in the one standardized not a concept of which only the general aspects have been determined.

I don't think I will give it much more effort. I am sorry, but I cannot subscribe to your theory of Britannica throughly researching common usage in this case, or in that of ISDN or B-ISDN for that matter. — Dgtsyb (talk) 21:30, 1 January 2010 (UTC)

A few more additions. ATM Forum documents: CS 107, CS 115, CS 125, CS 126, CS 127, CS 135, CS 140, CS 141, FBATM 139, LANE 38, LANE 112, MPOA 114, MPOA 129, NM 19, NM 27, NM 58, NM 73, NM 95, NM 103, NM 122, NM 184, PHY 43, PHY 79, PHY 86, PHY 110, PHY 128, PHY 130, PHY 133, PHY 134, PHY 138, PHY 142, PHY 143, PHY 144, PHY 162, PNNI 66, PNNI 81, RA 104, RA 105, RA 106, RA 123, RBB 99, RBB PY 101, SAA 108, SAA 109, SAA 124, SEC 100, TEST 30, TEST 42, TEST 44, TEST 51, TEST 52, TEST 67, TEST 70, TEST 90, TEST 137, TEST CSRA 111, TEST CSRA 118, TEST TM 131, TM 121, VTOA 83, VTOA 89, VTOA 113, VTOA 119, VTOA 120, VTOA 132—spelling Asynchronous Transfer Mode, all; asynchronous transfer mode, none. A decade of usage... — Dgtsyb (talk) 22:20, 1 January 2010 (UTC)

One more note: you do not seem to want to consider how the term is used by Engineers and yet the term is not commonly used outside of the field of Engineering. Outside of the field of Engineering, an ATM is a machine out of which you take all your money; inside the field of Engineering, ATM is a machine that takes all your money. ;) — Dgtsyb (talk) 22:01, 1 January 2010 (UTC)

Late to the party, I'm not going to bother responding to all the points above. Suffice to say, in my experience the common usage of Asynchronous Transfer Mode is always capitalized; I see no reason why Wikipedia should be the exception. //Blaxthos ( t / c ) 22:08, 1 January 2010 (UTC)

Take a look at Proper Noun. Asynchronous Transfer Mode is a specific standard and can only be thought of as a proper noun and must, therefore, be capitalised. As one cannot guarantee that other authors have correctly followed syntactical requirements, one should not base their argument on common usage. One should instead base their argument on syntactical principals. From this perspective, only capitalised ATM is permissible. This approach may seem contrary to WP philosophy, however, it is the only way to resolve conflicts such as this where common usage is often grammatically incorrect.Internet/internet, as mentioned earlier, being another example. --Spuzzdawg (talk) 22:42, 18 December 2010 (UTC)

This article needs help.

I added a few references and starting adding inline citations supporting the copy, but didn't make it past the lede. Much of the first part of this article is charged with diverging non-neutral points of view unsupported by the secondary sources I have. Other passages read like an attempt to justify its design. Further passages read like a tutorial or instruction manual for designing networks. Once past those there is a diagram and a few passages and it stops. This article needs a major rewrite from a neutral point of view. It is just too much for me to engage in on my own at the moment. In the mean time, if anyone can clean up some of these passages, I can contribute some secondary sources for them. — Dgtsyb (talk) 14:15, 2 January 2010 (UTC)

IBM Turboways ATM NIC PHY

Could anyone please tell me what is the PHY (physical layer) protocol used by the depictured IBM Turboways ATM NIC and similar cards by FORE Systems? Could it even be SDH STM-1? (The speed of 155 Mbit/s matches STM-1 exactly.) —Preceding unsigned comment added by 95.220.176.115 (talk) 01:37, 1 November 2010 (UTC)

I don't know this NIC, but there are two 155 Mbps (155 520 kbps) PHY standards given in ITU-T Recomendation I.432.2. One is SDH STM 1 (Sonet STS/OC 3c) and the other is the cell based phy, sometimes called the native ATM phy. This cell based phy has exactly the same cell throughput as STM 1 (149.760 Mbps), because an (extra) idle or PHY layer OAM cell is added after each 26 ATM layer (data) or idle cells. Graham Fountain 14:12, 1 December 2010 (UTC)

Current Uses of ATM

Can anybody add a section on the uses, particularly current uses, of ATM?

It's my understanding that although it's not become the ubiquitous network standard is was touted as in the 90s (Fast/GB Ethernet did), it's still being used in telecoms infrastructures, and, I have been given to understand, some parts of broadband Internet access.

Put somewhere near the start, this would, I think, be a useful and (possibly) interesting addition to indicate the relevance (or not) of this article. Graham Fountain 14:23, 1 December 2010 (UTC)

ATM (Another Technical Mistake)

This is to put some humour into the article. I sometime back remember reading a technical magazine and the author called ATM Another Technical mistake. I found it funny and think it could make the article interesting, at least mentioning that people in the technical industry do refer it by that name

ATM (Asynchronous Transfer Mode) or (Another Technical Mistake) - An attempt by the phone industry to turn your networking problem into something they know how to tariff

See this link [[1]] gathima (talk)