rfc1378.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 899 行 · 第 1/2 页

TXT
899
字号
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      4Parker                                                          [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 routerParker                                                         [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 19923.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 1992Intermediate 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 (sjs@network.com), Network Systems Corporation   Jim Muchow (muchow@anubis.network.com), Network Systems Corporation   Frank Slaughter (fgs@Shiva.COM), Shiva CorporationParker                                                         [Page 15]RFC 1378                        PPP ATCP                   November 1992Security 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: (916) 676-1147   EMail: brian@lloyd.com   John Veizades   Apple Computer, Inc.   20525 Mariani Avenue   Cupertino, CA 95014   Phone: (408) 996-1010   EMail: veizades@apple.comAuthor's Address   Questions about this memo can also be directed to:   Brad Parker   Cayman Systems, Inc.   26 Landsdowne Street   Cambridge, Ma 02139   EMail: brad@cayman.comParker                                                         [Page 16]

⌨️ 快捷键说明

复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?