Network Working Group S. Senum Request for Comments: 1762 DigiBoard Obsoletes: 1376 March 1995 Category: Standards Track
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.
The Point-to-Point Protocol (PPP)  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).
There are two basic approaches to running the DNA Phase IV Routing protocol over a serial line:
This document will define a method that uses the first approach.
The Phase IV DNA protocols which act as data link clients are:
. 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 .
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.
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  with the following exceptions:
The packet may utilize any modifications to the basic frame format which have been negotiated during the Link Establishment phase.
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).
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.
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.
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).
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 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Least significant byte of length field
Most significant byte of length field
DNA Phase IV Routing data, as specified in 
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 . 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,
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 issues are not discussed in this memo.
 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.
 Digital Equipment Corporation, "DNA Routing Layer Functional Specification", Version 2.0.0, Order No. AA-X435A-TK.
 Digital Equipment Corporation, "DNA Maintenance Operations Functional Specification", Version 3.0.0, Order No. AA-X436A-TK.
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.
The working group can be contacted via the current chair:
Senior Software Engineer
519 Lado Drive
Santa Barbara, California 93111
Phone: (408) 526-4257
Questions about this memo can also be directed to the author:
Steven J. Senum
6400 Flying Cloud Drive
Eden Prairie, Minnesota 55344
Phone: (612) 943-9020