| Author |
Message |
Michelot
Guest
|
 Posted:
Sat Nov 27, 2004 11:43 pm Post subject:
Bridged protocols |
|
|
Bonsoir,
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 |
|
| Back to top |
|
 |
anoop
Guest
|
| Posted:
Wed Dec 01, 2004 5:34 pm Post subject:
Re: Bridged protocols |
|
|
Michelot wrote:
| Quote: | 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
|
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.
Anoop |
|
| Back to top |
|
|
Michelot
Guest
|
| Posted:
Thu Dec 02, 2004 12:50 am Post subject:
Re: Bridged protocols |
|
|
Bonsoir Anoop,
| Quote: | 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 made a crasy confusion, I meant IEEE instead of Ethernet.
FDDI is not a protocol coming from IEEE.
And Ethernet is only specified in IEEE 802.3.
| Quote: | 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.
|
An important thing
| Quote: | The RFC is describing how to
encapsulate frames of different layer 2 media when the ATM
device is acting as a bridge.
|
I like that for layer 2, but it sounds bad for layer 3 !
"The RFC is also describing how to encapsulate frames of different layer 3
when the ATM device is acting as a router".
Regards,
Michelot |
|
| Back to top |
|
|
Albert Manfredi
Guest
|
| Posted:
Thu Dec 02, 2004 2:48 am Post subject:
Re: Bridged protocols |
|
|
"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:
[RFC 1483 updated to 2684]
| Quote: | I like that for layer 2, but it sounds bad for layer 3 !
"The RFC is also describing how to encapsulate frames of different
layer 3
when the ATM device is acting as a router".
|
Salut Michelot,
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.
Bert |
|
| Back to top |
|
|
J. Clarke
Guest
|
| Posted:
Thu Dec 02, 2004 8:56 am Post subject:
Re: Bridged protocols |
|
|
Michelot wrote:
| Quote: | Bonsoir,
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
|
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?
| Quote: | 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
|
--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net) |
|
| Back to top |
|
|
Rich Seifert
Guest
|
| Posted:
Thu Dec 02, 2004 9:14 pm Post subject:
Re: Bridged protocols |
|
|
In article <com41012uu7@news3.newsguy.com>,
"J. Clarke" <jclarke@nospam.invalid> wrote:
| Quote: | Was 802.4 ever actually implemented anywhere?
|
It saw a fair amount of use, for a while. I was one of the authors of
802.4, and former chief technical guru for a startup company that
specialized in 802.4 (Token Bus, MAP) products back in 1984-87.
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com |
|
| Back to top |
|
|
Michelot
Guest
|
| Posted:
Sun Dec 05, 2004 6:44 am Post subject:
Re: Bridged protocols |
|
|
Bonsoir Bert,
| Quote: | 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.
|
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?
| Quote: | 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.
|
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.
| Quote: | 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.
|
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.
| Quote: | 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.
|
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).
Regards,
Michelot |
|
| Back to top |
|
|
Patrick Schaaf
Guest
|
| Posted:
Sun Dec 05, 2004 11:56 am Post subject:
Re: Bridged protocols |
|
|
"Michelot" <mhostettler@wanadooNOSPAM.fr> writes:
| Quote: | 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?
|
If, and only if, the forwarding decision is made based on ATM (VP/VC)
information ONLY, it should be called an ATM switch.
If the forwarding decision is made using Ethernet headers / MAC addresses
ONLY, it should be called an Ethernet switch (in my opinion).
If the forwarding decision is made using IP headers / addresses ONLY,
it should be called an IP router.
At least, that's how I would call them. Hope this helps.
best regards
Patrick |
|
| Back to top |
|
|
Albert Manfredi
Guest
|
| Posted:
Mon Dec 06, 2004 4:55 am Post subject:
Re: Bridged protocols |
|
|
"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:
| Quote: | 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?
|
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.
| Quote: | 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.
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.
|
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.
| Quote: | 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).
|
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.
Bert |
|
| Back to top |
|
|
Walter Roberson
Guest
|
| Posted:
Mon Dec 06, 2004 9:14 am Post subject:
Re: Bridged protocols |
|
|
In article <I89x41.EM7@news.boeing.com>,
Albert Manfredi <albert.e.manfredi@nospam.com> wrote:
: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.
--
Warhol's Law: every Usenet user is entitled to his or her very own
fifteen minutes of flame -- The Squoire |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in