The PPP DECnet Phase IV Control Protocol (DNCP)
How a PPP link agrees to carry DECnet Phase IV routing traffic, treating the serial line like an Ethernet.
Senum, S., "The PPP DECnet Phase IV Control Protocol (DNCP)", RFC 1762, DOI 10.17487/RFC1762, March 1995, <https://www.rfc-editor.org/info/rfc1762>.
@misc{rfc1762,
series = {Request for Comments},
number = 1762,
howpublished = {RFC 1762},
publisher = {RFC Editor},
doi = {10.17487/RFC1762},
url = {https://www.rfc-editor.org/info/rfc1762},
author = {S. Senum},
title = {{The PPP DECnet Phase IV Control Protocol (DNCP)}},
pagetotal = 7,
year = 1995,
month = mar,
} RFC text
Contents
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.
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.
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.
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).
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).
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
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
AI ELI5
On this page
§1Two Ways to Run DECnet over a Serial Line
RFC 1762 defines the Network Control Protocol (NCP) that sets up Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over the Point-to-Point Protocol (PPP). PPP itself, defined in RFC 1661, provides a standard way to encapsulate network-layer traffic over point-to-point links and proposes a family of NCPs for configuring each network-layer protocol.
The RFC names two basic approaches for running Phase IV Routing over a serial line. Several router vendors treat the serial link as an Ethernet and use the same data and control messages an Ethernet would use. Digital's own approach uses DDCMP and slightly different control messages. This document defines a method that uses the first approach.
There are two ways to send these messages down a wire. This document picks the one that pretends the wire is a normal office network cable.
§2Which Phase IV Protocols Are Covered
The RFC lists the Phase IV DNA protocols that act as data link clients: Routing, System Console, Digital Customer Use, Diagnostics, the Naming Service (DNS), the Time Service (DTS), Load/Dump, Experimental Use, Communications Test and Digital Protocol X1. Each gets a short description.
Only the first is in scope. The document applies to DNA Phase IV Routing messages, both data and control, and not to other DNA Phase IV protocols such as MOP and LAT. The Routing protocol is described as a network layer protocol providing services similar to those of DoD IP: it routes messages in Phase IV DECnet networks and manages the packet flow.
The company had many kinds of network messages. This document only handles the one that works like a postal sorting system, and leaves the rest alone.
§3The DNA Phase IV Routing Control Protocol
The DNA Phase IV Routing Control Protocol (DNCP) configures, enables and disables the Phase IV Routing modules on both ends of the link. It uses the same packet exchange mechanism as the Link Control Protocol (LCP) and is exactly the same as LCP except for a few listed differences.
- DNCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. Packets received before then should be silently discarded.
- Exactly one DNCP packet goes in the Information field of a PPP frame whose Protocol field is hex
8027. - Only Codes 1 through 7 are used: Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject. Other Codes are treated as unrecognized and should result in Code-Rejects.
- DNCP has no Configuration Options.
On timeouts, an implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out on a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time.
The two machines use the same polite hello and goodbye steps they already use for the wire itself. There is nothing to bargain over here, just a yes or a no to turn the service on.
- 1Configure-Request — Asks the peer to open the routing protocol.
- 2Configure-Ack — Accepts the request.
- 3Configure-Nak — Refuses the request but suggests changes.
- 4Configure-Reject — Refuses the request.
- 5Terminate-Request — Asks to close the protocol.
- 6Terminate-Ack — Agrees to the close.
- 7Code-Reject — Sent for any other, unrecognized Code.
§4Sending Routing Packets in PPP Frames
Before any Routing packets are sent, PPP must reach the Network-Layer Protocol phase and DNCP must reach the Opened state.
Each PPP frame then carries exactly one length field and one Routing packet, with the Protocol field set to hex 0027. The length field counts the octets of the Routing packet. It is two octets long and is stored in VAX byte ordering, least significant byte first, to match DNA Phase IV Routing over Ethernet. It is needed to tell optional padding octets from real information.
The Routing packet itself has the same format as over Ethernet, without the Ethernet header, Pad and FCS fields. Its maximum length is the maximum length of the PPP Information field minus 2 octets for the length field.
Each message gets a small label at the front saying how long it is, so the receiver can tell real message from empty padding at the end.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
LENGTH-LSB | Length LSB | 1 byte | Least significant byte of the length. | |
LENGTH-MSB | Length MSB | 1 byte | Most significant byte of the length. | |
DATA | DATA | 2 bytes | DNA Phase IV Routing data, continuing for the rest of the packet. |
§5Routing Timers and Endnodes
When the network topology changes, Phase IV Routing nodes propagate the change at once through Level 1 and Level 2 Routing messages, with a 1 second minimum delay between updates. They also periodically resend the complete Level 1 and Level 2 distance vectors to guard against corrupted host memory and, on Ethernet, packet loss.
Digital's serial links use DDCMP, which guarantees delivery, so the recommended default retransmit time there is long (600 seconds). Ethernet does not guarantee delivery, so its recommended default is short (10 seconds). Because PPP sits between these cases, the RFC recommends that the time between routing updates be user configurable per PPP interface, based on the error rate of the underlying data link.
The Hello timer and Listen timer should follow the broadcast link recommendations, 15 and 45 seconds. Routers MAY skip sending routing updates when the remote node is an endnode, and endnodes MUST discard all routing updates received over a PPP link. A node's type can be learned from the hello messages it sends.
Machines repeat their route lists every so often in case something got lost. On a wire that never loses anything they can repeat rarely; on a shakier wire, more often. Machines that only receive mail, and do not pass it on, ignore the route lists.
§6Security Considerations
The RFC contains a Security Considerations section, but it says only that security issues are not discussed in this memo. Authentication, where used, happens in an earlier PPP phase before DNCP packets may be exchanged.
The document does not talk about how to keep bad guys out. It only describes how to turn the service on.