summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2835.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2835.txt')
-rw-r--r--doc/rfc/rfc2835.txt1851
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc2835.txt b/doc/rfc/rfc2835.txt
new file mode 100644
index 0000000..067811e
--- /dev/null
+++ b/doc/rfc/rfc2835.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group J.-M. Pittet
+Request for Comments: 2835 Silicon Graphics Inc.
+Category: Standards Track May 2000
+
+
+ IP and ARP over HIPPI-6400 (GSN)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ The ANSI T11.1 task force has standardized HIPPI-6400 also known as
+ Gigabyte System Network (GSN), a physical-level, point-to-point,
+ full-duplex, link interface for reliable, flow-controlled,
+ transmission of user data at 6400 Mbit/s, per direction. A parallel
+ copper cable interface for distances of up to 40 m is specified in
+ HIPPI-6400-PH [1]. Connections to a longer-distance optical
+ interface are standardized in HIPPI-6400-OPT [3].
+
+ HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC PDUs
+ [10] and by implication, IP on GSN. Another T11.1 standard describes
+ the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2].
+ T11.1 chose to leave HIPPI-6400 networking issues largely outside the
+ scope of their standards; this document specifies the use of HIPPI-
+ 6400 switches as IP local area networks. This document further
+ specifies a method for resolving IP addresses to HIPPI-6400 hardware
+ addresses (HARP) and for emulating IP broadcast in a logical IP
+ subnet (LIS) as a direct extension of HARP. Furthermore it is the
+ goal of this memo to define a IP and HARP that will allow
+ interoperability for HIPPI-800 and HIPPI-6400 equipment both
+ broadcast and non-broadcast capable networks.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1 Global concepts used . . . . . . . . . . . . . . . . 3
+ 2.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 4
+
+
+
+Pittet Standards Track [Page 1]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ 3. IP Subnetwork Configuration . . . . . . . . . . . . . . . 5
+ 3.1 Background . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 6
+ 4. Internet Protocol . . . . . . . . . . . . . . . . . . . . 7
+ 4.1 Packet Format . . . . . . . . . . . . . . . . . . . 7
+ 4.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 7
+ 4.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 7
+ 4.1.3 Packet diagrams . . . . . . . . . . . . . . . 8
+ 4.2 HIPPI-6400 Hardware address: Universal LAN MAC addr. 9
+ 4.3 Maximum Transmission Unit - MTU . . . . . . . . . . 10
+ 5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 11
+ 5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 12
+ 5.1.1 Selecting the authoritative HARP service . . . 12
+ 5.1.2 HARP registration phase . . . . . . . . . . . 13
+ 5.1.3 HARP operational phase . . . . . . . . . . . . 14
+ 5.2 HARP Client Operational Requirements . . . . . . . . 15
+ 5.3 Receiving Unknown HARP Messages . . . . . . . . . . 16
+ 5.4 HARP Server Operational Requirements . . . . . . . . 16
+ 5.5 HARP and Permanent ARP Table Entries . . . . . . . . 18
+ 5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 18
+ 6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 19
+ 6.1 Generic IEEE 802 ARP Message Format . . . . . . . . . 19
+ 6.2 HIPARP Message Formats . . . . . . . . . . . . . . . 21
+ 6.2.1 Example Message encodings: . . . . . . . . . . 23
+ 6.2.2 HARP_NAK message format . . . . . . . . . . . . 24
+ 7. Broadcast and Multicast . . . . . . . . . . . . . . . . 24
+ 7.1 Protocol for an IP Broadcast Emulation Server - PIBES 25
+ 7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 25
+ 7.3 IP Multicast Address . . . . . . . . . . . . . . . . 25
+ 7.4 A Note on Broadcast Emulation Performance . . . . . . 26
+ 8. HARP for Scheduled Transfer . . . . . . . . . . . . . . . 26
+ 9. Security Consierations . . . . . . . . . . . . . . . . . 26
+ 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 27
+ 11. HARP Examples . . . . . . . . . . . . . . . . . . . . . 27
+ 11.1 Registr. Phase of Client Y on Non-broadcast Hardware 27
+ 11.2 Registr. Phase of Client Y on Broadcast-capable . . 28
+ 11.3 Operational Phase (phase II) . . . . . . . . . . . 29
+ 11.3.1 Successful HARP_Resolve example . . . . . . 29
+ 11.3.2 Non-successful HARP_Resolve example . . . . 30
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . 31
+ 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . 32
+ 14. Author's Address . . . . . . . . . . . . . . . . . . . . 32
+ 15. Full Copyright Statement . . . . . . . . . . . . . . . . 33
+
+
+
+
+
+
+
+
+Pittet Standards Track [Page 2]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+1. Introduction
+
+ HIPPI-6400 is a duplex data channel that can transmit and receive
+ data simultaneously at nearly 6400 megabits per second. HIPPI-6400
+ data transfers are segmented into micropackets, each composed of 32
+ data bytes and 8 control bytes. HIPPI-6400 uses four multiplexed
+ virtual channels. These virtual channels are allocated to control
+ traffic, low latency traffic, and bulk traffic (see [1] for more
+ details).
+
+ Using small packets and four virtual channels, large file transfers
+ cannot lock out a host or switch port for interactive traffic.
+ HIPPI-6400 guarantees in order delivery of data. It also supports
+ link-level and end-to-end checksumming and credit-based flow control.
+
+ HIPPI-6400-PH defines a 20-bit interface for copper cables operating
+ at 500 MBaud. This provides a user payload bandwidth of 6400 Mb/s
+ (800,000,000 Bytes/sec) in each direction. [8]
+
+ HIPPI-6400-SC [2] defines two types of switches: bridging and non-
+ bridging. The bridging switches are required to support hardware
+ broadcast. Non-bridging switches are not required to support
+ broadcast. This memo allows for a coherent implementation of IP and
+ HARP with both types of switches.
+
+ Gigabyte System Network(TM) (GSN) is a marketing name for HIPPI-6400.
+ It is a trademark of the High Performance Networking Forum (HNF;
+ http://www.hnf.org) for use by its member companies that supply
+ products complying to ANSI HIPPI-6400 standards.
+
+2 Definitions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC-2119 [19].
+
+2.1 Global concepts used
+
+ In the following discussion, the terms "requester" and "target" are
+ used to identify the port initiating the address resolution request
+ and the port whose address it wishes to discover, respectively. This
+ document will use HIPPI-800 and HIPPI-6400 when referring to concepts
+ that apply to one or the other technology. The term HIPPI will be
+ used when referring to both technologies.
+
+ Values are decimal unless otherwise noted. Formatting follows IEEE
+ 802.1A canonical bit order and HIPPI-6400-PH bit and byte ordering.
+
+
+
+
+Pittet Standards Track [Page 3]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+2.2 Glossary
+
+ Broadcast
+
+ A distribution mode which transmits a message to all ports. The
+ sending port is part of "all" and will therefore also receive a copy
+ of the sent message.
+
+ Classical/Conventional
+
+ Both terms are used with respect to networks, including Ethernet,
+ FDDI, and other 802 LAN types, as distinct from HIPPI-SC LANs.
+
+ Destination
+
+ The HIPPI port that receives data from a HIPPI Source.
+
+ HARP
+
+ HARP (HIPPI Address Resolution Protocol describes the whole set of
+ HIPPI-6400 address resolution encodings and algorithms defined in
+ this memo. HARP is a combination and adaptation of the Internet
+ Address Resolution Protocol (ARP) RFC-826 [14] and Inverse ARP
+ (InARP) [5] (see section 5). HARP also describes the HIPPI (800 and
+ 6400) specific version of ARP (i.e. the protocol and the HIPPI
+ specific encoding).
+
+ HARP table
+
+ Each host has a HARP table which contains the IP to hardware address
+ mapping of IP members.
+
+ HRAL
+
+ The HARP Request Address List. A list of ULAs to which HARP messages
+ are sent when resolving names to addresses (see section 3.2).
+
+ Hardware (HW) address
+
+ The hardware address of a port; it consists of an ULA (see section
+ 4.2). Note: the term port as used in this document refers to a HIPPI
+ port and is roughly equivalent to the term "interface" as commonly
+ used in other IP documents.
+
+ Host
+
+ An entity, usually a computer system, that may have one or more HIPPI
+ ports and which may serve as a client or a HARP server.
+
+
+
+Pittet Standards Track [Page 4]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ Port
+
+ An entity consisting of one HIPPI Source/Destination dual simplex
+ pair that is connected by parallel or serial HIPPI to a HIPPI-SC
+ switch and that transmits and receives IP datagrams. A port may be
+ an Internet host, bridge, router, or gateway.
+
+ PIBES
+
+ The Protocol for Internet Broadcast Emulation Server (see section 7).
+
+ Source
+
+ The HIPPI port that generates data to send to a HIPPI Destination.
+
+ Universal LAN MAC Address (ULA)
+
+ A 48-bit globally unique address, administered by the IEEE, assigned
+ to each port on an Ethernet, FDDI, 802 network, or HIPPI-SC LAN.
+
+3. IP Subnetwork Configuration
+
+3.1 Background
+
+ ARP (address resolution protocol) as defined in [14] was meant to
+ work on the 'local' cable. This definition gives the ARP protocol a
+ local logical IP subnet (LIS) scope. In the LIS scenario, each
+ separate administrative entity configures its hosts and routers
+ within the LIS. Each LIS operates and communicates independently of
+ other LIS's on the same HIPPI-6400 network.
+
+ HARP has LIS scope only and serves all ports in the LIS.
+ Communication to ports located outside of the local LIS is usually
+ provided via an IP router. This router is a HIPPI-6400 port attached
+ to the HIPPI-6400 network that is configured as a member of one or
+ more LIS's. This configuration MAY result in a number of disjoint
+ LIS's operating over the same HIPPI-6400 network. Using this model,
+ ports of different IP subnets SHOULD communicate via an intermediate
+ IP router even though it may be possible to open a direct HIPPI-6400
+ connection between the two IP members over the HIPPI-6400 network.
+ This is an consequence of using IP and choosing to have multiple
+ LIS's on the same HIPPI-6400 fabric.
+
+ By default, the HARP method detailed in section 5 and the classical
+ LIS routing model MUST be available to any IP member client in the
+ LIS.
+
+
+
+
+
+Pittet Standards Track [Page 5]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+3.2 HIPPI LIS Requirements
+
+ The requirement for IP members (hosts, routers) operating in a
+ HIPPI-6400 LIS configuration is:
+
+ o All members of the LIS SHALL have the same IP network/subnet
+ address and address mask [4].
+
+ The following list identifies the set of HIPPI-6400-specific
+ parameters that MUST be implemented in each IP station connected to
+ the HIPPI-6400 network:
+
+ o HIPPI-6400 Hardware Address:
+
+ The HIPPI-6400 hardware address (a ULA) of an individual IP
+ endpoint (i.e. a network adapter within a host) MUST be unique in
+ the LIS.
+
+ o HARP Request Address List (HRAL):
+
+ The HRAL is an ordered list of two or more addresses identifying the
+ address resolution service(s). All HARP clients MUST be configured
+ identically, i.e. all ports MUST have the same addresses(es) in the
+ HRAL.
+
+ The HRAL MUST contain at least two HIPPI HW addresses identifying the
+ individual HARP service(s) that have authoritative responsibility for
+ resolving HARP requests of all IP members located within the LIS. By
+ default the first address MUST be the reserved address for broadcast,
+ i.e. FF:FF:FF:FF:FF:FF.
+
+ The second address MUST be the standard HW address for the HARP
+ server 00:10:3B:FF:FF:E0.
+
+ Therefore, the HRAL entries are sorted in the following order:
+ 1st : broadcast address (FF:FF:FF:FF:FF:FF) REQUIRED
+ 2nd : official HARP server address (00:10:3B:FF:FF:E0) REQUIRED
+ 3rd & on: any additional HARP server addresses will be OPTIONAL
+ sorted in decreasing order.
+
+ Manual configuration of the addresses and address lists presented in
+ this section is implementation dependent and beyond the scope of this
+ memo. However, prior to use by any service or operation detailed in
+ this memo, clients MUST have HRAL address(es) configured as
+ appropriate for their LIS.
+
+
+
+
+
+
+Pittet Standards Track [Page 6]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+4. Internet Protocol
+
+4.1 Packet format
+
+ The HIPPI-6400 packet format for Internet datagrams [15] shall
+ conform to the HIPPI-6400-PH standard [1]. The length of a HIPPI-
+ 6400-PH packet, including headers and trailing fill, shall be a
+ multiple of 32 bytes as required by HIPPI-6400-PH.
+
+ All IP Datagrams shall be carried on HIPPI-6400-PH Virtual Channel 1
+ (VC1). Since HIPPI-6400-PH has a 32-byte granularity, IP Datagrams
+ MUST be padded to a 32-byte granularity prior to sending. Added
+ padding is transparent to IP and is not reflected in the length field
+ of the IP header.
+
+ D_ULA Destination ULA SHALL be the ULA of the destination port.
+
+ S_ULA Source ULA SHALL be the ULA of the requesting port.
+
+ M_len Set to the IEEE 802 packet (e.g. IP or HARP message)
+ length + 8 Bytes to account for the LLC/SNAP header length.
+ The HIPPI-6400-PH [1] length parameter shall not include
+ the pad.
+
+4.1.1 IEEE 802.2 LLC
+
+ The IEEE 802.2 LLC Header SHALL begin in the first byte after M_len.
+
+ The LLC values (in hexadecimal and decimal) SHALL be
+
+ SSAP 0xAA 170 (8 bits)
+ DSAP 0xAA 170 (8 bits)
+ CTL 0x03 3 (8 bits)
+
+ for a total length of 3 bytes. The 0x03 CTL value indicates the
+ presence of a SNAP header.
+
+4.1.2 SNAP
+
+ The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes)
+ indicating that the following two-bytes is an Ethertype.
+
+ The Ethertype value SHALL be set as defined in Assigned Numbers [18]:
+
+ IP 0x0800 2048 (16 bits)
+ HARP = ARP = 0x0806 2054 (16 bits)
+
+ The total size of the LLC/SNAP header is fixed at 8 bytes.
+
+
+
+Pittet Standards Track [Page 7]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+4.1.3 HIPPI-6400 802 Packet diagrams
+
+ The following diagram shows a HIPPI-6400 message carrying IEEE 802
+ data.
+
+ |31 |23 |15 |7 0|
+ +------------+------------+------------+------------+ -------------
+ 0 | |
+ | D_ULA +-------------------------+ HIPPI-6400
+ 1 | | |
+ +-------------------------+ S_ULA | MAC
+ 2 | |
+ +---------------------------------------------------+ header
+ 3 | M_len |
+ +------------+------------+------------+------------+ -------------
+ 4 | DSAP | SSAP | Ctl | Org | IEEE 802
+ +------------+------------+------------+------------+ LLC/SNAP
+ 5 | Org | Org | Ethertype | header
+ +============+============+============+============+ =============
+ 6 | Msg byte 0 | Msg byte 1 | Msg byte 2 | . . . | IEEE 802
+ +---------------------------------------------------+ Data
+ Generic 802.1 data packet diagram
+
+ The following diagram shows an IP datagram of length n with the FILL
+ bytes ( value: 0x0 ). "<><>" indicates the micropacket separation. A
+ HIPPI-6400-PH [1] micropacket is 32 bytes long.
+
+ All IP (v4) [15] packets will always span two or more micropackets.
+ The first micropacket has a TYPE = header. The second and any further
+ micropackets have a TYPE = Data (see [1]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pittet Standards Track [Page 8]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ |31 |23 |15 |7 0|
+ +------------+------------+------------+------------+ -------------
+ 0 | |
+ | D_ULA +-------------------------+ HIPPI-6400
+ 1 | | |
+ +-------------------------+ S_ULA | MAC
+ 2 | |
+ +---------------------------------------------------+ header
+ 3 | M_len |
+ +------------+------------+------------+------------+ -------------
+ 4 | AA | AA | 03 | 00 | IEEE 802
+ +------------+------------+------------+------------+ LLC/SNAP
+ 5 | 00 | 00 | Ethertype = 0x0800=2048 | header
+ +============+============+============+============+ =============
+ 6 | VER | HLEN | TOS | Total Length |
+ +-----+------+------------+-----+-------------------+
+ 7 | ID | FLG | Frag Offset |
+ +<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ IPv4 Header
+ 8 | TTL | PROTO | Header Checksum |
+ +------------+------------+-------------------------+
+ 9 | Source IP Address |
+ +---------------------------------------------------+
+ 10 | Destination IP Address |
+ +---------------------------------------------------+
+ 11 | . . . |
+ +---------------------------------------------------+
+ | . . . | byte (n-2) | byte (n-1) | FILL |
+ +------------+------------+------------+------------+
+ | FILL | FILL | FILL | FILL |
+ +------------+------------+------------+------------+
+ M-1| FILL | FILL | FILL | FILL |
+ +<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+
+ IP v4 data packet diagram
+
+ As shown in above figure the first eight bytes of the IP Datagram
+ occupy the last eight bytes of the HIPPI-6400-PH [1] Header
+ micropacket.
+
+4.2 HIPPI-6400 Hardware address: Universal LAN MAC address (ULA)
+
+ HIPPI-6400 uses Universal LAN MAC Addresses specified in IEEE
+ Standard 802.1A [10] or a subset as defined in HIPPI-6400-SC [2].
+ The globally unique part of the 48 bit space is administered by the
+ IEEE. Each port on a HIPPI-6400-SC LAN MUST be assigned a ULA.
+ Multiple ULAs may be used if a node contains more than one IEEE 802.2
+ LLC protocol entity.
+
+
+
+
+
+Pittet Standards Track [Page 9]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ This memo assumes the use of "Logical Addressing" as described in
+ Annex A.2 of HIPPI-6400-SC[2].
+
+ The format of the address within its 48 bit HIPPI-6400-PH fields
+ follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit and
+ byte order:
+
+ 31 23 15 7 0
+ +---------------+---------------+---------------+---------------+
+ |ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 |
+ +---------------+---------------+---------------+---------------+
+ | ULA byte 4 | ULA byte 5 | (not used for ULA) |
+ +---------------+---------------+---------------+---------------+
+
+ Universal LAN MAC Address Format
+
+ L (U/L bit) = 1 for Locally administered addresses, 0 for Universal.
+ G (I/G bit) = 1 for Group addresses, 0 for Individual.
+
+4.3 Maximum Transmission Unit - MTU
+
+ Maximum Transmission Unit (MTU) is defined as the maximum length of
+ the IP packet, including IP header, but not including any overhead
+ below IP, i.e., HIPPI-6400 MAC header and IEEE 802 LLC/SNAP header.
+ Conventional LANs have MTU sizes determined by physical layer
+ specification. MTUs may be required simply because the chosen medium
+ won't work with larger packets, or they may serve to limit the amount
+ of time a node must wait for an opportunity to send a packet.
+
+ HIPPI-6400-PH [1] limits packets to about 4 gigabytes (on VC 3) which
+ imposes no practical limit for networking purposes. HIPPI-6400-PH VC
+ 1, which was chosen for IP and ARP traffic, limits messages to about
+ 128 Kbytes which is still larger than the HIPPI-800 MTU [17].
+
+ The MTU for HIPPI-6400 LANs SHALL be 65280 (decimal) bytes.
+
+ This value is backwards compatible with HIPPI-800. It allows the IP
+ packet to fit in one 64K byte buffer with up to 256 bytes of
+ overhead. The IP v4 overhead is 24 bytes for HIPPI-6400 and 40 bytes
+ for HIPPI-800.
+
+
+
+
+
+
+
+
+
+
+
+Pittet Standards Track [Page 10]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ For HIPPI-6400 the byte accounting is:
+
+ HIPPI-6400-PH Header 16 bytes
+ IEEE 802.2 LLC/SNAP Headers 8 bytes
+ Maximum IP packet size (MTU) 65280 bytes
+ Unused expansion room 232 bytes
+ ------------
+ Total 65536 bytes (64K)
+
+ In contrast, the HIPPI-800 accounting is:
+
+ HIPPI-800-FP Header 8 bytes
+ HIPPI-800-LE Header 24 bytes
+ IEEE 802.2 LLC/SNAP Headers 8 bytes
+ Unused expansion room 216 bytes
+ Maximum IP packet size (MTU) 65280 bytes
+ ------------
+ Total 65536 bytes (64K)
+
+5. HIPPI Address Resolution Protocol - HARP
+
+ Address resolution within the HIPPI-6400 LIS SHALL make use of the
+ HIPPI Address Resolution Protocol (HARP) and the Inverse HIPPI
+ Address Resolution Protocol (InHARP). HARP provides the same
+ functionality as the Internet Address Resolution Protocol (ARP).
+
+ HARP is based on ARP which is defined in RFC-826 [14] except the
+ HIPPI-6400 specific packet format. Knowing the Internet address,
+ conventional networks use ARP to discover another node's hardware
+ address. HARP presented in this section further specifies the
+ combination of the original protocol definitions to form a coherent
+ address resolution service that is independent of the hardware's
+ broadcast capability. InHARP is the same protocol as the original
+ Inverse ARP (InARP) protocol presented in [5] except the HIPPI-6400
+ specific packet format. Knowing its hardware address, InARP is used
+ to discover the other party's Internet address.
+
+ This memo further REQUIRES the PIBES (see section 7) extension to the
+ HARP protocol, guaranteeing broadcast service to upper layer
+ protocols like IP.
+
+ Internet addresses are assigned independent of ULAs. Before using
+ HARP, each node MUST know its IP and its HW addresses. The ULA is
+ optional but is RECOMMENDED if interoperability with conventional
+ networks is desired.
+
+
+
+
+
+
+Pittet Standards Track [Page 11]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ If all switches in the LIS support broadcast, then the source address
+ in the reply will be the target's source address. If all switches in
+ the LIS do not support broadcast, then a HARP server MUST be used to
+ provide the address resolution service, and the source address in the
+ reply will be the HARP server's source address.
+
+5.1 HARP Algorithm
+
+ This section defines the behavior and requirements for HARP
+ implementations on both broadcast and non-broadcast capable HIPPI-
+ 6400-SC networks. HARP creates a table in each port which maps remote
+ ports' IP addresses to ULAs, so that when an application requests a
+ connection to a remote port by its IP address, the remote ULA can be
+ determined, a correct HIPPI-6400-PH header can be built, and a
+ connection to the port can be established using the ULA.
+
+ HARP is a two phase protocol. The first phase is the registration
+ phase and the second phase is the operational phase. In the
+ registration phase the port detects if it is connected to broadcast
+ hardware or not. The InHARP protocol is used in the registration
+ phase. In case of non-broadcast capable hardware, the InHARP
+ Protocol will register and establish a table entry with the server.
+ The operational phase works much like conventional ARP with the
+ exception of the message format.
+
+5.1.1 Selecting the authoritative HARP service
+
+ Within the HIPPI LIS, there SHALL be an authoritative HARP service.
+ To select the authoritative HARP service, each port needs to
+ determine if it is connected to a broadcast network. At each point in
+ time there is only one authoritative HARP service.
+
+ The port SHALL send an InHARP_REQUEST to the first address in the
+ HRAL (FF:FF:FF:FF:FF:FF). If the port sees its own InHARP_REQUEST,
+ then it is connected to a broadcast capable network. In this case,
+ the rest of the HRAL is ignored and the authoritative HARP service is
+ the broadcast entry.
+
+ If the port is connected to a non-broadcast capable network, then the
+ port SHALL send the InHARP_REQUEST to all of the remaining entries in
+ the HRAL. Every address which sends an InHARP_REPLY is considered to
+ be a responsive HARP server. The authoritative HARP service SHALL be
+ the HARP server which appears first in the HRAL.
+
+ The order of addresses in the HRAL is only important for deciding
+ which address will be the authoritative one. On a non-broadcast
+ network, the port is REQUIRED to keep "registered" with all HARP
+ server addresses in the HRAL (NOTE: not the broadcast address since
+
+
+
+Pittet Standards Track [Page 12]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ it is not a HARP server address). If for instance the authoritative
+ HARP service is non-responsive, then the port will consider the next
+ address in the HRAL as a candidate for the authoritative address and
+ send an InHARP_REQUEST.
+
+ The authoritative HARP server SHOULD be considered non-responsive
+ when it has failed to reply to: (1) one or more registration requests
+ by the client (see section 5.1.2 and 5.2), (2) any two HARP_REQUESTs
+ in the last 120 seconds or (3) if an external agent has detected
+ failure of the authoritative HARP server. The details of such an
+ external agent and its interaction with the HARP client are beyond
+ the scope of this document. Should an authoritative HARP server
+ become non-responsive, then the registration process SHOULD be
+ restarted. Alternative methods for choosing an authoritative HARP
+ service are not prohibited.
+
+5.1.2 HARP registration phase
+
+ HARP clients SHALL initiate the registration phase by sending an
+ InHARP_REQUEST message using the HRAL addresses in order. The client
+ SHALL terminate the registration phase and transition into the
+ operational phase, when either: (1) it receives its own
+ InHARP_REQUEST, or (2) when it receives an InHARP_REPLY from at least
+ one of the HARP servers and it has determined the authoritative HARP
+ service as described in 5.1.1.
+
+ When ports are initiated they send an InHARP_REQUEST to the
+ authoritative HRAL address. The first address to be tried will be the
+ broadcast address "FF:FF:FF:FF:FF:FF". There are two outcomes:
+
+ 1. The port sees its own InHARP_REQUEST: then the port is connected
+ to a broadcast capable network. The first address becomes, and
+ remains, the authoritative address for the HARP service.
+
+ 2. The port does not receive its InHARP_REQUEST: then the port is
+ connected to a non-broadcast capable network.
+
+ The port SHALL choose the next address in the HRAL as a candidate
+ for a HARP server and send an InHARP_REQUEST to that address:
+ (00:10:3B:FF:FF:E0).
+
+ The port SHALL continue to retry each non-broadcast HARP server
+ address in the HRAL at least once every 5 seconds until one of the
+ following termination criteria are met for each address.
+
+ a. If the port receives its own message, then the port itself is
+ the HARP server and the port is REQUIRED to provide broadcast
+ services using the PIBES (see section 7).
+
+
+
+Pittet Standards Track [Page 13]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ b. If the port receives an InHARP_REPLY, then it is a HARP client
+ and not a HARP server. In both cases, the current candidate
+ address becomes the authoritative HARP service address.
+
+ InHARP is an application of the InARP protocol for a purpose not
+ originally intended. The purpose is to accomplish registration of
+ port IP address mappings with a HARP server if one exists or detect
+ hardware broadcast capability.
+
+ If the HIPPI-6400-SC LAN supports broadcast, then the client will see
+ its own InHARP_REQUEST message and SHALL complete the registration
+ phase. The client SHOULD further note that it is connected to a
+ broadcast capable network and use this information for aging the HARP
+ server entry and for IP broadcast emulation as specified in sections
+ 5.4 and 5.6 respectively.
+
+ If the client doesn't see its own InHARP_REQUEST it SHALL await an
+ InHARP_REPLY before completing the registration phase. This will also
+ provide the client with the protocol address by which the HARP server
+ is addressable. This will be the case when the client happens to be
+ connected to a non-broadcast capable HIPPI-6400-SC network.
+
+5.1.3 HARP operational phase
+
+ Once a HARP client has completed its registration phase it enters the
+ operational phase. In this phase of the protocol, the HARP client
+ SHALL gain and refresh its own HARP table information about other IP
+ members by sending of HARP_REQUESTs to the authoritative address in
+ the HRAL and by receiving of HARP_REPLYs. The client is fully
+ operational during the operational phase.
+
+ In the operational phase, the client's behavior for requesting HARP
+ resolution is the same for broadcast or non-broadcast HIPPI-6400-SC
+ switched networks.
+
+ The target of an address resolution request updates its address
+ mapping tables with any new information it can find in the request.
+ If it is the target port it SHALL formulate and send a reply message.
+ A port is the target of an address resolution request if at least ONE
+ of the following statements is true of the request:
+
+ 1. The port's IP address is in the target protocol address field
+ (ar$tpa) of the HARP message.
+
+ 2. The port's ULA, is in the ULA part of the Target Hardware Address
+ field (ar$tha) of the message.
+
+ 3. The port is a HARP server.
+
+
+
+Pittet Standards Track [Page 14]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ NOTE: It is REQUIRED to have a HARP server run on a port that has a
+ non-zero ULA.
+
+5.2 HARP Client Operational Requirements
+
+ The HARP client is responsible for contacting the HARP server(s) to
+ have its own HARP information registered and to gain and refresh its
+ own HARP entry/information about other IP members. This means, as
+ noted above, that HARP clients MUST be configured with the hardware
+ address of the HARP server(s) in the HRAL.
+
+ HARP clients MUST:
+
+ 1. When an interface is enabled (e.g. "ifconfig <interface> up" with
+ an IP address) or assigned the first or an additional IP address
+ (i.e. an IP alias), the client SHALL initiate the registration
+ phase.
+
+ 2. In the operational phase the client MUST respond to HARP_REQUEST
+ and InHARP_REQUEST messages if it is the target port. If an
+ interface has multiple IP addresses (e.g., IP aliases) then the
+ client MUST cycle through all the IP addresses and generate an
+ InHARP_REPLY for each such address. In that case an InHARP_REQUEST
+ will have multiple replies. (Refer to Section 7, "Protocol
+ Operation" in RFC-1293 [5].)
+
+ 3. React to address resolution reply messages appropriately to build
+ or refresh its own client HARP table entries. All solicited and
+ unsolicited HARP_REPLYs from the authoritative HARP server SHALL
+ be used to update and refresh its own client HARP table entries.
+
+ Explanation: This allows the HARP server to update the clients
+ when one of server's mappings change, similar to what is
+ accomplished on Ethernet with gratuitous ARP.
+
+ 4. Generate and transmit InHARP_REQUEST messages as needed and
+ process InHARP_REPLY messages appropriately (see section 5.1.3 and
+ 5.6). All InHARP_REPLY messages SHALL be used to build/refresh its
+ client HARP table entries. (Refer to Section 7, "Protocol
+ Operation" in [5].)
+
+ If the registration phase showed that the hardware does not support
+ broadcast, then the client MUST refresh its own entry for the HARP
+ server, created during the registration phase, at least once every 15
+ minutes. This can be accomplished either through the exchange of a
+ HARP request/reply with the HARP server or by repeating step 1. To
+ decrease the redundant network traffic, this timeout SHOULD be reset
+ after each HARP_REQUEST/HARP_REPLY exchange.
+
+
+
+Pittet Standards Track [Page 15]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ Explanation: The HARP_REQUEST shows the HARP server that the client
+ is still alive. Receiving a HARP_REPLY indicates to the client that
+ the server must have seen the HARP_REQUEST.
+
+ If the registration phase showed that the underlying network supports
+ broadcast, then the refresh sequence is NOT REQUIRED.
+
+5.3 Receiving Unknown HARP Messages
+
+ If a HARP client receives a HARP message with an operation code
+ (ar$op) that it does not support, it MUST gracefully discard the
+ message and continue normal operation. A HARP client is NOT REQUIRED
+ to return any message to the sender of the undefined message.
+
+5.4 HARP Server Operational Requirements
+
+ A HARP server MUST accept HIPPI-6400 connections from other HIPPI-
+ 6400 ports. The HARP server expects an InHARP_REQUEST as the first
+ message from the client. A server examines the IP address, the
+ hardware address of the InHARP_REQUEST and adds or updates its HARP
+ table entry <IP address(es), ULA> as well as the time stamp.
+
+ A HARP server replies to HARP_REQUESTs and InHARP_REQUESTs based on
+ the information which it has in its table. The HARP server replies
+ SHALL contain the hardware type and corresponding format of the
+ request (see also sec. 6).
+
+ The following table shows all possible source address combinations on
+ an incoming message and the actions to be taken. "linked" indicates
+ that an existing "IP entry" is linked to a "hardware entry". It is
+ possible to have an existing "IP entry" and to have an existing
+ "hardware entry" but neither is linked to the other.
+
+ +---+----------+----------+------------+---------------------+
+ | # | IP entry | HW entry | misc | Action |
+ +---+----------+----------+------------+---------------------+
+ | 1 | exists | exists | linked | * |
+ | 2 | exists | exists | not linked | *, a, b, e, f |
+ | 3 | exists | new | not linked | *, a, b, d, e, f |
+ | 4 | new | exists | not linked | *, c, e, f |
+ | 5 | new | new | not linked | *, c, d, e, f |
+ +---+----------+----------+------------+---------------------+
+ Actions:
+ *: update timeout value
+ a: break the existing IP -> hardware (HW) -old link
+ b: delete HW(old) -> IP link and decrement HW(old) refcount,
+ if refcount = 0, delete HW(old)
+ c: create new IP entry
+
+
+
+Pittet Standards Track [Page 16]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ d: create new HW entry
+ e: add new IP -> HW link to IP entry
+ f: add new HW -> IP link to HW entry
+
+ Examples of when this could happen (Numbers match lines in above
+ table):
+
+ 1: supplemental message
+
+ Just update timer.
+
+ 2: move an IP alias to an existing interface
+
+ If the IP source address of the InHARP_REQUEST duplicates a table
+ entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST
+ hardware source address matches a hardware address entry (e. g.
+ HWb <-> IPb), but they are not linked together, then:
+
+ - HWa entry needs to have its reference to the current IPa
+ address removed.
+ - HWb needs to have a new reference to IPa added
+ - IPa needs to be linked to HWb
+
+ The result will be a table with: IPb <-> HWa <-> IPb If IPb was
+ the only IP address referred to by the HWb entry, then delete the
+ HWb entry.
+
+ 3: move IP address to a new interface
+
+ If the InHARP_REQUEST requester's IP source address duplicates a
+ table entry IP address and the InHARP_REQUEST hardware source
+ address does not match the table entry hardware address, then a
+ new HW entry SHALL be created. The requestor's IP address SHALL be
+ moved from the original HW entry to the new one (see above).
+
+ 4: add IP alias to table
+
+ If the InHARP_REQUEST requester's hardware source address
+ duplicates a hardware source address entry, but there is no IP
+ entry matching the received IP address, then the IP address SHALL
+ be added to the hardware entries previous IP address(es). (E.g.
+ adding an IP alias).
+
+ 5: fresh entry, add it
+
+ Standard case, create both entries and link them.
+
+
+
+
+
+Pittet Standards Track [Page 17]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ A server MUST update the HARP table entry's timeout for each
+ HARP_REQUEST. Explanation: if the client is sending HARP requests to
+ the server, then the server should note that the client is still
+ "alive" by updating the timeout on the client's HARP table entry.
+
+ A HARP server SHOULD use the PIBES (see sect. 7) to send out
+ HARP_REPLYs to all hardware addresses in its table when the HARP
+ server table changes mappings. This feature decreases the time of
+ stale entries in the clients.
+
+ If there are multiple addresses in the HRAL, then a server needs to
+ act as a client to the other servers.
+
+5.5 HARP and Permanent ARP Table Entries
+
+ An IP station MUST have a mechanism (e.g. manual configuration) for
+ determining what permanent entries it has. The details of the
+ mechanism are beyond the scope of this memo. The permanent entries
+ allow interoperability with legacy HIPPI adapters which do not yet
+ implement dynamic HARP and use a table based static ARP. Permanent
+ entries are not aged.
+
+ The HARP server SHOULD use the static entries to resolve incoming
+ HARP_REQUESTs from the clients. This feature eliminates the need for
+ maintaining a static HARP table on the client ports.
+
+5.6 HARP Table Aging
+
+ HARP table aging MUST be supported since IP addresses, especially IP
+ aliases and also interfaces (with their ULA), are likely to move.
+ When so doing the mapping in the clients own HARP table/cache becomes
+ invalid and stale.
+
+ o When a client's HARP table entry ages beyond 15 minutes, a HARP
+ client MUST invalidate the table entry.
+
+ o When a server's HARP table entry ages beyond 20 minutes, the HARP
+ server MUST delete the table entry.
+
+ NOTE: the client SHOULD revalidate a HARP table entry before it ages,
+ thus restarting the aging time when the table entry is successfully
+ revalidated. The client MAY continue sending traffic to the port
+ referred to by this entry while revalidation is in progress, as long
+ as the table entry has not aged. The client MUST revalidate the
+ invalidated entry prior to transmitting any non-address resolution
+ traffic to the port referred to by this entry.
+
+
+
+
+
+Pittet Standards Track [Page 18]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ The client revalidates the entry by querying the HARP server. If a
+ valid reply is received (e.g. HARP_REPLY), the entry is updated. If
+ the address resolution service cannot resolve the entry (e.g.
+ HARP_NAK, "host not found"), the associated table entry is removed.
+ If the address resolution service is not available (i.e. "server
+ failure") the client MUST attempt to revalidate the entry by
+ transmitting an InHARP_REQUEST to the hardware address of the entry
+ in question and updating the entry on receipt of an InHARP_REPLY. If
+ the InHARP_REQUEST attempt fails to return an InHARP_REPLY, the
+ associated table entry is removed.
+
+6. HARP Message Encoding
+
+ The HARP message is another type of IEEE 802 payload as described in
+ section 4.1.3 above. The HIPPI-6400 HARP SHALL support two packet
+ formats, both the generic Ethernet ARP packet and the HIPPI-800 HARP
+ packet format defined in [13]. HARP messages SHALL be transmitted
+ with a hardware type code of 28 on non-broadcast capable hardware or
+ 1 in either case.
+
+ The ar$hrd field SHALL be used to differentiate between the two
+ packet formats. The reply SHALL be in the format of the request.
+
+6.1 Generic IEEE 802 ARP Message Format
+
+ This is the ARP packet format used by conventional IEEE 802 networks
+ (i.e. Ethernet, etc). The packet format is described in RFC-826 [14]
+ and is given here only for completeness purpose.
+
+ ar$hrd 16 bits Hardware type
+ ar$pro 16 bits Protocol type of the protocol fields below
+ ar$hln 8 bits byte length of each hardware address
+ ar$pln 8 bits byte length of each protocol address
+ ar$op 16 bits opcode (ares_op$REQUEST | ares_op$REPLY)
+ ar$sha 48 bits Hardware address of sender of this packet
+ ar$spa 32 bits Protocol address of sender of this packet
+ ar$tha 48 bits Hardware address of target of this
+ ar$tpa 32 bits Protocol address of target.
+
+ Where:
+ ar$hrd - SHALL contain 1. (Ethernet)
+
+ ar$pro - SHALL contain the IP protocol code 2048 (decimal).
+
+ ar$hln - SHALL contain 6.
+
+ ar$pln - SHALL contain 4.
+
+
+
+
+Pittet Standards Track [Page 19]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ ar$op - SHALL contain the operational value (decimal):
+ 1 for HARP_REQUESTs
+ 2 for HARP_REPLYs
+ 8 for InHARP_REQUESTs
+ 9 for InHARP_REPLYs
+ 10 for HARP_NAK
+
+ ar$rpa - in requests and NAKs it SHALL contain the requester's IP
+ address if known, otherwise zero.
+ In other replies it SHALL contain the target
+ port's IP address.
+
+ ar$sha - in requests and NAKs it SHALL contain the requester's ULA
+ In replies it SHALL contain the target port's ULA.
+
+ ar$spa - in requests and NAKs it SHALL contain the requester's IP
+ address if known, otherwise zero.
+ In other replies it SHALL contain the target
+ port's IP address.
+
+ ar$tha - in requests and NAKs it SHALL contain the target's ULA
+ if known, otherwise zero.
+ In other replies it SHALL contain the requester's ULA.
+
+ ar$tpa - in requests and NAKs it SHALL contain the
+ target's IP address if known, otherwise zero.
+ In other replies it SHALL contain the requester's
+ IP address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pittet Standards Track [Page 20]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ |31 |23 |15 |7 0|
+ +---------------+---------------+---------------+---------------+-----
+ 0 | |
+ | D_ULA +-------------------------------+HIPPI
+ 1 | | |6400
+ +-------------------------------+ S_ULA |MAC
+ 2 | |hdr
+ +---------------------------------------------------------------+
+ 3 | M_len |
+ +---------------+---------------+---------------+---------------+-----
+ 4 | AA | AA | 03 | 00 |IEEE
+ +---------------+---------------+---------------+---------------+802
+ 5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/
+ +------------+------------------+-------------------------------+SNAP
+ 6 | hrd (1) | pro (2048) |
+ +---------------+---------------+---------------+---------------+
+ 7 | hln (6) | phl (4) | op (ar$op) |
+ +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+
+ 8 | Source Hardware Address 0 - 3 |
+ +-------------------------------+-------------------------------+
+ 9 | Source ULA bytes 4 - 5 | Source IP Address bytes 0 - 1 |
+ +-------------------------------+-------------------------------+
+10 | Source IP Address bytes 2 - 3 | Target ULA bytes 0 - 1 |
+ +-------------------------------+-------------------------------+
+11 | Target Hardware Address (ULA) bytes 2 - 5 |
+ +---------------------------------------------------------------+
+12 | Target IP Address |
+ +---------------+---------------+---------------+---------------+
+13 | FILL | FILL | FILL | FILL |
+ +---------------+---------------+---------------+---------------+
+14 | FILL | FILL | FILL | FILL |
+ +><><><><><><><>+<><><><><><><><+><><><><><><><>+<><><><><><><><+
+
+6.2 HIPARP Message Formats
+
+ The HARP protocols further SHALL support the HIPARP hardware type
+ (ar$hrd) = 28 (dec) [18], protocol type (ar$pro), and operation code
+ (ar$op) data formats as the ARP, and InARP protocols [14,7]. In
+ addition, HARP makes use of an additional operation code for ARP_NAK
+ introduced with [11]. The remainder of the HIPARP message format
+ (defined in [13]) is different than the ARP/InARP message format
+ defined in [14,7,10] and it is also different from the format defined
+ in the first "IP and ARP on HIPPI" RFC-1374 [16].
+
+ The HARP message has several fields that have the following format
+ and values:
+
+
+
+
+
+Pittet Standards Track [Page 21]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ Data sizes and field meaning:
+ ar$hrd 16 bits Hardware type
+ ar$pro 16 bits Protocol type of the protocol fields below
+ ar$op 16 bits Operation code (request, reply, or NAK)
+ ar$pln 8 bits byte length of each protocol address
+ ar$rhl 8 bits requester's HIPPI hardware address length (q)
+ ar$thl 8 bits target's HIPPI hardware address length (x)
+ ar$rpa 32 bits requester's protocol address
+ ar$tpa 32 bits target's protocol address
+ ar$rha qbytes requester's HIPPI Hardware address
+ ar$tha xbytes target's HIPPI Hardware address
+
+ Where :
+ ar$hrd - SHALL contain 28. (HIPARP)
+
+ ar$pro - SHALL contain the IP protocol code 2048 (decimal).
+
+ ar$op - SHALL contain the operational value (decimal):
+ 1 for HARP_REQUESTs
+ 2 for HARP_REPLYs
+ 8 for InHARP_REQUESTs
+ 9 for InHARP_REPLYs
+ 10 for HARP_NAK
+
+ ar$pln - SHALL contain 4.
+
+ ar$rln - SHALL contain 10 IF this is a HIPPI-800 HW address
+ ELSE, for HIPPI-6400, it SHALL contain 6.
+
+ ar$thl - SHALL contain 10 IF this is a HIPPI-800 HW address
+ ELSE, for HIPPI-6400, it SHALL contain 6.
+
+ ar$rha - in requests and NAKs it SHALL contain the requester's
+ HW address.
+ In replies it SHALL contain the target port's HW address.
+
+ ar$rpa - in requests and NAKs it SHALL contain the requester's IP
+ address if known, otherwise zero.
+ In other replies it SHALL contain the target
+ port's IP address.
+
+ ar$tha - in requests and NAKs it SHALL contain the target's
+ HW address if known, otherwise zero.
+
+ In other replies it SHALL contain the requester's
+ HW address.
+
+
+
+
+
+Pittet Standards Track [Page 22]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ ar$tpa - in requests and NAKs it SHALL contain the
+ target's IP address if known, otherwise zero.
+ In other replies it SHALL contain the requester's
+ IP address.
+
+ Payload Format for HARP/InHARP PDUs:
+
+ |31 |23 |15 |7 0|
+ +---------------+---------------+---------------+---------------+-----
+ 0 | |
+ | D_ULA +-------------------------------+HIPPI
+ 1 | | |6400
+ +-------------------------------+ S_ULA |MAC
+ 2 | |hdr
+ +---------------------------------------------------------------+
+ 3 | M_len |
+ +---------------+---------------+---------------+---------------+-----
+ 4 | AA | AA | 03 | 00 |IEEE
+ +---------------+---------------+---------------+---------------+802
+ 5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/
+ +------------+------------------+-------------------------------+SNAP
+ 6 | hrd (28) | pro (2048) |
+ +---------------+---------------+---------------+---------------+
+ 7 | op (ar$op) | pln (6) | shl (q) |
+ +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+
+ 8 | thl (x) | Source IP Address upper (24 bits) |
+ +---------------------------------------------------------------+
+ 9 | Src. IP lower | Target IP Address upper (24 bits) |
+ +---------------+-----------------------------------------------+
+10 | Tgt. IP lower | Source HW Address bytes 0 - 2 |
+ +---------------+-------------------------------+---------------+
+11 | Source HW Address bytes 3 - q | Tgt HW byte 0 |
+ +-----------------------------------------------+---------------+
+12 | Target Hardware Address bytes 1 - 4 |
+ +---------------+-----------------------------------------------+
+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 of the HRAL and sends
+ a HARP_REQUEST for Y's hardware address:
+
+ HIPPI-6400-PH D_ULA = ULAa
+ HIPPI-6400-PH S_ULA = ULAx
+ HARP ar$op = 1 (HARP_REQUEST)
+ HARP ar$rpa = IPx
+ HARP ar$tpa = IPy
+ HARP ar$rha = ULAx
+ HARP ar$tha = 0 **
+ ** is what we would like to find out
+
+ 2. The HARP server receives the HARP request and updates its entry
+ for X if necessary. It then generates a HARP_REPLY with Y's
+ hardware address information.
+
+ HIPPI-6400-PH D_ULA = ULAx
+ HIPPI-6400-PH S_ULA = ULAa
+ HARP ar$op = 2 (HARP_Reply)
+ HARP ar$rpa = IPy
+ HARP ar$tpa = IPx
+ HARP ar$rha = ULAy *
+ HARP ar$tha = ULAx
+ * answer we were looking for
+
+ 3. Port X connects to port Y and transmits an IP message with the
+ following information in the HIPPI-LE header:
+
+ HIPPI-6400-PH D_ULA = ULAy
+ HIPPI-6400-PH S_ULA = ULAx
+ <data>
+
+
+
+
+
+
+Pittet Standards Track [Page 29]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ If the network had been broadcast-capable, the target ports would
+ themselves have received the HARP_REQUEST of step 2 above and
+ responded to them in the same way the HARP server did.
+
+11.3.2 Non-successful HARP_Resolve example
+
+ As in 11.3.1, assume that X and Y are fully registered with the HARP
+ server. Then the state of X and Y's HARP server table entry is:
+ VALID. So lets look at the message traffic when X tries to send a
+ message to Q. Further assume that interface Q is NOT configured UP,
+ i.e. it is DOWN. Since X doesn't have an entry for Q,
+
+ 1. Port X connects to the HARP server switch address and sends a
+ HARP_REQUEST for Q's hardware address:
+
+ HIPPI-6400-PH D_ULA = ULAa
+ HIPPI-6400-PH S_ULA = ULAx
+ HARP ar$op = 1 (HARP_REQUEST)
+ HARP ar$rpa = IPx
+ HARP ar$tpa = IPq
+ HARP ar$rha = ULAx
+ HARP ar$tha = 0 **
+ ** is what we would like to find out
+
+ 2. The HARP server receives the HARP request and updates its entry
+ for X if necessary. It then looks up IPq in its tables and doesn't
+ find it. The HARP server then generates a HARP_NAK reply message.
+
+ HIPPI-6400-PH D_ULA = ULAx
+ HIPPI-6400-PH S_ULA = ULAa
+ HARP ar$op = 10 (HARP_NAK)
+ HARP ar$rpa = IPx
+ HARP ar$tpa = IPq
+ HARP ar$rha = ULAx
+ HARP ar$tha = 0 ***
+ *** No Answer, and notice that the fields do not get swapped,
+ i.e. the HARP message is the same as the HARP_REQUEST
+ except for the operation code.
+
+ If the network had been broadcast-capable, then there would not have
+ been a reply.
+
+
+
+
+
+
+
+
+
+
+Pittet Standards Track [Page 30]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+12 References
+
+ [1] ANSI NCITS 323-1998, Information Technology - High-Performance
+ Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH).
+
+ [2] ANSI NCITS 324-199x, Information Technology - High-Performance
+ Parallel Interface - 6400 Mbit/s Physical Switch Control
+ (HIPPI-6400-SC).
+
+ [3] ANSI NCITS Project Number 1249-D, Information Technology -
+ High-Performance Parallel Interface - 6400 Mbit/s Optical
+ Specification (HIPPI-6400-OPT).
+
+ [4] Braden, R., "Requirements for Internet Hosts -- Communication
+ Layers", STD 3, RFC 1122, October 1989.
+
+ [5] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol",
+ RFC 2390, September 1998.
+
+ [6] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
+ Suite", ACM Computer Communications Review, Vol. 19, Issue 2,
+ pp. 32-48, 1989.
+
+ [7] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC
+ 1112, August 1989.
+
+ [8] Chesson, Greg, "HIPPI-6400 Overview", IEEE Hot Interconnects
+ 1996, Stanford University.
+
+ [10] ANSI/IEEE Std. 802.2-1989, Information Processing Systems -
+ Local Area Networks - Logical Link Control IEEE, IEEE, New York,
+ New York, 1989.
+
+ [11] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April
+ 1998.
+
+ [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
+ November, 1990.
+
+ [13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", RFC 2834,
+ May 2000.
+
+ [14] Plummer, D., "An Ethernet Address Resolution Protocol - or -
+ Converting Network Addresses to 48-bit Ethernet Address for
+ Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
+
+
+
+
+
+
+Pittet Standards Track [Page 31]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+ [15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
+
+ [16] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374,
+ October 1992.
+
+ [17] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
+
+ [18] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ October 1994.
+
+ [19] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+13 Acknowledgments
+
+ This memo could not have come into being without the critical review
+ from Greg Chesson, Carlin Otto, the High performance interconnect
+ group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand
+ and Jeff Young) and the expertise of the ANSI T11.1 Task Group
+ responsible for the HIPPI standards work.
+
+ This memo is based on the second part of [17], written by John
+ Renwick. ARP [14] written by Dave Plummer and Inverse ARP [7] written
+ by Terry Bradley and Caralyn Brown provide the fundamental algorithms
+ of HARP as presented in this memo. Further, the HARP server is based
+ on concepts and models presented in [13], written by Mark Laubach who
+ laid the structural groundwork for the HARP server.
+
+14 Author's Address
+
+ Jean-Michel Pittet
+ Silicon Graphics Inc
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94040
+
+ Phone: 650-933-6149
+ Fax: 650-933-3542
+ EMail: jmp@sgi.com, jmp@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pittet Standards Track [Page 32]
+
+RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
+
+
+15 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pittet Standards Track [Page 33]
+