rfc1634.txt

RFC 的详细文档！

   disconnected.







































Allen                                                          [Page 18]

RFC 1634                         IPXWAN                         May 1994


4.4 Information Response Packet

    +---------------------------------------------------------------+
    | Checksum         | FF FF             | Always FFFF            |
    | Packet Length    | 00 63             | Size of header+data    |
    |                  |                   | (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     | 03                | Information Response   |
    | WNode ID         | xx xx xx xx       | Primary Net # of       |
    |                  |                   | sending router         |
    |                  |                   | (Hi Lo order)          |
    | WSequence #      | 00                | Same as Info Request   |
    | WNum Options     | 01                | 1 Option to follow     |
    | WOption Number   | 01                | Define IPX RIP/SAP     |
    |                  |                   | info exchange          |
    | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
    | WOption Data Len | 00 36             | Option length (Hi Lo)  |
    | WOption Data     |                   |                        |
    |  Link Delay      | xx xx             | Hi Lo link delay (as   |
    |                  |                   | received in Info Requ) |
    |  Common Net #    | xx xx xx xx       | Hi Lo Common Network # |
    |                  |                   | (as received in Info   |
    |                  |                   | request)               |
    |  Router Name     | xx (x 48 decimal) | Router name - as defned|
    |                  |                   | in section 2.          |
    +---------------------------------------------------------------+

   The responses contained within this packet are as described in
   section 4.3.

   A link slave will additionally respond with the received  NIC address
   option as a confirmation of receipt. A workstation should replace the
   Router Name with the configured name, or a constant descriptor string
   as described in section 2. If the Information Request contained an
   inappropriate Common Net # or NIC address, the Information Response
   may set new values. The receiver of the Information Response is
   responsible for checking on the value and terminating the connection
   if the new values cannot be used.




Allen                                                          [Page 19]

RFC 1634                         IPXWAN                         May 1994


   Routers MUST set the WNodeID to their correct value when sending an
   Information Response. A value of zero must NOT be used.

5. Running Unnumbered RIP

   Unnumbered RIP refers to the case where two WAN routers are
   communicating using the RIP protocol across a link with NO physical
   IPX network address. The premise for this ability is that there is no
   need to address a packet to anything on that WAN link. RIP and SAP
   run in exactly the same way as before, except the source and
   destination network numbers should be set to zero.

   The advantage to running unnumbered RIP links is that it is not
   necessary to allocate/configure a pool of usable IPX network numbers
   which can be used on the WAN links. The other advantage is that when
   there is a large number of WAN links, it is not necessary to flood
   the network with an unnecessary set of extra RIP information.

6. Workstation Connectivity

   Workstations MUST reside on a network and have a unique NIC address
   on that network to be individually addressable. However, workstations
   do not need to periodically receive RIP and SAP broadcasts as they
   play no part in the routing process. This allows routers to reduce
   background traffic on the workstation link by not sending any
   periodic RIP and SAP data. Note that it will not cause a problem if
   the RIP and SAP is sent. It will just slow down the workstation
   access times.

   RIP and SAP information should ONLY be sent if the workstation makes
   a specific request for information - like a service or route request.

   It should also be noted that if multiple workstations are attached to
   a single WAN workstation network (per router), broadcasts on that
   network - whether originated from a workstation or the router - MUST
   reach ALL other workstations. This will involve the router
   duplicating the packet to all WAN workstation connections.

7. On-demand, Statically Routed Links

   On-demand, Static Routing serves two purposes. The "on-demand" part
   means that a router initiates communication to a destination only
   when there is data to be forwarded to that destination. "Inititating
   comunication" includes making a datalink call (where necessary) and
   performing the IPXWAN exchange. A transient connection is closed
   after a period of inactivity.





Allen                                                          [Page 20]

RFC 1634                         IPXWAN                         May 1994


   The "static routing" part means that no routing information is sent
   over the link - no RIP, no SAP, and no NLSP. Instead, the router at
   each end is configured with the routes and services accessible
   through the link.

   With on-demand, static routing, the called router must be able to
   identify the calling router so that statically configured routes and
   services can be attached to that connection. For example, with X.25
   switched virtual circuits, the calling DTE address can be used; with
   PPP, the PPP authentication can be used; after IPXWAN has completed,
   the "Router Name" can be used; with a persistent datalink connection,
   the physical port identifier or a permanent virtual circuit
   identifier can be used. The choice of identifier is an implementation
   decision. Whatever value the called router uses is called a Remote
   System Identifier, or RSI. For PPP links, Novell uses PPP PAP or CHAP
   authentication to determine the caller.

   A router implementing on-demand, static routing must maintain a
   database of RSIs, and lists describing the network numbers and
   services reachable through each RSI. These lists determine the
   reachability information it transmits to other routers in a routing
   area. Other routers treat each on-demand, static routing link as
   though it were permanently available.

   The on-demand exchange has a slight variation on the IPXWAN protocol.
   The differences are as follows.

   In the Timer Request, the calling router offers only the "On-demand,
   static routing" Routing Type. If the called router is capable of On-
   demand static routing, it offers "On-demand, static routing" in the
   Timer Request, along with any additional routing types it is willing
   to support on the link. The Master/Slave election and choice of
   routing type proceeds as described previously. If the Slave detects a
   mismatch in routing types, it disconnects the link.

   For a persistent datalink (like X.25 PVCs), there may be no
   descerable "link establishemnt" event. For such media, arrival of a
   Timer Request plays the role of detecting link establishment.

   As with Unnumbered RIP, there is no network number assigned to the
   link. NLSP Packets are not sent on the link. Moreover, periodic RIP
   and SAP packets are not sent on the link. However, a router must
   respond to RIP and SAP queries received on the link.








Allen                                                          [Page 21]

RFC 1634                         IPXWAN                         May 1994


8. References

   [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP) for the
       Transmission of Multi-protocol Datagrams over Point-to-Point
       Links", RFC 1548, Daydreamer, December 1993.

   [2] Malis, A., Robinson, D., and R. Ullman, "Multiprotocol
       Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
       August 1992.

   [3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect
       over Frame Relay", RFC 1490, Wellfleet Communications, Inc.,
       Ascom Timeplex, Inc., July 1993.

   [4] Simpson, W., "The PPP Internetwork Packet Exchange Control
       Protocol (IPXCP)", RFC 1552, Daydreamer, December 1993.

   [5] Novell IPX Router Specification.  Novell Part Number 107-000029-
       001. This document may be retrieved via Anonymous FTP to SJF-LWP
       (130.57.11.140) under /sys/ftpguest/dev_docs/ipx_rtr/ipxrtr.zip

   [6] Mathur, S., and M. Lewis, "Compressing IPX Headers Over WAN Media
       (CIPX)", RFC 1553, Telebit Corporation, December 1993.

   [7] ANSI, "Integrated Services Digital Network (ISDN) - Digital
       Subscriber Signalling System Number 1 (DSS1) - Signalling
       Specification for Frame Relay", ANSI T1.617-1991, June 1991.

   [8] Novell NetWare Link Services Protocol (NLSP) Specification.
       Novell part number 100-001708-002. This document may be retrieved
       via Anonymous FTP to SJF-LWP (130.57.11.140) under
       /sys/ftpguest/dev_docs/ipx_rtr/nlsp.zip.

9. Security Considerations

   Security issues are not discussed in this memo.















Allen                                                          [Page 22]

RFC 1634                         IPXWAN                         May 1994


10. Author's Address

   Michael Allen
   Novell, Inc.
   2180 Fortune Drive
   San Jose, CA 95131

   EMail: [e-mail]

   The working group can be contacted via the current chair:

   Fred Baker
   Advanced Computer Communications
   315 Bollay Drive
   Santa Barbara, California, 93111

   EMail: [e-mail]


































Allen                                                          [Page 23]