& & Network Working Group B. Parker Request for Comments: 1378 Cayman Systems November 1992 The PPP AppleTalk Control Protocol (ATCP) Status of this Memo This RFCspecifies an IAB standards track protocol for the Internet community, and request& & & & & & Network Working Group B. Parker& & Request for Comments: 1378 Cayman Systems& & November 1992& & The PPP AppleTalk Control Protocol (ATCP)& & Status of this Memo& & This RFCspecifies an IAB standards track protocol for the Internet& & community, and requests discussion and suggestions for improvements.& & Please refer to the current edition of the "IAB Official Protocol& & Standards" for the standardization state and status of this protocol.& & Distribution of this memo is unlimited.& & Abstract& & The Point-to-Point Protocol (PPP) [1] provides a standard method of& & encapsulating Network Layer protocol information over point-to-point& & links. PPP also defines an extensible Link Control Protocol, and& & proposes a family of Network Control Protocols (NCPs) for& & establishing and configuring different network-layer protocols.& & This document defines the NCP for establishing and configuring the& & AppleTalk Protocol [3] over PPP.& & This memo is a joint effort of the AppleTalk-IP Working Group and the& & Point-to-Point Protocol Working Group of the Internet Engineering& & Task Force (IETF). Comments on this memo should be submitted to the& & ietf-ppp@ucdavis.edumailing list.& & Table of Contents& & 1. Introduction .......................................... 2& & 2. A PPP Network Control Protocol (NCP) for AppleTalk .... 2& & 2.1 Sending AppleTalk Datagrams ........................... 3& & 2.2 Half-Routers .......................................... 4& & 3. ATCP Configuration Options ............................ 4& & 3.1 AppleTalk-Address ..................................... 5& & 3.2 Routing-Protocol ...................................... 7& & 3.3 Suppress-Broadcasts ................................... 8& & 3.4 AT-Compression-Protocol ............................... 9& & 3.5 Server-information .................................... 10& & 3.6 Zone-Information ...................................... 12& & 3.7 Default-Router-Address ................................ 13& & APPENDICES ................................................... 14& & A. ATCP Recommended Options .............................. 14& & REFERENCES ................................................... 15& & ACKNOWLEDGEMENTS ............................................. 15& & SECURITY CONSIDERATIONS ...................................... 16& & CHAIR'S ADDRESS .............................................. 16& & AUTHOR'S ADDRESS ............................................. 16& & 1. Introduction& & PPP has three main components:& & 1. A method for encapsulating datagrams over serial links.& & 2. A Link Control Protocol (LCP) for establishing, configuring,& & and testing the data-link connection.& & 3. A family of Network Control Protocols (NCPs) for establishing& & and configuring different network-layer protocols.& & In order to establish communications over a point-to-point link, each& & end of the PPP link must first send LCP packets to configure and test& & the data link. After the link has been established and optional& & facilities have been negotiated as needed by the LCP, PPP must send& & NCP packets to choose and configure one or more network-layer& & protocols. Once each of the chosen network-layer protocols has been& & configured, datagrams from each network-layer protocol can be sent& & over the link.& & The link will remain configured for communications until explicit LCP& & or NCP packets close the link down, or until some external event& & oclearcase/" target="_blank" >ccurs (an inactivity timer expires or network administrator& & intervention).& & 2. A PPP Network Control Protocol (NCP) for AppleTalk& & The AppleTalk Control Protocol (ATCP) is responsible for configuring,& & enabling, and disabling the AppleTalk protocol modules on both ends& & of the point-to-point link. ATCP uses the same packet exchange& & machanism as the Link Control Protocol (LCP). ATCP packets may not& & be exchanged until PPP has reached the Network-Layer Protocol phase.& & ATCP packets received before this phase is reached should be silently& & discarded.& & The AppleTalk Control Protocol is exactly the same as the Link& & Control Protocol [1] with the following exceptions:& & Frame. Modifications& & The packet may utilize any modifications to the basic frame. format& & which have been negotiated during the Link Establishment phase.& & Data Link Layer Protocol Field& & Exactly one ATCP packet is encapsulated in the Information field& & of a PPP Data Link Layer frame. where the Protocol field indicates& & type hex 8029 (AppleTalk Control Protocol).& & Code field& & Only Codes 1 through 7 (Configure-Request, Configure-Ack,& & Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack& & and Code-Reject) are used. Other Codes should be treated as& & unrecognized and should result in Code-Rejects.& & Timeouts& & ATCP packets may not be exchanged until PPP has reached the& & Network-Layer Protocol phase. An implementation should be& & prepared to wait for Authentication and Link Quality Determination& & to finish before timing out waiting for a Configure-Ack or other& & response. It is suggested that an implementation give up only& & after user intervention or a configurable amount of time.& & Configuration Option Types& & ATCP has a distinct set of Configuration Options, which are& & defined below.& & 2.1. Sending AppleTalk Datagrams& & Before any AppleTalk packets may be communicated, PPP must reach the& & Network-Layer Protocol phase, and the AppleTalk Control Protocol must& & reach the Opened state.& & Unless otherwise negotiated (via option 4), exactly one AppleTalk& & packet is encapsulated in the Information field of a PPP Data Link& & Layer frame. where the Protocol field indicates type hex 0029& & (AppleTalk).& & Note that the negotiation of compression may imply the use of& & different encapsulation and hence different protocol fields. These& & different protocol fields imply packet types which are sub-protocols& & of the base AppleTalk NCP.& & An encapsulated AppleTalk packet begins with an extended DDP& & (Datagram Delivery Protocol) header -- also known as a Long DDP& & header. The maximum length of a DDP datagram is 599 octets.& & Since there is no standard method for fragmenting and reassembling& & AppleTalk datagrams, it is required that PPP links supporting& & AppleTalk allow at least 599 octets in the information field of a& & data link layer frame.& & 2.2. Half-Routers& & One model for routers in [3] is two remote AppleTalk routers linked& & as "half-routers" without a Node ID or Network number assigned to& & either side of the link. When acting as half-routers, the only& & effect on transported packets is that the hop count is incremented& & when it is received over the link. Routing updates received over a& & half-router link should also increment the hop count of routing table& & updates.& & As part of normal operation, AppleTalk will send RTMP Routing updates& & every 10 seconds.& & 3. ATCP Configuration Options& & ATCP Configuration Options allow negotiation of desirable AppleTalk& & parameters. ATCP uses the same Configuration Option format defined& & for LCP [1], with a separate set of Options.& & The most up-to-date values of the ATCP Option Type field are& & specified in the most recent "Assigned Numbers" RFC[2]. Current& & values are assigned as follows:& & 1 AppleTalk-Address& & 2 Routing-Protocol& & 3 Suppress-Broadcasts& & 4 AT-Compression-Protocol& & 5 RESERVED& & 6 Server-information& & 7 Zone-information& & 8 Default-Router-Address& & 3.1. AppleTalk-Address& & Description& & This Configuration Option provides a way to negotiate the& & AppleTalk network and node number to be used on the local end of& & the link. It allows the sender of the Configure-Request to state& & which AppleTalk-address is desired, or to request that the peer& & provide the information. The peer can provide this information by& & NAKing the option, and returning a valid AppleTalk-address.& & If negotiation about the remote AppleTalk-address is required, and& & the peer did not provide the option in its Configure-Request, the& & option SHOULD be appended to a Configure-Nak. The value of the& & AppleTalk-address given must be acceptable as the remote& & AppleTalk-address, or indicate a request that the peer provide the& & information.& & By default, no AppleTalk address is assigned. A network or node& & number specified as zero in a Configure-Request shall be& & interpreted as requesting the remote end to specify a value via a& & Configure-Nak. A network or node number specified as zero in a& & Configure-Ack shall be interpreted as agreement that no value& & exists.& & An implementation which requires that no AppleTalk addresses be& & assigned (such as a intermediate system to intermediate system& & "half-routing") MUST Configure-Reject all AppleTalk-Address& & Configuration Options.& & An implementation which requires that AppleTalk addresses be& & assigned to it (such as a end system) MUST fail configuration if& & the remote side Configure-Rejects all AppleTalk-Address requests,& & or fails to provide a valid value.& & If this option is negotiated, the two sides MUST negotiate a& & common AppleTalk network number and two unique Appletalk node& & numbers. The network number MAY be zero but the Appletalk node& & numbers MUST be non-zero. Values selected for network and node& & numbers must adhere to the ranges defined in [3].& & The AppleTalk protocol, phase 2, defines the concept of "extended"& & and "non-extended" networks. Extended networks can support a& & large number (hundreds) of nodes, and requires multiple network& & numbers and multiple zone names to be managed effectively. Non-& & extended networks can only support a small number of devices, and& & require only a single network number and zone name to be managed& & effectively.& & If a PPP link transporting AppleTalk is assigned an AppleTalk& & address, it must have the "non-extended" characteristics as& & defined in [3].& & The format of the network and node data is defined to be the same& & as the "AppleTalk address" in [3], chapter 3, "AppleTalk AARP& & packet formats on Ethernet and token ring".& & A summary of the AppleTalk-Address 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 | Reserved | AT-Net |& & +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+& & | AT-Net | AT-Node |& & +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+& & Type& & 1& & 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 desired local AppleTalk network number& & of the sender of the Configure-Request. This two octet quantity& & represents a 16 bit unsigned number sent "network byte order"& & (most significant octet first).& & AT-Node& & The one octet AT-Node is the desired local AppleTalk node ID of& & the sender of the Configure-Request.& & 3.2. Routing-Protocol& & Description& & This Configuration Option provides a way to negotiate the use of a& & specific routing protocol. In particular, "half-routers" may want& & to exchange routing information using a protocol optimized for the& & PPP connection. By default, AppleTalk RTMP (Routing Table& & Maintenance Protocol) routing information is sent over the PPP& & connection.& & By default, AppleTalk RTMP routing information is sent over the& & PPP connection.& & A summary of the Routing-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 | Routing-Protocol |& & +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+& & | Data ...& & +-+-+-+-+& & Type& & 2& & Length& & >= 4& & Routing-Protocol& & The Routing-Protocol field is two octets and indicates the type of& & Routing-Protocol desired. This two octet quantity represents a 16& & bit number sent "network byte order" (most significant octet& & first).& & Negotiation of some routing protocols implies that you will& & receive packet types which transport these protocols.& & For example, negotiating AppleTalk AURP to exchange routing& & information implies both sides will accept EDDP type packets,& & since this is the transport type used by AURP.& & Initial values are assigned as follows:& & Value Protocol& & 0 No routing information exchange& & 1 AppleTalk RTMP is used to exchange routing information& & 2 AppleTalk AURP is used to exchange routing information& & 3 AppleTalk ABGP is used to exchange routing information& & Data& & The Data field is zero or more octets and contains additional data& & as determined by the routing protocol indicated in the Routing-& & Protocol field.& & None of the Routing-Protocol options defined here require& & additional data.& & 3.3. Suppress-Broadcasts& & Description& & This Configuration Option provides a way to negotiate the& & suppression of AppleTalk broadcast datagrams which might otherwise& & use up limitted PPP bandwidth. This Configuration Option is used& & to inform. the remote end that no AppleTalk broadcast datagrams of& & a given DDP type should be sent.& & This option is useful when negotiated by a single end system. It& & allows the local end system to request that broadcast packets& & generated on a remote network not be propagated across the PPP& & link. In the case of a single end system connected to a large& & network, this can be used to suppress regular NBP lookups& & generated by other end systems on the remote network. This will& & mean that protocols such as NBP can no longer be used to find& & network entities on the local system, but since the option& & configuration is asymmetric, it does not inhibit the local& & system's ability to find network entities on the remote network.& & By default, no AppleTalk broadcast datagrams are suppressed. Note& & that this option may conflict with other options (such as Routing& & Protocol). If so, the Suppress-Broadcasts option takes& & precedence.& & A summary of the Suppress-Broadcasts 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 | 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& & 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.& & 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& & 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.& & 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).& & 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)& & 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)",RFC1331,& & Daydreamer, May 1992.& & [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,RFC1340,& & 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 (), Network Systems Corporation& & Jim Muchow (muchow@), Network Systems Corporation& & Frank Slaughter (), Shiva Corporation& & 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: (916) 676-1147& & EMail:& & John Veizades& & Apple Computer, Inc.& & 20525 Mariani Avenue& & Cupertino, CA 95014& & Phone: (408) 996-1010& & EMail:& & Author's Address& & Questions about this memo can also be directed to:& & Brad Parker& & Cayman Systems, Inc.& & 26 Landsdowne Street& & Cambridge, Ma 02139& & EMail:& & 原文转自：http://www.ltesting.net
声明：该文章系网友上传分享，此内容仅代表网友个人经验或观点，不代表本网站立场和观点；若未进行原创声明，则表明该文章系转载自互联网；若该文章内容涉嫌侵权，请及时向
上一篇：下一篇：
相关经验教程
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.005 收益