rfc2299.Request for Comments Summary RFC Numbers 2200-2299

SIPReasonHeaderSIP Reason HeaderOverviewThe Reason Header field for SIP is included in each of the following messages. (ITU-T Recommendation Q.850) ?BYECANCEL4xx, 5xx, and 6xx messagesUp till software 10.3.3 the IMG had the ability to propagate the Reason Header in each of the above messages from the TDM leg of the call to the SIP leg of the call. The Reason Header would indicate why a SIP request or response was issued. In software 10.5.0 the ability to propagate the Reason Header from the SIP leg of a call to the TDM side of the call was added. The Reason Header Field in each of the SIP messages is used primarily for debugging problems in a circuit. Clients and servers are free to ignore this header field as it has no impact on protocol processing. The Reason Header Field satisfies RFC 3326. The Reason Header field now gives the customer the ability to propagate cause code information from SIP to TDM and TDM to SIP without having to configure SIP-T.Call TracingSupport Personnel can enable Call Tracing on the IMG. Once this is accomplished all Reason Header information will be printed out for the following messages:BYECANCEL4xx, 5xx, and 6xx messagesNote: In case of multiple Reason Headers presented in the incoming SIP message, only the first Reason Header is decoded.Benefits:This feature is useful for debugging purpose, particularly if there is a call failure in SIP to SS7 traffic. Below are Call Flows and their corresponding Call Traces. Note that for reference the Reason Header field is shown in red.Implementation (Message propagates from TDM to SIP)CASE #1:Cause Number 1 (404 message)A call is generated from the SIP side to the IMG. The IMG then converts to an SS7 network and receives the IAM message. The SS7 leg sends a release with cause code of 1 (Unallocated Number). The IMG then would send a SIP 404 message with the cause code in the Reason Header indicating the problem is an Unallocated (unassigned) number. See Call Flow and Call Trace belowCall FlowCall Trace<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]SIP/2.0 404 Not Found Call processing releasedVia: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-672bb759901c9e2a-1--d87543-; rport;received=10.129.39.1 23Contact:Call-ID: 2b61265d2e589e06ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.From: "Boston";tag=f818c458To: "508";tag=a94c095b773be1dd6e8d668a785a9c8449dcCSeq: 1 INVITEServer: Cantata-SIP/10.3.2.22 Boston 0Reason: Q.850 ;cause=1 ; text="Unallocated (unassigned) number"Content-Length: 0CASE #2:Cause Number 17 (486 message)A call is generated from the SIP side to the IMG. The IMG then converts to an SS7 network and receives the IAM message. The SS7 leg sends a release with cause code of 17 (User Busy). The IMG then would send a SIP 486 message with the cause code in the Reason Header indicating the problem is User Busy. See Call Flow and Call Trace below Call FlowCall Trace<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]SIP/2.0 486 Busy Here Call processing releasedVia: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-af44ae69a320e04a-1--d87543-; rport;received=10.129.39.1 23Contact:Call-ID: 1c214262d2299f3cZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.From: "Boston";tag=244d4425To: "508";tag=a94c095b773be1dd6e8d668a785a9c84c527CSeq: 1 INVITEServer: Cantata-SIP/10.3.2.22 Boston 0Reason: Q.850 ;cause=17 ; text="User busy"Content-Length: 0CASE #3Cause Number 16 (BYE message)A call is generated from the SS7 side to the IMG. The IMG then converts to a SIP network and receives the INVITE message. The SIP side then sends a 180 ringing response. The SIP side then sends a 200 OK message and the call gets connected. After a while the phone is hung up and the SS7 leg sends a RELEASE with cause code of 16 (Normal Clearing). The IMG then would send a SIP BYE message with the cause code in the Reason Header indicating the problem is a Normal Clearing. See Call Flow and Call Trace belowCall FlowCall Trace<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]BYEsip:***********.39.123:5060SIP/2.0Via:SIP/2.0/UDP10.129.39.59:5060;rport;branch=z9hG4bK-3a95-46623-19995-361Call-ID:***********************************.39.59CSeq: 2 BYEMax-Forwards: 70To: ;tag=8262313bFrom: ;tag=95ffcd055e0f78f7d5d397020e89288d2b07User-Agent: Cantata-SIP/10.3.2.22 Boston 0Reason: Q.850 ;cause=16 ; text="Normal call clearing"Content-Length: 0CASE #4:Cause Number 3 (404 message)If the user dials an incorrect number that is not in the route table the IMG will reject the call and send a 404 Not Found to the SIP side.Call FlowCall Trace<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]SIP/2.0 404 Not Found Call processing releasedVia: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-47486a49a1277175-1--d87543-; rport;received=10.129.39.123Contact:Call-ID: 3355d752f5739754ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.From: "Boston";tag=2816b75aTo: "999";tag=a94c095b773be1dd6e8d668a785a9c84de15CSeq: 1 INVITEServer: Cantata-SIP/10.3.2.37 Boston 0Reason: Q.850 ;cause=3 ; text="No route to destination"Content-Length: 0CASE #5:Cause Number 1 (404 message)In case the user dials correct number but incoming translation table has wrong number, then IMG would reject the call and send a 404 Not Found to the SIP side.Call FlowCall Trace<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]SIP/2.0 404 Not Found Call processing releasedVia: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-47486a49a1277175-1--d87543-; rport;received=10.129.39.123Contact:Call-ID: 3355d752f5739754ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.From: "Boston";tag=2816b75aTo: "999";tag=a94c095b773be1dd6e8d668a785a9c84de15CSeq: 1 INVITEServer: Cantata-SIP/10.3.2.37 Boston 0Reason: Q.850 ;cause=1 ; text="Unallocated (unassigned) number"Content-Length: 0Implementation (Message propagates from SIP to SIP)CASE #1:SIP to SIPIn the case of SIP to SIP traffic, the Reason header field is usually not needed in responses because the status code and the reason phrase already provide sufficient information,according to RFC 3326. However, the Reason Header is included for BYE, 4xx, 5xx, and 6xx. Please note that CANCEL message in the SIP to SIP traffic does not include the Reason header field.Call FlowCall Trace<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]BYEsip:***********.39.123:5060SIP/2.0Via:SIP/2.0/UDP10.129.39.59:5060;rport;branch=z9hG4bK-2701-1786-19997-394Call-ID:************************************.39.59CSeq: 2 BYEMax-Forwards: 70To: ;tag=d47d7510From: ;tag=95ffcd055e0f78f7d5d397020e89288d708eUser-Agent: Cantata-SIP/10.3.2.37 Boston 0Reason: SIP ;cause=16 ; text="Normal call clearing"Content-Length: 0CASE #2:487 MessageIn the case below, where SIP sends an INVITE message and then sends CANCEL, the IMG sends a 487 Request Terminated in response to the CANCEL message.Call FlowCall Trace<--- [10.129.39.123, 5070 <- 10.129.39.59, 5060]SIP/2.0 487 Request TerminatedVia: SIP/2.0/UDP10.129.39.123:5070;branch=z9hG4bK-675e-1160585843-19988-10-129-39-123;received=10.129.39.123 Contact:Call-ID:*************.39.123From: sipp ;tag=1To: sut ;tag=a94c095b773be1dd6e8d668a785a9c84e50dCSeq: 1 INVITEServer: Cantata-SIP/10.3.2.37 Boston 0Reason: SIP ;cause=487 ; text="Request Terminated"Content-Length: 0Implementation (Message propagates from SIP to TDM)CASE #1:Cause NumberA call is generated from SS7 protocol and sent to the IMG. IMG1 converts from SS7 to SIP. Call is then sent to IMG2 where it converts the SIP messaging back to SS7 and the call goes out of IMG2 using SS7 protocol. The call is then release by hanging phone up or any such normal call release scenario. Note the RELEASE message has the reason header information. Below is Call Flow.Call Trace<--- [10.129.45.107, 5060 <- 10.129.45.104, 5060]BYEsip:*****************.45.107:5060SIP/2.0\r\nVia: SIP/2.0/UDP 10.129.45.104:5060;rport;branch=z9hG4bK-149e-1196263031-19999-118\r\nCall-ID:***************************************.45.104\r\nCSeq: 2 BYE\r\nMax-Forwards: 0\r\nTo: ;tag=a94c095b773be1dd6e8d668a785a9c84089db2cd\r\n From: ;tag=95ffcd055e0f78f7d5d397020e89288d4e3f1b4c\r\nUser-Agent: Cantata-SIP/10.5.0.143 Boston 0\r\nReason: Q.850 ;cause=31 ;text="Normal, unspecified"\r\nContent-Length: 0\r\n\r\n。

Network Working Group R. DromsRequest for Comments: 2131 Bucknell UniversityObsoletes: 1541 March 1997Category: Standards TrackDynamic Host Configuration ProtocolStatus of this memoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.AbstractThe Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding thecapability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9].Table of Contents1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 62. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Configuration parameters repository . . . . . . . . . . . . . 112.2 Dynamic allocation of network addresses . . . . . . . . . . .123. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13 3.1 Client-server interaction - allocating a network address. . . 13 3.2 Client-server interaction - reusing a previously allocatednetwork address . . . . . . . . . . . . . . . . . . . . . . . 173.3 Interpretation and representation of time values. . . . . . . 20 3.4 Obtaining parameters with externally configured networkaddress . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 223.7 When clients should use DHCP. . . . . . . . . . . . . . . . .224. Specification of the DHCP client-server protocol. . . . . . . 22Droms Standards Track [Page 1]RFC 2131 Dynamic Host Configuration Protocol March 19974.1 Constructing and sending DHCP messages. . . . . . . . . . . .22 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 264.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . .345. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .426. References . . . . . . . . . . . . . . . . . . . . . . . . . .427. Security Considerations. . . . . . . . . . . . . . . . . . . .438. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44A. Host Configuration Parameters . . . . . . . . . . . . . . . .45 List of Figures1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 92. Format of the 'flags' field. . . . . . . . . . . . . . . . . .113. Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network address. . . . . . . . . 154. Timeline diagram of messages exchanged between DHCP client and servers when reusing a previously allocated network address. . 185. State-transition diagram for DHCP clients. . . . . . . . . . .34 List of Tables1. Description of fields in a DHCP message. . . . . . . . . . . .102. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . .143. Fields and options used by DHCP servers. . . . . . . . . . . .284. Client messages from various states. . . . . . . . . . . . . .335. Fields and options used by DHCP clients. . . . . . . . . . . .37 1. IntroductionThe Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from aDHCP server to a host and a mechanism for allocation of networkaddresses to hosts.DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. Throughout the remainder of this document, the term "server" refers to a host providinginitialization parameters through DHCP, and the term "client" refers to a hostrequesting initialization parameters from a DHCP server.A host should not act as a DHCP server unless explicitly configured to do so by a system administrator. The diversity of hardware and protocol implementations in the Internet would preclude reliable operation if random hosts were allowed to respond to DHCP requests. For example, IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed or assumed to have correct defaults. Also,distributed address allocation schemes depend on a polling/defenseDroms Standards Track [Page 2]RFC 2131 Dynamic Host Configuration Protocol March 1997mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot beguaranteed to avoid allocation of duplicate network addresses.DHCP supports three mechanisms for IP address allocation. In"automatic allocation", DHCP assigns a permanent IP address to aclient. In "dynamic allocation", DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). In "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.Dynamic allocation is the only one of the three mechanisms thatallows automatic reuse of an address that is no longer needed by the client to which it was assigned. Thus, dynamic allocation isparticularly useful for assigning an address to a client that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of clients that do not needpermanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new client being permanentlyconnected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old clients are retired. Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses inenvironments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.The format of DHCP messages is based on the format of BOOTP messages, to capture the BOOTP relay agent behavior described as part of the BOOTP specification [7, 21] and to allow interoperability ofexisting BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates the necessity of having a DHCP server on each physical networksegment.1.1 Changes to RFC 1541This document updates the DHCP protocol specification that appears in RFC1541. A new DHCP message type, DHCPINFORM, has been added; see section 3.4, 4.3 and 4.4 for details. The classing mechanism for identifying DHCP clients to DHCP servers has been extended to include "vendor" classes as defined in sections 4.2 and 4.3. The minimum lease time restriction has been removed. Finally, many editorial changes have been made to clarify the text as a result of experience gained in DHCP interoperability tests.Droms Standards Track [Page 3]RFC 2131 Dynamic Host Configuration Protocol March 19971.2 Related WorkThere are several Internet protocols and related mechanisms that address some parts of the dynamic host configuration problem. The Reverse Address Resolution Protocol (RARP) [10] (through theextensions defined in the Dynamic RARP (DRARP) [5]) explicitlyaddresses the problem of network address discovery, and includes an automatic IP address assignment mechanism. The Trivial File Transfer Protocol (TFTP) [20] provides for transport of a boot image from a boot server. The Internet Control Message Protocol (ICMP) [16]provides for informing hosts of additional routers via "ICMPredirect" messages. ICMP also can provide subnet mask information through the "ICMP mask request" message and other information through the (obsolete) "ICMP information request" message. Hosts can locate routers through the ICMP router discovery mechanism [8].BOOTP is a transport mechanism for a collection of configuration information. BOOTP is also extensible, and official extensions [17] have been defined for several configuration parameters. Morgan has proposed extensions to BOOTP for dynamic IP address assignment [15]. The Network Information Protocol (NIP), used by the Athena project at MIT, is a distributed mechanism for dynamic IP address assignment [19]. The Resource Location Protocol RLP [1] provides for location of higher level services. Sun Microsystems diskless workstations use a boot procedure that employs RARP, TFTP and an RPC mechanism called "bootparams" to deliver configuration information and operatingsystem code to diskless hosts. (Sun Microsystems, Sun Workstation and SunOS are trademarks of Sun Microsystems, Inc.) Some Sunnetworks also use DRARP and an auto-installation mechanism toautomate the configuration of new hosts in an existing network.In other related work, the path minimum transmission unit (MTU)discovery algorithm can determine the MTU of an arbitrary internet path [14]. The Address Resolution Protocol (ARP) has been proposed as a transport protocol for resource location and selection [6]. Finally, the Host Requirements RFCs [3, 4] mention specificrequirements for host reconfiguration and suggest a scenario for继续阅读。

nssa no-summary 与nssa 的区别-回复标题：NSSA与NSSA noSummary的区别详解在Cisco路由器的OSPF（开放最短路径优先）协议中，NSSA（非完全stub 区域）和NSSA noSummary是两种特殊类型的区域配置。

虽然它们在名称上相似，但在功能和应用上存在一些关键的区别。

以下将详细解析这两种配置的区别。

一、NSSA的基本理解NSSA是一种特殊的stub区域，它允许区域内引入外部路由，但这些外部路由只能以类型7的LSA（链路状态公告）形式存在于区域内，不能被转换为类型5的LSA传播到其他区域。

这意味着，NSSA区域可以接收来自其他区域的路由信息，但不能将这些信息传递给其他区域，除非这些路由是通过区域内的一台ASBR（自治系统边界路由器）引入的。

二、NSSA noSummary的理解NSSA noSummary是NSSA的一种扩展配置，它在NSSA的基础上增加了一个限制：禁止区域间的汇总路由（Type 3 LSA）在NSSA区域内传播。

也就是说，NSSA noSummary区域不仅不允许外部路由以Type 5 LSA 的形式传播出去，也不允许区域间的汇总路由在区域内传播。

三、NSSA与NSSA noSummary的区别1. 外部路由的处理：在NSSA区域中，外部路由可以被引入并以Type 7 LSA的形式在区域内传播，但不能转换为Type 5 LSA传播到其他区域。

而在NSSA noSummary区域中，外部路由的处理方式与NSSA区域相同。

2. 区域间汇总路由的处理：这是NSSA与NSSA noSummary的主要区别。

在NSSA区域中，区域间的汇总路由（Type 3 LSA）是可以正常传播的。

然而，在NSSA noSummary区域中，这种类型的路由被禁止传播。

这个特性在某些情况下非常有用。

例如，如果一个大型网络被划分为多个NSSA区域，而你希望每个区域只了解其自身所需的路由信息，而不希望看到其他区域的汇总路由，那么就可以使用NSSA noSummary配置。

Network Working Group W. Townsley Request for Comments: 2661 A. Valencia Category: Standards Track cisco Systems A. Rubens Ascend Communications G. Pall G. Zorn Microsoft Corporation B. Palter Redback Networks August 1999 Layer Two Tunneling Protocol "L2TP"Status of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (1999). All Rights Reserved.AbstractThis document describes the Layer Two Tunneling Protocol (L2TP). STD 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an interveningnetwork in a way that is as transparent as possible to both end-users and applications.Table of Contents1.0 Introduction (3)1.1 Specification of Requirements (4)1.2 Terminology (4)2.0 Topology (8)3.0 Protocol Overview (9)3.1 L2TP Header Format (9)3.2 Control Message Types (11)4.0 Control Message Attribute Value Pairs (12)4.1 AVP Format (13)4.2 Mandatory AVPs (14)4.3 Hiding of AVP Attribute Values (14)Townsley, et al. Standards Track [Page 1]4.4.1 AVPs Applicable To All Control Messages (17)4.4.2 Result and Error Codes (18)4.4.3 Control Connection Management AVPs (20)4.4.4 Call Management AVPs (27)4.4.5 Proxy LCP and Authentication AVPs (34)4.4.6 Call Status AVPs (39)5.0 Protocol Operation (41)5.1 Control Connection Establishment (41)5.1.1 Tunnel Authentication (42)5.2 Session Establishment (42)5.2.1 Incoming Call Establishment (42)5.2.2 Outgoing Call Establishment (43)5.3 Forwarding PPP Frames (43)5.4 Using Sequence Numbers on the Data Channel (44)5.5 Keepalive (Hello) (44)5.6 Session Teardown (45)5.7 Control Connection Teardown (45)5.8 Reliable Delivery of Control Messages (46)6.0 Control Connection Protocol Specification (48)6.1 Start-Control-Connection-Request (SCCRQ) (48)6.2 Start-Control-Connection-Reply (SCCRP) (48)6.3 Start-Control-Connection-Connected (SCCCN) (49)6.4 Stop-Control-Connection-Notification (StopCCN) (49)6.5 Hello (HELLO) (49)6.6 Incoming-Call-Request (ICRQ) (50)6.7 Incoming-Call-Reply (ICRP) (51)6.8 Incoming-Call-Connected (ICCN) (51)6.9 Outgoing-Call-Request (OCRQ) (52)6.10 Outgoing-Call-Reply (OCRP) (53)6.11 Outgoing-Call-Connected (OCCN) (53)6.12 Call-Disconnect-Notify (CDN) (53)6.13 WAN-Error-Notify (WEN) (54)6.14 Set-Link-Info (SLI) (54)7.0 Control Connection State Machines (54)7.1 Control Connection Protocol Operation (55)7.2 Control Connection States (56)7.2.1 Control Connection Establishment (56)7.3 Timing considerations (58)7.4 Incoming calls (58)7.4.1 LAC Incoming Call States (60)7.4.2 LNS Incoming Call States (62)7.5 Outgoing calls (63)7.5.1 LAC Outgoing Call States (64)7.5.2 LNS Outgoing Call States (66)7.6 Tunnel Disconnection (67)8.0 L2TP Over Specific Media (67)8.1 L2TP over UDP/IP (68)Townsley, et al. Standards Track [Page 2]9.0 Security Considerations (69)9.1 Tunnel Endpoint Security (70)9.2 Packet Level Security (70)9.3 End to End Security (70)9.4 L2TP and IPsec (71)9.5 Proxy PPP Authentication (71)10.0 IANA Considerations (71)10.1 AVP Attributes (71)10.2 Message Type AVP Values (72)10.3 Result Code AVP Values (72)10.3.1 Result Code Field Values (72)10.3.2 Error Code Field Values (72)10.4 Framing Capabilities & Bearer Capabilities (72)10.5 Proxy Authen Type AVP Values (72)10.6 AVP Header Bits (73)11.0 References (73)12.0 Acknowledgments (74)13.0 Authors’ Addresses (75)Appendix A: Control Channel Slow Start and CongestionAvoidance (76)Appendix B: Control Message Examples (77)Appendix C: Intellectual Property Notice (79)Full Copyright Statement (80)1.0 IntroductionPPP [RFC1661] defines an encapsulation mechanism for transportingmultiprotocol packets across layer 2 (L2) point-to-point links.Typically, a user obtains a L2 connection to a Network Access Server (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN,ADSL, etc.) and then runs PPP over that connection. In such aconfiguration, the L2 termination point and PPP session endpointreside on the same physical device (i.e., the NAS).L2TP extends the PPP model by allowing the L2 and PPP endpoints toreside on different devices interconnected by a packet-switchednetwork. With L2TP, a user has an L2 connection to an accessconcentrator (e.g., modem bank, ADSL DSLAM, etc.), and theconcentrator then tunnels individual PPP frames to the NAS. Thisallows the actual processing of PPP packets to be divorced from thetermination of the L2 circuit.One obvious benefit of such a separation is that instead of requiring the L2 connection terminate at the NAS (which may require along-distance toll charge), the connection may terminate at a (local) circuit concentrator, which then extends the logical PPP session over Townsley, et al. Standards Track [Page 3]a shared infrastructure such as frame relay circuit or the Internet.From the user’s perspective, there is no functional difference between having the L2 circuit terminate in a NAS directly or using L2TP.L2TP may also solve the multilink hunt-group splitting problem.Multilink PPP [RFC1990] requires that all channels composing amultilink bundle be grouped at a single Network Access Server (NAS).Due to its ability to project a PPP session to a location other thanthe point at which it was physically received, L2TP can be used tomake all channels terminate at a single NAS. This allows multilinkoperation even when the calls are spread across distinct physicalNASs.This document defines the necessary control protocol for on-demandcreation of tunnels between two nodes and the accompanyingencapsulation for multiplexing multiple, tunneled PPP sessions.1.1 Specification of RequirementsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thisdocument are to be interpreted as described in [RFC2119].1.2 TerminologyAnalog ChannelA circuit-switched communication path which is intended to carry3.1 kHz audio in each direction.Attribute Value Pair (AVP)The variable length concatenation of a unique Attribute(represented by an integer) and a Value containing the actualvalue identified by the attribute. Multiple AVPs make up ControlMessages which are used in the establishment, maintenance, andteardown of tunnels.CallA connection (or attempted connection) between a Remote System and LAC. For example, a telephone call through the PSTN. A Call(Incoming or Outgoing) which is successfully established between a Remote System and LAC results in a corresponding L2TP Sessionwithin a previously established Tunnel between the LAC and LNS.(See also: Session, Incoming Call, Outgoing Call).Townsley, et al. Standards Track [Page 4]Called NumberAn indication to the receiver of a call as to what telephonenumber the caller used to reach it.Calling NumberAn indication to the receiver of a call as to the telephone number of the caller.CHAPChallenge Handshake Authentication Protocol [RFC1994], a PPPcryptographic challenge/response authentication protocol in which the cleartext password is not passed over the line.Control ConnectionA control connection operates in-band over a tunnel to control the establishment, release, and maintenance of sessions and of thetunnel itself.Control MessagesControl messages are exchanged between LAC and LNS pairs,operating in-band within the tunnel protocol. Control messagesgovern aspects of the tunnel and sessions within the tunnel.Digital ChannelA circuit-switched communication path which is intended to carrydigital information in each direction.DSLAMDigital Subscriber Line (DSL) Access Module. A network device used in the deployment of DSL service. This is typically a concentrator of individual DSL lines located in a central office (CO) or local exchange.Incoming CallA Call received at an LAC to be tunneled to an LNS (see Call,Outgoing Call).Townsley, et al. Standards Track [Page 5]L2TP Access Concentrator (LAC)A node that acts as one side of an L2TP tunnel endpoint and is apeer to the L2TP Network Server (LNS). The LAC sits between anLNS and a remote system and forwards packets to and from each.Packets sent from the LAC to the LNS requires tunneling with theL2TP protocol as defined in this document. The connection fromthe LAC to the remote system is either local (see: Client LAC) or a PPP link.L2TP Network Server (LNS)A node that acts as one side of an L2TP tunnel endpoint and is apeer to the L2TP Access Concentrator (LAC). The LNS is thelogical termination point of a PPP session that is being tunneled from the remote system by the LAC.Management Domain (MD)A network or networks under the control of a singleadministration, policy or system. For example, an LNS’s Management Domain might be the corporate network it serves. An LAC’sManagement Domain might be the Internet Service Provider that owns and manages it.Network Access Server (NAS)A device providing local network access to users across a remoteaccess network such as the PSTN. An NAS may also serve as an LAC, LNS or both.Outgoing CallA Call placed by an LAC on behalf of an LNS (see Call, IncomingCall).PeerWhen used in context with L2TP, peer refers to either the LAC orLNS. An LAC’s Peer is an LNS and vice versa. When used in context with PPP, a peer is either side of the PPP connection.POTSPlain Old Telephone Service.Townsley, et al. Standards Track [Page 6]Remote SystemAn end-system or router attached to a remote access network (i.e.a PSTN), which is either the initiator or recipient of a call.Also referred to as a dial-up or virtual dial-up client.SessionL2TP is connection-oriented. The LNS and LAC maintain state foreach Call that is initiated or answered by an LAC. An L2TP Session is created between the LAC and LNS when an end-to-end PPPconnection is established between a Remote System and the LNS.Datagrams related to the PPP connection are sent over the Tunnelbetween the LAC and LNS. There is a one to one relationshipbetween established L2TP Sessions and their associated Calls. (See also: Call).TunnelA Tunnel exists between a LAC-LNS pair. The Tunnel consists of aControl Connection and zero or more L2TP Sessions. The Tunnelcarries encapsulated PPP datagrams and Control Messages betweenthe LAC and the LNS.Zero-Length Body (ZLB) MessageA control packet with only an L2TP header. ZLB messages are usedfor explicitly acknowledging packets on the reliable controlchannel.Townsley, et al. Standards Track [Page 7]2.0 TopologyThe following diagram depicts a typical L2TP scenario. The goal is to tunnel PPP frames between the Remote System or LAC Client and an LNS located at a Home LAN.[Home LAN][LAC Client]----------+ |____|_____ +--[Host]| | |[LAC]---------| Internet |-----[LNS]-----+| |__________| |_____|_____ :| || PSTN |[Remote]--| Cloud |[System] | | [Home LAN]|___________| || ______________ +---[Host]| | | |[LAC]-------| Frame Relay |---[LNS]-----+| or ATM Cloud | ||______________| :The Remote System initiates a PPP connection across the PSTN Cloud to an LAC. The LAC then tunnels the PPP connection across the Internet, Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN isobtained. The Remote System is provided addresses from the HOME LANvia PPP NCP negotiation. Authentication, Authorization and Accounting may be provided by the Home LAN’s Management Domain as if the userwere connected to a Network Access Server directly.A LAC Client (a Host which runs L2TP natively) may also participatein tunneling to the Home LAN without use of a separate LAC. In thiscase, the Host containing the LAC Client software already has aconnection to the public Internet. A "virtual" PPP connection is then created and the local L2TP LAC Client software creates a tunnel tothe LNS. As in the above case, Addressing, Authentication,Authorization and Accounting will be provided by the Home LAN’sManagement Domain.Townsley, et al. Standards Track [Page 8]3.0 Protocol OverviewL2TP utilizes two types of messages, control messages and datamessages. Control messages are used in the establishment, maintenance and clearing of tunnels and calls. Data messages are used toencapsulate PPP frames being carried over the tunnel. Controlmessages utilize a reliable Control Channel within L2TP to guarantee delivery (see section 5.1 for details). Data messages are notretransmitted when packet loss occurs.+-------------------+| PPP Frames |+-------------------+ +-----------------------+| L2TP Data Messages| | L2TP Control Messages |+-------------------+ +-----------------------+| L2TP Data Channel | | L2TP Control Channel || (unreliable) | | (reliable) |+------------------------------------------------+| Packet Transport (UDP, FR, ATM, etc.) |+------------------------------------------------+Figure 3.0 L2TP Protocol StructureFigure 3.0 depicts the relationship of PPP frames and ControlMessages over the L2TP Control and Data Channels. PPP Frames arepassed over an unreliable Data Channel encapsulated first by an L2TP header and then a Packet Transport such as UDP, Frame Relay, ATM,etc. Control messages are sent over a reliable L2TP Control Channelwhich transmits packets in-band over the same Packet Transport.Sequence numbers are required to be present in all control messagesand are used to provide reliable delivery on the Control Channel.Data Messages may use sequence numbers to reorder packets and detect lost packets.All values are placed into their respective fields and sent innetwork order (high order octets first).3.1 L2TP Header FormatL2TP packets for the control channel and data channel share a common header format. In each case where a field is optional, its space does not exist in the message if the field is marked not present. Notethat while optional on data messages, the Length, Ns, and Nr fieldsmarked as optional below, are required to be present on all controlmessages.Townsley, et al. Standards Track [Page 9]This header is formatted:0 1 2 30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Tunnel ID | Session ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Ns (opt) | Nr (opt) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Offset Size (opt) | Offset pad... (opt)+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3.1 L2TP Message HeaderThe Type (T) bit indicates the type of message. It is set to 0 for a data message and 1 for a control message.If the Length (L) bit is 1, the Length field is present. This bitMUST be set to 1 for control messages.The x bits are reserved for future extensions. All reserved bits MUST be set to 0 on outgoing messages and ignored on incoming messages.If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. The S bit MUST be set to 1 for control messages.If the Offset (O) bit is 1, the Offset Size field is present. The Obit MUST be set to 0 (zero) for control messages.If the Priority (P) bit is 1, this data message should receivepreferential treatment in its local queuing and transmission. LCPecho requests used as a keepalive for the link, for instance, should generally be sent with this bit set to 1. Without it, a temporaryinterval of local congestion could result in interference withkeepalive messages and unnecessary loss of the link. This feature is only for use with data messages. The P bit MUST be set to 0 for allcontrol messages.Ver MUST be 2, indicating the version of the L2TP data message header described in this document. The value 1 is reserved to permitdetection of L2F [RFC2341] packets should they arrive intermixed with L2TP packets. Packets received with an unknown Ver field MUST bediscarded.The Length field indicates the total length of the message in octets. Townsley, et al. Standards Track [Page 10]Tunnel ID indicates the identifier for the control connection. L2TPtunnels are named by identifiers that have local significance only.That is, the same tunnel will be given different Tunnel IDs by eachend of the tunnel. Tunnel ID in each message is that of the intended recipient, not the sender. Tunnel IDs are selected and exchanged asAssigned Tunnel ID AVPs during the creation of a tunnel.Session ID indicates the identifier for a session within a tunnel.L2TP sessions are named by identifiers that have local significanceonly. That is, the same session will be given different Session IDsby each end of the session. Session ID in each message is that of the intended recipient, not the sender. Session IDs are selected andexchanged as Assigned Session ID AVPs during the creation of asession.Ns indicates the sequence number for this data or control message,beginning at zero and incrementing by one (modulo 2**16) for eachmessage sent. See Section 5.8 and 5.4 for more information on usingthis field.Nr indicates the sequence number expected in the next control message to be received. Thus, Nr is set to the Ns of the last in-ordermessage received plus one (modulo 2**16). In data messages, Nr isreserved and, if present (as indicated by the S-bit), MUST be ignored upon receipt. See section 5.8 for more information on using thisfield in control messages.The Offset Size field, if present, specifies the number of octetspast the L2TP header at which the payload data is expected to start. Actual data within the offset padding is undefined. If the offsetfield is present, the L2TP header ends after the last octet of theoffset padding.3.2 Control Message TypesThe Message Type AVP (see section 4.4.1) defines the specific type of control message being sent. Recall from section 3.1 that this is only for control messages, that is, messages with the T-bit set to 1. Townsley, et al. Standards Track [Page 11]This document defines the following control message types (seeSection 6.1 through 6.14 for details on the construction and use ofeach message):Control Connection Management0 (reserved)1 (SCCRQ) Start-Control-Connection-Request2 (SCCRP) Start-Control-Connection-Reply3 (SCCCN) Start-Control-Connection-Connected4 (StopCCN) Stop-Control-Connection-Notification5 (reserved)6 (HELLO) HelloCall Management7 (OCRQ) Outgoing-Call-Request8 (OCRP) Outgoing-Call-Reply9 (OCCN) Outgoing-Call-Connected10 (ICRQ) Incoming-Call-Request11 (ICRP) Incoming-Call-Reply12 (ICCN) Incoming-Call-Connected13 (reserved)14 (CDN) Call-Disconnect-NotifyError Reporting15 (WEN) WAN-Error-NotifyPPP Session Control16 (SLI) Set-Link-Info4.0 Control Message Attribute Value PairsTo maximize extensibility while still permitting interoperability, a uniform method for encoding message types and bodies is usedthroughout L2TP. This encoding will be termed AVP (Attribute-ValuePair) in the remainder of this document.Townsley, et al. Standards Track [Page 12]4.1 AVP FormatEach AVP is encoded as:0 1 2 30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|M|H| rsvd | Length | Vendor ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Attribute Type | Attribute Value...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+[until Length is reached]... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The first six bits are a bit mask, describing the general attributes of the AVP.Two bits are defined in this document, the remaining are reserved for future extensions. Reserved bits MUST be set to 0. An AVP receivedwith a reserved bit set to 1 MUST be treated as an unrecognized AVP. Mandatory (M) bit: Controls the behavior required of animplementation which receives an AVP which it does not recognize. If the M bit is set on an unrecognized AVP within a message associatedwith a particular session, the session associated with this messageMUST be terminated. If the M bit is set on an unrecognized AVP within a message associated with the overall tunnel, the entire tunnel (and all sessions within) MUST be terminated. If the M bit is not set, an unrecognized AVP MUST be ignored. The control message must thencontinue to be processed as if the AVP had not been present.Hidden (H) bit: Identifies the hiding of data in the Attribute Value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP.Section 4.3 describes the procedure for performing AVP hiding.Length: Encodes the number of octets (including the Overall Lengthand bitmask fields) contained in this AVP. The Length may becalculated as 6 + the length of the Attribute Value field in octets. The field itself is 10 bits, permitting a maximum of 1023 octets ofdata in a single AVP. The minimum Length of an AVP is 6. If thelength is 6, then the Attribute Value field is absent.Vendor ID: The IANA assigned "SMI Network Management PrivateEnterprise Codes" [RFC1700] value. The value 0, corresponding toIETF adopted attribute values, is used for all AVPs defined withinthis document. Any vendor wishing to implement their own L2TPextensions can use their own Vendor ID along with private Attribute Townsley, et al. Standards Track [Page 13]values, guaranteeing that they will not collide with any othervendor’s extensions, nor with future IETF extensions. Note that there are 16 bits allocated for the Vendor ID, thus limiting this featureto the first 65,535 enterprises.Attribute Type: A 2 octet value with a unique interpretation acrossall AVPs defined under a given Vendor ID.Attribute Value: This is the actual value as indicated by the Vendor ID and Attribute Type. It follows immediately after the AttributeType field, and runs for the remaining octets indicated in the Length (i.e., Length minus 6 octets of header). This field is absent if the Length is 6.4.2 Mandatory AVPsReceipt of an unknown AVP that has the M-bit set is catastrophic tothe session or tunnel it is associated with. Thus, the M bit shouldonly be defined for AVPs which are absolutely crucial to properoperation of the session or tunnel. Further, in the case where theLAC or LNS receives an unknown AVP with the M-bit set and shuts down the session or tunnel accordingly, it is the full responsibility ofthe peer sending the Mandatory AVP to accept fault for causing annon-interoperable situation. Before defining an AVP with the M-bitset, particularly a vendor-specific AVP, be sure that this is theintended consequence.When an adequate alternative exists to use of the M-bit, it should be utilized. For example, rather than simply sending an AVP with the M- bit set to determine if a specific extension exists, availability may be identified by sending an AVP in a request message and expecting a corresponding AVP in a reply message.Use of the M-bit with new AVPs (those not defined in this document)MUST provide the ability to configure the associated feature off,such that the AVP is either not sent, or sent with the M-bit not set.4.3 Hiding of AVP Attribute ValuesThe H bit in the header of each AVP provides a mechanism to indicate to the receiving peer whether the contents of the AVP are hidden orpresent in cleartext. This feature can be used to hide sensitivecontrol message data such as user passwords or user IDs.The H bit MUST only be set if a shared secret exists between the LAC and LNS. The shared secret is the same secret that is used for tunnel authentication (see Section 5.1.1). If the H bit is set in any Townsley, et al. Standards Track [Page 14]AVP(s) in a given control message, a Random Vector AVP must also bepresent in the message and MUST precede the first AVP having an H bit of 1.Hiding an AVP value is done in several steps. The first step is totake the length and value fields of the original (cleartext) AVP and encode them into a Hidden AVP Subformat as follows:0 1 2 30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length of Original Value | Original Attribute Value ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | Padding ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length of Original Attribute Value: This is length of the OriginalAttribute Value to be obscured in octets. This is necessary todetermine the original length of the Attribute Value which is lostwhen the additional Padding is added.Original Attribute Value: Attribute Value that is to be obscured.Padding: Random additional octets used to obscure length of theAttribute Value that is being hidden.To mask the size of the data being hidden, the resulting subformatMAY be padded as shown above. Padding does NOT alter the value placed in the Length of Original Attribute Value field, but does alter thelength of the resultant AVP that is being created. For example, If an Attribute Value to be hidden is 4 octets in length, the unhidden AVP length would be 10 octets (6 + Attribute Value length). After hiding, the length of the AVP will become 6 + Attribute Value length + sizeof the Length of Original Attribute Value field + Padding. Thus, ifPadding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24octets.Next, An MD5 hash is performed on the concatenation of:+ the 2 octet Attribute number of the AVP+ the shared secret+ an arbitrary length random vectorThe value of the random vector used in this hash is passed in thevalue field of a Random Vector AVP. This Random Vector AVP must beplaced in the message by the sender before any hidden AVPs. The same random vector may be used for more than one hidden AVP in the same Townsley, et al. Standards Track [Page 15]message. If a different random vector is used for the hiding ofsubsequent AVPs then a new Random Vector AVP must be placed in thecommand message before the first AVP to which it applies.The MD5 hash value is then XORed with the first 16 octet (or less)segment of the Hidden AVP Subformat and placed in the Attribute Value field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, the Subformat is transformed as if the Attribute Value field had been padded to 16 octets before the XOR, but only the actualoctets present in the Subformat are modified, and the length of theAVP is not altered.If the Subformat is longer than 16 octets, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first XOR. That hash is XORed with the second 16 octet (or less) segment of the Subformat and placed in the corresponding octets of the Value field of the Hidden AVP.If necessary, this operation is repeated, with the shared secret used along with each XOR result to generate the next hash to XOR the next segment of the value with.The hiding method was adapted from RFC 2138 [RFC2138] which was taken from the "Mixing in the Plaintext" section in the book "NetworkSecurity" by Kaufman, Perlman and Speciner [KPS]. A detailedexplanation of the method follows:Call the shared secret S, the Random Vector RV, and the AttributeValue AV. Break the value field into 16-octet chunks p1, p2, etc.with the last one padded at the end with random data to a 16-octetboundary. Call the ciphertext blocks c(1), c(2), etc. We will also define intermediate values b1, b2, etc.b1 = MD5(AV + S + RV) c(1) = p1 xor b1b2 = MD5(S + c(1)) c(2) = p2 xor b2. .. .. .bi = MD5(S + c(i-1)) c(i) = pi xor biThe String will contain c(1)+c(2)+...+c(i) where + denotesconcatenation.On receipt, the random vector is taken from the last Random VectorAVP encountered in the message prior to the AVP to be unhidden. The above process is then reversed to yield the original value.Townsley, et al. Standards Track [Page 16]。

M. Rose & D. Cass [Page 1]Network Working Group Marshall T. Rose, Dwight E. Cass Request for Comments: RFC 1006 Northrop Research and Technology Center Obsoletes: RFC 983 May 1987 ISO Transport Service on top of the TCPVersion: 3Status of this MemoThis memo specifies a standard for the Internet community. Hostson the Internet that choose to implement ISO transport serviceson top of the TCP are expected to adopt and implement thisstandard. TCP port 102 is reserved for hosts which implement thisstandard. Distribution of this memo is unlimited.This memo specifies version 3 of the protocol and supersedes[RFC983]. Changes between the protocol as described in Request forComments 983 and this memo are minor, but are unfortunatelyincompatible.M. Rose & D. Cass [Page 1]1. Introduction and PhilosophyThe Internet community has a well-developed, mature set oftransport and internetwork protocols (TCP/IP), which are quitesuccessful in offering network and transport services toend-users. The CCITT and the ISO have defined various session,presentation, and application recommendations which have beenadopted by the international community and numerous vendors.To the largest extent possible, it is desirable to offer thesehigher level directly in the ARPA Internet, without disruptingexisting facilities. This permits users to develop expertisewith ISO and CCITT applications which previously were notavailable in the ARPA Internet. It also permits a moregraceful convergence and transition strategy fromTCP/IP-based networks to ISO-based networks in themedium-and long-term.There are two basic approaches which can be taken when "porting"an ISO or CCITT application to a TCP/IP environment. Oneapproach is to port each individual application separately,developing local protocols on top of the TCP. Although this isuseful in the short-term (since special-purpose interfaces to the TCP can be developed quickly), it lacks generality.A second approach is based on the observation that both the ARPAInternet protocol suite and the ISO protocol suite are bothlayered systems (though the former uses layering from a morepragmatic perspective). A key aspect of the layering principleis that of layer-independence. Although this section isredundant for most readers, a slight bit of background materialis necessary to introduce this concept.Externally, a layer is defined by two definitions:a service-offered definition, which describes the servicesprovided by the layer and the interfaces it provides toaccess those services; and,a service-required definitions, which describes the servicesused by the layer and the interfaces it uses to access thoseservices.Collectively, all of the entities in the network which co-operate to provide the service are known as the service-provider.Individually, each of these entities is known as a service-peer.Internally, a layer is defined by one definition:a protocol definition, which describes the rules which eachservice-peer uses when communicating with other service-peers. M. Rose & D. Cass [Page 2]Putting all this together, the service-provider uses the protocol and services from the layer below to offer the its service to the layer above. Protocol verification, for instance, deals withproving that this in fact happens (and is also a fertile fieldfor many Ph.D. dissertations in computer science).The concept of layer-independence quite simply is:IF one preserves the services offered by the service-provider THEN the service-user is completely naive with respect to the protocol which the service-peers useFor the purposes of this memo, we will use the layer-independence to define a Transport Service Access Point (TSAP) which appearsto be identical to the services and interfaces offered by theISO/CCITT TSAP (as defined in [ISO8072]), but we will in factimplement the ISO TP0 protocol on top of TCP/IP (as defined in[RFC793,RFC791]), not on top of the the ISO/CCITT networkprotocol. Since the transport class 0 protocol is used over theTCP/IP connection, it achieves identical functionality astransport class 4. Hence, ISO/CCITT higher level layers (allsession, presentation, and application entities) can operatefully without knowledge of the fact that they are running on aTCP/IP internetwork.M. Rose & D. Cass [Page 3]2. MotivationIn migrating from the use of TCP/IP to the ISO protocols, thereare several strategies that one might undertake. This memo waswritten with one particular strategy in mind.The particular migration strategy which this memo uses is basedon the notion of gatewaying between the TCP/IP and ISO protocolsuites at the transport layer. There are two strong argumentsfor this approach:1. Experience teaches us that it takes just as long to get goodimplementations of the lower level protocols as it takes to getimplementations of the higher level ones. In particular, it hasbeen observed that there is still a lot of work being done at the ISO network and transport layers. As a result, implementationsof protocols above these layers are not being aggressivelypursued. Thus, something must be done "now" to provide a mediumin which the higher level protocols can be developed. SinceTCP/IP is mature, and essentially provides identicalfunctionality, it is an ideal medium to support this development.2. Implementation of gateways at the IP and ISO IP layers areprobably not of general use in the long term. In effect, thiswould require each Internet host to support both TP4 and TCP.As such, a better strategy is to implement a graceful migrationpath from TCP/IP to ISO protocols for the ARPA Internet when theISO protocols have matured sufficiently.Both of these arguments indicate that gatewaying should occur ator above the transport layer service access point. Further, thefirst argument suggests that the best approach is to perform thegatewaying exactly AT the transport service access point tomaximize the number of ISO layers which can be developed.NOTE: This memo does not intend to act as a migration orintercept document. It is intended ONLY to meet theneeds discussed above. However, it would not beunexpected that the protocol described in this memomight form part of an overall transition plan. Thedescription of such a plan however is COMPLETELYbeyond the scope of this memo.Finally, in general, building gateways between other layers in the TCP/IP and ISO protocol suites is problematic, at best.To summarize: the primary motivation for the standard described in this memo is to facilitate the process of gaining experience with higher-level ISO protocols (session, presentation, andapplication). The stability and maturity of TCP/IP are ideal for M. Rose & D. Cass [Page 4]providing solid transport services independent of actualimplementation.M. Rose & D. Cass [Page 5]3. The ModelThe [ISO8072] standard describes the ISO transport servicedefinition, henceforth called TP.ASIDE: This memo references the ISO specifications ratherthan the CCITT recommendations. The differencesbetween these parallel standards are quite small,and can be ignored, with respect to this memo,without loss of generality. To provide the readerwith the relationships:Transport service [ISO8072] [X.214]Transport protocol [ISO8073] [X.224]Session protocol [ISO8327] [X.225]The ISO transport service definition describes the servicesoffered by the TS-provider (transport service) and the interfaces used to access those services. This memo focuses on how the ARPA Transmission Control Protocol (TCP) [RFC793] can be used to offer the services and provide the interfaces.+-----------+ +-----------+ | TS-user | | TS-user | +-----------+ +-----------+ | || TSAP interface TSAP interface || [ISO8072] || |+----------+ ISO Transport Services on the TCP +----------+ | client |-----------------------------------------| server | +----------+ (this memo) +----------+ | || TCP interface TCP interface || [RFC793] || |For expository purposes, the following abbreviations are used:TS-peer a process which implements the protocol described by this memoTS-user a process talking using the services of a TS-peer M. Rose & D. Cass [Page 6]TS-provider the black-box entity implementing the protocoldescribed by this memoFor the purposes of this memo, which describes version 2 of theTSAP protocol, all aspects of [ISO8072] are supported with oneexception:Quality of Service parametersIn the spirit of CCITT, this is left "for further study". Afuture version of the protocol will most likely support the QOSparameters for TP by mapping these onto various TCP parameters.The ISO standards do not specify the format of a session port(termed a TSAP ID). This memo mandates the use of the GOSIPspecification [GOSIP86] for the interpretation of this field.(Please refer to Section 5.2, entitled "UPPER LAYERS ADDRESSING".) Finally, the ISO TSAP is fundamentally symmetric in behavior.There is no underlying client/server model. Instead of a serverlistening on a well-known port, when a connection is established, the TS-provider generates an INDICATION event which, presumablythe TS-user catches and acts upon. Although this might beimplemented by having a server "listen" by hanging on theINDICATION event, from the perspective of the ISO TSAP, all TS-users just sit around in the IDLE state until they either generate a REQUEST or accept an INDICATION.M. Rose & D. Cass [Page 7]4. The PrimitivesThe protocol assumes that the TCP[RFC793] offers the followingservice primitives:Eventsconnected - open succeeded (either ACTIVE or PASSIVE)connect fails - ACTIVE open faileddata ready - data can be read from the connectionerrored - the connection has errored and is now closed closed - an orderly disconnection has startedActionslisten on port - PASSIVE open on the given portopen port - ACTIVE open to the given portread data - data is read from the connectionsend data - data is sent on the connectionclose - the connection is closed (pending data issent)This memo describes how to use these services to emulate the following service primitives, which are required by [ISO8073]:EventsN-CONNECT.INDICATION- An NS-user (responder) is notified thatconnection establishment is in progressN-CONNECT.CONFIRMATION- An NS-user (responder) is notified thatthe connection has been establishedN-DATA.INDICATION- An NS-user is notified that data can beread from the connectionM. Rose & D. Cass [Page 8]N-DISCONNECT.INDICATION- An NS-user is notified that the connectionis closedActionsN-CONNECT.REQUEST- An NS-user (initiator) indicates that itwants to establish a connectionN-CONNECT.RESPONSE- An NS-user (responder) indicates that itwill honor the requestN-DATA.REQUEST - An NS-user sends dataN-DISCONNECT.REQUEST- An NS-user indicates that the connectionis to be closedThe protocol offers the following service primitives, as definedin [ISO8072], to the TS-user:EventsT-CONNECT.INDICATION- a TS-user (responder) is notified thatconnection establishment is in progressT-CONNECT.CONFIRMATION- a TS-user (initiator) is notified that theconnection has been establishedT-DATA.INDICATION- a TS-user is notified that data can be read from the connectionT-EXPEDITED DATA.INDICATION- a TS-user is notified that "expedited" data can be read from the connectionT-DISCONNECT.INDICATION- a TS-user is notified that the connectionis closedM. Rose & D. Cass [Page 9]ActionsT-CONNECT.REQUEST- a TS-user (initiator) indicates that itwants to establish a connectionT-CONNECT.RESPONSE- a TS-user (responder) indicates that itwill honor the requestT-DATA.REQUEST - a TS-user sends dataT-EXPEDITED DATA.REQUEST- a TS-user sends "expedited" dataT-DISCONNECT.REQUEST- a TS-user indicates that the connectionis to be closedM. Rose & D. Cass [Page 10]5. The ProtocolThe protocol specified by this memo is identical to the protocolfor ISO transport class 0, with the following exceptions:- for testing purposes, initial data may be exchangedduring connection establishment- for testing purposes, an expedited data service issupported- for performance reasons, a much larger TSDU size issupported- the network service used by the protocol is providedby the TCPThe ISO transport protocol exchanges information between peers in discrete units of information called transport protocol data units (TPDUs). The protocol defined in this memo encapsulates theseTPDUs in discrete units called TPKTs. The structure of theseTPKTs and their relationship to TPDUs are discussed in the nextsection.PRIMITIVESThe mapping between the TCP service primitives and the service primitives expected by transport class 0 are quite straight-forward:network service TCP--------------- ---CONNECTION ESTABLISHMENTN-CONNECT.REQUEST open completesN-CONNECT.INDICATION listen (PASSIVE open)finishesN-CONNECT.RESPONSE listen completesN-CONNECT.CONFIRMATION open (ACTIVE open)finishesDATA TRANSFERN-DATA.REQUEST send dataN-DATA.INDICATION data ready followed by M. Rose & D. Cass [Page 11]read dataCONNECTION RELEASEN-DISCONNECT.REQUEST closeN-DISCONNECT.INDICATION connection closes orerrorsMapping parameters is also straight-forward:network service TCP--------------- ---CONNECTION RELEASECalled address server’s IP address(4 octets)Calling address client’s IP address(4 octets)all others ignoredDATA TRANSFERNS-user data (NSDU) dataCONNECTION RELEASEall parameters ignoredCONNECTION ESTABLISHMENTThe elements of procedure used during connection establishment are identical to those presented in [ISO8073], with threeexceptions.In order to facilitate testing, the connection request andconnection confirmation TPDUs may exchange initial user data, using the user data fields of these TPDUs.In order to experiment with expedited data services, theconnection request and connection confirmation TPDUs maynegotiate the use of expedited data transfer using thenegotiation mechanism specified in [ISO8073] is used (e.g.,setting the "use of transport expedited data transfer service" bit in the "Additional Option Selection" variable part). Thedefault is not to use the transport expedited data transferservice.M. Rose & D. Cass [Page 12]In order to achieve good performance, the default TPDU size is 65531 octets, instead of 128 octets. In order to negotiate a smaller (standard) TPDU size, the negotiation mechanismspecified in [ISO8073] is used (e.g., setting the desired bit in the "TPDU Size" variable part).To perform an N-CONNECT.REQUEST action, the TS-peer performsan active open to the desired IP address using TCP port 102.When the TCP signals either success or failure, this resultsin an N-CONNECT.INDICATION action.To await an N-CONNECT.INDICATION event, a server listens onTCP port 102. When a client successfully connects to thisport, the event occurs, and an implicit N-CONNECT.RESPONSEaction is performed.NOTE: In most implementations, a single server willperpetually LISTEN on port 102, handing offconnections as they are madeDATA TRANSFERThe elements of procedure used during data transfer are identical to those presented in [ISO8073], with one exception: expediteddata may be supported (if so negotiated during connectionestablishment) by sending a modified ED TPDU (described below).The TPDU is sent on the same TCP connection as all of the otherTPDUs. This method, while not faithful to the spirit of [ISO8072], is true to the letter of the specification.To perform an N-DATA.REQUEST action, the TS-peer constructs thedesired TPKT and uses the TCP send data primitive.To trigger an N-DATA.INDICATION action, the TCP indicates thatdata is ready and a TPKT is read using the TCP read dataprimitive.CONNECTION RELEASETo perform an N-DISCONNECT.REQUEST action, the TS-peer simply closes the TCP connection.If the TCP informs the TS-peer that the connection has been closed or has errored, this indicates an N-DISCONNECT.INDICATION event.M. Rose & D. Cass [Page 13]6. Packet FormatA fundamental difference between the TCP and the network serviceexpected by TP0 is that the TCP manages a continuous stream ofoctets, with no explicit boundaries. The TP0 expects informationto be sent and delivered in discrete objects termed networkservice data units (NSDUs). Although other classes of transportmay combine more than one TPDU inside a single NSDU, transportclass 0 does not use this facility. Hence, an NSDU is identicalto a TPDU for the purposes of our discussion.The protocol described by this memo uses a simple packetizationscheme in order to delimit TPDUs. Each packet, termed a TPKT, isviewed as an object composed of an integral number of octets, ofvariable length.NOTE: For the purposes of presentation, these objects are shown as being 4 octets (32 bits wide). Thisrepresentation is an artifact of the style of this memo and should not be interpreted as requiringthat a TPKT be a multiple of 4 octets in length.A TPKT consists of two parts: a packet-header and a TPDU. Theformat of the header is constant regardless of the type of packet. The format of the packet-header is as follows:0 1 2 30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vrsn | reserved | packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where:vrsn 8 bitsThis field is always 3 for the version of the protocol described in this memo.packet length 16 bits (min=7, max=65535)This field contains the length of entire packet in octets,including packet-header. This permits a maximum TPDU size of65531 octets. Based on the size of the data transfer (DT) TPDU,this permits a maximum TSDU size of 65524 octets.The format of the TPDU is defined in [ISO8073]. Note that onlyTPDUs formatted for transport class 0 are exchanged (differenttransport classes may use slightly different formats).M. Rose & D. Cass [Page 14]To support expedited data, a non-standard TPDU, for expedited data is permitted. The format used for the ED TPDU is nearly identical to the format for the normal data, DT, TPDU. The only difference is that the value used for the TPDU’s code is ED, not DT:0 1 2 30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header length | code |credit |TPDU-NR and EOT| user data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | ... | ... | | ... | ... | ... | ... | | ... | ... | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ After the credit field (which is always ZERO on output and ignored on input), there is one additional field prior to the user data.TPDU-NR and EOT 8 bitsBit 7 (the high-order bit, bit mask 1000 0000) indicates the endof a TSDU. All other bits should be ZERO on output and ignored on input.Note that the TP specification limits the size of an expeditedtransport service data unit (XSDU) to 16 octets.M. Rose & D. Cass [Page 15]7. CommentsSince the release of RFC983 in April of 1986, we have gained much experience in using ISO transport services on top of the TCP. In September of 1986, we introduced the use of version 2 of theprotocol, based mostly on comments from the community.In January of 1987, we observed that the differences betweenversion 2 of the protocol and the actual transport class 0definition were actually quite small. In retrospect, thisrealization took much longer than it should have: TP0 is is meant to run over a reliable network service, e.g., X.25. The TCP can be used to provide a service of this type, and, if no one complainstoo loudly, one could state that this memo really just describes a method for encapsulating TPO inside of TCP!The changes in going from version 1 of the protocol to version 2and then to version 3 are all relatively small. Initially, indescribing version 1, we decided to use the TPDU formats from the ISO transport protocol. This naturally led to the evolutiondescribed above.M. Rose & D. Cass [Page 16]8. References[GOSIP86] The U.S. Government OSI User’s Committee."Government Open Systems Interconnection Procurement(GOSIP) Specification for Fiscal years 1987 and1988." (December, 1986) [draft status][ISO8072] ISO."International Standard 8072. Information ProcessingSystems -- Open Systems Interconnection: TransportService Definition."(June, 1984)[ISO8073] ISO."International Standard 8073. Information ProcessingSystems -- Open Systems Interconnection: TransportProtocol Specification."(June, 1984)[ISO8327] ISO."International Standard 8327. Information ProcessingSystems -- Open Systems Interconnection: SessionProtocol Specification."(June, 1984)[RFC791] Internet Protocol.Request for Comments 791 (MILSTD 1777)(September, 1981)[RFC793] Transmission Control Protocol.Request for Comments 793 (MILSTD 1778)(September, 1981)[RFC983] ISO Transport Services on Top of the TCP.Request for Comments 983(April, 1986)[X.214] CCITT."Recommendation X.214. Transport Service Definitionsfor Open Systems Interconnection (OSI) for CCITTApplications."(October, 1984)[X.224] CCITT."Recommendation X.224. Transport ProtocolSpecification for Open Systems Interconnection (OSI)for CCITT Applications." (October, 1984)M. Rose & D. Cass [Page 17][X.225] CCITT."Recommendation X.225. Session Protocol Specificationfor Open Systems Interconnection (OSI) for CCITTApplications."(October, 1984)M. Rose & D. Cass [Page 18]。

开源项目rfc流程开源项目RFC流程1. 什么是RFC？•RFC是”Request for Comments”的缩写，意为”征求意见”或”意见征集”。

•在开源项目中，RFC是一种协作流程，用于提出新的功能或更改现有功能的建议，并征求项目群体的意见。

2. RFC的目的与重要性•RFC流程为开源项目提供了一个包容性的环境，让所有人都有机会参与决策过程。

•通过RFC流程，项目团队可以更好地理解社区成员的需求，减少冲突和误解，并确保变更是基于共识和讨论的结果。

3. RFC流程的具体步骤•提出RFC：在项目的RFC存储库中创建一个新的RFC文件，并使用Markdown格式编写提案。

•反馈与讨论：项目群体和有兴趣的社区成员将参与讨论，提出问题、建议和其他反馈。

•修改与改进：根据收到的反馈，作者可以对RFC进行修改和改进，以更好地满足需求和解决问题。

•状态更新：在RFC的生命周期中，通过更新RFC文件的状态，作者可以向社区反馈进展情况。

•最终评审：项目核心团队将对RFC进行最终评审，并确认是否接受或拒绝提案。

•实施与跟踪：一旦RFC被接受并实施，作者需要跟踪变更的进展，并确保及时更新相关文档。

4. RFC文章的Markdown格式要求•使用Markdown格式可以更好地展示RFC的内容和结构。

•下面提供一些常用的Markdown格式要求：–标题：使用井号（#）表示不同级别的标题，以突出重点和组织结构。

–列表：使用横杠（-）或星号（*）创建无序列表，使用数字创建有序列表。

–引用：使用大于号（>）创建引用段落，用于引用他人意见或讨论。

–代码块：使用反引号（`）创建代码块，用于展示代码示例或命令。

–链接：使用方括号（[]）和圆括号（()）创建链接，以便在RFC中引用其他文件或资源。

5. 一些建议与注意事项•清晰明了地描述问题或需求，以便社区成员更好地理解和提供反馈。

•避免使用复杂的排版和格式，以保持RFC的易读性。

组织：中国互动出版网（/）RFC文档中文翻译计划（/compters/emook/aboutemook.htm）E-mail：********************译者：黄晓东（黄晓东****************）译文发布时间：2001-7-14版权：本中文翻译文档版权归中国互动出版网所有。

可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。

Network Working Group T. Berners-Lee Request for Comments: 1945 MIT/LCS Category: Informational R. Fielding UC IrvineH. FrystykMIT/LCSMay 1996超文本传输协议 -- HTTP/1.0（Hyptertext Transfer Protocol – HTTP/1.0）关于下段备忘（Status of This Memo）本段文字为Internet团体提供信息，并没有以任何方式指定Internet标准。

本段文字没有分发限制。

IESG提示（IESG Note）：IESG已在关注此协议，并期待该文档能尽快被标准跟踪文档所替代。

摘要（Abstract）HTTP（Hypertext Transfer Protocol）是应用级协议，它适应了分布式超媒体协作系统对灵活性及速度的要求。

它是一个一般的、无状态的、基于对象的协议，通过对其请求方法（request methods）进行扩展，可以被用于多种用途，比如命名服务器（name server）及分布式对象管理系统。

HTTP的一个特性是其数据表现类型允许系统的构建不再依赖于要传输的数据。

HTTP自从1990年就在WWW上被广泛使用。

该规范反映了“HTTP/1.0”的普通用法。

目录（Table of Contents）1. 介绍（Introduction） 61.1 目的（Purpose） 61.2 术语（Terminology） 61.3 概述（Overall Operation）81.4 HTTP and MIME 92. 标志转换及通用语法（Notational Conventions and Generic Grammar）9 2.1 补充反馈方式（Augmented BNF）92.2 基本规则（Basic Rules）103. 协议参数（Protocol Parameters） 123.1 HTTP版本（HTTP Version）123.2 统一资源标识（Uniform Resource Identifiers）133.2.1 一般语法（General Syntax）133.2.2 http URL 143.3 Date/Time 格式（Date/Time Formats）153.4 字符集（Character Sets）163.5 内容译码（Content Codings）163.6 介质类型（Media Types）173.6.1标准及文本缺省（Canonicalization and Text Defaults）183.6.2 多部分类型（Multipart Types） 183.7 产品标识（Product Tokens） 194. HTTP 消息（HTTP Message）194.1 消息类型（Message Types）194.2 消息标题（Message Headers）204.3 普通标题域（General Header Fields）205. 请求（Request）215.1 请求队列（Request-Line）215.1.1 方法（Method）225.1.2 请求URI（Request-URI）225.2 请求标题域（Request Header Fields）236. 回应（Response）236.1 状态行（Status-Line）246.1.1 状态代码和原因分析（Status Code and Reason Phrase）246.2 回应标题域（Response Header Fields）257. 实体（Entity）267.1 实体标题域（Entity Header Fields） 267.2 实体主体（Entity Body）267.2.1 类型（Type）277.2.2 长度（Length）278. 方法定义（Method Definitions）278.1 GET 288.2 HEAD 288.3 POST 289. 状态代码定义（Status Code Definitions） 299.1 消息1xx（Informational 1xx）299.2 成功2xx（Successful 2xx）299.3 重定向（Redirection 3xx）309.4 客户端错误（Client Error ）4xx 319.5 服务器错误（Server Error ）5xx 3210. 标题域定义（Header Field Definitions） 3310.1 允许（Allow） 3310.2 授权（Authorization） 3410.3 内容编码（Content-Encoding）3410.4 内容长度（Content-Length）3410.5 内容类型（Content-Type）3510.6 日期（Date）3510.7 过期（Expires）3610.8 来自（From）3710.9 从何时更改（If-Modified-Since）3710.10 最近更改（Last-Modified）3810.11 位置（Location） 3810.12 注解（Pragma）3910.13 提交方（Referer） 3910.14 服务器（Server） 4010.15 用户代理（User-Agent）4010.16 WWW-授权（WWW-Authenticate） 4011. 访问鉴别（Access Authentication）4111.1 基本授权方案（Basic Authentication Scheme）4212. 安全考虑（Security Considerations）4312.1 客户授权（Authentication of Clients） 4312.2 安全方法（Safe Methods）4312.3 服务器日志信息的弊端（Abuse of Server Log Information）4312.4 敏感信息传输（Transfer of Sensitive Information） 4412.5 基于文件及路径名的攻击（Attacks Based On File and Path Names）4413. 感谢（Acknowledgments）4514. 参考书目（References）4515. 作者地址（Authors' Addresses） 47附录（Appendices）48A. Internet介质类型消息/http（Internet Media Type message/http）48B. 容错应用（Tolerant Applications）48C. 与MIME的关系（Relationship to MIME）49C.1 转换为规范形式（Conversion to Canonical Form） 49C.2 日期格式转换（Conversion of Date Formats） 49C.3 内容编码介绍（Introduction of Content-Encoding）50C.4 无内容传输编码（No Content-Transfer-Encoding） 50C.5 多个主体的HTTP标题域（HTTP Header Fields in Multipart Body-Parts）50D. 附加特性（Additional Features） 50D.1 附加请求方法（Additional Request Methods） 51D.2 附加标题域定义（Additional Header Field Definitions）511. 介绍（Introduction）1.1 目的（Purpose）HTTP（Hypertext Transfer Protocol）是应用级协议，它适应了分布式超媒体协作系统对灵活性及速度的要求。

rfc函数RFC（Request for Comments）函数：用于构建可靠性高、可扩展性强的网络应用程序RFC函数是一种使用RFC（最新请求命令）标准执行凉白开或查询的函数。

它可以帮助应用程序用最新的标准，而无需担心不同的操作系统之间的兼容性问题。

这里我们将讨论通用的RFC函数，在jQuery和PHP中的用法，以及它的工作原理。

## 1. 综述RFC函数提供了跨平台的客户端服务器交互，使应用程序更轻松的访问服务器上的资源。

应用程序可以使用它执行一些功能性操作，比如：验证用户名和密码，获取资源，更新信息等。

这项技术支持应用程序使用标准的请求，而不必担心操作系统的兼容性问题。

RFC函数是由多种不同的编程语言支持的。

它能够以不同的方法应对不同的功能要求，而且在不同的框架中会有不同的实现方法。

它也支持类似AJAX的技术，使得应用程序可以在客户端发出请求，而不需要客户端做全部的操作。

## 2. 在jQuery中使用RPC函数在jQuery中使用RPC函数非常简单，因为它支持AJAX技术。

开发者可以使用jQuery的.ajax()方法发出请求，并且将服务器返回的响应数据解析成JSON文件。

另外，为了更方便的使用，jQuery还提供了一系列针对RPC的简单封装函数，包括$.getRPC(), $.postRPC()等。

开发者可以直接调用这些函数来发出请求，从而减少代码的编写和测试时间。

## 3. 在PHP中使用RPC函数在PHP中也可以使用RPC函数，但是在使用之前，应用程序必须做出一些配置。

首先，它需要安装一个cURL扩展，以及设置一些环境变量。

然后应用程序可以使用PHP的cURL函数发出请求，并且从服务器返回的数据中解析所需的内容。

在PHP中，应用程序可以使用类似Yaml、JSON格式的数据编码。

使用这种协议可以节约服务器资源，因为这种格式可以以更少的数据代表相同的信息量，从而提高数据传输速度。

## 4. 工作原理来看一下具体的工作原理，RPC函数要求应用程序在客户端发出一个标准的通信请求，比如HTTP请求，并携带一些参数代表特定的请求内容，比如客户端想要发出验证用户名和密码的请求，就必须携带参数用户名和密码。