The IP over ATM Mailing List Archive by date

[schulter@zk3.dec.com]

I just thought I would chime back in since I'm back from USENIX and catching
up on things.

Markus wrote:

> I agree with Scott and Jim that we can't solve this issue in just a few days
> on the mailing list. Hopefully, there will be enough time for a discussion
> in Los Angeles. This topic should get a well-known place on the agenda of
> some wg, at a time when ipng, rolc and ipatm folks can attend. Or maybe a
> separate session just for this. But please: earlier than 9:45pm and more than
> 15 minutes (that's about the time we had in Dallas).

Yes.  I think there has been enough discussion here and on the IPv6 mailing
list to show that there's sufficient interest to justify spending a significant
part of one session on IPv6 over ATM issues.

> Anyway, this shouldn't keep us from identifying the issues and starting
> to discuss things?

Nope, we should be trying to come up with a list of issues to discuss. Good
idea.

> Back to Joel Halpern's concern:
>
> [It's good you bring this up a second time. I almost forgot about your first
>  mail because I've been away from my office for a few days.]
> 
>> Unfortunately, what it requires instead is a fully configured 
>> hierarchy of servers covering the entire ATM fabric.  Given taht in 
>> this proposal the servers are NOT running routing, there is 
>> complexity required to maintain the heirarchy.  With a heriarchy of 
>> routers, the routers maintain the hierarchy themselves.

And here's my response to Joel's concerns:

First, lets take a look at my proposal, and my very brief presentation
at Dallas.  First, there is the hierarchy of NDS servers that form the
Logical Link.  These servers really do nothing more than provide a
way for nodes to multicast.  At his level (simply the subnet level), they
are not involved in routing and are used to move ND packets between nodes.
In fact, in the latest version of the draft which I'm working on I've
got this entirely stateless, which means it's very easy to implement.
These servers are not running any protocol, routing or otherwise, they
just relay packets to make those parts of ND which require multicasting
work.  This completely maintains the ND and subnet semantics.  There
is also no need for address resolution servers or server synchronization
since it is always the solicited node which replies to each solicitation.
Further, when routers are introduced to the LL, they will function
just as the do for IPv6 over legacy LANs and can use redirects where
necessary.  Finally, router discovery and address autoconfig continue
to work with no changes to IPv6 and no requirements for any new
protocol over ATM to perform these functions.  Thus, 100% of ND is
used without the introduction of any new protocols for ATM or any
changes to IPv6 ND semantics.

The second part is linking the Logical Links together to form a larger
hierarchy through which prefix information is "leaked".  The NDS
servers outside the LL do not have a routing protocol, or any protocol.
They simply relay packets.  There is some optimization here to reduce
the amount of traffic on the hierarchy, but the NDS servers never do
anything other than relay ND packets.  The entire hierarchy just defines a 
logical group of nodes which are permitted to directly communicate over
ATM while still maintaining IPv6 addressing semantics and administrative
grouping of nodes.

There is really little complexity required to maintain the hierarchy other
than establishing the logical boundaries of the LL, and Site (to provide
proper scoping of the IPv6 addresses).

>> ~You do not want to set up a VC 
>> for a DNS query~.  Therefore, there must be a connected heirarchy of 
>> routers, so that packets can be default, connectionless, forwarded.

Ok, but this hierarchy provides that by allowing us to define which
packets are sent via the NDS tree.  This is done by filtering packets
to specific addresses to the node's connection to the tree.  Thus, we
can establish any connectionless forwarding policy we want.

And back to Markus' comments:

> Just to avoid misunderstandings for people who haven't read the draft so far:
> of course there's nothing in there that prevents you from installing routers
> inside the ATM network. There's just the option not to do so even for large
> ATM networks.

Exactly, and this is pointed out in the I-D and in my presentation at Dallas.
Linking LLs together is one option, using routers is another.  The point
is ND is 100% maintained. The full hierarchy extension is an
enhancement to allow more efficient uses of ATM resources without having
to use or introduce any non-ND protocols to do so.

 --- pete

------------------
Peter Schulter					schulter@zk3.dec.com
Digital UNIX Networking				voice (603) 881-2920
Digital Equipment Corp				voice (DTN) 381-2920
ZK3-03/U14					FAX   (603) 881-2257
110 Spit Brook Road				FAX   (DTN) 381-2257
Nashua, NH 03062