rfc2834.txt

中、英文RFC文档大全打包下载完全版 .

   MUST emulate broadcast through an IP broadcast emulation server.

   A HIPPI IP broadcast server (PIBES) is an extension to the HARP
   server and only makes sense when the LIS does not inherently support
   broadcast. The PIBES allows common upper layer networking protocols
   (RIP, TCP, UDP, etc.) to access IP LIS broadcast.

7.1 Protocol for an IP Broadcast Emulation Server - PIBES

   To emulate broadcast within an LIS, a PIBES SHALL use the currently
   valid HARP table of the HARP server as a list of addresses called the
   target list. The broadcast server SHALL validate that all incoming
   messages have a source address which corresponds to an address in the
   target list. Only messages addressed to the IP LIS broadcast
   addresses, multicast address or 255.255.255.255 are considered valid
   messages for broadcasting. Invalid messages MUST be dropped.  All
   valid incoming messages shall be forwarded to all addresses in the
   target list.







Pittet                      Standards Track                    [Page 23]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


   It is RECOMMENDED that the broadcast server run on the same port as
   the HARP server since this memo does not define the protocol for
   exchanging the valid HARP table. The default address to use for the
   broadcast address is the operational HARP server address.

7.2 IP Broadcast Address

   This memo only defines IP broadcast. It is independent of the
   underlying hardware addressing and broadcast capabilities. Any port
   can differentiate between IP traffic directed to itself and a
   broadcast message sent to it by looking at the IP address. All IP
   broadcast messages SHALL use the IP LIS broadcast address or.

   It is RECOMMENDED that the PIBES run on the same port as the HARP
   server. In that case, the PIBES SHALL use the same address as the
   HARP server.

7.3 IP Multicast Address

   HIPPI does not directly support multicast address, therefore there
   are no mappings available from IP multicast addresses to HIPPI
   multicast services.  Current IP multicast implementations (i.e. MBONE
   and IP tunneling, see [9]) will continue to operate over HIPPI-based
   logical IP subnets if all IP multicast packets are sent using the
   same algorithm as if the packet were being sent to 255.255.255.255.

7.4 A Note on Broadcast Emulation Performance

   It is obvious that a broadcast emulation service (as defined in
   section 7.1) has an inherent performance limit. In an LIS with n
   ports, the upper bound on the bandwidth that such a service can
   broadcast is:
                          (total bandwidth)/(n+1)

   since each message must first enter the broadcast server, accounting
   for the additional 1, and then be sent to all n ports. The broadcast
   server could forward the message destined to the port on which it
   runs internally, thus reducing (n+1) to (n) in a first optimization.

   This service is adequate for the standard networking protocols such
   as RIP, OSPF, NIS, etc. since they usually use a small fraction of
   the network bandwidth for broadcast. For these purposes, the
   broadcast emulation server as defined in this memo allows the HIPPI
   network to look similar to an Ethernet network to the higher layers.

   It is further obvious that such an emulation cannot be used to
   broadcast high bandwidth traffic. For such a solution, hardware
   support for true broadcast is required.



Pittet                      Standards Track                    [Page 24]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


8 HARP for Scheduled Transfer Protocol[17]

   This RFC also applies for resolving addresses used with Scheduled
   Transfer (STP) over  HIPPI-800 instead of IP. This RFC's message
   types and algorithms can  be used for STP (since STP uses Internet
   Addresses) as long as there is also an IP over HIPPI implementation
   on all of the ports.

9 Discovery of One's Own Switch Address

   This HARP specification assumes that each port has prior knowledge of
   its own hardware address.  This address may be manually configured,
   by means outside the scope of this memo or a port may discover its
   own logical address through the algorithm described below.

   Ports are NOT REQUIRED to implement this switch address discovery
   protocol but are encouraged to do so since it reduces the
   administrative overhead.  The algorithm presented in this section is
   based on John Renwick's work as detailed in RFC-1374 [14]. The
   concept of the discovery process is to scan all possible switch
   addresses. The messages that are received will be the ones containing
   one of our switch addresses.

   If a port implements this algorithm it SHALL form a HIPPI-LE message
   as defined in HIPPI-LE: containing an Self_Address_Resolution_Request
   (see [3]) PDU Type, a Source_IEEE_Address and
   Destination_IEEE_Address (set to the correct ULA for the sender), and
   the Source_Switch_Address and Destination_Switch_Address.

   This self address resolution message uses the same HIPPI-LE message
   format as described in HIPPI-SC and HIPPI-LE: the Self Address
   Resolution Request PDU and Self Address Resolution Response PDU type
   codes and no piggybacked ULP data.  The HIPPI-LE header contents for
   the request are:

      HIPPI-LE Message_Type is            = 3, Self Addr. Resolution Request
      HIPPI-LE Destination_Address_Type   = 0 (undefined)
      HIPPI-LE Destination_Switch_Address = X (X element scan range)
      HIPPI-LE Source_Address_Type        = 0 (undefined)
      HIPPI-LE Source_Switch_Address      = 0 (unknown)
      HIPPI-LE Destination_IEEE_Address   = 0
      HIPPI-LE Source_IEEE_Address        = my ULA

   There is no D2 data; the message contains only the HIPPI-FP header
   and D1_Area with the HIPPI-LE header.






Pittet                      Standards Track                    [Page 25]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


   Ports SHALL start the scan with a configurable logical address
   (default 0x000) and increment the value for by one for each
   subsequent try. The port SHALL continue until it sees its own self
   address resolution request or it has reached the end, which may be
   another configurable value (default 0xFFF). It is RECOMMENDED that
   the range of addresses to scan be configurable since some networks
   have equipment that does not gracefully handle HIPPI-LE messages.

   After a port sends the[se] request[s], two positive outcomes are
   possible:

   o  the port receives its own request(s), and obtains one of its own
      Switch Address, or

   o  the port receives an AR_S_Response with the
      Destination_Switch_Address filled in.

10 Security Considerations

   HARP messages are not authenticated which is a potentially flaw that
   could allow corrupt information to be introduced into the server
   system.

   There are other known security issues relating to port impersonation
   via the address resolution protocols used in the Internet [8].  No
   special security mechanisms have been added to the address resolution
   mechanism defined here for use with networks using HARP.

   Not all of the security issues relating to ARP over HIPPI are clearly
   understood at this time. However, given the security hole ARP allows,
   other concerns are probably minor.

11 Open Issues

   Synchronization and coordination of multiple HARP servers and
   multiple broadcast servers are left for further study.

12 HARP Examples

   Assume a HIPPI-SC switch is installed with three connected ports: x,
   y, and a.  Each port has a unique hardware address that consists of
   Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and
   ULAa, respectively). There is a HARP server connected to a switch
   port that is mapped to the address HWa (SWa, ULAa), this address is
   the authoritative HIPPI hardware address in the HRAL (HARP Request
   Address List).





Pittet                      Standards Track                    [Page 26]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


   The HARP server's table is empty. Ports X and Y each know their own
   hardware address.  Eventually they want to talk to each other; each
   knows the other's IP address (from the port database) but neither
   knows the other's ULA or Switch Address. Both ports X and Y have
   their interfaces configured DOWN.

   NOTE: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd,
   ar$pro, ar$pln fields are left out from the examples below since they
   are constant. Likewise, ar$rhl = ar$thl = 9 are omitted since these
   are all HIPPI-800 examples.

12.1 Registration Phase of Client Y on Non-broadcast Hardware

   Port Y starts: its HARP table entry state for the server: PENDING

   1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa
      after starting a table entry for HWa.

      HIPPI-LE Destination_Switch_Address = SWa
      HIPPI-LE Source_Switch_Address      = SWy
      HIPPI-LE Destination_IEEE_Address   = ULAa
      HIPPI-LE Source_IEEE_Address        = ULAy
      HARP ar$op                          = 8 (InHARP_REQUEST)
      HARP ar$rpa                         = IPy
      HARP ar$tpa                         = 0 **
      HARP ar$rha                         = SWy ULAy
      HARP ar$tha                         = SWa ULAa
      ** is what we would like to find out

   2. HARP server receives Y's InHARP_REQUEST, it examines the source
      addresses and scans its tables for a match. Since this is the
      first time Y connects to this server there is no entry and one
      will be created and time stamped with the information from the
      InHARP_REQUEST. The HARP server will then send a InHARP_REPLY
      including its IP address.

      HIPPI-LE Destination_Switch_Address = SWy
      HIPPI-LE Source_Switch_Address      = SWa
      HIPPI-LE Destination_IEEE_Address   = ULAy
      HIPPI-LE Source_IEEE_Address        = ULAa
      HARP ar$op                          = 9 (InHARP_REPLY)
      HARP ar$rpa                         = IPs *
      HARP ar$tpa                         = IPy
      HARP ar$rha                         = SWa ULAa
      HARP ar$tha                         = SWy ULAy
      * answer we were looking for





Pittet                      Standards Track                    [Page 27]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


   3. Port Y examines the incoming InHARP_REPLY, completes its table
      entry for the HARP server. The client's HARP table entry for the
      server now passes into the VALID state and is usable for regular
      HARP traffic. Receiving this reply ensures that the HARP server
      has properly registered the client.

12.2 Registration Phase of Client Y on Broadcast Capable Hardware

   If there is a broadcast capable network then the authoritative
   address in the HRAL would be mapped to the broadcast address, HWb =
   SWb, ULAb (likely 0xFE1 and FF:FF:FF:FF:FF:FF).

   Port Y starts: its HARP table entry state for HWa: PENDING

   1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa,
      in this example the broadcast address, after starting a table
      entry.

      HIPPI-LE Destination_Switch_Address = SWb
      HIPPI-LE Source_Switch_Address      = SWy
      HIPPI-LE Destination_IEEE_Address   = ULAb
      HIPPI-LE Source_IEEE_Address        = ULAy
      HARP ar$op                          = 8 (InHARP_REQUEST)
      HARP ar$rpa                         = IPy
      HARP ar$tpa                         = 0 **
      HARP ar$rha                         = SWy ULAy
      HARP ar$tha                         = SWb ULAb
      ** is what we would like to find out

   2. Since the network is a broadcast network, client Y will receive a
      copy of its InHARP_REQUEST. Client Y examines the source
      addresses.  Since they are the same as what Y filled in the
      InHARP_REQUEST, Y can deduce that it is connected to a broadcast
      medium.  Port Y completes its table entry for HWa. This entry will
      not timeout since it is considered unlikely for a particular
      underlying hardware type to change between broadcast and non-
      broadcast; therefore this mapping will never change.

12.3 Operational Phase (phase II)

   The Operational Phase of the HARP protocol as specified in this memo
   is the same for both broadcast and non-broadcast capable HIPPI
   hardware. The authoritative address in the HRAL for this example will
   be HWa: <SWa, ULAa> and IPs for simplicity reasons.







Pittet                      Standards Track                    [Page 28]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


12.3.1  Standard successful HARP_Resolve example

   Assume the same process (steps 1-3 of section 10.1) happened for por