rfc1362.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 731 行 · 第 1/3 页
TXT
731 行
Network Working Group M. Allen
Request for Comments: 1362 Novell, Inc.
September 1992
Novell IPX Over Various WAN Media (IPXWAN)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. 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.
Table of Contents
1. Introduction ................................................. 1
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 .............. 2
1.4. Operation Over Frame Relay .................................. 3
1.5. Operation Over Other WAN Media .............................. 3
2. Glossary Of Terms ............................................ 3
3. IPX WAN Protocol Description ................................. 4
4. Information Exchange Packet Formats .......................... 5
4.1. Timer Request Packet ........................................ 6
4.2. Timer Response Packet ....................................... 8
4.3. Information Request Packet .................................. 10
4.4. Information Response Packet ................................. 12
5. References ................................................... 12
6. Security Considerations ...................................... 13
7. Author's Address.............................................. 13
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.
Allen [Page 1]
RFC 1362 IPXWAN September 1992
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 reject all 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.
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
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.
Allen [Page 2]
RFC 1362 IPXWAN September 1992
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
Novell conforms to RFC-1294, "Multiprotocol Interconnect over Frame
Relay" [3] for frame relay service and packet encapsulation.
Currently, Novell has not stabilized the method for treating frame
relay connections - whether they treat the connections as LANs or
WANs.
1.5 Operation over other WAN media
Additional WAN media will be added here as specifications are
developed.
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', 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.
Allen [Page 3]
RFC 1362 IPXWAN September 1992
3. IPX WAN Protocol Description
IPX WAN links have the concept of a LINK MASTER and a LINK SLAVE.
This relationship is decided upon based on information contained
within the first IPX packets transferred across the WAN link.
After link establishment, both sides of the link send "Timer Request"
packets and start a timer waiting for a "Timer Response". These
"Timer Request" packets are sent every 20 seconds until a response is
received or a time-out occurs trying to initialize a connection (the
timer is restarted each time a new "Timer Request" is sent). The
time-out should be configurable, and is normally about one minute.
This is directly dependent on the call setup time for the connection.
If a time-out occurs, the router issues a disconnect on the offending
connection and optionally attempts to retry the connection.
When a "Timer Request" is received, the router with the lowest
primary network number MUST respond with a "Timer Response" packet -
and become the "Slave" of the link. If the "Slave" determines that it
cannot support any of the Routing Types included in the "Timer
Request" packet, the "Slave" should 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.2.
To allow this, both sides of the link MUST have an adequate pool of
WAN network numbers (unique within the internetwork) available to be
assigned to the link when the call is fully completed. The "Master"
of the link MUST then select a network number and construct an
"Information Request" packet containing the calculated link delay,
the common network number, and its own router name. On receiving this
packet, the "Slave" MUST turn the packet around, overwrite the router
name and node identifier and send an "Information Response".
After the "Master" has received the "Information Response" and the
"Slave" has received the "Information Request", standard IPX RIP and
SAP packets are transferred across the WAN link, as currently defined
for LAN links. The "IPX Router Specification" [5] contains
information describing the Novell RIP/SAP protocol for third party
developers.
Note that the "Information Request" and "Information Response"
packets are specific to the "Routing Type"=0 information exchanges.
Allen [Page 4]
RFC 1362 IPXWAN September 1992
With this routing type, no retransmission is made of any of the
Information packets. If a response has not been received within the
predefined time-out period, a disconnect is issued on the link, and
the link can optionally be attempted later.
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?