home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1762 < prev    next >
Text File  |  1995-03-01  |  13KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           S. Senum
  8. Request for Comments: 1762                                     DigiBoard
  9. Obsoletes: 1376                                               March 1995
  10. Category: Standards Track
  11.  
  12.  
  13.             The PPP DECnet Phase IV Control Protocol (DNCP)
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    The Point-to-Point Protocol (PPP) [1] provides a standard method of
  26.    encapsulating Network Layer protocol information over point-to-point
  27.    links.  PPP also defines an extensible Link Control Protocol, and
  28.    proposes a family of Network Control Protocols (NCPs) for
  29.    establishing and configuring different network-layer protocols.
  30.  
  31.    This document defines the NCP for establishing and configuring
  32.    Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.
  33.    This document applies only to DNA Phase IV Routing messages (both
  34.    data and control), and not to other DNA Phase IV protocols (MOP, LAT,
  35.    etc).
  36.  
  37. 1.  Introduction
  38.  
  39.    There are two basic approaches to running the DNA Phase IV Routing
  40.    protocol over a serial line:
  41.  
  42.    1. The approach that several router vendors have taken which is to
  43.       treat the serial link as an Ethernet, using the same data and
  44.       control messages an Ethernet would use.
  45.  
  46.    2. The approach defined by Digital, which uses DDCMP and slightly
  47.       different control messages.
  48.  
  49.    This document will define a method that uses the first approach.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Senum                                                           [Page 1]
  59.  
  60. RFC 1762                        PPP DNCP                      March 1995
  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 is a value reserved for use
  89.          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 is
  94.          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.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Senum                                                           [Page 2]
  115.  
  116. RFC 1762                        PPP DNCP                      March 1995
  117.  
  118.  
  119.       o  DNA Load/Dump
  120.          The Digital Network Architecture (DNA) Load/Dump protocol is a
  121.          maintenance protocol for copying the contents of processor
  122.          memory to or from a remote system.  For example, a system
  123.          manager can load an operating system into an unattended, remote
  124.          system.  The complete definition of the Phase IV DNA Load/Dump
  125.          protocol can be found in [3].
  126.  
  127.       o  DNA Experimental Use
  128.          The Digital Network Architecture (DNA) Experimental Use
  129.          protocol allows Digital experimental protocols to share a data
  130.          link with other data link clients.  It is for use by Digital
  131.          Equipment Corporation only.
  132.  
  133.       o  DNA Communications Test
  134.          The Digital Network Architecture (DNA) Communications Test
  135.          protocol is a maintenance protocol for testing the data link
  136.          communications path.  The complete definition of the DNA
  137.          Communications Test protocol can be found in [3].
  138.  
  139.       o  Digital Protocol X1
  140.          The Digital X1 protocol is a network layer protocol currently
  141.          private to Digital.
  142.  
  143.    This document defines the NCP for establishing and configuring
  144.    Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.
  145.    This document applies only to DNA Phase IV Routing messages (both
  146.    data and control), and not to other DNA Phase IV protocols.
  147.  
  148. 3.  A PPP Network Control Protocol for DNA Phase IV Routing
  149.  
  150.    The DNA Phase IV Routing Control Protocol (DNCP) is responsible for
  151.    configuring, enabling, and disabling the DNA Phase IV Routing
  152.    protocol modules on both ends of the point-to-point link.  DNCP uses
  153.    the same packet exchange mechanism as the Link Control Protocol
  154.    (LCP).  DNCP packets may not be exchanged until PPP has reached the
  155.    Network-Layer Protocol phase.  DNCP packets received before this
  156.    phase is reached should be silently discarded.
  157.  
  158.    The DNA Phase IV Routing Control Protocol is exactly the same as the
  159.    Link Control Protocol [1] with the following exceptions:
  160.  
  161.    Frame Modifications
  162.  
  163.       The packet may utilize any modifications to the basic frame format
  164.       which have been negotiated during the Link Establishment phase.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Senum                                                           [Page 3]
  171.  
  172. RFC 1762                        PPP DNCP                      March 1995
  173.  
  174.  
  175.    Data Link Layer Protocol Field
  176.  
  177.       Exactly one DNCP packet is encapsulated in the Information field
  178.       of a PPP Data Link Layer frame where the Protocol field indicates
  179.       type hex 8027 (DNA Phase IV Control Protocol).
  180.  
  181.    Code field
  182.  
  183.       Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  184.       Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
  185.       and Code-Reject) are used.  Other Codes should be treated as
  186.       unrecognized and should result in Code-Rejects.
  187.  
  188.    Timeouts
  189.  
  190.       DNCP packets may not be exchanged until PPP has reached the
  191.       Network-Layer Protocol phase.  An implementation should be
  192.       prepared to wait for Authentication and Link Quality Determination
  193.       to finish before timing out waiting for a Configure-Ack or other
  194.       response.  It is suggested that an implementation give up only
  195.       after user intervention or a configurable amount of time.
  196.  
  197.    Configuration Option Types
  198.  
  199.       DNCP has no Configuration Options.
  200.  
  201. 4.  Sending DNA Phase IV Routing Packets
  202.  
  203.       Before any DNA Phase IV Routing packets may be communicated, PPP
  204.       must reach the Network-Layer Protocol phase, and the DNA Phase IV
  205.       Routing Control Protocol must reach the Opened state.
  206.  
  207.       Exactly one length field and one DNA Phase IV Routing packet are
  208.       encapsulated in the information field of a PPP Data Link Layer
  209.       frame where the Protocol field indicates type hex 0027 (DNA Phase
  210.       IV Routing).  The length field contains a count of the number of
  211.       octets in the DNA Phase IV Routing packet.  It is two octets in
  212.       length itself, and is stored in VAX byte ordering, to be more
  213.       consistent with DNA Phase IV Routing over Ethernet (i.e. least
  214.       significant byte first).  It is needed to disambiguate optional
  215.       padding octets from real information.
  216.  
  217.       The maximum length of a DNA Phase IV Routing packet transmitted
  218.       over a PPP link is the same as the maximum length of the
  219.       Information field of a PPP data link layer frame minus 2 octets
  220.       (for the Length field).
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Senum                                                           [Page 4]
  227.  
  228. RFC 1762                        PPP DNCP                      March 1995
  229.  
  230.  
  231.       The format of the packets themselves is the same as the format
  232.       used over Ethernet, without the Ethernet header, Pad, and FCS
  233.       fields.
  234.  
  235.       A summary of the information field is shown below.  The fields are
  236.       transmitted from left to right.
  237.  
  238.     0                   1                   2                   3
  239.     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
  240.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  241.    |   Length LSB  |   Length MSB  |      DATA     |      ...      |
  242.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  243.    |                              ...                              |
  244.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  245.  
  246.    Length LSB
  247.  
  248.       Least significant byte of length field
  249.  
  250.    Length MSG
  251.  
  252.       Most significant byte of length field
  253.  
  254.    DATA
  255.  
  256.       DNA Phase IV Routing data, as specified in [2]
  257.  
  258. 5.  General Considerations
  259.  
  260.    When a topology change in the network occurs, DNA Phase IV Routing
  261.    nodes immediately propagate changes via Level 1 and Level 2 Routing
  262.    messages, with a 1 second minimum delay between updates.  DNA Phase
  263.    IV Routing nodes also periodically retransmit the complete Level 1
  264.    and Level 2 distance vectors to guard against data corruption in host
  265.    memory, and (in the case of Ethernet) loss of packets due to media
  266.    errors.  Because Digital's serial links run a protocol that
  267.    guarantees delivery of packets (DDCMP), the recommended default
  268.    retransmit time is long (600 seconds), whereas for Ethernet, where
  269.    packet delivery is not guaranteed, the recommended default is short
  270.    (10 seconds), as documented in [2].  To achieve convergence of routes
  271.    within a satisfactory time, the interval between updates should be
  272.    based upon the error rate of underlying data link.  As such, it is
  273.    recommended that the time between routing updates be user
  274.    configurable per PPP interface.
  275.  
  276.    The Hello timer and Listen timer should be set according to the
  277.    recommendations for broadcast links (15 and 45 seconds,
  278.    respectively).
  279.  
  280.  
  281.  
  282. Senum                                                           [Page 5]
  283.  
  284. RFC 1762                        PPP DNCP                      March 1995
  285.  
  286.  
  287.    Routers MAY not send routing updates if the remote node connected via
  288.    the PPP link is an endnode.  Endnodes MUST discard all routing
  289.    updates received over a PPP link.  The type of a node (endnode versus
  290.    routing) can be determined from the hello messages received from it.
  291.  
  292. Security Considerations
  293.  
  294.    Security issues are not discussed in this memo.
  295.  
  296. References
  297.  
  298.    [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
  299.        1661, Daydreamer, July 1994.
  300.  
  301.    [2] Digital Equipment Corporation, "DNA Routing Layer Functional
  302.        Specification", Version 2.0.0, Order No. AA-X435A-TK.
  303.  
  304.    [3] Digital Equipment Corporation, "DNA Maintenance Operations
  305.        Functional Specification", Version 3.0.0, Order No.  AA-X436A-TK.
  306.  
  307. Acknowledgments
  308.  
  309.    Some of the text in this document is taken from previous documents
  310.    produced by the Point-to-Point Protocol Working Group of the Internet
  311.    Engineering Task Force (IETF).
  312.  
  313.    The author wishes to thank Jim Muchow (Network Systems Corporation),
  314.    and Arthur Harvey (Digital Equipment Corporation) for their input to
  315.    this memo.
  316.  
  317. Chair's Address
  318.  
  319.    The working group can be contacted via the current chair:
  320.  
  321.    Fred Baker
  322.    Senior Software Engineer
  323.    Cisco Systems
  324.    519 Lado Drive
  325.    Santa Barbara, California 93111
  326.  
  327.    Phone: (408) 526-4257
  328.    EMail: fred@cisco.com
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Senum                                                           [Page 6]
  339.  
  340. RFC 1762                        PPP DNCP                      March 1995
  341.  
  342.  
  343. Author's Address
  344.  
  345.    Questions about this memo can also be directed to the author:
  346.  
  347.    Steven J. Senum
  348.    DigiBoard
  349.    6400 Flying Cloud Drive
  350.    Eden Prairie, Minnesota 55344
  351.  
  352.    Phone: (612) 943-9020
  353.    EMail: sjs@digibd.com
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Senum                                                           [Page 7]
  395.  
  396.