Subject: (ION) RFC 1483 extra twist

From: "Albert Manfredi" <[email-masked]>
Date: Tue, 9 Mar 1999 11:10:57 -0500

One possibility not discussed in RFC 1483 Section 5 (VC Based
Multiplexing) is the idea of using the called party AESA's ESI as a
MAC destination address, the calling party ESI as the MAC source
address. In cases where you need to bridge an AAL5 frame from an ATM
net to an IEEE 802 net, the AAL5 frame in principle could avoid ever
carrying any MAC DA/SA fields.

Conducting your basic paradigm shift, in ATM the function of the MAC
DA/SA is carried out during SVC signaling. So if there's no problem
with SVC setup time and no scaling problem with dedicating one VC to
a MAC DA/SA combination, then is it not possible to use this more
"native ATM" approach in the ATM net? Otherwise, RFC 1483 Section 5
says to send the MAC DA/SA with each AAL5 frame (for bridged
frames).

One example where this would work well is in the case of long-lived
pt-mpt SVCs, used to carry MAC multicasts over an ATM backbone. The
called party and calling party ESIs can be cached at the egress
switch and used to format each of the outgoing MAC frames.

Any comments, either way?

Bert
[email-masked]

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Dilip Pandit <[email-masked]>
Date: Wed, 17 Mar 1999 20:27:56 -0800 (PST)

Hi Bert,

I do not see the idea of using ESI as the DA/SA MAC addresses in bridged
PDUs to be feasible since the IEEE 802 MAC addresses in ATM - 802 bridging
may not map one-to-one correctly. The ESIs carried during signalling may be
entirely different from the MAC addresses in the BPDUs when an ATM network
acts as just an intermediate (transit) MAC layer network (assuming the
existence of a bridging application over AAL5). Also, reconstruction of MAC
headers at egress points will be a costly process, if not impossible.

All comments welcome.

P.S: Your query might elicit better response on the CR list.

--Dilip

-------

 From: "Albert Manfredi" <[email-masked]
 To: "ION Group" <[email-masked]
 Subject: (ION) RFC 1483 extra twist
 Date: Tue, 9 Mar 1999 11:10:57 -0500

 

 Bert

---

From: "Albert Manfredi" <[email-masked]>
Date: Thu, 18 Mar 1999 11:43:21 -0500

In thinking about this more, I've come up with a few conclusions:

1. Yes, the lower risk (and more brute force) approach is certainly
to send the MAC addresses as part of the data frame, as RFC 1483
describes.

2. The notion of using the ESI field to carry the MAC address for
bridging purposes is similar to the notion of encapsulating the IPv4
address in an IPv6 address field. In other words, an attempt to
integrate two schemes rather than keeping them completely separate.

3. If one uses an AESA that does not depend on the ESI field to find
the ATM interface, e.g. an encapsulated E.164 format where the ESI
is free, then I see no problem with using this bit of cleverness. In
principle, the egress switch could format IEEE 802 LAN-type frames
based on the VC on which the data arrived. After all, the egress
switch went through a signaling procedure when it established that
VC, so it can cache the source and destination ESI that were
exchanged during setup.

4. Of course, this would result in scaling problems, especially if
the ATM net is a backbone net rather than an access net. But either
much faster VC setup/teardown times or use of ATM in other than
backbone situations would bypass this scaling problem. (Example:
using ATM over ADSL, for access rather than backbone use, would be a
candidate for such a scheme. The assumption being that the data
traffic will find its way to a standard packet-switched Internet
backbone.)

5. I guess I've always found the standard layered approaches to be
practical, yes, but unappealing.

Bert

-----Original Message-----
From: Dilip Pandit <[email-masked]>