path: root/doc/rfc/rfc1762.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L