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: 26 Jul 90 15:05:24 EDT
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
  •   DHUNT