Network Working Group                                    Steven J. Senum
Request for Comments: Internet Draft         Network Systems Corporation
                                                            May 31, 1991


                    Point-to-Point Protocol Extensions
                                    for
                              DECnet Phase IV

Status of this Memo

   This draft document will be submitted to the RFC editor as a protocol
   specification.  Please send comments to the author.  It is an
   extension of the Internet Point-to-Point Protocol described in RFC
   1171 [1], targeting the use of Point-to-Point lines for DECnet.
   Distribution of this memo is unlimited.

1.  Introduction

   The purpose of this memo is to define a method for transmitting DNA
   Phase IV Routing packets over a serial link using the PPP protocol as
   defined in [1].  This memo only applies 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:

   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 memo 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



Senum                                                           [Page 1]

Internet Draft           DECnet Point-to-Point              May 31, 1991


         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.

      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



Senum                                                           [Page 2]

Internet Draft           DECnet Point-to-Point              May 31, 1991


         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.


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



Senum                                                           [Page 3]

Internet Draft           DECnet Point-to-Point              May 31, 1991


      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.


3.1.  DNA Phase IV Control Protocol Configuration Option Types

   The value for the Configuration Option Type field is

   1        Node Type

3.1.1.  Node Type

   Description

      This Configuration Option provides a way to ascertain the routing
      type of the nodes connected by the link.  If a router discovers it
      is connected to an endnode, then the router may choose not to send
      routing update messages over this link.  If this Configuration
      Option is rejected, the router should assume the other end of the
      link is a Level 2 Router.

   A summary of the Configuration Option format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |       Routing Type            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      1

   Length

      4

   Routing Type

      1      Level 2 Router
      2      Level 1 Router
      3      Endnode







Senum                                                           [Page 4]

Internet Draft           DECnet Point-to-Point              May 31, 1991


4.  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              May 31, 1991


5.  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).  To achieve convergence of routes within a satisfactory
   time, the interval between updates should be based upon the error
   rate of underlying data link.  The following values are guidelines by
   Digital for the routing update timer on unreliable links:

   o  For bit error rates greater than 1 in 10^7, a reliable protocol
      (e.g. HDLC) may have to be used instead of PPP to achieve
      acceptable performance.

   o  For bit error rates between 1 in 10^7 and 1 in 10^9, complete
      routing updates should be sent every 10 seconds.

   o  For bit error rates less than 1 in 10^9, complete routing updates
      should be sent every 30 seconds.

   o  Phase IV Routing should not be run over links of speed less than
      56 Kbits per second.  This will ensure that routing updates will
      never consume more that 3% of the nominal link bandwidth.

   Note that acceptable performance is also based on how often topology
   changes occur in the network, the size of the routing vectors, and
   what the network user is willing to tolerate.

   It is also 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.






Senum                                                           [Page 6]

Internet Draft           DECnet Point-to-Point              May 31, 1991


                                References

   [1]   Perkins, D., "The Point-to-Point Protocol for the Transmission
         of Multi-Protocol Datagrams Over Point-to-Point Links", RFC
         1171, Carnegie Mellon University, July 1990.


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

Security Considerations

   Security issues are not discussed in this memo.

Chairman's Address

   This proposal is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF). The working
   group can be contacted via the chair:

      Stev Knowles
      FTP Software
      26 Princess Street
      Wakefield, MA 01880-3004

      Phone: (617) 246-0900 x270

      EMail: Stev@FTP.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, MN   55428

      Phone: (612) 424-4888

      EMail: sjs@network.com





Senum                                                           [Page 7]

Internet Draft           DECnet Point-to-Point              May 31, 1991


Acknowledgments

   The author wishes to thank Jim Muchow (Network Systems  Corporation),
   and  Arthur Harvey (Digital Equipment Corporation) for their input to
   this memo.














































Senum                                                           [Page 8]