Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ukma!tut.cis.ohio-state.edu!ucbvax!JESSICA.STANFORD.EDU!morgan From: morgan@JESSICA.STANFORD.EDU Newsgroups: comp.protocols.appletalk Subject: Re: Appletalk Phase ][ Message-ID: Date: 19 Jun 89 18:07:00 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 102 (Sorry for the length of this, but it's my Soapbox . . .) Rick Ewing writes: > Appletalk Phase II (ATP2) is an important change in the architecture > of Appletalk to support wide area networks, as opposed to local area > networks. I disagree. I think the thrust of ATP2 is to support larger LANs, not larger internets. I'll try to make clear the distinction. It seems to me that the charter of ATP2 is to fix as many things as possible while allowing all current network applications to function unchanged. (Anything that implements an AppleTalk router, however, [such as Apple's new software, or Liaison, or Kboxes] will have to change a lot.) I would guess that the major constraint here is LaserWriters, which are a very popular network resource, and a big hassle to modify. I think this constraint prevented the ATP2 designers from tackling the Really Big Problems, however. The most important things ATP2 fixes are: 1) Number of nodes on a LAN. Anybody who runs a large bridged Ethernet and uses Macs has complained to Apple about the 254-node limit, imposed by the 8-bit node address space in the AppleTalk address (I'll note that this isn't our problem here at Stanford, since we're heavily partitioned with IP routers). ATP2's solution is the same one used by many people to extend the IP addressing on their Ethernets: just allow multiple network numbers on the same cable. ATP2 associates a contiguous network number range with a cable (an "extended" network) instead of just the single network number of ATP1. Basically this is just stealing network number bits to allow more host number bits, but the total stays at 24, still a meager number for a Real Network. Note that a LocalTalk can't do this: it still always has a single network number (a "non-extended" network). 2) Zone names on a cable. ATP1 requires each net to be in exactly one zone, which is also a problem on large bridged Ethernets. Now a zone name list is associated with a cable, and a node (eg a Mac) gets to choose the zone it wants to be in when it boots. Presumably it remembers this across boots so the poor confused user only has to do this once. There's an additional ZIP function (GetNetInfo) that a node can use to get the zone name list and net numbers from a router. 3) Broadcasts. People who run large nets complained about ATP1's use of broadcast Ethernet packets. ATP2 specifies the use of multicast packets for most functions instead of broadcasts (RTMP, NBP lookup, etc). This allows hosts with multicast-filtering capability in hardware to not be bothered by packets they're not interested in. Everyone will suddenly become very interested in the hardware support for multicast in their favorite AppleTalk hardware (EtherTalk, EtherPort, FastPath, Gatorbox, etc). Anybody want to start a list? In addition, ATP2 specifies the use of 802.2 format on Ethernets, so everybody's protocol analyzer will need some upgrading, too. 4) Routing. ATP2 routers use the "split horizon" technique to reduce the size of RTMP packets. Basically this means not telling other routers things they already know. Also, a node's caching of "best routes" to other networks is now explicit, to reduce the bouncing of packets in the presence of multiple routers on a cable. These are simple fixes that should help things a little bit. The main elements are 1, 2, and 3, which are all aimed at allowing individual LANs to have more nodes. Here are some problems with large internets that ATP2 doesn't consider: 1) Routing tables are too big. At Stanford, we have 150 Kboxes. I could imagine that, if we put them all into one AppleTalk internet (ATI), the routing table in each box would be 250 or more entries, couting all the EtherTalk and IPTalk network entries. This is a lot to maintain, but might work OK. Suppose we wanted to do AppleTalk with Big University X (BUX), which has 200 AppleTalk nets of its own. Now each router has to maintain a 450-entry table. This quickly grows unworkable. What's needed is something like what IP uses, which is subnets which have structure inside but only a single point of entry to the outside world. It seems like this would be hard to do with only 24 bits of address, though. 2) Too many zone names. Our mythical one big ATI at Stanford might have 100 zones. This is a lot to work with already. Again, if we combine with BUX, we'll have 200, and so on, as well as having multiple "Physics" zones, eg. Something like hierarchical zone names is required. Hmm, it might even look a lot like the IP Internet domain name system . . . 3) Dynamic name binding doesn't scale either. Every time I print to a LaserWriter my Mac does an NBP lookup to my zone to bind the LW's name to an AT address. A central resource that had a lot of users (perhaps a big central AppleShare server) would have lots of name lookups all the time, and any resource in its zone would also have to handle (only to discard) these lookups. Some kind of static naming is necessary for this kind of situation. Hmm, this might look a lot like the IP Internet domain name system, too . . . *8^)* I'm sure we'll do ATP2 here, but my initial reaction is that the pain of converting won't be worth the benefits we get. If ATP3 were out by 1Q90 maybe we'd wait . . . - RL "Bob" Morgan Networking Systems Stanford