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