Network Working Group Steven J. Senum Internet Draft Network Systems Corporation July 15, 1992 Point-to-Point Protocol Extensions for DECnet Phase IV Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other that as a ``working draft'' or ``work in progress.'' Please check the 1id- abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. The expiration date is 1/22/93. 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). Senum [Page 1] Internet Draft DECnet Point-to-Point July 15, 1992 1. Introduction There are two basic approaches to running the DNA Phase IV Routing protocol over a serial line: 1. The approached 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 type 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 type is reserved to allow diagnostic software communications in parallel with other data link clients. Senum [Page 2] Internet Draft DECnet Point-to-Point July 15, 1992 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 type 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 (MOP, LAT, etc). Senum [Page 3] Internet Draft DECnet Point-to-Point July 15, 1992 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. As with the Link Control Protocol (LCP, defined in [1]), this is accomplished through an exchange of packets. DNCP packets may not be exchanged until the LCP has reached the Network-Layer Protocol Configuration Negotiation phase. DNCP packets received before this phase is reached should be silently discarded. Likewise, DNA Phase IV Routing packets may not be exchanged until the DNCP has first opened the connection (reached the Open state). The DNCP is the same as the LCP with the following exceptions: Data Link Layer Protocol Field Exactly one DNCP packet is encapsulated in the Information field of PPP Data Link Layer frames 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 the LCP has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing 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. 4. DNA Phase IV Control Protocol Configuration Option Types The DNA Phase IV Control Protocol has no Configuration Options. Senum [Page 4] Internet Draft DECnet Point-to-Point July 15, 1992 5. Sending DNA Phase IV Routing Packets Before any DNA Phase IV Routing packets may be sent, both the Link Control Protocol and the DNA Phase IV Routing Control Protocol must reach Open state. Exactly one octet-count field and one DNA Phase IV Routing packet are encapsulated in the information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0027 (DNA Phase IV Routing). The octet-count 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 an 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] Senum [Page 5] Internet Draft DECnet Point-to-Point July 15, 1992 6. Security Considerations Security issues are not discussed in this memo. 7. Other 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 [1]. 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 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. The type of a node (endnode versus routing) can be determined from the hello messages received from it. Senum [Page 6] Internet Draft DECnet Point-to-Point July 15, 1992 References [1] Simpson, W. A., "The Point-to-Point Protocol for the Transmission of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC 1331, 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. Senum [Page 7] Internet Draft DECnet Point-to-Point July 15, 1992 Acknowledgments 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: Brian Lloyd Llyod & 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 Expiration Date The expiration date of this memo is 1/22/93. Senum [Page 8]