RFC 1376

The PPP DECnet Phase IV Control Protocol (DNCP)

📅 published November 1992, from ietf

RFC 1376: The PPP DECnet Phase IV Control Protocol (DNCP) 💖

Author: S. Senum, Network Systems Corporation 🎀 Date: November 1992 🌸 Category: IAB standards track protocol 👑 Stream: Network Working Group 🦋 Obsoletes / Updates: the title block doesn't list any RFCs it obsoletes or updates ✨

Status of This Memo

okay so this RFC is an IAB standards track protocol for the Internet community, and it's basically asking everyone to talk about it and suggest improvements 🗣️ If you want the current standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📚 And it's extremely shareable: distribution of this memo is unlimited 🫶

Abstract

the Point-to-Point Protocol (PPP) [1] is the standard way to wrap Network Layer protocol info so it can travel over point-to-point links 🎁 PPP also comes with an extensible Link Control Protocol, plus a whole family of Network Control Protocols (NCPs) that set up and configure different network-layer protocols 💅

this document defines the NCP that sets up and configures Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP 🧚 It only covers DNA Phase IV Routing messages (both data and control). It does not cover other DNA Phase IV protocols like MOP, LAT, etc. 🙈

1. Introduction ✨

there are two main ways to run DNA Phase IV Routing over a serial line 👀

  1. the approach a bunch of router vendors went with, which is to treat the serial link like an Ethernet and use the same data and control messages an Ethernet would use 🌈
  2. the approach Digital defined, which uses DDCMP and has slightly different control messages 💜

this document is going to define a method that uses the first approach 🦋

2. Overview Of Phase IV DNA Protocols 💅

these are the Phase IV DNA protocols that act as data link clients 🫶

  • DNA Phase IV Routing 🗺️ The Phase IV Digital Network Architecture (DNA) Routing protocol is a network layer protocol that gives you services kind of like 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 is in [2].
  • DNA System Console 💻 The Digital Network Architecture (DNA) System Console protocol is a maintenance protocol that gives you low level access to a system for these jobs:
    • 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 is in [3].

  • Digital Customer Use 🎀 The Digital Customer Use protocol type is a value reserved for Digital customers. It allocates a type for private use that won't conflict with Digital or other vendor protocols.
  • DNA Diagnostics 🩺 The Digital Network Architecture (DNA) Diagnostics protocol type is reserved so diagnostic software can talk in parallel with other data link clients.
  • DNA Naming Service (DNS) 🏷️ The Digital Network Architecture Naming Service (DNS) gives you a distributed naming service. Clients can register named objects and bind a set of attributes to those objects in a distributed database.
  • DNA Time Service (DTS) ⏰ The Digital Network Architecture Time Service (DTS) is a protocol that provides global clock synchronization in a distributed environment.
  • 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 is in [3].
  • DNA Experimental Use 🧪 The Digital Network Architecture (DNA) Experimental Use protocol type lets Digital experimental protocols share a data link with other data link clients. It's for use by Digital Equipment Corporation only.
  • 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 is in [3].
  • Digital Protocol X1 🔒 The Digital X1 protocol is a network layer protocol that's currently private to Digital.

this document defines the NCP that sets up and configures Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP 🧚 It only applies to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.) 💖

3. A PPP Network Control Protocol for DNA Phase IV Routing 🌸

the DNA Phase IV Routing Control Protocol (DNCP) handles 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 that show up 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 that were negotiated during the Link Establishment phase 🎀

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 are used: Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject 💅 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 while 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. zero. none. 🫠

4. Sending DNA Phase IV Routing Packets 🚀

before any DNA Phase IV Routing packets can 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 octet-count 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 octet-count holds a count of the number of octets in the DNA Phase IV Routing packet. It's two octets in length itself, and it's stored in VAX byte ordering, to be more consistent with DNA Phase IV Routing over Ethernet (i.e. least significant byte first) 💜 It's needed to tell optional padding octets apart 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 🦋

here's a summary of the information field. 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 🌈

okay this part is giving network drama 🎭 When a topology change happens in the network, DNA Phase IV Routing nodes immediately propagate the changes via Level 1 and Level 2 Routing messages, with a 1 second minimum delay between updates ⚡ They 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 🛡️

here's the thing: Digital's serial links run a protocol that guarantees delivery of packets (DDCMP), so the recommended default retransmit time is long (600 seconds) 🐢 Meanwhile, for Ethernet, where packet delivery isn't guaranteed, the recommended default is short (10 seconds), as documented in [2] 🐇 To get routes to converge within a satisfactory time, the interval between updates should be based upon the error rate of the underlying data link 📊 So, 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 are not required to send routing updates if the remote node connected via the PPP link is an endnode 🙅 Endnodes are required to discard all routing updates received over a PPP link 🗑️ You can tell the type of a node (endnode versus routing) from the hello messages received from it 🫶

References 📚

[1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331, Daydreamer, May 1992.

[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 💖

Security Considerations 💀

Security issues are not discussed in this memo. Not one word. Not even a hint. 😭

Chair's Address 🎀

the working group can be contacted via the current chair 💌

Brian Lloyd
Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682

Phone: (916) 676-1147
EMail: brian@lloyd.com

Author's Address 🖋️

questions about this memo can also be directed to the author 🧚

Steven J. Senum
Network Systems Corporation
7600 Boone Avenue North
Minneapolis, Minnesota 55428

Phone: (612) 424-4888
EMail: sjs@network.com
📦 where this page comes from