Saturday, October 29, 2011

introduction to Stream Control Transmission protocol

2.1 Introduction to SCTP
SCTP is a new reliable transport –layer protocol developed to overcome some of the limitations of tcp. For example in TCP, each peer is allowed to use one IP address where as in SCTP a peer is allowed to use multiple IP addresses on different physical layers. This ensures high path availability as is required in telecommunication networks. SCTP inherits most of the features of tcp. It lies between the application layer and the network layer just like TCP and UDP as can be seen in figure 2.1.


 Figure 2.1. The OSI layer
SCTP was originally designed to carry signaling system number seven (SS7) messages over IP. TCP which is the dominant protocol on the internet could not carry ss7 messages due to the following:
i.                    Head of line blocking. Tcp provides a reliable data transfer and a strict byte order of transmission delivery of data. Since its connection is made of a single stream, whenever there is a packet loss, all subsequent packets must be queued until the lost packet is retransmitted. This leads to head of line blocking.
ii.                  TCP sockets are limited in scope. In tcp only one IP address can be used by a peer in setting up the connection. This means that only one physical path can exist between the source and destination, that means there’ll be no physical redundancy between the source and the destination.
iii.                Security.TCP is relatively vulnerable to denial of service attacks such SYN attack.
2.2  SCTP Features
Even though SCTP takes most of the features of TCP, it also exhibits some features that make give it some advantages over TCP. These are:
i.                    Multi – Streaming:
Multi – Streaming allows SCTP to send data on multiple logical channels (Streams) as shown in figure 2. The number of streams supported by each endpoint is communicated during Association establishment.  The major advantage of multi-streaming is that if a segment belonging to one stream is lost, the remaining segments in that stream may be blocked, but other streams will continue to deliver their segments to the application layer until the lost data arrives. This ensures that SCTP does not experience head of line blocking as in TCP. In SCTP however, head of line is limited to individual streams and not the entire association as in TCP.
     Figure 2.2 SCTP Multi - Streaming
The Head of Line phenomenon in SCTP is explained in figure 2[8].  SSN 11 in stream 1 has just been delivered to the application layer whereas SSN 9 of the second stream is lost. As a result, SSN 10, 11 and 12 will therefore be buffered until SSN 9 has arrived. Also SSN4 of stream 3 is lost; therefore SSN5 and 6 are being queued. SSN 7 arriving will therefore be added to the queue. In Stream 4, SSN 21 is being delivered to the application layer. Since 22 is has not yet arrived SSN 23 arriving will be blocked until SSN 22 has arrived.
Figure 2.3 Head of Line Blocking in SCTP
ii.                  Multi-Homing:
 In TCP each peer is allowed to use only one IP address . However in SCTP, each endpoint is allowed to use multiple IP addresses. This is called multi-homing. Multi-homing ensures that there is a redundancy at the network layer as well as the physical layer so that if one endpoint fails, SCTP can quickly switchover to another path. Even though multiple IP addresses are used by each endpoint, only one IP address is designated as the primary address. SCTP continue to send packets to this address unless there is a path failure. Retransmissions are however permitted on alternative IP addresses. Secondary paths can also be used upon request from Upper layer protocol. Figure 2.4 bellow shows a multi-homed SCTP association.
Figure2.4. Multi-homed SCTP
iii.                Ordered and Unordered delivery
Besides Multi- Streaming and Multi-Homing, SCTP also allows for packets to be delivered out of order to the application layer. This is done by setting the parameter U in the SCTP data Chunk to 1. Whenever SCTP receives a data packet out of order, the packet must be queued until the missing packet arrives. However, if the out of order packet has the parameter U in its header set 1, it is delivered to the application without any delay.
2.3      SCTP Packet Format
The SCTP packet is composed of a common header and a set of chunks. The chunks may contain either control information or user data. The control chunks control and maintain the association where as the data chunks carry user data. The control chunks usually come before the user data in the SCTP packet. Figure 4 bellow shows the general format of the SCTP packet.
      Figure 2.5 SCTP packet format
2.3.1   SCTP Common Header:
The Common header defines the endpoints of the association to which the packet belong. It guarantees that the packet belongs to a particular association and preserves the integrity of the contents of the packet including the header itself. The common header is shown in figure 5 bellow.
Figure 2.6 SCTP common Header.
SCTP common header consists of:
i.                    The Source port. This 16 bit field that defines the port number of the process sending the packet. It can be used together with the source IP address, the destination port number and the destination IP address to identify the association uniquely.
ii.                  Destination Port Number. This is a 16 bit field that identifies the port number of the receiving process. The receiver uses this number to de-multiplex the packet to the correct endpoint or application.
iii.                Verification tag. The verification tag is used by the receiver to validate the sender of the packet. It is 32 bits long and matches a packet uniquely to an association. This because it is set to the Initiate Tag received during association initiation.
iv.                Checksum. It contains a CRC-32 checksum of the SCTP packet. SCTP uses Adler 32 algorithm to compute this value.
2.4.1 Initiation (INIT) Chunk:
            This chunk is used to initiate an association. It is the first packet sent during association establishment. According to Steward R. et al, a packet carrying INIT chunk must not carry any other chunk. The INIT chunk is shown in figure 2.6. 
 


Figure 2.7 INIT Chunk
The INIT Chunk contains the following fields:
i.                    Initiate Tag. The Initiate tag defines the verification tag for the packet travelling in the opposite direction. The receiver of the INIT records this value as the verification tag to be used in every packet that it will send in the association. It is allowed to have any value except zero.
ii.                  Advertised Receiver Window Credit. It represents a dedicated buffer space in number of bytes the sender of the INIT chunk can accept. It allows the receiver to know how much data to transmit.
iii.                Outbound Stream (OS). The outbound stream is the number of streams the initiator of the association wishes to create towards the outbound peer. This value cannot zero. It can however be reduced by the receiver of the INIT chunk.
iv.                Maximum Number of Inbound Streams (MIS). This is the maximum number of streams that the sender of the INIT chunk wishes to support in the inbound direction. It is 16 bits long.
v.                  Initial TSN. This is the initial transmission sequence number (TSN) used in the outgoing direction. Each data chunk in the association will be assigned a TSN in the range of 1 to 232 -1. The initial TSN is chosen randomly by the sender of the INIT chunk.
vi.                Optional Parameters. This parameters may be added to define the transport address of the sending endpoint, the number of and the number of addresses the endpoint can support.
2.0.3     Initiation Acknowledgement (INIT ACK):
 This packet is used to acknowledge the receipt of the INIT chunk. It is the second chunk transmitted during association establishment and is not allowed to carry any other information. The verification tag in the INIT ACK is the value of the initiate tag in the INIT chunk. The rest of the fields in the main part of this chunk are the same as those of the INIT chunk except for the mandatory fields and the optional/variable length parameters.
Figure 2.9 INIT ACK
2.4.2    COOKIE ECHO
            This chunk is sent by the initiator of the association after receiving INIT ACK. A sender of COOKIE ECHO is allowed to add user data to this packet. However the user control information must come before the user data.
Figure 2.10 COOKIE ECHO

No comments:

Post a Comment