morgan@JESSICA.STANFORD.EDU (06/20/89)
(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
wnn@DSUNX1.DSRD.ORNL.GOV (W. N. Naegeli) (06/20/89)
Rick Ewing writes: >>>>>>>> The original Appletalk (now called phase I) allowed up to 256 nodes on a network, and did a fairly lousy job of RTMP packet forwarding. The new Appletalk allows up to 16 million nodes, up to 256 zones ... <<<<<<<< The original AppleTalk allowed 254 nodes. (A note address of 0 is not allowed and treated as unknown, and an address of 255 is used for broad- casting to all nodes, according to "Inside AppleTalk." During the televised announcement, and in the literature we received from Apple it was stated that you could have as many as 1024 interconnected networks, each of which could have 256 zones and the users can pick which zone they wish to be in. Is that a new feature of the Chooser? What is meant by it? Already now you can select printers, net modems, etc. in other zones. Currently you can have 65535 networks and a zone can span multiple net- works, but you can only have one zone per network. It seems useful to allow multiple zones per network so that you do not have to search through dozens of printers, for example, if you wish to access on of the few in your workgroup and you are on a highspeed network with many other devices. However, it seems dangerous to allow the user to select a zone at random. Someone might inadvertently put himself or her- self into another zone and would no longer receive mail. If you inad- vertently select the wrong output device, you will notice the error when your output does not arrive at the expected place, but since you do not know when other users want to contact you, a zone selection error might go undetected for some while. >>>>>>> Standard networks using just localtalk or equivelents are *not* immediately affected by all this; since localtalk can only support 32 nodes electrically anyway (and phonenet roughly 100), it was not necessary to update all Macs to reflect the new software. <<<<<<<< Which Macs did you need to update? We actually have one LocalTalk cable with more than 60 connected devices. We tried to install a Hayes Inter- Brige once, when it was still quite a bit smaller, but we could not get it to work; some nodes became invisible. What are the rules for needing to update old networks on an internet? Some of our network numbers are higher than 1024. >>>>>>> Users that have Kinetics Fastpaths, cayman gatorboxes, Hayes Interbridges, or other devices that provide routing services need to contact their respective manufacturers for upgrades. <<<<<<< When I called Kinetics they told me that the update will require software only, no ROM swap, and that it is in Beta testing, but they did not give me a date. Nuvotech told me that the TurboBridge will require a ROM change, but that they are thinking about swapping the bridges rather than have users update them. They said they are working on it, but no date yet. Wolfgang N. Naegeli Oak Ridge National Laboratory Internet: wnn@dsunx1.dsrd.ornl.gov (128.219.96.46) Bitnet: wnn@ornlstc Phone: (615) 574-6143 Fax: (615) 574-3895
medin@nsipo.arc.nasa.gov (Milo S. Medin) (06/20/89)
All this only goes to show that Apple has yet again decided against using standard protocols like IP (or even OSI) and has again decided to reinvent the wheel, and make the same mistakes that were made before. If Apple spent a tenth of the effort making IP net building as easy as plugging together Appletalk, they and we would be much better off. This is a classic case of Not Invented Here. There are well known solutions to the types of internet problems ATP2 has built into it. It's obselete as a protocol even before it's fielded. The folks at Apple should try and open their eyes a bit. Even if the did everything differently at transport and above, running over IP at the network layer would be a big win, and allow use of standard routers and standard routing protocols, and really allow the Research community to interact much more with each other. It's really too bad when you think about how much better it could have been. It's not like SNA. Appletalk wasn't built in the '70's. Solutions were known and readily available. They just wern't used. There is no excuse for this. Thanks, Milo "Ethertalk: A poor implementation of a poor architecture."
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (06/20/89)
In article <27262@ames.arc.nasa.gov> medin@cincsac.arc.nasa.gov (Milo S. Medin) writes: >If Apple >spent a tenth of the effort making IP net building as easy as plugging >together Appletalk, they and we would be much better off. > >This is a classic case of Not Invented Here. There are well known solutions >to the types of internet problems ATP2 has built into it. If you and Bob Morgan and one person from Apple got together for a few weeks in a hotel somewhere, you three could crank out the 15 or so RFCs that would be needed to make IP as dynamic as AppleTalk. I'll bet you could even figure out how to put in the Big Switch which controls whether the net configuration is manager-less or managed (in terms of mailboxes and Well Known Resources and Authorizations). But I think you will have to get along without the Apple rep. According to the new products I see coming from Apple they are playing a different game than we. If not dynamic IP, how about a standard encapsulation of AppleTalk in IP for an RFC? (Done.) Is there some Great Hope that we could plug together some largish number of LocalTalks and EtherTalks into one largish InterAppleNet over IP? Could we go farther and glue some of the Name Binding into the Domain Name System? Could we use IP to avoid some of the ugly scaling problems with AppleTalk? Could we use our IP routing protocols to cover AppleTalk nets in our multi-protocol routers? (Non RTMP AppleTalk routing.) You and Bob and Greg from Kinetics and maybe one guy from Cayman can handle it. Maybe somebody from Microsoft to say they would support it in their applications. :-) Are you tearing your hair at the thought of all this? :-) Maybe dynamic IP would be easier. --Kent England, Boston U Standard disclaimer: The above is just a fantasy and is not to imply that Milo or Bob or Greg would ever think of doing such a thing.
chris@cayman.COM (Chris North) (06/20/89)
> Users that have Kinetics Fastpaths, cayman gatorboxes, > Hayes Interbridges, or other devices that provide routing services need > to contact their respective manufacturers for upgrades. GatorBox users should note that they will receive a free upgrade to Appletalk Phase II as part of our next release. The expected ship date is during the last week of August. -chris -- Chris North chris@cayman.COM Cayman Systems 26 Landsdowne Street Cambridge MA 02139 617-494-1999
medin@cincsac.arc.nasa.gov (Milo S. Medin) (06/21/89)
Why should I or anyone else in the Internet community go out and do all that work? Why do you think that Apple would pay attention to those RFC's when they ignored all the others? I think if we seriously believed that we could avoid this grief by doing that work, I'm sure I could get a bunch of people together and do it. But I don't think it would do any good. NIH isn't a conscious decision, it's a state of mind... Thanks, Milo
liam@cs.qmc.ac.uk (William Roberts) (06/23/89)
In article <27262@ames.arc.nasa.gov> medin@cincsac.arc.nasa.gov (Milo S. Medin) writes: >This is a classic case of Not Invented Here. There are well known solutions >to the types of internet problems ATP2 has built into it. It's obselete as >a protocol even before it's fielded. Yes, and that's the really sad thing about it. AppleTalk is a brilliantly simple "self-configuring" system which puts the human admin work only where it is needed. It also obtains services by lookup, which is much better than "well-known addresses". What I believe Apple should do (should have done) is to anticipate the meltdown in IP address space that will happen if we really do get intensely interconnected, and built an AppleTalk 2 that coped with the problems of hierarchical administration of truly enormous collections of small networks. Then it's time for Apple to licence the code to other vendors so that we can all use it, together with some neat peripherals like Ethernet laser printers to make it worth non-Mac sites using the stuff. My pet suggestion for doing this is to allow open ended extensions of the network number (nets of nets of nets of...) and let the routers worry about it. Might pay to up the size of the node number as well, allowing the old scheme to co-exist (rather like long and short form ddp addresses). Remember that services obtained by lookup have the inherent advantage that the return path can be anticipated by reversing the lookup path. If X25 (X75?) switches can do it (logical channel numbers and all) then so can anybody. -- William Roberts ARPA: liam@cs.qmc.ac.uk Queen Mary College UUCP: liam@qmc-cs.UUCP AppleLink: UK0087 190 Mile End Road Tel: 01-975 5250 LONDON, E1 4NS, UK Fax: 01-981 7517