home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
fddi
/
fddi-minutes-90feb.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
7KB
|
152 lines
CURRENT_MEETING_REPORT_
Reported by Dave Katz/Merit
MINUTES
The group met on the afternoon of Wednesday, February 7.
1. Document Overview: Dave Katz gave an overview of the current draft
IP Over FDDI document, which had been distributed to the
FDDI@MERIT.EDU mailing list, for the benefit of those new to the
working group. Highlighted were differences between the current
draft and RFC 1103.
2. Outstanding Technical Issues:
(a) A and C Indicators: A discussion ensued on the issue of the A
(Address Recognized) and C (Frame Copied) indicators. The
current draft states that "the A and C indicators shall be
ignored for IP and ARP packets." Objections were raised that
this would appear to preclude ANY use of these indicators, such
as the management of ARP cache entries. The document editor
gave his view that a standard can only specify
externally-visible behavior, and that implementation decisions
such as ARP cache management could not be precluded.
The intent of the language regarding A and C was to preclude
the use of link-level retransmission in the face of apparent
transient congestion in the receiver. The pros and cons of
retransmission were debated. After some discussion, the group
decided that the usage of the A and C bits would be specified
as an implementation decision, with an explicit note that link
level retransmission may in fact occur.
(b) Dual-MAC Issues: Dave Katz provided an overview of the issues
regarding the use of dual-MAC stations. Two basic approaches
are possible:
o Separate IP subnetworks on each ring
o A single IP subnetwork spanning both rings, with both MACs
using the same IP address (for load splitting)
With separate IP subnetworks, the major technical requirement
seems to be that all stations properly support subnetting (only
sending ARPs for stations on the proper subnet, for example) so
that the ring may wrap and unwrap without stations on the two
rings learning each others' MAC addresses. A further issue is
that if a dual-MAC station wraps the ring, the SMT
Configuration Management state machine implies that one of the
MACs may be disconnected for the duration of the wrap.
When a single IP subnetwork is used, the current ARP protocol
is insufficient to maintain knowledge of the binding between
MACs and rings. In particular, if the ring is wrapped and an
ARP is sent for an IP address, two responses may be received at
each source MAC, and it becomes ambiguous when the ring unwraps
as to which ring each MAC is connected. This problem is made
more difficult in the face of the lack of a reliable
1
event-driven indication of the wrap state of the ring
(especially if two MAC-less concentrators are performing the
wrap). Further complicating this problem are "translucent"
bridges between Ethernets and FDDI rings.
It was generally agreed that both the single-subnetwork and
dual- subnetwork configurations are desirable, and that they
should both be defined, and configurable on a per-LAN basis.
Doug Hunt of Prime presented a straw-man proposal of how to
deal with the single IP subnetwork case. It suggests the use
of an extension to the ARP protocol that allows the unambiguous
determination of the ring on which a MAC is present, even in
the face of the ring wrapping and unwrapping. This proposal
and other potential solutions were discussed by the group.
It was recognized that the development of the single-subnetwork
solution, which is generally viewed as being desirable, is
going to take a significant amount of work. No decision was
made regarding the mechanism to be used.
3. Document Progression and Future Work: The question of the
progression of one or more documents into the IETF standards track
was discussed. The choices of action balance a need to produce a
standard very quickly versus producing a complete standard.
The choices are:
(a) Progress the current document immediately as a single-MAC
standard and begin work on a separate dual-MAC standard.
(b) Quickly write a dual-subnetwork, dual-MAC solution, add it to
the current document, progress it as a standard, and begin work
on a separate single-subnet, dual-MAC standard.
(c) Add single- and dual-subnetwork, dual-MAC solutions to the
current document and progress it as a standard.
Choice a) has the advantage of starting the base document through the
standards process most quickly, significantly moving up the date at
which a standard could be published and conformant products could be
produced by vendors. It has the disadvantage of being only a partial
solution, and may give the impression of favoring single-MAC stations.
Choice b) includes support for dual-MAC stations, but delays the
progression of the base document and gives the impression that the
dual-subnetwork solution is the "right" solution for dual-MAC stations.
Choice c) provides the most even-handed document in terms of the various
solutions, but seriously delays the publication of any sort of standard.
The group decided to pursue the following course:
o Make minor additions and corrections to the current draft,
including a statement to the effect that a dual-MAC solution is to
follow. Forward this draft into the February X3T9.5 meeting.
Incorporate any additional comments from X3T9.5 into the draft and
o publish it immediately thereafter as an Internet Proposed Standard.
o Create a new working group to address "multi-rail" LANs, of which
FDDI is a specific case, with the intent of producing an Internet
2
Standard on the subject. Hope was expressed that generalizing this
problem would not significantly delay the development of a solution
for FDDI.
ATTENDEES
Doug Bagnall bagnall_d@apollo.hp.com
Samir K. Chatterjee samir@nynexst.com
Noel Chiappa jnc@lcs.mit.edu
Dino Farinacci dino@bridge2.3com.com
Ken Hays hays@scri1.scri.fsu.edu
Binh Hua no email
Doug Hunt dhunt@enr.prime.com
Ronald Jacoby rj@sgi.com
B.V. Jagadeesh bvj@chamundi.esd.3com.com
Dave Katz dkatz@merit.edu
Dave Piscitello dave@sabre.bellcore.com
Michael Reilly reilly@nsl.dec.com
Steve Senum sjs@network.com
Steve Shibuyama no email
Mary Jane Strohl strohl@apollo.hp.com
Dean Throop throop@dg-rtp.dg.com
3