rfc1634.txt

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

Network Working Group                                           M. Allen
Request For Comments: 1634                                  Novell, Inc.
Obsoletes: 1551, 1362                                           May 1994
Category: Informational

               Novell IPX Over Various WAN Media (IPXWAN)

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document describes how Novell IPX operates over various WAN
   media.  Specifically, it describes the common "IPX WAN" protocol
   Novell uses to exchange necessary router to router information prior
   to exchanging standard IPX routing information and traffic over WAN
   datalinks. This document supercedes RFC 1362 and RFC 1551. The
   changes from RFC 1551 are to correct a problem in the wording when an
   RFC 1362 router talks to an RFC 1551 router and to allow numbers to
   be specified in a Router Name.

Table of Contents

   1.  Introduction ................................................. 2
   1.1 Operation Over PPP ........................................... 2
   1.2 Operation Over X.25 Switched Virtual Circuits ................ 2
   1.3 Operation Over X.25 Permanent Virtual Circuits ............... 3
   1.4 Operation Over Frame Relay ................................... 3
   1.5 Operation Over Other WAN Media ............................... 3
   2.  Glossary Of Terms ............................................ 4
   3.  IPX WAN Protocol Description ................................. 4
   3.1 The Initial Negotiation ...................................... 5
   3.2 Information Exchange ......................................... 9
   3.3 NAK Packets .................................................. 10
   4.  Information Exchange Packet Formats .......................... 10
   4.1 Timer Request Packet ......................................... 12
   4.2 Timer Response Packet ........................................ 15
   4.3 Information Request Packet ................................... 16
   4.4 Information Response Packet .................................. 19
   5.  Running Unnumbered RIP ....................................... 20
   6.  Workstation Connectivity ..................................... 20
   7.  On-demand, Statically Routed Links ........................... 20
   8.  References ................................................... 22
   9.  Security Considerations ...................................... 22
   10. Author's Address.............................................. 23



Allen                                                           [Page 1]

RFC 1634                         IPXWAN                         May 1994


1. Introduction

   This document describes how Novell IPX operates over various WAN
   media. It is strongly motivated by a desire for IPX to treat ALL wide
   area links in the same manner. Sections 3 and 4 describe this common
   "IPX WAN" protocol.

   The IPX WAN protocol operation begins immediately after link
   establishment. While IPX is a connectionless datagram protocol, WANs
   are often connection-oriented.  Different WANs have different methods
   of link establishment. The subsections of section 1 of this document
   describe what link establishment means to IPX for different media.
   They also describe other WAN-media-dependent aspects of IPX
   operation, such as protocol identification, frame encapsulation, and
   link tear down.

1.1 Operation Over PPP

   IPX uses PPP [1] when operating over point-to-point synchronous and
   asynchronous networks.

   With PPP, link establishment means the IPX NCP [4] reaches the Open
   state. NetWare IPX will negotiate down to a null set of NCP options,
   and uses normal frame encapsulation as defined by PPP. The IPXWAN
   protocol MUST NOT occur until the IPX NCP reaches the Open state.
   Options negotiated by the IPXWAN protocol MUST supercede any options
   negotiated by the IPXCP.

   PPP allows either side of a connection to stop forwarding IPX if one
   end sends an IPXCP or an LCP Terminate-Request. When a router detects
   this, it will immediately reflect the lost connectivity in its
   routing information database instead of naturally aging it out.

1.2 Operation over X.25 Switched Virtual Circuits

   With X.25, link establishment means successfully opening an X.25
   virtual circuit.  As specified in RFC-1356, "Multiprotocol
   Interconnect on X.25 and ISDN in the Packet Mode" [2], the protocol
   identifier 0x800000008137 is used in the X.25 Call User Data field of
   the Call Request frame, and indicates that the virtual circuit will
   be devoted to IPX.

   Furthermore, each IPX packet is encapsulated directly in X.25 data
   frame sequences without additional framing.

   Either side of the virtual circuit may close it, thereby tearing down
   the IPX link. When a router detects this, it will immediately reflect
   the lost connectivity in its routing information database instead of



Allen                                                           [Page 2]

RFC 1634                         IPXWAN                         May 1994


   naturally aging it out.

1.3 Operation over X.25 Permanent Virtual Circuits

   The nature of X.25 PVC's is that no call request is made.  When the
   router is informed that X.25 Layer 2 is up, the router should assume
   that link establishment is complete.

   Each IPX packet is encapsulated in an X.25 data frame sequence
   without additional framing. Novell IPX assumes a particular X.25
   permanent circuit is devoted to the use of IPX.

   If a router receives a layer 2 error condition (e.g., X.25 Restart),
   it should reflect lost connectivity for the permanent circuits in its
   routing information database and re-perform the necessary steps to
   obtain a full IPX connection.

1.4 Operation over Frame Relay Permanent Virtual Circuits

   To determine when a permanent virtual circuit (PVC) has become active
   or inactive, the router interacts periodically with either a private
   Frame Relay switch or a public Frame Relay network. The method used
   depends on the switch or service provider. Some support [7], section
   6l others support [3], Annex D. Novell supports both methods.

   When a router is restarted, IPXWAN exchanges over active Frame Relay
   PVCs (that is, PVCs that have remained active before and after
   restart) can begin immediately.

   Each IPX packet is encapsulated in a Frame Relay frame sequence as
   defined in [3] without additional framing.

   When a router detects that a Frame Relay PVC has transitioned from an
   inactive to an active state, link establishment is considered
   complete and IPXWAN exchange over this newly activated link begins.

   When an active PVC becomes inactive, the router reflects the lost
   connectivity in its routing information database.

1.5 Operation over other WAN media

   Additional WAN media will be added here as specifications are
   developed.








Allen                                                           [Page 3]

RFC 1634                         IPXWAN                         May 1994


2. Glossary Of Terms

   Primary Network Number:

      Every IPX WAN router has a "primary network number". This is an
      IPX network number unique to the entire internet.  This number
      will be a permanently assigned network number for the router.
      Those readers familiar with NetWare 3.x servers should realize
      that this is the "Internal" network number.

   Router Name:

      Every IPX WAN router must have a "Router Name". This is a symbolic
      name given to the router. Its purpose is to allow routers to know
      who they are connected to after link establishment - particularly
      for network management purposes.  A symbolic name conveys more
      information to an operator than a set of numbers. The symbolic
      name should be between 1 and 47 characters in length containing
      the characters 'A' through 'Z', '0' through '9', underscore (_),
      hyphen (-) and "at" sign (@). The string of characters should be
      followed by a null character (byte of zero) and padded to 48
      characters using the null character.  Those readers familiar with
      NetWare 3.x servers should realize that the file server name is
      the Router Name.

      For workstation (client) connectivity, it is useful if the client
      connection software is configured with a symbolic name reflecting
      the name of the client. This allows a router management utility to
      determine which connection connects with which client/router.  If
      no name is configured, it is recommended that a default string
      such as "DIAL-IN-CLIENT" is used.

3. IPX WAN Protocol Description

   After the underlying data link connection is established as described
   in the preceding media dependant description, the IPXWAN protocol is
   activated to exchange identities and determine certain operational
   charactaristics of the link.

   There are two steps in the IPXWAN operation:

      - Negotiating master/slave role and choice of routing protocol.
        The master/slave roles persist for the IPXWAN exchanges only;

      - Information exchange of final router configuration.

   After these steps are concluded, transmission of IPX routing packets
   begins - using the routing protocol negotiated - as well as



Allen                                                           [Page 4]

RFC 1634                         IPXWAN                         May 1994


   transmission of IPX data traffic.

3.1 The Initial Negotiation

   The first exchange of packets decides the master/slave roles and the
   routing protocol to be used on the link and gauges the link delay for
   the routing metrics. The initial negotiation is the same for all
   protocols.

        +---------------+                 +---------------+
        | Timer Request |                 | Timer Request |
        +---------------+                 +---------------+
                         \---->\   /<----/
                                \ /
                                 x
                                / \
                   /\    /<----/   \---->\    /\
                 /    \                     /    \
               /        \                 /        \
             / My primary \             / My primary \
           / network address\         / network address\
           \    is larger   /         \   is smaller   /
             \            /             \            /
               \        /                 \        /
                 \    /                     \    /
                   \/                         \/
                 MASTER                      SLAVE

                                          +----------------+
                         <----------------+ Timer Response +
                                          +----------------+

   After link establishment, both sides of the link send Timer Request
   packets and start a timer waiting for a Timer Response. These Timer
   Requests are sent every 20 seconds until a response is received or a
   descision is made that the remote node is not responding. This could
   be after a predefined time (min. 60 seconds) or a number of retries
   (e.g., 16).

   In composing the Timer Request, the router or workstation takes into
   consideration:

      - Which types of routing protocols it supports;

      - Whether it is prepared to assign a network address to the link;

      - For workstations, whether they require the ability to specify
        their network/NIC address on a reconnect;



Allen                                                           [Page 5]

RFC 1634                         IPXWAN                         May 1994


      - Whether it is able to support IPX header compression [6].

   For each routing protocol supported, place an option in the Timer
   Request packet. The Routing Type options should be added in the
   originator's order of preference with the most preferred option
   first.

   Some of the newer (or modified) IPX routing protocols do not have the
   requirement to allocate a network number on a WAN link. This type of
   routing protocol has the advantage of potentially simpler
   configuration as no network number pools are necessary for WAN links.
   However, these router implementations may still wish to interoperate
   with the older IPXWAN implementations which are able to allocate
   network numbers for the WAN link. In this case, the following method
   is used to force the older implementation to become the link master.
   It should be noted that a router implementation capable of supporting
   workstation dial-in MUST be able to supply AT LEAST ONE network
   number on which the workstation can reside.

   If the router is prepared to assign an IPX network number to the
   link, it sends its primary network number in the Timer Request
   WNodeID field, and omits the Extended Node ID option. On the other
   hand, if the router is NOT prepared to assign an IPX network number
   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