rfc2835.txt

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

   +---------------+-----------------------------------------------+
13 |Tgt HW byte 5-x|
   +---------------+
                          HARP - InHARP Message

6.2.1 Example Message encodings:

   Assume for the following example that the HARP server is in the
   HIPPI-6400 side and the clients, X and Y are on the HIPPI-800 side of
   the non-broadcast capable network.







Pittet                      Standards Track                    [Page 23]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


   HARP_REQUEST message
         HARP ar$op   = 1 (HARP_REQUEST)
         HARP ar$rpa  = IPy                HARP ar$tpa  = IPx
         HARP ar$rha  = SWy ULAy           HARP ar$tha  = **
         ** is what we would like to find out

   HARP_REPLY message format
         HARP ar$op   = 2 (HARP_REPLY)
         HARP ar$rpa  = IPx                HARP ar$tpa  = IPy
         HARP ar$rha  = SWx ULAx *         HARP ar$tha  = SWy ULAy
         * answer we were looking for

   InHARP_REQUEST message format
         HARP ar$op    = 8 (InHARP_REQUEST)
         HARP ar$rpa   = IPy               HARP ar$tpa   = 0 **
         HARP ar$rha   = SWy ULAy          HARP ar$tha   = SWx ULAx
         ** is what we would like to find out

   InHARP_REPLY message format
         HARP ar$op    = 9 (InHARP_REPLY)
         HARP ar$rpa   = IPx *             HARP ar$tpa   = IPy
         HARP ar$rha   = SWx ULAx          HARP ar$tha   = SWy ULAy
         * answer we were looking for

6.2.2 HARP_NAK message format

   The HARP_NAK message format is the same as the received HARP_REQUEST
   message format with the operation code set to HARP_NAK; i.e. the
   HARP_REQUEST message data is copied for transmission with the
   HARP_REQUEST operation code changed to the HARP_NAK value.  HARP
   makes use of an additional operation code for HARP_NAK and MUST be
   implemented.

7  Broadcast and Multicast

   HIPPI-6400-SC requires compliant systems to support broadcast.
   Initial HIPPI-6400-SC systems MAY defer broadcast capability to a
   broadcast server rather than support it directly in the switching
   mechanism.  A centralized HARP server architecture meets two of the
   three major duties of a broadcast server.

   A central entity serving the whole LIS solves the coordination
   problem of a distributed approach. The registration requirement
   solves the second problem of determining which addresses make up the
   set loosely called "everyone". The last duty of a broadcast server is
   to replicate an incoming packet and send it to "everyone".





Pittet                      Standards Track                    [Page 24]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


   During its registration phase, every port , including HARP server(s),
   discover if the underlying medium is capable of broadcast (see
   section 5.1.1). Should this not be the case, then the HARP server(s)
   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.

   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.

   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-6400 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 [7]) 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.




Pittet                      Standards Track                    [Page 25]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


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-
   6400 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.

8 HARP for Scheduled Transfer

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

9 Security Consierations

   There are known security issues relating to port impersonation via
   the address resolution protocols used in the Internet [6].  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-6400 are
   clearly understood at this time, due to the fluid state of HIPPI-6400
   specifications, newness of the technology, and other factors.
   However, given the security hole ARP allows, other concerns are
   probably minor.






Pittet                      Standards Track                    [Page 26]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


10 Open Issues

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

11 HARP Examples

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

   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. Both ports X and Y have their interfaces
   configured DOWN.

   NOTE: The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$pln fields are
   left out from the examples below since they are constant. As well as
   ar$rhl = ar$thl = 6 since these are all HIPPI-6400 examples.

11.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 the
      HWa after starting a table entry for the HWa.

      HIPPI-6400-PH D_ULA                 = ULAa
      HIPPI-6400-PH S_ULA                 = ULAy
      HARP ar$op                          = 8 (InHARP_REQUEST)
      HARP ar$rpa                         = IPy
      HARP ar$tpa                         = 0 **
      HARP ar$rha                         = ULAy
      HARP ar$tha                         = 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.





Pittet                      Standards Track                    [Page 27]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


      HIPPI-6400-PH D_ULA                 = ULAy
      HIPPI-6400-PH S_ULA                 = ULAa
      HARP ar$op                          = 9 (InHARP_REPLY)
      HARP ar$rpa                         = IPs *
      HARP ar$tpa                         = IPy
      HARP ar$rha                         = ULAa
      HARP ar$tha                         = ULAy
      * answer we were looking for

   3. Port Y examines the incoming InHARP_REPLY and 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.

11.2 Registration Phase of Client Y on Broadcast Capable Hardware

   If port Y is connected to a broadcast-capable network then the
   authoritative address is the broadcast address, HWb = SWb, ULAb
   (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-6400-PH D_ULA                 = ULAb
      HIPPI-6400-PH S_ULA                 = ULAy
      HARP ar$op                          = 8 (InHARP_REQUEST)
      HARP ar$rpa                         = IPy
      HARP ar$tpa                         = 0 **
      HARP ar$rha                         = ULAy
      HARP ar$tha                         = 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.







Pittet                      Standards Track                    [Page 28]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


11.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-6400
   hardware. The authoritative address in the HRAL for this example will
   be HWa: <SWa, ULAa> and IPs for simplicity reasons.

11.3.1 Successful HARP_Resolve example

   Assume the same process (steps 1-3 of section 11.1) happened for port
   X. Then the state of X and Y's tables is: the HARP server table entry
   is in the VALID state. So lets look at the message traffic when X
   tries to send a message to Y. Since X doesn't have an entry for Y,

   1. Port X connects to the authoritative address