summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1762.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1762.txt')
-rw-r--r--doc/rfc/rfc1762.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc1762.txt b/doc/rfc/rfc1762.txt
new file mode 100644
index 0000000..c541bb3
--- /dev/null
+++ b/doc/rfc/rfc1762.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group S. Senum
+Request for Comments: 1762 DigiBoard
+Obsoletes: 1376 March 1995
+Category: Standards Track
+
+
+ The PPP DECnet Phase IV Control Protocol (DNCP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method of
+ encapsulating Network Layer protocol information over point-to-point
+ links. PPP also defines an extensible Link Control Protocol, and
+ proposes a family of Network Control Protocols (NCPs) for
+ establishing and configuring different network-layer protocols.
+
+ This document defines the NCP for establishing and configuring
+ Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.
+ This document applies only to DNA Phase IV Routing messages (both
+ data and control), and not to other DNA Phase IV protocols (MOP, LAT,
+ etc).
+
+1. Introduction
+
+ There are two basic approaches to running the DNA Phase IV Routing
+ protocol over a serial line:
+
+ 1. The approach that several router vendors have taken which is to
+ treat the serial link as an Ethernet, using the same data and
+ control messages an Ethernet would use.
+
+ 2. The approach defined by Digital, which uses DDCMP and slightly
+ different control messages.
+
+ This document will define a method that uses the first approach.
+
+
+
+
+
+
+
+
+Senum [Page 1]
+
+RFC 1762 PPP DNCP March 1995
+
+
+2. Overview Of Phase IV DNA Protocols
+
+ The Phase IV DNA protocols which act as data link clients are:
+
+ o DNA Phase IV Routing
+ The Phase IV Digital Network Architecture (DNA) Routing
+ protocol is a network layer protocol providing services similar
+ to that of DoD IP. It routes messages in Phase IV DECnet
+ networks and manages the packet flow. The complete definition
+ of the DNA Phase IV Routing protocol can be found in [2].
+
+ o DNA System Console
+ The Digital Network Architecture (DNA) System Console protocol
+ is a maintenance protocol providing low level access to a
+ system for the functions of:
+
+ . Identify processor
+ . Read data link counters
+ . Boot system
+ . Console carrier (a general purpose i/o channel)
+
+ The complete definition of the DNA System Console protocol can
+ be found in [3].
+
+ o Digital Customer Use
+ The Digital Customer Use protocol is a value reserved for use
+ by Digital customers. It allocates a type for private use
+ which will not conflict with Digital or other vendor protocols.
+
+ o DNA Diagnostics
+ The Digital Network Architecture (DNA) Diagnostics protocol is
+ reserved to allow diagnostic software communications in
+ parallel with other data link clients.
+
+ o DNA Naming Service (DNS)
+ The Digital Network Architecture Naming Service (DNS) provides
+ a distributed naming service. It allows clients to register
+ named objects and to bind a set of attributes to the objects in
+ a distributed database.
+
+ o DNA Time Service (DTS)
+ The Digital Network Architecture Time Service (DTS) is a
+ protocol providing global clock synchronization in a
+ distributed environment.
+
+
+
+
+
+
+
+Senum [Page 2]
+
+RFC 1762 PPP DNCP March 1995
+
+
+ o DNA Load/Dump
+ The Digital Network Architecture (DNA) Load/Dump protocol is a
+ maintenance protocol for copying the contents of processor
+ memory to or from a remote system. For example, a system
+ manager can load an operating system into an unattended, remote
+ system. The complete definition of the Phase IV DNA Load/Dump
+ protocol can be found in [3].
+
+ o DNA Experimental Use
+ The Digital Network Architecture (DNA) Experimental Use
+ protocol allows Digital experimental protocols to share a data
+ link with other data link clients. It is for use by Digital
+ Equipment Corporation only.
+
+ o DNA Communications Test
+ The Digital Network Architecture (DNA) Communications Test
+ protocol is a maintenance protocol for testing the data link
+ communications path. The complete definition of the DNA
+ Communications Test protocol can be found in [3].
+
+ o Digital Protocol X1
+ The Digital X1 protocol is a network layer protocol currently
+ private to Digital.
+
+ This document defines the NCP for establishing and configuring
+ Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.
+ This document applies only to DNA Phase IV Routing messages (both
+ data and control), and not to other DNA Phase IV protocols.
+
+3. A PPP Network Control Protocol for DNA Phase IV Routing
+
+ The DNA Phase IV Routing Control Protocol (DNCP) is responsible for
+ configuring, enabling, and disabling the DNA Phase IV Routing
+ protocol modules on both ends of the point-to-point link. DNCP uses
+ the same packet exchange mechanism as the Link Control Protocol
+ (LCP). DNCP packets may not be exchanged until PPP has reached the
+ Network-Layer Protocol phase. DNCP packets received before this
+ phase is reached should be silently discarded.
+
+ The DNA Phase IV Routing Control Protocol is exactly the same as the
+ Link Control Protocol [1] with the following exceptions:
+
+ Frame Modifications
+
+ The packet may utilize any modifications to the basic frame format
+ which have been negotiated during the Link Establishment phase.
+
+
+
+
+
+Senum [Page 3]
+
+RFC 1762 PPP DNCP March 1995
+
+
+ Data Link Layer Protocol Field
+
+ Exactly one DNCP packet is encapsulated in the Information field
+ of a PPP Data Link Layer frame where the Protocol field indicates
+ type hex 8027 (DNA Phase IV Control Protocol).
+
+ Code field
+
+ Only Codes 1 through 7 (Configure-Request, Configure-Ack,
+ Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
+ and Code-Reject) are used. Other Codes should be treated as
+ unrecognized and should result in Code-Rejects.
+
+ Timeouts
+
+ DNCP packets may not be exchanged until PPP has reached the
+ Network-Layer Protocol phase. An implementation should be
+ prepared to wait for Authentication and Link Quality Determination
+ to finish before timing out waiting for a Configure-Ack or other
+ response. It is suggested that an implementation give up only
+ after user intervention or a configurable amount of time.
+
+ Configuration Option Types
+
+ DNCP has no Configuration Options.
+
+4. Sending DNA Phase IV Routing Packets
+
+ Before any DNA Phase IV Routing packets may be communicated, PPP
+ must reach the Network-Layer Protocol phase, and the DNA Phase IV
+ Routing Control Protocol must reach the Opened state.
+
+ Exactly one length field and one DNA Phase IV Routing packet are
+ encapsulated in the information field of a PPP Data Link Layer
+ frame where the Protocol field indicates type hex 0027 (DNA Phase
+ IV Routing). The length field contains a count of the number of
+ octets in the DNA Phase IV Routing packet. It is two octets in
+ length itself, and is stored in VAX byte ordering, to be more
+ consistent with DNA Phase IV Routing over Ethernet (i.e. least
+ significant byte first). It is needed to disambiguate optional
+ padding octets from real information.
+
+ The maximum length of a DNA Phase IV Routing packet transmitted
+ over a PPP link is the same as the maximum length of the
+ Information field of a PPP data link layer frame minus 2 octets
+ (for the Length field).
+
+
+
+
+
+Senum [Page 4]
+
+RFC 1762 PPP DNCP March 1995
+
+
+ The format of the packets themselves is the same as the format
+ used over Ethernet, without the Ethernet header, Pad, and FCS
+ fields.
+
+ A summary of the information field is shown below. The fields are
+ transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length LSB | Length MSB | DATA | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length LSB
+
+ Least significant byte of length field
+
+ Length MSG
+
+ Most significant byte of length field
+
+ DATA
+
+ DNA Phase IV Routing data, as specified in [2]
+
+5. General Considerations
+
+ When a topology change in the network occurs, DNA Phase IV Routing
+ nodes immediately propagate changes via Level 1 and Level 2 Routing
+ messages, with a 1 second minimum delay between updates. DNA Phase
+ IV Routing nodes also periodically retransmit the complete Level 1
+ and Level 2 distance vectors to guard against data corruption in host
+ memory, and (in the case of Ethernet) loss of packets due to media
+ errors. Because Digital's serial links run a protocol that
+ guarantees delivery of packets (DDCMP), the recommended default
+ retransmit time is long (600 seconds), whereas for Ethernet, where
+ packet delivery is not guaranteed, the recommended default is short
+ (10 seconds), as documented in [2]. To achieve convergence of routes
+ within a satisfactory time, the interval between updates should be
+ based upon the error rate of underlying data link. As such, it is
+ recommended that the time between routing updates be user
+ configurable per PPP interface.
+
+ The Hello timer and Listen timer should be set according to the
+ recommendations for broadcast links (15 and 45 seconds,
+ respectively).
+
+
+
+Senum [Page 5]
+
+RFC 1762 PPP DNCP March 1995
+
+
+ Routers MAY not send routing updates if the remote node connected via
+ the PPP link is an endnode. Endnodes MUST discard all routing
+ updates received over a PPP link. The type of a node (endnode versus
+ routing) can be determined from the hello messages received from it.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+References
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
+ 1661, Daydreamer, July 1994.
+
+ [2] Digital Equipment Corporation, "DNA Routing Layer Functional
+ Specification", Version 2.0.0, Order No. AA-X435A-TK.
+
+ [3] Digital Equipment Corporation, "DNA Maintenance Operations
+ Functional Specification", Version 3.0.0, Order No. AA-X436A-TK.
+
+Acknowledgments
+
+ Some of the text in this document is taken from previous documents
+ produced by the Point-to-Point Protocol Working Group of the Internet
+ Engineering Task Force (IETF).
+
+ The author wishes to thank Jim Muchow (Network Systems Corporation),
+ and Arthur Harvey (Digital Equipment Corporation) for their input to
+ this memo.
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Fred Baker
+ Senior Software Engineer
+ Cisco Systems
+ 519 Lado Drive
+ Santa Barbara, California 93111
+
+ Phone: (408) 526-4257
+ EMail: fred@cisco.com
+
+
+
+
+
+
+
+
+
+Senum [Page 6]
+
+RFC 1762 PPP DNCP March 1995
+
+
+Author's Address
+
+ Questions about this memo can also be directed to the author:
+
+ Steven J. Senum
+ DigiBoard
+ 6400 Flying Cloud Drive
+ Eden Prairie, Minnesota 55344
+
+ Phone: (612) 943-9020
+ EMail: sjs@digibd.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Senum [Page 7]
+