rfc2960.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,498 行 · 第 1/5 页

      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.

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 which 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.4) to provide the other endpoint



Stewart, et al.             Standards Track                     [Page 6]

RFC 2960          Stream Control Transmission Protocol      October 2000


   (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 which 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 Functional View of SCTP

   The SCTP transport service can be decomposed into a number of
   functions.  These are depicted in Figure 2 and explained in the
   remainder of this section.






















Stewart, et al.             Standards Track                     [Page 7]

RFC 2960          Stream Control Transmission Protocol      October 2000


                           SCTP User Application

         -----------------------------------------------------
          _____________                  ____________________
         |             |                | Sequenced delivery |
         | Association |                |   within streams   |
         |             |                |____________________|
         |   startup   |
         |             |         ____________________________
         |     and     |        |    User Data Fragmentation |
         |             |        |____________________________|
         |   takedown  |
         |             |         ____________________________
         |             |        |     Acknowledgement        |
         |             |        |          and               |
         |             |        |    Congestion Avoidance    |
         |             |        |____________________________|
         |             |
         |             |         ____________________________
         |             |        |       Chunk Bundling       |
         |             |        |____________________________|
         |             |
         |             |     ________________________________
         |             |    |      Packet Validation         |
         |             |    |________________________________|
         |             |
         |             |     ________________________________
         |             |    |     Path Management            |
         |_____________|    |________________________________|

           Figure 2: Functional View of the SCTP Transport Service

1.3.1 Association Startup and Takedown

   An association is initiated by a request from the SCTP user (see the
   description of the ASSOCIATE (or SEND) primitive in Section 10).

   A cookie mechanism, similar to one described by Karn and Simpson in
   [RFC2522], is employed during the initialization to provide
   protection against security attacks.  The cookie mechanism uses a
   four-way handshake, the last two legs of which are allowed to carry
   user data for fast setup.  The startup sequence is described in
   Section 5 of this document.

   SCTP provides for graceful close (i.e., shutdown) of an active
   association on request from the SCTP user.  See the description of
   the SHUTDOWN primitive in Section 10.  SCTP also allows ungraceful
   close (i.e., abort), either on request from the user (ABORT



Stewart, et al.             Standards Track                     [Page 8]

RFC 2960          Stream Control Transmission Protocol      October 2000


   primitive) or as a result of an error condition detected within the
   SCTP layer.  Section 9 describes both the graceful and the ungraceful
   close procedures.

   SCTP does not support a half-open state (like TCP) wherein one side
   may continue sending data while the other end is closed.  When either
   endpoint performs a shutdown, the association on each peer will stop
   accepting new data from its user and only deliver data in queue at
   the time of the graceful close (see Section 9).

1.3.2 Sequenced Delivery within Streams

   The term "stream" is used in SCTP to refer to a sequence of user
   messages that are to be delivered to the upper-layer protocol in
   order with respect to other messages within the same stream.  This is
   in contrast to its usage in TCP, where it refers to a sequence of
   bytes (in this document a byte is assumed to be eight bits).

   The SCTP user can specify at association startup time the number of
   streams to be supported by the association.  This number is
   negotiated with the remote end (see Section 5.1.1).  User messages
   are associated with stream numbers (SEND, RECEIVE primitives, Section
   10).  Internally, SCTP assigns a stream sequence number to each
   message passed to it by the SCTP user.  On the receiving side, SCTP
   ensures that messages are delivered to the SCTP user in sequence
   within a given stream.  However, while one stream may be blocked
   waiting for the next in-sequence user message, delivery from other
   streams may proceed.

   SCTP provides a mechanism for bypassing the sequenced delivery
   service.  User messages sent using this mechanism are delivered to
   the SCTP user as soon as they are received.

1.3.3 User Data Fragmentation

   When needed, SCTP fragments user messages to ensure that the SCTP
   packet passed to the lower layer conforms to the path MTU.  On
   receipt, fragments are reassembled into complete messages before
   being passed to the SCTP user.

1.3.4 Acknowledgement and Congestion Avoidance

   SCTP assigns a Transmission Sequence Number (TSN) to each user data
   fragment or unfragmented message.  The TSN is independent of any
   stream sequence number assigned at the stream level.  The receiving






Stewart, et al.             Standards Track                     [Page 9]

RFC 2960          Stream Control Transmission Protocol      October 2000


   end acknowledges all TSNs received, even if there are gaps in the
   sequence.  In this way, reliable delivery is kept functionally
   separate from sequenced stream delivery.

   The acknowledgement and congestion avoidance function is responsible
   for packet retransmission when timely acknowledgement has not been
   received.  Packet retransmission is conditioned by congestion
   avoidance procedures similar to those used for TCP.  See Sections 6
   and 7 for a detailed description of the protocol procedures
   associated with this function.

1.3.5 Chunk Bundling

   As described in Section 3, the SCTP packet as delivered to the lower
   layer consists of a common header followed by one or more chunks.
   Each chunk may contain either user data or SCTP control information.
   The SCTP user has the option to request bundling of more than one
   user messages into a single SCTP packet.  The chunk bundling function
   of SCTP is responsible for assembly of the complete SCTP packet and
   its disassembly at the receiving end.

   During times of congestion an SCTP implementation MAY still perform
   bundling even if the user has requested that SCTP not bundle.  The
   user's disabling of bundling only affects SCTP implementations that
   may delay a small period of time before transmission (to attempt to
   encourage bundling).  When the user layer disables bundling, this
   small delay is prohibited but not bundling that is performed during
   congestion or retransmission.

1.3.6 Packet Validation

   A mandatory Verification Tag field and a 32 bit checksum field (see
   Appendix B for a description of the Adler-32 checksum) are included
   in the SCTP common header.  The Verification Tag value is chosen by
   each end of the association during association startup.  Packets
   received without the expected Verification Tag value are discarded,
   as a protection against blind masquerade attacks and against stale
   SCTP packets from a previous association.  The Adler-32 checksum
   should be set by the sender of each SCTP packet to provide additional
   protection against data corruption in the network.  The receiver of
   an SCTP packet with an invalid Adler-32 checksum silently discards
   the packet.









Stewart, et al.             Standards Track                    [Page 10]

RFC 2960          Stream Control Transmission Protocol      October 2000


1.3.7 Path Management

   The sending SCTP user is able to manipulate the set of transport
   addresses used as destinations for SCTP packets through the
   primitives described in Section 10.  The SCTP path management
   function chooses the destination transport address for each outgoing
   SCTP packet based on the SCTP user's instructions and the currently
   perceived reachability status of the eligible destination set.  The
   path management function monitors reachability through heartbeats
   when other packet traffic is inadequate to provide this information
   and advises the SCTP user when reachability of any far-end transport
   address changes.  The path management function is also responsible
   for reporting the eligible set of local transport addresses to the
   far end during association startup, and for reporting the transport
   addresses returned from the far end to the SCTP user.

   At association start-up, a primary path is defined for each SCTP
   endpoint, and is used for normal sending of SCTP packets.

   On the receiving end, the path management is responsible for
   verifying the existence of a valid SCTP association to which the
   inbound SCTP packet belongs before passing it for further processing.

   Note: Path Management and Packet Validation are done at the same
   time, so although described separately above, in reality they cannot
   be performed as separate items.

1.4 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