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 + -
显示快捷键?