The IP over ATM Mailing List Archive by date

[bryang@eng.adaptec.com (Bryan Gleeson)]

[ Greg wrote ...]

> I very much agree that there should be a single default encapsulation
> (for some odd reason, I thought we had one!). At any rate, a new default
> encapsulation would have some costs, such as:

>    1.) time-to-market (products will be delayed to change to the new default)
>    2.) complexity (the old default would still have to be supported)
>    3.) the reputation of the IETF (a fundamental redesign after two 2 years?)
>    4.) market uncertainty (LAN emulation is starting to look a lot better!)

I don't think the picture painted of the implications of a new encapsulation
are quite that bad. Anyway I think it is something we have to live with.
If we don't have one then we are saying that a router / edge device / layer
3 packet forwarder may _never_ use a multicast server, as it has no way of
recognizing its own transmissions. The problem with a full mesh approach is 
that it doesn't scale as it requires N*N VC end points for N devices. Dropping
in a multicast server or two will significantly reduce the number of VC end
points needed. Of course this comes at the cost of an extra hop(s) in the data
path but this trade-off is one that I believe we should allow to be made,
rather than forcing it by the protocol spec.

Given that I think a new encapsulation is needed - should it be the _default_
encapsulation for point-to-multipoint connections ? I think so. We could
say that it is an option that could be negotiated in the way that null encaps
is currently negotiated. However right now the presence of a multicast server
is completely transparent to a "regular" cluster member, which is good,
but a member has no way of knowing in advance if its transmissions might be bounced
back again. The group just seems to have fewer members than it actually has, 
and the mulitcast server appears just like any other cluster member. Negotiating
a different encapsulation if a multicast server was involved would cloud this
transparency.

It is interesting to note that there is a parallel discussion going on in
the ATM Forum regarding a new encapsulation for LANE 2.0 or LANE ++. This
time it is to introduce LLC/SNAP to allow VCC sharing and better scalability, 
given that LANE may now be used where MPOA requires bridging. Thus the
equivalent accusation could be made in the reverse direction (the ATM Forum
is making a fundamental design change after 2 years and Classical IP is
starting to look a lot better !) I think both charges are a bit unfair. 
It is simply a consequence of expanding the problem space that you are 
trying to solve. Something which meets the requirements of the original
problem space (IP/ATM unicast only, LANE as a replacement for a single
ethernet segment) may not be suitable for an expanded problem space 
(IP/ATM multicast, LANE over WANS). Of course if you know that the expanded
problem space exists when you are tackling the more limited one, it makes
sense to anticipate what might be needed - but I don't think the IETF
or the ATM Forum make any claim to infallibility here.


[ Andrew wrote ...]

> Your option (3) seems like the only suitable encaps that could be
> extended for multiprotocol use. That would seem to be the most important 
> requirement for implementation of a multiprotocol multicast-over-ATM
> solution.

I agree. The IANA (?) / IETF (?) already has an OUI for use with
ethernet multicasts. It is 01-00-5E. Could we reuse that one ?
Otherwise I think it costs $1000 to buy one from the IEEE. (Last 
time I looked there were about 1000 subscribers to this list.
Maybe if everyone chips in $1 ... :-)


[ Fong wrote ...]

> And Grenville is right, null encapsulation is always an option. The catch
> is that very few (if any) RFC1577 implemenations will do signaling negotiation
> and set the encapsulation according to the signaling. Just to get 
> a feel for how many implementations can negotiate encapsulation 
> (i.e. if one can take more than one B-LLI and select the one it supports,
> return the selected B-LLI in CONNECT message and set its Data 
> encapsulation accordingly.) Can we do a poll on how many vendors have
> done this in current RFC1577/RFC1755 implementations ? 

Right now I'm not aware of any implementations that support either
BLLI (or MTU size) negotiation. Ours doesn't at this time, anyway. I think 
the ease or difficulty in supporting the null encapsulation option depends
on how the current system is designed, as it takes in VCC management
issues as well as just the encapsulation type. For example if you
find out the IP address at the other end of an incoming VCC by sending
an InATMARP request down the incoming VCC then that wouldn't work. You would
have to either send an InATMARP request to the ARP server or wait for
reverse traffic and ATMARP the ARP server, which may or may not be
what is done already. I suspect that BLLI negotiation is regarded as
a "Release 2.0" sort of issue.


Bryan Gleeson,
Adaptec.