Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/appleip/appleip-minutes-90may.txt

Text File | 1993-02-17 | 5.8 KB | 153 lines

CURRENT_MEETING_REPORT_


Reported by John Veizades/ Apple

Minutes:

There was quite a bit of lively debate over the priorities of the
working group, but all priorities involve the effective support of
Macintosh computers on the Internet.  AppleTalk over IP discussion:

The issues involving AppleTalk encapsulation over IP networks are these:


  1. There's no standard for the existing state of IPTalk.
  2. There are several areas where the current state of IPTalk might be
     improved.


The problems with IPTalk derive from the mismatch in pairing the IP/UDP
layer with the AppleTalk DDP layer; a better match might be at the level
of IP and DDP (i.e.  encapsulate AppleTalk DDP packets just above the IP
layer, beside UDP). However, this would come at the expense of making
changes for every IP implementation in existence, which isn't feasible.
There are also problems with the number of UDP ports a MacTCP machine
can open, and the number of UDP ports the IPTalk server is required to
maintain; an IPTalk machine (such as a UNIX machine running CAP) is
required to listen on 256 UDP ports which are mapped to 256 AppleTalk
DDP ports, while a MacTCP host can only maintain 64 UDP ports.
Therefore, MacTCP machines can't fully interoperate with IPTalk
machines.

AppleTalk might scale better over large networks if IP is used
effectively as a transport.

Simplicity versus scale-ability.  To what extent does support for large
networks require extensive configuration from the maintainer?  AppleTalk
has always been constructed to be ``plug-and-play,'' but that has
introduced some problems with support over larger networks.

How well will AppleTalk Phase 2 be supported by IPTalk, if at all?
IPTalk routing isn't documented anywhere except within the KIP code
itself.

Documents describing Ed Moy's work (at UCB) were distributed.  Since not
everyone attending was familiar with the work, it was agreed to examine
it, and follow up with it as a base for further work, since it seems to
show considerable promise.  Ed Moy's work not only attempts to document
the existing state, but to propose a new IPTalk standard.

Ed Moy's report can be used as a starting point to address the issue
where there is no documentation for the current state of IPTalk

                                   1






networking.  It might also be used to address the problems with the
current level of IPTalk networking.  IP over AppleTalk Networks:

John Veizades ([e-mail]) presented an outline for a document
to standardize the methods by which the IP is conducted over an
AppleTalk network.  The outline was generally accepted, and several
areas were discussed.

An optional feature of the IP implementation on each Macintosh might be
to send a packet to the IP address assignment agent to shutdown IP
service.  When a Mac in tosh completes a session and no longer requires
an IP address, it may send a request to the gateway to free that
address.  If the feature is not implemented the address will age out of
the asigning agents table of assigned addresses.

In discussion of the operation of higher layer protocols, two regimes
were addressed:  when the locally attached DDP-IP gateway is acting as a
IP router, and when it's serving as an IP forwarding agent.  If the
DDP-IP gateway is serving as a router, it should comply with RFC-1009,
the Router Requirements Specification.  This would also require that the
IP implementaion on all Macintoshes handle ICMP packets (of all
varieties).

If the locally attached DDP-IP gateway is only forwaring IP packets,
then "non-intuitive" things may occur when two IP-forwarders are
connected to the same LocalTalk network, and connected to the same IP
(sub)network.  Proxy-ARP in this case leads to some confusion.

It was recommended that there should be no mention of DDP-ARP in the
standards document.

The AppleTalk MIB:

The only reservations raised about the proposed MIB for AppleTalk were
that the KIP section of the MIB had to refer to documented standard
protocols (i.e.  we need to document the KIP routing protocol), and that
the buffer section had some FastPath-specific sectionns that might be
better addressed in a vendor-specific MIB. In particular, the buffer
section of the MIB might be geared more toward a FastPath than to any
other product.  Leaving information about buffer counts was agreed to be
better left to a vendor-specific MIB.

Conclusions:

Several documents need to be drafted:

  1. A specification for IP over AppleTalk (based on John Veizades'
     outline)
  2. A specification for AppleTalk over IP (based on Ed Moy's report)
  3. A further revision of the AppleTalk MIB (Steve Waldbusser's, with
     modifications)


                                   2






ATTENDEES

    Leo McLaughlin            [e-mail]
    Rob Chandhok              [e-mail]+
    Bruce Crabill             [e-mail]
    Peter DiCamillo           [e-mail]
    Karen Frisa               [e-mail]
    Kanchei Loa               [e-mail]
    Tom Holodnik              [e-mail]
    Jonathan Wenocur          [e-mail]
    Mike Horowitz             [e-mail]
    Frank Slaughter           [e-mail]
    Josh Littlefield          [e-mail]
    Brad Parker               [e-mail]
    Zbigniew Opalka           [e-mail]
    Russ Hobby                [e-mail]
    Van Jacobson              [e-mail]
    Peter Vinsel              farcomp![e-mail]
    Terry Braun               [e-mail]
    Matthew Nocifore          [e-mail]
    Milo Medin                [e-mail]
    David Kaufamn             [e-mail]
    Steven Willis             [e-mail]
    Greg Satz                 [e-mail]
    Zaw-Sing Su               [e-mail]
    John Veizades             [e-mail]



                                   3