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