CURRENT_MEETING_REPORT_ Reported by John Veizades/Apple APPLEIP Minutes MacIP John Veizades led the MacIP discussion which resulted in numerous changes to the MacIP document. There was a discussion about broadcasting, and three notes came out of that talk. o Never forward link level broadcasts. o It is forbidden to unicast to a router who does directed broadcast by unicast explosion. o Gateways will follow router requirements document with respect to directed broadcasts on subnets. Two other documents were mentioned, the first an FYI RFC for ATALK AD and ATALK ATAB. These two protocols are the KIP implementation and not phase 2 compatible. Apparently we decided that there is no need for this RFC. Appletalk Tunnelling through IP The tunnelling discussion was lead by Alan Oppenheimer of Apple. It started Tuesday afternoon, and continued through the Wednesday meeting. Tuesday Agenda o Walk through the Working Model proposed draft, Alan Oppenheimer. o Chooser+: Screen shots of a hierarchical chooser written by Eran Reshef. o The ``Magic Gateway'', Brad Parker The magic gateway does on demand mapping a user on one AppleTalk AS and a service on a second AppleTalk AS. The mapping information is kept in 1 the user gateway as a tuple for each user. The mapping is only available to the user that created it, not to other users on the same gateway. Alan has screen shots of the hierarchical chooser. Everyone at the meeting greeted that presentation pleasantly. The reaction to the idea is positive. Oppenheimer thinks the user interface needs work. Brad Parker provided screen shots of the Magic Gateway interface. Copies of the Working Model proposed draft are available from apple.com. Wednesday Agenda: o Clustering and Remapping additions - Alan Oppenheimer. o AppleTalk MIB - Steve Waldbusser. o AppleTalk Tunnelling though Foreign Networks, Draft Proposal - Alan Oppenheimer. Clustering: Clustering is a way to represent combinations of networks and zones as one entity. Clustering will be used to represent remote apple internets. Possible Remapping Additions: o Network number remapping is optional. o Static vs. dynamic remapping. o Zone name remapping with some restrictions. o General (node) remapping. Appletalk MIB: o Add packets dropped due to bad checksums. o MIB is low level AppleTalk statistics intended primarily for routers. o Alan says routers are not expected to check checksums. Router vendors ARE checking checksums! 2 The MIB was acceptable to the members of the Working Group. Greg Minshall has implemented it and says it works. The MIB document with the few suggested changes is available via anonymous FTP from lancaster.andrew.cmu.edu as appletalk-MIB-text. Appletalk Tunnelling: Addressing Format o DI - Uniquely identified as an appletalk domain. o Must be extensible. o UI = DI + network number. The document proposes a general form and an IP form. The IP form is not generally accepted because if the IP address is part of the DI, it will be misused. A form that was mentioned was 8 bits of length, followed by 8 bits of authority, followed by the Global Identifier, a Unique ID (of length length). Data Format o Encapsulation in UDP datagram port 200. o Extended DDP header: - DataLink | IP header | UDP header | ?extended header length? | ... - Dest DI | Src DI | reserved 00000000 | type 000002 | DDP header | DATA The type ``000002'' means ``data''. Must use UDP header, and each DI is padded to an even length. It was not agreed whether the extended header length was needed/desirable. Routing Information Exchange o Provide methodology o Provide a protocol o Determine which parts of the method are required 3 In addition to the ``axis'' presented in the tunnelling document, a new axis as mentioned: coupling ``looseness'', for: o Zone info (appearance and disappearance). o Network information. o Metric changes. Protocol Summary o Initial reliable exchange of a full routing table. o (Optional) reliable communication of all changes to the table. o (Optional) tickling to handle routers going down. Reliable Exchange o ``One Way'' connection for exchange and update. o Network (UI) information sent in ack'd datagrams. o Zone information initially send in unack'd datagrams. o Background timer polls for lost zone information. Milo Medin suggests that: o Zone info needs to be propogated to all. o Network/routing setup on ``demand''. o Information updates only when requested, and only at some minimum interval. (The provider tells the requestor what the minimum interval is.). Possible update events: o Net added. o Net deleted. o Net hop count. o Zone name changes. Greg Minshall suggests that these update events are not needed or 4 interesting for users. Tickling o Routers must attempt to notify other connected routers when going down. o Routers MAY tickle at some minimal rate. o If tickling is not used, routers must guard against sending data to hosts/paths that may have disappeared. Issues o Zone remapping details o Surpassing the 15 hop limit when loops o Minimum required routing information exchange, including option negotiation o Underlying reliable transport mechanism o Determination of retransmission times It was suggested that we do not do zone name remapping, it is a protocol violation, and applications pass zone names around. We know about NBP and RTMP packets, but there will be others. However if there is no mapping, then there will be zone name conflicts between ASs. Underlying Reliable Transport is TCP the transport mechanism for routing information? There was a long discussion about this, but the bottom line was, stick with UDP. Minimum Routing Exchange o Routing protocol o Pure configuration o Centralized administration o Alternate routing protocol We need to add ZIP get zone list support and zone name change updates to the routing protocol. When a zone comes back in a reply, we need to allow unknown net numbers to come back too. Oppenheimer points out that not everyone uses NBP, so 5 network numbers must be known in advance. Server returns update validity interval. Client asks for update info when interval expires, and if the client still cares. It was suggested that the protocol proposed will scale to 100s but not 1000s. Shiva wants all options negotiable: what parts of the protocol are performed, and negotiate who you are talking to to try out special ideas. The next meeting is January 9, 1991 before MacWorld in an S.F. hotel. Attendees Gregory Bruell gob@shiva.com Philip Budne phil@shiva.com Cyrus Chow cchow@orion.arc.nasa.gov James Dray dray@st1.ncsl.nist.gov Karen Frisa karen.frisa@andrew.cmu.edu John Gawf ncar!cmpatsys!gawf Michael Horowitz mah@shiva.com Holly Knight holly@apple.com Philip Koch philip.koch@dartmouth.edu Louise Laier appleLink@laier1 Nik Langrind nik@shiva.com Joshua Littlefield josh@cayman.com John Mason Masoni@applelink.apple.com Milo Medin medin@nsipo.nasa.gov Greg Minshall minshall@wc.novell.com Alan Oppenheimer oppenheimer1@applelink.apple.com Brad Parker brad@cayman.com Mark Seger seger@asds.enet.dec.com John Seligson farcomp!johnsel@apple.com Frank Slaughter fgs@shiva.com John Veizades veizades@apple.com A. Lee Wade wade@discovery.arc.nasa.gov Jonathan Wenocur jhw@shiva.com 6