rfc1551.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   to the link, it sets the Timer Request WNodeID field to zero, and
   includes its primary network number in an Extended Node ID option.

   Workstations follow a similar, but slightly different set of rules
   for setting the WNodeID field. If this is the first time the work-
   station is connecting to the router, the workstation will set the
   WNodeID to zero indicating the router should be the link master and
   allocate a network number for the new link. In this case, the work-
   station will respond to the router's Timer Request and acknowledge
   only the Workstation Routing Type option. Note that a workstation
   does NOT include an Extended Node ID option in  it's timer request.

   If the workstation is reconnecting a link after an earlier inactivity
   disconnect, it is necessary for the workstation to be able to specify
   its network, NIC address and "Router Name" field (so that file server
   connections can be maintained after the reconnect).  In this case,
   the workstation will set its WNodeID field to FFFFFFFFh forcing
   itself to be the link master. In this case, the router will respond
   to the workstation's Timer Request with only the Workstation Router
   Type acknowledged.

   Further packets in the IPXWAN exchange MUST use the correct WNodeID
   (workstations will always use zero).





Allen                                                           [Page 6]

RFC 1551                         IPXWAN                    December 1993


   On receiving a Timer Request packet, a router determines its role -
   master or slave - for the remainder of the IPXWAN exchanges. The
   master role does not denote special privileges, it merely means that
   the router is the requestor in the ensuing request/response
   exchanges. The descision is made as follows:

      a) If there is an Extended Node ID present (and we understand
         the option), this must be compared to our Primary Network
         Number. If we have the lower Primary Network Number, we
         MUST respond with a Timer Response and become the slave.

      b) If there is NO Extended Node ID, we must compare the WNodeID
         of the received Timer Request with our Primary Network Number
         and respond if we have a lower number.

      Note: The Primary Network Number for a workstation when
      determining master/slave roles depends on whether the
      workstation requires itself to be the master of slave. It
      should compare the received WNodeID to that sent in it's own
      Timer Request.

   The numeric comparisons are done by considering each byte of the
   WNodeID or Extended Node ID fields as an unsigned integer, and the
   first byte as most significant.

   The link slave responds to the Timer Request with a Timer Response.
   To do so, each option in the received Timer Request is parsed. If an
   option is not supported (or recognized), that option is rejected by
   changing the WAccept field to "NO" for that option.

   When selecting the router type which will be used on the link, the
   first option in the Timer Request which can be supported should be
   accepted. All other router types should have the WAccept field set to
   "NO". A router MUST NOT accept workstation connectivity to a node
   which is another router.

   Note: It is permitted for a router to support a numbered routing
   type, but not be able to assign the network number. In this case,
   that routing type can be selected only if the other router supports
   it and is able to assign the network number. This can be determined
   by the value of the received WNodeID field. If the router is unable
   to assign a network number to the link, it MUST support Unnumbered
   RIP and include this option in the Timer Requests.

   If a router wishes to provide WAN Client access without supporting
   other WAN routing types, a potential problem arises since a router
   and WAN client would both just be sending a single Routing Type
   option indicating the use of WAN Client. The IPXWAN specification



Allen                                                           [Page 7]

RFC 1551                         IPXWAN                    December 1993


   does not allow a WAN workstation to connect to another WAN
   workstation. The method for detecting this is that the sent and
   received Timer Requests have a single Routing Type defined of WAN
   Client. To overcome this problem, IPXWAN defines that a router MUST
   NOT send a single Routing Type if that type is just WAN Client. The
   router MUST additionally include one (or more) of the defined routing
   types (like WAN RIP) with the WAccept option set to NO. This is so
   that a workstation may detect that this is actually a router sending
   the Timer Request and not just another workstation trying to call a
   workstation. The extra option will serve to be a counted Routing Type
   that will be ignored. If a workstation detects it is connecting to
   another workstation, it should disconnect the link.

   Note that a router supporting a workstation will need to be able to
   supply AT LEAST one network number for workstations. All dial-in
   workstations could share the same network, and be assigned unique
   node numbers by the router, or each workstation could be assigned a
   different network number. This is a router specific implementation
   detail. Use of a single network for all clients is prefered, however,
   this does involve extra work by the router when dealing with
   broadcast frames. When the router is the link master and allocating
   NIC addresses on a single network,it should ALWAYS use a unique value
   - by incrementing the NIC address for each client connection. This
   allows a workstation which is reconnecting the ability to specify his
   old network and NIC address. It is unlikely with a 6 byte NIC
   address, that there will be wrap-around in the numbers that would
   cause a problem. Router Node Number allocation should follow a few
   simple rules. The six byte NIC address SHOULD have the first byte set
   to 2.

         Byte # +--1----2----3----4----5----6-+
                | 02 | XX | XX | XX | XX | XX |
                +-----------------------------+

   In an IEEE address space, this would represent a non-multicast,
   locally defined address. Node numbers of zero or -1 are not allowed.

   If a slave determines it cannot support any of the supplied routing
   protocols in the received Timer Request, it MUST issue a disconnect
   on the connection being established. The master of the link
   (determined when a Timer Response packet is received) is responsible
   for defining the network number that is to be used as a common
   network number for the new WAN link, and for calculating the RIP
   transport time that will be advertized to other RIP routers for the
   new link. This is calculated by stopping the timer which was started
   when a Timer Request was initiated and applying the algorithm in
   section 4.3.




Allen                                                           [Page 8]

RFC 1551                         IPXWAN                    December 1993


3.2 Information Exchange

   After exchanging Timer Request packets, the link master and slave
   have been determined, and the Routing Protocol to be used on the link
   is negotiated. The link master is now responsible for sending an
   Information Request packet to the slave specifying the network number
   to be used on the new link (zero for unnumbered RIP and On Demand),
   the calculated transport time to be used in the routing metric, the
   Router Name (for management purposes), and for a workstation
   connection, the NIC address the workstation will be adopting. The NIC
   address option is a separate option added in the Information
   Request/Response for workstation connectivity. It is NOT present for
   router to router connections.

   If a router receives an inappropriate Information Request from a
   workstation trying to set the common network number and NIC address
   the router MUST overwrite these values with preferred values. When
   the workstation receives the Information Response, it MUST note the
   new values. If the workstation is unable to adjust to the new values,
   it MUST issue a disconnect on the link. If a workstation is the link
   master (i.e., it is reconnecting), the router is additionally
   responsible for ensuring the "Router Name" field matches that of the
   original connection. If the values differ, the call should be
   disconnected.

   If a router detects an error for which no suitable protocol response
   exists (e.g., unable to allocate a network number), the link should
   be terminated according to the relevant media specification.

   Under certain circumstances, particularly on X.25 permanent circuits,
   it is only possible to detect the remote router went away when it
   comes back up again.  In this case, one side of the link receives a
   Timer Request packet when IPX is in a fully connected state.  The
   side receiving the Timer Request MUST realize that a problem
   occurred, and revert to the IPX link establishment phase.
   Furthermore, the routing information learned from this connection
   should be immediately discarded.

   When Unnumbered RIP, On-demand or Workstation options are negotiated,
   Information Request packets are repeated every 20 seconds until a
   response is received. For the Numbered RIP links, the Information
   Request is NOT resent. Instead, the link is disconnected after a
   suitable delay (min. 60 seconds) - this requirement ensures
   interoperabilty with earlier versions of IPXWAN.  When Information
   Requests are repeated, they should continue for a preconfigured time
   (min. 60 seconds) or a preconfigured number of retries (e.g., 16).
   Each retry uses an incremented sequence number.




Allen                                                           [Page 9]

RFC 1551                         IPXWAN                    December 1993


3.3 NAK Packets

   The IPXWAN protocol uses a NAK packet to indicate the received IPXWAN
   packet was not acceptable. A NAK packet is an exact copy of the
   received packet with the WPacketType field set to NAK. There are two
   anticipated uses of this packet.

      - The received WPacketType is invalid or not recognized;

      - A badly formed IPXWAN packet is received.

   Returning a NAK packet allows the sender a chance to work out what
   was wrong. If the sender was unable to determine the problem, the
   call can then be disconnected.

   The value of the NAK WPacketType is FFh.

4. Information Exchange Packet Formats

   All IPX WAN protocol exchanges utilize the standard Novell IPX packet
   format. The packets use the IPX defined packet type 04 defining a
   Packet Exchange Packet. The socket number 0x9004 is a Novell reserved
   socket number for exclusive use with IPX WAN protocol exchange. IPX
   defines that a network number of zero (0) is interpreted as being a
   local network of unknown number that requires no routing. This
   feature is of use to us in transferring these packets before the
   common network number is exchanged. Some routers need to know a "Node
   Number" (or MAC address) for each node on a link. Node numbers will
   be formed from the "WNode ID" field.  The node number will be the 4
   bytes of WNode ID followed by 2 bytes of zero. For a workstation, the
   node number will be explicitly assigned by the router and notified to
   the workstation in the Information Request packet.

   Router Type number assignment. Other vendors IPX routing protocols
   can make use of the IPXWAN protocol definition by obtaining Router
   Types from Novell. This document will then include the new Router
   Types (with the references to vendor protocol description documents).
   Current Routing Types are:

      00      Numbered RIP/SAP
      01      NLSP (no RIP/SAP - defined in [8])
      02      Unnumbered RIP/SAP
      03      On Demand, static routing (no RIP/SAP or NLSP)
      04      Workstation (no RIP/SAP)
      05-FF   Currently undefined

   WOption Number assignment. These numbers only need to be assigned
   from Novell for the "Timer Request" and "Timer Response" packets.



Allen                                                          [Page 10]

RFC 1551                         IPXWAN                    December 1993


   Packet Types also need to be assigned by Novell. However, the options
   within these packets are dependant on the "Router Type" negotiated.
   WOption numbers in these packets are then defined by the vendor
   defining the Routing Type. The same packet format should still be
   maintained.

   Router Type 01 will not be described in this document since it
   involves knowledge of the NLSP protocol to implement. Please refer to
   [8] for a complete specification of these NLSP IPXWAN exchanges and
   the NLSP protocol.

4.1 Timer Request Packet

    +---------------------------------------------------------------+
    | Checksum         | FF FF             | Always FFFF            |
    | Packet Length    | 02 40             | Max IPX size (576 bytes|
    |                  |                   | Hi Lo order)           |
    | Trans Control    | 00                | Hops traversed         |
    | Packet Type      | 04                | Packet Exchange Packet |
    | Dest Net #       | 00 00 00 00       | Local Network          |
    | Dest Node #      | FF FF FF FF FF FF | Broadcast              |
    | Dest Socket #    | 90 04             | Reserved WAN socket    |
    | Source Net #     | 00 00 00 00       | Local Network          |
    | Source Node #    | 00 00 00 00 00 00 | Set to zero            |
    | Source Socket #  | 90 04             | Reserved WAN socket    |
    |------------------+-------------------+------------------------|
    | WIdentifier      | 57 41 53 4D       | Confidence identifier  |
    | WPacket Type     | 00                | Timer Request          |
    | WNode ID         | xx xx xx xx       | Primary Net # of       |
    |                  |                   | sending router         |
    |                  |                   | (Hi Lo order)          |
    | WSequence #      | xx                | Sequence start at 0    |
    | WNum Options     | xx                | Number of options      |
    |------------------+-------------------+------------------------|
    | WOption Number   | xx                | Option Identifier      |
    | WAccept Option   | xx                | 0=No,1=Yes,3=Not Applic|
    | WOption Data Len | xx xx             | Number of following    |
    |                  |                   | option bytes (Hi Lo)   |
    | WOption Data     | nn                | Option specific data   |
    +---------------------------------------------------------------+

Routing Type Option:
    One or more of the following router type options should be included
    in a Timer Request packet. A router should ALWAYS include Routing
    Type zero (0) if full interoperability is required with an older
    implementation. The router types MUST be included in the senders
    order of preference. If a router receives a Timer Response with more
    than one Router Type having WAccept set to Yes, the link MUST be



Allen                                                          [Page 11]