idnits 2.17.1 draft-pittet-hippiarp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 415 has weird spacing: '... remote nodes...' == Line 527 has weird spacing: '... needed and...' == Line 652 has weird spacing: '...ing the entry...' == Line 707 has weird spacing: '...ding on wheth...' == Line 902 has weird spacing: '... 8 bits byte ...' == (9 more instances...) -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9533 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'LA' on line 969 -- Looks like a reference, but probably isn't: 'FILL' on line 781 == Unused Reference: '11' is defined on line 1521, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1524, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1530, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1537, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1548, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1293 (ref. '7') (Obsoleted by RFC 2390) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 1577 (ref. '13') (Obsoleted by RFC 2225) ** Obsolete normative reference: RFC 1374 (ref. '17') (Obsoleted by RFC 2834) ** Obsolete normative reference: RFC 1340 (ref. '20') (Obsoleted by RFC 1700) ** Obsolete normative reference: RFC 1700 (ref. '21') (Obsoleted by RFC 3232) Summary: 14 errors (**), 0 flaws (~~), 13 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J.-M. Pittet 2 INTERNET DRAFT Silicon Graphics Inc. 3 Expires September 1998 March 1998 5 ARP and IP Broadcast over HIPPI-800 6 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 The ANSI X3T11.1 task force has standardized the encapsulation of 29 IEEE 802.2 LLC PDUs [3]. Another X3T11.1 standard [4] describes the 30 operation of HIPPI physical switches. X3T11.1 chose to leave HIPPI 31 networking issues largely outside the scope of their standards; this 32 document specifies a method for resolving IP addresses to HIPPI 33 hardware addresses (HIPARP) and for emulating IP broadcast in a 34 logical IP subnet (LIS) as a direct extension of HIPARP. 36 Furthermore it is the goal of this memo to define a HIPARP that will 37 allow interoperability for HIPPI-800 and HIPPI-6400 (a.k.a. Gigabit 38 Systems Network, GSN) equipment both broadcast and non-broadcast 39 capable. 41 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 43 TABLE OF CONTENTS 45 1. Introduction 46 2. Scope 47 2.1 Changes from RFC-1374 48 2.2 Terminology 49 3. Definitions 50 3.1 Global Concepts 51 3.2 Glossary 52 4. IP Subnetwork Configuration 53 4.1 Background 54 4.2 HIPPI LIS Requirements 55 5. HIPPI Address Resolution Protocol - HIPARP 56 5.1 HIPARP Algorithm 57 5.1.1 HIPARP registration phase 58 5.1.2 HIPARP operational phase 59 5.2 HIPARP Client Operational Requirements 60 5.3 Receiving Unknown HIPARP Packets 61 5.4 HIPARP Single Server Operational Requirements 62 5.5 HIPARP and Permanent ARP Table Entries 63 5.6 HIPARP Table Aging 64 6. HIPARP Message Encoding 65 6.1 HIPPI-LE Header of HIPARP Messages 66 6.1.1 IEEE 802.2 LLC 67 6.1.2 SNAP 68 6.1.3 Diagram 69 6.2 HIPPI Hardware Address Formats and Requirements 70 6.2.1 48-bit Universal LAN MAC Addresses 71 6.2.2 I-Field requirements for HIPARP messages 72 6.3 HIPARP and InHIPARP Message Formats 73 6.3.1 HIPARP_NAK packet format 74 6.3.2 Combined HIPPI-LE and HIPARP packet addresses 75 7. Broadcast and Multicast 76 7.1 HIPPI IP Broadcast Emulation Server - HIPIBS 77 7.2 IP Broadcast Address 78 7.3 IP Multicast Address 79 7.4 A Note on Broadcast Emulation Performance 80 8. HIPARP for Scheduled Transfer 81 9. Discovery of One's Own Switch Address 82 9.1 Switch Address Discovery 83 10. Security 84 11. Open Issues 85 12. HIPARP Examples 86 12.1 Registration Phase of Client Y on Non-broadcast Hardware 87 12.2 Registration Phase of Client Y on Broadcast Hardware 88 12.3 Operational Phase (phase II) 89 12.3.1 Standard successful HIPARP_Resolve example 90 12.3.2 Standard non-successful HIPARP_Resolve example 92 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 94 13. References 95 14. Acknowledgments 96 15. Author's Address 98 1. Introduction 100 The ANSI High-Performance Parallel Interface (HIPPI) is a dual 101 simplex data channel. HIPPI can send and receive data 102 simultaneously at nearly 800 megabits per second. (HIPPI has an 103 equally applicable 1600 megabit/second option.) Between 1987 and 104 1997, the ANSI X3T11.1 HIPPI working group standardised five 105 documents that bear on the use of HIPPI as a network interface. They 106 cover the physical and electrical specification (HIPPI-PH [1]), the 107 framing of a stream of octets (HIPPI-FP [2]), encapsulation of IEEE 108 802.2 LLC (HIPPI-LE [3]), the behavior of a standard physical layer 109 switch (HIPPI-SC [4]) and the physical-level and optical 110 specification (HIPPI-Serial [5]). HIPPI-LE also implies the 111 encapsulation of Internet Protocol[5]. The reader should be familiar 112 with the ANSI HIPPI documents. Approved ANSI standards are available 113 from ANSI (http://www.ansi.org). The working document of the T11.1 114 HIPPI Standards Committee may be obtained from the T11 web page 115 (http://www.t11.org/) until they become published standards. 117 HIPPI switches can be used to connect a variety of computers and 118 peripheral equipment for many purposes, but the working group stopped 119 short of describing their use as Local Area Networks. This memo 120 takes up where the working group and RFC-2067 [18] left off and 121 defines address resolution and LIS IP broadcast emulation for HIPPI- 122 800 networks. 124 While investigating possible solutions for HIPARP it became evident 125 that IP broadcast could easily be emulated for both HIPPI-800 and 126 HIPPI-6400 hardware types. This is useful since HIPPI switches are 127 not required to implement broadcast but many standard networking 128 protocols rely on broadcast. This memo therefore further addresses 129 the emulation of LIS IP broadcast as an extension of HIPARP. 131 2. Scope 133 2.1 Changes from RFC-1374 135 RFC-2067 left ARP out of its scope because there was not enough 136 implementation experience. This memo is an effort to clarify and 137 expand the definition of ARP over HIPPI as found in RFC-1374 such 138 that implementations will be more readily possible, especially 139 considering forward interoperability with HIPPI-6400. 141 The changes from RFC-1374 are: 143 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 145 o A new packet format to acknowledge the HIPPI hardware address 146 format and to eliminate the requirement of HIPPI-LE ARP for HIPARP 147 to function. 149 o Explicit registration phase. 151 o Additional packet formats: InHIPARP requests and replies as 152 well as HIPARP_NAKs. 154 o Details about the IP subnetwork configuration. 156 o Details about table aging. 158 o IP broadcast emulation. 160 2.2 Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC-2119. 166 2.3 Limitations 168 This memo defines the address resolution service in the LIS and 169 constrains it to consist of a single HIPARP service address. This 170 memo recognizes the possible future development of standards and 171 implementations of multiple-HIPARP-server models that will extend the 172 operations as defined in this memo to provide a highly reliable 173 address resolution service. 175 3. Definitions 177 3.1 Global concepts used 179 In the following discussion, the terms "requester" and "target" are 180 used to identify the node initiating the address resolution request 181 and the node whose address it wishes to discover, respectively. If 182 not all switches in the LIS support boadcast then there will be a 183 HIPARP server providing the address resolution service and it will be 184 the source of the reply. If on the other hand all switches support 185 broadcast then the source address of a reply will be the address of 186 the target. 188 This document uses the terms node, host, etc. when talking about 189 destinations of messages. This is not entirely correct in the sense 190 that HIPPI addresses or IP addresses which are said to identify such 191 an entity actually identify one host adapter within that entity. 193 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 195 3.2 Glossary 197 Classical/Conventional 199 Used with respect to networks, this refers to Ethernet, FDDI and 802 200 LAN types, as distinct from HIPPI-SC LANs. 202 Destination 204 The HIPPI implementation that receives data from a HIPPI Source. 206 HIPARP 208 HIPARP describes the whole set of HIPPI address resolution encodings 209 and algorithm defined in this memo. HIPARP is a combination and 210 adaptation of the Internet Address Resolution Protocol (ARP) RFC-826 211 [15], Inverse ARP (InARP), and Reverse ARP [10] (see section 5). 212 HIPARP also describes the HIPPI specific version of ARP [10] (i.e. 213 the protocol and the HIPPI specific encoding). 215 HIPIBS 217 HIPPI IP Broadcast Server (see section 7). 219 HIPRAL 221 The HIPARP Request Address List (see section 4.2). 223 Host 225 An entity, ususally a computer system, that may have one or more 226 HIPPI nodes and which may serve as a client or a HIPARP server. 228 Node 230 An entity consisting of one HIPPI Source/Destination dual simplex 231 pair that is connected by parallel or serial HIPPI to a HIPPI-SC 232 switch and that transmits and receives IP datagrams. A node may be 233 an Internet host, bridge, router, or gateway. This memo uses the 234 term node in place of the usual term "host", to indicate that a host 235 might be connected to the HIPPI LAN through an external adaptor that 236 does some of the protocol processing for the host (instead of being 237 connected directly). 239 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 241 HIPPI-Serial 243 An implementation of HIPPI in serial fashion on coaxial cable or 244 optical fiber. (see [5]) 246 Switch Address 248 A value used as the address of a node on a HIPPI-SC network. It is 249 transmitted in the I-field. HIPPI-SC switches may map Switch 250 Addresses to physical port numbers. The switch address is extended 251 with a mode byte to form an I-Field (see [4] and 6.2.2) 253 Source 255 The HIPPI implementation that generates data to send to a HIPPI 256 Destination. 258 Universal LAN MAC Address (ULA) 260 A 48-bit globally unique address, administered by the IEEE, assigned 261 to each node on an Ethernet, FDDI, 802 network, or HIPPI- SC LAN. 263 4. IP Subnetwork Configuration 265 4.1 Background 267 ARP (address resolution protocol) as defined in [13] was meant to 268 work on the 'local' cable. This definition gives the ARP protocol a 269 local logical IP subnet (LIS) scope. In the LIS scenario, each 270 separate administrative entity configures its hosts and routers 271 within the LIS. Each LIS operates and communicates independently of 272 other LISs on the same HIPPI network. 274 In the classical model, hosts communicate directly via HIPPI to other 275 hosts within the same LIS using the HIPARP mechanism described in 276 section 5 for resolving target IP addresses to target HIPPI endpoint 277 addresses. HIPARP has LIS scope only and serves all hosts in the 278 LIS. Communication to hosts located outside of the local LIS is 279 usually provided via an IP router. This router is a HIPPI endpoint 280 attached to the HIPPI network that is configured as a member of one 281 or more LISs. This configuration MAY result in a number of disjoint 282 LISs operating over the same HIPPI network. Using this model, hosts 283 of different IP subnets MUST communicate via an intermediate IP 284 router even though it may be possible to open a direct HIPPI 285 connection between the two IP members over the HIPPI network. This is 287 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 289 an obvious consequence of using IP and choosing to have multiple 290 LIS's on the same HIPPI fabric. 292 By default, the HIPARP method detailed in section 5 and the classical 293 LIS routing model MUST be available to any IP member client in the 294 LIS. 296 4.2 HIPPI LIS Requirements 298 The requirements for IP members (hosts, routers) operating in a HIPPI 299 LIS configuration are: 301 o All members of the LIS SHALL have the same IP network/subnet 302 and address mask [6]. 304 o All members within an LIS SHALL be directly connected to the 305 HIPPI network. 307 o All members of an LIS MUST implement the HIPARP mechanism for 308 resolving IP addresses to HIPPI addresses as detailed in this memo 309 in section 5, "HIPPI Address Resolution Protocol - HIPARP." 311 o All members within an LIS MUST be able to communicate via HIPPI 312 with all other members in the same LIS. 314 The following list identifies the set of HIPPI-specific parameters 315 that MUST be implemented in each IP station connected to the HIPPI 316 network: 318 o HIPPI Hardware Address: 320 The HIPPI hardware address of an individual IP endpoint (i.e. a 321 network adapter within a host) MUST contain a switch address (see 322 section 9). The address SHOULD also contain a non-zero ULA 323 address. If there is no ULA then that field MUST be zero. 325 o HIPARP Request Address List (HIPRAL): 327 The HIPRAL is an ordered list of one or more addresses identifying 328 the address resolution service(s). The HIPRAL SHOULD be the same 329 for all nodes within a LIS. The HIPRAL MUST contain at least one, 330 and MAY contain more than one HIPPI address, identifying the 331 individual HIPARP service(s) that have authoritative 332 responsibility for resolving HIPARP requests of all IP members 333 located within the LIS. An LIS MUST have at least one HIPARP 334 service entry configured and available to all members of the LIS. 336 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 338 This memo only defined the behaviour of the address resolution 339 service for one entry in the HIPRAL. This memo recognizes the 340 future development of standards and implementations of multiple- 341 HIPARP-server models that will extend the operations as defined in 342 this memo to provide a highly reliable address resolution service. 344 Depending on the hardware broadcast capabilities, the address MAY 345 be the address for "IP traffic conventionally directed to the IEEE 346 802.1 broadcast address: 0xFE1" [4] if every switch in the LIS 347 supports this address feature or otherwise the address of a HIPARP 348 server. For example, the HIPARP server address MAY be the 349 reserved address for "Messages pertaining to (the) ... address 350 resolution requests: 0xFE0 " [4] or any other address identifying 351 a HIPARP server. 353 In the case where there is only a single HIPRAL address, all HIPARP 354 clients MUST be configured identically to have one non-null entry in 355 HIPRAL configured with the same address. That identifies the primary 356 HIPARP service. 358 Within the restrictions mentioned above and in Section 6.2.2, local 359 administration MUST choose an address(es) for the HIPARP service 360 which they will put into the HIPRAL. 362 Manual configuration of the addresses and address lists presented in 363 this section is implementation dependent and beyond the scope of this 364 memo; i.e. this memo does not require any specific configuration 365 method. For all implementations designed in compliance with this 366 memo, these addresses MUST be configured completely on the client, as 367 appropriate for the LIS, prior to use by any service or operation 368 detailed in this memo. 370 5. HIPPI Address Resolution Protocol - HIPARP 372 Address resolution within the HIPPI LIS SHALL make use of the HIPPI 373 Address Resolution Protocol (HIPARP) (based on [15]) and the Inverse 374 HIPPI Address resolution Protocol (InHIPARP) (based on [7]). HIPARP 375 is the same protocol as the Internet Address Resolution Protocol 376 (ARP) which is defined in RFC-826 [15] except the HIPPI specific 377 packet format. Ethernet, FDDI, and 802 networks use ARP to discover 378 another host's hardware address, knowing the Internet address. 379 InHIPARP is the same protocol as the original Inverse ARP (InARP) 380 protocol presented in [7] except the HIPPI specific packet format. 381 InARP is used to discover the other party's Internet address, knowing 382 its hardware address. HIPRARP is the same protocol as reverse ARP 383 [10] and is used by a client to discover it's own Internet address, 384 from its own hardware address. 386 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 388 HIPARP presented in this section further specifies the combination of 389 these original protocol definitions to form a coherent address 390 resolution service that is independent of the harware's broadcast 391 capability. 393 Internet addresses are assigned independent of ULAs and switch 394 addresses. Each host implementation MUST know its own IP, ULA and 395 switch address (see section 9 "Discovery of One's Own Switch Address" 396 for one implementation method) and MUST respond to address resolution 397 requests appropriately (see sections 6.2 and 6.3, within "HIPARP 398 Message Encodings"). IP members MUST use HIPARP to resolve IP 399 addresses to hardware addresses when needed. 401 This memo defines the address resolution service in the LIS and 402 constrains it to consist of a single HIPARP server. Client-server 403 interaction is defined by using a single server approach as a 404 reference model. 406 This memo recognizes the future development of standards and 407 implementations of multiple-HIPARP-server models that will extend the 408 operations as defined in this memo to provide a highly reliable 409 address resolution service. 411 5.1 HIPARP Algorithm 413 This section defines the behavior and requirements for host HIPARP 414 implementation on both broadcast and non-broadcast capable HIPPI-SC 415 networks. HIPARP creates a table in each node that map remote nodes' 416 IP addresses to Switch Addresses and to optional ULAs, so that when 417 an application requests a connection to a remote node by its IP 418 address, both the Switch Address and the remote ULA can be 419 determined, a correct HIPPI-LE header can be built, and a connection 420 to the node can be established using the correct Switch Address in 421 the I-field. 423 HIPARP is a two phase protocol. The first phase is a registration 424 phase and the second phase is the operational phase. The operational 425 phase works much like conventional ARP with the exception of the 426 packet format. The registration phase uses the InARP protocol to 427 register and establish a table entry with the server. 429 5.1.1 HIPARP registration phase 431 The HIPARP client is responsible for contacting the HIPARP server to 432 have its own IP and HIPPI hardware address information registered. 433 HIPARP clients SHALL initiate the registration phase through the 434 sending of an InHIPARP_REQUEST message to the primary address in the 435 HIPRAL. 437 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 439 If the HIPPI-SC LAN supports broadcast, then the client will see its 440 own InHIPARP_REQUEST packet. The client SHALL complete the 441 registration phase after verifying that the InHIPARP_REQUEST contains 442 the address information it previously inserted. The client will 443 further note that it is connected to a broadcast capable network and 444 use this information for table aging and IP broadcast emulation as 445 specified in sections 5.4 and 5.6 respectively. 447 If on the other hand the client is connected to a non-broadcast 448 capable HIPPI-SC network it SHALL await an InHIPARP_REPLY before 449 completing the registration phase. This will also provide the client 450 with the protocol address by which the HIPARP server is addressable. 452 5.1.2 HIPARP operational phase 454 Once a HIPARP client has completed its registration phase it enters 455 the operational phase. In this phase of the protocol, the HIPARP 456 client SHALL gain and refresh its own HIPARP table information about 457 other IP members through the sending of HIPARP_REQUESTS to the 458 primary address in the HIPRAL and the reception of HIPARP_REPLYs. The 459 client is fully operational during the operational phase. 461 In this phase, the client's behavior is the same for broadcast or 462 non-broadcast HIPPI-SC switched networks. 464 The target of an address resolution request SHOULD first update its 465 address mapping tables with any new information it can find in a 466 request. If it is the target node (see table below) it SHALL 467 formulate and send a reply packet. A node is the target of an 468 address resolution request if any ONE of the following statements are 469 true of the request: 471 1. The node's IP address is in the target protocol address field 472 (ar$tpa) of the HIPARP message. 474 2. The node's ULA (if non-zero), is in the ULA part of the Target 475 Hardware Address field (ar$tha) of the message. 477 3. The node's switch address is in the Target Switch Address field 478 of Target Hardware Address field (ar$tha) of the message (see 479 section 6.2.2). 481 4. The node is the primary HIPARP server . 483 NOTE: It is strongly RECOMMENDED to have a HIPARP server run on a 484 node which has a non-zero ULA. 486 5.2 HIPARP Client Operational Requirements 487 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 489 The HIPARP client is responsible for contacting the HIPARP server to 490 have its own HIPARP information registered and to gain and refresh 491 its own HIPARP entry/information about other IP members. This means, 492 as noted above, that HIPARP clients MUST be configured with the 493 switch address and optionally the ULA of the HIPARP server in the 494 HIPRAL. 496 HIPARP clients MUST: 498 1. When an interface is enabled (e.g. "ifconfig up"), 499 the client SHALL send an InHIPARP_REQUEST message to the primary 500 address in the HIPRAL. This allows the client to detect a 501 broadcast network or this message registers the client with the 502 HIPARP server if. The client will either receive its 503 InHIPARP_REQUEST on a broadcast capable LIS or an InHIPARP_REPLY. 504 The client SHALL await one of the two messages before successfuly 505 completing the registration phase and passing into the 506 operational phase. 508 2. After successfully completing the registration phase, the clients 509 MUST respond to HIPARP_REQUEST and InHIPARP_REQUEST packets, if 510 it is the target node. If an interface has multiple IP addresses 511 (e.g., IP aliases) then the client MUST cycle through all the IP 512 addresses and generate an InHIPARP_REPLY for each such address. 513 In that case an InHIPARP_REQUEST can have multiple replies. 514 (Refer to Section 7, "Protocol Operation" in RFC-1293 [7].) 516 3. Generate and transmit HIPARP_REQUEST packets to the primary 517 address in the HIPRAL. It must respond to address resolution 518 reply packets appropriately to build/refresh its own client 519 HIPARP table entries. All (solicited and unsolicited) 520 HIPARP_REPLYs SHALL be used to update and refresh its own client 521 HIPARP table entries. 523 Explanation: This allows the HIPARP server to update the clients 524 when one of its mappings change, similar to what is accomplished 525 on Ethernet with gratuitous ARP. 527 4. Generate and transmit InHIPARP_REQUEST packets as needed and 528 process InHIPARP_REPLY packets appropriately (see section 5.1.1 529 and 5.6). All InHIPARP_REPLY packets SHALL be used to 530 build/refresh its own client HIPARP table entries. (Refer to 531 Section 7, "Protocol Operation" in [7].) 533 If the registration phase showed that the underlying network doesn't 534 support broadcast, then the client MUST refresh its own HIPARP 535 information with the server at least once every 15 minutes through 536 the repetition of step 1 or the exchange of other HIPARP traffic with 538 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 540 the HIPARP server. To decrease the redundant network traffic, his 541 timeout SHOULD be reset after each HIPARP_REPLY from the server. 542 Explanation: The HIPARP_REQUEST shows the HIPARP server that the 543 client is still alive. Receiving a HIPARP_REPLY indicates to the 544 client that the server must have seen the HIPARP_REQUEST. 546 5.3 Receiving Unknown HIPARP Packets 548 If a HIPARP client receives a HIPARP message with an operation code 549 (ar$op) that it is not coded to support, it MUST gracefully discard 550 the message and continue normal operation. A HIPARP client is NOT 551 REQUIRED to return any message to the sender of the unsupported 552 message. 554 5.4 HIPARP Single Server Operational Requirements 556 The HIPARP server accepts HIPPI connections from other HIPPI 557 endpoints. The HIPARP server expects an InARP_REQUEST from the client 558 as first message from the client. The server examines the IP address, 559 the switch address, and the ULA of the InARP_REQUEST and adds or 560 updates its HIPARP table entry 561 as well as the time stamp. 563 If the InHIPARP_REQUEST requester's IP address duplicates a table 564 entry IP address and the InHIPARP_REQUEST hardware address does not 565 match the table entry hardware address, then the table entry SHALL be 566 updated to the new mapping (E.g. moving an IP alias). If the 567 InHIPARP_REQUEST requester's ULA and switch address pair duplicates a 568 ULA and switch address table entry, the IP address SHALL be added to 569 the previous IP address(es). (E.g. adding an IP alias). If the ULA 570 and switch address match only partially, the information SHALL be 571 discarded and no modification to the table is made. 573 The server MUST update the HIPARP table entry's timeout for each 574 HIPARP_REQUEST. Explanation: if the client is sending HIPARP requests 575 to the server, then the server should note that the client is still 576 "alive" by updating the timeout on the client's HIPARP table entry. 578 The HIPARP server SHOULD send out HIPARP_REPLYs to all HW addresses 579 in its table when it undertakes a change of an existing entry in its 580 tables. This feature decreases the time of stale entries in the 581 clients. 583 The following table shows all possible situations at the HIPARP 584 server when a HIPARP_REQUEST is received. Since a HIPPI hardware 585 address is one unit, it is invalid only to change part of it. Any 586 actions marked with (*) indicate that the inactivity timeout SHALL be 588 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 590 reset. 592 +---+-----------+-----------+-----------+-----------------------+ 593 | # | IP entry | ULA entry | Sw addr |Action | 594 +---+-----------+-----------+-----------+-----------------------+ 595 | 1 | duplicate | duplicate | duplicate | * | 596 | 2 | duplicate | duplicate | new | Not Valid | 597 | 3 | duplicate | new | duplicate | Not Valid | 598 | 4 | duplicate | new | new | move IP alias,* | 599 | 5 | new | duplicate | duplicate | add IP alias to tbl,* | 600 | 6 | new | duplicate | new | Not Valid | 601 | 7 | new | new | duplicate | Not Valid | 602 | 8 | new | new | new | fresh entry, add it,* | 603 +---+-----------+-----------+-----------+-----------------------+ 605 5.5 HIPARP and Permanent ARP Table Entries 607 An IP station MUST have a mechanism (e.g. manual configuration) for 608 determining what permanent entries it has. The details of the 609 mechanism are beyond the scope of this memo. The permanent entries 610 allow interoperability with legacy HIPPI adapters which do not yet 611 implement dynamic HIPARP and use a table based static ARP. Permanent 612 entries are not aged. 614 5.6 HIPARP Table Aging 616 HIPARP table aging MUST be supported since IP addresses, especially 617 IP aliases and also interfaces (with their ULA), are likely to move. 618 When so doing the mapping in the clients own HIPARP table/cache 619 becomes invalid and stale. 621 o HIPARP table entries in client tables are valid for a maximum 622 time of 15 minutes. 624 o HIPARP table entries in the server table are valid for a 625 maximum time of 20 minutes. 627 If a server entry ages beyond 20 minutes without being updated 628 (refreshed) by the client, that entry SHALL be deleted from the 629 HIPARP server's table. 631 When a client HIPARP table entry ages, a HIPARP client MUST 632 invalidate the table entry. The client MUST revalidate the entry 633 prior to transmitting any non address resolution traffic to the node 634 referred to by this entry. 636 NOTE: the client is permitted to revalidate a HIPARP table entry 638 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 640 before it ages, thus restarting the aging time when the table entry 641 is successfully revalidated. The client MAY continue sending traffic 642 to the node referred to by this entry while revalidation is in 643 progress, as long as the table entry has not aged. 645 The client revalidates the entry by querying the address resolution 646 service. If a valid reply is received (e.g. HIPARP_REPLY), the entry 647 is updated. If the address resolution service cannot resolve the 648 entry (e.g. HIPARP_NAK, "host not found"), the associated table entry 649 is removed. If the address resolution service is not available (i.e. 650 "server failure") the client MUST attempt to revalidate the entry by 651 transmitting an InHIPARP_REQUEST to the hardware address of the entry 652 in question and updating the entry on receipt of an InHIPARP_REPLY. 653 If the InHIPARP_REQUEST attempt fails to return an InHIPARP_REPLY, 654 the associated table entry is removed. 656 6. HIPARP Message Encoding 658 The HIPARP FP header values are to be set as defined in RFC-2067 "IP 659 over HIPPI" [18]. 661 6.1 HIPPI-LE Header of HIPARP Messages 663 The HIPPI packet format for Internet datagrams shall conform to the 664 HIPPI-FP [2] and HIPPI-LE [3] standards. The length of a HIPPI 665 packet, including trailing fill, shall be a multiple of eight octets 666 as required by HIPPI-LE. The HIPPI-LE header fields of HIPARP, 667 HIPRARP, and InHIPARP requests and replies SHALL be set to: 669 FC (3 bits) shall contain zero unless otherwise defined by local 670 administration. 672 Double-wide SHALL be set to 0. This memo does not address the 673 implications on HIPARP when this bit is set to 1 indicating the 674 possibility of a node being able to accept 64-bit HIPPI connections. 676 Message_Type SHALL contain 0 to indicate data. as defined in 677 HIPPI-LE. 679 There is no HIPARP message corresponding to HIPPI-LE self-address 680 discovery; these packets are sent without ULP data as specified in 681 HIPPI-LE [3]. 683 Destination_Switch_Address, in requests, SHALL be the Switch Address 684 of the destination node if known, otherwise zero. In replies, it 685 SHALL be the requester's Switch Address. 687 Destination_Address_Type SHALL be 2, a 12-bit address. Type 1, source 689 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 691 routing, is not acceptable in this specification. 693 Source_Address_Type SHALL be 2, a 12-bit address. Type 1, source 694 routing, is not acceptable in this specification. 696 Source_Switch_Address in requests SHALL be the Switch Address of the 697 requesting node. In replies it SHALL be the replying node's Switch 698 Address. That is, the switch address of either the target or the 699 HIPARP server, depending on whether a LIS supports broadcast or not, 700 respectively. 702 Destination_IEEE_Address SHALL be the ULA of the destination node, if 703 known, otherwise zero. In replies, it SHALL be the requester's ULA. 705 Source_IEEE_Address SHALL be the ULA of the requesting node. In 706 replies it SHALL be the replying node's ULA Address. That is the the 707 target's ULA or HIPARP server's ULA, depending on whether a LIS 708 supports broadcast or not, respectively. 710 6.1.1 IEEE 802.2 LLC 712 The IEEE 802.2 LLC Header SHALL begin in the first byte of the 713 HIPPI-FP D2_Area. 715 The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 octets) 716 indicates the presence of a SNAP header. 718 6.1.2 SNAP 720 The OUI value for Organization Code SHALL be 0x00-00-00 (3 octets) 721 indicating that the following two-bytes is an ethertype. 723 The Ethertype value SHALL be set as defined in Assigned Numbers [21]: 724 HIPARP = ARP = 2054 ('0806'h), HIPRARP = RARP = 32,821 ('8035'h). 726 The total size of the LLC/SNAP header is fixed at 8-octets. 728 6.1.3 Diagram 730 Payload Format for HIPARP/InHIPARP/HIPRARP PDUs: 732 31 28 23 21 15 10 7 2 0 733 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 734 0 | 04 |1|0| 000 | 03 | 0 | 735 +---------------+-+-+---------------------+---------------+-----+ 736 1 | 36 | 737 +-----+-+-------+-----------------------+-----------------------+ 738 2 |[LA] |W|M_Type | 000 |Requester's Switch Addr| 740 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 742 +-----+-+-------+-----------------------+-----------------------+ 743 3 | D_A_T | S_A_T | 000 | Replyer's Switch Addr | 744 +-------+-------+---------------+-------+-----------------------+ 745 4 | 00 00 | | 746 +-------------------------------+ | 747 5 | Requester's ULA | 748 +-------------------------------+-------------------------------+ 749 6 | [LA] | | 750 +-------------------------------+ | 751 7 | Destination ULA | 752 +===============+===============+===============+===============+ 753 8 | AA | AA | 03 | 00 | 754 +---------------+---------------+---------------+---------------+ 755 9 | 00 | 00 | EtherType (2054) | 756 +---------------+---------------+-------------------------------+ 757 10 |Message octet 0|Message octet 1|Message octet 2| . . . | 758 +---------------+---------------+---------------+--- | 759 | . . . | 760 + ------------+---------------+---------------+---------------+ 761 | . . . | octet (n-2) | octet (n-1) | FILL | 762 +---------------+---------------+---------------+---------------+ 763 N-1| FILL | FILL | FILL | FILL | 764 +---------------+---------------+---------------+---------------+ 766 HIPPI Packet Format 768 Words 0-1: HIPPI-FP Header 769 Words 2-7: D1 Area (HIPPI-LE Header) 770 Words 8-9: D2 Area (IEEE 802.2 LLC/SNAP) 771 Words 10-(N-1): D2 Area (HIPARP message) 772 (n) is the number of octets in the HIPARP message. 773 +====+ denotes the boundary between D1 and D2 areas. 774 [LA] fields are zero unless used otherwise locally. 775 Abbreviations: 776 "W" = Double_Wide field SHALL be 0 777 "M_Type" = Message_Type field SHALL be set according to 778 HIPPI-LE 779 "D_A_T" = Destination_Address_Type SHALL be 2 780 "S_A_T" = Source_Address_Type SHALL be 2 781 [FILL] octets complete the HIPPI packet to an even 782 number of 32 bit words. The number of fill octets 783 is not counted in the data length. 785 6.2 HIPPI Hardware Address Formats and Requirements 787 For HIPPI-800, the Hardware Address is a 9-byte unit that SHALL 789 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 791 contain the Switch Address AND the ULA. Since HIPPI-800 doesn't 792 require the use of a ULA, its fields MAY be zero. The address length 793 is still 9 bytes. See the following diagram for an example of the 794 HIPPI Hardware Address in the HIPARP Message: 796 31 23 15 7 0 797 +---------------+-----------------------------------------------+ 798 | ... |Requester's HIPPI Hardware Address octets 0 - 2| 799 +---------------+-----------------------------------------------+ 800 | Requester's HIPPI Hardware Address octets 3 - 6 | 801 +-------------------------------+-------------------------------+ 802 | Requester's HW Addr oct 7 - 8 | 803 +---------------+---------------+ 805 In the case of the Requester's HIPPI Hardware Address, the HIPPI 806 hardware address is split into Switch address and ULA as follows: 808 31 23 15 7 0 809 +---------------+-----------------------------------------------+ 810 | ... |Requester's Switch Address 0-2, HW Addr 0 - 2 | 811 +---------------+---------------+---------------+---------------+ 812 | Requester's ULA octets 0 - 3 = Hardware Addr octets 3 - 6 | 813 +---------------+---------------+---------------+---------------+ 814 | Req's ULA 4-6 = HW Addr 7-8 | 815 +---------------+---------------+ 817 NOTE: In the case of HIPPI-6400, the hardware address is ONLY the 6- 818 byte ULA. Therefore the length of the hardware address clearly 819 defines which version of HIPPI is being used. 821 6.2.1 48-bit Universal LAN MAC Addresses 823 IEEE Standard 802.1A specifies the Universal LAN MAC Address. The 824 globally unique part of the 48-bit space is administered by the IEEE. 825 Each node on a HIPPI-SC LAN should be assigned a ULA. Multiple ULAs 826 may be used if a node contains more than one IEEE 802.2 LLC protocol 827 entity. 829 The format of the HIPPI hardware address within its HIPARP packet 830 follows IEEE 802.1A canonical bit order and HIPPI-FP bit and byte 831 order. For example the requester's ULA part of the HIPPI hardware 832 address would decompose to: 834 31 23 15 7 0 835 +---------------+---------------+---------------+---------------+ 836 |ULA octet 0|L|G| ULA octet 1 | ULA octet 2 | ULA octet 3 | 837 +---------------+---------------+---------------+---------------+ 838 | ULA octet 4 | ULA octet 5 | 840 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 842 +---------------+---------------+ 844 Universal LAN MAC Address Format 846 L (U/L bit) = 1 for Locally administered addresses, 0 for 847 Universal. 848 G (I/G bit) = 1 for Group addresses, 0 for Individual. 850 The use of ULAs is OPTIONAL, but RECOMMENDED. The use of ULAs is 851 REQUIRED if a host wishes to interoperate with HIPPI-6400 units. 852 Although ULAs are not used by HIPPI-SC switches, they are helpful for 853 HIPPI Switch Address resolution, and for distinguishing between 854 multiple logical entities that may exist within one node. They may 855 also be used by bridging devices that replace HIPPI hardware headers 856 with the MAC headers of other LANs. Carrying the ULAs in the HIPPI 857 header may simplify these devices, and it may also help if HIPPI is 858 used as an interface to some future HIPPI based LAN that uses only 859 ULAs for addressing (e.g. HIPPI-6400). 861 6.2.2 I-Field requirements for HIPARP messages 863 The first byte of the I-Field contains mode bits defined in HIPPI-SC 864 [4]. For simplicity and feasibility, this byte SHALL be the same for 865 all nodes in an LIS. It MAY be a configurable parameter. Consistency 866 across ALL the nodes in an LIS MUST be assured through means which 867 are beyond the scope of this memo. 869 Unless another convention is locally defined for HIPARP requests, the 870 I-field Path Selection bits SHOULD be set to binary 01 or 11 (logical 871 address mode). Section 6.1, "HIPPI-LE Header of the HIPARP Messages" 872 defines the values for the FC, Double-wide and Mesage-type fields. 874 6.3 HIPARP and InHIPARP Message Formats 876 The HIPARP protocols use the same hardware type (ar$hrd), protocol 877 type (ar$pro), and operation code (ar$op) data formats as the ARP, 878 InARP and RARP protocols [15,7,10]. The location of these three 879 fields within the HIPARP packet are in the same byte positions as 880 those in conventional ARP, RARP and InARP packets.In addition, HIPARP 881 makes use of an additional operation code for ARP_NAK introduced with 882 [13].The remainder of the HIPARP/InHIPARP packet format is different 883 than the ARP/InARP packet format defined in [15,7,10] and it is also 884 different from the format defined in the first "IP and ARP on HIPPI" 885 RFC-1374 [17]. 887 HIPARP packets SHALL be transmitted with a hardware type code of 1 888 (as for Ethernet). Furthermore, HIPARP packets SHALL be accepted if 890 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 892 received with hardware type codes of either 1 or 6 (IEEE 802 893 networks). 895 The HIPARP message has several fields that have the following format 896 and values: 898 Data sizes and field meaning: 899 ar$hrd 16 bits Hardware type 900 ar$pro 16 bits Protocol type of the protocol fields below 901 ar$op 16 bits Operation code (request, reply, or NAK) 902 ar$pln 8 bits byte length of each protocol address 903 ar$rhl 8 bits requester's HIPPI hardware address length (q) 904 ar$thl 8 bits target's HIPPI hardware address length (x) 905 ar$rpa 32 bits requester's protocol address 906 ar$tpa 32 bits target's protocol address 907 ar$rha qoctets requester's HIPPI Hardware address 908 ar$tha xoctets target's HIPPI Hardware address 910 Where : 911 ar$hrd - SHALL contain 1. (Ethernet) 913 ar$pro - SHALL contain the IP protocol code 2048 (decimal). 915 ar$op - SHALL contain the operational value (decimal): 916 1 for HIPARP_REQUESTs 917 2 for HIPARP_REPLYs 918 3 for HIPRARP_REPLYs 919 4 for HIPRARP_REPLYs 920 8 for InHIPARP_REQUESTs 921 9 for InHIPARP_REPLYs 922 10 for HIPARP_NAK 924 ar$hln - SHALL contain 9 IF this is a HIPPI-800 link 925 ELSE, for HIPPI-6400, it SHALL contain 6. 927 ar$pln - SHALL contain 4. 929 ar$rha - in requests and NAKs it SHALL contain the requester's ULA 930 In replies it SHALL contain the target node's ULA. 932 ar$rpa - in requests and NAKs it SHALL contain the requester's IP 933 address if known, otherwise zero. 934 In other replies it SHALL contain the target 935 node's IP address. 937 ar$tha - in requests and NAKs it SHALL contain the target's ULA 938 if known, otherwise zero. 939 In other replies it SHALL contain the requester's ULA. 941 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 943 ar$tpa - in requests and NAKs it SHALL contain the 944 target's IP address if known, otherwise zero. 945 In other replies it SHALL contain the requester's 946 IP address. 948 The format of the six octets of the ULA SHALL be the same as required 949 in the HIPPI-LE header (see section 6.2, "HIPPI Hardware Address 950 Formats and Requirements" above), except for the alignment of the 951 ULAs with respect to the 32-bit HIPPI word, which is different 952 between ARP and HIPPI-LE. No bit reversal is necessary as is 953 required with FDDI. 955 31 28 23 21 15 10 7 2 0 956 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 957 0 | 04 |1|0| 000 | 03 | 0 | 958 +---------------+-+-+---------------------+---------------+-----+ 959 1 | 36 | 960 +-----+-+-------+-----------------------+-----------------------+ 961 2 |[LA] |W| 1 | 000 | Dest. Switch Addr | 962 +-----+-+-------+-----------------------+-----------------------+ 963 3 | 2 | 2 | 000 |Requester's Switch Addr| 964 +---------------+---------------+-------+-----------------------+ 965 4 | 00 00 | | 966 +-------------------------------+ | 967 5 | Destination ULA | 968 +-------------------------------+-------------------------------+ 969 6 | [LA] | | 970 +-------------------------------+ | 971 7 | Requester's ULA | 972 +===============+===============+===============+===============+ 973 8 | AA | AA | 03 | 00 | 974 +---------------+---------------+---------------+---------------+ 975 9 | 00 | 00 | EtherType (2054) | 976 +---------------+---------------+-------------------------------+ 977 10 | hrd (1) | pro (2048) | 978 +---------------+---------------+---------------+---------------+ 979 11 | op (ar$op) | pln (6) | shl (q) | 980 +---------------+---------------+---------------+---------------+ 981 12 | thl (x) | Requester's IP Address upper (24 bits) | 982 +---------------------------------------------------------------+ 983 13 | Src. IP lower | Target's IP Address upper (24 bits) | 984 +---------------+-----------------------------------------------+ 985 14 | Tgt. IP lower |Requester's HIPPI Hardware Address octets 0 - 2| 986 +---------------+-----------------------------------------------+ 987 15 | Requester's HIPPI Hardware Address octets 3 - 6 | 988 +-------------------------------+-------------------------------+ 989 16 | Requester's HW Addr oct 7 - 8 | Target's HIPPI HW Addr 0 - 2 | 990 +---------------+---------------+-------------------------------+ 992 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 994 17 | Target's HIPPI Hardware Address octets 2 - 5 | 995 +-----------------------------------------------+---------------+ 996 18 | Target's HIPPI Hardware Address octets 6 - 8 | 997 +-----------------------------------------------+ 999 HIPARP - HIPRARP - InHIPARP Packet 1000 ( using 2 HIPPI-800 addresses ) 1002 +---------------+-----------------------------------------------+ 1003 14 | Tgt. IP lower | Requester's ULA octets 0 - 2 | 1004 +---------------+-------------------------------+---------------+ 1005 15 | Requester's ULA octets 3 - 5 | Tgt ULA oct 0 | 1006 +-----------------------------------------------+---------------+ 1007 16 | Target ULA octets 1 - 4 | 1008 +---------------+-----------------------------------------------+ 1009 17 | Tgt ULA oct 5 | 1010 +---------------+ 1012 HIPARP - HIPRARP - InHIPARP Packet 1013 (bottom half with 2 HIPPI 6400 addresses) 1015 6.3.1 HIPARP_NAK packet format 1017 The HIPARP_NAK packet format is the same as the received 1018 HIPARP_REQUEST packet format with the operation code set to 1019 HIPARP_NAK; i.e. the HIPARP_REQUEST packet data is exactly copied for 1020 transmission with the HIPARP_REQUEST operation code changed to the 1021 HIPARP_NAK value. HIPARP makes use of an additional operation code 1022 for HIPARP_NAK and MUST be implemented. 1024 6.3.2 Combined HIPPI-LE and HIPARP packet addresses 1026 The combined HIPPI-LE/HIPARP packet contains ten addresses, two for 1027 the destination and two for the source of the message, three for the 1028 requester and three for the target: 1030 Destination Switch Address (HIPPI-LE) 1031 Destination ULA (HIPPI_LE) 1033 Source Switch Address (HIPPI-LE) 1034 Source ULA (HIPPI-LE) 1036 Requester's IP Address (HIPARP) 1037 Requester's ULA (HIPARP) 1038 Requester's Switch Address (HIPARP) 1040 Target's IP Address (HIPARP) 1041 Target's ULA (HIPARP) 1043 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1045 Target's Switch Address (HIPARP) 1047 Examples: 1049 The following relations are true for a HIPARP_REQUEST and 1050 InHIPARP_REQUESTs. 1052 LIS without broadcast - Dest SW Addr = HIPARP server SW Addr 1053 (with HIPARP server) Dest ULA = HIPARP server ULA 1054 Source SW Addr = Requester's SW Addr 1055 Source ULA = Requester's ULA 1057 For InHIPARP_REPLYs and HIPARP_REPLYs for instance would be: 1059 LIS without broadcast - Dest SW Addr= Requester's SW Addr 1060 (with HIPARP server) Dest ULA = Requester's ULA 1061 Source SW Addr = HIPARP server SW Addr 1062 Source ULA = HIPARP server ULA 1064 Note that the use of ULAs with HIPPI is not required. In both the 1065 HIPPI-LE header and the HIPARP message, the fields that contain ULAs 1066 SHOULD be set to zero if the ULA is not known. 1068 7 Broadcast and Multicast 1070 HIPPI-SC does not require switches to support broadcast. Broadcast 1071 support has therefore been absent from many HIPPI networks. However, 1072 a centralized HIPARP server architecture solves two of the three 1073 major duties of a broadcast server. 1075 A central entity serving the whole LIS solves the coordination 1076 problem of a distributed approach. The registration requirement 1077 solves the second problem of determining which addresses make up the 1078 set loosely called "everyone". The last duty of a broadcast server is 1079 to replicate an incoming packet and send it to "everyone". 1081 During its registration phase, every node, including the node which 1082 has the same hardware address as the primary address in the HIPRAL 1083 and which is therefore the HIPARP server, discovers if the 1084 underlying medium is capable of broadcast (see section 5.1.1). Should 1085 this not be the case, then it makes sense for the HIPARP server to 1086 emulate broadcast through an IP broadcast emulation server. 1088 A HIPPI IP broadcast server (HIPIBS) is an extension to the HIPARP 1089 server and only makes sense when the LIS does not inherently support 1090 broadcast. The HIBIS is optional and MAY be implemented. 1092 7.1 HIPPI IP Broadcast Emulation Server - HIPIBS 1093 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1095 To emulate broadcast within an LIS, a HIPIBS SHALL use the currently 1096 valid HIPARP table of the HIPARP server as a list of addresses called 1097 the target list. The broadcast server SHALL validate that all 1098 incoming packets have a source address which corresponds to an 1099 address in the target list. Non-valid packets SHALL be dropped and a 1100 warning flag MAY be raised with the system administrator. All valid 1101 packets shall be forwarded to all addresses in the target list. 1103 It is RECOMMENDED that the broadcast server run on the same node as 1104 the HIPARP server since this memo does not define the protocol of 1105 exchanging the valid HIPARP table. 1107 7.2 IP Broadcast Address 1109 HIPPI-SC supports broadcast addressing, defined in section 4.2, 1110 "Reserved Logical Addresses". It is RECOMMENDED to pair the HIPARP 1111 server addresses in the HIPRAL (see section ) with a corresponding 1112 broadcast address. The default broadcast address SHALL be 0xFE1 as 1113 described in HIPPI-SC as being the address used for "All IP protocol 1114 traffic conventionally directed to the IEEE 802.1 broadcast address 1115 as described in RFC-1042". 1117 This memo defines the IP broadcast emulation service in the LIS and 1118 constrains it to consist of a single IP broadcast server. Client- 1119 server interaction is defined by using a single server approach as a 1120 reference model. 1122 This memo recognizes the possibility of future development of 1123 standards and implementations of multiple-IP-broadcast-server models 1124 that will extend the operations defined in this memo in order to 1125 provide a highly reliable broadcast service. 1127 7.3 IP Multicast Address 1129 HIPPI does not directly support IP multicast address services, 1130 therefore there are no mappings available from IP multicast addresses 1131 to HIPPI multicast services. Current IP multicast implementations 1132 (i.e. MBONE and IP tunneling, see [9]) will continue to operate over 1133 HIPPI-based logical IP subnets if all IP multicast addresses are 1134 mapped to the address of the primary broadcast emulation server. 1136 7.4 A Note on Broadcast Emulation Performance 1138 It is obvious that a broadcast emulation service (as defined in 1139 section 7.1) is an inherent performance bottleneck. In an LIS with n 1140 hosts, the upper bound on the bandwidth that such a service can 1141 broadcast is: 1142 (total bandwidth)/(n+1) 1144 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1146 since each packet must first enter the broadcast server, accounting 1147 for the additional 1, and then be sent to all n hosts. The broadcast 1148 server could forward the packet destined to the node on which it 1149 runs, thus internally reducing (n+1) to (n) in a first optimization. 1150 The point is that such a service works for the standard networking 1151 protocols such as RIP, OSPF, NIS, NFS, etc. since they usually 1152 represent a small fraction of the network bandwidth. For all general 1153 purposes, the broadcast emulation server as defined in this memo 1154 allows the HIPPI network to look similar to an Ethernet network to 1155 the higher layers. 1157 It is further obvious that such an emulation cannot be used to 1158 broadcast high bandwidth traffic. For such a solution, hardware 1159 support for true broadcast, implemented in a distributed fashion 1160 inside the individual switches, is required. 1162 8 HIPARP for Scheduled Transfer 1164 This RFC also applies for resolving addresses used with Scheduled 1165 Transfer (ST) over HIPPI-800 instead of IP. This RFC's message types 1166 and algorithms can be used for ST (since ST uses Internet Addresses) 1167 as long as there is also an IP over HIPPI implementation on all the 1168 hosts. 1170 9 Discovery of One's Own Switch Address 1172 This HIPARP specification assumes that each node has prior knowledge 1173 of its own switch address. This may be manually configured, by means 1174 that are outside the scope of this memo. If a broadcast capability 1175 exists, the node may discover its own address automatically when it 1176 starts up, using a protocol defined in HIPPI-LE. 1178 If on the other hand, one can not rely on the underlying hardware to 1179 support broadcast, then a node may discover its own logical address 1180 through the algorithm described in section 9.1. 1182 9.1 Switch Address Discovery 1184 Nodes are NOT REQUIRED to implement this protocol but are encouraged 1185 to do so since it reduces the administrative overhead of systems 1186 administration. 1188 If a node implements this feature it SHALL form a HIPPI-LE message as 1189 defined in HIPPI-LE: containing an AR_S_Request Message Type, and 1190 where the Source_IEEE_Address and Destination_IEEE_Address are set 1191 to the correct ULA for the sender, and the Source_Switch_Address and 1192 Destination_Switch_Address contain zero. 1194 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1196 This self address resolution message uses the same HIPPI-LE message 1197 format as described in HIPPI-SC and HIPPI-LE: the AR_S_Request and 1198 AR_S_Response message type codes and no piggybacked ULP data. The 1199 HIPPI-LE header contents for the request are: 1201 HIPPI-LE Message_Type is = 3, AR_S_Request 1202 HIPPI-LE Destination_Address_Type = 0 (undefined) 1203 HIPPI-LE Destination_Switch_Address = 0 (unknown) 1204 HIPPI-LE Source_Address_Type = 0 (undefined) 1205 HIPPI-LE Source_Switch_Address = 0 (unknown) 1206 HIPPI-LE Destination_IEEE_Address = my ULA 1207 HIPPI-LE Source_IEEE_Address = my ULA 1209 There is no D2 data; the packet contains only the HIPPI-FP header and 1210 D1_Area containing the HIPPI-LE header. 1212 HIPPI-LE leaves the target of such an address outside its scope. This 1213 memo defines that nodes SHALL start with the HIPPI broadcast address 1214 0xFE1 and if no reply is received, SHALL continue with the logical 1215 address of START ( e.g. 0x000) and increment the value by one each 1216 subsequent try. The node SHALL try until reaching 0xFFF or until it 1217 sees its own address resolution request. It is RECOMMENDED to make 1218 the starting address of the previous scan a configurable parameter 1219 for the network since some networks have equipment that does not 1220 gracefully drop HIPPI-LE packets that it cannot decode. HIPPI-LE 1221 section 7.1 HIPPI Address Resolution Overview: 1223 "After a host sends the[se] request[s], two positive outcomes are 1224 possible: 1226 o the host receives its own request, and obtains its own Switch 1227 Address from the CCI passed up from the underlying HIPPI-FP 1228 layer, or 1229 o the host receives an AR_S_Response with the 1230 Destination_Switch_Address filled in. 1232 In the first case the host should not respond to its own request." 1234 Or it receives a broadcast copy of its own message, and learns its 1235 own switch address from the destination address field of the 1236 received I-field. 1238 10 Security 1240 Not all of the security issues relating to ARP over HIPPI are clearly 1241 understood at this time. 1243 There are known security issues relating to host impersonation via 1245 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1247 the address resolution protocols used in the Internet [8]. No 1248 special security mechanisms have been added to the address resolution 1249 mechanism defined here for use with networks using HIPARP. 1251 11 Open Issues 1253 o Synchronization and coordination of multiple HIPARP servers and 1254 multiple broadcast servers are left for further study. 1256 o HIPARP packets are not authenticated. This is a potentially 1257 serious flaw in the overall system by allowing a mechanism by 1258 which corrupt information may be introduced into the server 1259 system. 1261 12 HIPARP Examples 1263 Assume a HIPPI-SC switch is installed with three connected nodes: X, 1264 Y, and a. Each node has a unique hardware address that consists of 1265 Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and 1266 ULAa, respectively). There is a HIPARP server connected to a switch 1267 port that is mapped to the address HWa (SWa, ULAa), this address is 1268 the primary HIPPI hardware address in the HIPRAL (HIPARP Request 1269 Address List). 1271 The HIPARP server's table is empty. Nodes X and Y each know their own 1272 hardware address. Eventually they want to talk to each other; each 1273 knows the other's IP address (from the host database) but neither 1274 knows the other's ULA or Switch Address. Both nodes X and Y have 1275 their interfaces configured DOWN. 1277 Note: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd, 1278 ar$pro, 1279 ar$pln fields are left out from the examples below since they 1280 are constant. As well as ar$shl = ar$thl = 9 since these are 1281 all 1282 HIPPI-800 examples. 1284 12.1 Registration Phase of Client Y on Non-broadcast Hardware 1286 Node Y starts: its HIPARP table entry state for the server: PENDING 1288 1. Node Y initiates its interface and sends an InHIPARP_REQUEST to 1289 the HIPARP server after starting a table entry for the HIPARP 1290 server. 1292 HIPPI-LE Destination_Switch_Address = SWa 1293 HIPPI-LE Source_Switch_Address = SWy 1294 HIPPI-LE Destination_IEEE_Address = ULAa 1296 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1298 HIPPI-LE Source_IEEE_Address = ULAy 1299 HIPARP ar$op = 8 (InHIPARP_request) 1300 HIPARP ar$rpa = IPy 1301 HIPARP ar$tpa = 0 ** 1302 HIPARP ar$rha = SWy ULAy 1303 HIPARP ar$tha = SWa ULAs 1304 ** is what we would like to find out 1306 2. HIPARP server receives Y's InHIPARP_REQUEST, it examines the 1307 source addresses and scans its tables for a match. Since this is 1308 the first time Y connects to this server there is no entry and 1309 one will be created and time stamped with the information from 1310 the InHIPARP_REQUEST. The HIPARP server will then send a 1311 InHIPARP_REPLY including its IP address. 1313 HIPPI-LE Destination_Switch_Address = SWy 1314 HIPPI-LE Source_Switch_Address = SWa 1315 HIPPI-LE Destination_IEEE_Address = ULAy 1316 HIPPI-LE Source_IEEE_Address = ULAs 1317 HIPARP ar$op = 9 (InHIPARP_REPLY) 1318 HIPARP ar$rpa = IPs * 1319 HIPARP ar$tpa = IPy 1320 HIPARP ar$rha = SWa ULAs 1321 HIPARP ar$tha = SWy ULAy 1322 * answer we were looking for 1324 3. Node Y examines the incoming InHIPARP_REPLY, completes its table 1325 entry for the HIPARP server. The client's HIPARP table entry for 1326 the server now passes into the VALID state and is usable for 1327 regular HIPARP traffic. Receiving this reply ensures that the 1328 HIPARP server has properly registered the client. 1330 12.2 Registration Phase of Client Y on Broadcast Capable Hardware 1332 If there is a broadcast capable network then the primary address in 1333 the HIPRAL would be the broadcast address, HWb = SWb, ULAb (likely 1334 0xFE1 and FF.FF.FF.FF.FF.FF). 1336 Node Y starts: its HIPARP table entry state for the primary address 1337 in the HIPRAL: PENDING 1339 1. Node Y initiates its interface and sends an InHIPARP_REQUEST to 1340 the primary address in the HIPRAL, in this example the 1341 broadcast address, after starting a table entry. 1343 HIPPI-LE Destination_Switch_Address = SWb 1344 HIPPI-LE Source_Switch_Address = SWy 1345 HIPPI-LE Destination_IEEE_Address = ULAb 1347 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1349 HIPPI-LE Source_IEEE_Address = ULAy 1350 HIPARP ar$op = 8 (InHIPARP_REQUEST) 1351 HIPARP ar$rpa = IPy 1352 HIPARP ar$tpa = 0 ** 1353 HIPARP ar$rha = SWy ULAy 1354 HIPARP ar$tha = SWb ULAb 1355 ** is what we would like to find out 1357 2. Since the network is a broadcast network, client Y will see an 1358 InHIPARP_REQUEST, it examines the source addresses. Since they 1359 are the same as what Y filled in the InHIPARP_REQUEST, Y can 1360 deduce that it is connected to a broadcast medium. Node Y 1361 completes its table entry for the primary address of the 1362 HIPRAL. This entry will not timeout since it is considered less 1363 than likely for a particular underlying hardware type to loose 1364 its quality of being able to do broadcast and therefore this 1365 mapping will never change. 1367 12.3 Operational Phase (phase II) 1369 The Operational Phase of the HIPARP protocol as specified in this 1370 memo is the same for both possibilities of a broadcast and non- 1371 broadcast capable HIPPI hardware. The primary address in the HIPRAL 1372 for this example section will be HWa: amd IPs for 1373 simplicity reasons. 1375 12.2.1 Standard successful HIPARP_Resolve example 1377 Assume the same process (steps 1-3 of section 10.1) happened for host 1378 X. Then the state of X and Y's tables is: the HIPARP server table 1379 entry is in the VALID state. So lets look at the packet traffic when 1380 X tries to send a packet to Y. Since X doesn't have an entry for Y, 1382 1. node X connects to the primary address of the HIPRAL and sends 1383 a HIPARP_REQUEST for Y's hardware address: 1385 HIPPI-LE Destination_Switch_Address = SWa 1386 HIPPI-LE Source_Switch_Address = SWx 1387 HIPPI-LE Destination_IEEE_Address = ULAa 1388 HIPPI-LE Source_IEEE_Address = ULAx 1389 HIPARP ar$op = 1 (HIPARP_REQUEST) 1390 HIPARP ar$rpa = IPx 1391 HIPARP ar$tpa = IPy 1392 HIPARP ar$rha = SWx ULAx 1393 HIPARP ar$tha = 0 ** 1394 ** is what we would like to find out 1396 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1398 2. The HIPARP server receives the HIPARP request and updates its 1399 entry for X if necessary. It then generates a HIPARP_REPLY with 1400 Y's hardware address information. 1402 HIPPI-LE Destination_Switch_Address = SWx 1403 HIPPI-LE Source_Switch_Address = SWa 1404 HIPPI-LE Destination_IEEE_Address = ULAx 1405 HIPPI-LE Source_IEEE_Address = ULAa 1406 HIPARP ar$op = 2 (HIPARP_Reply) 1407 HIPARP ar$rpa = IPy 1408 HIPARP ar$tpa = IPx 1409 HIPARP ar$rha = SWy ULAy * 1410 HIPARP ar$tha = SWx ULAx 1411 * answer we were looking for 1413 7. Node X connects to node Y and transmits an IP packet with the 1414 following information in the HIPPI-LE header: 1416 HIPPI-LE Destination_Switch_Address = SWy 1417 HIPPI-LE Source_Switch_Address = SWx 1418 HIPPI-LE Destination_IEEE_Address = ULAy 1419 HIPPI-LE Source_IEEE_Address = ULAx 1421 If there had been a broadcast capable HIPPI network, the target nodes 1422 would themselves have received the HIPARP_REQUEST of step 2 above 1423 and responded to them in the same way the HIPARP server did. 1425 12.3.2 Standard non-successful HIPARP_Resolve example 1427 Like in 12.3.1, assume that X and Y are fully registered with the 1428 HIPARP server. Then the state of X and Y's HIPARP server table entry 1429 is: VALID. So 1430 lets look at the packet traffic when X tries to send a packet to 1431 Q. Further assume that interface Q is NOT configured UP, i.e. it is 1432 DOWN. Since X doesn't have an entry for Q, 1434 1. node X connects to the HIPARP server switch address and sends 1435 a HIPARP_REQUEST for Q's hardware address: 1437 HIPPI-LE Destination_Switch_Address = SWa 1438 HIPPI-LE Source_Switch_Address = SWx 1439 HIPPI-LE Destination_IEEE_Address = ULAa 1440 HIPPI-LE Source_IEEE_Address = ULAx 1441 HIPARP ar$op = 1 (HIPARP_REQUEST) 1442 HIPARP ar$rpa = IPx 1443 HIPARP ar$tpa = IPq 1444 HIPARP ar$rha = SWx ULAx 1445 HIPARP ar$tha = 0 ** 1447 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1449 q ** is what we would like to find out 1451 2. The HIPARP server receives the HIPARP request and updates its 1452 entry for X if necessary. It then looks up IPq in its tables 1453 and doesn't find it. The HIPARP server then generates a 1454 HIPARP_NAK reply packet. 1456 HIPPI-LE Destination_Switch_Address = SWx 1457 HIPPI-LE Source_Switch_Address = SWa 1458 HIPPI-LE Destination_IEEE_Address = ULAx 1459 HIPPI-LE Source_IEEE_Address = ULAa 1460 HIPARP ar$op = 10 (HIPARP_NAK) 1461 HIPARP ar$rpa = IPx 1462 HIPARP ar$tpa = IPy 1463 HIPARP ar$rha = SWx ULAx 1464 HIPARP ar$tha = 0 *** 1465 *** No Answer, and notice that the fields do not get swapped, 1466 i.e. the HIPARP message is the same as the HIPARP_REQUEST 1467 except for the operation code. 1469 If there had been a broadcast capable HIPPI network, then there 1470 would not have been any reply. 1472 13 References 1474 [1] ANSI X3.183-1991, High-Performance Parallel Interface - 1475 Mechanical, Electrical and Signaling Protocol Specification; 1476 ISO/IEC 11518-1:1995, High-Performance Parallel Interface - 1477 Part 1: Mechanical, Electrical, and Signalling Protocol 1478 Specification (HIPPI-PH). 1480 [2] ANSI X3.210-1992, High-Performance Parallel Interface - Framing 1481 Protocol; ISO/IEC 11518-2:1995 High-Performance Parallel Interface 1482 - Part 2: Framing Protocol (HIPPI-FP). 1484 [3] ANSI X3.218-1993, High-Performance Parallel Interface - 1485 Encapsulation of of ISO 8802-2 (IEEE Std 802.2) Logical Link 1486 Control Protocol Data Units (802.2 Link Encapsulation); 1487 ISO/IEC 11518-3:1995 High-Performance Parallel Interface - 1488 Part 3: Encapsulation of ISO/IEC 8802-2 Logical link control 1489 protocol data units(HIPPI-LE). 1491 [4] ANSI X3.222-1997, High-Performance Parallel Interface - Physical 1492 Switch Control; ISO/IEC 11518-6:199x High-Performance Parallel 1493 Interface - Part 6: Physical Switch Control (HIPPI-SC). 1495 [5] ANSI X3.300-1997, High-Performance Parallel 1496 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1498 Interface - Serial Specification, ISO/IEC 11518-6:199x 1499 High-Performance Parallel Interface - 1500 Part 8: Serial Specification (HIPPI-Serial) 1502 [6] Braden, R., "Requirements for Internet Hosts -- Communication 1503 Layers", RFC-1122, USC/Information Sciences Institute, October 1504 1989. 1506 [7] Bradely, T., and Brown, C., "Inverse Address Resolution 1507 Protocol", RFC-1293, USC/Information Sciences Institute, January 1508 1992. 1510 [8] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol 1511 Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 1512 32-48, 1989. 1514 [9] Deering, S, "Host Extensions for IP Multicasting", RFC-1112, 1515 USC/Information Sciences Institute, August 1989. 1517 [10] Finlayson, R., Mann, T., Mogul, J., and Theimer, M., "A Reverse 1518 Address Resolution Protocol", RFC-903, Stanford University, June 1519 1984. 1521 [11] IEEE, "IEEE Standards for Local Area Networks: Logical Link 1522 Control", IEEE, New York, New York, 1985. 1524 [12] IEEE, "IEEE Standards for Local Area Networks: Logical Link 1525 Control", IEEE, New York, New York, 1985. 1527 [13] Laubach, Mark., "Classical IP and ARP over ATM", RFC-1577, 1528 Hewlett-Packard Laboratories, January 1994 1530 [14] Mogul, J.C., and Deering, S.E., "Path MTU Discovery", RFC-1191, 1531 Stanford University, November, 1990. 1533 [15] Plummer, D., "An Ethernet Address Resolution Protocol - or - 1534 Converting Network Addresses to 48-bit Ethernet Address for 1535 Transmission on Ethernet Hardware", RFC-826, MIT, November 1982. 1537 [16] Postel, J., "Internet Protocol", STD 5, RFC-791, USC/Information 1538 Sciences Institute, September 1981. 1540 [17] Renwick, J., Nicholson, A., "IP and ARP on HIPPI", RFC-1374, 1541 Cray Research, Inc., October 1992. 1543 [18] Renwick, J., "IP over HIPPI", RFC-2067, NetStar, Inc., January 1544 1997. 1546 INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98 1548 [20] Reynolds, J.K., and Postel, J., "Assigned Numbers", STD 2, RFC- 1549 1340, USC/Information Sciences Institute, July 1992. 1551 [21] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 1552 RFC-1700, USC/Information Sciences Institute, October 1994. 1554 14 Acknowledgments 1556 This memo could not have come into being without the critical review 1557 from Greg Chesson, Carlin Otto, the High performance interconnect 1558 group of Silicon Graphics and the expertise of the ANSI T11.1 Task 1559 Group responsible for the HIPPI standards work. 1561 This memo is based on the second part of [17], written by John 1562 Renwick. ARP [15] written by Dave Plummer and Inverse ARP [7] written 1563 by Terry Bradley and Caralyn Brown provide the fundamental algorithms 1564 of HIPARP as presented in this memo. Further, the HIPARP server is 1565 based on concepts and models presented in [13], written by Mark 1566 Laubach who laid the structural groundwork for the HIPARP server. 1568 15 Author's Address 1570 Jean-Michel Pittet 1571 Silicon Graphics Inc 1572 2011 N. Shoreline Ave 1573 Mountain View, CA 94040 1575 Phone: 650-933-6149 1576 Fax:650-933-3542 1577 EMail: jmp@sgi.com