It seems that, with the concept of bridged protocols (as it is called in RFC2684) , we have to understand Ethernet protocols and non-Ethernet protocols.
In the non-Ethernet protocols, we can include : FDDI (ISO/IEC 9634) In the Ethernet protocols, we can include : 802.3, Token Bus 802.4, Token Ring 802.5, DQDB 802.6, BPDU 802.1
I didn't indicate Wi-Fi 802.11 because bridged protocols is a concept for carrying layer-2 protocols over ATM.
Is it your understanding ? Thanks for the comments Michelot
These are different media. When using that RFC for bridged protocols, those are the different media that they considered. A bridged protocol is one that is not routed; i.e. the original MAC source and destination address are preserved just as they would when going through a bridge. Examples of bridged protocols would be NETBIOS, SNA, etc., or any other protocol that is not being "routed" by the device. The RFC is describing how to encapsulate frames of different layer 2 media when the ATM device is acting as a bridge.
RFC 2684 is very basic. It simply uses ATM as a static link, and allows either LLC/SNAP encapsulation or it allows the IP packets to be carried over a specially assigned VC that is only used for IP packets. So I don't see that RFC allowing ATM switches to behave like routers. This is a very simplistic use of ATM.
There are somewhat more advanced models described in RFCs, RFC 2225 (IPv4) and 2492 (IPv6), where ATM is assumed to provide more complete link layer services. These also specify how one maps IP addresses to ATM NSAPAs. In these RFCs, IP is directly over ATM. So ATM nets are used dynamically, but still, each ATM net is only assumed to be an island in an IP ocean. Separate ATM nets are not interconnected directly, through shortcuts. Separate IP networks are only tied together via IP routers, even if both networks are ATM nets.
Also, RFCs 2022 and 2337 for IP (or any layer 3) multicast support over ATM networks.
RFC 2332 allows ATM shortcuts to be established between IP subnets in different ATM networks. So this really goes way beyond RFC 2684. I think that *now* you are providing what one might call an ATM "routing" function, between IP subnets. In fact, this RFC bypasses the IP routers, which is in part why it doesn't get used much. People want IP routers between IP nets.
The ATM Forum also wrote specifications that do similar things. LAN Emulation (LANE) is somewhat like RFC 2225, except that it provides an Ethernet-look-alike layer. So you have the ATM NSAPA and the MAC layer over that, and then you can layer IP on top of that, or any other layer
3 protocol. It makes the ATM net appear to be Ethernet or other IEEE 802 LAN.
Multi Protocol over ATM (MPOA) is sort of like RFC 2225 and 2332, in that it too provides for ATM shortcuts to be established between different layer 3 network islands.
In those days, in the mid 1990s, it was still possible to see a future where ATM nets would span the globe. I think that today, IP has assumed that role, however. So it makes less sense, perhaps, to think about MPOA or RFC 2332. ATM islands are possible, but IP islands over bigger ATM nets are not so likely.
The Ethernet protocols are 802.3. While Token Ring can be kind of sort of bridged to Ethernet through brute force and awfulness combined with finesse and fancy footwork it's not really happy doing that. It's definitely not an Ethernet protocol though. Was 802.4 ever actually implemented anywhere?
So, we can imagine a backbone router with ATM interfaces and being either VC end point or not VC end point.
(1) Suppose the router VC termination
IP datagrams are extracted from (VP1, VC1) ATM cells, routed on an output interface, inserted in (VP2, VC2) ATM cells, and transmitted to the following router. Is that router could be considered as an ATM switch? We have ATM switching, but it's not a pure ATM switch. How would you call that device only at the ATM layer? The router could be also (1.1) VCC end point or not (1.2) VCC end pont.
In the case (1.1), is it that you call ATM nets? In the case (1.2), VCC could include the successive links VC1, VC2 and it is an ATM switch. Is it realistic?
(2) Suppose the router not VC en point
IP datagrams are extracted from (VP1, VC1) ATM cells, routed, and inserted in the same link (VP1, VC1). The VC is passing through the both router interfaces, realistic?
I need to see that. I emulated the reply of anoop with the layer 3 but it was a joke, because it seemed that he forgot IP over RFC2684. In fact, ATM is connected mode, except at the SVC establishing where the SETUP is transmitted using the source routing PNNI protocol.
It's an another case (apart bridged RFC2684 ) where we have devices with Ethernet addresses without a physical Ethernet network. I think that LANEs are not really used today.
Today, ATM is widely used in the access networks part, for ADSL (between the modem and the BAS) and UMTS (between the B-node and the RNC).
RFC 2225 does with ATM addresses exactly what ARP does with MAC addresses. That is, there's an ATMARP server in the ATM network that resolves IP addresses to ATM NSAPAs. So if you use the SVC option in RFC
2225, you end up setting up an SVC for every IP session. The ATM SVC stays up longer than the IP session, in case you need it again in a short time. Because setting up an ATM session takes some amount of noticeable time.
Or you can just set up a number of PVCs in your ATM island, which of course is a fairly unimaginative and uninteresting way of doing IP over ATM, although pragamatically attractive maybe, in smaller office networks.
Yes, ATM is connection oriented two layers below the TCP layer (which is also connection oriented). This is part of ATM's problem in dealing with IP and also in scaling up as we have become accustomed to with IP.
Imagine a world where web browsing were done with ATM only. This was the idea, back in the days when B-ISDN was considered to be the next big thing (say, late 1980s). Web browsing would have been quite a different experience from what it is now. All those switches out there having to maintain state for all those sessions. And all that ultra-fast signaling to continuously switch sessions as people click on different URLs. It would have been very difficult, on any sort of large scale.
True. But I wouldn't bet on ATM underneath the next generation of xDSL (VDSL). For some things, like TV to homes over telephone lines, ATM would be ideal. But there are other applications where we have gotten used to the advantages (*and* disadvantages) of using an IP solution. It would be hard to conceive of ATM taking that global backbone role any longer.
Even when ATM is used over ADSL, its capabilities are hardly required. Mostly you end up doing UBR service and PPP. The telcos never did deploy ATM in the way it had been intended, never gave customers a lot of (or any) signaling control. I think that's in large part why it didn't succeed. Instead, IP is constantly being improved to where it is becoming the multimedia backbone protocol. Actually, I'd say that the introduction of RTP (RFC 1889) in 1995 was a very good indicator that ATM was in big trouble. Also the fact that the telcos did not aggressively introduce services (such as TV over telephone lines) that would have depended on ATM's attributes.
:Imagine a world where web browsing were done with ATM only. This was the :idea, back in the days when B-ISDN was considered to be the next big :thing (say, late 1980s). Web browsing would have been quite a different :experience from what it is now. All those switches out there having to :maintain state for all those sessions. And all that ultra-fast signaling :to continuously switch sessions as people click on different URLs. It :would have been very difficult, on any sort of large scale.
The point you make about how browsing would have to make with ATM is interesting, but I have to question the suggested timing a little.
Tim Berners-Lee's CERN proposal wasn't until 1989, and didn't really get any action until 1990. B-ISDN was being worked on just about the same timeframe, with the decision to use ATM made about 1990, but the first official specs not issued until 1992.
Thus, I would suggest that "early 1990's" should be substituted for "late 1980s".
The first ISPs that I know of were forming at the end of the 1980's, with user access via direct dialup modem and via packet switch networks. By 1990, the price of small-buffered X.25 in Canada [the equivilent of telnet's usual character mode] had fallen enough to start making it cost effective for wide spread use -- that's about the point at which the X.25 providers started offering accounting by time or total volume rather than at high per-packet rates. I worked for some of the first transnational ISPs in that time frame.
It was too early to have heard of WWW or B-ISDN when I left that line around fall 1991, but we were starting to provide on-demand international information links (X.25 based). I think that if anyone had suggested HTML to us around then, that we would have implimented it a bit differently than you suggest ("ultra fast switching between sessions"): we would more likely have implimented it as the user connecting to an ISP, and the ISP doing caching and X.25 or modem dialouts to fetch additional information [*]. That probably wouldn't have scaled to anything even remotely close to the current situation, but it must be remembered that at the beginning of the 1990's, with the first browsers still years away, what may have been the largest transnational ISP at the time [The Association for Progressive Communications, aka APC] was just in the process of building up to a dozen nodes, and dirt-cheap communications amongst tens of millions of nodes was pretty much unimaginable at the time.
[*] Okay, the 'caching' part is perhaps more hindsight rather than an accurate representation of what I would have implimented. I -did- impliment dynamic server-based X.25 connections for information exchange. Thinking back, I recall that I didn't pioneer transparent data access between nodes: PopTel Communications's "Labournet" [yes, with a 'u': it was UK based] was originally on such a system, put together by the Swiss company GeoNet. GeoNet was, though, a closed architecture that ran on an obscure kind of server; the work we did then at the APC was Unix based, running on 80286's and 80386's.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.