SCTP协议标准RFC4960详解

4星 · 超过85%的资源需积分: 15 101 浏览量更新于2024-07-26 收藏 228KB PDF 举报

"rfc4960-sctp" 本文档是关于RFC 4960，即Stream Control Transmission Protocol (SCTP)的规范，它更新了先前的RFC 2960和RFC 3309，并被定义为互联网标准轨道协议。SCTP最初设计用于在IP网络上传输公共交换电话网络（PSTN）的信号消息，但其功能远不止于此，具有广泛的应用潜力。 SCTP是一种在无连接的分组网络（如IP网络）上运行的可靠传输协议，提供以下服务： 1. 确认无错且无重复的数据传输：SCTP确保用户数据的可靠传输，通过确认机制和错误检测来避免数据丢失或重复。 2. 数据分片：根据发现的路径最大传输单元（MTU）大小对数据进行分片，以适应不同的网络环境，避免因MTU过大导致的包分段问题。 3. 多流有序交付：SCTP支持在一个连接中创建多个独立的逻辑流，每个流都保证顺序交付用户消息，提供了一种灵活的数据传输结构。 4. 故障恢复与容错：SCTP包含强大的故障检测和恢复机制，如心跳报文（Heartbeat）用于检测链路状态，以及关联（Association）和路径（Path）级别的故障恢复，确保在链路故障时能够快速恢复服务。 5. 流量控制与拥塞控制：SCTP提供了流级别的流量控制，防止发送方过快导致接收方缓冲区溢出，同时也实施拥塞控制策略，以减少网络拥塞并保护网络资源。 6. 地址多宿主（Multi-homing）支持：SCTP允许一个端点拥有多个网络地址，增强了网络的可用性和可靠性。即使其中一个网络接口出现故障，SCTP也能自动切换到其他活动接口继续通信。 7. 安全性：虽然SCTP本身并不提供加密，但可以与安全协议如IPsec结合使用，以增强传输的安全性。 8. 用户消息边界保留：SCTP保持用户消息的边界，这意味着接收方可以根据需要原样接收完整的用户消息，无需重组。总结来说，RFC 4960的SCTP是一种高度可靠的、灵活的传输协议，不仅适用于电话网络的信令传输，还可应用于需要高可靠性和顺序保证的其他应用，如多媒体通信、在线游戏和分布式系统中的数据交换。由于其特性，SCTP在现代互联网架构中扮演着重要角色，尤其是在需要高安全性和容错性的场景下。

RFC 4960 Stream Control Transmission Protocol September 2007

3.1. SCTP Common Header Field Descriptions

SCTP Common Header Format

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port Number | Destination Port Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Verification Tag |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Port Number: 16 bits (unsigned integer)

This is the SCTP sender’s port number. It can be used by the

receiver in combination with the source IP address, the SCTP

destination port, and possibly the destination IP address to

identify the association to which this packet belongs. The port

number 0 MUST NOT be used.

Destination Port Number: 16 bits (unsigned integer)

This is the SCTP port number to which this packet is destined.

The receiving host will use this port number to de-multiplex the

SCTP packet to the correct receiving endpoint/application. The

port number 0 MUST NOT be used.

Verification Tag: 32 bits (unsigned integer)

The receiver of this packet uses the Verification Tag to validate

the sender of this SCTP packet. On transmit, the value of this

Verification Tag MUST be set to the value of the Initiate Tag

received from the peer endpoint during the association

initialization, with the following exceptions:

- A packet containing an INIT chunk MUST have a zero Verification

Tag.

- A packet containing a SHUTDOWN COMPLETE chunk with the T bit

set MUST have the Verification Tag copied from the packet with

the SHUTDOWN ACK chunk.

- A packet containing an ABORT chunk may have the verification

tag copied from the packet that caused the ABORT to be sent.

For details see Section 8.4 and Section 8.5.

Stewart Standards Track [Page 16]

RFC 4960 Stream Control Transmission Protocol September 2007

An INIT chunk MUST be the only chunk in the SCTP packet carrying it.

Checksum: 32 bits (unsigned integer)

This field contains the checksum of this SCTP packet. Its

calculation is discussed in Section 6.8. SCTP uses the CRC32c

algorithm as described in Appendix B for calculating the checksum.

3.2. Chunk Field Descriptions

The figure below illustrates the field format for the chunks to be

transmitted in the SCTP packet. Each chunk is formatted with a Chunk

Type field, a chunk-specific Flag field, a Chunk Length field, and a

Value field.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Chunk Type | Chunk Flags | Chunk Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\ \

/ Chunk Value /

\ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Type: 8 bits (unsigned integer)

This field identifies the type of information contained in the

Chunk Value field. It takes a value from 0 to 254. The value of

255 is reserved for future use as an extension field.

The values of Chunk Types are defined as follows:

ID Value Chunk Type

----- ----------

0 - Payload Data (DATA)

1 - Initiation (INIT)

2 - Initiation Acknowledgement (INIT ACK)

3 - Selective Acknowledgement (SACK)

4 - Heartbeat Request (HEARTBEAT)

5 - Heartbeat Acknowledgement (HEARTBEAT ACK)

6 - Abort (ABORT)

7 - Shutdown (SHUTDOWN)

8 - Shutdown Acknowledgement (SHUTDOWN ACK)

9 - Operation Error (ERROR)

10 - State Cookie (COOKIE ECHO)

11 - Cookie Acknowledgement (COOKIE ACK)

Stewart Standards Track [Page 17]

RFC 4960 Stream Control Transmission Protocol September 2007

12 - Reserved for Explicit Congestion Notification Echo

(ECNE)

13 - Reserved for Congestion Window Reduced (CWR)

14 - Shutdown Complete (SHUTDOWN COMPLETE)

15 to 62 - available

63 - reserved for IETF-defined Chunk Extensions

64 to 126 - available

127 - reserved for IETF-defined Chunk Extensions

128 to 190 - available

191 - reserved for IETF-defined Chunk Extensions

192 to 254 - available

255 - reserved for IETF-defined Chunk Extensions

Chunk Types are encoded such that the highest-order 2 bits specify

the action that must be taken if the processing endpoint does not

recognize the Chunk Type.

00 - Stop processing this SCTP packet and discard it, do not

process any further chunks within it.

01 - Stop processing this SCTP packet and discard it, do not

process any further chunks within it, and report the

unrecognized chunk in an ’Unrecognized Chunk Type’.

10 - Skip this chunk and continue processing.

11 - Skip this chunk and continue processing, but report in an

ERROR chunk using the ’Unrecognized Chunk Type’ cause of

error.

Note: The ECNE and CWR chunk types are reserved for future use of

Explicit Congestion Notification (ECN); see Appendix A.

Chunk Flags: 8 bits

The usage of these bits depends on the Chunk type as given by the

Chunk Type field. Unless otherwise specified, they are set to 0

on transmit and are ignored on receipt.

Chunk Length: 16 bits (unsigned integer)

This value represents the size of the chunk in bytes, including

the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.

Therefore, if the Chunk Value field is zero-length, the Length

field will be set to 4. The Chunk Length field does not count any

chunk padding.

Stewart Standards Track [Page 18]

RFC 4960 Stream Control Transmission Protocol September 2007

Chunks (including Type, Length, and Value fields) are padded out

by the sender with all zero bytes to be a multiple of 4 bytes

long. This padding MUST NOT be more than 3 bytes in total. The

Chunk Length value does not include terminating padding of the

chunk. However, it does include padding of any variable-length

parameter except the last parameter in the chunk. The receiver

MUST ignore the padding.

Note: A robust implementation should accept the chunk whether or

not the final padding has been included in the Chunk Length.

Chunk Value: variable length

The Chunk Value field contains the actual information to be

transferred in the chunk. The usage and format of this field is

dependent on the Chunk Type.

The total length of a chunk (including Type, Length, and Value

fields) MUST be a multiple of 4 bytes. If the length of the chunk is

not a multiple of 4 bytes, the sender MUST pad the chunk with all

zero bytes, and this padding is not included in the Chunk Length

field. The sender MUST NOT pad with more than 3 bytes. The receiver

MUST ignore the padding bytes.

SCTP-defined chunks are described in detail in Section 3.3. The

guidelines for IETF-defined chunk extensions can be found in Section

14.1 of this document.

3.2.1. Optional/Variable-Length Parameter Format

Chunk values of SCTP control chunks consist of a chunk-type-specific

header of required fields, followed by zero or more parameters. The

optional and variable-length parameters contained in a chunk are

defined in a Type-Length-Value format as shown below.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Parameter Type | Parameter Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\ \

/ Parameter Value /

\ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stewart Standards Track [Page 19]

RFC 4960 Stream Control Transmission Protocol September 2007

Chunk Parameter Type: 16 bits (unsigned integer)

The Type field is a 16-bit identifier of the type of parameter.

It takes a value of 0 to 65534.

The value of 65535 is reserved for IETF-defined extensions.

Values other than those defined in specific SCTP chunk

descriptions are reserved for use by IETF.

Chunk Parameter Length: 16 bits (unsigned integer)

The Parameter Length field contains the size of the parameter in

bytes, including the Parameter Type, Parameter Length, and

Parameter Value fields. Thus, a parameter with a zero-length

Parameter Value field would have a Length field of 4. The

Parameter Length does not include any padding bytes.

Chunk Parameter Value: variable length

The Parameter Value field contains the actual information to be

transferred in the parameter.

The total length of a parameter (including Type, Parameter Length,

and Value fields) MUST be a multiple of 4 bytes. If the length of

the parameter is not a multiple of 4 bytes, the sender pads the

parameter at the end (i.e., after the Parameter Value field) with

all zero bytes. The length of the padding is not included in the

Parameter Length field. A sender MUST NOT pad with more than 3

bytes. The receiver MUST ignore the padding bytes.

The Parameter Types are encoded such that the highest-order 2 bits

specify the action that must be taken if the processing endpoint

does not recognize the Parameter Type.

00 - Stop processing this parameter; do not process any further

parameters within this chunk.

01 - Stop processing this parameter, do not process any further

parameters within this chunk, and report the unrecognized

parameter in an ’Unrecognized Parameter’, as described in

Section 3.2.2.

10 - Skip this parameter and continue processing.

11 - Skip this parameter and continue processing but report the

unrecognized parameter in an ’Unrecognized Parameter’, as

described in Section 3.2.2.

Stewart Standards Track [Page 20]

剩余151页未读，继续阅读

younel0921

粉丝: 1
资源: 5

SCTP协议标准RFC4960详解

RFC4960：官方StreamControlTransmissionProtocol（SCTP）详解

匹配RFC 2960 SCTP数据包的位掩码实现

SCTP协议问题与RFC 4960修订：经验与解决方案

RFC2960-(SCTP)中文标准

rfc3588-diameter协议

核心网-diameter-rfc3588-中文翻译版

rfc3588-diameter.pdf

RFC8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960.

rfc4960_internet_networkprogramming_made_

rfc2960cn_SCTP.txt

最新资源