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-rrp1-spec-00.txt < prev    next >
Text File  |  1997-10-23  |  73KB  |  1,700 lines
  1.  
  2. Network Working Group                                        Danny Cohen
  3. Internet Draft                                                   Myricom
  4. Expires in six months                                         Craig Lund
  5.                                                        Mercury Computers
  6.                                                            Tony Skjellum
  7.                                             Mississippi State University
  8.                                                             Thom McMahon
  9.                                             Mississippi State University
  10.                                                            Robert George
  11.                                             Mississippi State University
  12.                                                             October 1997
  13.  
  14.                    Part-1 of
  15.        The Router-to-Router (RRP) PacketWay Protocol for
  16.      High-Performance Interconnection of Computer Clusters
  17.               <draft-ietf-pktway-protocol-rrp1-spec-00.txt>
  18.  
  19. Status of this Memo
  20.  
  21.      This document is an Internet-Draft.  Internet-Drafts are working
  22.      documents of the Internet Engineering Task Force (IETF), its
  23.      areas, and its working groups.  Note that other groups may also
  24.      distribute working documents as Internet-Drafts.
  25.  
  26.      Internet-Drafts are draft documents valid for a maximum of six
  27.      months and may be updated, replaced, or obsoleted by other
  28.      documents at any time.  It is inappropriate to use Internet-
  29.      Drafts as reference material or to cite them other than as
  30.      "work in progress."
  31.  
  32.      To view the entire list of current Internet-Drafts, please check
  33.      the "1id-abstracts.txt" listing contained in the Internet-Drafts
  34.      Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  35.      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  36.      Coast), or ftp.isi.edu (US West Coast).
  37.  
  38. Table of Content:
  39.  
  40.     1. Introduction....................................................2
  41.     2. A note about the PktWay documents...............................5
  42.     3. Notations.......................................................5
  43.     4. Implementation Levels of RRP....................................6
  44.     5. Use of RRP Messages by Levels...................................7
  45.     6. Node Attributes.................................................8
  46.     7. RRP Messages....................................................9
  47.     8. RRP Message Structure..........................................10
  48.     9. RRP Record Format..............................................12
  49.    10. Examples for RRP Message.......................................16
  50.    11. Appendix-A: Example of the use of RRP..........................21
  51.    12. Appendix-B: Glossary...........................................26
  52.    13. Appendix-C: Acronyms and Abbreviations.........................27
  53.    14. Appendix-D: PktWay at a Glance ("cheat-sheet").................29
  54.    15. Security Considerations........................................30
  55.    16. Editor's Address...............................................30
  56.  
  57. Cohen et al                                                    [Page  1]
  58.  
  59. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  60.  
  61.  
  62. 1. Introduction
  63.                                     
  64.    The PktWay protocol is introduced in the "The End-to-End (EEP)
  65.    PacketWay Protocol for High-Performance Interconnection of Computer
  66.    Clusters".  This document defines the basic part (Part 1) of the
  67.    Router-to-Router protocol (RRP) of PacketWay.
  68.  
  69.    The shorter "PktWay" is used for "PacketWay".
  70.  
  71.    More information about the PktWay activity is available from the
  72.    PktWay web site {http://www.erc.msstate.edu/PktWay}.
  73.  
  74.    The architecture of PktWay is very similar to the IP family (indeed,
  75.    it heavily borrows from IP), with emphasis on performance not
  76.    generality and scaleability as was selected for IP.
  77.  
  78.    Like IP, PktWay is based on an End-to-End protocol (EEP) that assumes
  79.    that if an address (or equivalent specification of the destination)
  80.    is placed in the appropriate field in the packet header, then the
  81.    packet will arrive to that destination.  Neither IP nor EEP specify
  82.    how this happens.
  83.  
  84.    Routers are responsible to transfer packets from their source
  85.    networks to their destination networks (possibly via other networks).
  86.  
  87.    The communication among the routers (such the entire family of the
  88.    GGPs [Gateway/Gateway Protocols] as they were originally called) is
  89.    NOT a part of IP (as defined originally in RFC-791 and MIL-STD-1777).
  90.    Similarly, nor is it a part of EEP.
  91.  
  92.    Like the IP family, PktWay defines separately its Router-to-Router
  93.    Protocol (RRP), in a device- and network-independent manner.
  94.  
  95.    However, the model of routers in PktWay is slightly different from
  96.    the original model in the IP family.  IP routers (or gateways as they
  97.    were called then) are monolithic devices, provided by their vendors.
  98.    Each IP-router is a bona-fide host on two (or more) networks.  The
  99.    communication among these intra-router hosts is an internal "private"
  100.    issue, handled by each vendor as it sees fit, not subject to
  101.    published standards.
  102.  
  103.    In the PktWay model a router is (like in the IP model) a set of
  104.    cooperating bona-fide hosts on two (or more) networks.  These hosts,
  105.    each being a full-fledged host on its SAN are called "half-routers"
  106.    (HRs).
  107.  
  108.    However, the intra-router communication among these hosts is a
  109.    "public" issue, handled according to the RRP which defines only the
  110.    Network-level [Level-2], and not the Physical-level [Level-1], of
  111.    this communication.
  112.  
  113.  
  114. Cohen et al                                                    [Page  2]
  115.  
  116. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  117.  
  118.    PktWay does not define the nature of this interconnection.  However,
  119.    we believe the PCI Local Bus de facto standard and internal SANs will
  120.    become a very popular link for short distances, and serial fiber for
  121.    long ones.
  122.  
  123.    Such an HR may be implemented by separate "boxes" with a long
  124.    inter-SAN communication link between them, or inside a single
  125.    "multi-homed" box that has an interface to each SAN, with these
  126.    interfaces being interconnected via a bus or an internal-SAN.
  127.  
  128.    RRP defines (via message structure and behavior) the interactions
  129.    between HRs, and between HRs and nodes.  RRP does not define the
  130.    lower level (PHY) protocols that deliver its messages (over links, or
  131.    between processes).  In particular, RRP does not define the inter-SAN
  132.    interconnection links between the HRs -- these are left for mutual
  133.    agreements among the implementors of each HR.  
  134.  
  135.    RRP defines (like IP's GGP) the router/router and the intra-SAN
  136.    node/router communication of PktWay.  Nodes usually do not
  137.    communicate explicitly with HRs on other SANs.
  138.  
  139.    The HRs within a single router are called "twins".  A router that is
  140.    connected to N SANs has N HRs, each being a twin of all the other
  141.    ones.  ("Half" and "twin" do not imply that there are only two.)
  142.  
  143.    All the HRs that are connected to the same SAN (being parts of
  144.    different routers) are called "buddies".
  145.  
  146.    An HR communicates with nodes on its own SAN, with its twins that are
  147.    on other SANs, and with its buddies that are on its SAN.  RRP defines
  148.    all these communications.
  149.  
  150.    Nodes may ask routers to forward messages to destinations specified
  151.    either by L2-routes or by L3-addresses.  Routers may provide
  152.    L2-routes to nodes upon their own initiative, or upon request by the
  153.    nodes.
  154.  
  155.    A node may ask (by [HRTO] messages) any router on its SAN, which
  156.    router on their SAN is the best to use for a given destination (the
  157.    nodes will typically ask their default routers for this information).
  158.  
  159.    In response, the router redirects (using [RDRC] messages) the node to
  160.    the best router for the specified destination.
  161.  
  162.    At any time routers may "redirect" the node by providing more
  163.    appropriate local routers for certain destinations, either upon
  164.    request by the node, or upon the initiative of the router (e.g., to
  165.    circumvent a fault).
  166.  
  167.  
  168.  
  169.  
  170.  
  171. Cohen et al                                                    [Page  3]
  172.  
  173. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  174.  
  175.    Nodes may ask (by [TELL]) routers for information about other nodes,
  176.    typically using PktWay-address, name, or capabilities to specify
  177.    those nodes.  In response, routers may provide (by [INFO]) a slew of
  178.    data about the specified node(s), including physical-address, and
  179.    optionally logical-addresses, name, and capabilities, if any.
  180.  
  181.    PktWay nodes may use a SRVLOC to locate required resources.
  182.  
  183.    It is assumed that each HR has a Routing Table (RT) for its own SAN
  184.    (aka Local Routing Table, LRT), with (at least) the addresses of all
  185.    the nodes and the source routes to each of them from the HR (and
  186.    possibly also names and capabilities for each node).  This
  187.    information could be dynamic or static, even manually configured.
  188.    The HRs may (or may not) perform dynamic mapping of their SANs.
  189.  
  190.    It is also assumed that each node, on each SAN/LAN, knows the SR to
  191.    at least one HR on its SAN/LAN, and that it has a default-HR defined.
  192.  
  193.    In order to be able to provide the nodes with such information, each
  194.    HR must collect this information about all the nodes in its own SAN.
  195.    This may be performed dynamically, or statically, in either an
  196.    automated or manual manner.  RRP does not sepcify how this
  197.    information is gathered.
  198.  
  199.    Each HR gives its Local Routing Table to all his twins.  HRs always
  200.    share with twins information received from buddies, and with buddies
  201.    information received from twins.  This yields the global mapping of
  202.    the PktWay.
  203.  
  204.    All the various RRP messages are composed of a small set of common
  205.    records.  This document defines the messages, their structure, their
  206.    common records, and their format.  Several examples are used to
  207.    illustrate the operation of the RRP.
  208.  
  209.    RRP specifies a series of options that allow system designers to
  210.    deploy PktWay nodes and routers of varying levels of capabilities
  211.    ("intelligence").
  212.  
  213.    There are four implementation levels of PktWay, indicated by a letter
  214.    code.  The higher the letter code ("A" = lowest), the more
  215.    interoperability and adaptability result.  System designers may
  216.    choose the level of implementation to best suit their needs.
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228. Cohen et al                                                    [Page  4]
  229.  
  230. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  231.  
  232.     
  233.  
  234. 2. A note about the PacketWay Documents
  235.  
  236.    The PacketWay protocol is defined by a series of documents: 
  237.       * EEP (End-to-End Protocol) 
  238.       * RRP-1 (basic Router-to-Router Protocol) 
  239.       * RRP-2 (dynamic inter-SAN routing) 
  240.       * PktWay enumerations
  241.  
  242.    Each of these documents should include the same "PacketWay at a
  243.    Glance (Cheat-Sheet)", this note, and the Notations page.  They
  244.    should include also (as appendices) a copy of the PacketWay glossary
  245.    of terms and its acronyms and abbreviations list.
  246.  
  247.    The EEP and the RRP documents will be published first as
  248.    Internet-Drafts and later as Proposed-Standards, Draft-Standards,
  249.    and Standards.
  250.  
  251.    The Enumeration Document will be first published as an
  252.    "Informational-RFC" and later will be maintained by IANA.
  253.  
  254.    The enumeration document may be attached to the EEP/RRP documents, as
  255.    a matter of convenience.  The enumeration is NOT a part of the PktWay
  256.    standard, just as RFC0739 (the original "Assigned Numbers" RFC) is
  257.    not a part of RFC0791, that defines IP.
  258.  
  259.    Similarly, the EEP-document has "Appendix-A: A Recommendation for
  260.    PktWay Address Assignment" which is a recommendation only and NOT
  261.    a part of the PktWay standard, just as IP-address-assignment is not
  262.    a part of RFC0791, that defines IP.
  263.  
  264.    The appendices are brought for clearance and convenience.  They are
  265.    not a part of the PktWay specification.
  266.  
  267.    Information about the PktWay activity may be found in the URL:
  268.    http://www.erc.msstate.edu/PktWay/
  269.  
  270.  
  271. 3. Notations
  272.  
  273.    The shorter "PktWay" is used for "PacketWay".
  274.  
  275.    8B means "8-byte" (64 bits).
  276.  
  277.    0x indicates hexadecimal values,  e.g., 0x0100 is 2^8=256(decimal).
  278.  
  279.    0b indicates binary values, e.g., 0b0100 is 4(decimal).
  280.  
  281.  
  282.  
  283.  
  284.  
  285. Cohen et al                                                    [Page  5]
  286.  
  287. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  288.    
  289.  
  290.    xxxx indicate a field that is discarded without any checking (e.g.,
  291.         padding).
  292.  
  293.    [fff] indicates that fff is an optional field, when appropriate.
  294.  
  295.    [exp] in equations, is the integral part, rounded down, of `exp`.
  296.          e.g., [23/8]=2.
  297.  
  298.    All length fields do not include themselves, and therefore may be 0.
  299.  
  300.    Lengths are specified either (a) by byte count, implying that some
  301.    padding bytes may follow to fill 8B-words, or (b) by 8B-word count
  302.    and PL, the number of trailing padding bytes (with PL between 0
  303.    and 7).
  304.  
  305.  
  306. 4. The Four Implementation Levels of RRP
  307.  
  308.    Level-A: Hosts have pre-wired (static) native routing.  It's an L2
  309.       ("MAC"-based) operation.  HRs do not provide any info to nodes,
  310.       nor to other HRs.  No RRP-messages are used in this level.
  311.  
  312.    Level-B: L2 (MAC based) or L3 forwarding (planner transfers, IP-like
  313.       operation).  Nodes may ask HRs for L2 routing and for the HR
  314.       to use for given destinations.  In this level the following
  315.       RRP-messages are used: [GVL2], [L2SR], [HRTO], and [RDRC].
  316.       In addition the [WRU]? and [INFO] messages may be used, too.
  317.  
  318.    Level-C: Node discovery (with static or dynamic routing).  In this
  319.       level nodes may ask HRs for information about other nodes,
  320.       including their capabilities.  In this level the [TELL] and the
  321.       [INFO] RRP-messages are used in addition to those of Level-B.
  322.  
  323.    Level-D: In this level there is a dynamic exchange of routing tables
  324.       among the HRs.  This create globals mapping of the PktWay, and
  325.       allows for dynamic circumvention of faults.  The [GVRT] and the
  326.       [RTBL] RRP-messages are used for this exchange among the HRs.
  327.             
  328.    Level-D applies only to routers, not to nodes.
  329.  
  330.    Level-B is an extension of Level-A (i.e., Level-B exists only with
  331.    Level-A).  Level-C and Level-D are independent extensions of Level-B.
  332.  
  333.    Level-B is the basic level of RRP.  This document, RRP Part-1
  334.    (aka RRP1), defines the RRP messages used for Level-B and Level-C.
  335.    Level-D is defined in RRP Part-2 (aka RRP2).
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342. Cohen et al                                                    [Page  6]
  343.  
  344. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  345.  
  346.    
  347.    In L2 operation under Level-B , when a source node, SN, needs to send
  348.    a message to a destination node, DN, it first uses a [GVL2] message
  349.    to ask any of the HRs on the SN's SAN for a source route (SR) from HR
  350.    to DN.  That HR would either (1) use an [L2SR] message to provide
  351.    such an SR, or (2) use an [RDRC] message to "re-direct", by
  352.    suggesting to SN to use the specified HR (which is also on SN's SAN),
  353.    or (3) use an error message to report no knowledge of DN (using the
  354.    UNK error message).
  355.  
  356.    SN may ask more than one HR for SRs to the same DN and use any
  357.    algorithm to choose which of these SRs to use.
  358.  
  359.    RRP does not specify whether (and how) to cache SRs.
  360.  
  361.    In L3 operation, when a source node, SN, needs to send a message to a
  362.    destination node, DN, it sends that message to any of the HRs on its
  363.    SAN, using L2, expecting L3-forwarding to DN, using DN's PktWay
  364.    address.  That HR would either (1) forward the message toward DN, and
  365.    possibly return to SN a "re-direct" message, suggesting to use, in
  366.    the future, another HR on SN's SAN for DN, or (2) report no knowledge
  367.    of DN (using the UNK error message).
  368.  
  369.    Under Level-C nodes may be located by PktWay-addresses, names,
  370.    or capabilities, but only addresses may be used for routing.
  371.  
  372.  
  373. 5. Use of RRP Messages by Levels
  374.  
  375.    Level-A: no RRP messages used
  376.  
  377.    Level-B: nodes send:      HRTO, GVL2, WRU?, INFO
  378.             nodes receive:   RDRC, L2SR, INFO, WRU?
  379.             routers receive: HRTO, GVL2, WRU?, INFO
  380.             routers send:    RDRC, L2SR, INFO, WRU?
  381.    
  382.    Level-C: nodes send:      HRTO, GVL2, WRU?, INFO, TELL
  383.             nodes receive:   RDRC, L2SR, INFO, WRU?
  384.             routers receive: HRTO, GVL2, WRU?, INFO, TELL
  385.              routers send:    RDRC, L2SR, INFO, WRU?
  386.    
  387.    Level-D: nodes send:      HRTO, GVL2, WRU?, INFO
  388.             nodes receive:   RDRC, L2SR, INFO, WRU?
  389.             routers receive: HRTO, GVL2, WRU?, INFO, GVRT, RTBL
  390.             routers send:    RDRC, L2SR, INFO, WRU?, GVRT, RTBL
  391.  
  392.  
  393.    This RRP1 document defines the 7 messages required for Levels B and C
  394.    (HRTO, RDRC, GVL2, L2SR, TELL, INFO, and WRU?).  The RRP2 document
  395.    defines the 2 messages required for Level D (GVRT and RTBL).
  396.    In addition, a few error messages are also defined.
  397.  
  398.  
  399. Cohen et al                                                    [Page  7]
  400.  
  401. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  402.  
  403.  
  404.  
  405. 6. Node Attributes
  406.  
  407.    Each node must have a Physical Address.  Optionally it may also have
  408.    Name, Capabilities, and Logical-Addresses:
  409.  
  410.       Physical Address: 23 bits, flat, unique in this PktWay.
  411.  
  412.       Name: flat, globally unique (e.g., IP address), arbitrary length
  413.  
  414.       Capabilities: regular GP node, router, PktWay-server, NFS, paging
  415.                     server, M/C server, SRVLOC-server, DSP, printer,...
  416.  
  417.                     Some capabilities may need additional parameters
  418.                     (e.g., SAN-ID for routers, and resolution+colors
  419.                     for printers).  
  420.  
  421.                     There parameters are capability-specific.
  422.  
  423.                     The capabilities are defined in the PktWay
  424.                     Enumeration document.
  425.  
  426.     Logical-Addresses:  a set of (logical) addresses to which this node
  427.                     requests to listen.  Logical addresses designate
  428.                     multicast and broadcast groups.
  429.  
  430.                     The control of the Logical-Addresses (a la IGMP)
  431.                     is not defined in this document.  This will be
  432.                     designed by the applications that use it (e.g.,
  433.                     PktWay-multicast).
  434.  
  435.                     The management of logical addresses (e.g., JOIN
  436.                     and LEAVE) is not defined here.
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454. Cohen et al                                                    [Page  8]
  455.  
  456. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  457.  
  458.  
  459. 7. RRP Messages
  460.  
  461.    RRP messages are PktWay messages with PT="RRP" and TE=RRP-type,
  462.    in their EEP-header, followed by some (zero or more) RRP-records
  463.    according to their RRP-type, followed (always) by the PktWay-TAIL
  464.    which is the EI field.
  465.  
  466.    The RRP-records constitute the Data Block (DB) of the PktWay-message.
  467.    They must be in Big-Endians order, with e=0 in the EEP-header.
  468.  
  469.    Following are the 7 RRP messages (for Level B and C), with their
  470.    RRP-type, and the related error messages.  The column S->D (Source
  471.    to Destination) shows who sends such messages to whom, where N is
  472.    for Node, H is for HR, and A is for Any.
  473.  
  474.     RRP-
  475.     Type       S->D   Description
  476.    --------   ------  -----------------------------------------------
  477.    [GVL2]      N->H   Please give me L2-routes to node (address)
  478.                         Replies to [GVL2]: [L2SR], [RDRC], or [ERR/UNK].
  479.    [L2SR]      H->N  Here are L2-routes to node (address)
  480.  
  481.    [HRTO]      N->H  Which HR should I use for node (address)?
  482.                         Replies to [HRTO]: [RDRC] or [ERR/UNK].
  483.    [RDRC]      H->N  Re-direct to node (address) via an HR on same SAN
  484.  
  485.    [TELL]      N->H  Please tell me about node (address, name, capa's)
  486.                         The reply to [TELL] is [INFO], or [ERR/UNK].
  487.    [INFO]      A->A  Info about node (address, name, capabilities, LAs)
  488.  
  489.    [WRU?]      A->A  Who/what-Are-You?  (Tell me all about yourself)
  490.                         The reply to [WRU?] is [INFO] about the replier.
  491.  
  492.    RRP also uses the following error messages:
  493.  
  494.    [ERR/UNK]          Destination Unknown (address)
  495.    [ERR/HRDOWN]       HR Down
  496.    [ERR/LKDOWN]       Link Down
  497.    [ERR/GENERAL]      General error message
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511. Cohen et al                                                    [Page  9]
  512.  
  513. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  514.  
  515.    
  516. 8. RRP Message Structure
  517.  
  518.    The RRP-messages are made of RRP-records, distinguished by their
  519.    Record-Type (RTyp).  These RRP records are:
  520.  
  521.        RTyp   Description
  522.        ----   ----------------------------------
  523.        ADDR   Address
  524.        NAME   Name
  525.        CAPA   Capability
  526.        LADR   Logical Addresses
  527.        SRQR   Source Route and its Quality (SR,Q)
  528.        MTUR   MTU (for the preceding SRQR)
  529.  
  530.    The RRP-records are made of 8B-words.  The following shows the
  531.    RRP-records that make each of the RRP-messages.  Each message
  532.    starts with a PH (PktWay-header), and ends with a PT (PktWay-TAIL).
  533.    The TAIL is not shown here.
  534.  
  535.    * [GVL2] Please give me L2-routes from you to node (address)
  536.  
  537.            PH (with [PT/TE]=[RRP/GVL2]) 
  538.            ADDR (address of the node for which SR is requested)
  539.  
  540.  
  541.    * [L2SR] Here are L2-routes from me to node (address)
  542.  
  543.            PH (with [PT/TE]=[RRP/L2SR]) 
  544.            ADDR (address of the node for which SR is provided) 
  545.            SRQR (SR with Q) possibly with a few
  546.            L2RH records MTUR (MTU for the above SR)
  547.  
  548.            This message may have several (SRQR,MTUR)s, one for each SR.
  549.  
  550.  
  551.    * [HRTO] Which HR should I use for node (address)
  552.  
  553.            PH   (with [PT/TE]=[RRP/HRTO])
  554.            ADDR (address of the node for which initial HR is requested)
  555.  
  556.  
  557.    * [RDRC] Re-direct to destination node (address) via a HR (address),
  558.             on the same SAN.
  559.  
  560.            PH   (with [PT/TE]=[RRP/RDRC])
  561.            ADDR (address of the destination node)
  562.            ADDR (address of the HR to be used for that destination)
  563.  
  564.            The above addresses are expected to be physical (but they
  565.            be otherwise). 
  566.  
  567.  
  568. Cohen et al                                                    [Page 10]
  569.  
  570. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  571.  
  572.  
  573.    * [TELL] Please tell me about node (address | name | capabilities)
  574.  
  575.            PH   (with [PT/TE]=[RRP/TELL])
  576.            ADDR (address of that node)
  577.         or
  578.            PH   (with [PT/TE]=[RRP/TELL])
  579.            NAME (name of that node)
  580.         or
  581.            PH   (with [PT/TE]=[RRP/TELL])
  582.            CAPA (capabilities for which nodes are requested)
  583.  
  584.            This message may have several CAPA's, one for each
  585.            capability.
  586.  
  587.            [TELL] identifies a node by an address and/or a name and/or
  588.            capabilities.  If more than one attribute is specified (e.g.,
  589.            an address and name(s)) any nodes that meets any of them
  590.            should be considered (like an implied OR).
  591.  
  592.  
  593.    * [INFO] Info about node(s) (address, name, capabilities)
  594.  
  595.            PH   (with [PT/TE]=[RRP/INFO])
  596.            ADDR (address of that node)
  597.            NAME (name of that node)
  598.            CAPA (capabilities for which nodes are requested)
  599.            LADR (Logical-Addresses for the requested node)
  600.  
  601.            This message may have several CAPA's, one for each
  602.            capability.  For nodes without NAME, LADR, or any CAPA,
  603.            these records are omitted.
  604.  
  605.            [INFO] provides all the known information about all the nodes
  606.            that match the [TELL].  The [ADDR} records are the separators
  607.            between the nodes.
  608.  
  609.  
  610.    * [WRU?] (CD) Who/what-Are-You?
  611.  
  612.            PH   (with [PT/TE]=[RRP/WRU?] and [DD]=0x7FFFFE)
  613.  
  614.    * [ERR/UNK] Destination Unknown (address)
  615.  
  616.            PH   (with [PT/TE]=ERROR/UNK)
  617.            XXXX (XXXX of the Destination node for which the requested
  618.                  information is not available), where XXXX is the ADDR
  619.                  and/or NAME and/or CAPA of the node(s) about which this
  620.                  message is sent
  621.  
  622.  
  623. Cohen et al                                                    [Page 11]
  624.  
  625. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  626.  
  627.  
  628.    * [ERR/HRDOWN] HR Down (or Router-Down)
  629.  
  630.            PH   (with [PT/TE]=[ERROR/HRDOWN])
  631.            ADDR (address of the HR that is down)
  632.            ADDR (the other address of the router that is down)
  633.  
  634.  
  635.    * [ERR/LINKDOWN] Link Down
  636.  
  637.            PH   (with [PT/TE]=[ERROR/LINKDOWN])
  638.            ADDR (address of one end of the link that is down)
  639.            ADDR (address of the other end of the link that is down)
  640.  
  641.  
  642.    * [ERR/GENERAL] General Error (i.e., none of the above)
  643.  
  644.            PH   (with [PT/TE]=[ERROR/GENERAL])
  645.            XX   (The entire message that caused the error PH+OH+DB+TAIL)
  646.  
  647.  
  648. 9. RRP Record Format
  649.  
  650.    Each RRP-record starts with an 8B-word header as shown below.  Its
  651.    first byte identifies the record type (RTyp).  The second byte is
  652.    the Pad-Count byte (PL) indicating the number of padding bytes.  The
  653.    third and the fourth bytes (RL) are the length (in 8B-words) of the
  654.    record, excluding the record header, hence it may be zero.  The rest
  655.    of the header bytes depend on the record type (RTyp).
  656.  
  657. +--------+--------+--------+--------+--------+--------+--------+--------+
  658. |  RTyp  |   PL   |       RL        |........|........|........|........|
  659. +--------+--------+--------+--------+--------+--------+--------+--------+
  660.     
  661.    Some records that have an arbitrary length are "right justified" and
  662.    have PL padding bytes before the data.  Padding Before Data [PBD].
  663.  
  664.    Some records that have an arbitrary length are "left justified" and
  665.    have PL bytes after the data.  Padding After Data [PAD].
  666.  
  667.    In either case the total number of data bytes is: (8*RL+4-PL).
  668.  
  669.    Following are the RRP-records.  These records are the building blocks
  670.    used to construct RRP-messages.
  671.  
  672.    In the following xxxx indicate bytes that are discarded, such as for
  673.    padding.  It is recommended to set them to all-0.
  674.  
  675.  
  676.  
  677.  
  678.  
  679. Cohen et al                                                    [Page 12]
  680.  
  681. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  682.    
  683.  
  684.  
  685.    ===> [ADDR] Node-Address Record [PAD]
  686.  
  687.    This record specifies either a single address (with AT=1) or a range
  688.    of addresses (with AT=2 followed by AT=3, or by AT=4 followed by AT=5).
  689.    AT is the "Address-Type".
  690.  
  691.     0        1        2        3        4        5        6        7
  692. +--------+--------+--------+--------+--------+--------+--------+--------+
  693. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |      PktWay-Address      |
  694. +--------+--------+--------+--------+--------+--------+--------+--------+
  695.  
  696.    or:
  697.     0        1        2        3        4        5        6        7
  698. +--------+--------+--------+--------+--------+--------+--------+--------+
  699. | "ADDR" |  PL=4  |      RL=1       |  AT=2  |    Min-PktWay-Address    |
  700. +--------+--------+--------+--------+--------+--------+--------+--------+
  701. |  AT=3  |    Max-PktWay-Address    |  xxxx  |  xxxx  |  xxxx  |  xxxx  |
  702. +--------+--------+--------+--------+--------+--------+--------+--------+
  703.  
  704.    or:
  705.     0        1        2        3        4        5        6        7
  706. +--------+--------+--------+--------+--------+--------+--------+--------+
  707. | "ADDR" |  PL=4  |      RL=1       |  AT=4  |   PktWay-Address-Value   |
  708. +--------+--------+--------+--------+--------+--------+--------+--------+
  709. |  AT=5  |   PktWay-Address-Mask    |  xxxx  |  xxxx  |  xxxx  |  xxxx  |
  710. +--------+--------+--------+--------+--------+--------+--------+--------+
  711.  
  712.    The address-mask follows the address-value.
  713.  
  714.    The above addresses may be physical or logical.
  715.  
  716.    The address X is specified by an ADDR record if:
  717.  
  718.    if AT=1:                            X  == PktWay-Address 
  719.  
  720.    if AT=2,3:   Min-PktWay-Address <=  X  <= Max-PktWay-Address 
  721.  
  722.    if AT=4,5:   (PktWay-Address-Mask & X) == PktWay-Address-Value
  723.  
  724.    An ADDR-record defines only one PktWay-address (or one range), unlike an
  725.    LADR record (see below) that may specify multiple addresses and multiple
  726.    address-ranges.
  727.  
  728.    If the ADDR record is followed by other records that describe the same
  729.    node (such as NAME, CAPA, LADR, SRQR, and MTUR) then the RL of the ADDR
  730.    records also covers all these records.  All these records apply to all
  731.    the addresses specified in this ADDR-record.  Needless to say that NAME
  732.    is not expected to appear within a record that specifies more than one
  733.    address.
  734.  
  735.  
  736. Cohen et al                                                    [Page 13]
  737.  
  738. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  739.  
  740.  
  741.    Hence, if an ADDR-record with AT=1 has RL>1, or if an ADDR-record
  742.    with AT>1 has RL>2, then this ADDR-record includes additional records
  743.    (such as CAPA, LADR, SRQR, and/or MTUR) about the specified
  744.    address(es).
  745.  
  746.    The enumeration is guaranteed not to have overlap between the AT and
  747.    the RTyp codes.
  748.  
  749.  
  750.    ===> [NAME] Node-Name Record [PAD] (e.g., a name with 7 bytes B1..B7)
  751.  
  752.     0        1        2        3        4        5        6        7
  753. +--------+--------+--------+--------+--------+--------+--------+--------+
  754. | "NAME" |  PL=3  |      RL=1       |   B1   |   B2   |   B3   |   B4   |
  755. +--------+--------+--------+--------+--------+--------+--------+--------+
  756. |   B5   |   B6   |   B7   |  xxxx  |  xxxx  |  xxxx  |  xxxx  |  xxxx  |
  757. +--------+--------+--------+--------+--------+--------+--------+--------+
  758.  
  759.       The number of bytes in the name is 8*RL+4-PL.
  760.  
  761.  
  762.  
  763.    ===> [CAPA] Node-Capability Record [PAD] (e.g., 9 parameter bytes):
  764.  
  765.     0        1        2        3        4        5        6        7
  766. +--------+--------+--------+--------+--------+--------+--------+--------+
  767. | "CAPA" |  PL=2  |      RL=1       | CC=Cx  |   P1   |   P2   |   P3   |
  768. +--------+--------+--------+--------+--------+--------+--------+--------+
  769. |   P4   |   P5   |   P6   |   P7   |   P8   |   P9   |  xxxx  |  xxxx  |
  770. +--------+--------+--------+--------+--------+--------+--------+--------+
  771.  
  772.    Byte#4 is the Capability Code, CC, followed by as many parameter
  773.    bytes as needed (9 in the above example).
  774.  
  775.    The capability codes are listed in the PktWay Enumeration document.
  776.  
  777.    The number of bytes used by the parameters is 8*RL+3-PL.
  778.  
  779.  
  780.    
  781.  
  782.    
  783.    
  784.    
  785.    
  786.    
  787.    
  788.    
  789.    
  790.    
  791.  
  792. Cohen et al                                                    [Page 14]
  793.  
  794. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  795.  
  796.    ===> [LADR] Logical-Addresses Record [PAD] 
  797.             (e.g., 2 logical addresses and a range of logical addresses)
  798.  
  799.     0        1        2        3        4        5        6        7
  800. +--------+--------+--------+--------+--------+--------+--------+--------+
  801. | "LADR" |  PL=4  |      RL=2       |  AT=1  |1110  Logical-Address-#1  |
  802. +--------+--------+--------+--------+--------+--------+--------+--------+
  803. |  AT=2  |1110  Min-Logical-Address |  AT=3  |1110  Max-Logical-Address |
  804. +--------+--------+--------+--------+--------+--------+--------+--------+
  805. |  AT=1  |1110  Logical-Address-#2  |  xxxx  |  xxxx  |  xxxx  |  xxxx  |
  806. +--------+--------+--------+--------+--------+--------+--------+--------+
  807.  
  808.    Whereas an ADDR-record defines only one PktWay-address (or one
  809.    range), an LADR record may specify multiple addresses (each with
  810.    AT=1) and multiple ranges (each with a pair of AT=2,3 or AT=4,5).
  811.    
  812.  
  813.    ===> [SRQR] Source-Route Record [PBD], with Q for that route.
  814.                (e.g., an SR combined of 2 L2RHs, one with 13 bytes and
  815.                 one with 4 bytes)
  816.  
  817.    This record carries one, or more, L2RHs (2 in the following example,
  818.    one with SR of 13B, followed by an SR of 5B). 
  819.  
  820.     1        2        3        4        5        6        7
  821. +--------+--------+--------+--------+--------+--------+--------+--------+
  822. | "SRQR" |  PL=2  |      RL=3       |  xxxx  |  xxxx  |        Q        |
  823. +--------+--------+--------+--------+--------+--------+--------+--------+
  824. |vv000000|10 L=13B|  SR01  |  SR02  |  SR03  |  SR04  |  SR05  |  SR06  |
  825. +--------+--------+--------+--------+--------+--------+--------+--------+
  826. |  SR07  |  SR08  |  SR09  |  SR10  |  SR11  |  SR12  |  SR13  |   xxxx |
  827. +--------+--------+--------+--------+--------+--------+--------+--------+
  828. |vv000000|10 L=4B |  SR01  |  SR02  |  SR03  |  SR04  |   xxxx |   xxxx |
  829. +--------+--------+--------+--------+--------+--------+--------+--------+
  830.  
  831.    Q (the Route Quality) is an unsigned 16-bit integer.  The units are
  832.    not defined here.  It is assumed that it is monotonic with all-0
  833.    being the best and all-1 the worst.  If there is an MTUR (MTU-record)
  834.    for that SR it should follow this SRQR record.  However, the RL of
  835.    the SRQR does not include the RL of the MTUR.
  836.  
  837.  
  838.    ===> [MTUR] MTU record [PBD]:
  839.  
  840.     0        1        2        3        4        5        6        7
  841. +--------+--------+--------+--------+--------+--------+--------+--------+
  842. | "MTUR" |  PL=0  |      RL=0       |         MTU (in 8B-words)         |
  843. +--------+--------+--------+--------+--------+--------+--------+--------+
  844.  
  845.    The MTU record provides the MTU for the SR defined before (by an SRQR).
  846.  
  847.    The value of 0 means indefinite MTU (i.e., any length is OK).
  848.  
  849. Cohen et al                                                    [Page 15]
  850.  
  851. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  852.  
  853.  
  854.  
  855. 10. Examples for RRP Message
  856.  
  857.  
  858.    Node-S asks HR1 to provide an L2RH to node-X:
  859.  
  860.    ==> [GVL2] Please give me L2-routes from you to node-X
  861.  
  862.     0        1        2        3        4        5        6        7
  863. +--------+--------+--------+--------+--------+--------+--------+--------+
  864. |00   P  |0      HR1-Address        |     "GVL2"      |     "R R P"     |
  865. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  866. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0        S-Address        |
  867. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  868. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |0        X-Address        |
  869. +--------+--------+--------+--------+--------+--------+--------+--------+
  870. |      64 zero bits, unless any error was indicated along the path      |
  871. +--------+--------+--------+--------+--------+--------+--------+--------+
  872.  
  873.    ==> [L2SR] HR1 replies with two L2-routes to node-X with Qs and MTUs
  874.        (e.g., an SR of 2 L2RHs (of 5+4 bytes), and an SR of 1 L2RH of 3 
  875.        bytes)
  876.  
  877.     0        1        2        3        4        5        6        7
  878. +--------+--------+--------+--------+--------+--------+--------+--------+
  879. |00   P  |0        S-Address        |      "L2SR"     |     "R R P"     |
  880. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  881. |E=0|PL=0| Data-Length=8 (8B-words) |0|  RZ  |0       HR1-Address       |
  882. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  883. | "ADDR" |  PL=0  |      RL=7       |  AT=1  |0        X-Address        |
  884. +--------+--------+--------+--------+--------+--------+--------+--------+
  885. | "SRQR" |  PL=2  |      RL=2       |  xxxx  |  xxxx  |        Q        |
  886. +--------+--------+--------+--------+--------+--------+--------+--------+
  887. |vv000000|10 L=5B |  SR01  |  SR02  |  SR03  |  SR04  |  SR05  |  xxxx  |
  888. +--------+--------+--------+--------+--------+--------+--------+--------+
  889. |vv000000|10 L=4B |  SR01  |  SR02  |  SR03  |  SR04  |  xxxx  |  xxxx  |
  890. +--------+--------+--------+--------+--------+--------+--------+--------+
  891. | "MTUR" |  PL=0  |      RL=0       |         MTU (in 8B-words)         |
  892. +--------+--------+--------+--------+--------+--------+--------+--------+
  893. | "SRQR" |  PL=2  |      RL=1       |  xxxx  |  xxxx  |        Q        |
  894. +--------+--------+--------+--------+--------+--------+--------+--------+
  895. |vv000000|10 L=3B |  SR01  |  SR02  |  SR03  |  xxxx  |  xxxx  |  xxxx  |
  896. +--------+--------+--------+--------+--------+--------+--------+--------+
  897. | "MTUR" |  PL=0  |      RL=0       |         MTU (in 8B-words)         |
  898. +--------+--------+--------+--------+--------+--------+--------+--------+
  899. |      64 zero bits, unless any error was indicated along the path      |
  900. +--------+--------+--------+--------+--------+--------+--------+--------+
  901.  
  902.  
  903.  
  904.  
  905.  
  906. Cohen et al                                                    [Page 16]
  907.  
  908. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  909.  
  910.    ==> [RDRC] HR1 redirects Node-S to use HR2 for node-X
  911.  
  912.     0        1        2        3        4        5        6        7
  913. +--------+--------+--------+--------+--------+--------+--------+--------+
  914. |00   P  |0        S-Address        |      "RDRC"     |     "R R P"     |
  915. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  916. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0       HR1-Address       |
  917. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  918. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |         X-Address        |
  919. +--------+--------+--------+--------+--------+--------+--------+--------+
  920. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |        HR2-Address       |
  921. +--------+--------+--------+--------+--------+--------+--------+--------+
  922. |      64 zero bits, unless any error was indicated along the path      |
  923. +--------+--------+--------+--------+--------+--------+--------+--------+
  924.  
  925.    ==> [TELL] Please tell about Node-X (address | name | capabilities)
  926.  
  927.    This message may have any of the following 3 forms:
  928.  
  929.    If by PktWay-address:
  930.  
  931.     0        1        2        3        4        5        6        7
  932. +--------+--------+--------+--------+--------+--------+--------+--------+
  933. |00   P  |0       HR1-Address       |      "TELL"     |     "R R P"     |
  934. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  935. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0        S-Address        |
  936. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  937. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |         X-Address        |
  938. +--------+--------+--------+--------+--------+--------+--------+--------+
  939. |      64 zero bits, unless any error was indicated along the path      |
  940. +--------+--------+--------+--------+--------+--------+--------+--------+
  941.  
  942.  
  943.    If by name (e.g., a name with 9 characters: A1...A9):
  944.  
  945.     0        1        2        3        4        5        6        7
  946. +--------+--------+--------+--------+--------+--------+--------+--------+
  947. |00   P  |0       HR1-Address       |      "TELL"     |     "R R P"     |
  948. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  949. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0        S-Address        |
  950. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  951. | "NAME" |  PL=3  |      RL=1       |   A1   |   A2   |   A3   |   A4   |
  952. +--------+--------+--------+--------+--------+--------+--------+--------+
  953. |   A5   |   A6   |   A7   |   A8   |   A9   |  xxxx  |  xxxx  |  xxxx  |
  954. +--------+--------+--------+--------+--------+--------+--------+--------+
  955. |      64 zero bits, unless any error was indicated along the path      |
  956. +--------+--------+--------+--------+--------+--------+--------+--------+
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963. Cohen et al                                                    [Page 17]
  964.  
  965. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  966.    
  967.  
  968.    If by capabilities (e.g., 2 capabilities, C1 with 2 parameter bytes,
  969.    and C2 with no parameter bytes):
  970.  
  971.     0        1        2        3        4        5        6        7
  972. +--------+--------+--------+--------+--------+--------+--------+--------+
  973. |00   P  |0       HR1-Address       |      "TELL"     |     "R R P"     |
  974. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  975. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0        S-Address        |
  976. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  977. | "CAPA" |  PL=1  |      RL=0       | CC=C1  |   P1   |   P2   |  xxxx  |
  978. +--------+--------+--------+--------+--------+--------+--------+--------+
  979. | "CAPA" |  PL=3  |      RL=0       | CC=C2  |  xxxx  |   xxxx |  xxxx  |
  980. +--------+--------+--------+--------+--------+--------+--------+--------+
  981. |      64 zero bits, unless any error was indicated along the path      |
  982. +--------+--------+--------+--------+--------+--------+--------+--------+
  983.  
  984.    A [TELL] may specify several nodes, by addresses, names, and
  985.    capabilities.  Any node that matches any of the specifications in
  986.    [the TELL] should be included in the replying [INFO], in separate
  987.    ADDR records.
  988.  
  989.    ==> [INFO] Info about Node-X (address, name, capabilities) e.g., a
  990.               name with 9 characters (A1...A9) and 3 capabilities (Cx,
  991.               Cy, and Cz):
  992.  
  993.     0        1        2        3        4        5        6        7
  994. +--------+--------+--------+--------+--------+--------+--------+--------+
  995. |00   P  |0        S-Address        |      "INFO"     |     "R R P"     |
  996. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  997. |E=0|PL=0| Data-Length=7 (8B-words) |0|  RZ  |0       HR1-Address       |
  998. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  999. | "ADDR" |  PL=0  |      RL=6       |  AT=1  |         X-Address        |
  1000. +--------+--------+--------+--------+--------+--------+--------+--------+
  1001. | "NAME" |  PL=3  |      RL=1       |   A1   |   A2   |   A3   |   A4   |
  1002. +--------+--------+--------+--------+--------+--------+--------+--------+
  1003. |   A5   |   A6   |   A7   |   A8   |   A9   |  xxxx  |  xxxx  |  xxxx  |
  1004. +--------+--------+--------+--------+--------+--------+--------+--------+
  1005. | "CAPA" |  PL=1  |      RL=0       | CC=Cx  |   P1   |   P2   |  xxxx  |
  1006. +--------+--------+--------+--------+--------+--------+--------+--------+
  1007. | "CAPA" |  PL=3  |      RL=0       | CC=Cy  |  xxxx  |  xxxx  |  xxxx  |
  1008. +--------+--------+--------+--------+--------+--------+--------+--------+
  1009. | "CAPA" |  PL=5  |      RL=1       | CC=Cz  |   P1   |   P2   |   P3   |
  1010. +--------+--------+--------+--------+--------+--------+--------+--------+
  1011. |   P4   |   P5   |   P6   |  xxxx  |  xxxx  |  xxxx  |  xxxx  |  xxxx  |
  1012. +--------+--------+--------+--------+--------+--------+--------+--------+
  1013. |      64 zero bits, unless any error was indicated along the path      |
  1014. +--------+--------+--------+--------+--------+--------+--------+--------+
  1015.  
  1016.  
  1017.  
  1018.  
  1019. Cohen et al                                                    [Page 18]
  1020.  
  1021. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1022.  
  1023.  
  1024.    The INFO records should specify all the nodes that meet any of the
  1025.    attributed specified in the TELL record.  When such aggregation is
  1026.    used, the DL (data length) in the PH is the sum of the (RL+1)s of
  1027.    all the ADDR fields.
  1028.  
  1029.    (*) The ADDR, NAME, and CAPA records are repeated for each applicable
  1030.        node. Same also for LADR, SRQR, and MTUR, if any.
  1031.  
  1032.    If several capabilities are specified in [TELL], any node that has
  1033.    any of these capabilities should be reported in [INFO].
  1034.  
  1035.  
  1036.  
  1037.    ==> [HRTO] Node-S asks HR1 which HR to use for Node-X.
  1038.  
  1039.     0        1        2        3        4        5        6        7
  1040. +--------+--------+--------+--------+--------+--------+--------+--------+
  1041. |00   P  |0       HR1-Address       |      "HRTO"     |     "R R P"     |
  1042. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1043. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0        S-Address        |
  1044. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1045. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |         X-Address        |
  1046. +--------+--------+--------+--------+--------+--------+--------+--------+
  1047. |      64 zero bits, unless any error was indicated along the path      |
  1048. +--------+--------+--------+--------+--------+--------+--------+--------+
  1049.    
  1050.  
  1051.  
  1052.    ==> [WRU?] Who/what-Are-You?
  1053.  
  1054.     0        1        2        3        4        5        6          7
  1055. +--------+--------+--------+--------+--------+--------+--------+--------+
  1056. |00   P  |01111111|11111111|11111110|      "WRU?"     |     "R R P"     |
  1057. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1058. |E=0|PL=0| Data-Length=0 (8B-words) |0|  RZ  |0        S-Address        |
  1059. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1060. |      64 zero bits, unless any error was indicated along the path      |
  1061. +--------+--------+--------+--------+--------+--------+--------+--------+
  1062.  
  1063.    This is addressed to 0x7FFFFE, the "Hey-You" address.
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070.  
  1071.  
  1072.  
  1073.  
  1074.  
  1075. Cohen et al                                                    [Page 19]
  1076.  
  1077. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1078.  
  1079.  
  1080.    ==> [ERR/UNK] Destination Unknown (address).  HR1 tells Node-S that
  1081.                  he does not know about Node-X.
  1082.  
  1083.     0        1        2        3        4        5        6        7
  1084. +--------+--------+--------+--------+--------+--------+--------+--------+
  1085. |00   P  |0        S-Address        |       UNK       |     "E R R"     |
  1086. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1087. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0      HR1-Address        |
  1088. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1089. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |        X-Address         |
  1090. +--------+--------+--------+--------+--------+--------+--------+--------+
  1091. |      64 zero bits, unless any error was indicated along the path      |
  1092. +--------+--------+--------+--------+--------+--------+--------+--------+
  1093.  
  1094.    This message reports that host (X) is unknown to S.
  1095.  
  1096.  
  1097.    ==> [ERR/HRDOWN] HR Down (2 addresses).
  1098.                     HR1 tells Node-S that HR-X is down
  1099.  
  1100.     0        1        2        3        4        5        6        7
  1101. +--------+--------+--------+--------+--------+--------+--------+--------+
  1102. |00   P  |0        S-Address        |     "HRDOWN"    |     "E R R"     |
  1103. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1104. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0       HR1-Address       |
  1105. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1106. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |       HRX-Address-1      |
  1107. +--------+--------+--------+--------+--------+--------+--------+--------+
  1108. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |       HRX-Address-2      |
  1109. +--------+--------+--------+--------+--------+--------+--------+--------+
  1110. |      64 zero bits, unless any error was indicated along the path      |
  1111. +--------+--------+--------+--------+--------+--------+--------+--------+
  1112.  
  1113.    HR1 knows 2 addresses of the downed router.
  1114.  
  1115.    ==> [ERR/LINKDOWN] Link Down (2 addresses)
  1116.  
  1117.     0        1        2        3        4        5        6        7
  1118. +--------+--------+--------+--------+--------+--------+--------+--------+
  1119. |00   P  |0        S-Address        |    "LINKDOWN"   |     "E R R"     |
  1120. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1121. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0       HR1-Address       |
  1122. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1123. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |          A-Addr          |
  1124. +--------+--------+--------+--------+--------+--------+--------+--------+
  1125. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |          B-Addr          |
  1126. +--------+--------+--------+--------+--------+--------+--------+--------+
  1127. |      64 zero bits, unless any error was indicated along the path      |
  1128. +--------+--------+--------+--------+--------+--------+--------+--------+
  1129.  
  1130.    This message reports that the link between A-Addr and B-Addr is down.
  1131.  
  1132. Cohen et al                                                    [Page 20]
  1133.  
  1134. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1135.  
  1136.  
  1137.    ==> [ERR/GENERAL] General error: HR1 tells node-S that it (HR1) could
  1138.                      not handle the enclosed message)
  1139.  
  1140.     0        1        2        3        4        5        6        7
  1141. +--------+--------+--------+--------+--------+--------+--------+--------+
  1142. |00   P  |0        S-Address        |     GENERAL     |     "E R R"     |
  1143. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1144. |E=0|PL=0| Data-Length=? (8B-words) |0|  RZ  |0       HR1-address       |
  1145. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1146. |                                                                       |
  1147. |<------The entire message that could not be handled by the sender----->|
  1148. |                                                                       |
  1149. +--------+--------+--------+--------+--------+--------+--------+--------+
  1150. |      64 zero bits, unless any error was indicated along the path      |
  1151. +--------+--------+--------+--------+--------+--------+--------+--------+
  1152.  
  1153.    This message reports that the enclosed message could not be handled
  1154.    by its receiver (the sender of this error  message).
  1155.  
  1156.  
  1157. 11. Appendix-A:  Example of the use of RRP
  1158.  
  1159.    The following PktWay is used for the example.  It included 3 SANs,
  1160.    interconnected via 2 routers, Router-A (RTRA) between SAN1 and SAN3,
  1161.    and RTRB between SAN1 and SAN2.
  1162.  
  1163. +-------+          +--0--+   SAN1   +--0--+          +--0--+
  1164. | Node1 +----------3 SW0 1----------3 SW1 1----------3 SW2 1   MTU=16KB
  1165. +-------+          +--2--+          +--2--+          +--2--+
  1166.                       |                                 |
  1167.            RTRA1 ***********       +---+---+       *********** RTRB1
  1168.                  * RouterA *       | Node2 |       * RouterB *
  1169.            RTRA3 ***********       +---+---+       *********** RTRB2
  1170.                       |                |                |   
  1171. +-------+   SAN3   +--0--+          +--0--+   SAN2   +--0--+
  1172. | Node3 +----------3 SW3 1          3 SW4 1----------3 SW5 1   MTU=8KB
  1173. +-------+          +--2--+          +--2--+          +--2--+
  1174.  
  1175.    In this example Node1 on SAN1 (with MTU=16KB) is looking for Node2
  1176.    which is on SAN2 (with MTU=8KB).  It first asks its default router
  1177.    (RTRA1) for an L2RH to Node2.  RTRA1 redirects Node1 to RTRB1
  1178.    regarding Node2.
  1179.  
  1180.    Node1 asks RTRA1 (by [HRTO], in message M1) which router to use for
  1181.    Node2.  RTRA1 suggests (using [RDRC], M2) to use RouterB.  Node1 uses
  1182.    L3-forwarding ([WRU?], M3), via Router-B, to verify that RTRB can
  1183.    indeed get to Node2, by asking Node2 for information about itself.
  1184.    Node2 provides this information ([TELL], M4) which Node1 likes.
  1185.    Node1 asks RouterB ([GVL2], M5) for L2RH(s) to Node2.  RouterB
  1186.    provides ([L2SR], M6) the requested L2RH with its MTU of 1,024
  1187.    8B-words (8KB).
  1188.  
  1189. Cohen et al                                                    [Page 21]
  1190.  
  1191. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1192.    
  1193.  
  1194.    Finally, Node1 sends data (by M7) to Node2 using L2-forwarding.
  1195.    Similarly, Node2 may ask its default router which HR to use for
  1196.    Node1 and for L2RH(s) to Node1.
  1197.  
  1198.    If Node1 had only Level-A implementation then it should have the
  1199.    combined L2RH from itself to RouterB and from there to Node2
  1200.    pre-wired, saving all this message exchange.
  1201.  
  1202.    The sequence of messages (M1 thru M7) is shown below.
  1203.  
  1204.    (M1) Node1 sends [HRTO] to its default router RTRA1 asking which
  1205.         HR to use for node2.
  1206.  
  1207.     0        1        2        3        4        5        6        7
  1208. +-----------------------------------------------------------------------+
  1209. | <----     The L2-header needed to get from Node1 to RouterA1    ----> |
  1210. | It may be any number of bytes.  In this example it's 9 bytes:230000000|
  1211. +--------+--------+--------+--------+--------+--------+--------+--------+
  1212. |00   P  |0          RTRA1          |      "HRTO"     |     "R R P"     |
  1213. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1214. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0          Node1          |
  1215. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1216. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |0          Node2          |
  1217. +--------+--------+--------+--------+--------+--------+--------+--------+
  1218. |      64 zero bits, unless any error was indicated along the path      |
  1219. +--------+--------+--------+--------+--------+--------+--------+--------+
  1220.  
  1221.    (M2) RTRA1 uses [RDRC] to re-direct to Node2 via RouterB.
  1222.  
  1223.     0        1        2        3        4        5        6        7
  1224. +-----------------------------------------------------------------------+
  1225. | <----     The L2-header needed to get from RouterA1 to Node1    ----> |
  1226. | It may be any number of bytes.  In this example it's 9 bytes:330000000|
  1227. +--------+--------+--------+--------+--------+--------+--------+--------+
  1228. |00   P  |0          Node1          |      "RDRC"     |     "R R P"     |
  1229. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1230. |E=0|PL=0| Data-Length=2 (8B-words) |0|  RZ  |0          RTRA1          |
  1231. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1232. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |0          Node2          |
  1233. +--------+--------+--------+--------+--------+--------+--------+--------+
  1234. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |0          RTRB1          |
  1235. +--------+--------+--------+--------+--------+--------+--------+--------+
  1236. |      64 zero bits, unless any error was indicated along the path      |
  1237. +--------+--------+--------+--------+--------+--------+--------+--------+
  1238.  
  1239.    Node1 knows how to get to RouterB over its SAN.
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245. Cohen et al                                                    [Page 22]
  1246.  
  1247. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1248.  
  1249.  
  1250.    (M3) Node1 uses [WRU?] (still using L3-forwarding via RouterB) to
  1251.         verify the capabilities of Node-2, and that RTRB can indeed get
  1252.         to it. This is done by asking Node2 for information about itself.
  1253.  
  1254.     0        1        2        3        4        5        6        7
  1255. +-----------------------------------------------------------------------+
  1256. | <----     The L2-header needed to get from Node1 to RouterB1    ----> |
  1257. |    It may be any number of bytes.  Here it is 11 bytes: 11230000000   |
  1258. +--------+--------+--------+--------+--------+--------+--------+--------+
  1259. |00   P  |0          Node2          |      "WRU?"     |     "R R P"     |
  1260. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1261. |E=0|PL=0| Data-Length=0 (8B-words) |0|  RZ  |0          Node1          |
  1262. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1263. |      64 zero bits, unless any error was indicated along the path      |
  1264. +--------+--------+--------+--------+--------+--------+--------+--------+
  1265.  
  1266.    (M4) Node2 uses [INFO] (via RouterB2, also using L3-forwarding) to
  1267.         provide information about itself to Node1.  This info includes
  1268.         its PktWay-address and its name ("Super").  If Node2 had
  1269.         implemented also Level-C of the RRP it would also provide a
  1270.         record about its capabilities (as shown in this example with
  1271.         2 capabilities (with codes of 5 and 7).
  1272.  
  1273.     0        1        2        3        4        5        6        7
  1274. +-----------------------------------------------------------------------+
  1275. | <----     The L2-header needed to get from Node2 to RouterB2    ----> |
  1276. |     It may be any number of bytes.  Here it is 10 bytes: 1030000000   |
  1277. +--------+--------+--------+--------+--------+--------+--------+--------+
  1278. |00   P  |0          Node1          |      "INFO"     |     "R R P"     |
  1279. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1280. |E=0|PL=0| Data-Length=5 (8B-words) |0|  RZ  |0          Node2          |
  1281. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1282. | "ADDR" |  PL=0  |      RL=4       |  AT=1  |0          Node2          |
  1283. +--------+--------+--------+--------+--------+--------+--------+--------+
  1284. | "NAME" |  PL=7  |      RL=1       |  "S"   |  "u"   |  "p"   |  "e"   |
  1285. +--------+--------+--------+--------+--------+--------+--------+--------+
  1286. |  "r"   |  xxxx  |  xxxx  |  xxxx  |  xxxx  |  xxxx  |  xxxx  |  xxxx  |
  1287. +--------+--------+--------+--------+--------+--------+--------+--------+
  1288. | "CAPA" |  PL=1  |      RL=0       |  CC=7  |   4    |   8    |  xxxx  |
  1289. +--------+--------+--------+--------+--------+--------+--------+--------+
  1290. | "CAPA" |  PL=3  |      RL=0       |  CC=5  |  xxxx  |  xxxx  |  xxxx  |
  1291. +--------+--------+--------+--------+--------+--------+--------+--------+
  1292. |      64 zero bits, unless any error was indicated along the path      |
  1293. +--------+--------+--------+--------+--------+--------+--------+--------+
  1294.  
  1295.    By receiving this message Node1 knows that RTRB could indeed be used
  1296.    for communication with Node2.
  1297.  
  1298.  
  1299.  
  1300.  
  1301.  
  1302. Cohen et al                                                    [Page 23]
  1303.  
  1304. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1305.  
  1306.    (M5) Node1 uses [GVL2] to ask RouterB for L2RH(s) from RouterB to
  1307.     Node2. 
  1308.  
  1309.     0        1        2        3        4        5        6        7
  1310. +-----------------------------------------------------------------------+
  1311. | <----     The L2-header needed to get from Node1 to RouterB1    ----> |
  1312. |    It may be any number of bytes.  Here it is 11 bytes: 11230000000   |
  1313. +--------+--------+--------+--------+--------+--------+--------+--------+
  1314. |00   P  |0          RTRB1          |      "GVL2"     |     "R R P"     |
  1315. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1316. |E=0|PL=0| Data-Length=1 (8B-words) |0|  RZ  |0          Node1          |
  1317. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1318. | "ADDR" |  PL=0  |      RL=0       |  AT=1  |0          Node2          |
  1319. +--------+--------+--------+--------+--------+--------+--------+--------+
  1320. |      64 zero bits, unless any error was indicated along the path      |
  1321. +--------+--------+--------+--------+--------+--------+--------+--------+
  1322.  
  1323.    (M6) RouterB uses [L2SR] to provide Node1 with an L2RH from RTRB2 to
  1324.         Node2, with its Q and MTU.  This L2RH is {3,0,3,0,0,0,0,0,0,0}
  1325.         from RouterB to Node2, and the MTU is 1,024 (meaning 8KB).
  1326.  
  1327.     0        1        2        3        4        5        6        7
  1328. +-----------------------------------------------------------------------+
  1329. | <----     The L2-header needed to get from RouterB1 to Node1    ----> |
  1330. |    It may be any number of bytes.  Here it is 11 bytes: 33330000000   |
  1331. +--------+--------+--------+--------+--------+--------+--------+--------+
  1332. |00  P   |0          Node1          |      "L2SR"     |     "R R P"     |
  1333. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1334. |E=0|PL=0| Data-Length=4 (8B-words) |0|  RZ  |0          RTRA1          |
  1335. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1336. | "ADDR" |  PL=0  |      RL=3       |  AT=1  |0          Node2          |
  1337. +--------+--------+--------+--------+--------+--------+--------+--------+
  1338. | "SRQR" |  PL=2  |      RL=1       |  xxxx  |  xxxx  |        Q        |
  1339. +--------+--------+--------+--------+--------+--------+--------+--------+
  1340. |vv000000|10 L=4B |   3    |   0    |   3    |   0    |  xxxx  |  xxxx  |
  1341. +--------+--------+--------+--------+--------+--------+--------+--------+
  1342. | "MTUR" |  PL=1  |      RL=0       |      MTU=1,024 (in 8B-words)      |
  1343. +--------+--------+--------+--------+--------+--------+--------+--------+
  1344. |      64 zero bits, unless any error was indicated along the path      |
  1345. +--------+--------+--------+--------+--------+--------+--------+--------+
  1346.  
  1347.    The MTU in the MTUR above is the lessor of the MTUs of both networks.
  1348.  
  1349.    The RL (record-length) of the last MTUR-record is NOT included in the
  1350.    RL of the preceding SRQR-record, but is included in the RL of the
  1351.    preceding ADDR-record (since the RL of the SRQR is included in the RL
  1352.    of the ADDR).  The RL=3 of the ADDR includes 2 words of SRQR and
  1353.    1 word of MTUR.
  1354.  
  1355.  
  1356.  
  1357.  
  1358. Cohen et al                                                    [Page 24]
  1359.  
  1360. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1361.  
  1362.    
  1363.    (M7) Finally, Node1 sends data to Node2 using L2-forwarding.
  1364.  
  1365.     0        1        2        3        4        5        6        7
  1366. +-----------------------------------------------------------------------+
  1367. | <----     The L2-header needed to get from Node1 to RouterB1    ----> |
  1368. |    It may be any number of bytes.  Here it is 11 bytes: 11230000000   |
  1369. +--------+--------+--------+--------+--------+--------+--------+--------+
  1370. |vv000000|10 L=4B |   3    |   0    |   3    |   0    |  xxxx  |  xxxx  |
  1371. +--------+--------+--------+--------+--------+--------+--------+--------+
  1372. |00  P   |0          Node2          |Sensor.SubType=? |     "Sensor"    |
  1373. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1374. |E=3|PL=0| Data-Length=? (8B-words) |0|  RZ  |0          Node1          |
  1375. +---+----+--------+--------+--------+-+------+--------+--------+--------+
  1376. |                                                                       |
  1377. | <------------------- The sensor data goes here ---------------------> |
  1378. |                                                                       |
  1379. +--------+--------+--------+--------+--------+--------+--------+--------+
  1380. |      64 zero bits, unless any error was indicated along the path      |
  1381. +--------+--------+--------+--------+--------+--------+--------+--------+
  1382.  
  1383.    E=3 (0b0011) indicates that all the data is 64-bit, Big Endian order. 
  1384.  
  1385.    Again, if Node1 had only Level-A implementation then it would have
  1386.    pre-wired the combined L2RH from itself to RouterB and from there to
  1387.    Node2, saving all this message exchange.
  1388.  
  1389.    All the messages shown in this appendix start with local L2 routing
  1390.    bytes needed to get across either SAN1 or SAN2 (indicated with "The
  1391.    L2-header needed to get from ... to ...") which are not L2RHs.  The
  1392.    difference is that these bytes are in front of the packet, exposed
  1393.    to the local switches, whereas the L2RHs are only exposed to
  1394.    PktWay-entities.
  1395.  
  1396.    These local L2 routing bytes are the actual bytes required by the
  1397.    SANs and likely to be consumed as the messages traverses the SAN,
  1398.    unlike the L2RHs that are intact until converted to actual routing
  1399.    bytes.
  1400.  
  1401.    The L2RHs start with 0bvv00000010 followed by the number of routing
  1402.    bytes in that L2RH, and possibly also by several bytes of padding.
  1403.  
  1404.  
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414. Cohen et al                                                    [Page 25]
  1415.  
  1416. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1417.  
  1418.  
  1419. 12. Appendix-B: Glossary
  1420.  
  1421.    Address:       A unique designation of a node (actually an interface
  1422.                   to that node) or a SAN.
  1423.    Buddy-HR:       HRs are "buddies" if they are on the same SAN.
  1424.    Cut-Thru:       See wormhole.
  1425.    Destination:    The node to which a packet is intended
  1426.    Dynamic-Routing: Routing according to dynamic information
  1427.                    (i.e., acquired  at run time, rather than pre-set).
  1428.    Endianness:     The property of being Big-Endian or Little-Endian
  1429.                    (transmission order, etc.)
  1430.    Ethertype:      A 16-bit value designating the type of Level-3
  1431.                    packets carried by a Level-2 communication system.
  1432.    HR:             Half-Router, the part of a router that handles one
  1433.                    network only.
  1434.    L2-Forwarding:  Forwarding based on Level-2 (i.e., data-link layer
  1435.                    of the ISORM) information, e.g., the native technique
  1436.                    of each SAN or LAN.  Also called "source routing."
  1437.    L3-Forwarding:  Forwarding based on end-to-end
  1438.                    (Level-3 i.e., network layer of the ISORM) addresses.
  1439.                    Also called "destination routing."
  1440.    Map:            The topology of a network.
  1441.    Mapper:         A node on a SAN/LAN that has the map and an RT
  1442.                    for that network.  It is expected that the mapper
  1443.                    dynamically updates the map and the RT.
  1444.    Multi-homed Node: A node with more than one network interface, where
  1445.                    each interface has another address.
  1446.    Node:           Whatever can send and receive packets 
  1447.                    (e.g., a computer, an MPP, a software process, etc.)
  1448.    Node structure: A C-struct (or equivalent) containing values for some
  1449.                    attributes of a node.
  1450.    Planned Transfer: Transfer of information, occurs after an initial
  1451.                    phase in which the sender decides which Level-2 route
  1452.                    to use for that transfer.
  1453.    RCVF:           The "Received From" set includes all the physical
  1454.                    addresses through which an RT was disseminated,
  1455.                    starting with the address of the mapper that created
  1456.                    that RT.
  1457.    Re-direct-message: A message that tells nodes which HR should be
  1458.                    used in order to get to a certain remote address.
  1459.    Router:         The inter-SAN communication device
  1460.    Security Context: A relationship between 2 (or more) nodes that
  1461.                    defines how the nodes utilize security services to
  1462.                    communicate securely. 
  1463.    Source:         The node that created a packet.
  1464.    Source-Route:   A Level-2 route that is chosen for a packet by its 
  1465.                    source.
  1466.    Symbol:         Data preceding the EEP header of a PktWay message,
  1467.                    interleaving with the L2RHs.
  1468.  
  1469.  
  1470.  
  1471. Cohen et al                                                    [Page 26]
  1472.  
  1473. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1474.  
  1475.    Twin-HR:        Two HRs are twins if they both are parts of the same
  1476.                    inter-SAN router.
  1477.    Wormhole-routing: (aka cut-thru routing) forwarding packets out of
  1478.                    switches as soon as possible, without storing that
  1479.                    entire packet in the switch (unlike Stop-and-forward)
  1480.    Zero-copy TCP:  A TCP system that copies data directly between the
  1481.                    user area and the network device, bypassing OS copies
  1482.  
  1483.  
  1484. 13. Appendix-C: Acronyms and Abbreviations
  1485.  
  1486.    0bNNNN  The binary number NNNN (e.g., 0b0100 is 4-decimal)
  1487.    0xNNNN  The hexadecimal number NNNN (e.g., 0x0100 is 256-decimal)
  1488.    8B      8 byte (64 bits) entity
  1489.    ADDR    The Address-record of RRP
  1490.    APIn    Application/Program Interface
  1491.    AT      Address Type
  1492.    ATM     Asynchronous Transmission Mode
  1493.    B       Byte (e.g., 4B)
  1494.    b       bit (e.g., 32b)
  1495.    BC      Byte Count (of parameters)
  1496.    BER     Bit Error Rate
  1497.    CAPA    The CAPAbility-record of RRP
  1498.    CC      Capability Code
  1499.    CSR     Common Source-Route
  1500.    DA      Destination Address
  1501.    DB      Data Block
  1502.    DL      Data Length (in 8B words)
  1503.    DSP     Digital Signal Processor
  1504.    DT      Destination-Type
  1505.    E       The Endianness field (in the EEP header)
  1506.    e       The MSbit of E
  1507.    EEP     End/End Protocol
  1508.    EI      Error Indication
  1509.    GP      General Purpose
  1510.    GVL2    An RRP message, requesting L2 route to a given destination
  1511.    GVRT    An RRP message asking an HR to give its routing tables
  1512.    h       Optional header fields flag
  1513.    HR      Half Router
  1514.    HRTO    An RRP message asking which HR to use for a given destination
  1515.    ID      Identification
  1516.    IGMP    Internet Group Management Protocol
  1517.    INFO    An RRP message providing information about nodes
  1518.    IP      The Internet protocol
  1519.    ISORM   The ISO Reference Model
  1520.    L       Length field (exclusive of itself)
  1521.    L2      Level-2 of the ISORM (Link)
  1522.    L2RH    Level-2 Routing Header 
  1523.    L2SR    Source Route
  1524.    L3      Level-3 of the ISORM (Network)
  1525.    LA      Logical Address
  1526.    LADR    The Logical-addresses-record of RRP
  1527.  
  1528. Cohen et al                                                    [Page 27]
  1529.  
  1530. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1531.  
  1532.    LAN     Local Area Network
  1533.    LRT     Local Routing Table
  1534.    LSbit   Least Significant bit
  1535.    LSbyte  Least Significant byte
  1536.    MAC     Message Authentication Code / Media Access Control
  1537.    MPI     Message Passing Interface
  1538.    MPP     Massively Parallel Processing system
  1539.    MSbit   Most Significant bit
  1540.    MSbyte  Most Significant byte
  1541.    MSU     Mississippi State University
  1542.    MTU     Maximum Transmission Unit
  1543.    MTUR    The MTU-record of RRP
  1544.    M/C     Multicast
  1545.    NAME    The name-record of RRP
  1546.    NFS     Network File Server
  1547.    OH      Optional Header field
  1548.    OH-TYPE The Type of an Optional Header field
  1549.    OT      Optional Trailer field
  1550.    P       The Priority field
  1551.    PAD     Padding After Data
  1552.    PBD     Padding Before Data
  1553.    PCI     The Peripheral Component Interconnect "standard"
  1554.    PH      PacketWay Header 
  1555.    PL      Padding Length (always in bytes)
  1556.    PPP     The Point-to-Point Protocol
  1557.    PROM    Programmable ROM (Read-Only-Memory)
  1558.    PT      Packet Type (2B)
  1559.    PVM     Parallel Virtual Machine
  1560.    PW      The Myrinet Packet Type assigned to PktWay (PW=0x0300)
  1561.    Q       Quality (of a path)
  1562.    RCVF    Received-From list, or the Received-From record of RRP
  1563.    RDRC    A re-direct message of RRP
  1564.    RH      Routing Header 
  1565.    RID     Record ID
  1566.    RL      Record Length (in 8B-words)
  1567.    RRP     Router/Router Protocol
  1568.    RT-hd   RT (Routing Table) header
  1569.    RT      Routing Table
  1570.    RTBL    An RRP message proving a Routing Table
  1571.    RTHD    The Routing-Table-Header record of RRP
  1572.    RTyp    RRP's Record Type
  1573.    RZ      The Reserved field (in the EEP header)
  1574.    SA      Source Address
  1575.    SAN     System Area Network
  1576.    SAN-ID  The 24-bit PktWay-address of a SAN
  1577.    SAR     Segmentation and Reassembly
  1578.    SN      Serial Number
  1579.    SNID    SAN-ID
  1580.    SNMP    Simple Network Management Protocol
  1581.    SR      Source Route (always at Level-2)
  1582.    SRQR    The Source-Route-and-Q-record of RRP
  1583.    ST      Symbol Type
  1584.  
  1585. Cohen et al                                                    [Page 28]
  1586.  
  1587. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1588.  
  1589.    TAIL    PacketWay EEP Trailer
  1590.    TE      Type Extension (2B)
  1591.    TELL    RRP message requesting INFO about a partially specified node
  1592.    UNK     Unknown
  1593.    V       Version
  1594.    WRU?    An RRP message asking its recipient to identify itself
  1595.    XRT     External Routing Table
  1596.    xxxx    A padding byte
  1597.  
  1598.  
  1599. 14. Appendix-4: PktWay at a Glance (aka "The Cheat-Sheet")
  1600.  
  1601.  2   6    type       24                     16                16
  1602. +-+------+-------+--------+---------+--------+--------+--------+--------+
  1603. |V|  P   |     Destination-Type     |  Type-Extension |   Packet-Type   |
  1604. +-+-+---++--------------------------+-+------+--------+-----------------+
  1605. | E | PL|   Data-Length (8B-words)  |h|  RZ  |0     Source-Address      |
  1606. +---+---+--------+--------+---------+-+------+--------+--------+--------+
  1607.   4    3             25              1   7    1           23
  1608.  
  1609.                 type = 0xxx Physical Address
  1610.                        10xx L2RH
  1611.                        110x Reserved
  1612.                        1110 Logical Address
  1613.                        1111 Symbols
  1614. L2RH:
  1615.   2   6    2   6      8        8        8        8        8        8
  1616. +--------+--------+--------+--------+--------+--------+--------+--------+
  1617. |V|  P   |10LLLLLL|  SR01  |  SR02  |........|........|........|........|
  1618. +--------+--------+--------+--------+--------+--------+--------+--------+
  1619.             Length
  1620. Symbol:
  1621.   2   6     4   6     8        8        8        8        8        8
  1622. +--------+--------+--------+--------+--------+--------+--------+--------+
  1623. |V|  P   |1111ssss|ssssssss|ssssssss| Length |  data  |........|........|
  1624. +--------+--------+--------+--------+--------+--------+--------+--------+
  1625.               <---- Symbol Type --->
  1626. Optional Header:
  1627.   2   6      8        8        8        8        8        8        8
  1628. +--------+--------+--------+--------+--------+--------+--------+--------+
  1629. |TCtttttt|LLLLLLLL|  data  |........|........|........|........|........|
  1630. +--------+--------+--------+--------+--------+--------+--------+--------+
  1631. T: 0=optional, 1=mandatory;  C: 0=more OH-fields follow, 1=last OH-field
  1632.  
  1633. RRP Record:
  1634.     8        8        8        8        8        8        8        8
  1635. +--------+--------+--------+--------+--------+--------+--------+--------+
  1636. |  RTyp  |   PL   |       RL        |........|........|........|........|
  1637. +--------+--------+--------+--------+--------+--------+--------+--------+
  1638. RRP-messages: GVL2, L2SR, RDRC, TELL, INFO, HRTO, WRU?, GVRT, RTBL;
  1639.         RTyp: ADDR, NAME, CAPA, LADR, SRQR, MTUR, RCVF, RTHD;
  1640.  
  1641. Cohen et al                                                    [Page 29]
  1642.  
  1643. Internet-Draft      PktWay Router-to-Router Protocol        October 1997
  1644.  
  1645.  
  1646. 15. Security Considerations
  1647.  
  1648.    This RFC raises no security issues.  PktWay is designed to work
  1649.    in clusters to which the access may be as controlled as needed.
  1650.  
  1651.    PktWay has a security applique for securing the comminucation between
  1652.    classified/sensitive clusters, even when non-secure clusters and
  1653.    non-secure communication facilities have to be used.  This applique
  1654.    uses cryptographic methods and equipment.  More about that applique
  1655.    may be found in "Proposed Specification for Security Extensions to
  1656.    the PacketWay Protocol"
  1657.    {http://WWW.ERC.MsState.Edu/labs/hpcl/packetway/secure.txt}.
  1658.  
  1659.    At the presence of security threats such applique should be used
  1660.  
  1661.  
  1662.  
  1663.  
  1664.  
  1665. 16. Editor's Address
  1666.  
  1667.    Danny Cohen
  1668.    Myricom, Inc.
  1669.    325 N. Santa Anita Ave
  1670.    Arcadia, CA 91006
  1671.  
  1672.    Phone: 626-821-5555
  1673.    Fax:   626-821-5316
  1674.    Email: Cohen@myri.com
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682.  
  1683.  
  1684.  
  1685.  
  1686.  
  1687.  
  1688.  
  1689.  
  1690.  
  1691.  
  1692.  
  1693.  
  1694.  
  1695.  
  1696.  
  1697. Cohen et al                                                    [Page 30]
  1698.  
  1699.  
  1700.