idnits 2.17.1 draft-renwick-hippiip-02.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-18) 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. ** There are 41 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 162: '... use of the word SHALL in capital lett...' RFC 2119 keyword, line 214: '...ween a node and a switch SHALL consist...' RFC 2119 keyword, line 220: '... implementation SHALL also be capable...' RFC 2119 keyword, line 221: '... suppressed) and SHALL be able to sele...' RFC 2119 keyword, line 284: '...or Internet datagrams SHALL conform to...' (41 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 869 has weird spacing: '... User of ...' -- 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 (June 1996) is 10169 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 451 -- Looks like a reference, but probably isn't: 'EtherType' on line 432 -- Looks like a reference, but probably isn't: 'FILL' on line 456 -- 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. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1340 (ref. '8') (Obsoleted by RFC 1700) Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Renwick 3 Internet-Draft NetStar, Inc. 4 June 1996 6 IP over HIPPI 8 draft-renwick-hippiip-02.txt 10 Status of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 24 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Abstract 30 ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of 31 IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. ANSI X3.222- 32 1993 (HIPPI-SC[4]) describes the operation of HIPPI physical 33 switches. The ANSI committee responsible for these standards chose 34 to leave HIPPI networking issues largely outside the scope of their 35 standards; this document describes the use of HIPPI switches as IP 36 local area networks. 38 This draft is a revision of RFC 1374, "IP and ARP on HIPPI", and is 39 intended to replace it in the Standards Track. RFC 1374 has been a 40 Proposed Standard since November, 1992, with at least 10 41 implementations of IP encapsulation and HIPPI switch discipline. No 42 major changes to it are required. However, the ARP part of RFC 1374 43 has not had sufficient implementation experience to be advanced to 44 Draft Standard. The present document contains all of RFC 1374 except 45 for the description ARP, which has been moved into a separate 46 document. 48 TABLE OF CONTENTS 50 1 Introduction 2 51 2 Scope 3 52 2.1 Changes from RFC 1374 3 53 2.2 Terminology 4 54 3 Definitions 4 55 4 Equipment 5 56 5 Protocol 7 57 5.1 Packet Format 7 58 5.2 48 bit Universal LAN MAC addresses 11 59 5.3 I-Field Format 12 60 5.4 Rules For Connections 13 61 5.5 MTU 15 62 6 Camp-on 15 63 7 Path MTU Discovery 16 64 8 Channel Data Rate Discovery 16 65 9 Performance 17 66 10 Sharing the Switch 19 67 11 References 20 68 12 Security Considerations 20 69 13 Authors' Addresses 20 70 14 Appendix A -- HIPPI Basics 21 71 15 Appendix B -- How to Build a Practical HIPPI LAN 27 73 1 Introduction 75 The ANSI High-Performance Parallel Interface (HIPPI) is a simplex 76 data channel. Configured in pairs, HIPPI can send and receive data 77 simultaneously at nearly 800 megabits per second. (HIPPI has an 78 equally applicable 1600 megabit/second option.) Between 1987 and 79 1991, the ANSI X3T9.3 HIPPI working group drafted four documents that 80 bear on the use of HIPPI as a network interface. They cover the 81 physical and electrical specification (HIPPI-PH [1]), the framing of 82 a stream of bytes (HIPPI-FP [2]), encapsulation of IEEE 802.2 LLC 83 (HIPPI-LE [3]), and the behavior of a standard physical layer switch 84 (HIPPI-SC [4]). HIPPI-LE also implies the encapsulation of Internet 85 Protocol[5]. The reader should be familiar with the ANSI HIPPI 86 documents, copies of which are archived at the site "ftp.network.com" 87 in the directory "hippi", and may be obtained via anonymous FTP. 89 HIPPI switches can be used to connect a variety of computers and 90 peripheral equipment for many purposes, but the working group stopped 91 short of describing their use as Local Area Networks. This memo 92 takes up where the working group left off, using the guiding 93 principle that except for length and hardware header, Internet 94 datagrams sent on HIPPI should be identical to the same datagrams 95 sent on a conventional network, and that any datagram sent on a 96 conventional 802 network[6] should be valid on HIPPI. 98 2 Scope 100 This memo describes the HIPPI interface between a host and a 101 crosspoint switch that complies with the HIPPI-SC draft standard. 102 Issues that have no impact on host implementations are outside the 103 scope of this memo. Host implementations that comply with this memo 104 are believed to be interoperable on a network composed of a single 105 HIPPI-SC switch. They are also interoperable on a simple point-to- 106 point, two-way HIPPI connection with no switch between them. They 107 may be interoperable on more complex networks as well, depending on 108 the internals of the switches and how they are interconnected; 109 however, these details are implementation dependent and outside the 110 scope of this memo. 112 Within the scope of this memo are: 114 1. Packet format and header contents, including HIPPI-FP, HIPPI- 115 LE, IEEE 802.2 LLC[7] and SNAP. 117 2. I-Field contents 119 3. Rules for the use of connections. 121 Outside of the scope are 123 1. Address Resolution (ARP) 125 2. Network configuration and management 127 3. Host internal optimizations 129 4. The interface between a host and an outboard protocol 130 processor. 132 2.1 Changes from RFC 1374 134 RFC 1374 described the use of ARP on HIPPI, but because of 135 insufficient implementation experience, the description of ARP 136 has been separated from IP encapsulation and moved to an 137 Informational memo. It may be returned to the standards track 138 in the future if interest and implementations warrant it. 140 RFC 1374's specification of IP over HIPPI has been changed in 141 this document. Certain packet format options, permitted in RFC 142 1374, are no longer allowed: 144 1. Optional short burst first; 146 2. D1 fill bytes; 148 3. Nonzero D2 offset. 150 That is, the header format is no longer variable and is required 151 to be that which is recommended by RFC 1374. 153 With these changes, it is possible to send packets which conform 154 to the ANSI standards but not to this memo. Because there are 155 no RFC 1374 implementations in use that used these options, we 156 believe that all existing RFC 1374 implementations are compliant 157 with the requirements of this memo, and there should be no 158 interoperability problems associated with these changes. 160 2.2 Terminology 162 In this document the use of the word SHALL in capital letters 163 indicates mandatory points of compliance. 165 3 Definitions 167 Conventional 169 Used with respect to networks, this refers to Ethernet, FDDI and 170 802 LAN types, as distinct from HIPPI-SC LANs. 172 Destination 174 The HIPPI implementation that receives data from a HIPPI Source. 176 Node 178 An entity consisting of one HIPPI Source/Destination pair that is 179 connected by parallel or serial HIPPI to a HIPPI-SC switch and 180 that transmits and receives IP datagrams. A node may be an 181 Internet host, bridge, router or gateway. This memo uses the term 182 node in place of the usual "host" to indicate that a host might be 183 connected to the HIPPI LAN not directly, but through an external 184 adaptor that does some of the protocol processing for the host. 186 Serial HIPPI 188 An implementation of HIPPI in serial fashion on coaxial cable or 189 optical fiber, informally standardized by implementor's agreement 190 in the Spring of 1991. 192 Switch Address 193 A value used as the address of a node on a HIPPI-SC network. It 194 is transmitted in the I-field. HIPPI-SC switches may map Switch 195 Addresses to physical port numbers. 197 Source 199 The HIPPI implementation that generates data to send to a HIPPI 200 Destination. 202 Universal LAN Address (ULA) 204 A 48 bit globally unique address, administered by the IEEE, 205 assigned to each node on an Ethernet, FDDI, 802 network or HIPPI- 206 SC LAN. 208 4 Equipment 210 A HIPPI network can be composed of nodes with HIPPI interfaces, HIPPI 211 cables or serial links, HIPPI-SC switches, gateways to other 212 networks. 214 Each HIPPI interconnection between a node and a switch SHALL consist 215 of a pair of HIPPI links, one in each direction. 217 If a link between a node and the switch is capable of the 1600 218 Megabit/second data rate option (i.e. Cable B installed for 64 bit 219 wide operation) in either direction, the node's HIPPI-PH 220 implementation SHALL also be capable of 32 bit operation (Cable B 221 data suppressed) and SHALL be able to select or deselect the 1600Mb/s 222 data rate option at the establishment of each new connection. 224 The following figure shows a sample HIPPI switch configuration. 226 +-----+ 227 | H 4 | 228 | +--+--+ 229 | +----+ +----+ +----+ | 230 | | H1 | | H2 | | H3 | +-++ 231 | +--+ +-++-+ +-++-+ +-++-+ |PP| 232 +---+H5| || || || ++++ 233 | +--+ || || || || 234 | +---++--------++--------++------++----+ 235 | | | 236 | +----+ | HIPPI-SC | 237 +---+ G1 +--------+ | 238 | | +--------+ Switch | 239 | +----+ | | 240 | +---++--------++--------++------++----+ 241 | +--+ || || || || 242 +---+H6| || ++++ 243 | +--+ +-++-+ |PP| 244 | | | +-++ 245 | | G2 | | 246 | | | +--+--+ 247 | +--+-+ | H 7 | 248 | | +-----+ 249 | 250 -----+------------+-------+-----------+-------------+------ 251 | | | | 252 | | | | 253 +--+--+ +--+--+ +--+--+ +--+--+ 254 | H 8 | | H 9 | | H10 | | H11 | 255 +-----+ +-----+ +-----+ +-----+ 257 Legend: ---+---+---+-- = 802 network, Ethernet or FDDI 258 || = Paired HIPPI link 259 H = Host computer 260 PP = Outboard Protocol Processor 261 G = Gateway 263 A possible HIPPI configuration 265 A single HIPPI-SC switch has a "non-blocking" characteristic, which 266 means there is always a path available from any Source to any 267 Destination. If the network consists of more than one switch, the 268 path from a Source to a Destination may include a HIPPI link between 269 switches. If this link is used by more than one Source/Destination 270 pair, a "blocking" network is created: one Source may be blocked from 271 access to a Destination because another Source is using the link it 272 shares. Strategies for establishing connections may be more 273 complicated on blocking networks than on non-blocking ones. 275 This memo does not take blocking issues into account, assuming that 276 the HIPPI LAN consists of one HIPPI-SC switch or, if the network is 277 more complex than that, it presents no additional problems that a 278 node must be aware of. 280 5 Protocol 282 5.1 Packet Format 284 The HIPPI packet format for Internet datagrams SHALL conform to 285 the HIPPI-FP and HIPPI-LE draft standards, with further 286 restrictions as imposed by this memo. Because this memo is more 287 restrictive than the ANSI standards, it is possible to send 288 encapsulated IP datagrams that conform to the ANSI standards, 289 but are illegal according to this memo. Destinations may either 290 accept or ignore such datagrams. 292 To summarize the additional restrictions on ANSI standards found 293 here: 295 Any short burst must be the last burst of the packet. 296 Leading short bursts are not permitted. 298 Nonzero values for the HIPPI-FP D2_Offset field are not 299 permitted. 301 The D1_AreaSize SHALL be 3 (64-bit words). No D1 Fill is 302 permitted. 304 Note: Although this document is for IP over HIPPI, the 305 encapsulation described below accommodates ARP as well. 307 The HIPPI-FP D1_Area SHALL contain the HIPPI-LE header. The 308 HIPPI-FP D2_Area, when present, SHALL contain one IEEE 802.2 309 Type 1 LLC Unnumbered Information (UI) PDU. Support of IEEE 310 802.2 XID, TEST and Type 2 PDUs is not required on HIPPI, and 311 Destinations that receive these PDUs may either ignore them or 312 respond correctly according to IEEE 802.2 requirements. 314 The length of a HIPPI packet, including trailing fill, SHALL be 315 a multiple of eight bytes as required by HIPPI-LE. 317 +----------+-----------+---------------------+----------- ------+ 318 | | | | 0 - 7 | 319 | HIPPI-FP | HIPPI-LE | IEEE 802.2 LLC/SNAP | IP . . . bytes | 320 |(8 bytes) |(24 bytes) | (8 bytes) | fill | 321 +----------+-----------+---------------------+----------- ------+ 322 HIPPI Packet Structure 324 ULP-id (8 bits) SHALL contain 4. 326 D1_Data_Set_Present (1 bit) SHALL be set. 328 Start_D2_on_Burst_Boundary (1 bit) SHALL be zero. 330 Reserved (11 bits) SHALL contain zero. 332 D1_Area_Size (8 bits) SHALL be sent as 3. 334 D2_Offset (3 bits) SHALL be zero. 336 D2_Size (32 bits) Shall contain the number of bytes in the 337 IEEE 802.2 LLC Type 1 PDU, or zero if no PDU is present. It 338 SHALL NOT exceed 65,288. This value includes the IEEE 802.2 339 LLC/SNAP header and the IP datagram. It does not include 340 trailing fill bytes. (See "MTU", below.) 342 HIPPI-LE Header 344 FC (3 bits) SHALL contain zero unless otherwise defined by 345 local administration. 347 Double_Wide (1 bit) SHALL contain one if the Destination 348 associated with the sending Source supports 64 bit HIPPI 349 operation. Otherwise it SHALL contain zero. 351 Message_Type (4 bits) contains a code identifying the type of 352 HIPPI-LE PDU. Defined values are: 354 0 Data PDU 355 1 Address Resolution Request PDU (AR_Request) 356 2 Address Resolution Response PDU (AR_Response) 357 3 Self Address Resolution Request PDU (AR_S_Request) 358 4 Self Address Resolution Response PDU (AR_S_Response) 360 Destination_Switch_Address is a 24-bit field containing the 361 Switch Address of the Destination if known, otherwise zero. 362 If the address comprises less than 24 bits, it SHALL be right 363 justified (occupying the least significant bits) in the 364 field. 366 Destination_Address_Type (4 bits) and Source_Address_Type (4 367 bits) contain codes identifying the type of addresses in the 368 Destination_Switch_Address and Source_Switch_Address fields 369 respectively. Defined values (binary) are: 371 0 Unspecified 372 1 HIPPI-SC Source Route (24 bits) 373 2 HIPPI-SC Address (12 bits) 375 Source_Switch_Address is a 24-bit field containing the Switch 376 Address of the Source. If the address comprises less than 24 377 bits, it SHALL be right justified (occupying the least 378 significant bits) in the field. 380 Reserved (16 bits) SHALL contain zero. 382 Destination_IEEE_Address (48 bits) SHALL contain the 48 bit 383 Universal LAN MAC Address of the Destination if known, 384 otherwise zero. 386 LE_Locally_Administered (16 bits) SHALL contain zero UNLESS 387 otherwise defined by local administration. 389 Source_IEEE_Address (48 bits) SHALL contain the 48 bit 390 Universal LAN MAC Address of the Source if known, otherwise 391 zero. 393 IEEE 802.2 LLC 395 The IEEE 802.2 LLC Header SHALL begin in the first byte of 396 the HIPPI-FP D2_Area. 398 SSAP (8 bits) SHALL contain 170 ('AA'h). 400 DSAP (8 bits) SHALL contain 170 ('AA'h). 402 CTL (8 bits) SHALL contain 3 (Unnumbered Information). 404 SNAP 406 Organization Code (24 bits) SHALL be zero. 408 EtherType (16 bits) SHALL be set as defined in Assigned 409 Numbers [8]: IP = 2048 ('0800'h), ARP = 2054 ('0806'h), RARP 410 = 32,821 ('8035'h). 412 31 28 23 21 15 10 7 2 0 413 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 414 0 | 04 |1|0| Reserved | 03 | 0 | 415 +---------------+-+-+---------------------+---------------+-----+ 416 1 | (n+8) | 417 +-----+-+-------+-----------------------------------------------+ 418 2 |[LA] |W|M_Type | Destination_Switch_Address | 419 +-----+-+-------+-----------------------------------------------+ 420 3 | D_A_T | S_A_T | Source_Switch_Address | 421 +-------+-------+---------------+-------------------------------+ 422 4 | Reserved | [Destination_IEEE_Address] | 423 +-------------------------------+ | 424 5 | | 425 +-------------------------------+-------------------------------+ 426 6 | [LA] | [Source_IEEE_Address] | 427 +-------------------------------+ | 428 7 | | 429 +---------------+---------------+---------------+---------------+ 430 8 | AA | AA | 03 | 00 | 431 +---------------+---------------+---------------+---------------+ 432 9 | 00 | 00 | [EtherType] | 433 +---------------+---------------+---------------+---------------+ 434 10 |Message byte 0 |Message byte 1 |Message byte 2 | . . . | 435 +---------------+---------------+---------------+--- | 436 | . . . 437 | 438 | -------+---------------+---------------+---------------+ 439 | . . . | byte (n-2) | byte (n-1) | FILL | 440 +---------------+---------------+---------------+---------------+ 441 N-1| FILL | FILL | FILL | FILL | 442 +---------------+---------------+---------------+---------------+ 444 HIPPI Packet Format 446 Words 0-1: HIPPI-FP Header 447 Words 2-7: D1 Area (HIPPI-LE Header) 448 Words 8-9: D2 Area (IEEE 802.2 LLC/SNAP) 449 Words 10-(N-1): D2 Area (IP message) 450 (n) is the number of bytes in the IP message. 451 [LA] fields are zero unless used otherwise locally. 452 Abbreviations: "W" = Double_Wide field; 453 "M_Type" = Message_Type field; 454 "D_A_T" = Destination_Address_Type; 455 "S_A_T" = Source_Address_Type; 456 [FILL] bytes complete the HIPPI packet to an even 457 number of 32 bit words. The number of fill bytes 458 is not counted in the data length. 460 IEEE 802.2 Data 462 The IEEE 802.2 Data SHALL begin in the byte following the 463 EtherType field. Fill bytes SHALL be used following the Data 464 as necessary to make the number of bytes in the packet a 465 multiple of 8. In accordance with HIPPI-FP, the amount of 466 this fill is not included in the D2_Size value in the HIPPI- 467 FP Header. 469 The order of the bytes in the data stream is from higher 470 numbered to lower numbered data signal (left to right) within 471 the HIPPI word, as specified in HIPPI-FP Clause 7, "Word and 472 byte formats." With the 1600 megabit/second data rate option 473 (64 bit) bits 32 through 63 are on Cable B, so that the four 474 bytes on Cable B come logically before those on Cable A. 475 Within each byte, the most significant bit is the highest 476 numbered signal. 478 5.2 48 bit Universal LAN MAC Addresses 480 IEEE Standard 802.1A specifies the Universal LAN MAC Address. 481 The globally unique part of the 48 bit space is administered by 482 the IEEE. Each node on a HIPPI-SC LAN should be assigned a ULA. 483 Multiple ULAs may be used if a node contains more than one IEEE 484 802.2 LLC protocol entity. 486 The format of the address within its 48 bit HIPPI-LE fields 487 follows IEEE 802.1A canonical bit order and HIPPI-FP bit and 488 byte order: 490 31 23 15 7 0 491 +-------------------------------+---------------+---------------+ 492 | (not used for ULA) |ULA byte 0 |L|G| ULA byte 1 | 493 +---------------+---------------+---------------+---------------+ 494 | ULA byte 2 | ULA byte 3 | ULA byte 4 | ULA byte 5 | 495 +---------------+---------------+---------------+---------------+ 497 Universal LAN MAC Address Format 499 L (U/L bit) = 1 for Locally administered addresses, 0 for 500 Universal. 501 G (I/G bit) = 1 for Group addresses, 0 for Individual. 503 The use of ULAs is optional, but encouraged. Although ULAs are 504 not used by HIPPI-SC switches, they may be helpful for HIPPI 505 Switch Address resolution, and for distinguishing between 506 multiple logical entities that may exist within one node. They 507 may also be used by gateway devices that replace HIPPI hardware 508 headers with the MAC headers of other LANs. Carrying the ULAs 509 in the HIPPI header may simplify these devices, and it may also 510 help if HIPPI is used as an interface to some future HIPPI based 511 LAN that uses ULAs for addressing. 513 5.3 I-Field format 515 The I-field bits, as defined in HIPPI-SC, SHALL be set as 516 follows: 518 Locally Administered (bit 31) SHALL be zero. 520 Reserved (bits 30, 29) should be zero. Destinations SHALL 521 accept any value for these bits. 523 Double wide (bit 28) SHALL be set when Source Cable B is 524 connected and the Source wants a 64 bit connection. It SHALL 525 be zero otherwise. 527 Direction (bit 27) should be sent as zero, however 528 Destinations SHALL accept either zero or one and interpret 529 the Routing Control field accordingly, per HIPPI-SC. 531 Path Selection (bits 26, 25) SHALL be 00, 01, or 11 (binary) 532 at the Source's option. 00 (source route mode) indicates 533 that the I-field bits 23-00 contain a 24 bit source route; 01 534 or 11 (logical address mode) indicate that bits 23-00 contain 535 12 bit Source and Destination Addresses. The value 11 is 536 meaningful when more than one route exists from a Source to a 537 Destination; it allows the switch to choose the route. Use 538 of 01 forces the switch always to use the same route for the 539 same Source/Destination pair. 541 Camp-on (bit 24) may be 1 or 0; however, a Source SHALL NOT 542 make consecutive requests without Camp-on to the same 543 Destination while the requests are being rejected. The 544 purpose of this restriction is to prevent a node from 545 circumventing the fair share arbitration mechanism of the 546 switch by repeating requests at a very high rate. 548 If logical address mode is used: 550 Source Address (bits 23-12) is not used. 552 Destination Address (bits 11-0) SHALL contain the Switch 553 Address of the Destination. 555 If source route mode is used: 557 Routing control (bits 23-00) SHALL contain the route to 558 the Destination. 560 5.4 Rules For Connections 562 The following rules for connection management by Source and 563 Destination are intended to insure frequent, fair share access 564 to Destinations for which multiple Sources are contending. If 565 possible, nodes should transfer data at full HIPPI speeds and 566 hold connections no longer than necessary. 568 A source may hold a connection for as long as it takes to send 569 68 HIPPI bursts at what ever speed the two connected nodes can 570 achieve together. The number of packets sent in one connection 571 is not limited, except that the number of bursts over all the 572 packets should not exceed 68. This is not a recommendation to 573 send as many packets as possible per connection; one packet per 574 connection is acceptable. The purpose of this limit is to give 575 each Source an fair share of a common Destination's bandwidth. 576 Without a limit, if there is a Destination that is constantly in 577 demand by multiple Sources, the Source that sends the most data 578 per connection wins the greatest share of bandwidth. 580 The limit of 68 bursts is not absolute. An implementation may 581 check the burst count after transmission of a packet and end the 582 connection if it is greater than or equal to some threshold. If 583 this is done, the threshold should be less than 68 depending on 584 the typical packet size, to ensure that the 68 burst limit is 585 not normally exceeded. For instance, a Source sending 64K 586 packets would send two per connection (130 bursts) if it checked 587 for 68 at the end of each packet. In this situation the Source 588 is required to check for a value small enough that it will not 589 send a second packet in the same connection. 591 Destinations SHALL accept all packets that arrive during a 592 connection, and may discard those that exceed its buffering 593 capacity. A Destination SHALL NOT abort a connection (deassert 594 CONNECT) simply because too many bursts were received; however a 595 Destination may abort a connection whose duration has exceeded a 596 time period of the Destination's choosing, as long as the Source 597 is allowed ample time to transmit its quota of bursts. 599 The rules admonish the node to do certain things as fast as it 600 can, however there is no absolute measure of compliance. Nodes 601 that cannot transfer data at full HIPPI speeds can still 602 interoperate but the faster the implementation, the better the 603 performance of the network will be. 605 Assuming that bursts flow at the maximum rate, the most 606 important factor in network throughput is the connection 607 switching time, measured from the deassertion of REQUEST by the 608 Source at the end of one connection to its first assertion of 609 BURST after the establishment of the new connection. 611 Implementations should keep this time as short as possible. For 612 a guideline, assuming parallel HIPPI and a single HIPPI-SC 613 switch, ten microseconds permits nearly full HIPPI throughput 614 with full-sized packets, and at 60 microseconds the available 615 throughput is reduced by about 10%. (See "Performance", below.) 617 All HIPPI electrical signaling SHALL comply with HIPPI-PH. In 618 every case, the following rules go beyond what HIPPI-PH 619 requires. 621 Rules for the Source 623 1. Do not assert REQUEST until a packet is ready to send. 625 2. Transmit bursts as quickly as READYs permit. Except for 626 the required HIPPI Source Wait states, there should be no 627 delay in the assertion of BURST whenever the Source's READY 628 counter is nonzero. 630 3. Make a best effort to ensure that connection durations do 631 not exceed 68 bursts. 633 4. Deassert REQUEST immediately when no packet is available 634 for immediate transmission or the last packet of the 635 connection has been sent. 637 Rules for the Destination 639 1. Reject all connections if unable to receive packets. 640 This frees the requesting Source to connect to other 641 Destinations with a minimum of delay. Inability to receive 642 packets is not a transient condition, but is the state of the 643 Destination when its network interface is not initialized. 645 2. A HIPPI node should be prepared to efficiently accept 646 connections and process incoming data packets. While this 647 may be best achieved by not asserting connect unless 68 648 bursts worth of buffers is available, it may be possible to 649 meet this requirement with fewer buffers. This may be due to 650 a priori agreement between nodes on packet sizes, the speed 651 of the interface to move buffers, or other implementation 652 dependent considerations. 654 3. Accept a connection immediately when buffers are 655 available. The Destination should never delay the acceptance 656 of a connection unnecessarily. 658 4. Once initialized, a Destination may reject connection 659 requests only for one of the following reasons: 661 1. The I-field was received with incorrect parity. 663 2. The I-field contents are invalid, e.g. the "W" bit set 664 when the Destination does not support the 1600 megabit 665 data rate option, the "Locally Administered" bit is set, 666 the Source is not permitted to send to this Destination, 667 etc. 669 Transient conditions within the Destination, such as 670 temporary buffer shortages, must never cause rejected 671 connections. 673 5. Ignore aborted connection sequences. Sources may time 674 out and abandon attempts to connect; therefore aborted 675 connection sequences are normal events. 677 5.5 MTU 679 Maximum Transmission Unit (MTU) is defined as the length of the 680 IP packet, including IP header, but not including any overhead 681 below IP. Conventional LANs have MTU sizes determined by 682 physical layer specification. MTUs may be required simply 683 because the chosen medium won't work with larger packets, or 684 they may serve to limit the amount of time a node must wait for 685 an opportunity to send a packet. 687 HIPPI has no inherent limit on packet size. The HIPPI-FP header 688 contains a 32 bit D2_Size field that, while it may limit packets 689 to about 4 gigabytes, imposes no practical limit for networking 690 purposes. Even so, a HIPPI-SC switch used as a LAN needs an MTU 691 so that Destination buffer sizes can be determined. 693 The MTU for HIPPI-SC LANs is 65280 bytes. 695 This value was selected because it allows the IP packet to fit 696 in one 64K byte buffer with up to 256 bytes of overhead. The 697 overhead is 40 bytes at the present time; there are 216 bytes of 698 room for expansion. 700 HIPPI-FP Header 8 bytes 701 HIPPI-LE Header 24 bytes 702 IEEE 802.2 LLC/SNAP Headers 8 bytes 703 Maximum IP packet size (MTU) 65280 bytes 704 ------------ 705 Total 65320 bytes (64K - 216) 707 6 Camp-on 709 When several Sources contend for a single Destination, the Camp-on 710 feature allows the HIPPI-SC switch to arbitrate and ensure that all 711 Sources have fair access. (HIPPI-SC does not specify the method of 712 arbitration.) Without Camp-on, the contending Sources would simply 713 have to retry the connection repeatedly until it was accepted, and 714 the fastest Source would usually win. To guarantee fair share 715 arbitration, Sources are prohibited from making repeated requests to 716 the same Destination without Camp-on in such a way as to defeat the 717 arbitration. 719 There is another important reason to use Camp-on: when a connection 720 without Camp-on is rejected, the Source cannot determine whether the 721 rejection came from the requested Destination or from the switch. 722 The Source also cannot tell the reason for the rejection, which could 723 be either that the Destination was off line or not cabled, or the I- 724 field was erroneous or had incorrect parity. Sources should not 725 treat a rejection of a request without Camp-on as an error. Camp-on 726 prevents rejection due to the temporary busy case; with one 727 exception, rejection of a Camp-on request indicates an error 728 condition, and an error event can be recorded. The exception occurs 729 when a 64 bit connection is attempted to a Destination that does not 730 have Cable B connected, resulting in a reject. This case is covered 731 in "Channel Data Rate Discovery", below. 733 7 Path MTU Discovery 735 RFC 1191 [9] describes the method of determining MTU restrictions on 736 an arbitrary network path between two hosts. HIPPI nodes may use 737 this method without modification to discover restrictions on paths 738 between HIPPI-SC LANs and other networks. Gateways between HIPPI-SC 739 LANs and other types of networks should implement RFC 1191. 741 8 Channel Data Rate Discovery 743 HIPPI exists in two data rate options (800 megabit/second and 1600 744 megabit/second). The higher data rate is achieved by making the 745 HIPPI 64 bits parallel instead of 32, using an extra cable containing 746 32 additional data bits and four parity bits. HIPPI-SC switches can 747 be designed to attach to both. Source and Destination HIPPI 748 implementations can be designed to operate at either rate, selectable 749 at the time a connection is established. The "W" bit (bit 28) of the 750 I-field controls the width of the connection through the switch. 751 Sources with both cables A and B attached to the switch may set the 752 "W" bit to request a 1600 megabit/second connection. If the 753 requested destination also has both cables attached, the switch can 754 connect Source to Destination on both cables. If the requested 755 Destination has only Cable A, the switch rejects the request. 756 Sixty-four bit Sources can connect to 32 bit Destinations by 757 requesting with the "W" bit clear and not using Cable B. Sixty-four 758 bit Destinations must examine the "W" bit in the received I-field and 759 use or ignore Cable B accordingly. Note that both INTERCONNECT 760 signals stay active while a 64 bit HIPPI is used in 32 bit mode. 762 The following table summarizes the possible combinations, the 763 switch's action for each, and the width of the resulting connection. 765 Destination 766 +-------------------+-------------------+ 767 | 32 | 64 | 768 +----+-----+-------------------+-------------------+ 769 | | W=0 | Accept 32 | Accept 32 | 770 | 32 +-----+-------------------+-------------------+ 771 | | W=1 | N/A | N/A | 772 Source +----+-----+-------------------+-------------------+ 773 | | W=0 | Accept 32 | Accept 32 | 774 | 64 +-----+-------------------+-------------------+ 775 | | W=1 | Reject | Accept 64 | 776 +----+-----+-------------------+-------------------+ 778 HIPPI Connection Combinations 780 If the path between a 64 bit Source and a 64 bit Destination includes 781 more than one switch, and the route between switches uses a link that 782 is only 32 bits wide, the switch rejects 64 bit connection requests 783 as if the Destination did not have 64 bit capability. 785 In a mixed LAN of 32 bit and 64 bit HIPPIs, a 64 bit Source needs to 786 know the data rates available at each Destination and on the path to 787 it. This can be known a priori by manual configuration, or it can be 788 discovered dynamically. The only reliable method of discovery is 789 simply to attempt a 64 bit connection with Camp-on. As long as 64 790 bit connections succeed, the Source knows the Destination and path 791 are double width. If a 64 bit connection is rejected, the Source 792 tries to connect for 32 bits. If the 32 bit connection succeeds, the 793 Source assumes that the Destination or path is not capable of double 794 width operation, and uses only 32 bit requests after that. If the 32 795 bit request is rejected, the Source assumes that the Destination or 796 path is down and makes no determination of its capability. 798 The Double_Wide bit in the HIPPI-LE header, if nonzero, gives the 799 node that receives it a hint that the 64 bit connection attempt may 800 be worthwhile when sending on the return path. 802 Note that Camp-on must be used at least in the 64 bit attempt, 803 because it removes some ambiguity from the meaning of rejects. If 804 the request is made with the "W" bit and no Camp-on, a reject could 805 mean either that the Destination has no Cable B or that it is simply 806 busy, and no conclusion can be drawn as to its status for 64 bit 807 connections. 809 9 Performance 811 The HIPPI connection rules are designed to permit best utilization of 812 the available HIPPI throughput under the constraint that each 813 Destination must be made available frequently to receive packets from 814 different Sources. This discipline asks both Sources and 815 Destinations to minimize connection setup overhead to deliver high 816 performance. Low connection setup times are easily achieved by 817 hardware implementations, but overhead may be too high if software is 818 required to execute between the initial request of a connection and 819 the beginning of data transfer. Hardware implementations in which 820 connection setup and data transfer proceed from a single software 821 action are very desirable. 823 HIPPI connections are controlled by HIPPI Sources; a Destination, 824 being unable to initiate a disconnect without the possibility of data 825 loss, is a slave to the Source once it has accepted a connection. 826 Optimizations of connection strategy are therefore the province of 827 the HIPPI Source, and several optimizations are permitted. 829 If the rate of available message traffic is less than the available 830 HIPPI throughput and Destinations are seldom busy when a connection 831 is requested, connection optimizations do not pay off and the 832 simplest strategy of waiting indefinitely for each connection to be 833 made and sending messages strictly in the order queued cannot be 834 improved upon. However if some nodes are slow, or network 835 applications can send or receive messages at a higher aggregate rate 836 than the available HIPPI bandwidth, Sources may frequently encounter 837 a busy Destination. In these cases, certain host output queuing 838 strategies may enhance channel utilization. Sources may maintain 839 separate output queues for different HIPPI Destinations, and abandon 840 one Destination in favor of another if a connection attempt without 841 Camp-on is rejected or a connection request with Camp-on is not 842 accepted within a predetermined interval. Such a strategy results in 843 aborted connection sequences (defined in HIPPI-PH: REQUEST is 844 deasserted before any data is sent). Destinations must treat these 845 as normal events, perhaps counting them but otherwise ignoring them. 847 Two components of connection setup time are out of the control of 848 both Source and Destination. One is the time required for the switch 849 to connect Source to Destination, currently less than four 850 microseconds in the largest commercially available (32 port) switch. 851 The second component is the round trip propagation time of the 852 REQUEST and CONNECT signals, negligible on a standard 25 meter copper 853 HIPPI cable, but contributing a total of about 10 microseconds per 854 kilometer on fiber optic links. HIPPI-SC LANs spanning more than a 855 few kilometers will have reduced throughput. Limited span networks 856 with buffered gateways or bridges between them may perform better 857 than long serial HIPPI links. 859 A Source is required to drop its connection after the transmission of 860 68 HIPPI bursts. This number was chosen to allow the transmission of 861 one maximum sized packet or a reasonable number of smaller sized 862 packets. The following table lists some possibilities, with 863 calculated maximum burst and throughput rates in millions (10**6) of 864 bytes per second: 866 Maximum HIPPI Throughput Rates 868 Number Number Hold Burst ------Max throughput MB/sec------- 869 User of of Time Rate Connection Setup Overhead (usec) 870 Data Packets Bursts (usec) MB/sec 10 30 60 90 120 150 871 ---- ------- ------ ------ ------ ---- ---- ---- ---- ---- ---- 872 63K 1 64 654 98.7 97.2 94.4 90.4 86.8 83.4 80.3 873 32K 2 66 665 98.6 97.1 94.3 90.4 86.8 83.5 80.4 874 16K 4 68 667 98.3 96.8 94.1 90.2 86.6 83.3 80.2 875 8K 7 63 587 97.8 96.1 93.0 88.7 84.8 81.2 77.8 876 4K 13 65 551 96.7 95.0 91.7 87.2 83.1 79.4 76.0 877 2K 22 66 476 94.6 92.7 89.0 84.0 79.6 75.6 72.0 878 1K 34 68 384 90.8 88.5 84.2 78.5 73.5 75.8 65.3 880 These calculations are based 259 40 ns clock periods to transmit a 881 full burst and 23 clock periods for a short burst. (HIPPI-PH 882 specifies three clock periods of overhead per burst.) A packet of "n" 883 kilobytes of user data consists of "n" full bursts and one short 884 burst equal in length to the number of bytes in the HIPPI, LLC, IP 885 and TCP headers. "Hold Time" is the minimum connection duration 886 needed to send the packets. "Burst Rate" is the effective transfer 887 rate for the duration of the connection, not counting connection 888 switching time. Throughput rates are in megabytes/second, accounting 889 for connection switching times of 10, 30, 60, 90, 120 and 150 890 microseconds. These calculations ignore any limit on the rate at 891 which a Source or Destination can process small packets; such limits 892 may further reduce the available throughput if small packets are 893 used. 895 10 Sharing the Switch 897 Network interconnection is only one potential application of HIPPI 898 and HIPPI-SC switches. While network applications need very frequent 899 transient connections, other applications may favor longer term or 900 even permanent connections between Source and Destination. Since the 901 switch can serve each Source or Destination with hardware paths 902 totally separate from every other, it is quite feasible to use the 903 same switch to support LAN interconnects and computer/peripheral 904 applications simultaneously. 906 Switch sharing is no problem when unlike applications do not share a 907 HIPPI cable on any path. However if a host must use a single input 908 or output cable for network as well as other kinds of traffic, or if 909 a link between switches must be shared, care must be taken to ensure 910 that all applications are compatible with the connection discipline 911 described in this memo. Applications that hold connections too long 912 on links shared with network traffic may cause loss of network 913 packets or serious degradation of network service. 915 11 References 917 [1] ANSI X3.183-1991, High-Performance Parallel Interface - 918 Mechanical, Electrical and Signalling Protocol Specification 919 (HIPPI-PH). 921 [2] ANSI X3.210-1992, High-Performance Parallel Interface - Framing 922 Protocol (HIPPI-FP). 924 [3] ANSI X3.218-1993, High-Performance Parallel Interface - 925 Encapsulation of IEEE 802.2 (IEEE Std 802.2) Logical Link 926 Control Protocol Data Units (802.2 Link Encapsulation) (HIPPI- 927 LE). 929 [4] ANSI X3.222-1993, High-Performance Parallel Interface - Physical 930 Switch Control (HIPPI-SC). 932 [5] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information 933 Sciences Institute, September 1981. 935 [6] IEEE, "IEEE Standards for Local Area Networks: Logical Link 936 Control", IEEE, New York, New York, 1985. 938 [7] IEEE, "IEEE Standards for Local Area Networks: Logical Link 939 Control", IEEE, New York, New York, 1985. 941 [8] Reynolds, J.K., and Postel, J., "Assigned Numbers", STD 2, RFC 942 1340, USC/Information Sciences Institute, July 1992. 944 [9] Mogul, J.C., and Deering, S.E., "Path MTU discovery", RFC 1191, 945 Stanford University, November, 1990. 947 12 Security Considerations 949 Security issues are not discussed in this memo. 951 13 Author's Address 953 John K. Renwick 954 NetStar, Inc. 955 10250 Valley View Road 956 Minneapolis, MN USA 55344 958 Phone: (612) 996-6847 959 EMail: jkr@NetStar.com 961 Mailing List: hippi-ext@think.com 963 14 Appendix A -- HIPPI Basics 965 This section is included as an aid to readers who are not completely 966 familiar with the HIPPI standards. 968 HIPPI-PH describes a parallel copper data channel between a Source 969 and a Destination. HIPPI transmits data in one direction only, so 970 that two sets are required for bidirectional flow. The following 971 figure shows a simple point-to-point link between two computer 972 systems: 974 +----------+ +----------+ 975 | | | | 976 | +--------+ +--------+ | 977 | | HIPPI | Cable | HIPPI | | 978 | | +--------------------->| | | 979 | | Source | | Dest. | | 980 | System +--------+ +--------+ System | 981 | X +--------+ +--------+ Y | 982 | | HIPPI | Cable | HIPPI | | 983 | | |<---------------------+ | | 984 | | Dest. | | Source | | 985 | +--------+ +--------+ | 986 | | | | 987 +----------+ +----------+ 989 A Simple HIPPI Duplex Link 991 Parallel copper cables may be up to 25 meters in length. 993 In this document, all HIPPI connections are assumed to be paired 994 HIPPI channels. 996 HIPPI-PH has a single optional feature: it can use a single cable in 997 each direction for a 32 bit parallel channel with a maximum data rate 998 of 800 megabit/second, or two cables for 64 bits and 1600 999 megabit/second. Cable A carries bits 0-31 and is used in both modes; 1000 Cable B carries bits 32-63 and is use only with the 1600 1001 megabit/second data rate option. 1003 HIPPI Signal Hierarchy 1005 HIPPI has the following hardware signals: 1007 Source to Destination 1009 INTERCONNECT A 1010 INTERCONNECT B (64 bit only) 1011 CLOCK (25 MHz) 1012 REQUEST 1013 PACKET 1014 BURST 1015 DATA (32 or 64 signals) 1016 PARITY (4 or 8 signals) 1018 Destination to Source 1020 INTERCONNECT A 1021 INTERCONNECT B (64 bit only) 1022 CONNECT 1023 READY 1025 The INTERCONNECT lines carry DC voltages that indicate that the 1026 cable is connected and that the remote interface has power. 1027 INTERCONNECT is not used for signaling. 1029 The CLOCK signal is a continuous 25 MHz (40 ns period) square 1030 wave. All Source-to-Destination signals are synchronized to the 1031 clock. 1033 The REQUEST and CONNECT lines are used to establish logical 1034 connections. A connection is always initiated by a Source as it 1035 asserts REQUEST. At the same time it puts 32 bits of data on DATA 1036 lines 0-31, called the I-field. The Destination samples the DATA 1037 lines and can complete a connection by asserting CONNECT. Packets 1038 can be transmitted only while both REQUEST and CONNECT are 1039 asserted. 1041 A Destination can also reject a connection by asserting CONNECT 1042 for only a short interval between 4 and 16 HIPPI clock periods 1043 (160-640 nanoseconds). The Source knows a connection has been 1044 accepted when CONNECT is asserted for more than 16 clocks or it 1045 receives a READY pulse. 1047 Either Source or Destination can terminate a connection by 1048 deasserting REQUEST or CONNECT, respectively. Normally 1049 connections are terminated by the Source after its last Packet has 1050 been sent. A Destination cannot terminate a connection without 1051 potential loss of data. 1053 +------+-------------------------+------+ 1054 | Idle | Connected | Idle | . . . 1055 +------+-------------------------+------+ 1056 / \ 1057 / \ 1058 / \ 1059 / \ 1060 / \ 1061 +-------+ +-------+ +-------+ +-------+ 1062 |I-field| |Packet | |Packet | |Packet | 1063 +-------+ +-------+ +-------+ +-------+ 1064 / \ 1065 / \ 1066 / \ 1067 / \ 1068 / \ 1069 / \ 1070 / \ 1071 +-----+ +-----+ +-----+ 1072 |Burst| |Burst|...|Burst| 1073 +-----+ +-----+ +-----+ 1075 HIPPI Logical Framing Hierarchy 1077 The Source asserts PACKET for the duration of a Packet 1078 transmission, deasserting it to indicate the end of a Packet. A 1079 sequence of Bursts comprise a Packet. To send a burst, a Source 1080 asserts the BURST signal for 256 clock periods, during which it 1081 places 256 words of data on the DATA lines. The first or last 1082 Burst of a Packet may be less than 256 clock periods, allowing the 1083 transmission of any integral number of 32 or 64 bit words in a 1084 Packet. 1086 The READY signal is a pulse four or more clock periods long. Each 1087 pulse signals the Source that the Destination can receive one 1088 Burst. The Destination need not wait for a burst before sending 1089 another READY if it has burst buffers available; up to 63 1090 unanswered READYs may be sent, allowing HIPPI to operate at full 1091 speed over distances of many kilometers. If a Source must wait 1092 for flow control, it inserts idle periods between Bursts. 1094 +------------------------------------------------+ 1095 REQUEST---+ +---- 1096 +--------------------------------------------+ 1097 CONNECT---------+ +-- 1098 +---------------------------------------+ 1099 PACKET-------------+ +---- 1101 +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ 1102 READY------------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +-- 1104 +-------+ +-------+ +-------+ +-----+ 1105 BURST--------------+ +-+ +-+ +-+ +-------- 1107 DATA------I-field----DATA------DATA------DATA-----DATA---------- 1109 HIPPI Signal Timing Diagram 1111 Serial HIPPI 1113 There is no ANSI standard for HIPPI other than the parallel copper 1114 cable version. However an implementors' agreement exists, 1115 specifying a serial protocol to extend HIPPI signals on optical 1116 fiber or coaxial copper cable. Serial links may be used 1117 interchangeably with parallel links to overcome HIPPI distance 1118 limitations; they are transparent to the Source and Destination, 1119 except for the possibility of longer propagation delays. 1121 I-Field and Switch Control 1123 The REQUEST, CONNECT and I-field features of HIPPI-PH were 1124 designed for the control of switches as described in HIPPI-SC. A 1125 switch is a hub with a number of input and output HIPPI ports. 1126 HIPPI Sources are cabled to switch input ports, and switch output 1127 ports are cabled to HIPPI Destinations. When a HIPPI Source 1128 requests a connection, the switch interprets the I-field to select 1129 an output port and electrically connects the HIPPI Source to the 1130 HIPPI Destination on that port. Once connected, the switch does 1131 not interact with the HIPPIs in any way until REQUEST or CONNECT 1132 is deasserted, at which time it breaks the physical connection and 1133 deasserts its output signals to both sides. Some existing switch 1134 implementations can switch connections in less than one 1135 microsecond. There is the potential for as many simultaneous 1136 connections, each transferring data at HIPPI speeds, as there are 1137 input or output ports on the switch. A switch offers much greater 1138 total throughput capacity than broadcast or ring media. 1140 31 28 26 23 11 0 1141 +-+---+-+-+---+-+-----------------------+-----------------------+ 1142 |L| |W|D|PS |C| Source Address | Destination Address | 1143 +-+---+-+-+---+-+-----------------------+-----------------------+ 1145 HIPPI-SC I-field Format (Logical Address Mode) 1147 L = Locally defined (1 => entire I-field is locally defined) 1148 W = Width (1 => 64 bit connection) 1149 D = Direction (1 => swap Source and Destination Address) 1150 PS = Path Selection (01 => Logical Address Mode) 1151 C = Camp-on (1 => wait until Destination is free) 1153 HIPPI-SC defines I-field formats for two different addressing 1154 modes. The first, called Source Routing, encodes a string of port 1155 numbers in the lower 24 bits. This string specifies a route over 1156 a number of switches. A Destination's address may differ from one 1157 Source to another if multiple switches are used. 1159 The second format, called Logical Address Mode, defines two 12 bit 1160 fields, Source Address and Destination Address. A Destination's 1161 12 bit Switch Address is the same for all Sources. Switches 1162 commonly have address lookup tables to map 12 bit logical 1163 addresses to physical ports. This mode is used for networking. 1165 Control fields in the I-field are: 1167 L The "Locally Defined" bit, when set, indicates that the I-field 1168 is not in the standard format. The meaning of bits 30-0 are 1169 locally defined. 1171 W The Width bit, when set, requests a 64 bit connection through 1172 the switch. It is meaningless if Cable B is not installed at 1173 the Source. If W is set and either the Source or the requested 1174 Destination has no Cable B to the switch, the switch rejects 1175 the connection. Otherwise the switch connects both Cable A and 1176 Cable B if W is set, or Cable A only if W is clear. This 1177 feature is useful if both Source and Destination 1178 implementations can selectively disable or enable Cable B on 1179 each new connection. 1181 D The Direction bit, when set, reverses the sense of the Source 1182 Address and Destination Address fields. In other words, D=1 1183 means that the Source Address is in bits 0-11 and the 1184 Destination Address is in bits 12-23. This bit was defined to 1185 give devices a simple way to route return messages. It is not 1186 useful for LAN operations. 1188 PS The Path Selection field determines whether the I-field 1189 contains Source Route or Address information, and in Logical 1190 Address mode, whether the switch may select from multiple 1191 possible routes to the destination. The value "01" selects 1192 Logical Address mode and fixed routes. 1194 C The Camp-on bit requests the switch not to reject the 1195 connection if the selected Destination is busy (connected to 1196 another Source) but wait and make the connection when the 1197 Destination is free. 1199 15 Appendix B -- How to Build a Practical HIPPI LAN 1201 "IP on HIPPI" describes the network host's view of a HIPPI local area 1202 network without providing much information on the architecture of the 1203 network itself. Here we describe a network constructed from 1204 available HIPPI components, having the following characteristics: 1206 1. A tree structure with a central HIPPI-SC compliant hub and 1207 optional satellite switches 1209 2. Each satellite is connected to the hub by just one bidirectional 1210 HIPPI link. 1212 3. Serial HIPPI or transparent fiber optic HIPPI extender devices 1213 may be used in any link. 1215 4. Some satellites may be a particular switch product which is not 1216 HIPPI-SC compliant. 1218 5. Host systems are attached either directly to the hub or to 1219 satellites, by single bidirectional links in which both HIPPI cables 1220 go to the same numbered switch port. 1222 Switch Address Management 1224 Switch addresses use a flat address space. The 12-bit address is 1225 subdivided into 6 bits of switch number and 6 bits of port number. 1227 11 5 0 1228 +-----------------------+-----------------------+ 1229 | Switch Number | Port Number | 1230 +-----------------------+-----------------------+ 1232 Logical Address Construction 1234 Switches may be numbered arbitrarily. A given host's address 1235 consists of the number of the switch it is directly attached to 1236 and the physical port number on that switch to which its input 1237 channel is attached. 1239 In the singly-connected tree structure, there is exactly one path 1240 between any pair of hosts. Since each satellite must be connected 1241 directly to the hub, the maximum length of this path is three 1242 hops, and the minimum length is one. Each HIPPI-SC compliant 1243 switch is programmed to map each of the host switch addresses to 1244 the appropriate output port: either the port to which the host is 1245 directly attached or a port that is linked to another switch in 1246 the path to it. 1248 Special Treatment of Nonstandard Switches 1250 There is one commercially available switch that was designed 1251 before the drafting of HIPPI-SC and is not fully compliant. It is 1252 in common use, so it is worth making some special provisions to 1253 allow its use in a HIPPI LAN. This switch supports only the 1254 Source Route mode of addressing with a four bit right shift that 1255 can be disabled by a hardware switch on each input port. 1256 Addresses cannot be mapped. The switch does not support the "W", 1257 "D", or "PS" fields of the I-field; it ignores their contents. 1258 Use of this switch as a satellite will require a slight deviation 1259 from normal I-field usage by the hosts that are directly attached 1260 to it. Hosts attached to standard switches are not affected. 1262 For a destination connected to a non compliant satellite, the 1263 satellite uses only the least significant four bits of the I-field 1264 as the address. Since the address contains the destination's 1265 physical port number in the least significant bits, its port will 1266 be selected. Nonstandard switches should be set to disable I- 1267 field shifting at the input from the hub, so that the destination 1268 host will see its correct switch address in the I-field when 1269 performing self-address discovery. I-field shifting must be 1270 enabled on the satellite for each input port to which a host is 1271 attached. 1273 Hosts attached to nonstandard satellites must deviate from the 1274 normal I-field usage when connecting to hosts on another switch. 1275 It is suggested that all host implementations have this capability 1276 as long as the nonstandard switches remain in use. The host must 1277 know, by some manual configuration method, that it is connected to 1278 a nonstandard switch, and it must have its "link port" number; 1279 that is, the number of the port on the satellite that is connected 1280 to the hub. 1282 The normal I-field format for a 32-bit connection, per the 1283 Internet Draft, is this: 1285 31 26 23 11 0 1286 +---------+---+-+-----------------------+-----------------------+ 1287 |0 0 0 0 0|x 1|C| Unused | Destination Address | 1288 +---------+---+-+-----------------------+-----------------------+ 1290 The special I-field format is: 1292 31 26 24 15 4 3 0 1293 +---------+---+-+---------------+-----------------------+-------+ 1294 |0 0 0 0 0|x 1|C| Unused | Destination Address | Link | 1295 +---------+---+-+---------------+-----------------------+-------+ 1297 This I-field is altered by shifting the lower 24 bits left by four 1298 and adding the link port number. Camp-on is optional, and the PS 1299 field is set to 01 or 11 (the host's option) as if the switch 1300 supported logical address mode. All other I-field bits are set to 1301 zero. When the host requests a connection with this I-field, the 1302 switch selects a connection through the link port to the hub, and 1303 shifts the lower 24 bits of the I-field right by four bits. The 1304 link port number is discarded and the I-field passed through to 1305 the hub is a proper HIPPI-SC I-field selecting logical address 1306 mode. 1308 A host on a nonstandard satellite may use the special I-field 1309 format for all connection requests. If connecting to another host 1310 on the same satellite, this will cause the connection to take an 1311 unnecessarily long path through the hub and back. If an 1312 optimization is desired, the host can be given additional 1313 information to allow it to use the standard I-field format when 1314 connecting to another host on the same switch. This information 1315 could consist of a list of the other hosts on the same switch, or 1316 the details of address formation, along with the switch number of 1317 the local satellite, which would allow the host to analyze the 1318 switch address to determine whether or not the destination is on 1319 the local switch. This optimization is fairly complicated and may 1320 not always be worthwhile.