DHUNT@enr.prime.com Thu, 26 July 1990 19:05 UTC
Received: from merit.edu by NRI.NRI.Reston.VA.US id aa10480; 26 Jul 90 15:05 EDT
Received: Thu, 26 Jul 90 14:04:25 EST from ENR.Prime.COM by merit.edu (5.59/1.6)
Message-Id: <9007261904.AA24836@merit.edu>
Received: (from user DHUNT) by ENR.Prime.COM; 26 Jul 90 15:05:24 EDT
To: fddi@merit.edu
From: DHUNT@enr.prime.com
Date: Thu, 26 Jul 1990 15:05:24 -0400
Status: O
To: fddi@merit.edu From: doug (dhunt@enr) Date: 26 Jul 90 2:54 PM Subject: memo on extended ARP, for discussion at IETF meeting Summary This memo will be presented at the IP-over-FDDI working group session at the Vancouver meeting, and is circulated to the mailing list so that interested parties may look it over in advance. It covers proposed extensions to the ARP protocol to cover the case of single IP subnet FDDI networks. It is based on the extended ARP presentation given at the February IETF IP-over-FDDI session, and incorporates comments made at that session, as well as comments received from interested individuals between the February meeting and the upcoming one. It is our hope to get constructive feedback at the Vancouver meeting, which can be used to update this initial version of an RFC on extended ARP. ---------------------- 1. Status of This Memo The purpose of this RFC is to focus discussion on the particular problem associated with the application of the Address Resolution Protocol (ARP)[1] to a network where one IP address may correspond to more than one MAC layer hardware address. FDDI dual MAC stations will be used to illustrate the problems, but proposed solutions will be general to include multi-MAC cases as well. In this initial draft RFC, no specific solution is proposed as a standard. It is hoped that discussions will result in a concensus followed by the adoption of a clear standard. It is recommended that the reader be familiar with the FDDI station attachment concepts and the "wrapped" and "thru" node and network configurations. This knowledge will aid understanding of this RFC [2, 7]. Distribution of this memo is unlimited. 2. Acknowledgments This memo draws heavily from the April 1988 memo of J. Lekashman (NASA AMES GE) entitled "Multi-Homed Hosts in an IP Network"[3] and from RFC 1042 [4] by J. Postel and J. Reynolds of ISI. The memo represents a cooperative effort on the part of the authors with the advice of Carol Iturralde, now at DEC. Comments from Steve Deering of Stanford and Paul Koning of DEC have also been incorporated, although only the authors are responsible for any mistakes in the final document. 3. Motivation In the standard method of network host attachment, a host computer is connected through only one physical device to any one network. Since the mapping of IP to MAC addresses is, therefore, one-to-one, the network interface is simple to both understand and build. As a reliable network interface becomes more critical, however, the limitations of a one-to-one mapping become less acceptable. A single network device on a supercomputer may become the bottleneck which throttles traffic between the resident network computational server and its many local clients. For remote clients, if the server is singly-attached, the addition of gateways cannot ameliorate congestion. In fact the offered resources of a network server may become hostage to the state of a single physical device. This memo proposes a method for mapping protocol addresses to hardware addresses where the mapping is a one-to-many. The new method would not supersede the existing one-to-one method, but would complement it. Hosts which understand only the older mapping will be free to communicate with hosts implementing the new mapping without modifications. The intent is that the one-to-many mapping method be a straightforward extention of the existing Address Resolution Protocol. This proposal augments RFC 1103 which addresses the case of single MAC FDDI stations, but left the case of dual (or multi) MAC stations for future RFCs. 4. Overview Any extensions to ARP must be flexible enough to accommodate stations with one or many network interfaces as well as maintain backward compatibility with existing ARP implementations. Additionally, this new ARP must have the property that even though one, or more interfaces of multi-MAC stations become unusable, if a connection to the network exists, the faulty station will maintain connectivity to other stations on the network. In this case, the new ARP must also provide sufficient information that stations will continue communications during network transitions (faulty station returning to full connectivity for example) with minimal or no re-ARPing. The approach, then, is to provide, within the context of an extended ARP (EARP) request and response, information necessary to ensure proper mapping of IP to hardware addressing. For a given station with multiple network interfaces, I1,I2...In, and corresponding hardware addresses H1,H2...Hn, the necessary information would be of the form: <IP address><H1,I1><H2,I2>...<Hn,In> (e.g. hardware address Hk is reachable via interface Ik). EARP request and response messages are defined to convey this connection information in a network where all stations implement EARP. For mixed networks (i.e. with both standard ARP and EARP stations), there are two suggested methods for EARP implementations which preserve backward compatibility with standard ARP. One suggests implementing an EARP request as a modified ARP request where the interface information is stored in an unused request field. The second suggests implementing the EARP request as a new request type containing interface hardware address pairings. In this case, a requesting host would issue a standard ARP request if there is no response from the EARP request. With either implementation, a responding host would return ARP information in a new EARP-style response which contains interface and hardware address mappings. With these criteria, the burden of maintaining connections through transitions must be shouldered by the EARP supporting stations. Specifics are presented in the following sections. 5. Proposed ARP Extentions 5.1 EARP request format An EARP request is essentially a standard ARP request with some additional information specifying multiple network connections and hardware addresses. The requesting station will format a request for each of its interfaces to ensure that any connected station, whether single or multi-MAC, will receive the request. Upon receipt of an EARP request, a station will process it according to RFC 826 with appropriate processing of additional interface data. The EARP Request will use the new EARP SNAP value of <TBD> and will be formatted as follows: 16 bit Protocol version number 16 bit Hardware type code 16 bit Protocol type code 8 bit Byte length of each hardware address (n) 8 bit Byte length of each protocol address (m) 16 bit Opcode -- request 8 bits Station State; encoding TBD mbytes Protocol address of sender 16 bits Count of hardware addresses to follow for each hardware address associated with the IP address nbytes Hardware address of sender 8 bits corresponding path interface (primary etc.) mbytes Protocol address of target nbytes Hardware address of target The protocol version number suggested at the February 1990 IP-Over-FDDI working group meeting is used to distinguish various versions of the EARP protocol. The count field is used to indicate how many hardware address/path interface pairs are included in this request. The first hardware address-interface pair will correspond to the interface that is sending this message. In this manner, any one of the request messages tells the responding station all there is to know about the requesting station, eliminating the need to resend lost ARP requests for stations with multiple interface paths. In order that all stations properly associate the value of the path interface designation with their understanding of primary, secondary, etc. rings, the following codes should be observed. 00 -- not applicable 01 -- unknown 02 -- TBD 03 -- TBD 04 -- primary path interface 05 -- secondary path interface etc. The value "not applicable" is used in the case where a station implements EARP, but is not a standard FDDI station. Though it seems unlikely that a station would implement the extended ARP and not understand path interface distinction, the situation is possible and must be accounted for. A value of "unknown" is provided for the case where a single attachment station is connected through a concentrator that is, as yet, unaware of which ring it has been inserted into. Encoding details for station state information are TBD, but may be derived from those used in the FDDI MIB [2]. Use of the station state information is discussed in section 5.4. 5.2 EARP Response Upon receipt of an ARP request of either type, the EARP station must format a response. If the request were either a modified ARP request or an EARP request, the responding station will send a response for each request it receives and format it as follows using the new EARP SNAP value of TBD. 16 bit Protocol version number 16 bit Hardware address space (e.g., Ethernet) 16 bit Protocol type 8 bit Byte length of each hardware address (n) 8 bit Byte length of each protocol address (m) 16 bit Opcode (i.e. response) 8 bits Station state; encoding TBD mbytes Protocol address of sender 16 bits Count of hardware addresses to follow for each hardware address associated with the IP address nbytes Hardware address of sender 8 bits corresponding path interface (primary, etc.) mbytes Protocol address of target nbytes Hardware address of target As with the EARP request, the first hardware address-interface pair will correspond to the interface that is sending this message. In this manner, any one of the response messages tells the requesting station all there is to know about the responding station eliminating the need to resend lost ARP responses. 5.3 Backward Compatibility Proposals 5.3.1 EARP Proposal One Initially, EARP stations are likely to be in a mixed environment. That is, a network which contains both standard ARP stations and new stations (such as dual MAC FDDI stations) that support EARP. The first of the two EARP methods proposes a hybrid ARP request for this case which is backward compatible with standard ARP. For a network populated solely with EARP capable stations, this approach suggests the use of a switch to allow a network administrator to tune the ARP method to a pure EARP implementation as presented in section 5.1 and 5.2. The advantage of tuning the system for EARP-only networks is the elimination of backward compatible checks and processing resulting in better performance. The default for this parameter will support the mixed network. This method breaks down into a decision tree with the specifics presented below. For the initiating station: Is station in EARP-only network? YES send EARP request and receive EARP response. NO -- most likely early situation send hybid EARP request and accept either ARP or EARP response For the responding stations: Did the station have state and interface information? (a hybrid) YES send an EARP response NO send standard ARP response Ideally, an EARP request would simply extend the standard ARP request by adding fields for additional interface information. Unfortunately, many existing ARP implementations check the size of ARP reqests and flag "too long" requests as errors. Providing this modified request allows the EARP station to send only one type of message in order to reach any attached station. Without it, the EARP station would be required to issue two requests; a standard ARP request for non-EARP stations and an extended request providing station attachment information which non-EARP stations would ignore. The disadvantage, however, is that EARP stations must receive multiple requests to establish a complete ARP entry for a multi-MAC station. The modified ARP request will continue to use the standard ARP SNAP value and will be formatted as follows. 16 bit Hardware address space (e.g., Ethernet) 16 bit Protocol type 8 bit Byte length of each hardware address (n) 8 bit Byte length of each protocol address (m) 16 bit Opcode (i.e. request) nbytes Hardware address of sender mbytes Protocol address of sender nbytes ***encoding of station state and path interface (ring) corresponding to sender hardware address mbytes Protocol address of target *** New information. Notice that where standard ARP specifies the target hardware address (which is meaningless in the request), EARP specifies an encoding of the sending station's station state (wrap, thru) and path interface. The addition of this information does not change the size or meaning of the ARP request and, therefore, will be acceptable to either a standard ARP station or an EARP station. A requesting station will format such a request for each of its interfaces to ensure that any connected station, whether single or multi-MAC, will receive the request. Upon receipt of such a request, a station will process it according to RFC 826 and EARP supporting stations will additionally decode the station state and path interface identification. The implication is that in a mixed network, a dual (or multi) MAC station will need to process more than one hybrid ARP request to determine all of the possible bindings of another dual (or multi) MAC station. 5.3.2 EARP Proposal Two The second proposed EARP request scenario requires sending two requests. The first request would include a one-to-many IP to hardware address mapping included in the new EARP request described above. Only those hosts supporting EARP would record the addresses from this packet. All addresses obtained from this message would be equivalent and an IP packet sent to any one of them would be queued identically. Traffic to EARP-supporting stations could thus be balanced among all available interfaces. If the EARP request did not recieve a response within a specified timeout period, the requesting station would send out a standard ARP request as described in RFC 826 [1]. The one-to-one mapping included in this request would be for a selected hardware interface which is a matter of network configuration. The network administrator would select this interface and then ensure that all stations which do not support EARP would have at least one connection through the this interface. The requesting station would send the standard ARP request only through this specific interface. This method breaks down into a decision tree with the specifics presented below. For requestion station: Send EARP request with all interface mappings Did we receive a response within timeout?? YES record information in EARP cache NO send standard ARP request for proper interface. wait for standard ARP reply For responding stations: Does the station support EARP? YES reply with EARP response NO drop request; unrecognized SNAP value. The advantage of this proposal is that no intervention is required to tune the system for a network composed solely of EARP stations. In this case, any ARPed for station will respond to the first EARP request and no second request would be issued. 5.4. Station Transitions - Thru to Wrapped When a station transitions from thru to wrap, one or more MAC addresses on the wrapping station may no longer be accessable. Since there is no way for other stations to accurately determine which addresses will be visible, the wrapping station will send this information. Such messages should not be sent immediately upon a transition, but should be associated with a timer to indicate a station has "settled" into this new state. The EARP request will provide the medium for such transition notification. One such request message will be formated for each active interface. In order to reduce the number of EARP messages resulting from the station transition, the target protocol address will be the address of the wrapping station and the message will be sent via broadcast. This will ensure that all EARP stations presently connected to the transitioning station will update their ARP tables to reflect the new wrapped condition, but none will be obliged to send a response. It is during the period of time when the station is in "wrap" that the inclusion of the station state in both the EARP request and response becomes useful. If the EARP station answers an EARP request with a station state of wrap, the requesting station may wish to receive the EARP response with caution because all interfaces may not be accessible. In this case, the requesting station may choose to only cache those interface pairings associated with the interfaces over which EARP responses are actually received. Note: In any network which has wrapped once, at most two stations will transition into wrap. All other stations will remain in thru and be undisturbed by the transition (i.e. in general there is no need for protocol exchange resulting from wrap/thru transitions for non end point stations.). 5.5. Station Transitions - Wrapped to Thru A station whose internal state is "wrapped" may not offer all of its MAC addresses, though other stations may continue to communicate with it via its other active interfaces. When an EARP station transitions from wrapped to thru, it must inform the other stations that it is now fully operational. To accomplish this, the transitioning station will again format a message as it did for transitions from thru to wrap. The message is an EARP request with the target address equal to the transitioning station's IP address. All EARP stations will continue to be able to communicate across a wrap-thru transition. The inclusion of this notification will just indicate that multiple paths are now accessable on the transitioning station. As such, this message need not be sent immediately upon transition, but may wait until the station is in a more stable configuration. During a period when an EARP station is in the wrap state, new EARP table entries that are created for non-EARP stations should be flagged as questionable. This is because the EARP station may not have retained the proper interface to maintain communication after it (and the network) transitions to thru. In this case, when the EARP station transitions, all such entries should be eliminated thereby forcing the EARP station to re-ARP and receive the correct hardware address-interface binding. 5.6. Operations to Ensure Backward Compatibility In the case where a non-EARP station ARPs for a station supporting EARP, the responding EARP station must issue a standard ARP response. The hardware address included in this response should correspond to the interface on which the request was received. In the case where all non-EARP stations are required to be associated with a particular interface, the hardware address should correspond to the required interface. When a non-EARP station receives a modified ARP request from an EARP station, it will not attempt to decode the target hardware address field and will simply respond with a standard ARP response. The requesting station will receive this response and enter the values into its ARP table marking it as a non-EARP entry and specifying the interface as that on which the response was received. There is one situation where the combination of non-EARP and EARP stations will not necessarily maintain communication after a station transition. It is the case where two stations, one EARP and the other non-EARP, establish communications while another system on the network is in wrap and non-EARP stations are not required to be attached to a particular interface path. If the wrapped station transitions to thru, there is no way for the two connected stations to update their tables to reflect the new network communications at that point. In some cases, the tables will reflect the actual state of the network and communications will continue. On the other hand, the tables may indicate MAC address-interface parings that are no longer valid. There are, however, other methods for correcting obsolete entries which are discussed in the following section. 9. Additional Considerations RFC 1122 [5] makes some suggestions to eliminate faulty or obsolete ARP entries (see ARP Cache Validation). In combination with EARP, these suggestions and others indicated below, will ensure connectivity. Serial MACs - Nodes that are causing the wrap may put their MACs in series thereby allowing all packets destined for the node (either MAC) to be recognized. Aliasing - Nodes that are causing the wrap may set up each MAC to recognize packets destined for another MAC on the same node. This would only be for purposes of LLC and would not affect SMT frames. The aliasing would need to be removed when the node returned to the thru configuaration. 10. References [1] "An Ethernet Address Resolution Protocol", IETF Network Working Group, David C. Plummer, RFC 826 November 1982 [2] "FDDI Station Management (SMT)" Preliminary draft proposed American National Standard May 1990 [3] "Multi-Homed Hosts in an IP Network", J. Lekashman, NASA AMES GE April 1988 [4] "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", USC/Information Sciences Institute, J. Postel and J. Reyolds, RFC 1042 February 1988 [5] "Requirements for Internet Hosts -- Communication Layers," IETF Network Working Group, R. Braden, Ed., RFC 1122, October 1989 [5] "A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks," IETF Network Working Group, D. Katz, RFC 1103 March 1990 [6] "Applying ARP to an FDDI LAN", working paper, C. Iturralde and D. Hunt December 1989 [7] "The Use of Connectionless Network Layer Protocols over FDDI Networks," ACM Computer Communication Review, pages 32-45, Dave Katz, July 1990 Authors' Addresses Doug Bagnall and Mary Jane Strohl Caralyn Brown and Doug Hunt Apollo/HP Prime Computer 250 Apollo Drive Mail Stop 10-10 Chelmsford, MA 500 Old Connecticut Path Framingham, MA 01701 D. Bagnal C. Brown phone (508) 256-6600 x phone (508)879-2960 x4237 email BAGNALL_D@apollo.hp.com email CBROWN@enr.prime.com M.J. Strohl D. Hunt phone (508) 256-6600 x4421 phone (508)879-2960 x4054 email STROHL@apollo.hp.com email DHUNT@enr.prime.com