Bridged protocols

Archived from groups: comp.dcom.lans.ethernet (More info?)

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

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonsoir Anoop,

> > 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.

> 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

> 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

Archived from groups: comp.dcom.lans.ethernet (More info?)

Michelot wrote:

> 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?

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

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonsoir Bert,

> 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?

> 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.

> 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.

> 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

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:

> 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.

>> 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.

> 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