doc: Add RFC documents

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]
+