home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pktway-protocol-spec-02.txt < prev    next >
Text File  |  1996-10-29  |  117KB  |  2,768 lines
  1.  
  2. Network Working Group                                        Danny Cohen
  3. Internet Draft                                                   Myricom
  4. expires in six months                                         Craig Lund
  5.                                                        Mercury Computers
  6.                                                             October 1996
  7.  
  8.  
  9.             Proposed Specification for the PacketWay Protocol
  10.  
  11.                   draft-ietf-pktway-protocol-spec-02.txt 
  12.  
  13.                expires April 1997
  14.  
  15. Status of this Memo
  16.  
  17.    This document is an independent submission.  Comments should be
  18.    submitted to the PktWay@myri.com mailing list.
  19.  
  20.    Distribution of this memo is unlimited.
  21.  
  22.    This document is an Internet-Draft.  Internet Drafts are working
  23.    documents of the Internet Engineering Task Force (IETF), its Areas,
  24.    and its Working Groups.  Note that other groups may also distribute
  25.    working documents as Internet Drafts.
  26.  
  27.    Internet Drafts are draft documents valid for a maximum of six
  28.    months, and may be updated, replaced, or obsoleted by other
  29.    documents at any time.  It is not appropriate to use Internet
  30.    Drafts as reference material, or to cite them other than as a
  31.    "working draft" or "work in progress."
  32.  
  33.    To learn the current status of any Internet-Draft, please check the
  34.    "1id-abstracts.txt" listing contained in the internet-drafts Shadow
  35.    Directories on:
  36.  
  37.       ftp.is.co.za (Africa)
  38.       nic.nordu.net (Europe)
  39.       ds.internic.net (US East Coast)
  40.       ftp.isi.edu (US West Coast)
  41.       munnari.oz.au (Pacific Rim)
  42.  
  43. Abstract
  44.  
  45.    PacketWay's goal is to move data from a "Source" (a node on a System
  46.    Area Network) to a "Destination" (another node, probably on another
  47.    System Area Network) at the high performance available on these SANs.
  48.    Sources and Destinations can be physical things (a processor or a
  49.    smart memory board).  They can also be "logical" things, such as a
  50.    group of cooperating processes.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.                  [ B l a n k ]
  74.  
  75. PktWay-WG                         <01>                          PktWay-WG
  76.  
  77.  
  78.  
  79.  
  80.                     
  81.                  D  R  A  F  T
  82.  
  83.                  October 1996
  84.                     
  85.                     
  86.                     
  87.              Proposed Specification for the
  88.                     
  89.                PacketWay Protocol
  90.                ------------------
  91.                     
  92.                     
  93.               Danny Cohen (Myricom)
  94.              Craig Lund (Mercury Computers)
  95.               with considerable help from
  96.         Tony Skjellum (MSU), Thom McMahon (MSU)
  97.             and Robert George (MSU)
  98.  
  99.  
  100.                    PktWay-WG
  101.                     
  102.  
  103.                    This page....................................1
  104.                    Cheat-sheet..................................2
  105.            Part-1: PacketWay EEP Messages.......................3
  106.                    Notations....................................4
  107.                    PktWay Message Structure.....................5
  108.            Part-2: PacketWay RRP Messages......................15
  109.                    The Basic Model.............................16
  110.                    Node Attributes.............................17
  111.                    Routing Tables..............................18
  112.                    Inter-SAN Mapping...........................19
  113.            Part-3: PacketWay RRP Message Format................21
  114.                    RRP Message Types...........................21
  115.                    The Structure of RRP messages...............22
  116.                    RRP Record Format...........................25
  117.                    RRP Message Examples........................29
  118.        Appendix-A: Enumerations................................37
  119.        Appendix-B: Example of the Mapping Process..............41
  120.        Appendix-C: Example of the use of RRP for discovery.....45
  121.        Appendix-D: Glossary....................................53
  122.        Appendix-E: Acronyms and Abbreviations..................55
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.       Please send your comments re this draft to <Cohen@myri.com>.
  131. Cheat-sheet                         <02>                          PktWay-WG
  132.  
  133.  
  134. PktWay at a Glance
  135. +-----------------
  136.  
  137.  
  138.        2   6               24                     16                16
  139. PW-Hdr+-+------+-------+--------+---------+--------+--------+--------+--------+
  140.    PH1|V|  P   |    Destination-Address   |  Type-Extension |   Packet-Type   |
  141.       +-+-+---++--------------------------+-+------+--------+-----------------+
  142.    PH2| E | PL|   Data-Length (8B-words)  |h|  RZ  |0     Source-Address      |
  143.       +---+---+--------+--------+---------+-+------+--------+--------+--------+
  144.         4    3             25              1   7    1           23
  145.  
  146.  
  147.  
  148.       +--------+--------+--------+--------+--------+--------+--------+--------+
  149. L2RH  |vv000000|11LLLLLL|  SR01  |  SR02  |........|........|........|........|
  150.       +--------+--------+--------+--------+--------+--------+--------+--------+
  151.  
  152.  
  153.  
  154.  
  155.       +--------+--------+--------+--------+--------+--------+--------+--------+
  156. Symbol|vv000000|1011ssss|ssssssss|ssssssss| Length |  data  |........|........|
  157.       +--------+--------+--------+--------+--------+--------+--------+--------+
  158.  
  159.  
  160.  
  161. Opt'l +--------+--------+--------+--------+--------+--------+--------+--------+
  162. fields|TCtttttt|LLLLLLLL|  data  |........|........|........|........|........|
  163.       +--------+--------+--------+--------+--------+--------+--------+--------+
  164.       T: 0=optional, 1=mandatory;  C: 0=more fields follow, 1=last field
  165.  
  166.  
  167.  
  168.       RRP-messages: GVL2, L2SR, RDRC, TELL, INFO, HRTO, WRU, GVRT, RTBL;
  169. RRP   +--------+--------+--------+--------+--------+--------+--------+--------+
  170. Record|  RTyp  |   PL   |       RL        |........|........|........|........|
  171.       +--------+--------+--------+--------+--------+--------+--------+--------+
  172.       RTyp: ADDR, NAME, CAPA, LADR, SRQR, MTUR, RCVF, SNID, RTHD, GVSC, SCID;
  173.  
  174. XRT = {SN, SAN-ID, RCVF, CSR+Q, MTUR, LRT}
  175. LRT = For each node: {ADDR,NAME,CAPA,LA,SRQR} }
  176. PktWay-WG                         <03>                          EEP-msgs
  177.  
  178.  
  179.             Part-1: PacketWay EEP messages
  180.             -------------------------------
  181.  
  182.  
  183. PacketWay is an open family of specifications for internetworking
  184. high-performance System Area Networks (SANs) and high-performance LANs. 
  185.  
  186. Even though most modern SANs have much in common (such as high rates,
  187. low latency, low BER, being packet networks made of point-to-point links
  188. with flow control, and the usage of source routes), each is an island
  189. upon itself, incapable of direct intercommunications with other SANs.
  190. PacketWay's goal is to "internet" such SANs and high-performance LANs.
  191.  
  192. This part describes the PacketWay EEP (End-to-End Protocol).  Part-2
  193. describes the PacketWay RRP (Router-to-Router Protocol).  Part-3 defines
  194. the format of the RRP packets.  Other PacketWay layers, such as the
  195. PacketWay Server Layer, will be described in documents to be provided
  196. later.
  197.  
  198. Some basic PacketWay terminology requires explanation.  PacketWay
  199. interconnects high-performance System Area Networks (SANs).  Each
  200. SAN contains some "nodes".  At least one node in each SAN is also
  201. a PacketWay "router", connected to more than one SAN.
  202.  
  203. PacketWay's goal is to move data from a "Source" (e.g., a node on
  204. a SAN) to a "Destination" (e.g., a node on another SAN).  Sources and
  205. Destinations can be physical entities (a processor or a smart memory
  206. board).  They can also be logical entities (a group of cooperating
  207. processes).  These nodes include sources, destinations, and routers.
  208.  
  209. Within each instance of PacketWay all nodes have unique 24-bit
  210. PacketWay addresses.  A system designer can assign these "PacketWay
  211. Addresses" manually.  Alternatively, the optional PacketWay Server
  212. Layer provides a way to assign and discover addresses dynamically.
  213. Throughout this document "address" always means the 24-bit PacketWay
  214. address.
  215.  
  216. SANs also may have PacketWay addresses, aka SAN-IDs.  They are also
  217. 24-bit quantities, sharing the address space with the nodes.  These
  218. addresses, of SANs and nodes, are unique within each instance of
  219. PacketWay.
  220.  
  221. To optimize for performance, PacketWay has a data transfer mode that
  222. leverages the native message routing schemes used within the SANs.
  223. This mode uses a "Planned Transfer" paradigm.  During the planning phase,
  224. a source collects information on optimal routes to a destination,
  225. expressed in the various native formats of the intervening SANs.
  226. A source later uses this information for low latency transfers to that
  227. destination.  In PacketWay, the transfer phase of a Planned Transfer
  228. is called "L2-forwarding."  Appendix-C shows an example of the planning
  229. phase.
  230. EEP-msgs                         <04>                          PktWay-WG
  231.  
  232.  
  233. PacketWay also optionally supports a more traditional data transfer
  234. mode that requires no planning.  Such transfers specify the destinations
  235. by their addresses only.  PacketWay calls this more traditional
  236. approach "L3-forwarding."
  237.  
  238. PacketWay packets travel through SANs encapsulated inside the native
  239. packet format of each SAN, by being prefixed with the routing header and
  240. followed by the tail as required by that SAN.
  241.  
  242. PacketWay packets get to their destinations by Level-2 (L2) forwarding,
  243. Level-3 (L3) forwarding, or a combination thereof.
  244.  
  245. In L3-forwarding (similar to IP forwarding), the L2-routing through each
  246. SAN is determined by an inter-SAN router upon entering that SAN.  The
  247. router prefixes the packet with an L2 routing header (such as a source
  248. route) corresponding to the destination address specified in the packet.
  249. It is a task for that router to determine the L2-routing-header
  250. corresponding to the given PacketWay-address.
  251.  
  252. In L2-forwarding the source prefixes the packet with all the L2-routing
  253. headers needed along the path to the destination.  Each router has only
  254. to get the L2-routing-header from the leading L2RH (L2-Routing-Header
  255. record) that was provided by the source.
  256.  
  257. PacketWay does not provide Segmentation and Reassembly (SAR).
  258. Therefore, the length of a packet cannot exceed the minimum MTU
  259. (Maximum Transmission Unit) along its path.
  260.  
  261. PacketWay does not detect errors.  It only gathers error detection
  262. information from the SANs and inter-SAN routers that a packet transits.
  263.  
  264. Packetway is big-endian 8B-word based.
  265.  
  266.  
  267. NOTATIONS
  268. +--------
  269.  
  270. 8B means "8-byte" (64 bits).
  271.  
  272. 0x indicates hexadecimal values (e.g., 0x0100 is 2^8=256-decimal).
  273.  
  274. 0b indicates binary values (e.g., 0b0100 is 4-decimal).
  275.  
  276. xxx indicate a field that is discarded without any checking (e.g., padding).
  277.  
  278. [fff] indicates that fff is an optional field.
  279.  
  280. All length fields do not include themselves, and therefore may always be
  281. zero.
  282. PktWay-WG                         <05>                          EEP-msgs
  283.  
  284.  
  285. The PacketWay MESSAGE STRUCTURE
  286. +------------------------------
  287.  
  288. PacketWay messages have 6 components, including 4 optional ones:
  289.  
  290. [1]: [Optional Sequence of L2-Routing-Headers Records (L2RHs) and Symbols]
  291. [2]: EEP Header (16 bytes)                      (PH)
  292. [3]: [Optional Header fields]                         (OH)
  293. [4]: [Optional, Most likely: Data Block]             (DB)
  294. [5]: [Optional trailer fields]                        (OT)
  295. [6]: EEP Trailer (8 bytes)                            (TAIL)
  296.  
  297. Re [1]: as explained later, if the 9th+10th bits of a messages are 0b11
  298. then the message starts with an L2RH (or a symbol).  If the 9th through
  299. the 12th bits of a message are 0b1011 then this message starts with a
  300. "symbol".  The other values of these bits indicates the lack of L2RH and
  301. symbols and that the message begins with the EEP-header.
  302.  
  303. Re [3]: if the h-bit in the EEP header [2] is 1 then there are optional
  304. header fields.  The sequence of these header fields is terminated with a
  305. word whose 2 MSBytes are 0xFF00.
  306.  
  307. Re [4]: if DL>0 in the EEP header then a Data Block (DB) is
  308. included in this message.
  309.  
  310. Re [5]: the optional header fields, [3], may indicate that some optional
  311. trailer fields are present after the DB, [4].  The formats of the
  312. trailer fields are defined by the optional header fields.
  313.  
  314. It is expected that most messages will have Data Blocks (DB), and that
  315. most messages will not have Optional Header fields (OH), nor trailer
  316. fields (OT).
  317.  
  318. [1], the leading L2RHs and symbols are consumed by the SANs before
  319. reaching the destination which receives only the other components,
  320. [2] through [6].  These parts, [2] to [6], constitute the end-to-end
  321. protocol of PacketWay.
  322.  
  323. TAIL, the EEP trailer, [6] may be modified along the way to the
  324. destination, unlike [2], [3] and [4], which arrive exactly as sent
  325. by the source.  Therefore, the TAIL should not be CRCed.
  326.  
  327. Each PacketWay packet may be first L2-forwarded (zero or more times)
  328. before being L3-forwarded (zero or more times).
  329.  
  330. Although PacketWay headers and trailers are always in Big Endian order,
  331. the byte order of the Data Block is not defined by PacketWay.
  332.  
  333. Since all the elements of PacketWay (L2RHs, EEP-headers, optional
  334. fields, data, and EEP-trailers) are always multiples of 8B-words,
  335. it is recommended that PacketWay headers (and data) be aligned on
  336. 8B-boundaries.
  337. EEP-msgs                         <06>                          PktWay-WG
  338.  
  339.  
  340.  
  341. [1]: Optional Sequence of L2-Routing-Headers Records (L2RHs) and Symbols
  342. +-----------------------------------------------------------------------
  343.  
  344. A PacketWay source may specify native routes, by placing the native
  345. routes before the PacketWay Header.  The native routes (for all SANs and
  346. LANs beyond the initial one) must appear within a sequence of PacketWay
  347. L2-Routing-Header records (L2RH).
  348.  
  349. The contents of the L2RH are totally SAN dependent, with the exception
  350. of the first 2 bytes that distinguish this record from a EEP-header and
  351. also provide the Length (L) indicating the number of routing bytes of
  352. that L2RH (not including these 2 bytes).
  353.  
  354. L is always between 0 and 63.  The total number of bytes in the L2RH is
  355. L+2, packed in [(L+9)/8] 8B-words (where the square brackets [] indicate
  356. the integer part of the quantity within).
  357.  
  358. It's up to each SAN to provide padding, if needed, to fill the L2RH words.  
  359.  
  360. Each L2RH is defined by the entity that will process it.  In addition
  361. to routing information per se, it may also include demuxing information
  362. such as a local message-type.  For example, over Myrinet it should end
  363. with 0x0300 which is the Myrinet-type assigned to PacketWay.
  364.  
  365. The L2 header must contain enough information to allow a router to
  366. quickly create any necessary local routing headers and trailers.
  367. PacketWay implementations that support L2-forwarding must document
  368. their unique L2 header requirements.
  369.  
  370. When a PacketWay message is encapsulated inside any native SAN message
  371. (Paragon or Myrinet, for example), it's up to that SAN to distinguish
  372. between it and its own native packets.  This is not a PacketWay issue.
  373. For example, Myrinet uses its Message-Type to recognize PacketWay
  374. messages.
  375.  
  376. PacketWay-Routers on the boundaries between SANs are asked to forward
  377. packets with either L2 or L3 routings.  The former start with an L2RH,
  378. (having both its 9th and its 10th bits set to 1), whereas the latter
  379. start with PacketWay-addresses (with other values for these 2 bits).
  380.  
  381. FORMAT:
  382.  
  383. Each L2RH is in the format:
  384.  
  385. +--------+--------+--------+--------+--------+--------+--------+--------+
  386. |vv000000|11LLLLLL|  SR01  |  SR02  |........|........|........|  xxx   | L2RH
  387. +--------+--------+--------+--------+--------+--------+--------+--------+
  388.  
  389. The first 2 bits are 0b00 for the working version of the protocol.
  390. They may have other values for experimental versions.
  391.  
  392. The next 6 bits should be all zeroes.
  393. PktWay-WG                         <07>                          EEP-msgs
  394.  
  395.  
  396. The next two bits must be 0b11 to indicate that this is an L2RH record.
  397. The next 6 bits are the byte count of the routing information that
  398. starts in the third byte and is followed by as many padding bytes as
  399. needed to fill to the next 8B-boundary.  The length of the routing
  400. information is expected to be between 1 and 63 bytes.
  401.  
  402. This 0b11 was chosen to be consistent with the 0b11 of PktWay-addresses,
  403. as described in [2] below.
  404.  
  405.  
  406. EXAMPLES:
  407.  
  408. An L2RH with an SR with 5 routing bytes:
  409.  
  410.         0b11    5     #1       #2       #3       #4       #5    padding
  411. +--------+--------+--------+--------+--------+--------+--------+--------+
  412. |vv000000|11000101|  SR01  |  SR02  |  SR03  |  SR04  |  SR05  |  xxx   | L2RH
  413. +--------+--------+--------+--------+--------+--------+--------+--------+
  414.           ^^      |<---------- routing information ----------->|
  415.  
  416. An L2RH with an SR with 13 routing bytes:
  417.  
  418.         0b11  L=13    2        3        4        5        6        7
  419. +--------+--------+--------+--------+--------+--------+--------+--------+
  420. |vv000000|11001101|  SR01  |  SR02  |  SR03  |  SR04  |  SR05  |  SR06  | L2RH
  421. +--------+--------+--------+--------+--------+--------+--------+--------+
  422. |  SR07  |  SR08  |  SR09  |  SR10  |  SR11  |  SR02  |  SR13  |  xxx   |
  423. +--------+--------+--------+--------+--------+--------+--------+--------+
  424.  
  425.  
  426. Symbols (to be defined later) may be mixed among the L2RHs, before the
  427. EEP-header.  Their format is:
  428.  
  429. +--------+--------+--------+--------+--------+--------+--------+--------+
  430. |vv000000|1011ssss|ssssssss|ssssssss| Length |  data  |........|........|Symbol
  431. +--------+--------+--------+--------+--------+--------+--------+--------+
  432.  
  433.  
  434.  
  435. [2]: EEP Header (16 bytes) (PH)
  436. +------------------------------
  437.  
  438.  2   6               24                     16                16
  439. +-+------+-------+--------+---------+--------+--------+--------+--------+
  440. |V|  P   |    Destination-Address   |  Type-Extension |   Packet-Type   |PH1
  441. +-+-+---++--------------------------+-+------+--------+--------+--------+
  442. | E | PL|   Data-Length  (8B-words) |h|  RZ  |0     Source-Address      |PH2
  443. +---+---+--------+--------+---------+-+------+--------+--------+--------+
  444.   4    3             25              1   7                24              
  445.  
  446. These fields are described below.
  447. EEP-msgs                         <08>                          PktWay-WG
  448.  
  449.  
  450.  
  451. [3]: Optional Header Fields (OH)
  452. +-------------------------------
  453.  
  454. A PacketWay-message has optional header fields (OH) if the Option-Flag
  455. (h) is set to 1 in the EEP-header.
  456.  
  457. Each OH is in the format:
  458.  
  459. +--------+--------+--------+--------+--------+--------+--------+--------+
  460. |TCtttttt|LLLLLLLL|  data  |........|........|........|........|........| OH
  461. +--------+--------+--------+--------+--------+--------+--------+--------+
  462.  
  463. The first byte indicates the TYPE of this optional header field (OH-TYPE).
  464.  
  465. The first bit of the first byte, T, indicates the type of this OH-TYPE:
  466.  
  467.  T=0: Optional (may drop this field if this OH-TYPE is unknown)
  468.  T=1: Mandatory (should not process this message if this OH-TYPE is unknown)
  469.  
  470. The second bit of the first byte, C, indicates that there are no more
  471. trailer fields (i.e., this is the last field of this message).
  472.  
  473.  C=0: More trailer fields follow
  474.  C=1: End of Optional fields group (OH or OT)
  475.  
  476. The other 6 bits of this byte, tttttt, are the OH-TYPE.
  477.  
  478. The second byte is the byte-count of the data for this field that starts
  479. in the third byte, and is padded with as many padding bytes as needed to
  480. fill 8B-words.  E.g., L=(0-6) implies one 8B-word. L=(7-14) implies two.
  481. L does not include itself, and can range from 0 to 255.
  482.  
  483. The Enumeration Appendix (A6) will define the values for the type field
  484. of the OH.  The value 0x3F is assigned to indicate last OH in a message.
  485.  
  486.  
  487. Example: An Optional Header Field (OH) with a mandatory OH-TYPE and 4
  488. data bytes:
  489.                L=4    #1       #2       #3       #4    padding  padding
  490. +--------+--------+--------+--------+--------+--------+--------+--------+
  491. |1Ctttttt|00000100| data01 | data02 | data03 | data04 |  xxx   |  xxx   | OH
  492. +--------+--------+--------+--------+--------+--------+--------+--------+
  493.                   |<------------- value ------------->|
  494. PktWay-WG                         <09>                          EEP-msgs
  495.  
  496.  
  497. [4]: Optional Data Block (DB)
  498. +----------------------------
  499.  
  500. The DB is free for applications to use in any way.  Routers must not
  501. modify this field.
  502.  
  503. The DB has DL 8B-words, including optional padding (at the end) of PL
  504. bytes.  Hence, the number of data bytes is 8*DL-PL.  Both DL and PL are
  505. defined in the EEP-header.
  506.  
  507. The maximum length of the DB is 8*(2^25-1)B=256MB.
  508.  
  509.  
  510. [5]: Optional Trailer Fields (OT)
  511. +--------------------------------
  512.  
  513. A PacketWay-message has optional trailer fields (OT) if so indicated in
  514. an Optional Header field, e.g., an OH field may indicate that a CRC64
  515. follows the Data Block.
  516.  
  517.  
  518. [6]: EEP Trailer (TAIL)
  519. +----------------------
  520.  
  521. The TAIL consists of only the Error Indication (EI) field which is a
  522. single 8B-word.
  523.  
  524. Routers may start forwarding packets toward their destinations before
  525. detecting transmission errors (wormhole routing).  The EI field provides
  526. such routers with a means to append an error indication to the end of a
  527. packet.
  528.  
  529.  
  530. An all zero EI value means that no error was indicated.
  531. Any non zero EI value indicates one or more errors.
  532.  
  533. The packet source will usually initialize the EI field to all zeros.
  534. However, as an alternative example, a memory board may create a packet
  535. with a non zero EI field (EI=1) that indicates that a parity error was
  536. detected by the memory board.
  537.  
  538. Each router does an arithmetic left shift, on the EI field by one bit
  539. unless its MSbit is 1.  Routers that detect transmission errors also set
  540. the LSbit (after the shift) to 1.
  541.  
  542. This provides the ability to identify which routers have indicated
  543. errors (if the route is known).
  544. EEP-msgs                         <10>                          PktWay-WG
  545.  
  546.  
  547. THE DETAILS OF THE EEP-HEADER, [2]
  548. +---------------------------------
  549.                                       Bytes.bits
  550.       Version                 (V)      0.2
  551.       Priority                   (P)      0.6
  552.       Destination Address        (DA)     3.0
  553.       Packet Type Extension      (TE)     2.0
  554.       Packet Type                (PT)     2.0
  555.       Endianness                 (E)      0.4
  556.       Padding Length             (PL)     0.3
  557.       Data Length                (DL)     3.1
  558.       Options flag               (h)      0.1
  559.       Reserved                   (RZ)     0.7
  560.       Source Address             (SA)     3.0
  561.  
  562.  
  563. Version (V) 2 bits
  564.  
  565.   This field is static.  Its 2 bits are 0b00 for the working version of
  566.   the protocol.  These bits should have other values for experimental
  567.   versions.
  568.  
  569. Priority (P) unsigned integer, 6 bits
  570.  
  571.   All ones is the highest priority, and all zeroes the lowest.  Ideally,
  572.   packets with higher priority should gain access to contested resources
  573.   before packets with lower priority.  Implementations may ignore the
  574.   Priority field.
  575.  
  576. Destination Address (DA) 24 bits
  577.  
  578.   This field contains the PacketWay address of the destination.
  579.  
  580.   Addresses are unique within each instance of PacketWay.  Nodes
  581.   should have addresses assigned to them.  The method of assigning
  582.   addresses to PacketWay nodes is not specified here.
  583.  
  584.   Examples of potentially addressable PacketWay nodes include: groups
  585.   of cooperating processes, an entire MPP, or each of an MPP's many
  586.   processors or processes.
  587.  
  588.   All half-routers (as defined in Part-2) must have addresses so that
  589.   they can exchange control and configuration packets with other
  590.   routers.
  591.  
  592.   The 24-bit PacketWay address space is divided into several segments,
  593.   each identified by the most significant bit(s) of the address.
  594.  
  595.               MSbits | Segment  | Count | Range
  596.             ---------+----------+-------+-------------------
  597.                0XXX  | Physical |   8M  | 0x000000-0x7FFFFF
  598.                100X  | Unused   |   2M  | 0x800000-0x9FFFFF
  599.                1010  | Logical  |   1M  | 0xA00000-0xAFFFFF
  600.                1011  | Symbols  |   1M  | 0xB00000-0xBFFFFF
  601.                11XX  | L2RH     |   4M  | 0xC00000-0xFFFFFF
  602. PktWay-WG                         <11>                          EEP-msgs
  603.  
  604.  
  605.   This 0b11 was chosen for L2RH to be consistent with the 0b11
  606.   indication of L2RHs, as described in [1] above.
  607.  
  608.   LAs, "Logical Addresses", (for broadcast and for multicast groups)
  609.   are also in this address space.  An address is a "Logical Address"
  610.   if its 4 MSbits are set to 0b1010.
  611.  
  612.   Certain RRP messages specify addresses either as a unique address or
  613.   as a set of addresses, by (min,max) or by (value,mask).
  614.  
  615.   A few Physical-addresses are reserved:
  616.  
  617.     0x000000  Illegal
  618.  
  619.     0x7FFFFE ("Hey-You!") This address could be used at power up
  620.          to address nodes or routers, over point-to-point links.
  621.          ("If you receive it, it's for you.")
  622.  
  623.     0x7FFFFF (Broadcast) This address is reserved for broadcast
  624.          operations which may be added in later versions.
  625.          ("If you receive it, it's for you.")
  626.  
  627.  
  628. Type Extension (TE) 2 bytes
  629.  
  630.   An extension of the following PT field.
  631.  
  632.  
  633. Packet Type (PT) 2 bytes
  634.  
  635.   The intent of the PT field is to provide all the information needed
  636.   for demuxing in support of multiple protocol layers (such as in
  637.   support of zero copy TCP).  Whereas traditional protocol layering
  638.   requires several stages of sequential demuxing, PacketWay is expected
  639.   to provide enough information to support a single combined demuxing.
  640.  
  641.   PT values to support popular parallel programming APIs such as MPI
  642.   will be defined.  The Enumeration Appendix (A1) defines several values
  643.   for this PT field.
  644.  
  645.   Some PTs use also the preceeding 2 bytes of the Type Extension (TE)
  646.   field for passing PT-specific parameters.
  647.  
  648.   However, layered protocols cannot be ignored.  The PT field can also
  649.   define data blocks as containing IP, SNMP, ATM, Ethernet, and other
  650.   popular layered protocols.  The PT will be then used for that purpose
  651.   as done throughout the internet (e.g., "ether-types").
  652. EEP-msgs                         <12>                          PktWay-WG
  653.  
  654.  
  655.   For example, here are PT values a memory board may need:
  656.  
  657.      PT        Meaning
  658.   ---------    --------------------------------------------------------
  659.   MEM-WRITE -- Treat the first few bytes of the Data Block as a local
  660.                memory-address and write the remaining data into memory.
  661.  
  662.   MEM-READ  -- Treat the data block as 2 memory-addresses and a
  663.                byte count.  Generate a return WRITE packet containing
  664.            the first address, followed by the appropriate data,
  665.            that was read from the second address.
  666.  
  667.   The PT field will also indicate the commands used in the PacketWay
  668.   Router-to-Router configuration and control Protocol (RRP).
  669.  
  670.   We will define a special PT value that specifies that the Data Block
  671.   contains an embedded PacketWay message, complete with another EEP
  672.   header, and, potentially, prefixed L2-Routing-Headers.  This feature
  673.   will allow to use L3-routing to an intermediate node, followed by
  674.   L2-routing from there to the final destination.
  675.  
  676.   Special Types
  677.  
  678.     RRP - PacketWay's Router-to-Router protocol (see Part-2).
  679.  
  680.     ERR - Error reporting packet, usually sent to the Source Address
  681.           (SA, see below) in response to a PacketWay message that
  682.           could not be properly handled, such as "Destination Unknown."
  683.           The TE indicates the nature of the error (e.g., UNK) as
  684.           defined in the Enumeration Appendix (A4).
  685.  
  686.  
  687. Endianness (E), 4 bits
  688.  
  689.   The idea is that if the SAN interface of the receiving-node detects
  690.   Endianness that is different than its own and if the entire Data Block
  691.   (DB) consists of N-bytes fields, then it may kick in byte-swapping
  692.   hardware for N-byte fields, saving much work for the receiving node.
  693.  
  694.   e, the first bit (MSbit) of E, indicates that the DB is in Big-Endian
  695.   order (e=0) or in Little-Endian order (e=1).  The next 3 bits could
  696.   control hardware byte swapping, if any, which assumes that all the
  697.   data consists of words of the same length.
  698.  
  699.     e000: don't swap, it's 8-bit data
  700.     e001: swap as if all the data is  16-bit words
  701.     e010: swap as if all the data is  32-bit words
  702.         e011: swap as if all the data is  64-bit words
  703.     e100: swap as if all the data is 128-bit words
  704.     e101: illegal and reserved for future use
  705.     e110: illegal and reserved for future use
  706.     e111: illegal and reserved for future use
  707. PktWay-WG                         <13>                          EEP-msgs
  708.  
  709.  
  710. Pad Length (PL) unsigned integer, 3 bits
  711.  
  712.   The number of padding bytes that were added at the end of the DB
  713.   (i.e., from the end of the data to the end of the DB).  PL can be
  714.   between 0 and 7.
  715.  
  716.  
  717. Data Length (DL) unsigned integer, 25 bits
  718.  
  719.   Length of the data block (not including the EEP-header, OH, and TAIL
  720.   in 8B-words, including any optional padding.  Hence, the net length of
  721.   the Data Block is 8*DL-PL bytes.  The minimum is zero, and the maximum
  722.   length is (2^25-1)*8 bytes ~ 2^28 ~ 256 MBytes.
  723.  
  724.  
  725. Optional Header-Field Flag (h) 1 bit
  726.  
  727.   This bit is set to 1 if there is one (or more) optional header fields
  728.   following the standard 16-byte EEP-header.
  729.  
  730.  
  731. Reserved (RZ) 7 bits
  732.  
  733.   This field is reserved for future use.  Applications should neither
  734.   use it, nor count on others not to use it.  In this version it should
  735.   be always set to zero (0b0000000).
  736.  
  737.  
  738. Source Address (SA) 24 bit
  739.  
  740.   This field contains the physical address of the packet's original
  741.   source in the same format as DA.  However, unlike DA, the SA must
  742.   be a physical address.
  743.  
  744.   Filling in this field is optional.  A value of zero means that the SA
  745.   is not specified.
  746.  
  747.   Routers may use this field to identify the sender to which error
  748.   messages may be returned.
  749. EEP-msgs                         <14>                          PktWay-WG
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.                  [ B l a n k ]
  769. PktWay-WG                       <15>                            RRP-msgs
  770.  
  771.  
  772.             Part-2: PacketWay RRP messages
  773.             ------------------------------
  774.  
  775. PacketWay is an open family of specifications for internetworking System
  776. Area Networks (SANs).  This part describes the RRP (Router to Router
  777. Protocol) part of the PacketWay-protocol.  It is built on top of the
  778. PacketWay-EEP described in Part-1.  Part-3 defines and discusses the
  779. format of the RRP packets.
  780.  
  781. We introduce some new terminology within this document.  A PacketWay
  782. Router always bridges (at least) two SANs.  The Router consists of three
  783. parts: the "Half Router" (HR) attached to the first SAN, the HR attached
  784. to the second SAN, and their interconnection.
  785.  
  786. PacketWay does not define the nature of this interconnection.
  787. However, we believe the PCI Local Bus de facto standard will become
  788. a very popular link.
  789.  
  790. This document specifies a series of options that allow system designers
  791. to deploy PacketWay routers of varying levels of intelligence.  Each
  792. router is considered as a set of interconnected Half-Routers (HRs),
  793. each being a full fledged address-bearing node on some SAN.
  794.  
  795. There are several implementation levels of PacketWay, for nodes and
  796. for routers.  System designers may choose the level of implementation
  797. to best suit their needs.  The higher the implementation level, the
  798. more interoperability and adaptability result.
  799.  
  800. Node implementation levels:
  801.  
  802.     Level-A: Built-in L2 source routes
  803.     Level-B: Built-in L3 addresses (dynamic update of first HR)
  804.     Level-C: Requesting and receiving dynamic information
  805.  
  806. Level-A nodes send messages by using L2-forwarding, by specifying
  807. SRs (in L2RHs) that are hard-coded into them, without the ability
  808. to dynamically acquire or modify them.
  809.  
  810. Level-B nodes have, in addition, also the ability to send messages by
  811. using L3-forwarding, by specifying addresses that are hard-coded into
  812. them, without the ability to dynamically acquire them.  These nodes can
  813. ask HRs for the best first HR for any destination node (specified by its
  814. address) and for the SR to destination nodes.  In addition they can also
  815. handle Re-direct messages, telling them which HR to use for given nodes.
  816.  
  817. Level-C nodes can also locate nodes by asking HRs to provide the
  818. attributes of nodes specified by addresses, names, and/or capabilities.
  819. They also respond to such queries by reporting their own attributes.
  820.  
  821. Router implementation levels:
  822.  
  823.     Level-A: Forwarding according to L2 source routes
  824.     Level-B: Handling L3 addresses, and dynamic first HR (re-direct, etc)
  825.     Level-C: Supporting dynamic routing by nodes
  826.     Level-D: Dynamic inter-SAN routing, mapping, and discovery
  827. RRP-msgs                        <16>                            PktWay-WG
  828.  
  829.  
  830. HRs can support nodes of same (or lower) implementation level.
  831. We design for the highest implementation levels, but expect that
  832. some instances of PacketWay will use lower implementation levels.
  833.  
  834. Level-A routers support only L2-Forwarding, and do not support the
  835. planning phase of Planned Transfers.  Therefore, nodes which use
  836. Level-A routers must have the necessary native routes hard-coded
  837. (e.g., burned into a PROM somewhere).
  838.  
  839. Level-B routers also support L3-Forwarding, and advise nodes about the
  840. first HR to use for each destination.
  841.  
  842. Level-C routers add the planning phase of Planned Transfers (by
  843. supporting requests for routes).  Level-D routers exchange routing
  844. information with each other, allowing dynamic discovery and adaptation.
  845.  
  846.  
  847. THE BASIC MODEL
  848.  
  849. The basic model of PacketWay is a set of SANs (System Area Networks),
  850. each with its own conventions and protocols.
  851.  
  852. The interconnection between SANs is via PacketWay-routers.  A router
  853. between the SAN-A and the SAN-B is composed of two interconnected
  854. processes, each a fully-fledged node on a SAN.  These processes are
  855. known as HRs ("Half-Routers") or "SAN-interfaces."
  856.  
  857. These HRs may be implemented by two separate "boxes" with an inter-SAN
  858. communication link between them, or inside a single "multi-homed" box
  859. that has interfaces to both SANs, interconnected via some bus or SAN.
  860.  
  861. RRP defines (via message structure and behavior) the interactions
  862. between HRs, and between HRs and computing nodes.  RRP does not define
  863. the lower level protocols that deliver its messages (over links, or
  864. between processes in multi-homed routers).  In particular, RRP does not
  865. define the inter-SAN interconnection links between the HRs that are left
  866. for mutual agreements among the implementors.  These links are expected
  867. to range from serial fibers to PCI buses.  A PPP-like protocol may be
  868. defined later for these links.
  869.  
  870. It is assumed that each HR has a Routing Table (RT) for its own SAN
  871. (aka Local Routing Table, LRT), with (at least) the addresses of all
  872. the nodes, and the source routes to each of them from the HR.  This
  873. information could be dynamic or static, even manually configured.
  874. The HRs may (or may not) perform dynamic mapping of their SANs.
  875.  
  876. It is also assumed that each node, on each SAN/LAN, knows the SR to at
  877. least one HR on its SAN/LAN.
  878.  
  879. PktWay-WG                       <17>                            RRP-msgs
  880.  
  881.  
  882. In L2 operation under levels C and D, when a source node, SA, needs to
  883. send a message to a destination node, DA, it first asks any of the HRs
  884. on its [SA's] SAN for a source route (SR) from HR to DA.  That HR would
  885. (1) provide such an SR, or (2) reply with a "Re-direct" message,
  886. suggesting to ask another HR which is also on SA's SAN, or (3) report no
  887. knowledge of DA (using the UNK error message).
  888.  
  889. SA may ask more than one HR for SRs to the same DA and use any algorithm
  890. to choose which of these SRs to use.
  891.  
  892. RRP does not address caching the SRs.
  893.  
  894. In L3 operation, when a source node, SA, needs to send a message to a
  895. destination node, DA, it sends that message to any of the HRs on its
  896. SAN, using L2, expecting L3-forwarding to DA, using DA's PacketWay
  897. address.  That HR would either (1) forward the message toward DA, and
  898. possibly return to SA a "Re-direct" message, suggesting to use, in the
  899. future, another HR on SA's SAN for DA, or (2) report no knowledge of DA
  900. (using the UNK error message).
  901.  
  902. Under levels C and D, nodes may be located by PacketWay-addresses,
  903. names, or capabilities, but only addresses may be used for routing.
  904.  
  905.  
  906. NODE ATTRIBUTES
  907. +--------------
  908.  
  909. Each node has: Physical Address, Name, Capabilities, and Logical-Addresses
  910.  
  911.  Address (Physical): 3 bytes, flat, unique in this PacketWay
  912.  
  913.  Name:               flat, globally unique (e.g., IP address),
  914.                      arbitrary length
  915.  
  916.  Capabilities:       regular GP node, router, PacketWay-server, NFS,
  917.                      paging server, M/C server, DSP, printer, ....
  918.  
  919.                      Some capabilities may need additional parameters
  920.                      (e.g., SAN-ID for routers, and resolution+colors
  921.                      for printers).
  922.  
  923.              The capabilities are defined in the Enumeration
  924.              Appendix (A5).
  925.  
  926.  Logical-Addresses:  a set of (logical) addresses to which this node
  927.                      requests to listen.  Logical addresses designate
  928.                      multicast and broadcast groups.
  929.  
  930.                      The control of the Logical-Addresses (a la IGMP)
  931.                      is not defined in this document.
  932.  
  933.              The management of logical addresses (e.g., JOIN
  934.              and LEAVE) is not defined yet.
  935.  
  936. RRP-msgs                        <18>                            PktWay-WG
  937.  
  938. ROUTING TABLES (RTs)
  939. +-------------------
  940.  
  941. Routing tables provide the information needed for finding SRs to
  942. destinations specified by their addresses.  In Level-D they also
  943. provide means to identify nodes also by names and/or capabilities.
  944.  
  945. The RTs are based on "maps" for SANs prepared by "mappers", local
  946. nodes on the SANs with maps (i.e., routing tables, LRTs) of their SANs,
  947. obtained dynamically or statically.  The inter-SAN routing process
  948. depends on the exchange of these maps to form local and remote RTs.
  949.  
  950. The attributes of an RT are:
  951.  
  952.     SN         Serial Number of this RT (by RCVF)
  953.     SAN-ID     ID of the SAN which this RT describes
  954.     RCVF       List of Received-From physical addresses or SAN-IDs (history)
  955.     CSR+Q      Common Source Route for the entire RT and its Q
  956.     MinMTU     Min MTU for this RT (along the above CSR)
  957.     Local-RT   Node-Structures, for nodes on that SAN
  958.  
  959. The Local-RT has one or more Node-Structures for each node on this SAN.
  960. These Node-Structures are of the form:
  961.  
  962.     Address                 Physical address on this SAN
  963.     [Name]                  Optional
  964.     [Capabilities]          Optional
  965.     [Logical-Address(es)]   Optional: The LA(s) to which it listens
  966.     SR                    From the mapper to that node
  967.  
  968. Each SR entry (and the CSR, too) contains Q, the quality of the SR, an
  969. unsigned 16-bit integer.  The units are not defined here.  It is assumed
  970. that Q is monotonic (sort of analogous to latency, hence additive) with
  971. all-0 being the best and all-1 the worst.  
  972.  
  973. Until otherwise defined, let Q be an unsigned-integer in microseconds.
  974. In updating it, its value should be clipped to the maximum value (~64msec).
  975.  
  976. The CSR has a MinMTU which is the minimal MTU along the entire CSR.
  977.  
  978. The RCVF is the list of the physical addresses along which this RT was
  979. forwarded.  Its entries are either HR-addresses or SAN-IDs.
  980.  
  981. The RCVF could have been derived from the CSR, if only the HRs could
  982. parse the CSR and associate HR-addresses with SRs and SAN-IDs with
  983. HR-addresses, which should not be assumed.
  984.  
  985. Different RTs for the same SAN may be kept.  Each RCVF has its own SN.
  986.  
  987. The Node-Structure (in an RT) has SRs from the mapper (of that RT) to
  988. that node.  The CSR is an SR to the same mapper.  Hence, by catenating
  989. the CSR to the beginning of the SR in the Node-Structure, an SR is
  990. derived all the way to that node.
  991.  
  992. Each SAN has a unique SAN-ID, known to the HRs on it.  The SAN-IDs share
  993. the PacketWay-address space with the nodes.  Hence, a SAN-ID is also a
  994. unique 24-bit physical PacketWay-address (starting with a 0 bit).
  995. PktWay-WG                       <19>                            RRP-msgs
  996.  
  997.  
  998. INTER-SAN MAPPING (Level-D)
  999. +--------------------------
  1000.  
  1001. "Buddy-HRs" are HRs that are nodes on the same SAN.  The halves of the
  1002. a single router are called "twin-HRs" or "neighbors."
  1003.  
  1004. HRs use the following procedure to exchange RTs, from which they derive
  1005. routes to any node in the PacketWay.  Each HR interchanges RTs only
  1006. with its buddy-HRs (over their common SAN), and with its twin-HR.
  1007. Typically, RTs arriving from the twin are forwarded to all the buddies,
  1008. and RTs arriving from any buddy are forwarded to the twin.
  1009.  
  1010. This document does NOT define how HRs map their own SANs or how
  1011. they find their buddies.  It is the job of each SAN to provide this
  1012. information.
  1013.  
  1014. The procedure starts with each HR getting an RT for its own SAN.
  1015. Thereafter, whenever a new RT (including the local-RT) is received from
  1016. anywhere (or changes) it is processed by:
  1017.  
  1018.         if (I am already in this RCVF)           // ignore this RT
  1019.         if (new SN(RCVF) =< old SN(RCVF) )       // ignore this RT
  1020.         Keep this RT with:
  1021.                 SN(RCVF) = SN(RCVF) + 1
  1022.                 SAN-ID   = (as received in RT)
  1023.                 RCVF     = (RCVF, me)
  1024.                 CSR      = ( (me->Sender-of-RT), CSR )
  1025.                 Q(CSR)   = Q(CSR) + q(me->Sender-of-RT)
  1026.                 MinMTU   = Min(my-MTU, MinMTU)
  1027.                 Local-RT = (as received in RT)
  1028.  
  1029.         if (RT received from my twin-HR) {Send RT to all my buddy-HRs}
  1030.         if (RT received from a buddy-HR) {Send RT only to my twin-HR}
  1031.  
  1032. COMMENTS:
  1033.  
  1034. The MTU of the new RT is the minimum of its previous MTU and that of the
  1035. current SAN.
  1036.  
  1037. HRs must keep at least the best eXternal-RT (XRT) to any given SAN.
  1038. However, any HR may keep any number of best-XRTs (there is no need for
  1039. these numbers to be the same among all the HRs).
  1040.  
  1041. The SNs belong to the RCVF.  When a new RT arrives, it gets an SN which
  1042. is greater by 1 than that of the previous RT that has the same RCVF.
  1043. Hence, an RT with a higher SN should always replace an RT with a lower
  1044. SN and with the same RCVF.
  1045.  
  1046. An HR finds an SR (L2-route) from itself to the foreign node-D, by
  1047. finding an RT that has D in it, catenating the CSR of that RT in front
  1048. of the SR for D, as found in the RT.  The HR also should add their Qs to
  1049. get the total Q.
  1050.  
  1051. The best SR is found by repeating this action and looking for the route
  1052. with the smallest Q.
  1053. RRP-msgs                        <20>                            PktWay-WG
  1054.  
  1055.  
  1056. For L3-forwarding, the HR finds an RT that has D in it, and L2-forwards
  1057. the packet to the last address on the RCVF of that RT (i.e., to the
  1058. address that was most recently added to the RCVF).
  1059.  
  1060. When an HR receives an HR-DOWN (or a LINK-DOWN) error message, it finds
  1061. all the RTs that it has with that downed-HR (or link) in their RCVF
  1062. fields, and deletes them; then it forwards this error message to those
  1063. nodes from which these RT were received, and to those nodes to which
  1064. these RTs were sent.
  1065. PktWay-WG                       <21>                            RRP-format
  1066.  
  1067.  
  1068.          Part-3: PacketWay RRP Message Format
  1069.          -------------------------------------
  1070.  
  1071. RRP messages are PacketWay messages with PT="RRP" in their EEP-header.
  1072. The EEP-header is followed by some (zero or more) RRP-records according
  1073. to their RRP-type, followed (always) by the TAIL which is the EI field.
  1074.  
  1075. The RRP-records constitute the DB of the PacketWay-message.  They must
  1076. be in Big-Endians order, with e=0 in the EEP-header.
  1077.  
  1078. The RRP-Type is carried in the TE of the of the EEP-header.
  1079.  
  1080. Following are the RRP messages, with their RRP-type:
  1081.  
  1082. RRP MESSAGE SUBTYPES
  1083. +-------------------
  1084.  
  1085.  RRP-      Impl'n
  1086.  Type      Levels  Description
  1087. +-------   ------  -----------------------------------------------
  1088. [GVL2]        BCD  Please give me L2-routes to node (address)
  1089.            The reply to [GVL2] is [L2SR], [RDRC], or [ERR/UNK].
  1090. [L2SR]        BCD  Here are L2-routes to node (address)
  1091. [RDRC]        BCD  Re-direct to node (address) via a neighbor HR(address)
  1092. [TELL]         CD  Please tell me about node (address, name, capabilities)
  1093.            The reply to [TELL] is [INFO], or [ERR/UNK].
  1094. [INFO]         CD  Info about node (address, name, capabilities, LAs)
  1095.  
  1096. [HRTO]        BCD  Which HR should I use for node (address)
  1097.            The reply to [HRTO] is [RDRC], or [ERR/UNK].
  1098.  
  1099. [WRU?]         CD  Who/what-Are-You?
  1100.            The reply to [WRU?] is [INFO].
  1101.  
  1102. [GVRT]          D  Please give me your RTs
  1103. [RTBL]          D  Here is an RT
  1104.  
  1105. RRP also uses the following error messages:
  1106.  
  1107. [ERR/UNK]     BCD  Destination Unknown (address)
  1108. [ERR/HRDOWN]  BCD  HR Down
  1109. [ERR/LKDOWN]  BCD  Link Down
  1110. [ERR/GENERAL]ABCD  General error message
  1111.  
  1112. All these messages may be sent from nodes or from HRs, to nodes or
  1113. to HRs.
  1114.  
  1115. The format of these messages is defined in this part.
  1116. RRP-format                       <22>                            PktWay-WG
  1117.  
  1118.  
  1119. The RRP records are:
  1120.  
  1121.     RTyp   Description
  1122.     ----   ----------------------------------
  1123.     ADDR   Address
  1124.     NAME   Name
  1125.     CAPA   Capability
  1126.     LADR   Logical Addresses
  1127.     SRQR   Source Route and its Quality (SR,Q)
  1128.     MTUR   MTU (for the previous SRQR)
  1129.     RCVF   RCVF ("Received-From" list)
  1130.     SNID   SAN-ID
  1131.     RTHD   RT-Header
  1132.  
  1133.  
  1134. THE STRUCTURE OF THE RRP MESSAGES
  1135. +--------------------------------
  1136.  
  1137. The RRP-records are made of one or more 8B-words.  In the following the
  1138. RRP-type is in [] and its implementation level in ().  Each message ends
  1139. with an TAIL which is not shown here.
  1140.  
  1141. * [GVL2] (BCD) Please give me L2-routes from you to node (address)
  1142.  
  1143.         PH   (with [PT/TE]=[RRP/GVL2])
  1144.         ADDR (address of the node for which SR is requested)
  1145.  
  1146.  
  1147. * [L2SR] (BCD) Here are L2-routes to node (address)
  1148.  
  1149.         PH   (with [PT/TE]=[RRP/L2SR])
  1150.         ADDR (address of the node for which SR is provided)
  1151.         SRQR (SR with Q)
  1152.     MTUR (MTU for the above SR)
  1153.  
  1154.     This message may have several (SRQR,MTUR)s, one for each SR.
  1155.  
  1156.  
  1157. * [RDRC] (BCD) Re-direct to node (address) via a neighbor HR (address)
  1158.  
  1159.         PH   (with [PT/TE]=[RRP/RDRC])
  1160.         ADDR (address of the destination node for which Re-direct is issued)
  1161.         ADDR (address of the HR to be used for that destination node)
  1162.  
  1163.     The above addresses are expected to be physical (but they be
  1164.     otherwise). 
  1165. PktWay-WG                       <23>                            RRP-format
  1166.  
  1167.  
  1168. * [TELL] (CD) Please tell me about node (address | name | capabilities)
  1169.  
  1170.         PH   (with [PT/TE]=[RRP/TELL])
  1171.         ADDR (address of the node for which more information is requested)
  1172.      or
  1173.         PH   (with [PT/TE]=[RRP/TELL])
  1174.         NAME (name of the node for which more information is requested)
  1175.      or
  1176.         PH   (with [PT/TE]=[RRP/TELL])
  1177.         CAPA (capabilities for which nodes are requested)
  1178.  
  1179.     This message may have several CAPA's, one for each capability.
  1180.  
  1181.     [TELL] identifies a node by an address and/or a name and/or
  1182.     capabilities.  If more than one attribute is specified (e.g., an
  1183.     address and a name) any nodes that meets any of them should be
  1184.     considered (like an implied OR).
  1185.  
  1186.  
  1187. * [INFO] (CD) Info about node (address, name, capabilities)
  1188.  
  1189.         PH   (with [PT/TE]=[RRP/INFO])
  1190.         ADDR (address of the node for which more information is requested)
  1191.         NAME (name of the node for which more information is requested)
  1192.         CAPA (capabilities for which nodes are requested)
  1193.         LADR (Logical-Addresses for the requested node)
  1194.  
  1195.         This message may have several CAPA's, one for each capability.
  1196.         For nodes without NAME or LADR, these records are omitted.
  1197.  
  1198.         [INFO] provides all the known information about that node,
  1199.         address, name, capabilities, and logical-addresses. 
  1200.  
  1201. * [HRTO] (BCD) Which HR should I use for node (address)
  1202.  
  1203.         PH   (with [PT/TE]=[RRP/HRTO])
  1204.         ADDR (address of the node for which initial HR is requested)
  1205.  
  1206.  
  1207. * [WRU?] (CD) Who/what-Are-You?
  1208.  
  1209.         PH   (with [PT/TE]=[RRP/WRU?] and [DA]=0x7FFFFE)
  1210.  
  1211.  
  1212. * [GVRT] (D) Please give me your RTs
  1213.  
  1214.         PH   (with [PT/TE]=[RRP/GVRT])
  1215. RRP-format                       <24>                            PktWay-WG
  1216.  
  1217.  
  1218.  
  1219. * [RTBL] (D) Here is an RT
  1220.  
  1221.         PH   (with [PT/TE]=[RRP/RTBL])
  1222.         RTHD (RT-header, SN)
  1223.     SNID (SAN-ID)
  1224.         RCVF (RCVF)
  1225.         SRQR (CSR and its Q)
  1226.         MTUR (MTU)
  1227.         for each node: ADDR (address)
  1228.                        NAME (name, optional)
  1229.                        CAPA (capabilities, optional)
  1230.                        LADR (logical-addresses, optional)
  1231.                        SRQR (SRQR to that node)
  1232.  
  1233.  
  1234. * [ERR/UNK] (BCD) Destination Unknown (address)
  1235.  
  1236.         PH   (with [PT/TE]=ERROR/UNK)
  1237.         XXXX (XXXX of the Destination node for which the requested
  1238.           information is not available), where XXXX is the ADDR
  1239.           and/or NAME and/or CAPA of the node(s) about which this
  1240.           message is sent
  1241.  
  1242.  
  1243. * [ERR/HRDOWN] (BCD) HR Down (or Router-Down)
  1244.  
  1245.         PH   (with [PT/TE]=[ERROR/HRDOWN])
  1246.         ADDR (address of the HR that is down)
  1247.         ADDR (the other address of the router that is down)
  1248.  
  1249.  
  1250. * [ERR/LINKDOWN] (BCD) Link Down
  1251.  
  1252.         PH   (with [PT/TE]=[ERROR/LINKDOWN])
  1253.         ADDR (address of one end of the link that is down)
  1254.         ADDR (address of the other end of the link that is down)
  1255.  
  1256.  
  1257. * [ERR/GENERAL] (ABCD)
  1258.  
  1259.         PH   (with [PT/TE]=[ERROR/GENERAL])
  1260.         XX   (The entire message that caused that error: PH+OH+DB+TAIL)
  1261. PktWay-WG                       <25>                            RRP-format
  1262.  
  1263.  
  1264. RRP RECORD FORMAT
  1265. +----------------
  1266.  
  1267. Each RRP-record starts with an 8B-word header as shown below.  Its first
  1268. byte identifies the record type (RTyp).  The second byte is the
  1269. Pad-Count byte (PL) indicating the number of padding bytes.  The third
  1270. and the fourth bytes (RL) are the length (in 8B-words) of the record,
  1271. excluding the record header, hence it may be zero.  The rest of the
  1272. header bytes depend on the record type (RTyp).
  1273.  
  1274. +--------+--------+--------+--------+--------+--------+--------+--------+
  1275. |  RTyp  |   PL   |       RL        |        |        |        |        |Record
  1276. +--------+--------+--------+--------+--------+--------+--------+--------+
  1277.  
  1278. Some records that have an arbitrary length are "right justified" and
  1279. have PL padding bytes before the data.  Padding Before Data [PBD].    
  1280.  
  1281. Some records that have an arbitrary length are "left justified" and
  1282. have PL bytes after the data.  Padding After Data [PAD].
  1283.  
  1284. In either case the total number of data bytes is: (8*RL-PL-4).
  1285.  
  1286. Following are the RRP-records.  These records are the building blocks
  1287. used to construct RRP-messages.
  1288.  
  1289. In the following xxx indicate bytes that are discarded, such as for
  1290. padding.  It is recommended to set them to all-0.
  1291.  
  1292.  
  1293. ===> [ADDR] Node-Address Record [PAD]
  1294.  
  1295. This record specifies either a single address (with AT=1) or a range
  1296. of addresses (with AT=2 followed by AT=3, or by AT=4 followed by AT=5).
  1297. AT is the "Address-Type".
  1298.  
  1299.     0        1        2        3        4        5        6        7
  1300. +--------+--------+--------+--------+--------+--------+--------+--------+
  1301. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |      PktWay-Address      |
  1302. +--------+--------+--------+--------+--------+--------+--------+--------+
  1303.  
  1304. or:
  1305.  
  1306.     0        1        2        3        4        5        6        7
  1307. +--------+--------+--------+--------+--------+--------+--------+--------+
  1308. | "ADDR" |  PL=4  |      RL=1       |  AT=2  |    Min-PktWay-Address    |
  1309. +--------+--------+--------+--------+--------+--------+--------+--------+
  1310. |  AT=3  |    Max-PktWay-Address    |  xxx   |  xxx   |  xxx   |  xxx   |
  1311. +--------+--------+--------+--------+--------+--------+--------+--------+
  1312. RRP-format                       <26>                            PktWay-WG
  1313.  
  1314.  
  1315. or:
  1316.     0        1        2        3        4        5        6        7
  1317. +--------+--------+--------+--------+--------+--------+--------+--------+
  1318. | "ADDR" |  PL=4  |      RL=1       |  AT=4  |   PktWay-Address-Value   |
  1319. +--------+--------+--------+--------+--------+--------+--------+--------+
  1320. |  AT=5  |   PktWay-Address-Mask    |  xxx   |  xxx   |  xxx   |  xxx   |
  1321. +--------+--------+--------+--------+--------+--------+--------+--------+
  1322.    The address-mask follows the address-value after 4 padding bytes.
  1323.  
  1324. The above addresses may be physical or logical.
  1325.  
  1326. The address X is specified by an ADDR record if:
  1327.  
  1328. if AT=1:                            X  == PktWay-Address 
  1329.  
  1330. if AT=2,3:   Min-PktWay-Address <=  X  <= Max-PktWay-Address 
  1331.  
  1332. if AT=4,5:   (PktWay-Address-Mask & X) == PktWay-Address-Value
  1333.  
  1334. An ADDR-record defines only one PktWay-address (or one range),
  1335. unlike an LADR record that may specify multiple addresses and
  1336. multiple address-ranges.
  1337.  
  1338. If the ADDR record is followed by other records that describe the same
  1339. node (such as NAME, CAPA, LADR, SRQR, and MTUR) then the RL of the ADDR
  1340. records also covers all these records.  All these records apply to all
  1341. the addresses specified in this ADDR-record.  Needless to say that NAME
  1342. is not expected to appear within a record that specifies more than one
  1343. address.
  1344.  
  1345. Hence, if an ADDR-record with AT=1 has RL>1, or if an ADDR-record with
  1346. AT>1 has RL>2, then this ADDR-record includes additional records (such
  1347. as CAPA, LADR, SRQR, and/or MTUR) about the specified address(es).
  1348.  
  1349.  
  1350. ===> [NAME] Node-Name Record [PAD] (e.g., a name with 9 characters: A1..A9):
  1351.  
  1352.     0        1        2        3        4        5        6        7
  1353. +--------+--------+--------+--------+--------+--------+--------+--------+
  1354. | "NAME" |  PL=3  |      RL=1       |   A1   |   A2   |   A3   |   A4   |Name
  1355. +--------+--------+--------+--------+--------+--------+--------+--------+
  1356. |   A5   |   A6   |   A7   |   A8   |   A9   |  xxx   |  xxx   |  xxx   |
  1357. +--------+--------+--------+--------+--------+--------+--------+--------+
  1358.  
  1359.  
  1360. ===> [CAPA] Node-Capability Record [PAD] (e.g., with 9 parameter bytes):
  1361.  
  1362.     0        1        2        3        4        5        6        7
  1363. +--------+--------+--------+--------+--------+--------+--------+--------+
  1364. | "CAPA" |  PL=2  |      RL=1       | CC=Cx  |   P1   |   P2   |   P3   |cap
  1365. +--------+--------+--------+--------+--------+--------+--------+--------+
  1366. |   P4   |   P5   |   P6   |   P7   |   P8   |   P9   |  xxx   |  xxx   |
  1367. +--------+--------+--------+--------+--------+--------+--------+--------+
  1368.  
  1369. Byte#4 is the Capability Code, CC, followed by as many parameter bytes
  1370. as needed.
  1371. PktWay-WG                       <27>                            RRP-format
  1372.  
  1373.  
  1374. The capability codes are listed in the Enumeration Appendix (A5).
  1375.  
  1376. The number of bytes used by the parameters is 8*RL-PL-5.
  1377.  
  1378.  
  1379. ===> [LADR] Logical-Addresses Record [PAD] (e.g., 2 logical addresses
  1380. and a range of logical addresses):
  1381.  
  1382.     0        1        2        3        4        5        6        7
  1383. +--------+--------+--------+--------+--------+--------+--------+--------+
  1384. | "LADR" |  PL=4  |      RL=2       |  AT=1  |1010  Logical-Address-#1  |LogAdr
  1385. +--------+--------+--------+--------+--------+--------+--------+--------+
  1386. |  AT=2  |1010  Min-Logical-Address |  AT=3  |1010  Max-Logical-Address |
  1387. +--------+--------+--------+--------+--------+--------+--------+--------+
  1388. |  AT=1  |1010  Logical-Address-#2  |  xxx   |  xxx   |  xxx   |  xxx   |
  1389. +--------+--------+--------+--------+--------+--------+--------+--------+
  1390.  
  1391. Whereas an ADDR-record defines only one PktWay-address (or one range),
  1392. an LADR record may specify multiple addresses (each with AT=1) and
  1393. multiple ranges (each with a pair of AT=2,3 or AT=4,5).
  1394.  
  1395.  
  1396. ===> [SRQR] Source-Route Record [PBD], with Q for that route.
  1397.           (e.g., a  combined SR with 13 bytes and an SR with 4 bytes)
  1398.  
  1399. This record carries one, or more, L2RHs (2 in the following example). 
  1400.  
  1401.     1        2        3        4        5        6        7
  1402. +--------+--------+--------+--------+--------+--------+--------+--------+
  1403. | "SRQR" |  PL=2  |      RL=3       |  xxx   |  xxx   |        Q        |SR+Q
  1404. +--------+--------+--------+--------+--------+--------+--------+--------+
  1405. |vv000000|11 L=13B|  SR01  |  SR02  |  SR03  |  SR04  |  SR05  |  SR06  |L2RH#1
  1406. +--------+--------+--------+--------+--------+--------+--------+--------+
  1407. |  SR07  |  SR08  |  SR09  |  SR10  |  SR11  |  SR12  |  SR13  |   xxx  |
  1408. +--------+--------+--------+--------+--------+--------+--------+--------+
  1409. |vv000000|11 L=4B |  SR01  |  SR02  |  SR03  |  SR04  |   xxx  |   xxx  |L2RH#2
  1410. +--------+--------+--------+--------+--------+--------+--------+--------+
  1411.  
  1412. Q (the Route Quality) is an unsigned 16-bit integer.  The units are not
  1413. defined here.  It is assumed that it is monotonic with all-0 being the
  1414. best and all-1 the worst.  If there is an MTUR (MTU-record) for that SR
  1415. it should follow this SRQR record.  However, the RL of this SRQR does
  1416. not include the RL of the MTUR.
  1417.  
  1418.  
  1419. ===> [MTUR] MTU record [PBD]:
  1420.  
  1421.     0        1        2        3        4        5        6        7
  1422. +--------+--------+--------+--------+--------+--------+--------+--------+
  1423. | "MTUR" |  PL=0  |      RL=0       |         MTU (in 8B-words)         |MTU
  1424. +--------+--------+--------+--------+--------+--------+--------+--------+
  1425.  
  1426. The MTU record provides the MTU for the SR defined before (by an SRQR).
  1427.  
  1428. The value of 0 means indefinite MTU (i.e., any length is OK).
  1429. RRP-format                       <28>                            PktWay-WG
  1430.  
  1431.  
  1432.  
  1433. ===> [RCVF] RCVF Record [PAD] (e.g., 4 addresses)
  1434.  
  1435.     0        1        2        3        4        5        6        7
  1436. +--------+--------+--------+--------+--------+--------+--------+--------+
  1437. | "RCVF" |  PL=4  |      RL=2       |  AT=1  |0    Address-1 (first)    |RCVF
  1438. +--------+--------+--------+--------+--------+--------+--------+--------+
  1439. |  AT=1  |0        Address-2        |  AT=1  |0        Address-3        |
  1440. +--------+--------+--------+--------+--------+--------+--------+--------+
  1441. |  AT=1  |0    Address-4 (last)     |   xxx  |   xxx  |   xxx  |   xxx  |
  1442. +--------+--------+--------+--------+--------+--------+--------+--------+
  1443.  
  1444. The RCVF tracks, along its path, the addresses of the routers.  Each
  1445. additional router is added at the end of the list.  Each router should
  1446. add at least its exit address (possibly more of its addresses).  The PL
  1447. is always either 0 or 4.
  1448.  
  1449. Address-1, the first address (in the 4 LSBytes of the first word) is
  1450. always the address of the mapper-HR that created this LRT.  All addresses
  1451. in the RCVF are always physical (with MSbit=0) and single (with AT=1).
  1452.  
  1453. ===> [SNID] SAN ID
  1454.  
  1455.     0        1        2        3        4        5        6        7
  1456. +--------+--------+--------+--------+--------+--------+--------+--------+
  1457. | "SNID" |  PL=0  |      RL=0       |  AT=1  |          SAN-ID          |
  1458. +--------+--------+--------+--------+--------+--------+--------+--------+
  1459.  
  1460. Could be physical or logical, but unique (i.e., with AT=1).  If no ID is
  1461. assigned to that SAN, a 0 value should be used as its SAN-ID.
  1462.  
  1463.  
  1464. ===> [RTHD] Routing-Table-Header record:
  1465.  
  1466.     0        1        2        3        4        5        6        7
  1467. +--------+--------+--------+--------+--------+--------+--------+--------+
  1468. | "RTHD" |  PL=2  |      RL=?       |  xxxx  |  xxxx  |  Serial-Number  |RT-hd
  1469. +--------+--------+--------+--------+--------+--------+--------+--------+
  1470.  
  1471.  
  1472. This is followed by:
  1473.  
  1474.      SNID (SAN ID)
  1475.          SRQR (CSR and its Q)
  1476.          MTUR (min MTU along CSR and the target SAN)
  1477.          RCVF (RCVF)
  1478.          for each node: ADDR (address)
  1479.                         NAME (name, optional)
  1480.                         CAPA (capabilities, optional)
  1481.                         LADR (logical-addresses, optional)
  1482.                         SRQR (SR to that node, and its Q)
  1483.  
  1484. The MTUR should not exceed the MTU of the CSR nor of the SAN of this RT.
  1485. PktWay-WG                       <29>                            RRP-format
  1486.  
  1487.  
  1488. RRP MESSAGE EXAMPLES 
  1489. +-------------------
  1490.  
  1491. Node-S asks HR1 to provide an L2RH to node-X:
  1492.  
  1493. ==> [GVL2] Please give me L2-routes from you to node-X
  1494.     0        1        2        3        4        5        6        7
  1495. +--------+--------+--------+--------+--------+--------+--------+--------+
  1496. |00   P  |       HR1-Address        |     "GVL2"      |     "R R P"     |PH1
  1497. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1498. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0        S-Address        |PH2
  1499. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1500. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |         X-Address        |Dest
  1501. +--------+--------+--------+--------+--------+--------+--------+--------+
  1502. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1503. +--------+--------+--------+--------+--------+--------+--------+--------+
  1504.  
  1505. ==> [L2SR] HR1 replies with two L2-routes to node-X with Qs and MTUs
  1506.     (e.g., an SR of 2 L2RHs (of 5+4 bytes), and an SR an L2RH of 3 bytes)
  1507.     0        1        2        3        4        5        6        7
  1508. +--------+--------+--------+--------+--------+--------+--------+--------+
  1509. |00   P  |         S-Address        |      "L2SR"     |     "R R P"     |PH1
  1510. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1511. |E=0|PL=0| Data-Length=8 (8B-words) |0|  RZ  |0       HR1-Address       |PH2
  1512. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1513. | "ADDR" |  PL=0  |      RL=7       |  AT=1  |         X-Address        |Addr
  1514. +--------+--------+--------+--------+--------+--------+--------+--------+
  1515. | "SRQR" |  PL=2  |      RL=2       |  xxx   |  xxx   |        Q        |SR+Q
  1516. +--------+--------+--------+--------+--------+--------+--------+--------+
  1517. |vv000000|11 L=5B |  SR01  |  SR02  |  SR03  |  SR04  |  SR05  |  xxx   |L2RH
  1518. +--------+--------+--------+--------+--------+--------+--------+--------+
  1519. |vv000000|11 L=4B |  SR01  |  SR02  |  SR03  |  SR04  |  xxx   |  xxx   |L2RH
  1520. +--------+--------+--------+--------+--------+--------+--------+--------+
  1521. | "MTUR" |  PL=0  |      RL=0       |         MTU (in 8B-words)         |MTU
  1522. +--------+--------+--------+--------+--------+--------+--------+--------+
  1523. | "SRQR" |  PL=2  |      RL=1       |  xxx   |  xxx   |        Q        |SR+Q
  1524. +--------+--------+--------+--------+--------+--------+--------+--------+
  1525. |vv000000|11 L=3B |  SR01  |  SR02  |  SR03  |  xxx   |  xxx   |  xxx   |L2RH
  1526. +--------+--------+--------+--------+--------+--------+--------+--------+
  1527. | "MTUR" |  PL=0  |      RL=0       |         MTU (in 8B-words)         |MTU
  1528. +--------+--------+--------+--------+--------+--------+--------+--------+
  1529. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1530. +--------+--------+--------+--------+--------+--------+--------+--------+
  1531.  
  1532. ==> [RDRC] HR1 redirects Node-S to use HR2 for node-X
  1533.     0        1        2        3        4        5        6        7
  1534. +--------+--------+--------+--------+--------+--------+--------+--------+
  1535. |00   P  |         S-Address        |      "RDRC"     |     "R R P"     |PH1
  1536. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1537. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0       HR1-Address       |PH2
  1538. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1539. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |         X-Address        |Dest
  1540. +--------+--------+--------+--------+--------+--------+--------+--------+
  1541. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |        HR2-Address       |via-HR
  1542. +--------+--------+--------+--------+--------+--------+--------+--------+
  1543. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1544. +--------+--------+--------+--------+--------+--------+--------+--------+
  1545. RRP-format                       <30>                            PktWay-WG
  1546.  
  1547.  
  1548. ==> [TELL] Please tell me about Node-X (address | name | capabilities)
  1549.  
  1550. This message may have any of the following 3 forms:
  1551.  
  1552. If by PacketWay-address:
  1553.  
  1554.     0        1        2        3        4        5        6        7
  1555. +--------+--------+--------+--------+--------+--------+--------+--------+
  1556. |00   P  |        HR1-Address       |      "TELL"     |     "R R P"     |PH1
  1557. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1558. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0        S-Address        |PH2
  1559. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1560. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |         X-Address        |Addr
  1561. +--------+--------+--------+--------+--------+--------+--------+--------+
  1562. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1563. +--------+--------+--------+--------+--------+--------+--------+--------+
  1564.  
  1565.  
  1566. If by name (e.g., a name with 9 characters: A1...A9):
  1567.  
  1568.     0        1        2        3        4        5        6        7
  1569. +--------+--------+--------+--------+--------+--------+--------+--------+
  1570. |00   P  |        HR1-Address       |      "TELL"     |     "R R P"     |PH1
  1571. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1572. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0        S-Address        |PH2
  1573. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1574. | "NAME" |  PL=3  |      RL=1       |   A1   |   A2   |   A3   |   A4   |Name
  1575. +--------+--------+--------+--------+--------+--------+--------+--------+
  1576. |   A5   |   A6   |   A7   |   A8   |   A9   |  xxx   |  xxx   |  xxx   |
  1577. +--------+--------+--------+--------+--------+--------+--------+--------+
  1578. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1579. +--------+--------+--------+--------+--------+--------+--------+--------+
  1580.  
  1581.  
  1582. If by capabilities (e.g., 2 capabilities, C1 with 2 parameter bytes,
  1583. and C2 with no parameter bytes):
  1584.  
  1585.     0        1        2        3        4        5        6        7
  1586. +--------+--------+--------+--------+--------+--------+--------+--------+
  1587. |00   P  |        HR1-Address       |      "TELL"     |     "R R P"     |PH1
  1588. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1589. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0        S-Address        |PH2
  1590. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1591. | "CAPA" |  PL=1  |      RL=0       | CC=C1  |   P1   |   P2   |  xxx   |cap
  1592. +--------+--------+--------+--------+--------+--------+--------+--------+
  1593. | "CAPA" |  PL=3  |      RL=0       | CC=C2  |  xxx   |   xxx  |  xxx   |cap
  1594. +--------+--------+--------+--------+--------+--------+--------+--------+
  1595. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1596. +--------+--------+--------+--------+--------+--------+--------+--------+
  1597.  
  1598. A "TELL" may specify several nodes, by addresses, names, and
  1599. capabilities.  Any node that matches any of the specifications will be
  1600. included in the reply.
  1601. PktWay-WG                       <31>                            RRP-format
  1602.  
  1603.  
  1604.  
  1605. ==> [INFO] Info about Node-X (address, name, capabilities) e.g., a name
  1606.          with 9 characters (A1...A9) and 3 capabilities (Cx, Cy, and Cz):
  1607.  
  1608.     0        1        2        3        4        5        6        7
  1609. +--------+--------+--------+--------+--------+--------+--------+--------+
  1610. |00   P  |         S-Address        |      "INFO"     |     "R R P"     |PH1
  1611. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1612. |E=0|PL=0| Data-Length=7 (8B-words) |0|  RZ  |0       HR1-Address       |PH2
  1613. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1614. | "ADDR" |  PL=0  |      RL=6       |  AT=1  |         X-Address        | *
  1615. +--------+--------+--------+--------+--------+--------+--------+--------+ *
  1616. | "NAME" |  PL=3  |      RL=1       |   A1   |   A2   |   A3   |   A4   | *
  1617. +--------+--------+--------+--------+--------+--------+--------+--------+ *
  1618. |   A5   |   A6   |   A7   |   A8   |   A9   |  xxx   |  xxx   |  xxx   | *
  1619. +--------+--------+--------+--------+--------+--------+--------+--------+ *
  1620. | "CAPA" |  PL=1  |      RL=0       | CC=Cx  |   P1   |   P2   |  xxx   | *
  1621. +--------+--------+--------+--------+--------+--------+--------+--------+ *
  1622. | "CAPA" |  PL=3  |      RL=0       | CC=Cy  |  xxx   |  xxx   |  xxx   | *
  1623. +--------+--------+--------+--------+--------+--------+--------+--------+ *
  1624. | "CAPA" |  PL=5  |      RL=1       | CC=Cz  |   P1   |   P2   |   P3   | *
  1625. +--------+--------+--------+--------+--------+--------+--------+--------+ *
  1626. |   P4   |   P5   |   P6   |  xxx   |  xxx   |  xxx   |  xxx   |  xxx   | *
  1627. +--------+--------+--------+--------+--------+--------+--------+--------+
  1628. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1629. +--------+--------+--------+--------+--------+--------+--------+--------+
  1630.  
  1631. The INFO records aggregate all the nodes that meet any of the attributed
  1632. specified in the TELL record.  When such aggregation is used, the DL
  1633. (data length) in the PH is the sum of the RLs in all the ADDR fields.
  1634.  
  1635. (*) The ADDR, NAME, and CAPA records are repeated for each applicable node.
  1636.     Same also for LADR, SRQR, and MTUR, if any.
  1637.  
  1638. If several capabilities are specified in [TELL], any node that has any of
  1639. these capabilities should be reported in [INFO].
  1640.  
  1641.  
  1642.  
  1643. ==> [HRTO] Node-S asks HR1 which HR to use for Node-X.
  1644.  
  1645.     0        1        2        3        4        5        6        7
  1646. +--------+--------+--------+--------+--------+--------+--------+--------+
  1647. |00   P  |        HR1-Address       |      "HRTO"     |     "R R P"     |PH1
  1648. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1649. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0        S-Address        |PH2
  1650. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1651. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |         X-Address        |Dest
  1652. +--------+--------+--------+--------+--------+--------+--------+--------+
  1653. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1654. +--------+--------+--------+--------+--------+--------+--------+--------+
  1655. RRP-format                       <32>                            PktWay-WG
  1656.  
  1657.  
  1658.  
  1659.  
  1660. ==> [WRU?] Who/what-Are-You?
  1661.  
  1662.     0        1        2        3        4        5        6          7
  1663. +--------+--------+--------+--------+--------+--------+--------+--------+
  1664. |00   P  |01111111|11111111|11111110|      "WRU?"     |     "R R P"     |PH1
  1665. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1666. |E=0|PL=0| Data-Length=0 (8B-words) |0|  RZ  |0        S-Address        |PH2
  1667. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1668. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1669. +--------+--------+--------+--------+--------+--------+--------+--------+
  1670.  
  1671. This is addressed to 0x7FFFFE, the "Hey-You" address.
  1672.  
  1673.  
  1674. ==> [GVRT] Please give me your RTs.    HR1 asks HR2 for his RTs.
  1675.  
  1676.     0        1        2        3        4        5        6        7
  1677. +--------+--------+--------+--------+--------+--------+--------+--------+
  1678. |00   P  |        HR2-Address       |      "GVRT"     |     "R R P"     |PH1
  1679. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1680. |E=0|PL=0| Data-Length=0 (8B-words) |0|  RZ  |0       HR1-Address       |PH2
  1681. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1682. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1683. +--------+--------+--------+--------+--------+--------+--------+--------+
  1684. PktWay-WG                       <33>                            RRP-format
  1685.  
  1686.  
  1687.  
  1688. ==> [RTBL]  HR2 replies to HR1: Here is an RT.
  1689.  
  1690.     0        1        2        3        4        5        6        7
  1691. +--------+--------+--------+--------+--------+--------+--------+--------+
  1692. |00   P  |        HR1-Address       |      "RTBL"     |     "R R P"     |PH1
  1693. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1694. |E=0|PL=0| Data-Length=? (8B-words) |0|  RZ  |0       HR2-Address       |PH2
  1695. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1696. | "RTHD" |  PL=0  |      RL=?       |  xxxx  |  xxxx  |  Serial-Number  |RThdr
  1697. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1698. | "SNID" |  PL=0  |      RL=0       |  AT=1  |          SAN-ID          |SAN-ID
  1699. +--------+--------+--------+--------+--------+--------+--------+--------+
  1700. | "RCVF" |  PL=0  |      RL=1       |  AT=1  |0    Address-1 (first)    |RCVF
  1701. +--------+--------+--------+--------+--------+--------+--------+--------+
  1702. |  AT=1  |0        Address-2        |  AT=1  |0    Address-3 (last)     |
  1703. +--------+--------+--------+--------+--------+--------+--------+--------+
  1704. | "SRQR" |  PL=2  |      RL=2       |  xxx   |  xxx   |        Q        |CSR+Q
  1705. +--------+--------+--------+--------+--------+--------+--------+--------+
  1706. |vv000000|11 L=5B |  SR01  |  SR02  |  SR03  |  SR04  |  SR05  |  xxx   |L2RH
  1707. +--------+--------+--------+--------+--------+--------+--------+--------+
  1708. |vv000000|11 L=4B |  SR01  |  SR02  |  SR03  |  SR04  |  xxx   |  xxx   |L2RH
  1709. +--------+--------+--------+--------+--------+--------+--------+--------+
  1710. | "MTUR" |  PL=0  |      RL=0       |         MTU (in 8B-words)         |MTU
  1711. +--------+--------+--------+--------+--------+--------+--------+--------+
  1712. | "ADDR" |  PL=0  |      RL=9       |  AT=1  |         H-Address        | * R
  1713. +--------+--------+--------+--------+--------+--------+--------+--------+ * e
  1714. | "NAME" |  PL=3  |      RL=1       |   A1   |   A2   |   A3   |   A4   | * p
  1715. +--------+--------+--------+--------+--------+--------+--------+--------+ * e
  1716. |   A5   |   A6   |   A7   |   A8   |   A9   |  xxx   |  xxx   |  xxx   | * a
  1717. +--------+--------+--------+--------+--------+--------+--------+--------+ * t
  1718. | "CAPA" |  PL=2  |      RL=0       | CC=C1  |   P1   |  XXX   |  xxx   | * e
  1719. +--------+--------+--------+--------+--------+--------+--------+--------+ * d
  1720. | "LADR" |  PL=4  |      RL=1       |  AT=1  |1010  Logical-Address-#1  | *
  1721. +--------+--------+--------+--------+--------+--------+--------+--------+ * 4
  1722. |  AT=1  |1010  Logical-Address-#2  |  xxx   |  xxx   |  xxx   |  xxx   | * 
  1723. +--------+--------+--------+--------+--------+--------+--------+--------+ * e
  1724. | "SRQR" |  PL=2  |      RL=3       |  xxx   |  xxx   |        Q        | * a
  1725. +--------+--------+--------+--------+--------+--------+--------+--------+ * c
  1726. |vv000000|11 L=8B |  SR01  |  SR02  |  SR03  |  SR04  |  SR05  |  SR06  | * h
  1727. +--------+--------+--------+--------+--------+--------+--------+--------+ * 
  1728. |  SR07  |  SR08  |  xxx   |  xxx   |  xxx   |  xxx   |  xxx   |  xxx   | * n
  1729. +--------+--------+--------+--------+--------+--------+--------+--------+ * o
  1730. |vv000000|11 L=5B |  SR01  |  SR02  |  SR03  |  SR04  |  SR05  |  xxx   | * d
  1731. +--------+--------+--------+--------+--------+--------+--------+--------+ * e
  1732. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1733. +--------+--------+--------+--------+--------+--------+--------+--------+
  1734.  
  1735. ADDR, NAME, CAPA, LADR, and SRQR are repeated for each node in the RT.
  1736. RRP-format                       <34>                            PktWay-WG
  1737.  
  1738.  
  1739.  
  1740. ==> [ERR/UNK] Destination Unknown (address).  HR1 tells Node-S that
  1741.               he does not know about Node-X.
  1742.  
  1743.     0        1        2        3        4        5        6        7
  1744. +--------+--------+--------+--------+--------+--------+--------+--------+
  1745. |00   P  |         S-Address        |       UNK       |     "E R R"     |PH1
  1746. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1747. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0      HR1-Address        |PH2
  1748. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1749. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |        X-Address         |Addr
  1750. +--------+--------+--------+--------+--------+--------+--------+--------+
  1751. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1752. +--------+--------+--------+--------+--------+--------+--------+--------+
  1753.  
  1754.  
  1755. ==> [ERR/HRDOWN] HR Down (2 addresses).  HR1 tells Node-S that HR-X is down
  1756.  
  1757.     0        1        2        3        4        5        6        7
  1758. +--------+--------+--------+--------+--------+--------+--------+--------+
  1759. |00   P  |         S-Address        |     "HRDOWN"    |     "E R R"     |PH1
  1760. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1761. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0       HR1-Address       |PH2
  1762. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1763. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |       HRX-Address-1      |Addr
  1764. +--------+--------+--------+--------+--------+--------+--------+--------+
  1765. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |       HRX-Address-2      |Addr
  1766. +--------+--------+--------+--------+--------+--------+--------+--------+
  1767. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1768. +--------+--------+--------+--------+--------+--------+--------+--------+
  1769.  
  1770. HR1 knows 2 addresses of the downed router.
  1771.  
  1772.  
  1773. ==> [ERR/LINKDOWN] Link Down (2 addresses)
  1774.  
  1775.     0        1        2        3        4        5        6        7
  1776. +--------+--------+--------+--------+--------+--------+--------+--------+
  1777. |00   P  |         S-Address        |    "LINKDOWN"   |     "E R R"     |PH1
  1778. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1779. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0       HR1-Address       |PH2
  1780. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1781. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |          A-Addr          |
  1782. +--------+--------+--------+--------+--------+--------+--------+--------+
  1783. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |          B-Addr          |
  1784. +--------+--------+--------+--------+--------+--------+--------+--------+
  1785. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1786. +--------+--------+--------+--------+--------+--------+--------+--------+
  1787.  
  1788. This message reports that the link between A-Addr and B-Addr is down.
  1789. PktWay-WG                       <35>                            RRP-format
  1790.  
  1791.  
  1792.  
  1793. ==> [ERR/GENERAL] General error: HR1 tells node-S that it (HR1) could
  1794. not handle the enclosed message)
  1795.  
  1796.     0        1        2        3        4        5        6        7
  1797. +--------+--------+--------+--------+--------+--------+--------+--------+
  1798. |00   P  |         S-Address        |     GENERAL     |     "E R R"     |PH1
  1799. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1800. |E=0|PL=0| Data-Length=? (8B-words) |0|  RZ  |0       HR1-address       |PH2
  1801. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1802. |                                                                       |Data
  1803. |<------The entire message that could not be handled by the sender----->|Data
  1804. |                                                                       |Data
  1805. +--------+--------+--------+--------+--------+--------+--------+--------+
  1806. |      64 zero bits, unless any error was indicated along the path      |TAIL
  1807. +--------+--------+--------+--------+--------+--------+--------+--------+
  1808.  
  1809. This message reports that the enclosed message could not be handled by
  1810. its receiver (the sender of this error  message).
  1811.  
  1812.  
  1813. ABOUT ROUTING TABLES
  1814.  
  1815. In aggregated routing tables a single ADDR record may define a range
  1816. of nodes, assigning the same capabilities to all.  Exceptional nodes
  1817. (e.g., router, and I/O processor) that are included in the address range
  1818. defined by the ADDR record, should have also their own ADDR records,
  1819. with the information specific to them, BEFORE the aggregated ADDR
  1820. record.
  1821.  
  1822. For example:
  1823.  
  1824.     Node #3        Router
  1825.     Node #7        DSP
  1826.     Node #1-#9000    GP
  1827.  
  1828. defines that there are 9,000 nodes, all GP type, except #3 and #7 that
  1829. are a router and a DSP.
  1830.  
  1831. The rule is that the routing table is searched until the first
  1832. definition of that node is found.  Hence, earlier overrules later.
  1833. RRP-format                         <36>                          PktWay-WG
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851.  
  1852.                  [ B l a n k ]
  1853. PktWay-WG                      <37>                            APPENDIX-A
  1854.  
  1855.             Appendix-A: Enumerations
  1856.             ------------------------
  1857.  
  1858. (A1) PacketWay Packet Types
  1859. +--------------------------
  1860.  
  1861. The EEP header reserves 4 bytes for signaling from the source node
  1862. directly to the destination node.  They are the PACKET TYPE (PT),
  1863. and the TYPE EXTENSION (TE), 2 bytes each.
  1864.  
  1865. This list defines values for the PACKET-TYPE (PT) field.  Each
  1866. packet-type has its own interpretation of the TE and the h-fields.
  1867.  
  1868.        Code     Packet Type
  1869. +----------     ----------------------      
  1870.           0     Illegal
  1871.           1    RRP
  1872.           2    Embedded PacketWay Packet
  1873.           3    MEM-READ
  1874.           4    MEM-WRITE
  1875.               Higher level protocols:
  1876.          21        IP
  1877.          22        SNMP
  1878.          23        ATM
  1879.         Link layer Protocols
  1880.          50        Ethernet (E10)
  1881.          51        Ethernet (E100)
  1882.      52        Ethernet (E1000)
  1883.      53        Myrinet
  1884.      54        Fibre Channel
  1885.      55        RACEway
  1886.      56        SCI
  1887.      57        VME
  1888.         Application level protocols:
  1889.      81        MPI
  1890.      82        PVM
  1891.         Secure Protocols
  1892.     121        Secure (1)
  1893.     122        Secure (2)
  1894.     123        Secure (3)
  1895. 1,024-2,047     User defined
  1896.      65,535    ERR (for Error)
  1897.  
  1898. More values will be assigned.  "Ether-types" should be added with
  1899. a pointer to those used by the Internet. 
  1900. APPENDIX-A                      <38>                PktWay-WG
  1901.  
  1902.  
  1903. (A2) RRP Messages  (Type Extensions of PT="RRP)
  1904. +----------------------------------------------
  1905.   RRP-
  1906.   Type  Code Description
  1907. +------ ---- ----------------------------------------------------
  1908.           0  Illegal
  1909.   GVL2   21  Please give me L2-routes from you to node (address)
  1910.   L2SR   22  Here are L2-routes to node (address)
  1911.   RDRC   23  Re-direct to node (address) via a neighbor HR (address)
  1912.   TELL   24  Please tell about node (address | name | capabilities)
  1913.   INFO   25  Info about node (address, name, capabilities)
  1914.   HRTO   26  Which HR should I use for node (address)
  1915.   WRU?   27  Who/what-Are-You?
  1916.   GVRT   28  Please give me your RTs
  1917.   RTBL   29  Here is an RT
  1918.   GVSC   41  Please give me a Security-Context
  1919.   IDSC   42  Here is the ID for a Security-Context
  1920.  
  1921. Throughout this document the RRP messages are indicated by their
  1922. type (e.g., RDRC for Re-direct).  In actual messages the code is used
  1923. (e.g., 2 for RDRC).
  1924.  
  1925.  
  1926.  
  1927. (A3) RRP records
  1928. +---------------
  1929.  
  1930.   RTyp  Code Description
  1931. +------ ---- ----------------------------------------------------
  1932.           0  Illegal
  1933.   ADDR   41  Address record for one or many nodes
  1934.   NAME   42  Node Name record
  1935.   CAPA   43  Node Capability record
  1936.   LADR   44  Node Logical Addresses record
  1937.   SRQR   45  Source Route record and its Quality (SR, Q)
  1938.   MTUR   46  MTU record (for the previous SRQR)
  1939.   RCVF   47  RCVF record
  1940.   RTHD   48  RT-header record
  1941.   SNID   49  SAN-ID record
  1942.   SCID   55  Security-Context record
  1943.  
  1944. Throughout this document the RRP records are indicated by their RTyp (e.g.,
  1945. ADDR for address).  In actual messages the code is used (e.g.,41 for ADDR).
  1946. PktWay-WG                      <39>                            APPENDIX-A
  1947.  
  1948.  
  1949. (A4) Error Messages
  1950. +------------------
  1951.  
  1952.   Subtype     Code      Description
  1953.   ---------   ----      ----------------------------------------------
  1954.                 0       Illegal
  1955.   UNK          71    Unknown (address)
  1956.   HRDOWN       72    HR-Down (and the links associated with it)
  1957.   LINKDOWN     73    Link-Down (between two HRs)
  1958.   GENERAL      74    General error message 
  1959.   SEC-ERR-01  101    Security error #01
  1960.   SEC-ERR-02  102    Security error #02
  1961.   SEC-ERR-03  103    Security error #03
  1962.  
  1963. Throughout this document the error messages are indicated by their
  1964. subtype (e.g., LINKDOWN for Link-Down).  In actual messages the code
  1965. is used (e.g., 3 for LINKDOW).
  1966.  
  1967.  
  1968. (A5) PacketWay Node Capabilities
  1969. +-------------------------------
  1970.  
  1971. Code  Capability                Parameters
  1972. +---  ------------------------  --------------------------------------
  1973.   0   Illegal
  1974.   1   GP Computing Node
  1975.   2   Router                    SAN-IDs, 1+3 Bytes each
  1976.   3   PacketWay Server
  1977.   4   Network Multicast Server
  1978.   5   NFS
  1979.   6   NPS (Paging Server)
  1980.   7   Floating-point DSP        IEEE word-sizes (in bytes), 1B per size
  1981.   8   Fixed-point DSP           word-sizes (in bytes), 1B per size
  1982.   9   Printer
  1983. 254   Security capabilities    security-subtypes
  1984. 255   SAN
  1985. APPENDIX-A                      <40>                            PktWay-WG
  1986.  
  1987.  
  1988.  
  1989. (A6) Optional Header Fields Types (OH)
  1990. +-------------------------------------
  1991.  
  1992. The MSbit of the OH-type-field (T) is the type-of-type.  Its assignment is:
  1993.  
  1994.    0b0: Optional (may drop this OH if its type, tttttt, is unknown)
  1995.    0b1: Mandatory (should not process this OH if its type is unknown)
  1996.  
  1997. The next bit is the "Completion bit" (C).  Its assignment is:
  1998.  
  1999.    0b0: More options follow
  2000.    0b1: This is the last option field
  2001.  
  2002. The 6 LSbits, tttttt, are the type field.  Their assignment is:
  2003.  
  2004.  0x00:      Illegal
  2005.  0x01:        TBD
  2006.  0x02:      CRC32 here
  2007.  0x03:      CRC32 following the DB
  2008.  0x04:      CRC64 here
  2009.  0x05:      CRC64 following the DB
  2010.  0x06:        MAC here
  2011.  0x07:      MAC following the DB
  2012.  0x08-0x3D: TBD
  2013.  0x3E:      Cryptographic data
  2014.  0x3F:      End of Optional fields (Mandatory, i.e., 0xFF).
  2015.  
  2016.  
  2017. (A7) Byte Order (Endianness)
  2018. +---------------------------
  2019.  
  2020. A 4 bit field (E) is used to indicate Endianness, with e being its first
  2021. bit (MSbit).
  2022.  
  2023.     e=0: Big-Endian order
  2024.     e=1: Little-Endian order
  2025.  
  2026. The 3 LSbits indicate the size of data chucks (must be the same for the
  2027. entire data block) to allow hardware swapping
  2028.  
  2029.     e000: don't swap, it's 8-bit data
  2030.     e001: swap as if all the data is  16-bit words
  2031.     e010: swap as if all the data is  32-bit words
  2032.         e011: swap as if all the data is  64-bit words
  2033.     e100: swap as if all the data is 128-bit words
  2034.     e101: illegal and reserved for future use
  2035.     e110: illegal and reserved for future use
  2036.     e111: illegal and reserved for future use
  2037. PktWay-WG                      <41>                            Appendix-B
  2038.  
  2039.  
  2040.            Appendix-B: Example of the Mapping Process
  2041.            ------------------------------------------
  2042.  
  2043. First, the notation.  Rab is the PacketWay-address (on SAN-A) of the
  2044. A-half of the router between the SANs A and B.  It is interconnected via
  2045. some link (bus? wire? fiber? shared-memory?) with Rba, its twin, the
  2046. B-half that is on SAN-B, having Rba its PacketWay-address (on SAN-B).
  2047. Sometimes we use (ab) as a shorthand notation for the router between
  2048. SAN-A and SAN-B.
  2049.  
  2050. The values, in this example, of the PacketWay-addresses of the HRs are
  2051. denoted by #nn.
  2052.  
  2053. Hence, the router between SAN-A and SAN-B is: Rab+interconnection+Rba. 
  2054. This inter-SAN connection is marked, in this example, by ***.
  2055.  
  2056. If there are several routers between A and B, numbers are appended to
  2057. their designations (e.g., Rab2).
  2058.  
  2059. The map below is used throughout the following example
  2060.  
  2061.                 #21     #22
  2062.                 Rab     Rba
  2063.      +-----------+  (ab) +-------------+
  2064.      |H0,H1 [A]  ********* [B]    H2,H3|
  2065.      +-----*-----*       +-----*---*---+
  2066.         Rac*   Rad*        Rbd1*   *Rbd2
  2067.         #23*    #25*        #27*   *#29
  2068.            *        *          *   *
  2069.        (ac)*     (ad)*    (bd1)*   *(bd2)
  2070.            *          *        *   *
  2071.         #24*        #26*    #28*   *#30
  2072.         Rca*         Rda*  Rdb1*   *Rdb2
  2073.      +-----*-----+       *-----*---*---+        +----------+
  2074.      |H4,H5 [C]  ********* [D]    H6,H7********** [E] H8,H9|
  2075.      +-----------+ (cd)  +-------------+  (de)  +----------+
  2076.                 Rcd     Rdc           Rde      Red
  2077.                 #31     #32           #33      #34
  2078.  
  2079.  
  2080. Hn (for n=1,2,3,...) is host (node) #n, its address is #n.
  2081.  
  2082. The Local-RT for SAN-A, as computed at Rax is denoted by LRT(A/ax).
  2083.  
  2084. Initially, Rab has an LRT(A/ab) consisting of:
  2085.  
  2086.     H0  #00  node   (SR(A:Rab->H0),  Q)
  2087.     H1  #01  node   (SR(A:Rab->H1),  Q)
  2088.     Rac #23  router (SR(A:Rab->Rac), Q)
  2089.     Rad #25  router (SR(A:Rab->Rad), Q)
  2090. Appendix-B                      <42>                            PktWay-WG
  2091.  
  2092.  
  2093. Rac has an LRT(A/ac) consisting of:
  2094.  
  2095.     H0  #00  node   (SR(A:Rac->H0),  Q)
  2096.     H1  #01  node   (SR(A:Rac->H1),  Q)
  2097.     Rab #21  router (SR(A:Rac->Rab), Q)
  2098.     Rad #25  router (SR(A:Rac->Rad), Q)
  2099.  
  2100. Rad has an LRT(A/ad) consisting of:
  2101.  
  2102.     H0  #00  node   (SR(A:Rad->H0),  Q)
  2103.     H1  #01  node   (SR(A:Rad->H1),  Q)
  2104.     Rab #21  router (SR(A:Rad->Rab), Q)
  2105.     Rac #23  router (SR(A:Rad->Rac), Q)
  2106.  
  2107. Rba has an LRT(B/ba) consisting of:
  2108.  
  2109.     H2   #02 node   (SR(B:Rba->H2),  Q)
  2110.     H3   #03 node   (SR(B:Rba->H3),  Q)
  2111.     Rbd1 #27 router (SR(B:Rba->Rbd1),Q)
  2112.     Rbd2 #29 router (SR(B:Rba->Rbd2),Q)
  2113.  
  2114. Other HRs have similar LRTs.
  2115.  
  2116. Later, each HR exchanges (over its "***"-link) its RTs with
  2117. its twin-HR.
  2118.  
  2119. The SN, Q, SAN-ID and MTU entries are not shown here.
  2120.  
  2121. Rab now has:
  2122.   LRT(A/ab)
  2123.   XRT{ RCVF={Rba}, CSR=(*:Rab->Rba), LRT(B/ba) }
  2124.  
  2125. Rba has:
  2126.   LRT(B/ba)
  2127.   XRT{ RCVF={Rab}, CSR=(*:Rba->Rab), LRT(A/ab) }
  2128.  
  2129. Similarly Rac has:
  2130.   LRT(A/ac)
  2131.   XRT{ RCVF={Rca}, CSR=(*:Rac->Rca), LRT(C/ca) }
  2132.  
  2133. Rca has
  2134.   LRT(C/ca)
  2135.   XRT{ RCVF={Rac}, CSR=(*:Rca->Rac), LRT(A/ac) }
  2136.  
  2137. Rda has
  2138.   LRT(D/da)
  2139.   XRT{ RCVF={Rad}, CSR=(*:Rda->Rad), LRT(A/ad) }
  2140.  
  2141. Because Rab, Rac, Rad and are buddies, directly connected (because they
  2142. all are on A), they exchange their XRTs, over SAN-A.
  2143. PktWay-WG                      <43>                            Appendix-B
  2144.  
  2145.  
  2146. Now Rab has:      
  2147.   LRT(A/ab)
  2148.   XRT{ RCVF={Rba}      , CSR=(*:Rab->Rba),               LRT(B/ba) }
  2149.   XRT{ RCVF={Rca,Rac}  , CSR=(A:Rab->Rac,*:Rac->Rca),    LRT(C/ca) }
  2150.   XRT{ RCVF={Rda,Rad}  , CSR=(A:Rab->Rad,*:Rad->Rda),    LRT(D/da) }
  2151.  
  2152. Rba has:
  2153.   LRT(B/ba)
  2154.   XRT{ RCVF={Rab}      , CSR=(*:Rba->Rab),               LRT(A/ab) }
  2155.   XRT{ RCVF={Rdb1,Rbd1}, CSR=(B:Rba->Rbd1,*:Rbd1->Rdb1), LRT(D/db1 }
  2156.   XRT{ RCVF={Rdb2,Rbd2}, CSR=(B:Rba->Rbd2,*:Rbd2->Rdb2), LRT(D/db2 }
  2157.  
  2158. Next, Rba will share it with Rab.  Now Rab has:
  2159. LRT(A/ab)
  2160. XRT{RCVF={Rba}          ,CSR=(*:Rab->Rba),                          LRT(B/ba) }
  2161. XRT{RCVF={Rca,Rac}      ,CSR=(A:Rab->Rac,*:Rac->Rca),               LRT(C/ca) }
  2162. XRT{RCVF={Rda,Rad}      ,CSR=(A:Rab->Rad,*:Rad->Rda),               LRT(D/da) }
  2163. XRT{RCVF={Rdb1,Rbd1,Rba},CSR=(*:Rab->Rba,B:Rba->Rbd1,*:Rbd1->Rdb1), LRT(D/db1 }
  2164. XRT{RCVF={Rdb2,Rbd2,Rba},CSR=(*:Rab->Rba,B:Rba->Rbd2,*:Rbd2->Rdb2), LRT(D/db2 }
  2165.  
  2166.  
  2167. Now Rab has 3 different ways to get to nodes on D: directly through
  2168. Rad, or via Rab to B, and then via either Rbd1 or Rbd2 into D.  The Qs
  2169. could provide preference.
  2170.  
  2171. Rab may decide to keep all of them, or only the best (or the k best ones).
  2172.  
  2173. Soon, Rab will also have yet another way to get to D:
  2174.  
  2175.   XRT{ RCVF={Rdc,Rcd,Rca,Rac},
  2176.        CSR=(A:Rab->Rac,*:Rac->Rca,C:Rca->Rcd,*:Rcd->Rdc),
  2177.        LRT(D/dc)
  2178.      }
  2179.  
  2180. Let "/" represent a path between 2 buddy-HRs on the same SAN (e.g., ax/fay
  2181. over the a-SAN).  Let "*" represent a path between twin HRs (e.g., ab*ba).
  2182.  
  2183. However, with time Rab will have the following paths to SAN-E:
  2184.  
  2185.           b  t  b   t   b  t
  2186.         ab/ad*da/de *ed                                (ADE)
  2187.            ab*ba/bd1*db1/de*ed                         (AB1DE)
  2188.            ab*ba/bd2*db2/de*ed                         (AB2DE)
  2189.         ab/ac*ca/cd *dc /de*ed                         (ACDE)
  2190.  
  2191. and also:
  2192.  
  2193.           b  t  b   t   b   t   b   t   b  t  b  t
  2194.         ab/ad*da/db1*bd1/bd2*db2/de *ed                (AD1B2DE)
  2195.         ab/ad*da/db2*bd2/bd1*db1/de *ed                (AD2B1DE)
  2196.         ab/ac*ca/cd *dc /db1*bd1/bd2*db2/de*ed         (ACD1B2DE)
  2197.         ab/ac*ca/cd *dc /db2*bd2/bd1*db1/de*ed         (ACD2B1DE)
  2198.            ab*ba/bd1*db1/dc *cd /ca *ac /ad*da/de*ed   (AB1DCADE)
  2199.            ab*ba/bd2*db2/dc *cd /ca *ac /ad*da/de*ed   (AB2DCADE)
  2200.            ab*ba/bd1*db1/da *ad /ac *ca /cd*dc/de*ed   (AB1DACDE)
  2201.            ab*ba/bd2*db2/da *ad /ac *ca /cd*dc/de*ed   (AB2DACDE)
  2202. Appendix-B                      <44>                            PktWay-WG
  2203.  
  2204.  
  2205. The first path is the most reasonable, the next 3 are also reasonable,
  2206. but the last 8 are not reasonable.  None of these 8 paths has the same
  2207. HR twice, but all of them have the same SAN (D, here) twice.
  2208.  
  2209. The latter 8 (or 11) should be ignored because of high Q values.
  2210.  
  2211. ........................................................................
  2212.  
  2213.  
  2214.      +-----------+  (ab) +-----------+
  2215.      |H0,H1 [A]  ********* [B]  H2,H3|
  2216.      +-----*-----*       +---*---*---+
  2217.            *       *    (bd1)*   *(bd2)
  2218.        (ac)*     (ad)*       *   *
  2219.            *           *     *   *
  2220.      +-----*-----+       *---*---*---+       +----------+
  2221.      |H4,H5 [C]  ********* [D]  H6,H7********* [E] H8,H9|
  2222.      +-----------+ (cd)  +-----------+ (de)  +----------+
  2223.  
  2224. ..............................................................................
  2225. PktWay-WG                      <45>                            Appendix-C
  2226.  
  2227.  
  2228.      Appendix-C: Example of the use of RRP (over Myrinets)
  2229.      -----------------------------------------------------
  2230.  
  2231. In this example Node1 on SAN1 (with MTU=16KB) is looking for an
  2232. automatic spectral analyzer (CC=X).  It uses TELL (s1) to ask its
  2233. default router (RTRA1, the half of RouterA connected to SAN#1) which
  2234. nodes have this capability.  RTRA1 knows about no such node, and replies
  2235. with ERROR/UNK (s2) telling Node1 that RTRA1 knows about no such node.
  2236. (The extent by which RTRA1 checks with others before sending this reply
  2237. is not specified here.)
  2238.  
  2239. Failing to find such analyzer, Node1 is looking for a DSP that handles
  2240. IEEE floating-point 64-bit data.  Node1 (s3) asks RTRA1 to provide the
  2241. list of floating-point DSPs that can handle 64bit IEEE data.  (s4) RTRA1
  2242. provides the addresses of both Node2 and Node3.  For its own reasons
  2243. Node1 decides to use Node2.  (s5) Node1 asks RTRA1 which router to use
  2244. for Node2.  (s6) RTRA1 suggests to use RouterB.  (s7) Node1 uses
  2245. L3-forwarding, via Router-B, to verify Node2's capabilities, by asking
  2246. Node2 for information about itself.  (s8) Node2 provides this
  2247. information which Node1 likes.  (s9) Node1 asks RouterB for L2RH(s) to
  2248. Node2.  (s10) RouterB provides the requested L2RH with its MTU of 1,024
  2249. 8B-words (8KB).  Finally, (s11) Node1 starts sending data to Node2 using
  2250. L2-forwarding.  Similarly, NOde2 may ask its default router which HR to
  2251. use for Node1 and for L2RH(s) to Node1.
  2252.  
  2253. If Node1 had only Level-A implementation then it should have the
  2254. combined L2RH from itself to RouterB and from there to Node2 pre-wired,
  2255. saving all this message exchange.
  2256.  
  2257.  
  2258.  +-------+          +--0--+   SAN1   +--0--+          +--0--+
  2259.  | Node1 +----------3 SW0 1----------3 SW1 1----------3 SW2 1   MTU=16KB
  2260.  +-------+          +--2--+          +--2--+          +--2--+
  2261.                        |                                 |
  2262.             RTRA1 ***********       +---+---+       *********** RTRB1
  2263.                   * RouterA *       | Node2 |       * RouterB *
  2264.             RTRA3 ***********       +---+---+       *********** RTRB2
  2265.                        |                |                |   
  2266.  +-------+   SAN3   +--0--+          +--0--+   SAN2   +--0--+
  2267.  | Node3 +----------3 SW3 1          3 SW4 1----------3 SW5 1   MTU=8KB
  2268.  +-------+          +--2--+          +--2--+          +--2--+
  2269.  
  2270.  
  2271. The sequence of messages is shown below.
  2272.  
  2273. (s1) Node1 sends a [TELL] message asking its default router (RTRA1) to
  2274. provide a list of nodes with the capability code X (CC=X).  Node1 knows
  2275. that RTRA1 is on its network, with SR={2,PW}={2,3,0}, where PW=0x0300 is
  2276. the 16-bit Myrinet-type assigned to PacketWay.  Myrinet is described
  2277. here with absolute addresses.
  2278. Appendix-B                      <46>                            PktWay-WG
  2279.  
  2280.  
  2281.  
  2282.     0        1        2        3        4        5        6        7
  2283. +-----------------------------------------------------------------------+
  2284. | <----     The L2-header needed to get from Node1 to RouterA1    ----> |
  2285. | It may be any number of bytes.  In this example it is 3 bytes: {2,PW} |
  2286. +--------+--------+--------+--------+--------+--------+--------+--------+
  2287. |00   P  |          RTRA1           |      "TELL"     |     "R R P"     |PH1
  2288. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2289. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0          Node1          |PH2
  2290. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2291. | "CAPA" |  PL=3  |      RL=0       |  CC=X  |  xxx   |  xxx   |  xxx   |Spect
  2292. +--------+--------+--------+--------+--------+--------+--------+--------+
  2293. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2294. +--------+--------+--------+--------+--------+--------+--------+--------+
  2295.  
  2296. This asks for information about nodes with capability-X.
  2297.  
  2298.  
  2299. (s2) RTRA1 uses [ERR/UNK] to tell Node1 that no such node is known to RTRA1.
  2300.  
  2301.     0        1        2        3        4        5        6        7
  2302. +--------+--------+--------+--------+--------+--------+--------+--------+
  2303. | <----     The L2-header needed to get from RouterA1 to Node1    ----> |
  2304. | It may be any number of bytes.  In this example it is 3 bytes: {3,PW} |
  2305. +---+----+--------+--------+--------+--------+--------+--------+--------+
  2306. |00   P  |          Node1           |       UNK       |     "E R R"     |PH1
  2307. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2308. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0          RTRA1          |PH2
  2309. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2310. | "CAPA" |  PL=3  |      RL=0       |  CC=X  |  xxx   |  xxx   |  xxx   |Spect
  2311. +--------+--------+--------+--------+--------+--------+--------+--------+
  2312. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2313. +--------+--------+--------+--------+--------+--------+--------+--------+
  2314.  
  2315.  
  2316.  
  2317. (s3) Node1 sends another [TELL] message to RTRA1 asking for a list of
  2318. floating-point DSPs that handle 64bit IEEE data (CC=7,8).
  2319.  
  2320.     0        1        2        3        4        5        6        7
  2321. +-----------------------------------------------------------------------+
  2322. | <----     The L2-header needed to get from Node1 to RouterA1    ----> |
  2323. | It may be any number of bytes.  In this example it is 3 bytes: {2,PW} |
  2324. +--------+--------+--------+--------+--------+--------+--------+--------+
  2325. |00   P  |          RTRA1           |      "TELL"     |     "R R P"     |PH1
  2326. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2327. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0          Node1          |PH2
  2328. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2329. | "CAPA" |  PL=2  |      RL=0       |  CC=7  |    8   |  xxx   |  xxx   |64-DSP
  2330. +--------+--------+--------+--------+--------+--------+--------+--------+
  2331. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2332. +--------+--------+--------+--------+--------+--------+--------+--------+
  2333. PktWay-WG                      <47>                            Appendix-C
  2334.  
  2335.  
  2336.  
  2337. (s4) RTRA1 uses [INFO] to provide the addresses and capabilities of
  2338. both Node2 and Node3 (the former only 64 bits, the latter both 32 and 64).
  2339.  
  2340.     0        1        2        3        4        5        6        7
  2341. +-----------------------------------------------------------------------+
  2342. | <----     The L2-header needed to get from RouterA1 to Node1    ----> |
  2343. | It may be any number of bytes.  In this example it is 3 bytes: {3,PW} |
  2344. +--------+--------+--------+--------+--------+--------+--------+--------+
  2345. |00   P  |          Node1           |      "INFO"     |     "R R P"     |PH1
  2346. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2347. |E=0|PL=0| Data-Length=4 (8B-words) |0|  RZ  |0          RTRA1          |PH2
  2348. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2349. | "ADDR" |  PL=0  |      RL=1       |  AT=1  |           Node2          |adr2
  2350. +--------+--------+--------+--------+--------+--------+--------+--------+
  2351. | "CAPA" |  PL=2  |      RL=0       |  CC=7  |    8   |  xxx   |  xxx   |FP-DSP
  2352. +--------+--------+--------+--------+--------+--------+--------+--------+
  2353. | "ADDR" |  PL=0  |      RL=1       |  AT=1  |           Node3          |adr3
  2354. +--------+--------+--------+--------+--------+--------+--------+--------+
  2355. | "CAPA" |  PL=1  |      RL=0       |  CC=7  |    4   |    8   |  xxx   |FP-DSP
  2356. +--------+--------+--------+--------+--------+--------+--------+--------+
  2357. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2358. +--------+--------+--------+--------+--------+--------+--------+--------+
  2359.  
  2360. It is possible that Node2 and Node3 are specified by addresses that are
  2361. not physical addresses.
  2362.  
  2363. For its own reasons Node1 decided to use Node2 and sends [HRTO] to ask
  2364. RTRA1 which HR to use for node2.
  2365.  
  2366.     0        1        2        3        4        5        6        7
  2367. +-----------------------------------------------------------------------+
  2368. | <----     The L2-header needed to get from Node1 to RouterA1    ----> |
  2369. | It may be any number of bytes.  In this example it is 3 bytes: {2,PW} |
  2370. +--------+--------+--------+--------+--------+--------+--------+--------+
  2371. |00   P  |           RTRA1          |      "HRTO"     |     "R R P"     |PH1
  2372. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2373. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0          Node1          |PH2
  2374. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2375. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |           Node2          |Dest
  2376. +--------+--------+--------+--------+--------+--------+--------+--------+
  2377. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2378. +--------+--------+--------+--------+--------+--------+--------+--------+
  2379. Appendix-B                      <48>                            PktWay-WG
  2380.  
  2381.  
  2382.  
  2383. (s6) RTRA1 uses [RDRC] to re-direct to Node2 via RouterB.
  2384.  
  2385.     0        1        2        3        4        5        6        7
  2386. +-----------------------------------------------------------------------+
  2387. | <----     The L2-header needed to get from RouterA1 to Node1    ----> |
  2388. | It may be any number of bytes.  In this example it is 3 bytes: {3,PW} |
  2389. +--------+--------+--------+--------+--------+--------+--------+--------+
  2390. |00   P  |           Node1          |      "RDRC"     |     "R R P"     |PH1
  2391. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2392. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0          RTRA1          |PH2
  2393. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2394. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |           Node2          |Dest
  2395. +--------+--------+--------+--------+--------+--------+--------+--------+
  2396. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |           RTRB1          |via-HR
  2397. +--------+--------+--------+--------+--------+--------+--------+--------+
  2398. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2399. +--------+--------+--------+--------+--------+--------+--------+--------+
  2400.  
  2401. Node1 knows how to get to RouterB over its SAN.
  2402.  
  2403.  
  2404. (s7) Node1 uses [TELL] (still using L3-forwarding via RouterB) to verify
  2405. Node2's capabilities, by asking Node2 for information about itself.
  2406.  
  2407.     0        1        2        3        4        5        6        7
  2408. +-----------------------------------------------------------------------+
  2409. | <----     The L2-header needed to get from Node1 to RouterB1    ----> |
  2410. |    It may be any number of bytes.  Here it is 5 bytes: {1,1,2,PW}     |
  2411. +--------+--------+--------+--------+--------+--------+--------+--------+
  2412. |00   P  |           Node2          |      "TELL"     |     "R R P"     |PH1
  2413. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2414. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0          Node1          |PH2
  2415. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2416. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |           Node2          |Addr
  2417. +--------+--------+--------+--------+--------+--------+--------+--------+
  2418. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2419. +--------+--------+--------+--------+--------+--------+--------+--------+
  2420. PktWay-WG                      <49>                            Appendix-C
  2421.  
  2422.  
  2423. (s8) Node2 uses [INFO] (via RouterB2, also using L3-forwarding) to provide
  2424. more information to Node1 about Node2 than what RTRA1 did.
  2425.  
  2426.     0        1        2        3        4        5        6        7
  2427. +-----------------------------------------------------------------------+
  2428. | <----     The L2-header needed to get from Node2 to RouterB2    ----> |
  2429. |     It may be any number of bytes.  Here it is 4 bytes: {1,0,PW}      |
  2430. +--------+--------+--------+--------+--------+--------+--------+--------+
  2431. |00   P  |           Node1          |      "INFO"     |     "R R P"     |PH1
  2432. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2433. |E=0|PL=0| Data-Length=5 (8B-words) |0|  RZ  |0          Node2          |PH2
  2434. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2435. | "ADDR" |  PL=0  |      RL=4       |  AT=1  |           Node2          |
  2436. +--------+--------+--------+--------+--------+--------+--------+--------+
  2437. | "NAME" |  PL=7  |      RL=1       |  "S"   |  "u"   |  "p"   |  "e"   |
  2438. +--------+--------+--------+--------+--------+--------+--------+--------+
  2439. |  "r"   |  xxx   |  xxx   |  xxx   |  xxx   |  xxx   |  xxx   |  xxx   |
  2440. +--------+--------+--------+--------+--------+--------+--------+--------+
  2441. | "CAPA" |  PL=1  |      RL=0       |  CC=7  |   4    |   8    |  xxx   |FP-DSP
  2442. +--------+--------+--------+--------+--------+--------+--------+--------+
  2443. | "CAPA" |  PL=3  |      RL=0       |  CC=5  |  xxx   |  xxx   |  xxx   |NFS
  2444. +--------+--------+--------+--------+--------+--------+--------+--------+
  2445. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2446. +--------+--------+--------+--------+--------+--------+--------+--------+
  2447.  
  2448. Node2 provided more information about itself, than what RTRA1 did, such
  2449. as its name, "Super", its ability to handle also 32-bit IEEE floating
  2450. point (in addition to 64 bit), and also being an NFS (CC=5).
  2451.  
  2452.  
  2453. (s9) Node1 uses [GVL2] to ask RouterB for L2RH(s) from RouterB to Node2.
  2454.  
  2455.     0        1        2        3        4        5        6        7
  2456. +-----------------------------------------------------------------------+
  2457. | <----     The L2-header needed to get from Node1 to RouterB1    ----> |
  2458. |    It may be any number of bytes.  Here it is 5 bytes: {1,1,2,PW}     |
  2459. +--------+--------+--------+--------+--------+--------+--------+--------+
  2460. |00   P  |           RTRB1          |      "GVL2"     |     "R R P"     |PH1
  2461. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2462. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0          Node1          |PH2
  2463. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2464. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |           Node2          |Dest
  2465. +--------+--------+--------+--------+--------+--------+--------+--------+
  2466. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2467. +--------+--------+--------+--------+--------+--------+--------+--------+
  2468. Appendix-C                      <50>                            PktWay-WG
  2469.  
  2470.  
  2471. (s10) RouterB uses [L2SR] to provide Node1 with an L2RH from RTRB2 to
  2472. Node2, with its Q and MTU.  Here it is {3,0,PW} from RouterB to Node2.
  2473.  
  2474.     0        1        2        3        4        5        6        7
  2475. +-----------------------------------------------------------------------+
  2476. | <----     The L2-header needed to get from RouterB1 to Node1    ----> |
  2477. |    It may be any number of bytes.  Here it is 5 bytes: {3,3,3,PW}     |
  2478. +--------+--------+--------+--------+--------+--------+--------+--------+
  2479. |00  P   |           Node1          |      "L2SR"     |     "R R P"     |PH1
  2480. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2481. |E=0|PL=0| Data-Length=4 (8B-words) |0|  RZ  |0          RTRA1          |PH2
  2482. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2483. | "ADDR" |  PL=0  |      RL=3       |  AT=1  |           Node2          |Dest
  2484. +--------+--------+--------+--------+--------+--------+--------+--------+
  2485. | "SRQR" |  PL=2  |      RL=1       |  xxx   |  xxx   |        Q        |SR+Q
  2486. +--------+--------+--------+--------+--------+--------+--------+--------+
  2487. |vv000000|11 L=4B |   3    |   0    |   3    |   0    |  xxx   |  xxx   |L2RH
  2488. +--------+--------+--------+--------+--------+--------+--------+--------+
  2489. | "MTUR" |  PL=1  |      RL=0       |      MTU=1,024 (in 8B-words)      |MTU
  2490. +--------+--------+--------+--------+--------+--------+--------+--------+
  2491. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2492. +--------+--------+--------+--------+--------+--------+--------+--------+
  2493.  
  2494. The MTU in the MTUR above is the lessor of the MTUs of both networks.
  2495.  
  2496. The RL (record-length) of the last MTUR-record is included both in the
  2497. RL of the preceding SRQR-record and in the RL of the preceding
  2498. ADDR-record (since the RL of the SRQR is included in the RL of the ADDR).
  2499.  
  2500.  
  2501. (s11) Finally, Node1 starts sending data to Node2 using L2-forwarding.
  2502.  
  2503.     0        1        2        3        4        5        6        7
  2504. +-----------------------------------------------------------------------+
  2505. | <----     The L2-header needed to get from Node1 to RouterB1    ----> |
  2506. |    It may be any number of bytes.  Here it is 5 bytes: {1,1,2,PW}     |
  2507. +--------+--------+--------+--------+--------+--------+--------+--------+
  2508. |vv000000|11 L=4B |   3    |   0    |   3    |   0    |  xxx   |  xxx   |L2RH
  2509. +--------+--------+--------+--------+--------+--------+--------+--------+
  2510. |00  P   |           Node2          |Sensor.SubType=? |     "Sensor"    |PH1
  2511. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2512. |E=3|PL=0| Data-Length=? (8B-words) |0|  RZ  |0          Node1          |PH2
  2513. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  2514. |                                                                       |Data
  2515. | <------------------- The sensor data goes here ---------------------> |....
  2516. |                                                                       |Data
  2517. +--------+--------+--------+--------+--------+--------+--------+--------+
  2518. |      64 zero bits, unless any error was indicated along the path      |TAIL
  2519. +--------+--------+--------+--------+--------+--------+--------+--------+
  2520.  
  2521. E=3 (0b0011) indicates that all the data is 64-bit, in Big Endian order. 
  2522. PktWay-WG                      <51>                            Appendix-C
  2523.  
  2524.  
  2525. Again, if Node1 had only Level-A implementation then it would have
  2526. pre-wired the combined L2RH from itself to RouterB and from there to
  2527. Node2, saving all this message exchange.
  2528.  
  2529. All the messages shown in this appendix start with local L2 routing
  2530. bytes needed to get across either SAN1 or SAN2 (indicated with "The
  2531. L2-header needed to get from ... to ...") which are not L2RHs.  The
  2532. difference is that these bytes are in front of the packet, exposed to
  2533. the local switches, whereas the L2RHs are only exposed to
  2534. PacketWay-entities.
  2535.  
  2536. These local L2 routing bytes are the actual bytes required by the SANs
  2537. and likely to be consumed as the messages traverses the SAN, unlike the
  2538. L2RHs that are intact until converted to actual routing bytes.
  2539.  
  2540. The L2RHs start with 0b0000000011 followed by the number of routing
  2541. bytes in that L2RH, and possibly also by several bytes of padding.
  2542. Appendix-C                      <52>                            PktWay-WG
  2543.  
  2544.  
  2545.  
  2546.  
  2547.  
  2548.  
  2549.  
  2550.  
  2551.  
  2552.  
  2553.  
  2554.  
  2555.  
  2556.  
  2557.  
  2558.  
  2559.  
  2560.  
  2561.                  [ B l a n k ]
  2562. PktWay-WG                      <53>                          GLOSSARY (D)
  2563.  
  2564.  
  2565.               Appendix-D: Glossary
  2566.                           --------------------
  2567.  
  2568. Address:        A unique designation of a node (actually an interface to
  2569.                 that node) or a SAN.
  2570.  
  2571. Buddy-HR:       HRs are "buddies" if they are on the same SAN.
  2572.  
  2573. Cut-Thru:    See wormhole.
  2574.  
  2575. Destination:    The node to which a packet is intended
  2576.  
  2577. Dynamic-Routing: Routing according to dynamic information
  2578.                 (i.e., acquired  at run time, rather than pre-set).
  2579.  
  2580. Endianness:     The property of being Big-Endian or Little-Endian
  2581.         (transmission order, etc.)
  2582.  
  2583. Ethertype:    A 16-bit value designating the type of Level-3 packets
  2584.         carried by a Level-2 communication system.
  2585.  
  2586. HR:             Half-Router, the part of a router that handles one
  2587.                 network only.
  2588.  
  2589. L2-Forwarding:    Forwarding based on Level-2 (i.e., data-link layer
  2590.         of the ISORM) information, e.g., the native technique
  2591.         of each SAN or LAN.  Also called "source routing."
  2592.  
  2593. L3-Forwarding:    Forwarding based on end-to-end Level-3 (i.e., network
  2594.         layer of the ISORM) addresses.  Also called
  2595.         "destination routing."
  2596.  
  2597. MAC:        Message Authentication Code.
  2598.  
  2599. Map:            The topology of a network.
  2600.  
  2601. Mapper:        A node on a SAN/LAN that has the map and an RT for that
  2602.         network.  It is expected that the mapper dynamically
  2603.         updates the map and the RT.
  2604.  
  2605. Multi-homed Node: A node with more than one network interface, where each
  2606.                 interface has another address.
  2607.  
  2608. Node:           Whatever can send and receive packets (e.g., a computer,
  2609.                 an MPP, a software process, etc.)
  2610.  
  2611. Node structure: A C-struct (or equivalent)n containing values for some
  2612.         attributes of a node.
  2613.  
  2614. Planned Transfer: Transfer of information, occurs after an initial phase
  2615.                 in which the sender decides which Level-2 route to use
  2616.                 for that transfer.
  2617.  
  2618. RCVF:           The "Received From" set includes all the physical
  2619.                 addresses through which an RT was disseminated, starting
  2620.         with that of the mapper that created that RT.
  2621.  
  2622. Re-direct-message: A message that tells nodes which HR should be used in
  2623. GLOSSARY (D)                      <54>                      PktWay-WG
  2624.  
  2625.  
  2626.                 order to get to a certain remote address (or range of).
  2627.  
  2628. Router:         The inter-SAN communication device
  2629.  
  2630. SAN:            System Area Network.
  2631.  
  2632. Security Context: A relationship between 2 (or more) nodes that defines
  2633.         how the nodes utilize security services to communicate
  2634.         securely. 
  2635.  
  2636. Source:         The node that created a packet.
  2637.  
  2638. Source-Route:   A Level-2 route that is chosen for a packet by its source.
  2639.  
  2640. Symbol:        Data preceeding the EEP header of a PktWay message,
  2641.         interleaving with the L2RHs.
  2642.  
  2643. Twin-HR:        Two HRs are twins if they both are parts of the same
  2644.                 inter-SAN router.
  2645.  
  2646. Wormhole-routing: (aka cut-thru routing) forwarding packets out of
  2647.                 switches as soon as possible, without storing that
  2648.                 entire packet in the switch (unlike Stop-and-forward).
  2649.  
  2650. Zero-copy TCP:  A TCP system that copies data directly between the user
  2651.                 area and the network device, bypassing OS copies.
  2652.  
  2653. PktWay-WG                      <55>                          ACRONYMS (E)
  2654.  
  2655.                 
  2656.                  Appendix-E: Acronyms and Abbreviations
  2657.                  --------------------------------------
  2658.  
  2659. 0bNNNN  The binary number NNNN (e.g., 0b0100 is 4-decimal)
  2660. 0xNNNN  The hexadecimal number NNNN (e.g., 0x0100 is 256-decimal)
  2661. 8B      8 byte (64 bits) entity
  2662. ADDR    The Address-record of RRP
  2663. API    Application/Program Interface
  2664. AT    Address Type
  2665. ATM    Asynchronous Transmission Mode
  2666. BC    Byte Count (of parameters)
  2667. BER    Bit Error Rate
  2668. CAPA    The capability-record of RRP
  2669. CC    Capability Code
  2670. CSR     Common Source-Route
  2671. DA    Destination Address
  2672. DB    Data Block
  2673. DL    Data Length (in 8B words)
  2674. DSP     Digital Signal Processor
  2675. e    The MSbit of E
  2676. E    The Endianness field (in the EEP header)
  2677. EEP     End/End Protocol
  2678. EI    Error Indication
  2679. GP    General Purpose
  2680. GVL2    An RRP message, requesting L2 route to a given destination
  2681. GVRT    An RRP message asking an HR to give its routing tables
  2682. h    Optional header fields flag
  2683. HR      Half Router
  2684. HRTO    An RRP message asking which HR to use for a given destination
  2685. ID      Identification
  2686. IGMP    Internet Group Management Protocol
  2687. INFO    An RRP message providing information about nodes
  2688. IP    The Internet protocol
  2689. ISORM    The ISO Reference Model
  2690. L       Length
  2691. L2      Level-2 of the ISORM (Link)
  2692. L2RH    Level-2 Routing Header 
  2693. L2SR    Source Route
  2694. L3      Level-3 of the ISORM (Network)
  2695. LA    Logical Address
  2696. LADR    The Logical-addresses-record of RRP
  2697. LAN    Local Area Network
  2698. LRT     Local Routing Table
  2699. LSbit   Least Significant bit
  2700. LSbyte  Least Significant byte
  2701. MPI    Message Passing Interface
  2702. MPP    Massively Parallel Processing system
  2703. MSbit   Most Significant bit
  2704. MSbyte  Most Significant byte
  2705. MTU    Maximum Transmission Unit
  2706. MTUR    The MTU-record of RRP
  2707. NAME    The name-record of RRP
  2708. NFS     Network File Server
  2709. ACRONYMS (E)                      <56>                      PktWay-WG
  2710.  
  2711.  
  2712. OH    Optional Header field
  2713. OH-TYPE    The Type of an Optional Header field
  2714. OT    Optional Trailer field
  2715. P       The Priority field
  2716. PAD     Padding After Data
  2717. PBD     Padding Before Data
  2718. PCI     The Peripheral Component Interconnect "standard"
  2719. PH      PacketWay Header 
  2720. PL    Padding Length (always in bytes)
  2721. PPP     The Point-to-Point Protocol
  2722. PROM    Programmable ROM (Read-Only-Memory)
  2723. PT    Packet Type
  2724. PW    The Myrinet Packet Type assigned to PktWay (PW=0x0300)
  2725. Q       Quality (of a path)
  2726. RCVF    Received-From list, or the Received-From record of RRP
  2727. RDRC    A Re-direct message of RRP
  2728. RH      Routing Header 
  2729. RID    Record ID
  2730. RL    Record Length (in 8B-words)
  2731. RRP     Router/Router Protocol
  2732. RT-hd   RT (Routing Table) header
  2733. RT      Routing Table
  2734. RTBL    An RRP message proving a Routing Table
  2735. RTHD    The Routing-Table-Header record of RRP
  2736. RTyp    RRP's Record Type
  2737. RZ    The Reserved field (in the EEP header)
  2738. SA    Source Address
  2739. SAN     System Area Network
  2740. SAN-ID    The 24-bit PktWay-address of a SAN
  2741. SAR    Segmentation and Reassembly
  2742. SN      Serial Number
  2743. SNMP    Simple Network Management Protocol
  2744. SR      Source Route (always at Level-2)
  2745. SRQR    The Source-Route-and-Q-record of RRP
  2746. TAIL    PacketWay EEP Trailer (the Error Indication, EI)
  2747. TE    Type Extension
  2748. TELL    An RRP message requesting information about nodes partially specified
  2749. UNK    Unknown
  2750. V       Version
  2751. WRU?    An RRP message asking its recipient to identify itself
  2752. XRT     External Routing Table
  2753. xxx    A padding byte
  2754.  
  2755.  
  2756.  
  2757.  
  2758.  
  2759.  
  2760.  
  2761.  
  2762.  
  2763.  
  2764.  
  2765.                   draft-PktWay-protocol-spec-03.txt
  2766.                expires April 1997
  2767.                                             [end]
  2768.