- Forward


Stream Control Transmission Protocol (SCTP)
An Introduction


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Introduction
Back Forward
  • Specification:
    • RFC 4960,
  • Purpose:
    • Provide a mechanism for applications to reliably send and receive messages
  • Assumptions:
    • Access to a potentially unreliable datagram service
    • Applications are associated with ports
Properties
Back Forward
  • Connection/Session-Oriented:
    • Handshaking
    • State information is maintained
  • Reliable:
    • Error-free non-duplicated transfer of messages
  • Message-Oriented:
    • Transmission of complete messages (with the possibility of requiring a particular order-of-arrival)
    • Each message can contain one or more chunks (containing either control information or user DATA)
  • Controlled:
    • Flow control
    • Congestion control
  • Multi-Homing:
    • A single endpoint can support multiple IP addresses for redundancy purposes (i.e., to improve the probability of retransmissions reaching the destination)
Reliability in SCTP
Back Forward
  • Requirement:
    • "SCTP provides a reliable transport service, ensuring that data is transported across the network without error and in sequence."
  • Satisfying this Requirement:
    • Selective ACK - Receipt of DATA chunks is acknowledged by sending SACK chucks (that include the cumulative Transmission Sequence Number range received and non-cumulative TSNs that indicate gaps)
    • Aknowledgment (ACK) from the recipient (and retransmission if the ACK is not received in a given amount of time)
    • Use checksums
Flow and Congestion Control in SCTP
Back Forward
  • Requirement:
    • As in TCP
  • Satisfying this Requirement:
    • As in TCP
The Demultiplexing Process
Back Forward
  • Recall:
    • SCTP needs to know what process/application to deliver segments to
    • There may be more than one active connection at the same time
  • The Socket:
    • As in TCP, the connection can be characterized by a four-tuple consisting of the sending IP address and port and receiving IP address and port
Moving through the Stack/Layers
Back Forward
  • Moving Down:
    • The SCTP segment becomes the payload of the IP datagram
  • Moving Up:
    • The payload of the SCTP datagram is handed off to the process bound to the destination port
Required Functionality of Service Providers
Back Forward
  • Create a "welcoming channel" that waits for a connection
  • Receive connection-establishment requests
  • Send and/or receive messages
  • Close the connection
SCTP Packet Format
Back Forward
  • The Common Header:
    • Source Port (16 bits)
    • Destination Port (16 bits)
    • Verification Tag (32 bits) - agreed upon during handshaking
    • Checksum (32 bits)
  • Chunk Field Descriptions:
    • Chunk Type (8 bits)
    • Chunk Flags (8 bits)
    • Chunk Length (16 bits)
SCTP Packet Format (cont.)
Back Forward
  • Some Chunk Types:
    • 0 - Payload Data (DATA)
    • 1 - Initiation (INIT)
    • 2 - Initiation Acknowledgment (INIT ACK)
    • 3 - Selective Acknowledgment (SACK)
    • 4 - Heartbeat Request (HEARTBEAT)
    • 5 - Heartbeat Acknowledgment (HEARTBEAT ACK)
    • 7 - Shutdown (SHUTDOWN)
    • 8 - Shutdown (SHUTDOWN ACK)
    • 10 - State Cookie (COOKIE ECHO)
    • 11 - Cookie Acknowledgment (COOKIE ACK)
  • DATA Chunks:
    • Type (8 bits)
    • Reserved (5 bits)
    • Unordered Flag (1 bit)
    • Beginning Fragment Flag (1 bit)
    • Ending Fragment Flag (1 bit)
    • Length (16 bits)
    • Transmission Sequence Number/TSN (32 bits)
    • "Stream" Identifier (16 bits)
    • "Stream" Sequence Number (16 bits)
    • Payload Protocol Identifier (for use by applications)
    • User Data
  • Other Chunks:
    • Each has its own format
Establishing a Connection (Four-Way Handshake)
Back Forward
  1. Client sends INIT to server
    • Includes the client's Verification Tag
  2. Server responds with INIT ACK
    • Includes the client's Verification Tag and the server's verification Tag
    • Includes a cookie
    • The server does not keep any state information at this point
  3. Client responds with a COOKIE ECHO
    • Includes the cookie received from the server
  4. Server responds with a COOKIE ACK
    • The server now starts to maintain state information
    • When the client receives the COOKIE ACK it also starts to maintain state information
Closing a Connection (Three-Way Procedure)
Back Forward
  1. Peer A sends SHUTDOWN
  2. Peer Z receives SHUTDOWN and when there are no more outstanding DATA chunks, responds with a SHUTDOWN ACK
  3. Peer A receives the SHUTDOWN ACK and sends a SHUTDOWN COMPLETE
    • When peer A receives the SHUTDOWN ACK it deletes all state information (assuming it is in the SHUTDOWN-ACK-STATE state)
    • When peer Z receives the SHUTDOWN COMPLETE it deletes all state information
There's Always More to Learn
Back -