CURRENT MEETING REPORT
Minutes of the IP over ATM Working Group
(ipatm)
Reported by Jeffrey Dunn, Hewlett-Packard,
and Mark Laubach, Com 21, Inc.
Mark Laubach opened the session. This is
Mark's last meeting as chair of the working group. Andy Malis
has been appointed the new chair. Mark and Andy co-chaired the
working group sessions for this meeting.
The ipatm email distribution list has moved
to ip-atm@nexen.com. The management address has moved to ip-atm-request@nexen.com.
George Swallow gave a brief report on the
ATM Forum LAN Emulation (LANE) and MultiProtocol over ATM (MPOA)
activities. He reported that the ATM Forum met two times since
the Dallas IETF meeting. The MPOA Working Group is looking at
NHRP for layer 3, LANE for layer 2, and MARS for layer 3 multicast.
This group sent a liaison to ATM Forum to ask for general configuration
server. This will be investigated; LANE has its own system.
Andy Malis gave a rolc update from the sessions
the day before. Server synchronization problems were addressed.
It was decided that the methods must be the same for NHRP, MARS,
and Classic ATMARP work. The classic2 authors agreed that the
synchronized server specification will be removed from the current
classic2 update draft and server mechanisms will be submitted
as a separate draft.
Grenville Armitage gave an update on the
IPMC draft status. The draft is currently under review by the
IESG. Not much has changed since Dallas, however some implementation
testing revealed a minor bug. The changes to fix the bug were
small and the work was released as version-12 of the document.
Expect IETF last call for this document shortly.
The authors of the Framework draft were
not present. Mark Laubach reported that the draft has been updated
as per some discussions on the mailing list. The new draft will
be considered for promotion to informational status.
Mark Laubach and Joel Halpern presented
an update on the status of the RFC1577 update, draft-ietf-ipatm-classic2-01.txt.
Due to Mark's other time commitments, he added Joel Halpern as
a second author on the draft. The presentation was divided into
two parts, one the "bug fixes" to RFC1577, and the second
the server synchronization status. Mark Laubach presented the
bug fixes to RFC1577.
A question was raised regarding availability
of ATMARP servers to all clients in the LIS in view of the transition
to NHRP. The answer was that if there are RFC1577 ATMARP only
clients in the LIS, then these clients will continue to use RFC1577
ATMARP [NHRP servers will also answer ATMARP queries for local
destinations]. Joel Halpern mentioned that that ATMARP/NHRP transition
plan will be in the applicability document or the framework document.
This will be decided later.
A question was raised about existence of
a mechanism to differentiate between classic1 and classic2 clients
with respect to a timeout on the InATMARP requests. Mark Laubach
answered that the lack of an InATMARP from the server will not
effect operation of old clients with new servers or new clients
with old servers. A discussion concluded that the old InATMARP_Request
registration method was unreliable and the first request was dropped
more often than not.
A question was raised on whether you could
have a race condition were nobody talks. Joel Halpern replied
that the client will always send an ARP. A compromise method of
the server sending an InATMARP after a timeout is under consideration.
Joel Halpern presented an update on the
classic2 server synchronization mechanism. The goals for the synchronization
system were presented.
OSPF experience will be leveraged in the
synchronized server approach. The statistical nature of the epidemic
algorithms are very useful for the future, however for the moment,
the default configuration will be to do reliable flooding.
An issue was raised on the email list that
there is a potential race condition if a client moves to a different
port and server to server update trashing occurs due to the two
circulating rumors. The solution is to fix this for NHRP, since
fixing this would require a change in the ATMARP client-server
packet format. Also, obsolete information will be discarded completely
within 20 minutes.
The synchronized server mechanism will be
removed from the classic2 update and detailed in a separate draft.
The remaining material in the classic2 update will be bug fixes
and documentation fixed for RFC1577 and RFC1626. The details of
moving from ATMARP to NHRP will be detailed in another separate
draft.
Jim Luciani presented an overview of his
server cache synchronization draft. Due to many people already
seeing the same presentation from the rolc session, the presentation
was abbreviated. The goals of the method were overviewed for ATMARP,
MARS, and NHRP. It was felt that there was not enough information
on the ATM Forum LANE option at this time. Jim and Joel Halpern
will be authoring a combined server synchronization draft statement.
They said they will issue it approximately three weeks after the
IETF meeting.
Maryann Maher presented an approach for
the RFC1755 update to UNI 4.0. This draft should serve as an implementers
guide for UNI signaling in IP over ATM, NHRP, MARS, etc. A number
of new features are of particular interest, such as ATM traffic
parameter negotiation, ABR signaling for point to point calls,
leaf initiated join for multicast, ATM anycast, frame discard,
and signaling of individual QOS parameters. The ATM Forum final
straw vote for UNI 4.0 will be in April.
The UNI 4.0 spec will have a section detailing
issues of interoperability with UNI 3.1 end systems. In terms
of CBR and VBR, there are issues in transition. There are combinations
of parameters which could cause rejection in UNI 4.0. Traffic
parameter negotiation will be in PNNI and UNI 4.0. The BBC and
B-LLI information elements in PNNI come from UNI 4.0. UNI signaling
will propagate to the NNI except leaf initiated join and proxy
signaling.
To start the second session, Maria Greene
presented an update on the Classical IP-ATM MIB draft. It is planned
for a revised draft in March with an intent to go to last call
in June, 1996. An issue to be resolved is: should we have the
ipAtmVirtualifType? It gives the ability to have multiple interfaces
per MIB. The LIS is associated with an interface of AAL5. The
AToMIB can handle the modeling of PVCs. Objects for ATM subaddr
can be deferred until they are needed - they can always be added.
"ipAtmLisVcType" will be removed. "ipAtmLisIsSrvr"
has been used to tell a machine it is the server. Instead, we
will have a local addr appear in ipAtmArpSrvrTable. Further study
is need for moving the ArpServer to a new location (ATM addr).
The AToMIB MTU is the initial, but the classical is the actual
negotiated value. This may be in the supplemental MIB, but we
have agreed not to support this as it is not finished. A MARS
MIB will be written in the future.
Rajesh Talpade presented his MultiCast Server
(MCS) Architecture for MARS draft. This is a more detailed description
of the MCS and their interaction with the MARS. Receiver sharing
implies a single MCS has a smaller number of point to multipoint
connections. If receivers are shared, the load is less. A leaf
from a receiver tree can be dropped at only one point rather than
all MCSs. The network has to remove the receivers from the tree
regardless. You can reduce the problem to backup and sender sharing.
It was stated that receiver sharing reduces signaling load. There
was some feeling expressed that the working group needs to get
involved in the specifications of the MCS architecture, specifically
with the specification for the interaction for the MARS and MCS
protocols. There was general agreement that the work needed to
be done but not on the shape it should take, and that people should
work on this between now and next meeting. MCS to MCS synchronization
is an issue for further study.
Dilip Kandlur presented an overview on the
Extension to the MARS model draft. Some issues were raised with
regard to shared senders and MCSs, participation of direct senders
with the MCS synchronization protocol, and complexity for the
sender. These are for future study. Issues raised by this draft
and additions to the MARS draft will be considered at a later
time.
Eric Crawley presented an overview on the
Multicast Routing over ATM draft. It was noted that there are
still many open issues with respect to multicast routing to be
resolved.
A question was raised about that status of the broadcast draft. It was generally felt that the work was valuable and that the draft should be updated to the current reference for the MARS -12 draft and that the author should contact the chair for further working group action. This can proceed before the MARS draft becomes an RFC. The RFC editor will take care of reference adjustments.