home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1376 < prev    next >
Text File  |  1992-11-06  |  12KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           S. Senum
  8. Request for Comments: 1376                   Network Systems Corporation
  9.                                                            November 1992
  10.  
  11.  
  12.             The PPP DECnet Phase IV Control Protocol (DNCP)
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC specifies an IAB standards track protocol for the Internet
  17.    community, and requests discussion and suggestions for improvements.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    The Point-to-Point Protocol (PPP) [1] provides a standard method of
  25.    encapsulating Network Layer protocol information over point-to-point
  26.    links.  PPP also defines an extensible Link Control Protocol, and
  27.    proposes a family of Network Control Protocols (NCPs) for
  28.    establishing and configuring different network-layer protocols.
  29.  
  30.    This document defines the NCP for establishing and configuring
  31.    Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.
  32.    This document applies only to DNA Phase IV Routing messages (both
  33.    data and control), and not to other DNA Phase IV protocols (MOP, LAT,
  34.    etc.).
  35.  
  36. 1.  Introduction
  37.  
  38.    There are two basic approaches to running the DNA Phase IV Routing
  39.    protocol over a serial line:
  40.  
  41.    1. The approached that several router vendors have taken which is to
  42.       treat the serial link as an Ethernet, using the same data and
  43.       control messages an Ethernet would use.
  44.  
  45.    2. The approach defined by Digital, which uses DDCMP and slightly
  46.       different control messages.
  47.  
  48.    This document will define a method that uses the first approach.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Senum                                                           [Page 1]
  59.  
  60. RFC 1376                        PPP DNCP                   November 1992
  61.  
  62.  
  63. 2.  Overview Of Phase IV DNA Protocols
  64.  
  65.    The Phase IV DNA protocols which act as data link clients are:
  66.  
  67.       o  DNA Phase IV Routing
  68.          The Phase IV Digital Network Architecture (DNA) Routing
  69.          protocol is a network layer protocol providing services similar
  70.          to that of DoD IP.  It routes messages in Phase IV DECnet
  71.          networks and manages the packet flow.  The complete definition
  72.          of the DNA Phase IV Routing protocol can be found in [2].
  73.  
  74.       o  DNA System Console
  75.          The Digital Network Architecture (DNA) System Console protocol
  76.          is a maintenance protocol providing low level access to a
  77.          system for the functions of:
  78.  
  79.           .  Identify processor
  80.           .  Read data link counters
  81.           .  Boot system
  82.           .  Console carrier (a general purpose i/o channel)
  83.  
  84.          The complete definition of the DNA System Console protocol can
  85.          be found in [3].
  86.  
  87.       o  Digital Customer Use
  88.          The Digital Customer Use protocol type is a value reserved for
  89.          use by Digital customers.  It allocates a type for private use
  90.          which will not conflict with Digital or other vendor protocols.
  91.  
  92.       o  DNA Diagnostics
  93.          The Digital Network Architecture (DNA) Diagnostics protocol
  94.          type is reserved to allow diagnostic software communications in
  95.          parallel with other data link clients.
  96.  
  97.       o  DNA Naming Service (DNS)
  98.          The Digital Network Architecture Naming Service (DNS) provides
  99.          a distributed naming service.  It allows clients to register
  100.          named objects and to bind a set of attributes to the objects in
  101.          a distributed database.
  102.  
  103.       o  DNA Time Service (DTS)
  104.          The Digital Network Architecture Time Service (DTS) is a
  105.          protocol providing global clock synchronization in a
  106.          distributed environment.
  107.  
  108.       o  DNA Load/Dump
  109.          The Digital Network Architecture (DNA) Load/Dump protocol is a
  110.          maintenance protocol for copying the contents of processor
  111.  
  112.  
  113.  
  114. Senum                                                           [Page 2]
  115.  
  116. RFC 1376                        PPP DNCP                   November 1992
  117.  
  118.  
  119.          memory to or from a remote system.  For example, a system
  120.          manager can load an operating system into an unattended, remote
  121.          system.  The complete definition of the Phase IV DNA Load/Dump
  122.          protocol can be found in [3].
  123.  
  124.       o  DNA Experimental Use
  125.          The Digital Network Architecture (DNA) Experimental Use
  126.          protocol type allows Digital experimental protocols to share a
  127.          data link with other data link clients.  It is for use by
  128.          Digital Equipment Corporation only.
  129.  
  130.       o  DNA Communications Test
  131.          The Digital Network Architecture (DNA) Communications Test
  132.          protocol is a maintenance protocol for testing the data link
  133.          communications path.  The complete definition of the DNA
  134.          Communications Test protocol can be found in [3].
  135.  
  136.       o  Digital Protocol X1
  137.          The Digital X1 protocol is a network layer protocol currently
  138.          private to Digital.
  139.  
  140.    This document defines the NCP for establishing and configuring
  141.    Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.
  142.    This document applies only to DNA Phase IV Routing messages (both
  143.    data and control), and not to other DNA Phase IV protocols (MOP, LAT,
  144.    etc.).
  145.  
  146. 3.  A PPP Network Control Protocol for DNA Phase IV Routing
  147.  
  148.    The DNA Phase IV Routing Control Protocol (DNCP) is responsible for
  149.    configuring, enabling, and disabling the DNA Phase IV Routing
  150.    protocol modules on both ends of the point-to-point link.  DNCP uses
  151.    the same packet exchange mechanism as the Link Control Protocol
  152.    (LCP).  DNCP packets may not be exchanged until PPP has reached the
  153.    Network-Layer Protocol phase.  DNCP packets received before this
  154.    phase is reached should be silently discarded.
  155.  
  156.    The DNA Phase IV Routing Control Protocol is exactly the same as the
  157.    Link Control Protocol [1] with the following exceptions:
  158.  
  159.    Frame Modifications
  160.  
  161.       The packet may utilize any modifications to the basic frame format
  162.       which have been negotiated during the Link Establishment phase.
  163.  
  164.    Data Link Layer Protocol Field
  165.  
  166.       Exactly one DNCP packet is encapsulated in the Information field
  167.  
  168.  
  169.  
  170. Senum                                                           [Page 3]
  171.  
  172. RFC 1376                        PPP DNCP                   November 1992
  173.  
  174.  
  175.       of a PPP Data Link Layer frame where the Protocol field indicates
  176.       type hex 8027 (DNA Phase IV Control Protocol).
  177.  
  178.    Code field
  179.  
  180.       Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  181.       Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
  182.       and Code-Reject) are used.  Other Codes should be treated as
  183.       unrecognized and should result in Code-Rejects.
  184.  
  185.    Timeouts
  186.  
  187.       DNCP packets may not be exchanged until PPP has reached the
  188.       Network-Layer Protocol phase.  An implementation should be
  189.       prepared to wait for Authentication and Link Quality Determination
  190.       to finish before timing out waiting for a Configure-Ack or other
  191.       response.  It is suggested that an implementation give up only
  192.       after user intervention or a configurable amount of time.
  193.  
  194.    Configuration Option Types
  195.  
  196.       DNCP has no Configuration Options.
  197.  
  198. 4.  Sending DNA Phase IV Routing Packets
  199.  
  200.    Before any DNA Phase IV Routing packets may be communicated, PPP must
  201.    reach the Network-Layer Protocol phase, and the DNA Phase IV Routing
  202.    Control Protocol must reach the Opened state.
  203.  
  204.    Exactly one octet-count field and one DNA Phase IV Routing packet are
  205.    encapsulated in the information field of a PPP Data Link Layer frame
  206.    where the Protocol field indicates type hex 0027 (DNA Phase IV
  207.    Routing).  The octet-count contains a count of the number of octets
  208.    in the DNA Phase IV Routing packet.  It is two octets in length
  209.    itself, and is stored in VAX byte ordering, to be more consistent
  210.    with DNA Phase IV Routing over Ethernet (i.e. least significant byte
  211.    first).  It is needed to disambiguate optional padding octets from
  212.    real information.
  213.  
  214.    The maximum length of an DNA Phase IV Routing packet transmitted over
  215.    a PPP link is the same as the maximum length of the Information field
  216.    of a PPP data link layer frame minus 2 octets (for the Length field).
  217.  
  218.    The format of the packets themselves is the same as the format used
  219.    over Ethernet, without the Ethernet header, Pad, and FCS fields.
  220.  
  221.    A summary of the information field is shown below.  The fields are
  222.    transmitted from left to right.
  223.  
  224.  
  225.  
  226. Senum                                                           [Page 4]
  227.  
  228. RFC 1376                        PPP DNCP                   November 1992
  229.  
  230.  
  231.     0                   1                   2                   3
  232.     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
  233.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  234.    |   Length LSB  |   Length MSB  |      DATA     |      ...      |
  235.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  236.    |                              ...                              |
  237.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  238.  
  239.    Length LSB
  240.  
  241.       Least significant byte of length field
  242.  
  243.    Length MSG
  244.  
  245.       Most significant byte of length field
  246.  
  247.    DATA
  248.  
  249.       DNA Phase IV Routing data, as specified in [2]
  250.  
  251. 5.  General Considerations
  252.  
  253.    When a topology change in the network occurs, DNA Phase IV Routing
  254.    nodes immediately propagate changes via Level 1 and Level 2 Routing
  255.    messages, with a 1 second minimum delay between updates.  DNA Phase
  256.    IV Routing nodes also periodically retransmit the complete Level 1
  257.    and Level 2 distance vectors to guard against data corruption in host
  258.    memory, and (in the case of Ethernet) loss of packets due to media
  259.    errors.  Because Digital's serial links run a protocol that
  260.    guarantees delivery of packets (DDCMP), the recommended default
  261.    retransmit time is long (600 seconds), whereas for Ethernet, where
  262.    packet delivery is not guaranteed, the recommended default is short
  263.    (10 seconds), as documented in [2].  To achieve convergence of routes
  264.    within a satisfactory time, the interval between updates should be
  265.    based upon the error rate of underlying data link.  As such, it is
  266.    recommended that the time between routing updates be user
  267.    configurable per PPP interface.
  268.  
  269.    The Hello timer and Listen timer should be set according to the
  270.    recommendations for broadcast links (15 and 45 seconds,
  271.    respectively).
  272.  
  273.    Routers are not required to send routing updates if the remote node
  274.    connected via the PPP link is an endnode.  Endnodes are required to
  275.    discard all routing updates received over a PPP link.  The type of a
  276.    node (endnode versus routing) can be determined from the hello
  277.    messages received from it.
  278.  
  279.  
  280.  
  281.  
  282. Senum                                                           [Page 5]
  283.  
  284. RFC 1376                        PPP DNCP                   November 1992
  285.  
  286.  
  287. References
  288.  
  289.    [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
  290.        Daydreamer, May 1992.
  291.  
  292.    [2] Digital Equipment Corporation, "DNA Routing Layer Functional
  293.        Specification", Version 2.0.0, Order No. AA-X435A-TK.
  294.  
  295.    [3] Digital Equipment Corporation, "DNA Maintenance Operations
  296.        Functional Specification", Version 3.0.0, Order No.  AA-X436A-TK.
  297.  
  298. Acknowledgments
  299.  
  300.    Some of the text in this document is taken from previous documents
  301.    produced by the Point-to-Point Protocol Working Group of the Internet
  302.    Engineering Task Force (IETF).
  303.  
  304.    The author wishes to thank Jim Muchow (Network Systems Corporation),
  305.    and Arthur Harvey (Digital Equipment Corporation) for their input to
  306.    this memo.
  307.  
  308. Security Considerations
  309.  
  310.    Security issues are not discussed in this memo.
  311.  
  312. Chair's Address
  313.  
  314.    The working group can be contacted via the current chair:
  315.  
  316.    Brian Lloyd
  317.    Lloyd & Associates
  318.    3420 Sudbury Road
  319.    Cameron Park, California 95682
  320.  
  321.    Phone: (916) 676-1147
  322.    EMail: brian@lloyd.com
  323.  
  324. Author's Address
  325.  
  326.    Questions about this memo can also be directed to the author:
  327.  
  328.    Steven J. Senum
  329.    Network Systems Corporation
  330.    7600 Boone Avenue North
  331.    Minneapolis, Minnesota 55428
  332.  
  333.    Phone: (612) 424-4888
  334.    EMail: sjs@network.com
  335.  
  336.  
  337.  
  338. Senum                                                           [Page 6]
  339.  
  340.