As per Relevance of the word exchange, we have this rfc below:
Network Working Group M.
Request For Comments: 1634 Novell, Inc
Obsoletes: 1551, 1362 May 1994
Category:
Novell IPX Over Various WAN Media (IPXWAN
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document describes how Novell IPX operates over various
media. Specifically, it describes the common "IPX WAN"
Novell uses to exchange necessary router to router information
to exchanging standard IPX routing information and traffic over
datalinks. This document supercedes RFC 1362 and RFC 1551.
changes from RFC 1551 are to correct a problem in the wording when
RFC 1362 router talks to an RFC 1551 router and to allow numbers
be specified in a Router Name
Table of
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.
This document describes how Novell IPX operates over various
media. It is strongly motivated by a desire for IPX to treat ALL
area links in the same manner. Sections 3 and 4 describe this
"IPX WAN" protocol
The IPX WAN protocol operation begins immediately after
establishment. While IPX is a connectionless datagram protocol,
are often connection-oriented. Different WANs have different
of link establishment. The subsections of section 1 of this
describe what link establishment means to IPX for different media
They also describe other WAN-media-dependent aspects of
operation, such as protocol identification, frame encapsulation,
link tear down
1.1 Operation Over
IPX uses PPP [1] when operating over point-to-point synchronous
asynchronous networks
With PPP, link establishment means the IPX NCP [4] reaches the
state. NetWare IPX will negotiate down to a null set of NCP options
and uses normal frame encapsulation as defined by PPP. The
protocol MUST NOT occur until the IPX NCP reaches the Open state
Options negotiated by the IPXWAN protocol MUST supercede any
negotiated by the IPXCP
PPP allows either side of a connection to stop forwarding IPX if
end sends an IPXCP or an LCP Terminate-Request. When a router
this, it will immediately reflect the lost connectivity in
routing information database instead of naturally aging it out
1.2 Operation over X.25 Switched Virtual
With X.25, link establishment means successfully opening an X.25
virtual circuit. As specified in RFC-1356, "
Interconnect on X.25 and ISDN in the Packet Mode" [2], the
identifier 0x800000008137 is used in the X.25 Call User Data field
the Call Request frame, and indicates that the virtual circuit
be devoted to IPX
Furthermore, each IPX packet is encapsulated directly in X.25
frame sequences without additional framing
Either side of the virtual circuit may close it, thereby tearing
the IPX link. When a router detects this, it will immediately
the lost connectivity in its routing information database instead
Allen [Page 2]
RFC 1634 IPXWAN May 1994
naturally aging it out
1.3 Operation over X.25 Permanent Virtual
The nature of X.25 PVC's is that no call request is made. When
router is informed that X.25 Layer 2 is up, the router should
that link establishment is complete
Each IPX packet is encapsulated in an X.25 data frame
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
routing information database and re-perform the necessary steps
obtain a full IPX connection
1.4 Operation over Frame Relay Permanent Virtual
To determine when a permanent virtual circuit (PVC) has become
or inactive, the router interacts periodically with either a
Frame Relay switch or a public Frame Relay network. The method
depends on the switch or service provider. Some support [7],
6l others support [3], Annex D. Novell supports both methods
When a router is restarted, IPXWAN exchanges over active Frame
PVCs (that is, PVCs that have remained active before and
restart) can begin immediately
Each IPX packet is encapsulated in a Frame Relay frame sequence
defined in [3] without additional framing
When a router detects that a Frame Relay PVC has transitioned from
inactive to an active state, link establishment is
complete and IPXWAN exchange over this newly activated link begins
When an active PVC becomes inactive, the router reflects the
connectivity in its routing information database
1.5 Operation over other WAN
Additional WAN media will be added here as specifications
developed
Allen [Page 3]
RFC 1634 IPXWAN May 1994
2. Glossary Of
Primary Network Number
Every IPX WAN router has a "primary network number". This is
IPX network number unique to the entire internet. This
will be a permanently assigned network number for the router
Those readers familiar with NetWare 3.x servers should
that this is the "Internal" network number
Router Name
Every IPX WAN router must have a "Router Name". This is a
name given to the router. Its purpose is to allow routers to
who they are connected to after link establishment -
for network management purposes. A symbolic name conveys
information to an operator than a set of numbers. The
name should be between 1 and 47 characters in length
the characters 'A' through 'Z', '0' through '9', underscore (_),
hyphen (-) and "at" sign (@). The string of characters should
followed by a null character (byte of zero) and padded to 48
characters using the null character. Those readers familiar
NetWare 3.x servers should realize that the file server name
the Router Name
For workstation (client) connectivity, it is useful if the
connection software is configured with a symbolic name
the name of the client. This allows a router management utility
determine which connection connects with which client/router.
no name is configured, it is recommended that a default
such as "DIAL-IN-CLIENT" is used
3. IPX WAN Protocol
After the underlying data link connection is established as
in the preceding media dependant description, the IPXWAN protocol
activated to exchange identities and determine certain
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
begins - using the routing protocol negotiated - as well
Allen [Page 4]
RFC 1634 IPXWAN May 1994
transmission of IPX data traffic
3.1 The Initial
The first exchange of packets decides the master/slave roles and
routing protocol to be used on the link and gauges the link delay
the routing metrics. The initial negotiation is the same for
protocols
+---------------+ +---------------+
| Timer Request | | Timer Request |
+---------------+ +---------------+
\---->\ /<----/
\ /
/ \
/\ /<----/ \---->\ /\
/ \ / \
/ \ / \
/ My primary \ / My primary \
/ network address\ / network address
\ is larger / \ is smaller /
\ / \ /
\ / \ /
\ / \ /
\/ \/
MASTER
+----------------+
<----------------+ Timer Response +
+----------------+
After link establishment, both sides of the link send Timer
packets and start a timer waiting for a Timer Response. These
Requests are sent every 20 seconds until a response is received or
descision is made that the remote node is not responding. This
be after a predefined time (min. 60 seconds) or a number of
(e.g., 16).
In composing the Timer Request, the router or workstation takes
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
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
Request packet. The Routing Type options should be added in
originator's order of preference with the most preferred
first
Some of the newer (or modified) IPX routing protocols do not have
requirement to allocate a network number on a WAN link. This type
routing protocol has the advantage of potentially
configuration as no network number pools are necessary for WAN links
However, these router implementations may still wish to
with the older IPXWAN implementations which are able to
network numbers for the WAN link. In this case, the following
is used to force the older implementation to become the link master
It should be noted that a router implementation capable of
workstation dial-in MUST be able to supply AT LEAST ONE
number on which the workstation can reside
If the router is prepared to assign an IPX network number to
link, it sends its primary network number in the Timer
WNodeID field, and omits the Extended Node ID option. On the
hand, if the router is NOT prepared to assign an IPX network
to the link, it sets the Timer Request WNodeID field to zero,
includes its primary network number in an Extended Node ID option
Workstations follow a similar, but slightly different set of
for setting the WNodeID field. If this is the first time the work
station is connecting to the router, the workstation will set
WNodeID to zero indicating the router should be the link master
allocate a network number for the new link. In this case, the work
station will respond to the router's Timer Request and
only the Workstation Routing Type option. Note that a
does NOT include an Extended Node ID option in it's timer request
If the workstation is reconnecting a link after an earlier
disconnect, it is necessary for the workstation to be able to
its network, NIC address and "Router Name" field (so that file
connections can be maintained after the reconnect). In this case
the workstation will set its WNodeID field to FFFFFFFFh
itself to be the link master. In this case, the router will
to the workstation's Timer Request with only the Workstation
Type acknowledged
Further packets in the IPXWAN exchange MUST use the correct
(workstations will always use zero).
Allen [Page 6]
RFC 1634 IPXWAN May 1994
On receiving a Timer Request packet, a router determines its role -
master or slave - for the remainder of the IPXWAN exchanges.
master role does not denote special privileges, it merely means
the router is the requestor in the ensuing request/
exchanges. The descision is made as follows
a) If the WNodeID field is zero in the sent and the received
i) If both Timer Requests include an Extended Node ID,
router with the higher numeric value of this field is
Master. If the two Extended Node ID fields are equal,
configuration error has occurred. After reporting the error
the router issues a disconnect on the underlying data-
connection. Manual intervention is needed to correct
error condition
ii) If only one Timer Request includes the Extended Node ID
the router sending it is the Master
iii) If neither Timer Request includes the Extended Node ID,
connection cannot be established. The data-link circuit
cleared by the system that initiated it
b) If either the sent or received Timer Request (or both)
a nonzero WNodeID field, the router with the higher WNodeID
the Master
c) If the two WNodeID fields are equal and nonzero,
configuration error has occurred. After reporting the error
the router issues a disconnect on the underlying data-
connection. Manual intervention is needed to correct the
condition
Note: The Primary Network Number for a workstation
determining master/slave roles depends on whether the
requires itself to be the master of slave. It should compare
received WNodeID to that sent in it's own Timer Request
The numeric comparisons are done by considering each byte of
WNodeID or Extended Node ID fields as an unsigned integer, and
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
option is not supported (or recognized), that option is rejected
changing the WAccept field to "NO" for that option
Allen [Page 7]
RFC 1634 IPXWAN May 1994
When selecting the router type which will be used on the link,
first option in the Timer Request which can be supported should
accepted. All other router types should have the WAccept field set
"NO". A router MUST NOT accept workstation connectivity to a
which is another router
Note: It is permitted for a router to support a numbered
type, but not be able to assign the network number. In this case
that routing type can be selected only if the other router
it and is able to assign the network number. This can be
by the value of the received WNodeID field. If the router is
to assign a network number to the link, it MUST support
RIP and include this option in the Timer Requests
If a router wishes to provide WAN Client access without
other WAN routing types, a potential problem arises since a
and WAN client would both just be sending a single Routing
option indicating the use of WAN Client. The IPXWAN
does not allow a WAN workstation to connect to another
workstation. The method for detecting this is that the sent
received Timer Requests have a single Routing Type defined of
Client. To overcome this problem, IPXWAN defines that a router
NOT send a single Routing Type if that type is just WAN Client.
router MUST additionally include one (or more) of the defined
types (like WAN RIP) with the WAccept option set to NO. This is
that a workstation may detect that this is actually a router
the Timer Request and not just another workstation trying to call
workstation. The extra option will serve to be a counted Routing
that will be ignored. If a workstation detects it is connecting
another workstation, it should disconnect the link
Note that a router supporting a workstation will need to be able
supply AT LEAST one network number for workstations. All dial-
workstations could share the same network, and be assigned
node numbers by the router, or each workstation could be assigned
different network number. This is a router specific
detail. Use of a single network for all clients is prefered, however
this does involve extra work by the router when dealing
broadcast frames. When the router is the link master and
NIC addresses on a single network,it should ALWAYS use a unique
- by incrementing the NIC address for each client connection.
allows a workstation which is reconnecting the ability to specify
old network and NIC address. It is unlikely with a 6 byte
address, that there will be wrap-around in the numbers that
cause a problem. Router Node Number allocation should follow a
simple rules. The six byte NIC address SHOULD have the first byte
to 2.
Allen [Page 8]
RFC 1634 IPXWAN May 1994
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
protocols in the received Timer Request, it MUST issue a
on the connection being established. The master of the
(determined when a Timer Response packet is received) is
for defining the network number that is to be used as a
network number for the new WAN link, and for calculating the
transport time that will be advertized to other RIP routers for
new link. This is calculated by stopping the timer which was
when a Timer Request was initiated and applying the algorithm
section 4.3.
3.2 Information
After exchanging Timer Request packets, the link master and
have been determined, and the Routing Protocol to be used on the
is negotiated. The link master is now responsible for sending
Information Request packet to the slave specifying the network
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,
Router Name (for management purposes), and for a
connection, the NIC address the workstation will be adopting. The
address option is a separate option added in the
Request/Response for workstation connectivity. It is NOT present
router to router connections
If a router receives an inappropriate Information Request from
workstation trying to set the common network number and NIC
the router MUST overwrite these values with preferred values.
the workstation receives the Information Response, it MUST note
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
master (i.e., it is reconnecting), the router is
responsible for ensuring the "Router Name" field matches that of
original connection. If the values differ, the call should
disconnected
If a router detects an error for which no suitable protocol
exists (e.g., unable to allocate a network number), the link
be terminated according to the relevant media specification
Allen [Page 9]
RFC 1634 IPXWAN May 1994
Under certain circumstances, particularly on X.25 permanent circuits
it is only possible to detect the remote router went away when
comes back up again. In this case, one side of the link receives
Timer Request packet when IPX is in a fully connected state.
side receiving the Timer Request MUST realize that a
occurred, and revert to the IPX link establishment phase
Furthermore, the routing information learned from this
should be immediately discarded
When Unnumbered RIP, On-demand or Workstation options are negotiated
Information Request packets are repeated every 20 seconds until
response is received. For the Numbered RIP links, the
Request is NOT resent. Instead, the link is disconnected after
suitable delay (min. 60 seconds) - this requirement
interoperabilty with earlier versions of IPXWAN. When
Requests are repeated, they should continue for a preconfigured
(min. 60 seconds) or a preconfigured number of retries (e.g., 16).
Each retry uses an incremented sequence number
3.3 NAK
The IPXWAN protocol uses a NAK packet to indicate the received
packet was not acceptable. A NAK packet is an exact copy of
received packet with the WPacketType field set to NAK. There are
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
was wrong. If the sender was unable to determine the problem,
call can then be disconnected
The value of the NAK WPacketType is FFh
4. Information Exchange Packet
All IPX WAN protocol exchanges utilize the standard Novell IPX
format. The packets use the IPX defined packet type 04 defining
Packet Exchange Packet. The socket number 0x9004 is a Novell
socket number for exclusive use with IPX WAN protocol exchange.
defines that a network number of zero (0) is interpreted as being
local network of unknown number that requires no routing.
feature is of use to us in transferring these packets before
common network number is exchanged. Some routers need to know a "
Number" (or MAC address) for each node on a link. Node numbers
Allen [Page 10]
RFC 1634 IPXWAN May 1994
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,
node number will be explicitly assigned by the router and notified
the workstation in the Information Request packet
Router Type number assignment. Other vendors IPX routing
can make use of the IPXWAN protocol definition by obtaining
Types from Novell. This document will then include the new
Types (with the references to vendor protocol description documents).
Current Routing Types are
00 Numbered RIP/
01 NLSP (no RIP/SAP - defined in [8])
02 Unnumbered RIP/
03 On Demand, static routing (no RIP/SAP or NLSP
04 Workstation (no RIP/SAP
05-FF Currently
WOption Number assignment. These numbers only need to be
from Novell for the "Timer Request" and "Timer Response" packets
Packet Types also need to be assigned by Novell. However, the
within these packets are dependant on the "Router Type" negotiated
WOption numbers in these packets are then defined by the
defining the Routing Type. The same packet format should still
maintained
Router Type 01 will not be described in this document since
involves knowledge of the NLSP protocol to implement. Please refer
[8] for a complete specification of these NLSP IPXWAN exchanges
the NLSP protocol
Allen [Page 11]
RFC 1634 IPXWAN May 1994
4.1 Timer Request
+---------------------------------------------------------------+
| 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
in a Timer Request packet. A router should ALWAYS include
Type zero (0) if full interoperability is required with an
implementation. The router types MUST be included in the
order of preference. If a router receives a Timer Response with
than one Router Type having WAccept set to Yes, the link MUST
disconnected
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 00 | IPX RIP/SAP Routing |
+---------------------------------------------------------------+
Allen [Page 12]
RFC 1634 IPXWAN May 1994
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 01 | NLSP |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 02 | Unnumbered RIP/SAP |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 03 | On-demand, static Rting
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 04 | Client - No RIP/SAP |
| | | except on request |
+---------------------------------------------------------------+
Extended Node ID Option
The extended node ID should only be included if the WNodeID field
set to zero AND the node constructing the packet is a router.
that an older version of IPXWAN will just reject this option
automatically become the link master as the WNodeID is zero
+---------------------------------------------------------------+
| WOption Number | 04 | Extended Node ID |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 00 04 | Pad data length (Hi Lo)|
| WOption Data | xx xx xx xx | Real primary network # |
| | | of this router (Hi-Lo) |
+---------------------------------------------------------------+
Header Compression Option
Although more than one header compression option may be specified
a Timer Request packet, it is important that a MAXIMUM of ONE
compression option is accepted. If an implementation receives
Timer Response with more than one header compression option with
accept option set to Yes, the link MUST be disconnected. [Ref 6]
defines the full Telebit Header Compression method
Allen [Page 13]
RFC 1634 IPXWAN May 1994
+---------------------------------------------------------------+
| WOption Number | 80 | Header Compression |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 00 03 | Variable - at least 1 |
| WOption Data | 00 | 0 = Telebit Hdr Compr. |
| | xx | Compression Options |
| | xx | Compression Slots |
+---------------------------------------------------------------+
PAD Option
The PAD option is used to fill the Timer Request up to the 576
limit. This field will be of variable length depending on the
of other options in the packet. This option will normally be
last entry in the packet. Its sole purpose is to fill the
packet to be 576 bytes. The pad option data should be filled with
selection of totally random numbers to avoid compression modems
PPP data compression from destroying the link delay calculation
Note that this is different from the original RFC 1362
specification. This should not affect implementations
Implementations should not attempt to verify the contents of a
option
+---------------------------------------------------------------+
| WOption Number | FF | Pad option |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | xx xx | Pad data length (Hi Lo)|
| | | (enough to fill packet)|
| WOption Data | Random numbers | |
+---------------------------------------------------------------+
Note
Timer Request packets will always be 576 bytes. However
there should be no assumption made about the number
options specified in this packet
After link establishment, Timer Request packets are sent by
sides of the link. Each end starts their sequence number at zero
Subsequent retries (every 20 seconds) will increment the value
this sequence number. Only a Timer Response packet with a
number matching the last sent sequence number will be acted upon
As mentioned earlier, the WNodeID field may be set to zero for
router if it is unable to provide a network number for the link.
a router ONLY supports the Numbered RIP/SAP option, it MUST
capable of proving a network number for a WAN link
Allen [Page 14]
RFC 1634 IPXWAN May 1994
Packets received on the reserved socket number not having
WIdentifier set to the hexadecimal values noted above should
discarded
4.2 Timer Response
+---------------------------------------------------------------+
| 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 | 01 | Timer Response |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | xx | Same as Timer Request |
| | | received |
| 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 |
+---------------------------------------------------------------+
The options contained within this packet are as described in
4.1 Any unknown options or not supported options within the
Request MUST have the WAccept Option set to NO in the Timer Response
If the Timer Request packet contained more than one Router
option and the "Slave" supports all the options, the "Slave" MUST
the WAccept Option to YES on the FIRST Router Type supported and
to ALL other Router Types. This is the Router Type which is to
adopted by both ends of the link. Information exchanges will
proceed by the link master based on the accepted Router Type
This packet must contain the same sequence number as the
Timer Request. This packet should ONLY be sent by the router
Allen [Page 15]
RFC 1634 IPXWAN May 1994
workstation determining themselves to be the "Slave" of the link
(Workstations are ALWAYS the link slave).
Routers MUST set the WNodeID to their correct value when
with the Timer Response. A value of zero must NOT be used
4.3 Information Request
+---------------------------------------------------------------+
| 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 | 02 | Information Request |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | 00 | Sequence start at 0 |
| 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 in |
| | | milli seconds (see |
| | | below for calculation) |
| Common Net # | xx xx xx xx | Hi Lo Common Network # |
| Router Name | xx (x 48 decimal) | Router name - as defned
| | | in section 2. |
+---------------------------------------------------------------+
Routers MUST set the WNodeID to their correct value when sending
Information Request. A value of zero must NOT be used
A workstation should replace the Router Name with the
name, or a constant descriptor string as described in section 2.
Allen [Page 16]
RFC 1634 IPXWAN May 1994
For a Workstation Information Request, an extra option is added
specifies the NIC address for the workstation. In this case,
number of options will be set to two (2).
+---------------------------------------------------------------+
| WOption Number | 05 | Define NIC Address |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 00 06 | Option length (Hi Lo) |
| WOption Data | 02 xx xx xx xx xx | NIC Address for W/S |
+---------------------------------------------------------------+
Routers or workstations should not refuse to use a NIC address
a first byte with a value other than 02.
Calculation of link delay is performed as follows
// Start_time is a time stamp when Timer Request sent
// End_time is a time stamp when a Timer Response
// received
link_delay = end_time - start_time; // 1/18th
if (link_delay < 1)
{
link_delay = 1;
}/*IF*/
// We are on a slow net, so add some biasing to help
// multiple workstation sessions timing out on the
link_delay *= 6; /* Add the biasing for multiple sessions */
link_delay *= 55; /* Convert link delay to milliseconds */
If a higher resolution timer is available, better results may
obtained using the following algorithm
conversion_factor = number of timer units in 1/18th second
link_delay = ((end_time - start_time) * 6) / conversion_factor
if (link_delay == 0)
{
link_delay = 1;
}/*IF*/
link_delay *= 55; /* Convert link delay to milliseconds */
The "Link Delay" is used as the network transport time
advertized in the IPX RIP packet tuple for the network entry "
Net #". For a consistent network, a common link delay is required
both ends of the link and is calculated by the link "Master".
Delay is specified in milli seconds
Allen [Page 17]
RFC 1634 IPXWAN May 1994
The Common Net # is supplied by the link "Master". This number
be unique in the connected internetwork. Each WAN call requires
separate number. If the negotiated Router Type was Unnumbered RIP
On-demand, or NLSP, the specified Common Net # will be zero
This packet should contain a sequence number starting at zero.
packet should ONLY be sent by the router or workstation
themselves to be the "Slave" of the link
If extra options are included in this packet, they should be
discarded.If the information option is missing, the link MUST
disconnected
Allen [Page 18]
RFC 1634 IPXWAN May 1994
4.4 Information Response
+---------------------------------------------------------------+
| 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
section 4.3.
A link slave will additionally respond with the received NIC
option as a confirmation of receipt. A workstation should replace
Router Name with the configured name, or a constant descriptor
as described in section 2. If the Information Request contained
inappropriate Common Net # or NIC address, the Information
may set new values. The receiver of the Information Response
responsible for checking on the value and terminating the
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
Information Response. A value of zero must NOT be used
5. Running Unnumbered
Unnumbered RIP refers to the case where two WAN routers
communicating using the RIP protocol across a link with NO
IPX network address. The premise for this ability is that there is
need to address a packet to anything on that WAN link. RIP and
run in exactly the same way as before, except the source
destination network numbers should be set to zero
The advantage to running unnumbered RIP links is that it is
necessary to allocate/configure a pool of usable IPX network
which can be used on the WAN links. The other advantage is that
there is a large number of WAN links, it is not necessary to
the network with an unnecessary set of extra RIP information
6. Workstation
Workstations MUST reside on a network and have a unique NIC
on that network to be individually addressable. However,
do not need to periodically receive RIP and SAP broadcasts as
play no part in the routing process. This allows routers to
background traffic on the workstation link by not sending
periodic RIP and SAP data. Note that it will not cause a problem
the RIP and SAP is sent. It will just slow down the
access times
RIP and SAP information should ONLY be sent if the workstation
a specific request for information - like a service or route request
It should also be noted that if multiple workstations are attached
a single WAN workstation network (per router), broadcasts on
network - whether originated from a workstation or the router -
reach ALL other workstations. This will involve the
duplicating the packet to all WAN workstation connections
7. On-demand, Statically Routed
On-demand, Static Routing serves two purposes. The "on-demand"
means that a router initiates communication to a destination
when there is data to be forwarded to that destination. "
comunication" includes making a datalink call (where necessary)
performing the IPXWAN exchange. A transient connection is
after a period of inactivity
Allen [Page 20]
RFC 1634 IPXWAN May 1994
The "static routing" part means that no routing information is
over the link - no RIP, no SAP, and no NLSP. Instead, the router
each end is configured with the routes and services
through the link
With on-demand, static routing, the called router must be able
identify the calling router so that statically configured routes
services can be attached to that connection. For example, with X.25
switched virtual circuits, the calling DTE address can be used;
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
identifier can be used. The choice of identifier is an
decision. Whatever value the called router uses is called a
System Identifier, or RSI. For PPP links, Novell uses PPP PAP or
authentication to determine the caller
A router implementing on-demand, static routing must maintain
database of RSIs, and lists describing the network numbers
services reachable through each RSI. These lists determine
reachability information it transmits to other routers in a
area. Other routers treat each on-demand, static routing link
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
Timer Request, along with any additional routing types it is
to support on the link. The Master/Slave election and choice
routing type proceeds as described previously. If the Slave detects
mismatch in routing types, it disconnects the link
For a persistent datalink (like X.25 PVCs), there may be
descerable "link establishemnt" event. For such media, arrival of
Timer Request plays the role of detecting link establishment
As with Unnumbered RIP, there is no network number assigned to
link. NLSP Packets are not sent on the link. Moreover, periodic
and SAP packets are not sent on the link. However, a router
respond to RIP and SAP queries received on the link
Allen [Page 21]
RFC 1634 IPXWAN May 1994
8.
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP) for
Transmission of Multi-protocol Datagrams over Point-to-
Links", RFC 1548, Daydreamer, December 1993.
[2] Malis, A., Robinson, D., and R. Ullman, "
Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
August 1992.
[3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol
over Frame Relay", RFC 1490, Wellfleet Communications, Inc.,
Ascom Timeplex, Inc., July 1993.
[4] Simpson, W., "The PPP Internetwork Packet Exchange
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-
(130.57.11.140) under /sys/ftpguest/dev_docs/ipx_rtr/ipxrtr.
[6] Mathur, S., and M. Lewis, "Compressing IPX Headers Over WAN
(CIPX)", RFC 1553, Telebit Corporation, December 1993.
[7] ANSI, "Integrated Services Digital Network (ISDN) -
Subscriber Signalling System Number 1 (DSS1) -
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
via Anonymous FTP to SJF-LWP (130.57.11.140)
/sys/ftpguest/dev_docs/ipx_rtr/nlsp.zip
9. Security
Security issues are not discussed in this memo
Allen [Page 22]
RFC 1634 IPXWAN May 1994
10. Author's
Michael
Novell, Inc
2180 Fortune
San Jose, CA 95131
EMail: mallen@novell.
The working group can be contacted via the current chair
Fred
Advanced Computer
315 Bollay
Santa Barbara, California, 93111
EMail: fbaker@acc.
Allen [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
