< draft-pittet-gsnlan-02.txt   draft-pittet-gsnlan-03.txt >
Network Working Group J.-M. Pittet Network Working Group J.-M. Pittet
INTERNET DRAFT Silicon Graphics Inc. INTERNET DRAFT Silicon Graphics Inc.
Expires April 2000 October 1999 Expires July 2000 January 2000
IP and ARP over HIPPI-6400 (GSN) IP and ARP over HIPPI-6400 (GSN)
<draft-pittet-gsnlan-02.txt> <draft-pittet-gsnlan-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 5 skipping to change at page 2, line 5
T11.1 chose to leave HIPPI-6400 networking issues largely outside the T11.1 chose to leave HIPPI-6400 networking issues largely outside the
scope of their standards; this document specifies the use of HIPPI- scope of their standards; this document specifies the use of HIPPI-
6400 switches as IP local area networks. This document further 6400 switches as IP local area networks. This document further
specifies a method for resolving IP addresses to HIPPI-6400 hardware specifies a method for resolving IP addresses to HIPPI-6400 hardware
addresses (HARP) and for emulating IP broadcast in a logical IP addresses (HARP) and for emulating IP broadcast in a logical IP
subnet (LIS) as a direct extension of HARP. Furthermore it is the 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 goal of this memo to define a IP and HARP that will allow
interoperability for HIPPI-800 and HIPPI-6400 equipment both interoperability for HIPPI-800 and HIPPI-6400 equipment both
broadcast and non-broadcast capable networks. broadcast and non-broadcast capable networks.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00 INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Global concepts used . . . . . . . . . . . . . . . . 3 2.1 Global concepts used . . . . . . . . . . . . . . . . 3
2.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 4
3. IP Subnetwork Configuration . . . . . . . . . . . . . . . 5 3. IP Subnetwork Configuration . . . . . . . . . . . . . . . 5
3.1 Background . . . . . . . . . . . . . . . . . . . . . 5 3.1 Background . . . . . . . . . . . . . . . . . . . . . 5
3.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 6 3.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 6
4. Internet Protocol . . . . . . . . . . . . . . . . . . . . 7 4. Internet Protocol . . . . . . . . . . . . . . . . . . . . 7
4.1 Packet Format . . . . . . . . . . . . . . . . . . . 7 4.1 Packet Format . . . . . . . . . . . . . . . . . . . 7
4.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 7 4.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 7
4.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 7 4.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 7
4.1.3 Packet diagrams . . . . . . . . . . . . . . . 8 4.1.3 Packet diagrams . . . . . . . . . . . . . . . 8
4.2 HIPPI-6400 Hardware address: Universal LAN MAC addr. 9 4.2 HIPPI-6400 Hardware address: Universal LAN MAC addr. 9
4.3 Maximum Transmission Unit - MTU . . . . . . . . . . 10 4.3 Maximum Transmission Unit - MTU . . . . . . . . . . 10
5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 10 5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 11
5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 11 5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 11
5.1.1 Selecting the authoritative HARP service . . . 12 5.1.1 Selecting the authoritative HARP service . . . 12
5.1.2 HARP registration phase . . . . . . . . . . . 12 5.1.2 HARP registration phase . . . . . . . . . . . 13
5.1.3 HARP operational phase . . . . . . . . . . . . 13 5.1.3 HARP operational phase . . . . . . . . . . . . 14
5.2 HARP Client Operational Requirements . . . . . . . . 14 5.2 HARP Client Operational Requirements . . . . . . . . 14
5.3 Receiving Unknown HARP Messages . . . . . . . . . . 15 5.3 Receiving Unknown HARP Messages . . . . . . . . . . 16
5.4 HARP Server Operational Requirements . . . . . . . . 15 5.4 HARP Server Operational Requirements . . . . . . . . 16
5.5 HARP and Permanent ARP Table Entries . . . . . . . . 17 5.5 HARP and Permanent ARP Table Entries . . . . . . . . 18
5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 18 5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 18
6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 18 6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 19
6.1 Generic IEEE 802 ARP Message Format . . . . . . . . . 19 6.1 Generic IEEE 802 ARP Message Format . . . . . . . . . 19
6.2 HIPARP Message Formats . . . . . . . . . . . . . . . 20 6.2 HIPARP Message Formats . . . . . . . . . . . . . . . 21
6.2.1 Example Message encodings: . . . . . . . . . . 23 6.2.1 Example Message encodings: . . . . . . . . . . 23
6.2.2 HARP_NAK message format . . . . . . . . . . . . 23 6.2.2 HARP_NAK message format . . . . . . . . . . . . 24
7. Broadcast and Multicast . . . . . . . . . . . . . . . . 23 7. Broadcast and Multicast . . . . . . . . . . . . . . . . 24
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 24 7.1 Protocol for an IP Broadcast Emulation Server - PIBES 25
7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 24 7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 25
7.3 IP Multicast Address . . . . . . . . . . . . . . . . 24 7.3 IP Multicast Address . . . . . . . . . . . . . . . . 25
7.4 A Note on Broadcast Emulation Performance . . . . . . 25 7.4 A Note on Broadcast Emulation Performance . . . . . . 26
8. HARP for Scheduled Transfer . . . . . . . . . . . . . . . 25 8. HARP for Scheduled Transfer . . . . . . . . . . . . . . . 26
9. Security . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Security . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 26 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 27
11. HARP Examples . . . . . . . . . . . . . . . . . . . . . 26 11. HARP Examples . . . . . . . . . . . . . . . . . . . . . 27
11.1 Registr. Phase of Client Y on Non-broadcast Hardware 26 11.1 Registr. Phase of Client Y on Non-broadcast Hardware 27
11.2 Registr. Phase of Client Y on Broadcast-capable . . 27 11.2 Registr. Phase of Client Y on Broadcast-capable . . 27
11.3 Operational Phase (phase II) . . . . . . . . . . . 27 11.3 Operational Phase (phase II) . . . . . . . . . . . 28
11.3.1 Successful HARP_Resolve example . . . . . . 28 11.3.1 Successful HARP_Resolve example . . . . . . 29
11.3.2 Non-successful HARP_Resolve example . . . . 29 11.3.2 Non-successful HARP_Resolve example . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . 31 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . 32
14. Author's Address . . . . . . . . . . . . . . . . . . . . 31 14. Author's Address . . . . . . . . . . . . . . . . . . . . 32
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00 INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
1. Introduction 1. Introduction
HIPPI-6400 is a duplex data channel that can transmit and receive HIPPI-6400 is a duplex data channel that can transmit and receive
data simultaneously at nearly 6400 megabits per second. HIPPI-6400 data simultaneously at nearly 6400 megabits per second. HIPPI-6400
data transfers are segmented into micropackets, each composed of 32 data transfers are segmented into micropackets, each composed of 32
data bytes and 8 control bytes. HIPPI-6400 uses four multiplexed data bytes and 8 control bytes. HIPPI-6400 uses four multiplexed
virtual channels. These virtual channels are allocated to control virtual channels. These virtual channels are allocated to control
traffic, low latency traffic, and bulk traffic (see [1] for more traffic, low latency traffic, and bulk traffic (see [1] for more
details). details).
skipping to change at page 3, line 39 skipping to change at page 3, line 39
broadcast. This memo allows for a coherent implementation of IP and broadcast. This memo allows for a coherent implementation of IP and
HARP with both types of switches. HARP with both types of switches.
Gigabyte System Network(TM) (GSN) is a marketing name for HIPPI-6400. Gigabyte System Network(TM) (GSN) is a marketing name for HIPPI-6400.
It is a trademark of the High Performance Networking Forum (HNF; It is a trademark of the High Performance Networking Forum (HNF;
http://www.hnf.org) for use by its member companies that supply http://www.hnf.org) for use by its member companies that supply
products complying to ANSI HIPPI-6400 standards. products complying to ANSI HIPPI-6400 standards.
2 Definitions 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.
2.1 Global concepts used 2.1 Global concepts used
In the following discussion, the terms "requester" and "target" are In the following discussion, the terms "requester" and "target" are
used to identify the port initiating the address resolution request used to identify the port initiating the address resolution request
and the port whose address it wishes to discover, respectively. This and the port whose address it wishes to discover, respectively. This
document will use HIPPI-800 and HIPPI-6400 when referring to concepts 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 that apply to one or the other technology. The term HIPPI will be
used when referring to both technologies. used when referring to both technologies.
Values are decimal unless otherwise noted. Values are decimal unless otherwise noted. Formatting follows IEEE
802.1A canonical bit order and HIPPI-6400-PH bit and byte ordering.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
2.2 Glossary 2.2 Glossary
Broadcast Broadcast
A distribution mode which transmits a message to all ports. The A distribution mode which transmits a message to all ports. The
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
sending port is part of "all" and will therefore also receive a copy sending port is part of "all" and will therefore also receive a copy
of the sent message. of the sent message.
Classical/Conventional Classical/Conventional
Both terms are used with respect to networks, including Ethernet, Both terms are used with respect to networks, including Ethernet,
FDDI, and other 802 LAN types, as distinct from HIPPI-SC LANs. FDDI, and other 802 LAN types, as distinct from HIPPI-SC LANs.
Destination Destination
skipping to change at page 4, line 36 skipping to change at page 4, line 41
6400) specific version of ARP (i.e. the protocol and the HIPPI 6400) specific version of ARP (i.e. the protocol and the HIPPI
specific encoding). specific encoding).
HARP table HARP table
Each host has a HARP table which contains the IP to hardware address Each host has a HARP table which contains the IP to hardware address
mapping of IP members. mapping of IP members.
HRAL HRAL
The HARP Request Address List (see section 3.2). 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 Hardware (HW) address
The hardware address consisting of an ULA (see section 4.2) 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.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
Host Host
An entity, usually a computer system, that may have one or more HIPPI 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. ports and which may serve as a client or a HARP server.
Port Port
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
An entity consisting of one HIPPI Source/Destination dual simplex An entity consisting of one HIPPI Source/Destination dual simplex
pair that is connected by parallel or serial HIPPI to a HIPPI-SC 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 switch and that transmits and receives IP datagrams. A port may be
an Internet host, bridge, router, or gateway. an Internet host, bridge, router, or gateway.
PIBES PIBES
The Protocol for Internet Broadcast Emulation Server (see section 7). The Protocol for Internet Broadcast Emulation Server (see section 7).
Source Source
skipping to change at page 5, line 44 skipping to change at page 6, line 4
other LIS's on the same HIPPI-6400 network. other LIS's on the same HIPPI-6400 network.
HARP has LIS scope only and serves all ports in the LIS. HARP has LIS scope only and serves all ports in the LIS.
Communication to ports located outside of the local LIS is usually Communication to ports located outside of the local LIS is usually
provided via an IP router. This router is a HIPPI-6400 port attached 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 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 more LIS's. This configuration MAY result in a number of disjoint
LIS's operating over the same HIPPI-6400 network. Using this model, LIS's operating over the same HIPPI-6400 network. Using this model,
ports of different IP subnets SHOULD communicate via an intermediate ports of different IP subnets SHOULD communicate via an intermediate
IP router even though it may be possible to open a direct HIPPI-6400 IP router even though it may be possible to open a direct HIPPI-6400
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
connection between the two IP members over the HIPPI-6400 network. connection between the two IP members over the HIPPI-6400 network.
This is an consequence of using IP and choosing to have multiple This is an consequence of using IP and choosing to have multiple
LIS's on the same HIPPI-6400 fabric. LIS's on the same HIPPI-6400 fabric.
By default, the HARP method detailed in section 5 and the classical 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 routing model MUST be available to any IP member client in the
LIS. LIS.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
3.2 HIPPI LIS Requirements 3.2 HIPPI LIS Requirements
The requirement for IP members (hosts, routers) operating in a The requirement for IP members (hosts, routers) operating in a
HIPPI-6400 LIS configuration is: HIPPI-6400 LIS configuration is:
o All members of the LIS SHALL have the same IP network/subnet o All members of the LIS SHALL have the same IP network/subnet
address and address mask [4]. address and address mask [4].
The following list identifies the set of HIPPI-6400-specific The following list identifies the set of HIPPI-6400-specific
parameters that MUST be implemented in each IP station connected to parameters that MUST be implemented in each IP station connected to
skipping to change at page 6, line 32 skipping to change at page 6, line 40
endpoint (i.e. a network adapter within a host) MUST be unique in endpoint (i.e. a network adapter within a host) MUST be unique in
the LIS. the LIS.
o HARP Request Address List (HRAL): o HARP Request Address List (HRAL):
The HRAL is an ordered list of two or more addresses identifying The HRAL is an ordered list of two or more addresses identifying
the address resolution service(s). All HARP clients MUST be the address resolution service(s). All HARP clients MUST be
configured identically, i.e. all ports MUST have the same configured identically, i.e. all ports MUST have the same
addresses(es) in the HRAL. addresses(es) in the HRAL.
The HRAL MUST contain at least two HIPPI-6400 addresses The HRAL MUST contain at least two HIPPI HW addresses identifying
identifying the individual HARP service(s) that have authoritative the individual HARP service(s) that have authoritative
responsibility for resolving HARP requests of all IP members responsibility for resolving HARP requests of all IP members
located within the LIS. By default the first address SHOULD be located within the LIS. By default the first address MUST be the
the reserved address for broadcast, i.e. FF:FF:FF:FF:FF:FF. 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: Therefore, the HRAL entries are sorted in the following order:
1st : broadcast address (FF:FF:FF:FF:FF:FF), 1st : broadcast address (FF:FF:FF:FF:FF:FF) REQUIRED
2nd : official HARP server address (00:10:3B:FF:FF:E0), 2nd : official HARP server address (00:10:3B:FF:FF:E0) REQUIRED
3rd & on: any additional HARP server addresses will be sorted in 3rd & on: any additional HARP server addresses will be OPTIONAL
decreasing order. sorted in decreasing order.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
Manual configuration of the addresses and address lists presented in Manual configuration of the addresses and address lists presented in
this section is implementation dependent and beyond the scope of this this section is implementation dependent and beyond the scope of this
memo. However, prior to use by any service or operation detailed in memo. However, prior to use by any service or operation detailed in
this memo, clients MUST have HRAL address(es) configured as this memo, clients MUST have HRAL address(es) configured as
appropriate for their LIS. appropriate for their LIS.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
4. Internet Protocol 4. Internet Protocol
4.1 Packet format 4.1 Packet format
The HIPPI-6400 packet format for Internet datagrams [15] shall The HIPPI-6400 packet format for Internet datagrams [15] shall
conform to the HIPPI-6400-PH standard [1] (see section 6). The conform to the HIPPI-6400-PH standard [1]. The length of a HIPPI-
length of a HIPPI-6400-PH packet, including headers and trailing 6400-PH packet, including headers and trailing fill, shall be a
fill, shall be a multiple of 32 bytes as required by HIPPI-6400-PH. multiple of 32 bytes as required by HIPPI-6400-PH.
ALL IP Datagrams shall be carried on HIPPI-6400-PH Virtual Channel 1 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 (VC1). Since HIPPI-6400-PH has a 32-byte granularity, IP Datagrams
must also provide the data payload with a 32-byte granularity. If a MUST be padded to a 32-byte granularity prior to sending. Added
user's data is not an integral multiple of 32-byte units, then the padding is transparent to IP and is not reflected in the length field
necessary zero fill padding SHALL be added. of the IP header.
D_ULA Destination ULA SHALL be the ULA of the destination port. D_ULA Destination ULA SHALL be the ULA of the destination port.
S_ULA Source ULA SHALL be the ULA of the requesting 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) 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. length + 8 Bytes to account for the LLC/SNAP header length.
The HIPPI-6400-PH [1] length parameter shall not include The HIPPI-6400-PH [1] length parameter shall not include
the pad. the pad.
skipping to change at page 7, line 47 skipping to change at page 8, line 4
SSAP 0xAA 170 (8 bits) SSAP 0xAA 170 (8 bits)
DSAP 0xAA 170 (8 bits) DSAP 0xAA 170 (8 bits)
CTL 0x03 3 (8 bits) CTL 0x03 3 (8 bits)
for a total length of 3 bytes. The 0x03 CTL value indicates the for a total length of 3 bytes. The 0x03 CTL value indicates the
presence of a SNAP header. presence of a SNAP header.
4.1.2 SNAP 4.1.2 SNAP
The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes) The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes)
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
indicating that the following two-bytes is an Ethertype. indicating that the following two-bytes is an Ethertype.
The Ethertype value SHALL be set as defined in Assigned Numbers [18]: The Ethertype value SHALL be set as defined in Assigned Numbers [18]:
IP 0x0800 2048 (16 bits) IP 0x0800 2048 (16 bits)
HARP = ARP = 0x0806 2054 (16 bits) HARP = ARP = 0x0806 2054 (16 bits)
The total size of the LLC/SNAP header is fixed at 8 bytes. The total size of the LLC/SNAP header is fixed at 8 bytes.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
4.1.3 HIPPI-6400 802 Packet diagrams 4.1.3 HIPPI-6400 802 Packet diagrams
The following diagram shows a HIPPI-6400 message carrying IEEE 802 The following diagram shows a HIPPI-6400 message carrying IEEE 802
data. data.
|31 |23 |15 |7 0| |31 |23 |15 |7 0|
+------------+------------+------------+------------+ -------------- +------------+------------+------------+------------+ --------------
0 | | 0 | |
| D_ULA +-------------------------+ HIPPI-6400 | D_ULA +-------------------------+ HIPPI-6400
1 | | | 1 | | |
skipping to change at page 8, line 38 skipping to change at page 9, line 5
Generic 802.1 data packet diagram Generic 802.1 data packet diagram
The following diagram shows an IP datagram of length n with the FILL The following diagram shows an IP datagram of length n with the FILL
bytes ( value: 0x0 ). "<><>" indicates the micropacket separation. A bytes ( value: 0x0 ). "<><>" indicates the micropacket separation. A
HIPPI-6400-PH [1] micropacket is 32 bytes long. HIPPI-6400-PH [1] micropacket is 32 bytes long.
All IP (v4) [15] packets will always span two or more micropackets. All IP (v4) [15] packets will always span two or more micropackets.
The first micropacket has a TYPE = header. The second and any further The first micropacket has a TYPE = header. The second and any further
micropackets have a TYPE = Data (see [1]). micropackets have a TYPE = Data (see [1]).
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
|31 |23 |15 |7 0| |31 |23 |15 |7 0|
+------------+------------+------------+------------+ -------------- +------------+------------+------------+------------+ --------------
0 | | 0 | |
| D_ULA +-------------------------+ HIPPI-6400 | D_ULA +-------------------------+ HIPPI-6400
1 | | | 1 | | |
+-------------------------+ S_ULA | MAC +-------------------------+ S_ULA | MAC
2 | | 2 | |
+---------------------------------------------------+ header +---------------------------------------------------+ header
3 | M_len | 3 | M_len |
+------------+------------+------------+------------+ -------------- +------------+------------+------------+------------+ --------------
4 | AA | AA | 03 | 00 | IEEE 802 4 | AA | AA | 03 | 00 | IEEE 802
+------------+------------+------------+------------+ LLC/SNAP +------------+------------+------------+------------+ LLC/SNAP
5 | 00 | 00 | Ethertype = 0x0800=2048 | header 5 | 00 | 00 | Ethertype = 0x0800=2048 | header
+============+============+============+============+ ============== +============+============+============+============+ ==============
6 | VER | HLEN | TOS | Total Length | 6 | VER | HLEN | TOS | Total Length |
+-----+------+------------+-----+-------------------+ +-----+------+------------+-----+-------------------+
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
7 | ID | FLG | Frag Offset | 7 | ID | FLG | Frag Offset |
+<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ IPv4 Header +<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ IPv4 Header
8 | TTL | PROTO | Header Checksum | 8 | TTL | PROTO | Header Checksum |
+------------+------------+-------------------------+ +------------+------------+-------------------------+
9 | Source IP Address | 9 | Source IP Address |
+---------------------------------------------------+ +---------------------------------------------------+
10 | Destination IP Address | 10 | Destination IP Address |
+---------------------------------------------------+ +---------------------------------------------------+
11 | . . . | 11 | . . . |
+---------------------------------------------------+ +---------------------------------------------------+
skipping to change at page 9, line 39 skipping to change at page 10, line 4
4.2 HIPPI-6400 Hardware address: Universal LAN MAC address (ULA) 4.2 HIPPI-6400 Hardware address: Universal LAN MAC address (ULA)
HIPPI-6400 uses Universal LAN MAC Addresses specified in IEEE HIPPI-6400 uses Universal LAN MAC Addresses specified in IEEE
Standard 802.1A [10] or a subset as defined in HIPPI-6400-SC [2]. 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 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. 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 Multiple ULAs may be used if a node contains more than one IEEE 802.2
LLC protocol entity. LLC protocol entity.
This memo assumes the use of "Logical Addressing" as described in This memo assumes the use of "Logical Addressing" as described in
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
Annex A.2 of HIPPI-6400-SC[2]. Annex A.2 of HIPPI-6400-SC[2].
The format of the address within its 48 bit HIPPI-6400-PH fields 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 follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit and
byte order: byte order:
31 23 15 7 0 31 23 15 7 0
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
|ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 | |ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| ULA byte 4 | ULA byte 5 | (not used for ULA) | | ULA byte 4 | ULA byte 5 | (not used for ULA) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Universal LAN MAC Address Format Universal LAN MAC Address Format
L (U/L bit) = 1 for Locally administered addresses, 0 for Universal. L (U/L bit) = 1 for Locally administered addresses, 0 for Universal.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
G (I/G bit) = 1 for Group addresses, 0 for Individual. G (I/G bit) = 1 for Group addresses, 0 for Individual.
4.3 Maximum Transmission Unit - MTU 4.3 Maximum Transmission Unit - MTU
Maximum Transmission Unit (MTU) is defined as the maximum length of Maximum Transmission Unit (MTU) is defined as the maximum length of
the IP packet, including IP header, but not including any overhead 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. below IP, i.e., HIPPI-6400 MAC header and IEEE 802 LLC/SNAP header.
Conventional LANs have MTU sizes determined by physical layer Conventional LANs have MTU sizes determined by physical layer
specification. MTUs may be required simply because the chosen medium specification. MTUs may be required simply because the chosen medium
won't work with larger packets, or they may serve to limit the amount won't work with larger packets, or they may serve to limit the amount
skipping to change at page 10, line 40 skipping to change at page 11, line 5
For HIPPI-6400 the byte accounting is: For HIPPI-6400 the byte accounting is:
HIPPI-6400-PH Header 16 bytes HIPPI-6400-PH Header 16 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes IEEE 802.2 LLC/SNAP Headers 8 bytes
Maximum IP packet size (MTU) 65280 bytes Maximum IP packet size (MTU) 65280 bytes
Unused expansion room 232 bytes Unused expansion room 232 bytes
------------ ------------
Total 65536 bytes (64K) Total 65536 bytes (64K)
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
In contrast, the HIPPI-800 accounting is: In contrast, the HIPPI-800 accounting is:
HIPPI-800-FP Header 8 bytes HIPPI-800-FP Header 8 bytes
HIPPI-800-LE Header 24 bytes HIPPI-800-LE Header 24 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes IEEE 802.2 LLC/SNAP Headers 8 bytes
Unused expansion room 216 bytes Unused expansion room 216 bytes
Maximum IP packet size (MTU) 65280 bytes Maximum IP packet size (MTU) 65280 bytes
------------ ------------
Total 65536 bytes (64K) Total 65536 bytes (64K)
5. HIPPI Address Resolution Protocol - HARP 5. HIPPI Address Resolution Protocol - HARP
Address resolution within the HIPPI-6400 LIS SHALL make use of the Address resolution within the HIPPI-6400 LIS SHALL make use of the
HIPPI Address Resolution Protocol (HARP) and the Inverse HIPPI HIPPI Address Resolution Protocol (HARP) and the Inverse HIPPI
Address Resolution Protocol (InHARP). HARP provides the same Address Resolution Protocol (InHARP). HARP provides the same
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
functionality as the Internet Address Resolution Protocol (ARP). functionality as the Internet Address Resolution Protocol (ARP).
HARP is based on ARP which is defined in RFC-826 [14] except the HARP is based on ARP which is defined in RFC-826 [14] except the
HIPPI-6400 specific packet format. Knowing the Internet address, HIPPI-6400 specific packet format. Knowing the Internet address,
conventional networks use ARP to discover another node's hardware conventional networks use ARP to discover another node's hardware
address. HARP presented in this section further specifies the address. HARP presented in this section further specifies the
combination of the original protocol definitions to form a coherent combination of the original protocol definitions to form a coherent
address resolution service that is independent of the hardware's address resolution service that is independent of the hardware's
broadcast capability. InHARP is the same protocol as the original broadcast capability. InHARP is the same protocol as the original
Inverse ARP (InARP) protocol presented in [5] except the HIPPI-6400 Inverse ARP (InARP) protocol presented in [5] except the HIPPI-6400
skipping to change at page 11, line 40 skipping to change at page 12, line 4
in the reply will be the target's source address. If all switches in 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 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 provide the address resolution service, and the source address in the
reply will be the HARP server's source address. reply will be the HARP server's source address.
5.1 HARP Algorithm 5.1 HARP Algorithm
This section defines the behavior and requirements for HARP This section defines the behavior and requirements for HARP
implementations on both broadcast and non-broadcast capable HIPPI- implementations on both broadcast and non-broadcast capable HIPPI-
6400-SC networks. HARP creates a table in each port which maps remote 6400-SC networks. HARP creates a table in each port which maps remote
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
ports' IP addresses to ULAs, so that when an application requests a 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 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 determined, a correct HIPPI-6400-PH header can be built, and a
connection to the port can be established using the ULA. connection to the port can be established using the ULA.
HARP is a two phase protocol. The first phase is the registration HARP is a two phase protocol. The first phase is the registration
phase and the second phase is the operational phase. In the phase and the second phase is the operational phase. In the
registration phase the port detects if it is connected to broadcast registration phase the port detects if it is connected to broadcast
hardware or not. The InHARP protocol is used in the registration hardware or not. The InHARP protocol is used in the registration
phase. In case of non-broadcast capable hardware, the InHARP phase. In case of non-broadcast capable hardware, the InHARP
Protocol will register and establish a table entry with the server. Protocol will register and establish a table entry with the server.
The operational phase works much like conventional ARP with the The operational phase works much like conventional ARP with the
exception of the message format. exception of the message format.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
5.1.1 Selecting the authoritative HARP service 5.1.1 Selecting the authoritative HARP service
Within the HIPPI LIS, there SHALL be an authoritative HARP service. Within the HIPPI LIS, there SHALL be an authoritative HARP service.
To select the authoritative HARP service, each port needs to To select the authoritative HARP service, each port needs to
determine if it is connected to a broadcast network. At each point in determine if it is connected to a broadcast network. At each point in
time there is only one authoritative HARP service. time there is only one authoritative HARP service.
The port SHALL send an InHARP_REQUEST to the first address in the 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, 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, then it is connected to a broadcast capable network. In this case,
skipping to change at page 12, line 32 skipping to change at page 12, line 46
the HRAL. Every address which sends an InHARP_REPLY is considered to the HRAL. Every address which sends an InHARP_REPLY is considered to
be a responsive HARP server. The authoritative HARP service SHALL be be a responsive HARP server. The authoritative HARP service SHALL be
the HARP server which appears first in the HRAL. the HARP server which appears first in the HRAL.
The order of addresses in the HRAL is only important for deciding The order of addresses in the HRAL is only important for deciding
which address will be the authoritative one. On a non-broadcast which address will be the authoritative one. On a non-broadcast
network, the port is REQUIRED to keep "registered" with all HARP network, the port is REQUIRED to keep "registered" with all HARP
server addresses in the HRAL (NOTE: not the broadcast address since server addresses in the HRAL (NOTE: not the broadcast address since
it is not a HARP server address). If for instance the authoritative it is not a HARP server address). If for instance the authoritative
HARP service is non-responsive, then the port will consider the next HARP service is non-responsive, then the port will consider the next
address in the HRAL as a candidate for the selected address and send address in the HRAL as a candidate for the authoritative address and
an InHARP_REQUEST. send an InHARP_REQUEST.
The authoritative HARP server SHOULD be considered non-responsive The authoritative HARP server SHOULD be considered non-responsive
when it has failed to reply to: (1) one or more registration requests 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 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 in the last 120 seconds or (3) if an external agent has detected
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
failure of the authoritative HARP server. The details of such an failure of the authoritative HARP server. The details of such an
external agent and its interaction with the HARP client are beyond external agent and its interaction with the HARP client are beyond
the scope of this document. Should an authoritative HARP server the scope of this document. Should an authoritative HARP server
become non-responsive, then the registration process SHOULD be become non-responsive, then the registration process SHOULD be
restarted. Alternative methods for choosing an authoritative HARP restarted. Alternative methods for choosing an authoritative HARP
service are not prohibited. service are not prohibited.
5.1.2 HARP registration phase 5.1.2 HARP registration phase
HARP clients SHALL initiate the registration phase by sending an HARP clients SHALL initiate the registration phase by sending an
InHARP_REQUEST message using the HRAL addresses in order. The client InHARP_REQUEST message using the HRAL addresses in order. The client
SHALL terminate the registration phase and transition into the SHALL terminate the registration phase and transition into the
operational phase, when either: (1) it receives its own operational phase, when either: (1) it receives its own
InHARP_REQUEST, or (2) when it receives an InHARP_REPLY from at least 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 one of the HARP servers and it has determined the authoritative HARP
service as described in 5.1.1. service as described in 5.1.1.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00 When ports are initiated they send an InHARP_REQUEST to the
authoritative HRAL address. The first address to be tried will be the
When ports are initiated they send an InHARP_REQUEST to the selected broadcast address "FF:FF:FF:FF:FF:FF". There are two outcomes:
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 1. The port sees its own InHARP_REQUEST: then the port is connected
to a broadcast capable network. The first address becomes, and to a broadcast capable network. The first address becomes, and
remains, the selected address for the HARP service. remains, the authoritative address for the HARP service.
2. The port does not receive its InHARP_REQUEST: then the port is 2. The port does not receive its InHARP_REQUEST: then the port is
connected to a non-broadcast capable network. connected to a non-broadcast capable network.
The port SHALL choose the next address in the HRAL as a candidate 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: for a HARP server and send an InHARP_REQUEST to that address:
(00:10:3B:FF:FF:E0). (00:10:3B:FF:FF:E0).
The port SHALL continue to retry each non-broadcast HARP server 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 address in the HRAL at least once every 5 seconds until one of the
skipping to change at page 13, line 39 skipping to change at page 14, line 5
b. If the port receives an InHARP_REPLY, then it is a HARP client 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 and not a HARP server. In both cases, the current candidate
address becomes the authoritative HARP service address. address becomes the authoritative HARP service address.
InHARP is an application of the InARP protocol for a purpose not InHARP is an application of the InARP protocol for a purpose not
originally intended. The purpose is to accomplish registration of originally intended. The purpose is to accomplish registration of
port IP address mappings with a HARP server if one exists or detect port IP address mappings with a HARP server if one exists or detect
hardware broadcast capability. hardware broadcast capability.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
If the HIPPI-6400-SC LAN supports broadcast, then the client will see If the HIPPI-6400-SC LAN supports broadcast, then the client will see
its own InHARP_REQUEST message and SHALL complete the registration its own InHARP_REQUEST message and SHALL complete the registration
phase. The client SHOULD further note that it is connected to a phase. The client SHOULD further note that it is connected to a
broadcast capable network and use this information for aging the HARP broadcast capable network and use this information for aging the HARP
server entry and for IP broadcast emulation as specified in sections server entry and for IP broadcast emulation as specified in sections
5.4 and 5.6 respectively. 5.4 and 5.6 respectively.
If the client doesn't see its own InHARP_REQUEST it SHALL await an If the client doesn't see its own InHARP_REQUEST it SHALL await an
InHARP_REPLY before completing the registration phase. This will also InHARP_REPLY before completing the registration phase. This will also
provide the client with the protocol address by which the HARP server 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 is addressable. This will be the case when the client happens to be
connected to a non-broadcast capable HIPPI-6400-SC network. connected to a non-broadcast capable HIPPI-6400-SC network.
5.1.3 HARP operational phase 5.1.3 HARP operational phase
Once a HARP client has completed its registration phase it enters the Once a HARP client has completed its registration phase it enters the
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
operational phase. In this phase of the protocol, the HARP client operational phase. In this phase of the protocol, the HARP client
SHALL gain and refresh its own HARP table information about other IP SHALL gain and refresh its own HARP table information about other IP
members by sending of HARP_REQUESTs to the selected address in the members by sending of HARP_REQUESTs to the authoritative address in
HRAL and by receiving of HARP_REPLYs. The client is fully operational the HRAL and by receiving of HARP_REPLYs. The client is fully
during the operational phase. operational during the operational phase.
In the operational phase, the client's behavior for requesting HARP In the operational phase, the client's behavior for requesting HARP
resolution is the same for broadcast or non-broadcast HIPPI-6400-SC resolution is the same for broadcast or non-broadcast HIPPI-6400-SC
switched networks. switched networks.
The target of an address resolution request updates its address The target of an address resolution request updates its address
mapping tables with any new information it can find in the request. 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. 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 A port is the target of an address resolution request if at least ONE
of the following statements is true of the request: of the following statements is true of the request:
skipping to change at page 14, line 39 skipping to change at page 15, line 4
3. The port is a HARP server. 3. The port is a HARP server.
NOTE: It is REQUIRED to have a HARP server run on a port that has a NOTE: It is REQUIRED to have a HARP server run on a port that has a
non-zero ULA. non-zero ULA.
5.2 HARP Client Operational Requirements 5.2 HARP Client Operational Requirements
The HARP client is responsible for contacting the HARP server(s) to The HARP client is responsible for contacting the HARP server(s) to
have its own HARP information registered and to gain and refresh its have its own HARP information registered and to gain and refresh its
own HARP entry/information about other IP members. This means, as own HARP entry/information about other IP members. This means, as
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
noted above, that HARP clients MUST be configured with the hardware noted above, that HARP clients MUST be configured with the hardware
address of the HARP server(s) in the HRAL. address of the HARP server(s) in the HRAL.
HARP clients MUST: HARP clients MUST:
1. When an interface is enabled (e.g. "ifconfig <interface> up") or 1. When an interface is enabled (e.g. "ifconfig <interface> up" with
assigned an IP alias, the client SHALL initiate the registration an IP address) or assigned the first or an additional IP address
(i.e. an IP alias), the client SHALL initiate the registration
phase. phase.
2. In the operational phase the client MUST respond to HARP_REQUEST 2. In the operational phase the client MUST respond to HARP_REQUEST
and InHARP_REQUEST messages, if it is the target port. If an and InHARP_REQUEST messages if it is the target port. If an
interface has multiple IP addresses (e.g., IP aliases) then the interface has multiple IP addresses (e.g., IP aliases) then the
client MUST cycle through all the IP addresses and generate an client MUST cycle through all the IP addresses and generate an
InHARP_REPLY for each such address. In that case an InHARP_REPLY for each such address. In that case an
InHARP_REQUEST can have multiple replies. (Refer to Section 7, InHARP_REQUEST will have multiple replies. (Refer to Section 7,
"Protocol Operation" in RFC-1293 [5].) "Protocol Operation" in RFC-1293 [5].)
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00 3. React to address resolution reply messages appropriately to build
or refresh its own client HARP table entries. All solicited and
3. React to address resolution reply messages appropriately to unsolicited HARP_REPLYs from the authoritative HARP server SHALL
build/refresh its own client HARP table entries. All (solicited
and unsolicited) HARP_REPLYs from the selected HARP server SHALL
be used to update and refresh its own client HARP table entries. be used to update and refresh its own client HARP table entries.
Explanation: This allows the HARP server to update the clients Explanation: This allows the HARP server to update the clients
when one of server's mappings change, similar to what is when one of server's mappings change, similar to what is
accomplished on Ethernet with gratuitous ARP. accomplished on Ethernet with gratuitous ARP.
4. Generate and transmit InHARP_REQUEST messages as needed and 4. Generate and transmit InHARP_REQUEST messages as needed and
process InHARP_REPLY messages appropriately (see section 5.1.3 process InHARP_REPLY messages appropriately (see section 5.1.3
and 5.6). All InHARP_REPLY messages SHALL be used to and 5.6). All InHARP_REPLY messages SHALL be used to
build/refresh its client HARP table entries. (Refer to Section build/refresh its client HARP table entries. (Refer to Section
skipping to change at page 15, line 37 skipping to change at page 16, line 5
decrease the redundant network traffic, this timeout SHOULD be reset decrease the redundant network traffic, this timeout SHOULD be reset
after each HARP_REQUEST/HARP_REPLY exchange. after each HARP_REQUEST/HARP_REPLY exchange.
Explanation: The HARP_REQUEST shows the HARP server that the client Explanation: The HARP_REQUEST shows the HARP server that the client
is still alive. Receiving a HARP_REPLY indicates to the client that is still alive. Receiving a HARP_REPLY indicates to the client that
the server must have seen the HARP_REQUEST. the server must have seen the HARP_REQUEST.
If the registration phase showed that the underlying network supports If the registration phase showed that the underlying network supports
broadcast, then the refresh sequence is NOT REQUIRED. broadcast, then the refresh sequence is NOT REQUIRED.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
5.3 Receiving Unknown HARP Messages 5.3 Receiving Unknown HARP Messages
If a HARP client receives a HARP message with an operation code If a HARP client receives a HARP message with an operation code
(ar$op) that it does not support, it MUST gracefully discard the (ar$op) that it does not support, it MUST gracefully discard the
message and continue normal operation. A HARP client is NOT REQUIRED message and continue normal operation. A HARP client is NOT REQUIRED
to return any message to the sender of the undefined message. to return any message to the sender of the undefined message.
5.4 HARP Server Operational Requirements 5.4 HARP Server Operational Requirements
A HARP server MUST accept HIPPI-6400 connections from other HIPPI- A HARP server MUST accept HIPPI-6400 connections from other HIPPI-
6400 ports. The HARP server expects an InHARP_REQUEST as the first 6400 ports. The HARP server expects an InHARP_REQUEST as the first
message from the client. A server examines the IP address, the message from the client. A server examines the IP address, the
hardware address of the InHARP_REQUEST and adds or updates its HARP hardware address of the InHARP_REQUEST and adds or updates its HARP
table entry <IP address(es), ULA> as well as the time stamp. table entry <IP address(es), ULA> as well as the time stamp.
A HARP server replies to HARP_REQUESTs and InHARP_REQUESTs based on A HARP server replies to HARP_REQUESTs and InHARP_REQUESTs based on
the information which it has in its table. The HARP server replies the information which it has in its table. The HARP server replies
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
SHALL contain the hardware type and corresponding format of the SHALL contain the hardware type and corresponding format of the
request (see also sec. 6). request (see also sec. 6).
The following table shows all possible source address combinations on The following table shows all possible source address combinations on
an incoming message and the actions to be taken. "linked" indicates an incoming message and the actions to be taken. "linked" indicates
that an existing "IP entry" is linked to a "hardware entry". It is 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 possible to have an existing "IP entry" and to have an existing
"hardware entry" but neither is linked to the other. "hardware entry" but neither is linked to the other.
+---+----------+----------+------------+---------------------+ +---+----------+----------+------------+---------------------+
skipping to change at page 16, line 35 skipping to change at page 17, line 5
Actions: Actions:
*: update timeout value *: update timeout value
a: break the existing IP -> hardware (HW) -old link a: break the existing IP -> hardware (HW) -old link
b: delete HW(old) -> IP link and decrement HW(old) refcount, b: delete HW(old) -> IP link and decrement HW(old) refcount,
if refcount = 0, delete HW(old) if refcount = 0, delete HW(old)
c: create new IP entry c: create new IP entry
d: create new HW entry d: create new HW entry
e: add new IP -> HW link to IP entry e: add new IP -> HW link to IP entry
f: add new HW -> IP link to HW entry f: add new HW -> IP link to HW entry
Examples of when this could happen: INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
Examples of when this could happen (Numbers match lines in above
table):
1: supplemental message 1: supplemental message
Just update timer. Just update timer.
2: move an IP alias to an existing interface 2: move an IP alias to an existing interface
If the InHARP_REQUEST requester's IP address duplicates a table If the IP source address of the InHARP_REQUEST duplicates a table
entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST
hardware address matches a hardware address entry (e. g. HWb <-> hardware source address matches a hardware address entry (e. g.
IPb), but they are not linked together, then: HWb <-> IPb), but they are not linked together, then:
- HWa entry needs to have its reference to the current IPa address - HWa entry needs to have its reference to the current IPa address
removed. removed.
- HWb needs to have a new reference to IPa added - HWb needs to have a new reference to IPa added
- IPa needs to be linked to HWb - IPa needs to be linked to HWb
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00 The result will be a table with: IPb <-> HWa <-> IPb If IPb was
the only IP address refered to by the HWb entry, then delete the
HWb entry.
3: move IP address to a new interface 3: move IP address to a new interface
If the InHARP_REQUEST requester's IP address duplicates a table If the InHARP_REQUEST requester's IP source address duplicates a
entry IP address and the InHARP_REQUEST hardware address does not table entry IP address and the InHARP_REQUEST hardware source
match the table entry hardware address, then a new HW entry SHALL address does not match the table entry hardware address, then a
be created and the IP entry SHALL be updated. 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 4: add IP alias to table
If the InHARP_REQUEST requester's hardware address duplicates a If the InHARP_REQUEST requester's hardware source address
hardware address entry, but there is no IP entry matching the duplicates a hardware source address entry, but there is no IP
received IP address, then IP address SHALL be added to the entry matching the received IP address, then the IP address SHALL
hardware entries previous IP address(es). (E.g. adding an IP be added to the hardware entries previous IP address(es). (E.g.
alias). adding an IP alias).
5: fresh entry, add it 5: fresh entry, add it
Standard case, create both entries and link them. Standard case, create both entries and link them.
A server MUST update the HARP table entry's timeout for each A server MUST update the HARP table entry's timeout for each
HARP_REQUEST. Explanation: if the client is sending HARP requests to HARP_REQUEST. Explanation: if the client is sending HARP requests to
the server, then the server should note that the client is still the server, then the server should note that the client is still
"alive" by updating the timeout on the client's HARP table entry. "alive" by updating the timeout on the client's HARP table entry.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
A HARP server SHOULD use the PIBES (see sect. 7) to send out 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 HARP_REPLYs to all hardware addresses in its table when the HARP
server table changes mappings. This feature decreases the time of server table changes mappings. This feature decreases the time of
stale entries in the clients. stale entries in the clients.
If there are multiple addresses in the HRAL, then a server needs to If there are multiple addresses in the HRAL, then a server needs to
act as a client to the other servers. act as a client to the other servers.
5.5 HARP and Permanent ARP Table Entries 5.5 HARP and Permanent ARP Table Entries
skipping to change at page 18, line 5 skipping to change at page 18, line 28
determining what permanent entries it has. The details of the determining what permanent entries it has. The details of the
mechanism are beyond the scope of this memo. The permanent entries mechanism are beyond the scope of this memo. The permanent entries
allow interoperability with legacy HIPPI adapters which do not yet allow interoperability with legacy HIPPI adapters which do not yet
implement dynamic HARP and use a table based static ARP. Permanent implement dynamic HARP and use a table based static ARP. Permanent
entries are not aged. entries are not aged.
The HARP server SHOULD use the static entries to resolve incoming The HARP server SHOULD use the static entries to resolve incoming
HARP_REQUESTs from the clients. This feature eliminates the need for HARP_REQUESTs from the clients. This feature eliminates the need for
maintaining a static HARP table on the client ports. maintaining a static HARP table on the client ports.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
5.6 HARP Table Aging 5.6 HARP Table Aging
HARP table aging MUST be supported since IP addresses, especially IP HARP table aging MUST be supported since IP addresses, especially IP
aliases and also interfaces (with their ULA), are likely to move. aliases and also interfaces (with their ULA), are likely to move.
When so doing the mapping in the clients own HARP table/cache becomes When so doing the mapping in the clients own HARP table/cache becomes
invalid and stale. invalid and stale.
o When a client's HARP table entry ages beyond 15 minutes, a HARP o When a client's HARP table entry ages beyond 15 minutes, a HARP
client MUST invalidate the table entry. client MUST invalidate the table entry.
skipping to change at page 18, line 31 skipping to change at page 19, line 4
thus restarting the aging time when the table entry is successfully thus restarting the aging time when the table entry is successfully
revalidated. The client MAY continue sending traffic to the port revalidated. The client MAY continue sending traffic to the port
referred to by this entry while revalidation is in progress, as long referred to by this entry while revalidation is in progress, as long
as the table entry has not agedb. The client MUST revalidate the as the table entry has not agedb. The client MUST revalidate the
invalidated entry prior to transmitting any non-address resolution invalidated entry prior to transmitting any non-address resolution
traffic to the port referred to by this entry. traffic to the port referred to by this entry.
The client revalidates the entry by querying the HARP server. If a 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 valid reply is received (e.g. HARP_REPLY), the entry is updated. If
the address resolution service cannot resolve the entry (e.g. the address resolution service cannot resolve the entry (e.g.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
HARP_NAK, "host not found"), the associated table entry is removed. HARP_NAK, "host not found"), the associated table entry is removed.
If the address resolution service is not available (i.e. "server If the address resolution service is not available (i.e. "server
failure") the client MUST attempt to revalidate the entry by failure") the client MUST attempt to revalidate the entry by
transmitting an InHARP_REQUEST to the hardware address of the entry transmitting an InHARP_REQUEST to the hardware address of the entry
in question and updating the entry on receipt of an InHARP_REPLY. If in question and updating the entry on receipt of an InHARP_REPLY. If
the InHARP_REQUEST attempt fails to return an InHARP_REPLY, the the InHARP_REQUEST attempt fails to return an InHARP_REPLY, the
associated table entry is removed. associated table entry is removed.
6. HARP Message Encoding 6. HARP Message Encoding
The HARP message is another type of IEEE 802 payload as described in 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 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 formats, both the generic Ethernet ARP packet and the HIPPI-800 HARP
packet format defined in [13]. HARP messages SHALL be transmitted packet format defined in [13]. HARP messages SHALL be transmitted
with a hardware type code of 28 on non-broadcast capable hardware or with a hardware type code of 28 on non-broadcast capable hardware or
1 in either case. 1 in either case.
The ar$hrd field SHALL be used to differentiate between the two The ar$hrd field SHALL be used to differentiate between the two
packet formats. The reply SHALL be in the format of the request. packet formats. The reply SHALL be in the format of the request.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
6.1 Generic IEEE 802 ARP Message Format 6.1 Generic IEEE 802 ARP Message Format
This is the ARP packet format used by conventional IEEE 802 networks 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] (i.e. Ethernet etc). The packet format is described in RFC 826 [14]
and is given here only for completeness purpose. and is given here only for completeness purpose.
ar$hrd 16 bits Hardware type ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type of the protocol fields below ar$pro 16 bits Protocol type of the protocol fields below
ar$hln 8 bits byte length of each hardware address ar$hln 8 bits byte length of each hardware address
ar$pln 8 bits byte length of each protocol address ar$pln 8 bits byte length of each protocol address
skipping to change at page 19, line 35 skipping to change at page 20, line 4
ar$pro - SHALL contain the IP protocol code 2048 (decimal). ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar$hln - SHALL contain 6. ar$hln - SHALL contain 6.
ar$pln - SHALL contain 4. ar$pln - SHALL contain 4.
ar$op - SHALL contain the operational value (decimal): ar$op - SHALL contain the operational value (decimal):
1 for HARP_REQUESTs 1 for HARP_REQUESTs
2 for HARP_REPLYs 2 for HARP_REPLYs
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
8 for InHARP_REQUESTs 8 for InHARP_REQUESTs
9 for InHARP_REPLYs 9 for InHARP_REPLYs
10 for HARP_NAK 10 for HARP_NAK
ar$rpa - in requests and NAKs it SHALL contain the requester's IP ar$rpa - in requests and NAKs it SHALL contain the requester's IP
address if known, otherwise zero. address if known, otherwise zero.
In other replies it SHALL contain the target In other replies it SHALL contain the target
port's IP address. port's IP address.
ar$sha - in requests and NAKs it SHALL contain the requester's ULA ar$sha - in requests and NAKs it SHALL contain the requester's ULA
skipping to change at page 20, line 5 skipping to change at page 20, line 28
ar$spa - in requests and NAKs it SHALL contain the requester's IP ar$spa - in requests and NAKs it SHALL contain the requester's IP
address if known, otherwise zero. address if known, otherwise zero.
In other replies it SHALL contain the target In other replies it SHALL contain the target
port's IP address. port's IP address.
ar$tha - in requests and NAKs it SHALL contain the target's ULA ar$tha - in requests and NAKs it SHALL contain the target's ULA
if known, otherwise zero. if known, otherwise zero.
In other replies it SHALL contain the requester's ULA. In other replies it SHALL contain the requester's ULA.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
ar$tpa - in requests and NAKs it SHALL contain the ar$tpa - in requests and NAKs it SHALL contain the
target's IP address if known, otherwise zero. target's IP address if known, otherwise zero.
In other replies it SHALL contain the requester's In other replies it SHALL contain the requester's
IP address. IP address.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
Payload Format for IEEE HARP/InHARP packet: Payload Format for IEEE HARP/InHARP packet:
|31 |23 |15 |7 0| |31 |23 |15 |7 0|
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+ ---------
0 | | 0 | |
| D_ULA +-------------------------------+ | D_ULA +-------------------------------+ HIPPI-
HIPPI- 1 | | | 6400
1 | | |
6400
+-------------------------------+ S_ULA | MAC +-------------------------------+ S_ULA | MAC
2 | | 2 | |
+---------------------------------------------------------------+ header +---------------------------------------------------------------+ header
3 | M_len | 3 | M_len |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+ ---------
4 | AA | AA | 03 | 00 | IEEE 4 | AA | AA | 03 | 00 | IEEE 802
802 +---------------+---------------+---------------+---------------+ LLC/SNAP
+---------------+---------------+---------------+---------------+ 5 | 00 | 00 | Ethertype = 0x0800 = 2048 | header
LLC/SNAP +------------+------------------+-------------------------------+ =========
5 | 00 | 00 | Ethertype = 0x0800 = 2048 |
header
+------------+------------------+-------------------------------+
==========
6 | hrd (1) | pro (2048) | 6 | hrd (1) | pro (2048) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
7 | hln (6) | phl (4) | op (ar$op) | 7 | hln (6) | phl (4) | op (ar$op) |
+<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+ +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+
8 | Source Hardware Address 0 - 3 | 8 | Source Hardware Address 0 - 3 |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
9 | Source ULA bytes 4 - 5 | Source IP Address bytes 0 - 1 | 9 | Source ULA bytes 4 - 5 | Source IP Address bytes 0 - 1 |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
10 | Source IP Address bytes 2 - 3 | Target ULA bytes 0 - 1 | 10 | Source IP Address bytes 2 - 3 | Target ULA bytes 0 - 1 |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
skipping to change at page 21, line 4 skipping to change at page 21, line 48
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
14 | FILL | FILL | FILL | FILL | 14 | FILL | FILL | FILL | FILL |
+><><><><><><><>+<><><><><><><><+><><><><><><><>+<><><><><><><><+ +><><><><><><><>+<><><><><><><><+><><><><><><><>+<><><><><><><><+
6.2 HIPARP Message Formats 6.2 HIPARP Message Formats
The HARP protocols further SHALL support the HIPARP hardware type The HARP protocols further SHALL support the HIPARP hardware type
(ar$hrd) = 28 (dec) [18], protocol type (ar$pro), and operation code (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 (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 addition, HARP makes use of an additional operation code for ARP_NAK
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
introduced with [11]. The remainder of the HIPARP message format introduced with [11]. The remainder of the HIPARP message format
(defined in [13]) is different than the ARP/InARP message format defined (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 in [14,7,10] and it is also different from the format defined in the
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
first "IP and ARP on HIPPI" RFC-1374 [16]. first "IP and ARP on HIPPI" RFC-1374 [16].
The HARP message has several fields that have the following format and The HARP message has several fields that have the following format and
values: values:
Data sizes and field meaning: Data sizes and field meaning:
ar$hrd 16 bits Hardware type ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type of the protocol fields below ar$pro 16 bits Protocol type of the protocol fields below
ar$op 16 bits Operation code (request, reply, or NAK) ar$op 16 bits Operation code (request, reply, or NAK)
ar$pln 8 bits byte length of each protocol address ar$pln 8 bits byte length of each protocol address
skipping to change at page 22, line 5 skipping to change at page 22, line 53
ar$rha - in requests and NAKs it SHALL contain the requester's ar$rha - in requests and NAKs it SHALL contain the requester's
HW address. HW address.
In replies it SHALL contain the target port'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 ar$rpa - in requests and NAKs it SHALL contain the requester's IP
address if known, otherwise zero. address if known, otherwise zero.
In other replies it SHALL contain the target In other replies it SHALL contain the target
port's IP address. port's IP address.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
ar$tha - in requests and NAKs it SHALL contain the target's ar$tha - in requests and NAKs it SHALL contain the target's
HW address if known, otherwise zero. HW address if known, otherwise zero.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
In other replies it SHALL contain the requester's In other replies it SHALL contain the requester's
HW address. HW address.
ar$tpa - in requests and NAKs it SHALL contain the ar$tpa - in requests and NAKs it SHALL contain the
target's IP address if known, otherwise zero. target's IP address if known, otherwise zero.
In other replies it SHALL contain the requester's In other replies it SHALL contain the requester's
IP address. IP address.
Payload Format for HARP/InHARP PDUs: Payload Format for HARP/InHARP PDUs:
|31 |23 |15 |7 0| |31 |23 |15 |7 0|
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+ ---------
0 | | 0 | |
| D_ULA +-------------------------------+ | D_ULA +-------------------------------+ HIPPI-
HIPPI- 1 | | | 6400
1 | | |
6400
+-------------------------------+ S_ULA | MAC +-------------------------------+ S_ULA | MAC
2 | | 2 | |
+---------------------------------------------------------------+ header +---------------------------------------------------------------+ header
3 | M_len | 3 | M_len |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+ ---------
4 | AA | AA | 03 | 00 | IEEE 4 | AA | AA | 03 | 00 | IEEE 802
802 +---------------+---------------+---------------+---------------+ LLC/SNAP
+---------------+---------------+---------------+---------------+ 5 | 00 | 00 | Ethertype = 0x0800 = 2048 | header
LLC/SNAP +------------+------------------+-------------------------------+ =========
5 | 00 | 00 | Ethertype = 0x0800 = 2048 |
header
+------------+------------------+-------------------------------+
==========
6 | hrd (28) | pro (2048) | 6 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
7 | op (ar$op) | pln (6) | shl (q) | 7 | op (ar$op) | pln (6) | shl (q) |
+<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+ +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+
8 | thl (x) | Source IP Address upper (24 bits) | 8 | thl (x) | Source IP Address upper (24 bits) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
9 | Src. IP lower | Target 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 | 10 | Tgt. IP lower | Source HW Address bytes 0 - 2 |
+---------------+-------------------------------+---------------+ +---------------+-------------------------------+---------------+
11 | Source HW Address bytes 3 - q | Tgt HW byte 0 | 11 | Source HW Address bytes 3 - q | Tgt HW byte 0 |
+-----------------------------------------------+---------------+ +-----------------------------------------------+---------------+
12 | Target Hardware Address bytes 1 - 4 | 12 | Target Hardware Address bytes 1 - 4 |
+---------------+-----------------------------------------------+ +---------------+-----------------------------------------------+
13 |Tgt HW byte 5-x| 13 |Tgt HW byte 5-x|
+---------------+ +---------------+
HARP - InHARP Message HARP - InHARP Message
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00 INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
6.2.1 Example Message encodings: 6.2.1 Example Message encodings:
Assume for the following example that the HARP server is in the 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 HIPPI-6400 side and the clients, X and Y are on the HIPPI-800 side of
the non-broadcast capable network. the non-broadcast capable network.
HARP_REQUEST message HARP_REQUEST message
HARP ar$op = 1 (HARP_REQUEST) HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPy HARP ar$tpa = IPx HARP ar$rpa = IPy HARP ar$tpa = IPx
skipping to change at page 24, line 5 skipping to change at page 25, line 5
7 Broadcast and Multicast 7 Broadcast and Multicast
HIPPI-6400-SC requires compliant systems to support broadcast. HIPPI-6400-SC requires compliant systems to support broadcast.
Initial HIPPI-6400-SC systems MAY defer broadcast capability to a Initial HIPPI-6400-SC systems MAY defer broadcast capability to a
broadcast server rather than support it directly in the switching broadcast server rather than support it directly in the switching
mechanism. A centralized HARP server architecture meets two of the mechanism. A centralized HARP server architecture meets two of the
three major duties of a broadcast server. three major duties of a broadcast server.
A central entity serving the whole LIS solves the coordination A central entity serving the whole LIS solves the coordination
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00 INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
problem of a distributed approach. The registration requirement problem of a distributed approach. The registration requirement
solves the second problem of determining which addresses make up the solves the second problem of determining which addresses make up the
set loosely called "everyone". The last duty of a broadcast server is set loosely called "everyone". The last duty of a broadcast server is
to replicate an incoming packet and send it to "everyone". to replicate an incoming packet and send it to "everyone".
During its registration phase, every port , including HARP server(s), During its registration phase, every port , including HARP server(s),
discover if the underlying medium is capable of broadcast (see 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) section 5.1.1). Should this not be the case, then the HARP server(s)
MUST emulate broadcast through an IP broadcast emulation server. MUST emulate broadcast through an IP broadcast emulation server.
skipping to change at page 24, line 28 skipping to change at page 25, line 28
server and only makes sense when the LIS does not inherently support server and only makes sense when the LIS does not inherently support
broadcast. The PIBES allows common upper layer networking protocols broadcast. The PIBES allows common upper layer networking protocols
(RIP, TCP, UDP, etc.)to access IP LIS broadcast. (RIP, TCP, UDP, etc.)to access IP LIS broadcast.
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 7.1 Protocol for an IP Broadcast Emulation Server - PIBES
To emulate broadcast within an LIS, a PIBES SHALL use the currently 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 valid HARP table of the HARP server as a list of addresses called the
target list. The broadcast server SHALL validate that all incoming target list. The broadcast server SHALL validate that all incoming
messages have a source address which corresponds to an address in the messages have a source address which corresponds to an address in the
target list. Only messages addressed to the IP LIS broadcast address target list. Only messages addressed to the IP LIS broadcast
or FF.FF.FF.FF are considered valid messages for broadcasting. addresses, multicast address or 255.255.255.255 are considered valid
Invalid messages MUST be dropped. All valid incoming messages shall messages for broadcasting. Invalid messages MUST be dropped. All
be forwarded to all addresses in the target list. 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 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 the HARP server since this memo does not define the protocol for
exchanging the valid HARP table. 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 7.2 IP Broadcast Address
This memo only defines IP broadcast. It is independent of the This memo only defines IP broadcast. It is independent of the
underlying hardware addressing and broadcast capabilities. Any port underlying hardware addressing and broadcast capabilities. Any port
can differentiate between IP traffic directed to itself and a can differentiate between IP traffic directed to itself and a
broadcast message sent to it by looking at the IP address. All IP broadcast message sent to it by looking at the IP address. All IP
broadcast messages SHALL use the IP LIS broadcast address. broadcast messages SHALL use the IP LIS broadcast address.
It is RECOMMENDED that the PIBES run on the same port as the HARP 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 server. In that case, the PIBES SHALL use the same address as the
HARP server. HARP server.
7.3 IP Multicast Address 7.3 IP Multicast Address
HIPPI-6400 does not directly support multicast address, therefore HIPPI-6400 does not directly support multicast address, therefore
there are no mappings available from IP multicast addresses to HIPPI 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
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00 INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
logical IP subnets if all IP multicast addresses are mapped to the IP multicast services. Current IP multicast implementations (i.e. MBONE
broadcast address or FF.FF.FF.FF. 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.
7.4 A Note on Broadcast Emulation Performance 7.4 A Note on Broadcast Emulation Performance
It is obvious that a broadcast emulation service (as defined in It is obvious that a broadcast emulation service (as defined in
section 7.1) has an inherent performance limit. In an LIS with n 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 ports, the upper bound on the bandwidth that such a service can
broadcast is: broadcast is:
(total bandwidth)/(n+1) (total bandwidth)/(n+1)
since each message must first enter the broadcast server, accounting since each message must first enter the broadcast server, accounting
skipping to change at page 25, line 51 skipping to change at page 27, line 4
9 Security 9 Security
There are known security issues relating to port impersonation via There are known security issues relating to port impersonation via
the address resolution protocols used in the Internet [6]. No the address resolution protocols used in the Internet [6]. No
special security mechanisms have been added to the address resolution special security mechanisms have been added to the address resolution
mechanism defined here for use with networks using HARP. mechanism defined here for use with networks using HARP.
Not all of the security issues relating to ARP over HIPPI-6400 are 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 clearly understood at this time, due to the fluid state of HIPPI-6400
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
specifications, newness of the technology, and other factors. specifications, newness of the technology, and other factors.
However, given the security hole ARP allows, other concerns are However, given the security hole ARP allows, other concerns are
probably minor. probably minor.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
10 Open Issues 10 Open Issues
Synchronization and coordination of multiple HARP servers and Synchronization and coordination of multiple HARP servers and
multiple broadcast servers are left for further study. multiple broadcast servers are left for further study.
11 HARP Examples 11 HARP Examples
Assume a HIPPI-6400-SC switch is installed with three connected Assume a HIPPI-6400-SC switch is installed with three connected
ports: x, y, and a. Each port has a unique hardware address that ports: x, y, and a. Each port has a unique hardware address that
consists unique ULA (ULAx, ULAy and UlAa, respectively). There is a consists unique ULA (ULAx, ULAy and UlAa, respectively). There is a
HARP server connected to a switch port that is mapped to the address HARP server connected to a switch port that is mapped to the address
HWa, this address is the selected HIPPI hardware address in the HRAL HWa, this address is the authoritative HIPPI hardware address in the
(HARP Request Address List). HRAL (HARP Request Address List).
The HARP server's table is empty. Ports X and Y each know their own 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 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 IP address (from the port database) but neither
knows the other's ULA. Both ports X and Y have their interfaces knows the other's ULA. Both ports X and Y have their interfaces
configured DOWN. configured DOWN.
NOTE: The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$pln fields are 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 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. ar$rhl = ar$thl = 6 since these are all HIPPI-6400 examples.
skipping to change at page 26, line 49 skipping to change at page 28, line 4
HIPPI-6400-PH S_ULA = ULAy HIPPI-6400-PH S_ULA = ULAy
HARP ar$op = 8 (InHARP_REQUEST) HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy HARP ar$rpa = IPy
HARP ar$tpa = 0 ** HARP ar$tpa = 0 **
HARP ar$rha = ULAy HARP ar$rha = ULAy
HARP ar$tha = ULAa HARP ar$tha = ULAa
** is what we would like to find out ** is what we would like to find out
2. HARP server receives Y's InHARP_REQUEST, it examines the 2. HARP server receives Y's InHARP_REQUEST, it examines the
source addresses and scans its tables for a match. Since this is source addresses and scans its tables for a match. Since this is
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
the first time Y connects to this server there is no entry and the first time Y connects to this server there is no entry and
one will be created and time stamped with the information from one will be created and time stamped with the information from
the InHARP_REQUEST. The HARP server will then send a the InHARP_REQUEST. The HARP server will then send a
InHARP_REPLY including its IP address. InHARP_REPLY including its IP address.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
HIPPI-6400-PH D_ULA = ULAy HIPPI-6400-PH D_ULA = ULAy
HIPPI-6400-PH S_ULA = ULAa HIPPI-6400-PH S_ULA = ULAa
HARP ar$op = 9 (InHARP_REPLY) HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPs * HARP ar$rpa = IPs *
HARP ar$tpa = IPy HARP ar$tpa = IPy
HARP ar$rha = ULAa HARP ar$rha = ULAa
HARP ar$tha = ULAy HARP ar$tha = ULAy
* answer we were looking for * answer we were looking for
3. Port Y examines the incoming InHARP_REPLY and completes its table 3. Port Y examines the incoming InHARP_REPLY and completes its table
skipping to change at page 27, line 50 skipping to change at page 29, line 4
HARP ar$tha = ULAb HARP ar$tha = ULAb
** is what we would like to find out ** is what we would like to find out
2. Since the network is a broadcast network, client Y will receive 2. Since the network is a broadcast network, client Y will receive
a copy of its InHARP_REQUEST. Client Y examines the source addresses. 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, 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 Y can deduce that it is connected to a broadcast medium. Port Y
completes its table entry for HWa. This entry will not timeout completes its table entry for HWa. This entry will not timeout
since it is considered unlikely for a particular underlying since it is considered unlikely for a particular underlying
hardware type to change between broadcast and non-broadcast; hardware type to change between broadcast and non-broadcast;
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
therefore this mapping will never change. therefore this mapping will never change.
11.3 Operational Phase (phase II) 11.3 Operational Phase (phase II)
The Operational Phase of the HARP protocol as specified in this memo The Operational Phase of the HARP protocol as specified in this memo
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
is the same for both broadcast and non-broadcast capable HIPPI-6400 is the same for both broadcast and non-broadcast capable HIPPI-6400
hardware. The selected address in the HRAL for this example will be hardware. The authoritative address in the HRAL for this example will
HWa: <SWa, ULAa> and IPs for simplicity reasons. be HWa: <SWa, ULAa> and IPs for simplicity reasons.
11.3.1 Successful HARP_Resolve example 11.3.1 Successful HARP_Resolve example
Assume the same process (steps 1-3 of section 11.1) happened for port 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 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 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, 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 1. Port X connects to the authoritative address of the HRAL and
sends a HARP_REQUEST for Y's hardware address: sends a HARP_REQUEST for Y's hardware address:
skipping to change at page 28, line 50 skipping to change at page 30, line 5
HARP ar$tha = ULAx HARP ar$tha = ULAx
* answer we were looking for * answer we were looking for
3. Port X connects to port Y and transmits an IP message with the 3. Port X connects to port Y and transmits an IP message with the
following information in the HIPPI-LE header: following information in the HIPPI-LE header:
HIPPI-6400-PH D_ULA = ULAy HIPPI-6400-PH D_ULA = ULAy
HIPPI-6400-PH S_ULA = ULAx HIPPI-6400-PH S_ULA = ULAx
<data> <data>
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
If the network had been broadcast-capable, the target ports If the network had been broadcast-capable, the target ports
would themselves have received the HARP_REQUEST of step 2 above would themselves have received the HARP_REQUEST of step 2 above
and responded to them in the same way the HARP server did. and responded to them in the same way the HARP server did.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
11.3.2 Non-successful HARP_Resolve example 11.3.2 Non-successful HARP_Resolve example
As in 11.3.1, assume that X and Y are fully registered with the 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 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 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, 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, 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 1. Port X connects to the HARP server switch address and sends
a HARP_REQUEST for Q's hardware address: a HARP_REQUEST for Q's hardware address:
skipping to change at page 29, line 46 skipping to change at page 31, line 5
HARP ar$tpa = IPq HARP ar$tpa = IPq
HARP ar$rha = ULAx HARP ar$rha = ULAx
HARP ar$tha = 0 *** HARP ar$tha = 0 ***
*** No Answer, and notice that the fields do not get swapped, *** No Answer, and notice that the fields do not get swapped,
i.e. the HARP message is the same as the HARP_REQUEST i.e. the HARP message is the same as the HARP_REQUEST
except for the operation code. except for the operation code.
If the network had been broadcast-capable, then there If the network had been broadcast-capable, then there
would not have been a reply. would not have been a reply.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
12 References 12 References
[1] ANSI NCITS 323-1998, Information Technology - High-Performance [1] ANSI NCITS 323-1998, Information Technology - High-Performance
Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH). Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH).
[2] ANSI NCITS 324-199x, Information Technology - High-Performance [2] ANSI NCITS 324-199x, Information Technology - High-Performance
Parallel Interface - 6400 Mbit/s Physical Switch Control Parallel Interface - 6400 Mbit/s Physical Switch Control
(HIPPI-6400-SC). (HIPPI-6400-SC).
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
[3] ANSI NCITS Project Number 1249-D, Information Technology - [3] ANSI NCITS Project Number 1249-D, Information Technology -
High-Performance Parallel Interface - 6400 Mbit/s Optical High-Performance Parallel Interface - 6400 Mbit/s Optical
Specification (HIPPI-6400-OPT). Specification (HIPPI-6400-OPT).
[4] Braden, R., "Requirements for Internet Hosts -- Communication [4] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", RFC-1122, USC/Information Sciences Institute, October Layers", RFC-1122, USC/Information Sciences Institute, October
1989. 1989.
[5] Bradely, T., and Brown, C., "Inverse Address Resolution [5] Bradely, T., and Brown, C., "Inverse Address Resolution
Protocol", RFC-1293, USC/Information Sciences Institute, January Protocol", RFC-2390, September 1998.
1992.
[6] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol [6] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp.
32-48, 1989. 32-48, 1989.
[7] Deering, S, "Host Extensions for IP Multicasting", RFC-1112, [7] Deering, S, "Host Extensions for IP Multicasting", RFC-1112,
USC/Information Sciences Institute, August 1989. USC/Information Sciences Institute, August 1989.
[8] Chesson, Greg, "HIPPI-6400 Overview", IEEE Hot Interconnects 1996, [8] Chesson, Greg, "HIPPI-6400 Overview", IEEE Hot Interconnects 1996,
Stanford University. Stanford University.
[10] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local [10] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local
Area Networks - Logical Link Control IEEE, IEEE, New York, Area Networks - Logical Link Control IEEE, IEEE, New York,
New York, 1989. New York, 1989.
[11] Laubach, Mark., "Classical IP and ARP over ATM", RFC-1577, [11] Laubach, Mark., "Classical IP and ARP over ATM", RFC-2225,
Hewlett-Packard Laboratories, January 1994. Com21, Inc., April 1998.
[12] Mogul, J.C., and Deering, S.E., "Path MTU Discovery", RFC-1191, [12] Mogul, J.C., and Deering, S.E., "Path MTU Discovery", RFC-1191,
Stanford University, November, 1990. Stanford University, November, 1990.
[13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", Internet-Draft, [13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", Internet-Draft,
Silicon Graphics Inc., December 1998. Silicon Graphics Inc., December 1998.
[14] Plummer, D., "An Ethernet Address Resolution Protocol - or - [14] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Addresses to 48-bit Ethernet Address for Converting Network Addresses to 48-bit Ethernet Address for
Transmission on Ethernet Hardware", RFC-826, MIT, November 1982. Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
[15] Postel, J., "Internet Protocol", STD 5, RFC-791, USC/Information [15] Postel, J., "Internet Protocol", STD 5, RFC-791, USC/Information
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 7/00
Sciences Institute, September 1981. Sciences Institute, September 1981.
[16] Renwick, J., Nicholson, A., "IP and ARP on HIPPI", RFC-1374, [16] Renwick, J., Nicholson, A., "IP and ARP on HIPPI", RFC-1374,
Cray Research, Inc., October 1992. Cray Research, Inc., October 1992.
[17] Renwick, J., "IP over HIPPI", RFC-2067, NetStar, Inc., January [17] Renwick, J., "IP over HIPPI", RFC-2067, NetStar, Inc., January
1997. 1997.
INTERNET DRAFT IP and ARP over HIPPI-6400 (GSN) Expires 4/00
[18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC-1700, USC/Information Sciences Institute, October 1994. RFC-1700, USC/Information Sciences Institute, October 1994.
13 Acknowledgments 13 Acknowledgments
This memo could not have come into being without the critical review This memo could not have come into being without the critical review
from Greg Chesson, Carlin Otto, the High performance interconnect from Greg Chesson, Carlin Otto, the High performance interconnect
group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand
and Jeff Young) and the expertise of the ANSI T11.1 Task Group and Jeff Young) and the expertise of the ANSI T11.1 Task Group
responsible for the HIPPI standards work. responsible for the HIPPI standards work.
skipping to change at page 31, line 30 skipping to change at page 32, line 38
by Terry Bradley and Caralyn Brown provide the fundamental algorithms by Terry Bradley and Caralyn Brown provide the fundamental algorithms
of HARP as presented in this memo. Further, the HARP server is based 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 on concepts and models presented in [13], written by Mark Laubach who
laid the structural groundwork for the HARP server. laid the structural groundwork for the HARP server.
14 Author's Address 14 Author's Address
Jean-Michel Pittet Jean-Michel Pittet
Silicon Graphics Inc Silicon Graphics Inc
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94040
Phone: 650-933-6149 Phone: 650-933-6149
Fax: 650-933-3542 Fax: 650-933-3542
EMail: jmp@sgi.com, jmp@acm.org EMail: jmp@sgi.com, jmp@acm.org
 End of changes. 99 change blocks. 
183 lines changed or deleted 200 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/