GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1376

Network Working Group S. Senum Request for Comments: 1376 Network Systems Corporation

                                                         November 1992
          The PPP DECnet Phase IV Control Protocol (DNCP)

Status of this Memo

 This RFC specifies an IAB standards track protocol for the Internet
 community, and requests discussion and suggestions for improvements.
 Please refer to the current edition of the "IAB Official Protocol
 Standards" 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 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.

Senum [Page 1] RFC 1376 PPP DNCP November 1992

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

Senum [Page 2] RFC 1376 PPP DNCP November 1992

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

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

Senum [Page 3] RFC 1376 PPP DNCP November 1992

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

Senum [Page 4] RFC 1376 PPP DNCP November 1992

  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 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 5] RFC 1376 PPP DNCP November 1992

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.

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

Senum [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1376.txt · Last modified: 1992/11/05 00:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki