rfc1378.txt

RFC 的详细文档！


RFC 1378                        PPP ATCP                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  DDP-Type  1  |  DDP-Type  2  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | etc...
   +-+-+-+-+


   Type

      3

   Length

      >= 2

   DDP-Types

      A vector of one or more single octet DDP type values, each of
      which are to be suppressed if sent to the broadcast address.

      If no data is present (the length = 2), all broadcast packets are
      to be suppressed, regardless of DDP type.

3.4.  AT-Compression-Protocol

   Description

      This Configuration Option provides a way to negotiate the use of a
      specific compression protocol.  By default, compression is not
      enabled.

   A summary of the AT-Compression-Protocol 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     |   AT-Compression-Protocol     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+


   Type

      4



Parker                                                          [Page 9]

RFC 1378                        PPP ATCP                   November 1992


   Length

      >= 4

   AT-Compression-Protocol

      The AT-Compression-Protocol field is two octets and indicates the
      compression protocol desired.  Values for this field are always
      the same as the PPP Data Link Layer Protocol field values for that
      same compression protocol.

      The most up-to-date values of the AT-Compression-Protocol field
      are specified in the most recent "Assigned Numbers" RFC [2].
      Current values are assigned as follows:


         Value (in hex)          Protocol

                                 none defined


   Data

      The Data field is zero or more octets and contains additional data
      as determined by the particular compression protocol.

3.5.  Server-information

   Description

      This Configuration Option provides a way to obtain information
      about the communications server providing the remote side of the
      PPP connection.

      The nature of this option is advisory only.  It is provided as a
      means of improving an end system's ability to provide a simple
      user interface.

   A summary of the Server-Information Option format is shown below.
   The fields are transmitted from left to right.











Parker                                                         [Page 10]

RFC 1378                        PPP ATCP                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |          Server-class         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Server-implementation-id                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Server-name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      6

   Length

      >= 8

   Server-class

      The Server-class field is two octets and indicates the class of
      the communication server providing the remote end of the PPP
      connection.

      Initial values are assigned as follows:

      Value        Class

        1          AppleTalk PPP Dial-in server.

                   The server-implementation-id is a four byte version
                   id, with the first byte defined as the major
                   version number (1-255) and the second byte defined
                   as the minor version number (1-255).

                   The third and fourth bytes are undefined and should
                   be zero.

        2          Generic AppleTalk PPP implementation.

                   The server-implementation-id is undefined and
                   vendor specific.

        3          Both dial-in server and router






Parker                                                         [Page 11]

RFC 1378                        PPP ATCP                   November 1992


   Server-implementation-id

      The Server-implementation-id field is four octets and indicates
      the version of the communication server providing the remote end
      of the PPP connection.

   Server-name

      This optional field contains the "AppleTalk ASCII" name of the
      server.  The character codes used in "AppleTalk ASCII" are defined
      in [3], appendix D, "Character codes".  The length of the name is
      bounded by the option length.

3.6.  Zone-Information

   Description

      This Configuration Option provides a way to obtain information
      about the AppleTalk zone used for the PPP connection.

      The nature of this option is advisory only.  It is provided as a
      means of improving the end system's ability to provide a simple
      user interface.

   A summary of the Zone-Information 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     |           Zone-name...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      7

   Length

      >= 3

   Zone-name

      This field contains the "AppleTalk ASCII" zone name in which the
      server resides.  The character codes used in "AppleTalk ASCII" are
      defined in [3], appendix D, "Character codes".  The length of the
      name is bounded by the option length.



Parker                                                         [Page 12]

RFC 1378                        PPP ATCP                   November 1992


3.7.  Default-Router-Address

   Description


      This Configuration Option provides a way to obtain information
      about a "default" Appletalk router which may be used to obtain
      network information such as zone names.  It is provided as a means
      of obtaining the address of a router in the case both sides of the
      link are end systems.

      Any AppleTalk RTMP packets received should supercede information
      negotiated in this option.

      By default, no default router is present.

   A summary of the Default-Router-Address 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     |    Reserved   |     AT-Net    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     AT-Net    |    AT-Node    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      8

   Length

      6

   Reserved

      This octet is reserved and MUST be set to zero on transmission and
      ignored on reception.

   AT-Net

      The two octet AT-Net is the AppleTalk network number of the
      default router.  This two octet quantity represents a 16 bit
      unsigned number sent in "network byte order" (most significant
      octet first).




Parker                                                         [Page 13]

RFC 1378                        PPP ATCP                   November 1992


   AT-Node

      The one octet AT-Node is the AppleTalk node ID of the default
      router.

A.  ATCP Recommended Options

   The ATCP is designed to support three different modes of operation.
   Each mode places constraints on the configuration options used and
   the values negotiated.

   The options for server information, zone information and default
   router address are "informational" options provided by one end of the
   connection and are not intended to be negotiated.  These options are
   provided to support a higher level of service to dial-in end systems.

   The options which SHOULD be negotiated in each case are outlined
   below.  Any option not listed may be rejected.

End System to Intermediate System - "dial-in"

   This mode of operation is intended to support end system dial-in.

         1       AppleTalk-Address (required)
         2       Routing-Protocol (required, no routing protocol)
         3       Suppress-Broadcasts (optional)
         4       AT-Compression-Protocol (optional)
         6       Server-information (optional, request from end system)























Parker                                                         [Page 14]

RFC 1378                        PPP ATCP                   November 1992


Intermediate system to Intermediate system - with network number

   This mode of operation is intended to support WAN-to-WAN, i.e.,
   router to router, connections where the link is configured with a
   network number.

         1      AppleTalk-Address (required, nets must be zero or equal)
         2      Routing-Protocol (optional)
         3      Suppress-Broadcasts (optional)

Intermediate system to Intermediate system - without network number

   This mode of operation is intended to support WAN-to-WAN, i.e.,
   router to router, connections where the link is not configured with a
   network number.  Routers in this mode are referred to as "half-
   routers" in [3].

         1      AppleTalk-Address (optional, nets & nodes MUST be zero)
         2      Routing-Protocol (optional)
         3      Suppress-Broadcasts (optional, suppress all broadcasts)

References

   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
       Daydreamer, May 1992.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

   [3] Sidhu G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk,
       Second Edition", Addison-Wesley Publishing Company, Inc., May
       1990.

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

   This document is derivative of drafts written by the following
   people.  Many thanks for their work, and for taking an initial stab
   at the protocol:

   Steve Senum ([e-mail]), Network Systems Corporation
   Jim Muchow ([e-mail]), Network Systems Corporation
   Frank Slaughter ([e-mail]), Shiva Corporation





Parker                                                         [Page 15]

RFC 1378                        PPP ATCP                   November 1992


Security Considerations

   Security issues are not discussed in this memo.

Chair's Address

   The working groups can be contacted via the current chairs:

   Brian Lloyd
   Lloyd & Associates
   3420 Sudbury Road
   Cameron Park, California 95682

   Phone: [phone]
   EMail: [e-mail]


   John Veizades
   Apple Computer, Inc.
   20525 Mariani Avenue
   Cupertino, CA 95014

   Phone: [phone]
   EMail: [e-mail]

Author's Address

   Questions about this memo can also be directed to:

   Brad Parker
   Cayman Systems, Inc.
   26 Landsdowne Street
   Cambridge, Ma 02139

   EMail: [e-mail]
















Parker                                                         [Page 16]