The IP over ATM Mailing List Archive by date

[manfredi@engr04.comsys.rockwell.com (Albert E. Manfredi)]

I've read RFC-1577 and _Classical IP and ARP over ATM Update (Part Deux)_, 
draft-ietf-ipatm-classic2-00.txt, dated 31 August 1995. Hoping not to 
cover too much old ground (am new to this list), I'd like to make a few 
comments on these.

. It is unfortunate that we have been stuck with an address resolution 
problem, between ATM and IP, for the foreseeable future.

. The sequence RFC-1577 and Part Deux beg for an ongoing series, with Part 
Trois, Part Quatre, etc. to follow, each one with a new address resolution 
server. For example, we now have an ATMARP server and an NHRP server 
defined. Presumably, Part Trois will have a 2ndHRP server defined, and so 
on. And at each hop, the option would be to default back to RFC-1577 and 
routers or perhaps to the next lower tier-HRP.

. It seems to me that a scheme which would more gracefully scale upward 
might be considered. A scheme which would look basically identical to RFC-
1577 for small, isolated ATM nets, but which would seamlessly grow to 
something entirely different as the ATM portion of the net pushes out. Of 
course, one can always keep this scheme shackled by Ethernet-like 
structures, but it would not _depend_ on such constraints.

Some ideas to this end might be as follows:

1. Replace the term ATMARP with ATMDS (ATM Directory Service). For small, 
isolated ATM nets, the difference is merely in the name. But as the ATM 
net grows, the difference is in the nature of this beast. The ATMDS would 
evolve into a system similar to, or even replacing, the Domain Name System 
(DNS). It would certainly operate at that hierarchical level. By contrast, 
ARP is limited to local nets, LANs, in concept and mindset, if nothing 
else. The ATMDS is simply a service that maps the global IP address with 
the equally global ATM address. As the ATM net grows, this function will 
require increasingly more DNS-like mechanisms, and will look less and less 
like any sort of ARP.

2. The router is a box which must link the ATM net to the outside world. 
But as that local ATM net grows, the router should become an edge device 
on the periphery of the greater ATM net, rather than remaining tied to the 
LIS.

3. For small, isolated ATM nets, any IP address outside the local ATM LIS 
will naturally be sent via VC to the router. As the ATM environment grows, 
several routers might appear connecting the growing ATM cloud to the 
outside world.

4. Now a decision on which router to use for any given IP address is 
required. For this, the ATMDS can be made to keep a table of, let's say, 
the three most desirable routers, in priority order, to reach that IP 
destination. This would permit a sudden failure in the closest router to 
be bypassable when setting up that VC to the world outside the ATM cloud. 
In other words, call setup would retry using the second and third choices 
if the first tries don't work.

5. In order for the ATMDS to build these lists, the routers would have to 
provide regular updates of nets reachable and the number of hops required. 
For any given non-ATM IP destination, the ATMDS will only cache the first 
three (or two or one, this is a detail). I don't think anything in the 
above is particularly difficult. Of course, these servers will have to 
keep each other updated, but that's true for ATMARP as well.

6. For IP destinations available within the ATM cloud, the ATMDS only 
needs to provide one ATM address for that host. Of course, an ATM hosat 
with dual ports (sort of a dual-homed ATM host?) could have the two ports 
listed in priority order, much like those optional routers to the outside 
world were listed.

7. For firewalls and network administration, I don't think routers or IP 
subnets are needed. The "natural" model to use here would be the telephone 
PBX model. That is, ATM addresses can be part of a local PBX-like 
structure, using the hierarchical format of ATM addresses, and firewalls 
can be placed in the path of all traffic to a particular ATM local 
network. (For example, an office might have ATM addresses +1 (703) 412-
XXXX assigned to it. The firewall can be placed in the path of any call to 
exchange 412. Note that one could set up even smaller groups of numbers, 
filtering out only calls to +1 (703) 412-6XXX for instance.) The IP subnet 
model which Part Deux and RFC-1577 maintain is only useful if IP routers 
tie one to the outside world. But one of ATM's claim to fame is that 
routers are no longer needed to reach the world.

8. To reach a destination, one might have to traverse ATM and non-ATM 
environments. This should not be a problem, because the ATMDS servers of 
one ATM cloud do _not_ communicate with the ATMDS servers of an isolated 
ATM cloud. Hence, if the destination host is an ATM host, but in an 
isolated ATM cloud from the calling party, the calling party will not be 
aware of the destiation's own ATM address. Rather, the calling party will 
only be given the ATM address of the needed router(s).

I hope this conveys the idea. As you see, RFC-1577 and Part Deux would be 
virtually unchanged, as long as the ATM cloud is very small, or as long as 
people insist on preserving the historical contraints presented by 
Ethernet, Token Ring, and FDDI. But as (if?) the ATM cloud is allowed to 
grow, I think this scheme would prevent the discrete steps which we would 
have to follow with the RFC-1577 and Part Deux sequence.

Too bad the addressing schemes don't match, though!

Bert
manfredi@engr05.comsys.rockwell.com