SCTP协议官方原版.pdf-资料库

Network Working Group R. Stewart, Ed. Request for Comments: 4960 September 2007 Obsoletes: 2960, 3309 Category: Standards Track Stream Control Transmission Protocol Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. 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. Abstract This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. Stewart Standards Track [Page 1]

RFC 4960 Stream Control Transmission Protocol September 2007 Table of Contents 1. Introduction ....................................................5 1.1. Motivation .................................................5 1.2. Architectural View of SCTP .................................6 1.3. Key Terms ..................................................6 1.4. Abbreviations .............................................10 1.5. Functional View of SCTP ...................................10 1.5.1. Association Startup and Takedown ...................11 1.5.2. Sequenced Delivery within Streams ..................12 1.5.3. User Data Fragmentation ............................12 1.5.4. Acknowledgement and Congestion Avoidance ...........12 1.5.5. Chunk Bundling .....................................13 1.5.6. Packet Validation ..................................13 1.5.7. Path Management ....................................13 1.6. Serial Number Arithmetic ..................................14 1.7. Changes from RFC 2960 .....................................15 2. Conventions ....................................................15 3. SCTP Packet Format .............................................15 3.1. SCTP Common Header Field Descriptions .....................16 3.2. Chunk Field Descriptions ..................................17 3.2.1. Optional/Variable-Length Parameter Format ..........19 3.2.2. Reporting of Unrecognized Parameters ...............21 3.3. SCTP Chunk Definitions ....................................21 3.3.1. Payload Data (DATA) (0) ............................22 3.3.2. Initiation (INIT) (1) ..............................24 3.3.2.1. Optional/Variable-Length Parameters in INIT ........................27 3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........30 3.3.3.1. Optional or Variable-Length Parameters ....33 3.3.4. Selective Acknowledgement (SACK) (3) ...............34 3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................38 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......39 3.3.7. Abort Association (ABORT) (6) ......................40 3.3.8. Shutdown Association (SHUTDOWN) (7) ................41 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........41 3.3.10. Operation Error (ERROR) (9) .......................42 3.3.10.1. Invalid Stream Identifier (1) ............44 3.3.10.2. Missing Mandatory Parameter (2) ..........44 3.3.10.3. Stale Cookie Error (3) ...................45 3.3.10.4. Out of Resource (4) ......................45 3.3.10.5. Unresolvable Address (5) .................46 3.3.10.6. Unrecognized Chunk Type (6) ..............46 3.3.10.7. Invalid Mandatory Parameter (7) ..........47 3.3.10.8. Unrecognized Parameters (8) ..............47 3.3.10.9. No User Data (9) .........................48 3.3.10.10. Cookie Received While Shutting Down (10) ...............................48 Stewart Standards Track [Page 2]

RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.11. Restart of an Association with New Addresses (11) ......................49 3.3.10.12. User-Initiated Abort (12) ...............49 3.3.10.13. Protocol Violation (13) .................50 3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................50 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........51 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........51 4. SCTP Association State Diagram .................................52 5. Association Initialization .....................................56 5.1. Normal Establishment of an Association ....................56 5.1.1. Handle Stream Parameters ...........................58 5.1.2. Handle Address Parameters ..........................58 5.1.3. Generating State Cookie ............................61 5.1.4. State Cookie Processing ............................62 5.1.5. State Cookie Authentication ........................62 5.1.6. An Example of Normal Association Establishment .....64 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and ..........................................65 5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) .......................66 5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, .............................66 5.2.3. Unexpected INIT ACK ................................67 5.2.4. Handle a COOKIE ECHO when a TCB Exists .............67 5.2.4.1. An Example of a Association Restart .......69 5.2.5. Handle Duplicate COOKIE-ACK. .......................71 5.2.6. Handle Stale COOKIE Error ..........................71 5.3. Other Initialization Issues ...............................72 5.3.1. Selection of Tag Value .............................72 5.4. Path Verification .........................................72 6. User Data Transfer .............................................73 6.1. Transmission of DATA Chunks ...............................75 6.2. Acknowledgement on Reception of DATA Chunks ...............78 6.2.1. Processing a Received SACK .........................81 6.3. Management of Retransmission Timer ........................83 6.3.1. RTO Calculation ....................................83 6.3.2. Retransmission Timer Rules .........................85 6.3.3. Handle T3-rtx Expiration ...........................86 6.4. Multi-Homed SCTP Endpoints ................................87 6.4.1. Failover from an Inactive Destination Address ......88 6.5. Stream Identifier and Stream Sequence Number ..............88 6.6. Ordered and Unordered Delivery ............................88 6.7. Report Gaps in Received DATA TSNs .........................89 6.8. CRC32c Checksum Calculation ...............................90 6.9. Fragmentation and Reassembly ..............................91 6.10. Bundling .................................................92 7. Congestion Control .............................................93 7.1. SCTP Differences from TCP Congestion Control ..............94 Stewart Standards Track [Page 3]

RFC 4960 Stream Control Transmission Protocol September 2007 7.2. SCTP Slow-Start and Congestion Avoidance ..................95 7.2.1. Slow-Start .........................................96 7.2.2. Congestion Avoidance ...............................97 7.2.3. Congestion Control .................................98 7.2.4. Fast Retransmit on Gap Reports .....................98 7.3. Path MTU Discovery .......................................100 8. Fault Management ..............................................100 8.1. Endpoint Failure Detection ...............................100 8.2. Path Failure Detection ...................................101 8.3. Path Heartbeat ...........................................102 8.4. Handle "Out of the Blue" Packets .........................104 8.5. Verification Tag .........................................105 8.5.1. Exceptions in Verification Tag Rules ..............105 9. Termination of Association ....................................106 9.1. Abort of an Association ..................................107 9.2. Shutdown of an Association ...............................107 10. Interface with Upper Layer ...................................110 10.1. ULP-to-SCTP .............................................110 10.2. SCTP-to-ULP .............................................120 11. Security Considerations ......................................123 11.1. Security Objectives .....................................123 11.2. SCTP Responses to Potential Threats .....................124 11.2.1. Countering Insider Attacks .......................124 11.2.2. Protecting against Data Corruption in the Network ..........................................124 11.2.3. Protecting Confidentiality .......................124 11.2.4. Protecting against Blind Denial-of-Service Attacks ........................125 11.2.4.1. Flooding ................................125 11.2.4.2. Blind Masquerade ........................126 11.2.4.3. Improper Monopolization of Services .....127 11.3. SCTP Interactions with Firewalls ........................127 11.4. Protection of Non-SCTP-Capable Hosts ....................128 12. Network Management Considerations ............................128 13. Recommended Transmission Control Block (TCB) Parameters ......129 13.1. Parameters Necessary for the SCTP Instance ..............129 13.2. Parameters Necessary per Association (i.e., the TCB) ....129 13.3. Per Transport Address Data ..............................131 13.4. General Parameters Needed ...............................132 14. IANA Considerations ..........................................132 14.1. IETF-defined Chunk Extension ............................132 14.2. IETF-Defined Chunk Parameter Extension ..................133 14.3. IETF-Defined Additional Error Causes ....................133 14.4. Payload Protocol Identifiers ............................134 14.5. Port Numbers Registry ...................................134 15. Suggested SCTP Protocol Parameter Values .....................136 16. Acknowledgements .............................................137 Appendix A. Explicit Congestion Notification .....................139 Stewart Standards Track [Page 4]

RFC 4960 Stream Control Transmission Protocol September 2007 Appendix B. CRC32c Checksum Calculation ..........................140 Appendix C. ICMP Handling ........................................142 References .......................................................149 Normative References ..........................................149 Informative References ........................................150 1. Introduction This section explains the reasoning behind the development of the Stream Control Transmission Protocol (SCTP), the services it offers, and the basic concepts needed to understand the detailed description of the protocol. This document obsoletes [RFC2960] and [RFC3309]. 1.1. Motivation TCP [RFC0793] has performed immense service as the primary means of reliable data transfer in IP networks. However, an increasing number of recent applications have found TCP too limiting, and have incorporated their own reliable data transfer protocol on top of UDP [RFC0768]. The limitations that users have wished to bypass include the following: -- TCP provides both reliable data transfer and strict order-of- transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking offered by TCP causes unnecessary delay. -- The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time. -- The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts. -- TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks. Transport of PSTN signaling across the IP network is an application for which all of these limitations of TCP are relevant. While this application directly motivated the development of SCTP, other applications may find SCTP a good match to their requirements. Stewart Standards Track [Page 5]

RFC 4960 Stream Control Transmission Protocol September 2007 1.2. Architectural View of SCTP SCTP is viewed as a layer between the SCTP user application ("SCTP user" for short) and a connectionless packet network service such as IP. The remainder of this document assumes SCTP runs on top of IP. The basic service offered by SCTP is the reliable transfer of user messages between peer SCTP users. It performs this service within the context of an association between two SCTP endpoints. Section 10 of this document sketches the API that should exist at the boundary between the SCTP and the SCTP user layers. SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint (Section 1.3) to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations that may be generated from each endpoint’s lists. _____________ _____________ | SCTP User | | SCTP User | | Application | | Application | |-------------| |-------------| | SCTP | | SCTP | | Transport | | Transport | | Service | | Service | |-------------| |-------------| | |One or more ---- One or more| | | IP Network |IP address \/ IP address| IP Network | | Service |appearances /\ appearances| Service | |_____________| ---- |_____________| SCTP Node A |<-------- Network transport ------->| SCTP Node B Figure 1: An SCTP Association 1.3. Key Terms Some of the language used to describe SCTP has been introduced in the previous sections. This section provides a consolidated list of the key terms and their definitions. o Active destination transport address: A transport address on a peer endpoint that a transmitting endpoint considers available for receiving user messages. Stewart Standards Track [Page 6]

RFC 4960 Stream Control Transmission Protocol September 2007 o Bundling: An optional multiplexing operation, whereby more than one user message may be carried in the same SCTP packet. Each user message occupies its own DATA chunk. o Chunk: A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content. o Congestion window (cwnd): An SCTP variable that limits the data, in number of bytes, a sender can send to a particular destination transport address before receiving an acknowledgement. o Cumulative TSN Ack Point: The TSN of the last DATA chunk acknowledged via the Cumulative TSN Ack field of a SACK. o Idle destination address: An address that has not had user messages sent to it within some length of time, normally the HEARTBEAT interval or greater. o Inactive destination transport address: An address that is considered inactive due to errors and unavailable to transport user messages. o Message = user message: Data submitted to SCTP by the Upper Layer Protocol (ULP). o Message Authentication Code (MAC): An integrity check mechanism based on cryptographic hash functions using a secret key. Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties. In SCTP, it is used by an endpoint to validate the State Cookie information that is returned from the peer in the COOKIE ECHO chunk. The term "MAC" has different meanings in different contexts. SCTP uses this term with the same meaning as in [RFC2104]. o Network Byte Order: Most significant byte first, a.k.a., big endian. o Ordered Message: A user message that is delivered in order with respect to all previous user messages sent within the stream on which the message was sent. o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement. Stewart Standards Track [Page 7]

RFC 4960 Stream Control Transmission Protocol September 2007 o Path: The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths. o Primary Path: The primary path is the destination and source address that will be put into a packet outbound to the peer endpoint by default. The definition includes the source address since an implementation MAY wish to specify both destination and source address to better control the return path taken by reply chunks and on which interface the packet is transmitted when the data sender is multi-homed. o Receiver Window (rwnd): An SCTP variable a data sender uses to store the most recently calculated receiver window of its peer, in number of bytes. This gives the sender an indication of the space available in the receiver’s inbound buffer. o SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time. o SCTP endpoint: The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint. o SCTP packet (or packet): The unit of data delivery across the interface between SCTP and the connectionless packet network (e.g., IP). An SCTP packet includes the common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP DATA chunks. o SCTP user application (SCTP user): The logical higher-layer application entity which uses the services of SCTP, also called the Upper-Layer Protocol (ULP). Stewart Standards Track [Page 8]

资料库

SCTP协议官方原版.pdf

相关推荐

网络技术

热门标签

最新资料