idnits 2.17.1 draft-pittet-hippiarp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages 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. ** There are 21 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 332 has weird spacing: '...address resol...' == Line 510 has weird spacing: '... to be conne...' == Line 580 has weird spacing: '... needed and...' == Line 751 has weird spacing: '...ing the entry...' == Line 965 has weird spacing: '... 8 bits byte ...' == (8 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 (January 2000) is 8839 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 1037 -- Looks like a reference, but probably isn't: 'FILL' on line 878 -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1374 (ref. '14') (Obsoleted by RFC 2834) ** Obsolete normative reference: RFC 1700 (ref. '16') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '17' Summary: 7 errors (**), 0 flaws (~~), 8 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 July 2000 January 2000 5 ARP and IP Broadcast over HIPPI-800 6 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document specifies a method for resolving IP addresses to ANSI 32 High-Performance Parallel Interface (HIPPI) hardware addresses and 33 for emulating IP broadcast in a logical IP subnet (LIS) as a direct 34 extension of HARP. This memo defines a HARP that will interoperate 35 between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System 36 Network, GSN). 38 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 40 TABLE OF CONTENTS 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 43 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 44 2.1 Changes from RFC-1374 . . . . . . . . . . . . . . . . 4 45 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . 5 46 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 47 3.1 Global Concepts . . . . . . . . . . . . . . . . . . . 5 48 3.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 5 49 4. IP Subnetwork Configuration . . . . . . . . . . . . . . . 7 50 4.1 Background . . . . . . . . . . . . . . . . . . . . . 7 51 4.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 8 52 5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 9 53 5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 10 54 5.1.1 Selecting the authoritative HARP service . . . 10 55 5.1.2 HARP registration phase . . . . . . . . . . . . 11 56 5.1.3 HARP operational phase . . . . . . . . . . . . 12 57 5.2 HARP Client Operational Requirements . . . . . . . . . . 13 58 5.3 Receiving Unknown HARP Messages . . . . . . . . . . . 14 59 5.4 HARP Server Operational Requirements . . . . . . . . 14 60 5.5 HARP and Permanent ARP Table Entries . . . . . . . . 16 61 5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 16 62 6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 17 63 6.1 HIPPI-LE Header of HARP Messages . . . . . . . . . . 17 64 6.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 18 65 6.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 18 66 6.1.3 Diagram . . . . . . . . . . . . . . . . . . . . 19 67 6.2 HIPPI Hardware Address Formats and Requirements . . . 20 68 6.2.1 48-bit Universal LAN MAC Addresses . . . . . . 20 69 6.3 HARP and InHARP Message Formats . . . . . . . . . . . 21 70 6.3.1 Example Message encodings . . . . . . . . . . . 23 71 6.3.2 HARP_NAK message format . . . . . . . . . . . . 24 72 6.3.3 Combined HIPPI-LE and HARP message addresses . 24 73 7. Broadcast and Multicast . . . . . . . . . . . . . . . . . 25 74 7.1 Protocol for an IP Broadcast Emulation Server - PIBES 25 75 7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 26 76 7.3 IP Multicast Address . . . . . . . . . . . . . . . . 26 77 7.4 A Note on Broadcast Emulation Performance . . . . . . 26 78 8. HARP for Scheduled Transfer . . . . . . . . . . . . . . . 27 79 9. Discovery of One's Own Switch Address . . . . . . . . . . 27 80 10. Security . . . . . . . . . . . . . . . . . . . . . . . . 28 81 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 28 82 12. HARP Examples . . . . . . . . . . . . . . . . . . . . . . 28 83 12.1 Registration Phase of Client Y on Non-broadcast HW . 29 84 12.2 Registration Phase of Client Y on Broadcast Hardware 30 85 12.3 Operational Phase (phase II) . . . . . . . . . . . . 30 86 12.3.1 Standard successful HARP_Resolve example . . 30 87 12.3.2 Standard non-successful HARP_Resolve example 31 89 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 91 13. References . . . . . . . . . . . . . . . . . . . . . . . 32 92 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 34 93 15. Author's Address . . . . . . . . . . . . . . . . . . . . 34 95 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 97 1. Introduction 99 The ANSI High-Performance Parallel Interface (HIPPI) is a dual 100 simplex data channel. HIPPI can send and receive data 101 simultaneously at 800 or 1600 megabits per second. Between 1987 and 102 1997, the ANSI X3T11.1 HIPPI working group (now known as NCITS T11.1) 103 Standardized five documents that bear on the use of HIPPI as a 104 network interface. They cover the physical and electrical 105 specification (HIPPI-PH [1]), the framing of a stream of bytes 106 (HIPPI-FP [2]), encapsulation of IEEE 802.2 LLC (HIPPI-LE [3]), the 107 behavior of a physical layer switch (HIPPI-SC [4]) and the physical- 108 level and optical specification (HIPPI-Serial [5]). HIPPI-LE also 109 implies the encapsulation of Internet Protocol[5]. The reader should 110 be familiar with the ANSI HIPPI documents. Approved ANSI NCITS 111 standards are available from ANSI (http://www.ansi.org). The working 112 documents of the T11.1 working group may be obtained from the T11 web 113 page (http://www.t11.org/). 115 HIPPI switches can be used to connect a variety of computers and 116 peripheral equipment for many purposes, but the working group stopped 117 short of describing their use as Local Area Networks. RFC-2067 [15] 118 describes the encapsulation of IP over HIPPI-800. This memo takes up 119 where the working group and RFC-2067 [15] left off and defines 120 address resolution and LIS IP broadcast emulation for HIPPI-800 121 networks. 123 While investigating possible solutions for HARP it became evident 124 that IP broadcast could easily be emulated for both HIPPI-800 and 125 HIPPI-6400 hardware types. This is useful since HIPPI switches are 126 not required to implement broadcast but many standard networking 127 protocols rely on broadcast. This memo therefore further addresses 128 the emulation of LIS IP broadcast as an extension of HARP. 130 2. Scope 132 2.1 Changes from RFC-1374 [14] 134 RFC-2067 obsoletes RFC-1374 but left ARP outside of its scope because 135 there was not enough implementation experience. This memo is an 136 effort to clarify and expand the definition of ARP over HIPPI as 137 found in RFC-1374 such that implementations will be more readily 138 possible, especially considering forward interoperability with 139 HIPPI-6400. 141 The changes from RFC-1374 [14] are: 143 o A new message format to acknowledge the HIPPI hardware address 144 format and to eliminate the requirement of HIPPI-LE ARP for HARP 146 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 148 to function. 150 o Explicit registration phase. 152 o Additional message formats: InHARP requests and replies as 153 well as HARP_NAKs. 155 o Details about the IP subnetwork configuration. 157 o Details about table aging. 159 o IP broadcast emulation. 161 2.2 Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC-2119. 167 3. Definitions 169 3.1 Global concepts used 171 In the following discussion, the terms "requester" and "target" are 172 used to identify the port initiating the address resolution request 173 and the port whose address it wishes to discover, respectively. If 174 not all switches in the LIS support broadcast then there will be a 175 HARP server providing the address resolution service and it will be 176 the source of the reply. If on the other hand all switches support 177 broadcast then the source address of a reply will be the target's 178 target address. 180 Values are decimal unless otherwise noted. Formatting follows IEEE 181 802.1A canonical bit order and and HIPPI-FP bit and byte order. 183 3.2 Glossary 185 Broadcast 187 A distribution mode which transmits a message to all ports. 188 Particularly also the port sending the message. 190 Classical/Conventional 192 Both terms are used to refer to networks such as Ethernet, FDDI, and 193 other 802 LAN types, as distinct from HIPPI-SC LANs. 195 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 197 Destination 199 The HIPPI port that receives data from a HIPPI Source. 201 HARP 203 HARP describes the whole set of HIPPI address resolution encodings 204 and algorithms defined in this memo. HARP is a combination and 205 adaptation of the Internet Address Resolution Protocol (ARP) RFC-826 206 [13] and Inverse ARP (InARP) [7] (see section 5). HARP also describes 207 the HIPPI specific version of ARP [10] (i.e. the protocol and the 208 HIPPI specific encoding). 210 HARP table 212 Each host has a HARP table which contains the IP to hardware address 213 mapping of IP members. 215 HIPPI-Serial 217 An implementation of HIPPI in serial fashion on coaxial cable or 218 optical fiber. (see [5]) 220 HRAL 222 The HARP Request Address List. A list of ULAs to which HARP messages 223 are sent when resolving names to addresses (see section 4.2). 225 Hardware (HW) address 227 The hardware address of a port consisting of an I-Field and an 228 optional ULA (see section 6.2). Note: the term port as used in this 229 document refers to a HIPPI port and is roughly equivalent to the term 230 "interface" as commonly used in other IP documents. 232 Host 234 An entity, usually a computer system, that may have one or more HIPPI 235 ports and which may serve as a client or a HARP server. 237 Port 239 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 241 An entity consisting of one HIPPI Source/Destination dual simplex 242 pair that is connected by parallel or serial HIPPI to a HIPPI-SC 243 switch and that transmits and receives IP datagrams. 245 PIBES 247 The Protocol for Internet Broadcast Emulation Server (see section 7). 249 Switch Address 251 A value used as the address of a port on a HIPPI-SC network. It is 252 transmitted in the I-field. HIPPI-SC switches map Switch Addresses 253 to physical switch port numbers. The switch address is extended with 254 a mode byte to form an I-Field (see [4] and 6.2.2) 256 Source 258 The HIPPI port that generates data to send to a HIPPI Destination. 260 Universal LAN MAC Address (ULA) 262 A 48-bit globally unique address, administered by the IEEE, assigned 263 to each port on an Ethernet, FDDI, 802 network, or HIPPI-SC LAN. 265 4. IP Subnetwork Configuration 267 4.1 Background 269 ARP (address resolution protocol) as defined in [12] was meant to 270 work on the 'local' cable. This definition gives the ARP protocol a 271 local logical IP subnet (LIS) scope. In the LIS scenario, each 272 separate administrative entity configures its hosts and routers 273 within the LIS. Each LIS operates and communicates independently of 274 other LIS's on the same HIPPI network. 276 HARP has LIS scope only and serves all ports in the LIS. 277 Communication to ports located outside of the local LIS is usually 278 provided via an IP router. This router is a HIPPI port attached to 279 the HIPPI network that is configured as a member of one or more 280 LIS's. This configuration MAY result in a number of disjoint LIS's 281 operating over the same HIPPI network. Using this model, ports of 282 different IP subnets SHOULD communicate via an intermediate IP router 283 even though it may be possible to open a direct HIPPI connection 284 between the two IP members over the HIPPI network. This is a 286 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 288 consequence of using IP and choosing to have multiple LIS's on the 289 same HIPPI fabric. 291 By default, the HARP method detailed in section 5 and the classical 292 LIS routing model MUST be available to any IP member client in the 293 LIS. 295 4.2 HIPPI LIS Requirements 297 The requirement for IP members (hosts, routers) operating in a HIPPI 298 LIS configuration is: 300 o All members of the LIS SHALL have the same IP network/subnet 301 address and address mask [6]. 303 The following list identifies the set of HIPPI-specific parameters 304 that MUST be implemented in each IP station connected to the HIPPI 305 network: 307 o HIPPI Hardware Address: 309 The HIPPI hardware address of an individual IP port MUST contain 310 the port's Switch Address (see section 9). The address SHOULD also 311 contain a non-zero ULA address. If there is no ULA then that field 312 MUST be zero. 314 o HARP Request Address List (HRAL): 316 The HRAL is an ordered list of two or more addresses identifying 317 the address resolution service(s). All HARP clients MUST be 318 configured identically, i.e. all ports MUST have the same 319 addresses(es) in the HRAL. 321 The HRAL MUST contain at least two HIPPI HW addresses identifying 322 the individual HARP service(s) that have authoritative 323 responsibility for resolving HARP requests of all IP members 324 located within the LIS. 326 By default the first address MUST be the reserved address for 327 broadcast, i.e. the address for "IP traffic conventionally 328 directed to the IEEE 802.1 broadcast address: 0xFE1" [4]. The ULA 329 for this HARP service entry SHALL be FF:FF:FF:FF:FF:FF. 331 It is REQUIRED that the second address be the address for 332 "Messages pertaining to (the) ... address resolution requests: 333 0xFE0" [4]. The ULA for this HARP server entry is 334 00:00:00:00:00:00. 336 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 338 Therefore, the HRAL entries are sorted in the following order: 339 1st ** : broadcast address (0x07000FE1 FF:FF:FF:FF:FF:FF), 340 2nd ** : official HARP server address (0x07000FE0 00:00:00:00:00:00), 341 3rd & on: any additional HARP server addresses will be sorted in 342 decreasing order of the 12bit destination switch 343 address portion of their I-Field (see section 6.2). 344 ** REQUIRED 346 Within the restrictions mentioned above and in Section 6.2.2, local 347 administration choose address(es) for the additional HARP services 348 which they will put into the HRAL. 350 An example of such a list: 351 1st entry: 0x07000FE1 FF:FF:FF:FF:FF:FF 352 2nd entry: 0x07000FE0 00:00:00:00:00:00 353 3rd entry: 0x07000001 354 ... 356 Manual configuration of the addresses and address lists presented in 357 this section is implementation dependent and beyond the scope of this 358 memo. 360 5. HIPPI Address Resolution Protocol - HARP 362 Address resolution within the HIPPI LIS SHALL make use of the HIPPI 363 Address Resolution Protocol (HARP) and the Inverse HIPPI Address 364 Resolution Protocol (InHARP). HARP provides the same functionality as 365 the Internet Address Resolution Protocol (ARP). HARP is based on ARP 366 which is defined in RFC-826 [13]. Knowing the Internet address, 367 conventional networks use ARP to discover another port's hardware 368 address. HARP presented in this section further specifies the 369 combination of the original protocol definitions to form a coherent 370 address resolution service that is independent of the hardware's 371 broadcast capability. 373 InHARP is based on the original Inverse ARP (InARP) protocol 374 presented in [7]. Knowing its hardware address, InARP is used to 375 discover the other party's Internet address. 377 This memo further REQUIRES the PIBES (see section 7 below) extension 378 to the HARP protocol, guaranteeing broadcast service to upper layer 379 protocols like IP. 381 Internet addresses are assigned independent of ULAs and switch 382 addresses. Before using HARP, each port MUST know its IP and its 383 hardware addresses. The ULA is optional but is RECOMMENDED if 384 bridging to conventional networks is desired. 386 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 388 5.1 HARP Algorithm 390 This section defines the behavior and requirements for HARP 391 implementations on both broadcast and non-broadcast capable HIPPI-SC 392 networks. HARP creates a table in each port which maps the IP address 393 of each port to a hardware address, so that when an application 394 requests a connection to a remote port by its IP address, the 395 hardware address can be determined, a correct HIPPI-LE header can be 396 built, and a connection to the port can be established using the 397 correct Switch Address in the I-field. 399 HARP is a two phase protocol. The first phase is the registration 400 phase and the second phase is the operational phase. In the 401 registration phase the port detects if it is connected to broadcast 402 hardware or not. The InHARP protocol is used in the registration 403 phase. In case of non-broadcast capable hardware, the InHARP 404 Protocol will register and establish a table entry with the server. 405 The operational phase works much like conventional ARP with the 406 exception of the message format. 408 5.1.1 Selecting the authoritative HARP service 410 Within the HIPPI LIS, there SHALL be an authoritative HARP service. 411 At each point in time there is only one authoritative HARP service. 413 To select the authoritative HARP service, each port needs to 414 determine if it is connected to a broadcast network. 416 The port SHALL send an InHARP_REQUEST to the first address in its 417 HRAL (0x07000FE1 FF:FF:FF:FF:FF:FF). If the port sees its own 418 InHARP_REQUEST, then it is connected to a broadcast capable network. 419 In this case, the rest of the HRAL is ignored and the authoritative 420 HARP service is the broadcast entry. 422 If the port is connected to a non-broadcast capable network, then the 423 port SHALL send the InHARP_REQUEST to all of the remaining entries in 424 the HRAL. Every address which sends an InHARP_REPLY is considered to 425 be a responsive HARP server. The authoritative HARP service SHALL be 426 the HARP server which appears first in the HRAL. 428 The sequence of the HRAL is only important for deciding which address 429 will be the authoritative one. On a non-broadcast network, the port 430 is REQUIRED to keep "registered" with all HARP server addresses in 431 the HRAL (NOTE: not the broadcast address since it is not a HARP 432 server address). If for instance the authoritative HARP service is 433 non-responsive, then the port will consider the next address in the 434 HRAL as a candidate for the authoritative address and send an 435 InHARP_REQUEST. 437 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 439 The authoritative HARP server SHOULD be considered non-responsive 440 when it has failed to reply to: (1) one or more registration requests 441 by the client (see section 5.1.2 and 5.2), (2) any two HARP_REQUESTs 442 in the last 120 seconds or (3) if an external agent has detected 443 failure of the authoritative HARP server. The details of such an 444 external agent and its interaction with the HARP client are beyond 445 the scope of this document. Should an authoritative HARP server 446 become non-responsive, then the registration process SHOULD be 447 restarted. Alternative methods for choosing an authoritative HARP 448 service are not prohibited. 450 5.1.2 HARP registration phase 452 HARP clients SHALL initiate the registration phase by sending an 453 InHARP_REQUEST message using the addresses in the HRAL in order. The 454 client SHALL terminate the registration phase and transition into the 455 operational phase, either when it receives its own InHARP_REQUEST or 456 when it receives an InHARP_REPLY from at least one of the HARP 457 servers and when it has determined the authoritative HARP service as 458 described in section 5.1.1. 460 When ports are initiated they send an InHARP_REQUEST to the 461 authoritative address as described in section 5.1.2. The first 462 address to be tried will be the broadcast address "0x07000FE1 463 FF:FF:FF:FF:FF:FF". There are two outcomes: 465 1. The port sees its own InHARP_REQUEST: then the port is connected 466 to a broadcast capable network. The first address becomes and 467 remains the authoritative address for the HARP service. 469 2. The port does not receive its InHARP_REQUEST: then the port is 470 connected to a non-broadcast capable network. 472 In the second case, the port SHALL choose the next address in the 473 HRAL as a candidate for a authoritative address and send an 474 InHARP_REQUEST to that address: (0x07000FE0 00:00:00:00:00:00). 476 o If the port receives its own message, then the port itself is the 477 HARP server and the port is REQUIRED to provide broadcast services 478 using the PIBES (see section 7). 480 o If the port receives an InHARP_REPLY, then it is a HARP client and 481 not a HARP server. 483 In both cases, the current candidate address becomes the 484 authoritative HARP service address. 486 If the client determines it is connected to a non-broadcast capable 488 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 490 network then the client SHALL continue to retry each non-broadcast 491 HARP server address in the HRAL at least once every 5 seconds until 492 one of these two termination criteria are met for each address. 494 InHARP is an application of the InARP protocol for a purpose not 495 originally intended. The purpose is to accomplish registration of 496 port IP address mappings with a HARP server if one exists or detect 497 hardware broadcast capability. 499 If the HIPPI-SC LAN supports broadcast, then the client will see its 500 own InHARP_REQUEST message and SHALL complete the registration phase. 501 The client SHOULD further note that it is connected to a broadcast 502 capable network and use this information for aging the HARP server 503 entry and for IP broadcast emulation as specified in sections 5.4 and 504 5.6 respectively. 506 If the client doesn't see its own InHARP_REQUEST, then it SHALL await 507 an InHARP_REPLY before completing the registration phase. This will 508 also provide the client with the protocol address by which the HARP 509 server is addressable. This will be the case when the client happens 510 to be connected to a non-broadcast capable HIPPI-SC network. 512 5.1.3 HARP operational phase 514 Once a HARP client has completed its registration phase it enters the 515 operational phase. In this phase of the protocol, the HARP client 516 SHALL gain and refresh its own HARP table which contains the IP to HW 517 address mapping of IP members by sending HARP_REQUESTS to the 518 authoritative address in the HRAL and receiving HARP_REPLYs. The 519 client is fully operational during the operational phase. 521 In the operational phase, the client's behavior for requesting HARP 522 resolution is the same for broadcast or non-broadcast networks. 524 The target of an address resolution request updates its address 525 mapping tables with any new information it can find in the request. 526 If it is the target port it SHALL formulate and send a reply message. 527 A port is the target of an address resolution request if at least ONE 528 of the following statements is true of the request: 530 1. The port's IP address is in the target protocol address field 531 (ar$tpa) of the HARP message. 533 2. The port's ULA (if non-zero), is in the ULA part of the Target 534 Hardware Address field (ar$tha) of the message. 536 3. The port's switch address is in the Target Switch Address field 537 of Target Hardware Address field (ar$tha) of the message (see 539 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 541 section 6.2.2). 543 4. The port is a HARP server. 545 NOTE: It is RECOMMENDED that all HARP servers run on a ports which 546 each have a non-zero ULA. 548 5.2 HARP Client Operational Requirements 550 The HARP client is responsible for contacting the HARP server(s) to 551 have its own HARP information registered and to gain and refresh its 552 own HARP entry/information about other IP members. This means, as 553 noted above, that HARP clients MUST be configured with the hardware 554 address of the HARP server(s) in the HRAL. 556 HARP clients MUST: 558 1. When an interface is enabled (e.g. "ifconfig up" with 559 an IP address) or assigned the first or an additional IP address 560 (i.e. an IP alias), the client SHALL initiate the registration 561 phase. 563 2. In the operational phase the client MUST respond to HARP_REQUEST 564 and InHARP_REQUEST messages if it is the target port. If an 565 interface has multiple IP addresses (e.g., IP aliases) then the 566 client MUST cycle through all the IP addresses and generate an 567 InHARP_REPLY for each such address. In that case an 568 InHARP_REQUEST will have multiple replies. (Refer to Section 7, 569 "Protocol Operation" in RFC-1293 [7].) 571 3. React to address resolution reply messages appropriately to build 572 or refresh its own client HARP table entries. All solicited and 573 unsolicited HARP_REPLYs from the authoritative HARP server SHALL 574 be used to update and refresh its own client HARP table entries. 576 Explanation: This allows the HARP server to update the clients 577 when one of server's mappings change, similar to what is 578 accomplished on Ethernet with gratuitous ARP. 580 4. Generate and transmit InHARP_REQUEST messages as needed and 581 process InHARP_REPLY messages appropriately (see section 5.1.2 582 and 5.6). All InHARP_REPLY messages SHALL be used by the client 583 to build or refresh its HARP table entries. (Refer to Section 7, 584 "Protocol Operation" in [7].) 586 If the registration phase showed that the hardware does not support 587 broadcast, then the client MUST refresh its own entry for the HARP 589 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 591 server, created during the registration phase, at least once every 15 592 minutes. This can be accomplished either through the exchange of a 593 HARP request/reply with the HARP server or by repeating step 1. To 594 decrease the redundant network traffic, this timeout SHOULD be reset 595 after each HARP_REQUEST/HARP_REPLY exchange. 597 Explanation: The HARP_REQUEST shows the HARP server that the client 598 is still alive. Receiving a HARP_REPLY indicates to the client that 599 the server must have seen the HARP_REQUEST. 601 If the registration phase shows that the underlying network supports 602 broadcast, then periodic InHARP_REQUEST/InHARP_REPLY operations of 603 step 4 are NOT REQUIRED. 605 5.3 Receiving Unknown HARP Messages 607 If a HARP client receives a HARP message with an operation code 608 (ar$op) that it does not support, it MUST gracefully discard the 609 message and continue normal operation. A HARP client is NOT REQUIRED 610 to return any message to the sender of the undefined message. 612 5.4 HARP Server Operational Requirements 614 A HARP server MUST accept HIPPI connections from other HIPPI ports. 615 The HARP server expects an InHARP_REQUEST as the first message from 616 the client. A server examines the IP source address, the hardware 617 source address of the InHARP_REQUEST and adds or updates its HARP 618 table entry as well as the 619 time stamp. 621 A HARP server SHALL reply to HARP_REQUESTs and InHARP_REQUESTs based 622 on the information which it has in its HARP table. The HARP server 623 SHALL reply with a HARP_REPLY or a InHARP_REPLY, if it has the 624 requested information in its tables; otherwise it SHALL reply with a 625 HARP_NAK. The HARP server replies SHALL contain the hardware type and 626 corresponding format of the request (see also section 6). 628 The following table shows all possible source address combinations on 629 an incoming message and the actions to be taken. "linked" indicates 630 that an existing "IP entry" is linked to a "hardware entry". It is 631 possible to have an existing "IP entry" and to have an existing 632 "hardware entry" but neither is linked to the other. 634 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 636 +---+----------+----------+------------+---------------------+ 637 | # | IP entry | HW entry | misc | Action | 638 +---+----------+----------+------------+---------------------+ 639 | 1 | exists | exists | linked | * | 640 | 2 | exists | exists | not linked | *, a, b, e, f | 641 | 3 | exists | new | not linked | *, a, b, d, e, f | 642 | 4 | new | exists | not linked | *, c, e, f | 643 | 5 | new | new | not linked | *, c, d, e, f | 644 +---+----------+----------+------------+---------------------+ 645 Actions: 646 *: update timeout value 647 a: break the existing IP -> hardware (HW) - old link 648 b: delete HW(old) -> IP link and decrement HW(old) refcount, if 649 refcount = 0, delete HW(old) 650 c: create new IP entry 651 d: create new HW entry 652 e: add new IP -> HW link to IP entry 653 f: add new HW -> IP link to HW entry 655 Examples of when this could happen (Numbers match lines in above 656 table): 658 1: supplemental message 660 Just update timer. 662 2: move an IP alias to an existing interface 664 If the IP source address of the InHARP_REQUEST duplicates a table 665 entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST 666 hardware source address matches a hardware address entry (e.g. HWb 667 <-> IPb), but they are not linked together, then: 668 - HWa entry needs to have its reference to the current IPa address 669 removed. 670 - HWb needs to have a new reference to IPa added 671 - IPa needs to be linked to HWb 673 3: move IP address to a new interface 675 If the InHARP_REQUEST requester's IP source address duplicates a 676 table entry IP address and the InHARP_REQUEST hardware source 677 address does not match the table entry hardware address, then a 678 new HW entry SHALL be created. The requestor's IP address SHALL be 679 moved from the original HW entry to the new one (see above). 681 4: add IP alias to table 683 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 685 If the InHARP_REQUEST requester's hardware source address 686 duplicates a hardware source address entry, but there is no IP 687 entry matching the received IP address, then the IP address SHALL 688 be added to the hardware entries previous IP address(es). (E.g. 689 adding an IP alias). 691 5: fresh entry, add it 693 Standard case, create both entries and link them. 695 A server MUST update the HARP table entry's timeout for each 696 HARP_REQUEST. Explanation: if the client is sending HARP requests to 697 the server, then the server SHOULD note that the client is still 698 "alive" by updating the timeout on the client's HARP table entry. 700 A HARP server SHOULD use the PIBES (see section 7) to send out 701 HARP_REPLYs to all hardware addresses in its table when the HARP 702 server table changes mappings. This feature decreases the time of 703 stale entries in the clients. 705 If there are multiple addresses in the HRAL, then a server needs to 706 act as a client to the other servers. 708 5.5 HARP and Permanent ARP Table Entries 710 An IP station MUST have a mechanism (e.g. manual configuration) for 711 determining what permanent entries it has. The details of the 712 mechanism are beyond the scope of this memo. The permanent entries 713 allow interoperability with legacy HIPPI adapters which do not yet 714 implement dynamic HARP and use a table-based static ARP. Permanent 715 entries are not aged. 717 The HARP server SHOULD use the static entries to resolve incoming 718 HARP_REQUESTs from the clients. This feature eliminates the need for 719 maintaining a static HARP table on the client ports. 721 5.6 HARP Table Aging 723 HARP table aging MUST be supported since IP addresses, especially IP 724 aliases and also interfaces (with their ULA), are likely to move. 725 When so doing the mapping in the clients own HARP table/cache becomes 726 invalid and stale. 728 o When a client's HARP table entry ages beyond 15 minutes, a HARP 729 client MUST invalidate the table entry. 731 o When a server's HARP table entry ages beyond 20 minutes, the HARP 732 server MUST delete the table entry. 734 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 736 NOTE: the client SHOULD revalidate a HARP table entry before it ages, 737 thus restarting the aging time when the table entry is successfully 738 revalidated. The client MAY continue sending traffic to the port 739 referred to by this entry while revalidation is in progress, as long 740 as the table entry has not aged. The client MUST revalidate an aged 741 entry prior to transmitting any non-address-resolution traffic to the 742 port referred to by this entry. 744 The client revalidates the entry by querying the HARP server with a 745 HARP_REQUEST. If a valid reply is received (e.g. HARP_REPLY), the 746 entry is updated. If the address resolution service cannot resolve 747 the entry (e.g. HARP_NAK, "host not found"), the associated table 748 entry is removed. If the address resolution service is not available 749 (i.e. "server failure") the client MUST attempt to revalidate the 750 entry by transmitting an InHARP_REQUEST to the hardware address of 751 the entry in question and updating the entry on receipt of an 752 InHARP_REPLY. If the InHARP_REQUEST attempt fails to return an 753 InHARP_REPLY, the associated table entry is removed. 755 6. HARP Message Encoding 757 The HARP Message is encapsulated over HIPPI-FP and HIPPI-LE headers. 758 The HARP FP header values are to be set as defined in RFC-2067 "IP 759 over HIPPI" [15]. The following sections detail the HIPPI-LE field 760 contents and HARP message structure and contents. In a broadcast 761 capable network the client MAY also support Type 1 and 6, Ethernet 762 and IEEE 802 ARP packet formats. 764 6.1 HIPPI-LE Header of HARP Messages 766 The HIPPI message format for Internet datagrams shall conform to the 767 HIPPI-FP [2] and HIPPI-LE [3] standards. The length of a HIPPI 768 message, including trailing fill, shall be a multiple of eight bytes 769 as required by HIPPI-LE. The HIPPI-LE header fields of HARP and 770 InHARP requests and replies SHALL be: 772 FC (3 bits) SHALL contain zero. 774 Double-wide SHOULD be set according to HIPPI-LE [3]. This memo does 775 NOT address the implications on HARP when this bit is set to 1 776 indicating the possibility of a port being able to accept 64-bit 777 HIPPI connections. 779 Message_Type SHALL contain 0 to indicate a data message. HARP 780 messages are identified using the Ethertype and the message type in 781 the ar$op field of the HARP message. 783 Destination_Switch_Address, SHALL be the Switch Address of the 785 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 787 destination port. 789 Destination_IEEE_Address SHALL be the ULA of the destination port, if 790 known, otherwise zero. 792 Destination_Address_Type SHALL be 2, a 12-bit logical address. The 793 behavior with type = 1, source routing, is NOT defined in this 794 specification. 796 Source_Switch_Address in requests SHALL be the sender's Switch 797 Address. 799 Source_IEEE_Address SHALL be the sender's ULA if known, otherwise 800 zero. 802 Source_Address_Type SHALL be 2, a 12-bit logical address. The 803 behavior with type = 1, source routing, is NOT defined in this 804 specification. 806 6.1.1 IEEE 802.2 LLC 808 The IEEE 802.2 LLC Header SHALL begin in the first byte of the 809 HIPPI-FP D2_Area. 811 The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 bytes) 812 indicating the presence of a SNAP header. 814 6.1.2 SNAP 816 The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes) 817 indicating that the following two-bytes is an Ethertype. 819 The Ethertype value SHALL be set as defined in Assigned Numbers [16]: 820 InHARP = InARP = HARP = ARP = 2054 = 0x0806. 822 The total size of the LLC/SNAP header is fixed at 8-bytes. 824 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 826 6.1.3 HIPPI-LE header Diagram 828 HIPPI-LE header for HARP/InHARP PDUs: 830 31 28 23 21 15 10 7 2 0 831 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 832 0 | 04 = IP ULP |1|0| 000 | 03 | 0 | 833 +---------------+-+-+---------------------+---------------+-----+ 834 1 | n + 8 | 835 +-----+-+-------+-----------------------+-----------------------+ 836 2 |[LA] |W|M_Type | 000 | Dest. Switch Addr | 837 +-----+-+-------+-----------------------+-----------------------+ 838 3 | D_A_T | S_A_T | 000 | Source Switch Addr | 839 +-------+-------+---------------+-------+-----------------------+ 840 4 | 00 00 | | 841 +-------------------------------+ | 842 5 | Destination ULA | 843 +-------------------------------+-------------------------------+ 844 6 | [LA] | | 845 +-------------------------------+ | 846 7 | Source ULA | 847 +===============+===============+===============+===============+ 848 8 | AA | AA | 03 | 00 | 849 +---------------+---------------+---------------+---------------+ 850 9 | 00 | 00 | Ethertype (2054) | 851 +---------------+---------------+-------------------------------+ 852 10 |Message byte 0 |Message byte 1 |Message byte 2 | . . . | 853 +---------------+---------------+---------------+--- | 854 | . . . | 855 + ------------+---------------+---------------+---------------+ 856 | . . . | byte (n-2) | byte (n-1) | FILL | 857 +---------------+---------------+---------------+---------------+ 858 N-1| FILL | FILL | FILL | FILL | 859 +---------------+---------------+---------------+---------------+ 860 HIPPI Message Format 862 Words 0-1: HIPPI-FP Header 863 Words 2-7: D1_Area (HIPPI-LE Header) 864 Words 8-9: D2_Area (IEEE 802.2 LLC/SNAP) 865 Words 10-(N-1): D2_Area (HARP message) 866 (n+8) is the nb of bytes in the HARP message, incl. LLC/SNAP. 867 +====+ denotes the boundary between D1_Area and D2_Area. 868 [LA] fields are zero unless used otherwise locally. 869 Abbreviations: 870 "W" = Double_Wide field SHALL be 0 871 "M_Type" = Message_Type field SHALL be set according to 872 HIPPI-LE 873 "D_A_T" = Destination_Address_Type SHALL be 2 875 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 877 "S_A_T" = Source_Address_Type SHALL be 2 878 [FILL] bytes complete the HIPPI message to an even 879 number of 32 bit words. The number of fill bytes 880 is not counted in the data length. 882 6.2 HIPPI Hardware Address Formats and Requirements 884 For HIPPI-800, the Hardware Address is a 10-byte unit that SHALL 885 contain the Switch Address AND the ULA. The format of a hardware 886 address is: 888 31 23 15 7 0 889 +---------------+---------------+-------+-------+---------------+ 890 | Mode Byte | 00 | 0 | X | XX | 891 +---------------+---------------+-------+-------+---------------+ 892 | ULA byte 0 | ULA byte 1 | ULA byte 2 | ULA byte 3 | 893 +---------------+---------------+---------------+---------------+ 894 | ULA byte 4 | ULA byte 5 | 895 +---------------+---------------+ 897 Where "XXX" is the 12 bit HIPPI logical address defined in HIPPI-SC 898 [4]. Details on ULA see next section. 900 Two switch addresses are considered to be the same when they have the 901 same 12 bit destination HIPPI logical address. 903 NOTE: In the case of HIPPI-6400, the hardware address is ONLY the 6- 904 byte ULA. Therefore the length of the hardware address clearly 905 defines which version of HIPPI is being used. 907 6.2.1 48-bit Universal LAN MAC Addresses 909 IEEE Standard 802.1A [11] specifies the Universal LAN MAC Address 910 format. The globally unique part of the 48-bit space is administered 911 by the IEEE. Each port on a HIPPI-SC LAN SHOULD be assigned a ULA. 912 Multiple ULAs may be used if a port contains more than one IEEE 802.2 913 LLC protocol entity. 915 The format of the HIPPI hardware address within its HARP message 916 follows IEEE 802.1A canonical bit order and HIPPI-FP bit and byte 917 order. For example the requester's ULA part of the HIPPI hardware 918 address would decompose to: 920 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 922 31 23 15 7 0 923 +---------------+---------------+---------------+---------------+ 924 |ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 | 925 +---------------+---------------+---------------+---------------+ 926 | ULA byte 4 | ULA byte 5 | 927 +---------------+---------------+ 929 Universal LAN MAC Address Format 931 L (U/L bit) = 1 for Locally administered addresses, 932 0 for Universal. 933 G (I/G bit) = 1 for Group addresses, 934 0 for Individual. 936 The use of ULAs is OPTIONAL, but RECOMMENDED. The use of ULAs is 937 REQUIRED if a port wishes to interoperate with a conventional 938 network. 940 ULAs may also be used by bridging devices that replace HIPPI hardware 941 headers with the MAC headers of other LANs. 943 6.3 HARP and InHARP Message Formats 945 The HARP protocols use the HIPARP hardware type (ar$hrd) [16], 946 protocol type (ar$pro), and operation code (ar$op) data formats as 947 the ARP, and InARP protocols [15,7]. In addition, HARP makes use of 948 an additional operation code for ARP_NAK introduced with [12]. The 949 remainder of the HARP/InHARP message format is different than the 950 ARP/InARP message format defined in [15,7,10] and it is also 951 different from the format defined in the first "IP and ARP on HIPPI" 952 RFC-1374 [14]. 954 HARP messages SHALL be transmitted with the HIPARP hardware type code 955 of 28 (decimal). Furthermore, HARP messages SHALL be accepted if 956 received with hardware type codes of either 28, 1 or 6 (decimal). 958 The HARP message has several fields that have the following format 959 and values: 961 Data sizes and field meaning: 962 ar$hrd 16 bits Hardware type 963 ar$pro 16 bits Protocol type of the protocol fields below 964 ar$op 16 bits Operation code (request, reply, or NAK) 965 ar$pln 8 bits byte length of each protocol address 966 ar$rhl 8 bits requester's HIPPI hardware address length (q) 967 ar$thl 8 bits target's HIPPI hardware address length (x) 968 ar$rpa 32 bits requester's protocol address 970 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 972 ar$tpa 32 bits target's protocol address 973 ar$rha qbytes requester's HIPPI Hardware address 974 ar$tha xbytes target's HIPPI Hardware address 976 Where : 977 ar$hrd - SHALL contain 28. (HIPARP) 979 ar$pro - SHALL contain the IP protocol code 2048 (decimal). 981 ar$op - SHALL contain the operational value (decimal): 982 1 for HARP_REQUESTs 983 2 for HARP_REPLYs 984 8 for InHARP_REQUESTs 985 9 for InHARP_REPLYs 986 10 for HARP_NAK 988 ar$pln - SHALL contain 4. 990 ar$rln - SHALL contain 10 IF this is a HIPPI-800 HW address 991 ELSE, for HIPPI-6400, it SHALL contain 6. 993 ar$thl - SHALL contain 10 IF this is a HIPPI-800 HW address 994 ELSE, for HIPPI-6400, it SHALL contain 6. 996 ar$rha - in requests and NAKs it SHALL contain the requester's 997 HW address. In replies it SHALL contain the target 998 port's HW address. 1000 ar$rpa - in requests and NAKs it SHALL contain the requester's IP 1001 address if known, otherwise zero. 1002 In other replies it SHALL contain the target 1003 port's IP address. 1005 ar$tha - in requests and NAKs it SHALL contain the target's 1006 HW address if known, otherwise zero. 1007 In other replies it SHALL contain the requester's 1008 HW addressA. 1010 ar$tpa - in requests and NAKs it SHALL contain the 1011 target's IP address if known, otherwise zero. 1012 In other replies it SHALL contain the requester's 1013 IP address. 1015 The format of the six bytes of the ULA SHALL be the same as required 1016 in the HIPPI-LE header (see section 6.2), except for the alignment of 1017 the ULAs with respect to the 32-bit HIPPI word, which is different 1018 between ARP and HIPPI-LE. No bit reversal is necessary as is 1019 required with FDDI. 1021 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1023 31 28 23 21 15 10 7 2 0 1024 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 1025 0 | 04 |1|0| 000 | 03 | 0 | 1026 +---------------+-+-+---------------------+---------------+-----+ 1027 1 | 45 | 1028 +-----+-+-------+-----------------------+-----------------------+ 1029 2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr | 1030 +-----+-+-------+-----------------------+-----------------------+ 1031 3 | 2 | 2 | 000 | Source Switch Addr | 1032 +---------------+---------------+-------+-----------------------+ 1033 4 | 00 00 | | 1034 +-------------------------------+ | 1035 5 | Destination ULA | 1036 +-------------------------------+-------------------------------+ 1037 6 | [LA] | | 1038 +-------------------------------+ | 1039 7 | Source ULA | 1040 +===============+===============+===============+===============+ 1041 8 | AA | AA | 03 | 00 | 1042 +---------------+---------------+---------------+---------------+ 1043 9 | 00 | 00 | Ethertype (2054) | 1044 +---------------+---------------+-------------------------------+ 1045 10 | hrd (28) | pro (2048) | 1046 +---------------+---------------+---------------+---------------+ 1047 11 | op (ar$op) | pln (6) | rhl (q) | 1048 +---------------+---------------+---------------+---------------+ 1049 12 | thl = (x) | Requester IP Address upper (24 bits) | 1050 +---------------------------------------------------------------+ 1051 13 | Req. IP lower | Target IP Address upper (24 bits) | 1052 +---------------+-----------------------------------------------+ 1053 14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2 | 1054 +---------------+-----------------------------------------------+ 1055 15 | Requester HIPPI Hardware Address bytes 3 - 6 | 1056 +-----------------------------------------------+---------------+ 1057 16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 | 1058 +---------------+---------------+---------------+---------------+ 1059 17 | Target HIPPI Hardware Address bytes 1 - 4 | 1060 +---------------------------------------------------------------+ 1061 18 | Target HIPPI Hardware Address bytes 5 - 8 | 1062 +---------------+---------------+---------------+---------------+ 1063 19 |Tgt HW byte 9-x| FILL | FILL | FILL | 1064 +---------------+---------------+---------------+---------------+ 1065 HARP - InHARP Message 1067 6.3.1 Example Message encodings: 1069 HARP_REQUEST message 1070 HARP ar$op = 1 (HARP_REQUEST) 1072 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1074 HARP ar$rpa = IPy HARP ar$tpa = IPa 1075 HARP ar$rha = SWy ULAy HARP ar$tha = 0 ** 1076 ** is what we would like to find out 1078 HARP_REPLY message format 1079 HARP ar$op = 2 (HARP_REPLY) 1080 HARP ar$rpa = IPa HARP ar$tpa = IPy 1081 HARP ar$rha = SWa ULAa * HARP ar$tha = SWy ULAy 1082 * answer we were looking for 1084 InHARP_REQUEST message format 1085 HARP ar$op = 8 (InHARP_REQUEST) 1086 HARP ar$rpa = IPy HARP ar$tpa = 0 ** 1087 HARP ar$rha = SWy ULAy HARP ar$tha = SWa ULAa 1088 ** is what we would like to find out 1090 InHARP_REPLY message format 1091 HARP ar$op = 9 (InHARP_REPLY) 1092 HARP ar$rpa = IPs * HARP ar$tpa = IPy 1093 HARP ar$rha = SWa ULAa HARP ar$tha = SWy ULAy 1094 * answer we were looking for 1096 6.3.2 HARP_NAK message format 1098 The HARP_NAK message format is the same as the received HARP_REQUEST 1099 message format with the operation code set to HARP_NAK; i.e. the 1100 HARP_REQUEST message data is copied byte for byte for transmission 1101 with the HARP_REQUEST operation code changed to the HARP_NAK value. 1102 HARP makes use of an additional operation code for HARP_NAK. Hence, 1103 HARP_NAK MUST be implemented. 1105 6.3.3 Combined HIPPI-LE and HARP message addresses 1107 The combined HIPPI-LE/HARP message contains ten addresses, two for 1108 the destination and two for the source of the message, three for the 1109 requester and three for the target: 1111 Destination Switch Address (HIPPI-LE) 1112 Destination ULA (HIPPI_LE) 1114 Source Switch Address (HIPPI-LE) 1115 Source ULA (HIPPI-LE) 1117 Requester IP Address (HARP) 1118 Requester ULA (HARP) 1119 Requester Switch Address (HARP) 1121 Target IP Address (HARP) 1123 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1125 Target ULA (HARP) 1126 Target Switch Address (HARP) 1128 Examples: 1130 The following relations are true for a HARP_REQUEST and 1131 InHARP_REQUESTs. 1133 LIS without broadcast - Dest SW Addr = HARP server SW Addr 1134 (with HARP server) Dest ULA = HARP server ULA 1135 Source SW Addr = Requester's SW Addr 1136 Source ULA = Requester's ULA 1138 7 Broadcast and Multicast 1140 HIPPI-SC does not require switches to support broadcast. Broadcast 1141 support has therefore been absent from many HIPPI networks. 1143 During its registration phase, every port, including HARP server(s), 1144 discover if the underlying medium is capable of broadcast (see 1145 section 5.1.2). Should this not be the case, then the HARP server(s) MUST 1146 emulate broadcast through an IP broadcast emulation server. 1148 A HIPPI IP broadcast server (PIBES) is an extension to the HARP 1149 server and only makes sense when the LIS does not inherently support 1150 broadcast. The PIBES allows common upper layer networking protocols 1151 (RIP, TCP, UDP, etc.) to access IP 1152 LIS broadcast. 1154 7.1 Protocol for an IP Broadcast Emulation Server - PIBES 1156 To emulate broadcast within an LIS, a PIBES SHALL use 1157 the currently valid HARP table of the HARP server as a list of 1158 addresses called the target list. The broadcast server SHALL 1159 validate that all incoming messages have a source address which 1160 corresponds to an address in the target list. Only messages addressed to 1161 the IP LIS broadcast addresses, multicast address or 255.255.255.255 1162 are considered valid messages for broadcasting. Invalid messages MUST 1163 be dropped. All valid incoming messages shall be forwarded to all 1164 addresses in the target list. 1166 It is RECOMMENDED that the broadcast server run on the same port as 1167 the HARP server since this memo does not define the protocol for 1168 exchanging the valid HARP table. The default address to use for 1170 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1172 the broadcast address is the operational HARP server address. 1174 7.2 IP Broadcast Address 1176 This memo only defines IP broadcast. It is independent of the 1177 underlying hardware addressing and broadcast capabilities. Any port can 1178 differentiate between IP traffic directed to itself and a broadcast 1179 message sent to it by looking at the IP address. All IP broadcast 1180 messages SHALL use the IP LIS broadcast address or. 1182 It is RECOMMENDED that the PIBES run on the same port as the HARP 1183 server. In that case, the PIBES SHALL use the same address as the HARP 1184 server. 1186 7.3 IP Multicast Address 1188 HIPPI does not directly support multicast address, therefore there are 1189 no mappings available from IP multicast addresses to HIPPI multicast 1190 services. Current IP multicast implementations (i.e. MBONE and IP 1191 tunneling, see [9]) will continue to operate over HIPPI-based logical 1192 IP subnets if all IP multicast packets are sent using the same 1193 algorithm as if the packet were being sent to 255.255.255.255. 1195 7.4 A Note on Broadcast Emulation Performance 1197 It is obvious that a broadcast emulation service (as defined in 1198 section 7.1) has an inherent performance limit. In an LIS 1199 with n ports, the upper bound on the bandwidth that such a service can 1200 broadcast is: 1201 (total bandwidth)/(n+1) 1203 since each message must first enter the broadcast server, accounting 1204 for the additional 1, and then be sent to all n ports. The 1205 broadcast server could forward the message destined to the port on 1206 which it runs internally, thus reducing (n+1) to (n) in a first 1207 optimization. 1209 This service is adequate for the standard networking protocols such as 1210 RIP, OSPF, NIS, etc. since they usually use a small fraction of 1211 the network bandwidth for broadcast. For these purposes, the 1212 broadcast emulation server as defined in this memo allows the HIPPI 1213 network to look similar to an Ethernet network to the higher layers. 1215 It is further obvious that such an emulation cannot be used to 1216 broadcast high bandwidth traffic. For such a solution, hardware 1217 support for true broadcast is required. 1219 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1221 8 HARP for Scheduled Transfer [17] 1223 This RFC also applies for resolving addresses used with Scheduled 1224 Transfer (ST) over HIPPI-800 instead of IP. This RFC's message 1225 types and algorithms can be used for ST (since ST uses Internet 1226 Addresses) as long as there is also an IP over HIPPI implementation 1227 on all of the ports. 1229 9 Discovery of One's Own Switch Address 1231 This HARP specification assumes that each port has prior knowledge 1232 of its own hardware address. This address may be manually configured, 1233 by means outside the scope of this memo or a port may discover its own 1234 logical address through the algorithm described below. 1236 Ports are NOT REQUIRED to implement this switch address discovery protocol 1237 but are encouraged to do so since it reduces the administrative overhead. 1238 The algorithm presented in this section is based on John Renwick's work 1239 as detailed in RFC-1374 [14]. The concept of the discovery process is 1240 to scan all possible switch addresses. The messages that are received 1241 will be the ones containing one of our switch addresses. 1243 If a port implements this algorithm it SHALL form a HIPPI-LE message 1244 as defined in HIPPI-LE: containing an Self_Address_Resolution_Request 1245 (see [3]) PDU Type, a Source_IEEE_Address and Destination_IEEE_Address 1246 (set to the correct ULA for the sender), and the Source_Switch_Address 1247 and Destination_Switch_Address. 1249 This self address resolution message uses the same HIPPI-LE message 1250 format as described in HIPPI-SC and HIPPI-LE: the Self Address 1251 Resolution Request PDU and Self Address Resolution Response PDU type 1252 codes and no piggybacked ULP data. The HIPPI-LE header contents for 1253 the request are: 1255 HIPPI-LE Message_Type is = 3, Self Addr. Resolution Request 1256 HIPPI-LE Destination_Address_Type = 0 (undefined) 1257 HIPPI-LE Destination_Switch_Address = X (X element scan range) 1258 HIPPI-LE Source_Address_Type = 0 (undefined) 1259 HIPPI-LE Source_Switch_Address = 0 (unknown) 1260 HIPPI-LE Destination_IEEE_Address = 0 1261 HIPPI-LE Source_IEEE_Address = my ULA 1263 There is no D2 data; the message contains only the HIPPI-FP header 1264 and D1_Area with the HIPPI-LE header. 1266 Ports SHALL start the scan with a configurable logical address 1267 (default 0x000) and increment the value for by one for each 1268 subsequent try. The port SHALL continue until it sees its own self 1270 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1272 address resolution request or it has reached the end, which may be 1273 another configurable value (default 0xFFF). It is RECOMMENDED that 1274 the range of addresses to scan be configurable since some networks 1275 have equipment that does not gracefully handle HIPPI-LE messages. 1277 After a port sends the[se] request[s], two positive outcomes are 1278 possible: 1280 o the port receives its own request(s), and obtains one of its own 1281 Switch Address, or 1283 o the port receives an AR_S_Response with the 1284 Destination_Switch_Address filled in. 1286 10 Security 1288 HARP messages are not authenticated which is a potentially flaw that 1289 could allow corrupt information to be introduced into the server 1290 system. 1292 There are other known security issues relating to port impersonation 1293 via the address resolution protocols used in the Internet [8]. No 1294 special security mechanisms have been added to the address resolution 1295 mechanism defined here for use with networks using HARP. 1297 Not all of the security issues relating to ARP over HIPPI are clearly 1298 understood at this time. However, given the security hole ARP allows, 1299 other concerns are probably minor. 1301 11 Open Issues 1303 Synchronization and coordination of multiple HARP servers and 1304 multiple broadcast servers are left for further study. 1306 12 HARP Examples 1308 Assume a HIPPI-SC switch is installed with three connected ports: x, 1309 y, and a. Each port has a unique hardware address that consists of 1310 Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and 1311 ULAa, respectively). There is a HARP server connected to a switch 1312 port that is mapped to the address HWa (SWa, ULAa), this address is 1313 the authoritative HIPPI hardware address in the HRAL (HARP Request 1314 Address List). 1316 The HARP server's table is empty. Ports X and Y each know their own 1318 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1320 hardware address. Eventually they want to talk to each other; each 1321 knows the other's IP address (from the port database) but neither 1322 knows the other's ULA or Switch Address. Both ports X and Y have 1323 their interfaces configured DOWN. 1325 NOTE: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd, 1326 ar$pro, ar$pln fields are left out from the examples below 1327 since they are constant. Likewise, ar$rhl = ar$thl = 9 1328 are omitted since these are all HIPPI-800 examples. 1330 12.1 Registration Phase of Client Y on Non-broadcast Hardware 1332 Port Y starts: its HARP table entry state for the server: PENDING 1334 1. Port Y initiates its interface and sends an InHARP_REQUEST to 1335 HWa after starting a table entry for HWa. 1337 HIPPI-LE Destination_Switch_Address = SWa 1338 HIPPI-LE Source_Switch_Address = SWy 1339 HIPPI-LE Destination_IEEE_Address = ULAa 1340 HIPPI-LE Source_IEEE_Address = ULAy 1341 HARP ar$op = 8 (InHARP_REQUEST) 1342 HARP ar$rpa = IPy 1343 HARP ar$tpa = 0 ** 1344 HARP ar$rha = SWy ULAy 1345 HARP ar$tha = SWa ULAa 1346 ** is what we would like to find out 1348 2. HARP server receives Y's InHARP_REQUEST, it examines the 1349 source addresses and scans its tables for a match. Since this is 1350 the first time Y connects to this server there is no entry and 1351 one will be created and time stamped with the information from 1352 the InHARP_REQUEST. The HARP server will then send a 1353 InHARP_REPLY including its IP address. 1355 HIPPI-LE Destination_Switch_Address = SWy 1356 HIPPI-LE Source_Switch_Address = SWa 1357 HIPPI-LE Destination_IEEE_Address = ULAy 1358 HIPPI-LE Source_IEEE_Address = ULAa 1359 HARP ar$op = 9 (InHARP_REPLY) 1360 HARP ar$rpa = IPs * 1361 HARP ar$tpa = IPy 1362 HARP ar$rha = SWa ULAa 1363 HARP ar$tha = SWy ULAy 1364 * answer we were looking for 1366 3. Port Y examines the incoming InHARP_REPLY, completes its table 1367 entry for the HARP server. The client's HARP table entry for 1369 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1371 the server now passes into the VALID state and is usable for 1372 regular HARP traffic. Receiving this reply ensures that the 1373 HARP server has properly registered the client. 1375 12.2 Registration Phase of Client Y on Broadcast Capable Hardware 1377 If there is a broadcast capable network then the authoritative address in 1378 the HRAL would be mapped to the broadcast address, HWb = SWb, ULAb 1379 (likely 0xFE1 and FF:FF:FF:FF:FF:FF). 1381 Port Y starts: its HARP table entry state for HWa: PENDING 1383 1. Port Y initiates its interface and sends an InHARP_REQUEST to 1384 HWa, in this example the broadcast address, after starting a table 1385 entry. 1387 HIPPI-LE Destination_Switch_Address = SWb 1388 HIPPI-LE Source_Switch_Address = SWy 1389 HIPPI-LE Destination_IEEE_Address = ULAb 1390 HIPPI-LE Source_IEEE_Address = ULAy 1391 HARP ar$op = 8 (InHARP_REQUEST) 1392 HARP ar$rpa = IPy 1393 HARP ar$tpa = 0 ** 1394 HARP ar$rha = SWy ULAy 1395 HARP ar$tha = SWb ULAb 1396 ** is what we would like to find out 1398 2. Since the network is a broadcast network, client Y will receive 1399 a copy of its InHARP_REQUEST. Client Y examines the source addresses. 1400 Since they are the same as what Y filled in the InHARP_REQUEST, 1401 Y can deduce that it is connected to a broadcast medium. Port Y 1402 completes its table entry for HWa. This entry will not timeout 1403 since it is considered unlikely for a particular underlying 1404 hardware type to change between broadcast and non-broadcast; 1405 therefore this mapping will never change. 1407 12.3 Operational Phase (phase II) 1409 The Operational Phase of the HARP protocol as specified in this memo 1410 is the same for both broadcast and non-broadcast capable HIPPI 1411 hardware. The authoritative address in the HRAL for this example will 1412 be HWa: and IPs for simplicity reasons. 1414 12.3.1 Standard successful HARP_Resolve example 1416 Assume the same process (steps 1-3 of section 10.1) happened for port 1418 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1420 X. Then the state of X and Y's tables is: the HARP server table entry 1421 is in the VALID state. So lets look at the message traffic when X 1422 tries to send a message to Y. Since X doesn't have an entry for Y, 1424 1. Port X connects to the authoritative address of the HRAL and sends 1425 a HARP_REQUEST for Y's hardware address: 1427 HIPPI-LE Destination_Switch_Address = SWa 1428 HIPPI-LE Source_Switch_Address = SWx 1429 HIPPI-LE Destination_IEEE_Address = ULAa 1430 HIPPI-LE Source_IEEE_Address = ULAx 1431 HARP ar$op = 1 (HARP_REQUEST) 1432 HARP ar$rpa = IPx 1433 HARP ar$tpa = IPy 1434 HARP ar$rha = SWx ULAx 1435 HARP ar$tha = 0 ** 1436 ** is what we would like to find out 1438 2. The HARP server receives the HARP request and updates its 1439 entry for X if necessary. It then generates a HARP_REPLY with 1440 Y's hardware address information. 1442 HIPPI-LE Destination_Switch_Address = SWx 1443 HIPPI-LE Source_Switch_Address = SWa 1444 HIPPI-LE Destination_IEEE_Address = ULAx 1445 HIPPI-LE Source_IEEE_Address = ULAa 1446 HARP ar$op = 2 (HARP_Reply) 1447 HARP ar$rpa = IPy 1448 HARP ar$tpa = IPx 1449 HARP ar$rha = SWy ULAy * 1450 HARP ar$tha = SWx ULAx 1451 * answer we were looking for 1453 3. Port X connects to port Y and transmits an IP message with the 1454 following information in the HIPPI-LE header: 1456 HIPPI-LE Destination_Switch_Address = SWy 1457 HIPPI-LE Source_Switch_Address = SWx 1458 HIPPI-LE Destination_IEEE_Address = ULAy 1459 HIPPI-LE Source_IEEE_Address = ULAx 1461 If there had been a broadcast capable HIPPI network, the target ports 1462 would themselves have received the HARP_REQUEST of step 2 above 1463 and responded to them in the same way the HARP server did. 1465 12.3.2 Standard non-successful HARP_Resolve example 1467 Like in 12.3.1, assume that X and Y are fully registered with the 1469 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1471 HARP server. Then the state of X and Y's HARP server table entry 1472 is: VALID. So lets look at the message traffic when X tries to send a 1473 message to Q. Further assume that interface Q is NOT configured UP, 1474 i.e. it is DOWN. Since X doesn't have an entry for Q, 1476 1. Port X connects to the HARP server switch address and sends 1477 a HARP_REQUEST for Q's hardware address: 1479 HIPPI-LE Destination_Switch_Address = SWa 1480 HIPPI-LE Source_Switch_Address = SWx 1481 HIPPI-LE Destination_IEEE_Address = ULAa 1482 HIPPI-LE Source_IEEE_Address = ULAx 1483 HARP ar$op = 1 (HARP_REQUEST) 1484 HARP ar$rpa = IPx 1485 HARP ar$tpa = IPq 1486 HARP ar$rha = SWx ULAx 1487 HARP ar$tha = 0 ** 1488 ** is what we would like to find out 1490 2. The HARP server receives the HARP request and updates its 1491 entry for X if necessary. It then looks up IPq in its tables 1492 and doesn't find it. The HARP server then generates a 1493 HARP_NAK reply message. 1495 HIPPI-LE Destination_Switch_Address = SWx 1496 HIPPI-LE Source_Switch_Address = SWa 1497 HIPPI-LE Destination_IEEE_Address = ULAx 1498 HIPPI-LE Source_IEEE_Address = ULAa 1499 HARP ar$op = 10 (HARP_NAK) 1500 HARP ar$rpa = IPx 1501 HARP ar$tpa = IPq 1502 HARP ar$rha = SWx ULAx 1503 HARP ar$tha = 0 *** 1504 *** No Answer, and notice that the fields do not get swapped, 1505 i.e. the HARP message is the same as the HARP_REQUEST 1506 except for the operation code. 1508 If there had been a broadcast capable HIPPI network, then there 1509 would not have been a reply. 1511 13 References 1513 [1] ANSI X3.183-1991(R1996), Information Technology - 1514 High-Performance Parallel Interface - Mechanical, 1515 Electrical and Signaling Protocol Specification; (HIPPI-PH). 1517 [2] ANSI X3.210-1998, Information Technology - High-Performance 1519 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1521 Parallel Interface - Framing Protocol; (HIPPI-FP). 1523 [3] ANSI X3.218-1993, Information Technology - High-Performance 1524 Parallel Interface - Encapsulation of ISO 8802-2 (IEEE Std 1525 802.2) Logical Link Control Protocol Data Units; (HIPPI-LE). 1527 [4] ANSI X3.222-1997, Information Technology - High-Performance 1528 Parallel Interface - Physical Switch Control; (HIPPI-SC). 1530 [5] ANSI X3.300-1997, Information Technology - High-Performance 1531 Parallel Interface - Serial Specification; (HIPPI-Serial). 1533 [6] Braden, R., "Requirements for Internet Hosts -- Communication 1534 Layers", RFC-1122, USC/Information Sciences Institute, October 1535 1989. 1537 [7] Bradely, T., and Brown, C., "Inverse Address Resolution 1538 Protocol", RFC-2390, September 1998. 1540 [8] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol 1541 Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 1542 32-48, 1989. 1544 [9] Deering, S, "Host Extensions for IP Multicasting", RFC-1112, 1545 USC/Information Sciences Institute, August 1989. 1547 [10] Finlayson, R., Mann, T., Mogul, J., and Theimer, M., "A Reverse 1548 Address Resolution Protocol", RFC-903, Stanford University, June 1549 1984. 1551 [11] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local 1552 Area Networks - Logical Link Control, "IEEE Standards for Local 1553 Area Networks: Logical Link Control", IEEE, New York, New York, 1554 1985. 1556 [12] Laubach, Mark., "Classical IP and ARP over ATM", RFC-2225, 1557 Com21, Inc., April 1998. 1559 [13] Plummer, D., "An Ethernet Address Resolution Protocol - or - 1560 Converting Network Addresses to 48-bit Ethernet Address for 1561 Transmission on Ethernet Hardware", RFC-826, MIT, November 1982. 1563 [14] Renwick, J., Nicholson, A., "IP and ARP on HIPPI", RFC-1374, 1564 Cray Research, Inc., October 1992. 1566 [15] Renwick, J., "IP over HIPPI", RFC-2067, NetStar, Inc., January 1567 1997. 1569 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00 1571 [16] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 1572 RFC-1700, USC/Information Sciences Institute, October 1994. 1574 [17] ANSI NCITS xxx.199x, Project 1245-D, Scheduled Transfer Protocol 1575 ANSI NCITS, Scheduled Transfer Protocol draft standard. 1577 14 Acknowledgments 1579 This memo could not have come into being without the critical review 1580 from Greg Chesson, Carlin Otto, the high performance interconnect 1581 group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand 1582 and Jeff Young) and the expertise of the ANSI T11.1 Task Group 1583 responsible for the HIPPI standards work. 1585 This memo is based on the second part of [14], written by John 1586 Renwick. ARP [13] written by Dave Plummer and Inverse ARP [7] written 1587 by T. Bradley and C. Brown provide the fundamental algorithms of HARP 1588 as presented in this memo. Further, the HARP server is based on 1589 concepts and models presented in [12], written by Mark Laubach who 1590 laid the structural groundwork for the HARP server. 1592 15 Author's Address 1594 Jean-Michel Pittet 1595 Silicon Graphics Inc 1596 1600 Amphitheatre Parkway 1597 Mountain View, CA 94043 1599 Phone: 650-933-6149 1600 Fax: 650-933-3542 1601 EMail: jmp@sgi.com, jmp@acm.org 1603 -- 1604 -----8<----- 1605 Jean-Michel Pittet jmp@sgi.com Phone:650-933-6149 Fax:933-3542 1606 SGI, 1600 Amphitheatre Parkway, MS 802, Mountain View, CA, 94043 USA