3FL12936AAAAWBZZA_02

Alcatel 8690 SIGTRAN Description - Page 1All Rights Reserved 2007, Alcatel-Lucent

All rights reserved 2007, Alcatel-Lucent

Alcatel 8690 OSP - Alcatel 8690 SIGTRAN Description

Alcatel 8690 OSPAlcatel 8690 SIGTRAN

Description

TRAINING MANUAL

3FL12936AAAAWBZZAEdition 2

Copyright 2007 by Alcatel-Lucent - All rights reservedPassing on and copying of this document, use and

communication of its contents not permitted without written authorization from Alcatel-Lucent


All Rights Reserved Alcatel-Lucent 2007Alcatel 8690 OSP

Alcatel 8690 SIGTRAN Description

2

Legal Notice

Switch to notes view!Safety Warning

Both lethal and dangerous voltages are present within the equipment. Do not wear conductive jewelry

while working on the equipment. Always observe all safety precautions and do not work on the

equipment alone.

Caution

The equipment used during this course is electrostatic sensitive. Please observe correct anti-static

precautions.

Trade Marks

Alcatel and MainStreet are trademarks of Alcatel.

All other trademarks, service marks and logos (Marks) are the property of their respective holders

including Alcatel-Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel

or such third party owning the Mark. The absence of a Mark identifier is not a representation that a

particular product or service name is not a Mark.

Copyright

This document contains information that is proprietary to Alcatel-Lucent and may be used for training

purposes only. No other use or transmission of all or any part of this document is permitted without

Alcatel-Lucents written permission, and must include all copyright and other proprietary notices. No

other use or transmission of all or any part of its contents may be used, copied, disclosed or conveyed to

any party in any manner whatsoever without prior written permission from Alcatel-Lucent.

Use or transmission of all or any part of this document in violation of any applicable Canadian or other

legislation is hereby expressly prohibited.

User obtains no rights in the information or in any product, process, technology or trademark which it

includes or describes, and is expressly prohibited from modifying the information or creating derivative

works without the express written consent of Alcatel-Lucent.

Alcatel-Lucent, The Alcatel-Lucent logo, MainStreet and Newbridge are registered trademarks of Alcatel-

Lucent. All other trademarks are the property of their respective owners. Alcatel-Lucent assumes no

responsibility for the accuracy of the information presented, which is subject to change without notice.

2007 Alcatel-Lucent. All rights reserved.

Disclaimer

In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential

damages, including lost profits, lost business or lost data, resulting from the use of or reliance upon the

information, whether or not Alcatel has been advised of the possibility of such damages.

Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes

neither an endorsement nor a recommendation.

Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-

Lucent equipment and its operation.




3

Table of Contents

Switch to notes view!1. Sigtran Description

Module 1. Introduction

Module 2. SCTP

Module 3. M3UA

Module 4. Trace

Module 5. OSP 2.4 Sigtran presentation

Module 6. Abbreviations




4

Table of Contents [cont.]

Switch to notes view!

This page is left blank intentionally




5

Course Objectives


Welcome to Alcatel 8690 SIGTRAN Description

After successful completion of this course, you should understand:

Describe why SIGTRAN is needed

Describe the SIGTRAN architecture

Describe the main concepts of SCTP layer

Describe SCTP association establishment and shutdown

Describe the main concepts of SCTP data transmission

Describe the main concepts of M3UA layer

Describe the M3UA operation modes and services

Identify the M3UA messages

Describe the association establishment and Traffic failover scenarios

Analyze a SIGTRAN trace

Present the OSP 2.4 SIGTRAN Alcatel-Lucent solution




6

Course Objectives [cont.]






7

About this Student Guide

Switch to notes view!Conventions used in this guide

Where you can get further information

If you want further information you can refer to the following:

Technical Practices for the specific product

Technical support page on the Alcatel website: http://www.alcatel-lucent.com

Note

Provides you with additional information about the topic being discussed.

Although this information is not required knowledge, you might find it useful

or interesting.

Technical Reference (1) 24.348.98 Points you to the exact section of Alcatel-Lucent Technical

Practices where you can find more information on the topic being discussed.

WarningAlerts you to instances where non-compliance could result in equipment

damage or personal injury.




8

About this Student Guide [cont.]






9

Self-Assessment of Objectives

At the end of each section you will be asked to fill this questionnaire

Please, return this sheet to the trainer at the end of the training


Instructional objectives Yes (or globally yes)

No (or globally no)

Comments

1 Describe why SIGTRAN is needed

2 Describe the SIGTRAN architecture

3 Describe the main concepts of SCTP layer

4 Describe SCTP association establishment and shutdown

5 Describe the main concepts of SCTP data transmission

6 Describe the main concepts of M3UA layer

7 Describe the M3UA operation modes and services

8 Identify the M3UA messages

9 Describe the association establishment and Traffic failover scenarios

10 Analyze a SIGTRAN trace

11 Present the OSP 2.4 SIGTRAN Alcatel-Lucent solution

Contract number:

Course title: SIGTRAN M3UA Description

Client (Company, Center) :

Language: Dates from: to:

Number of trainees: Location:

Surname, First name:

Did you meet the following objectives?

Tick the corresponding box

Please, return this sheet to the trainer at the end of the training




10

Self-Assessment of Objectives [cont.]


Instructional objectives Yes (or Globally yes)

No (or globally no)

Comments

Thank you for your answers to this questionnaire

Other comments

Section 1 Module 1 Page 1

All Rights Reserved 2007, Alcatel-Lucent

3JK10348AAAAWBZZA Edition 2

Do not delete this graphic elements in here:

All Rights Reserved Alcatel-Lucent 2007

Alcatel 8690 OSP Alcatel 8690 SIGTRAN Description

11 Module 1Introduction3JK10348AAAAWBZZA Edition 2Section 1

Sigtran Description






Sigtran Description Introduction 1 1 2

Blank Page


First editionRosa Maria Izquierdo Kulich

2007-04-2101

RemarksAuthorDateEdition

Document History







Objectives

At the end of this chapter you will be able to:

Describe why SIGTRAN is needed.

Describe the SIGTRAN architecture.







Objectives [cont.]








Table of Contents

Switch to notes view! Page

1 Why SIGTRAN? 71.1 OSP in TDM Network 81.2 SS7 Overview 91.3 OSP in IP Network 101.4 Benefits of signaling over IP 11

2 SIGTRAN Architecture 122.1 SIGTRAN 132.2 SIGTRAN and SS7 152.2.1 SCTP Features 162.2.2 M3UA Features 17

2.3 SIGTRAN (M3UA) and SS7 19







1 Why SIGTRAN?







CAP

SSP

1 Why SIGTRAN?

1.1 OSP in TDM Network

MTPMTP

SS7SS7

INAP/CAP/MAP

MSC

SMS-C SGSNHLR

SRP

SP

SP

SP

SP SPSP

SP

INAP

CAP

CAP

MAP

INAP/CAP

FEPSLEE

SMP SDP

SCP

OSP

ISUP

The fundamental principle of CCSS#7 (SS7) is the division of functions into a common Message Transfer

Part (MTP) and several User Parts.

The different user parts use the transport capability provided by MTP.

The complete MTP is capable of sending messages through the network. In addition, error detection and

correction, as well as flow control functionality are provided.

The Signaling System N 7 (SS7) is composed of 3 layers, named Message Transfer Part:

MTP1: Signaling Data Link Functions.

MTP2: Signaling Link Functions.

MTP3: Signaling Network Functions.







1 Why SIGTRAN?

1.2 SS7 Overview

SCCP

Transmission of bits

Packages the signaling message for error-free transmission

Signaling message handling functions

Connection-oriented protocol

Transfer of information between applications

Intelligent Network and Mobile applications

TCAP

INAP/CAP/MAP

MTP3

MTP2

MTP1 Timeslot E1/T1 board

LinksetLInk

SP, DestinationRoute

GTT GTTRSSN

BeginContinueAbort

IDPPACUI

Signaling Connection Control Part (SCCP)

SCCP is used to increase the functionality of MTP by adding a number of extra features. It corresponds to OSI Layer 3. Routing between two exchanges is now always supported, even when they are located in

different countries. Instead of only using a Point Code (MTP-parameter), which is a unique identification

of a node in a local network, an additional SCCP-parameter called Global Title is used to uniquely

identify a node worldwide.

An important parameter at SCCP level is the Sub System Number (SSN), which identifies the user of

SCCP. By including it in the message, the analysis at the destination will result in the delivery of the

information to the correct SCCP-user. Except when the user of SCCP is the Transaction Capabilities

Application Part (TCAP), in that case the SSN identifies the user of TCAP.

Transaction Capabilities Application Part (TCAP)

TCAP is an example of a user which uses the connectionless services of SCCP. In intelligent networks, the user of TCAP is the Intelligent Network Application Protocol (INAP).

Intelligent Network Application Protocol (INAP)

The user of TCAP in IN is INAP. In this part, the operations and their associated parameters are defined.

This part is related to an application, in this case intelligent networks. For other applications, for

instance mobile telecommunication, another application part is the user of TCAP, namely Mobile Application Part (MAP).

CAMEL Application Part (CAP)

CAP is the implementation of INAP in the mobile world.







1 Why SIGTRAN?

1.3 OSP in IP Network

CAP

SSP

M3UAM3UA//SCTPSCTP

IPIP

INAP/CAP/MAP

MSC

SMS-C SGSNHLR

SRP

SP

SP

SP

SP SPSP

SP

INAP

CAP

CAP

MAP

INAP/CAP

FEPSLEE

SMP SDP

AS

OSP

ISUP

The proliferation of packet-based protocols throughout the telephony industry has generated a need for

the transmission of signaling information through an IP-based network. Much of the development work on

methods to implement such information transport is still in its infancy. However, a number of standards

are emerging. One of the more notable standards is the work by the Internet Engineering Task Force,

IETF, SIGTRAN group.

The IETF have specified a number of signaling transport protocols and interworking layers that enable

SS7 like information to be conveyed through IP networks. IP is a transport mechanism, whereas SS7 is a

transport mechanism and network structure that provides user services. The IETF specifications provide a

migration path that combines the structure of existing networks with the advantages of IP transport.

M3UA: Message Transfer Part level 3 User Adaptation (one of SIGTRAN components)

SCTP: Stream Control Transmission Protocol (one of SIGTRAN components)

IP: Internet Protocol

SCCP: Signaling Connection Control Part

CAP: Camel Application Part

MAP: Mobile Application Part

INAP: Intelligent Network Application Protocol

SDP: Service Data Point

FEP: Front End Process

SLEE: Service Login Execution Environment

OSP: Open Service Platform

AS: Application Server

SP: Signaling Point

SMP: Service Management Point







1 Why SIGTRAN?

1.4 Benefits of signaling over IP

No need for specialized SS7 hardware.

Very large bandwidth

Fault resilient

Incremental approach to leveraging IP flexibility:

Flexible network maintenance and expansion: costs are lowered.

It allows migration toward a full NGN network architecture.

The IP network suppresses expensive long-distance TDM leased lines and replaces them by cost-effective IP links, reduces network infrastructure cost by removing Signaling Transfer Points (STPs) when possible and provides on-demand bandwidth opposed to fixed reserved bandwidth when using the TDM technology.

Very large bandwidth: at least 100 Mbits per IP link versus 64 Kbits or 2 Mbits per link with SS7.

Fault resilient: Session failure detection and Redundant Stream Control Transmission Protocol (SCTP).

Incremental approach to leveraging IP flexibility: It maintains existing network functions.







2 SIGTRAN Architecture








2.1 SIGTRAN

The SIGnaling TRANsport working group (SIGTRAN) of the IETF has defined User Adaptation Protocols

SIGTRAN

Architecture

Adaptation Protocol(xUA xPA)

Common signaling Transport(SCTP)

Standard Internet Protocol

(IP)

RFC 2960

RFC 4666

For M3UA

User Adaptation Protocols to provide the architectural model of signaling transport over IP networks.

The SIGTRAN protocol stack consists of 3 components:

A standard IP stack.

A common signaling transport protocol, Stream Control Transmission Protocol (SCTP): SCTP provides

connection-oriented reliable transfer of user messages between peer SCTP users (Adaptation layer

protocols). Note: The SCTP layer replaces the Transmission Control Protocol (TCP) layer.

Adaptation layer: The protocols defined for this layer are:

MTP2 Peer-to-peer Adaptation (M2PA),

MTP2 User Adaptation (M2UA),

MTP3 User Adaptation (M3UA),

SCCP User Adaptation (SUA).

SIGTRAN defines many IP-based protocols that replace almost all SS7 layers:

M2UA, M2PA for MTP2.

M3UA for MTP3.

ISDN User Adaptation (IUA).

SUA for SCCP.








2.1 SIGTRAN [cont.]

M3UA

SCTP

IP

SUAM2PA

SS7 ApplicationPart

SS7 link SS7 User part

M3UA: MTP3 User Adaptation enables SS7 user parts (SCCP, ISUP) to run over IP.

SCTP: Stream Control Transmission Protocol is a reliable transport

protocol operating on top of IP.

Stream Control Transmission Protocol (SCTP) provides very reliable transport of messages.

MTP2 User Adaptation (M2UA) is ideal for backhauling signaling links at a centralized location.

MTP2 Peer-to-peer Adaptation (M2PA) enables SS7 links to run over IP.

MTP3 User Adaptation (M3UA) enables SS7 User Parts (ISUP, SCCP) to run over IP.

SCCP User Adaptation (SUA) enables SS7 Application Parts (e.g. TCAP) to run over IP.

Why M3UA has been chosen?

M2UA is not suitable:

designed for MTP2 backhauling (invocation of remote MTP2 layer).

no full IP peer-to-peer mode, only IP-SS7 legacy interworking (for example, relay of legacy SS7

associated signaling terminated at an MGW toward an MGC through IP).

SUA is not suitable: unable to transport ISUP & BICC signaling.

M2PA could have been suitable:

only peer-to-peer mode: a legacy SS7 link is replaced by an "SS7 IP link" (an SCTP association).

MTP3 management is kept unchanged.

M2PA enabled STP can be needed in networks.








2.2 SIGTRAN and SS7

Data

User

MTP3

MTP

L1, L2

SS7 Stack

MTP3

IP

M3UAM3UA

SCTP

SUA

M2UAM2PA

TCAP

MAP/CAP/INAP

ISUP/BICC/TUP

IUA

Q931Q931

SIGTRAN Stack

SCCP

Stream Control Transmission Protocol (SCTP) provides very reliable transport required by SCN signaling.

MTP2 User Adaptation (M2UA) is ideal for backhauling signaling links at a centralized location.

MTP2 Peer-to-peer Adaptation (M2PA) enables SS7 links to run over IP.

MTP3 User Adaptation (M3UA) enables SS7 User Parts (ISUP, SCCP) to run over IP.

SCCP User Adaptation (SUA) enables SS7 Application Parts (e.g. TCAP) to run over IP.

The ISDN User Part (ISUP) defines the protocol and procedures used to set up, manage and release trunk circuits that carry voice and data calls over the Public Switched Telephone Network (PSTN). ISUP is used for both Integrated Services Digital Network (ISDN) and non-ISDN calls. Calls that originate and terminate at the same switch do not use ISUP signaling.

Bearer Independent Call Control (BICC) is an implementation of SS7 defined in ITU-T Recommendation Q.BICC and ANSI T1.BICC. BICC provides call control of telephone calls over the ISDN where the bearer is non-traditional. BICC can use the services of the Message Transfer Part.

The Telephone User Part (TUP) provides conventional PSTN telephony services across the SS7 network. TUP was the first layer 4 protocol defined by the standards bodies and as such did not provision for ISDN services. Prior to the introduction of ISUP, national variants of TUP have evolved which provide varying degrees of support for ISDN.

Q.931 (also called Q931) is a signaling protocol for ISDN communications that is used in Voice over IP (VoIP). The Q.931 protocol is involved in the setup and termination of connections.







2.2 SIGTRAN and SS7

2.2.1 SCTP Features

Ensures the error-free transmission of user messages.

Ensures in-sequence delivery of user messages.

Enables fast delivery.

Avoids head-of-line blocking.

Is a more suitable protocol than the TCP and the UDP.







2.2 SIGTRAN and SS7

2.2.2 M3UA Features

Provides an interface between SCTP and those applications that typically use the services of MTP3.

SCTP enables seamless peer-to-peer communication between MTP3 user applications in the IP network and identical applications in SS7 networks.

Provides services to the applications in the SS7 network and offers equivalent services to applications in the IP network.

Has a registered port: 2905.







2.2 SIGTRAN and SS7

2.2.2 M3UA Features [cont.]

M3UA

SCTP

IP

NIF

MTP3

MTP

L1, L2

MTP3 User

M3UA

SCTP

IP

MGC

MTP3 user

MTP3

MTP2

Level 1

SEP or STPSG

IP SS7

Nodal Interworking Function (NIF)

Consider a Media Gateway Controller (MGC) that needs to run an application as ISUP. The MGC can

implement M3UA over SCTP. The point is to identify where the MTP3 function really resides.

The real MTP3 resides at the Signaling Gateway (SG). M3UA simply enables the ISUP application at the

MGC to remotely access the MTP3 function at the SG, without the ISUP application realizing that the

MTP3 function is not local.

The MGC must have its own Signaling Point, separate from the Signaling point of the SG. In that case, the

SG functions like an STP and appears as an STP to the outside of the network. The SS7 network views the

MGC as a typical SS7 signaling endpoint to which access is achieved via one or more SG STPs.








2.3 SIGTRAN (M3UA) and SS7

MTP2 Link management Stream Control Transmission Protocol (SCTP)

MTP3 Configuration and provisioning

M3UA configuration and provisioning

SCCP and TCAP layers remain unchanged

Fully replaces

Fully replace







Answer the Questions

Why SIGTRAN is needed?

Mention the functions of SCTP.

Mention the functions of M3UA.







Summary

In this chapter, we have seen:

why SIGTRAN is needed.

the SIGTRAN architecture.







Self-Assessment on the Objectives

Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module

The form can be found in the first partof this course documentation







End of ModuleIntroduction




Do not delete this graphic elements in here:

All Rights Reserved Alcatel-Lucent 2007

Alcatel 8690 OSP Alcatel 8690 SIGTRAN Description

12 Module 2SCTP3JK10349AAAAWBZZA Edition 2Section 1

Sigtran Description






Sigtran Description SCTP 1 2 2

Blank Page


First editionRosa Maria Izquierdo Kulich

2007-04-2101

RemarksAuthorDateEdition

Document History







Objectives

At the end of this chapter you will be able to:

Describe the main concepts of SCTP layer.

Describe SCTP association establishment and shutdown.

Describe the main concepts of SCTP data transmission.







Objectives [cont.]








Table of Contents

Switch to notes view! Page

1 SCTP Presentation 71.1 SCTP Features 81.2 SCTP, UDP and TCP 91.3 SCTP Main Concepts 101.4 SCTP Overview 111.5 SCTP Packet Presentation 121.6 SCTP Packet and Chunks 131.7 Chunks 14

2 Association 172.1 Association Establishment 182.2 Graceful Termination of an Association 192.3 Aborting the Association 20

3 Data Transmission 223.1 SCTP Data Transmission 233.1.1 Reliable Transfer 243.1.1.1 Checksum 253.1.1.2 Transmission Sequence Number 263.1.1.3 SACK Mechanism 27

3.1.2 Flexible Delivery 293.1.3 Multi-Homing 313.1.3.1 Primary Path 323.1.3.2 Transport address states 333.1.3.3 Rules to Transmit to the Destination Address 343.1.3.4 Path failure detection 353.1.3.5 End point failure detection 363.1.3.6 Network resilience example 373.1.3.7 HEARTBEAT 40

3.2 SCTP Robustness 413.3 SL, Association and Stream Relationship Example 42

4 Annexes: SCTP Messages Format 464.1 INIT and INIT Ack 474.2 Cookie Echo and Cookie Echo ACK 484.3 Shutdown 494.4 Abort Association 504.5 Payload Data 514.6 SACK 534.7 HEARTBEAT 544.8 Operation Error 55







1 SCTP Presentation







1 SCTP Presentation

1.1 SCTP Features

Reliable transport protocol operating on top of an IP, alternative to UDP, TCP.

SCTP offers acknowledged error-free non-duplicated transfer ofdatagrams (messages).

A selective retransmission mechanism is applied to correct loss or corruption of data.

SCTP multi-homing: nodes reached under several IP addresses.

SCTP multi-streaming: separates and transmits user data on multiple SCTP streams.

SCTP multi-homing: Support of multi-homed nodes feature is an essential property of SCTP; i.e. nodes, which can be, reached under several IP addresses.The multi-homing feature enables SCTP endpoints to

support multiple IP addresses. Multi-homing protects an association from potential network failures by

steering traffic to alternate IP addresses. During the initiation of an association, SCTP endpoints

exchange lists of IP addresses. Therefore, each endpoint can send and receive messages from any of the

IP addresses listed at the remote endpoint. For example, one of the listed IP addresses will be

designated as the primary address during the initiation. If the primary address repeatedly drops chunks,

however, all chunks will be transmitted to an alternate address until a connection to the primary address

can be reestablished.

SCTP multi-streaming: A stream is a unidirectional logical channel that permits exchange of messages between SCTP peer entities. When an association is set up, the number of available streams per

direction is exchanged between the peer entities.The multi-streaming feature separates and transmits

user data on multiple SCTP streams. These streams are capable of independent, sequenced delivery.

Message loss in a particular stream will only hinder delivery within that stream. Therefore, other streams

within an association are not affected. Through multi-streaming, SCTP eliminates unnecessary blocking

that often occurs in TCP transmissions. Since SCTP streams are independent, retransmitted and high-

priority messages can bypass less significant messages.







1 SCTP Presentation

1.2 SCTP, UDP and TCP

SCTPTCPUDP

Framing

Reliable

Ordering

PMTU fragmentation

Bundling

Multi-homing failover

Flow control congestion control

X X

XX

X

Optional &

multi-streamX

XX

X

XX

Multi-homing failover and Bundling are two new features in SCTP.







1 SCTP Presentation

1.3 SCTP Main Concepts

IP Network service

SCTP Endpoint

A

IP Network service

SCTP Endpoint

B

SCTPM3UA

IP@ IP@ IP@ Transport address

Primary path

Association

IP Address + Port Number

IP@ IP@ IP@

SCTPM3UA

HeaderVerification tag

CRC-32c


CRC-32cData headerData headerCtrl chunkCtrl chunk

Outbound stream

Inbound stream

Data chunkTSN

Data chunkTSN

Data chunk User message

Data chunkTSN

Data chunkTSN Data header

Data header Ctrl chunkCtrl chunkHeader

Verification tagCRC-32c


CRC-32c

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 is unique to an SCTP endpoint.

Association: Relationship between SCTP endpoints that allows their communication. An association is 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.

Transport Address: Traditionally defined by Network Layer address, Transport Layer protocol and Transport Layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the Transport protocol).

SCTP 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 (Protocol Data Unit (PDU) of SCTP that forms the payload of an IP packet).

Stream: A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service.

Chunk: A unit of information within an SCTP packet, consisting of a chunk header and chunk specific content.

Transmission Sequence Number (TSN): A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries.

Bundling: Multiple Data and control chunks may be bundled by the sender into a single SCTP packet for transmission, as long as the final size of the packet does not exceed the current path MTU. Each user message occupies its own data chuck. The receiver will unbundled the packet back into the original chunks. Control chunks must come before Data chunks in the packet. The fragmentation and bundling mechanisms are optional. The chunk bundling function of SCTP is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end.







1 SCTP Presentation

1.4 SCTP Overview

M3UA layer

Association

Sequenced delivery within streams

User Data Fragmentation

Acknowlegement and congestion

avoidance

Chunk Bundling

Packet Validation

Path management

Upper layers

IP layer

Request from M3UA user

Nb of streamers?

Conforms to PathMTU

TSN to each message; Rx end

Header and Chunks

Tag and 32-bit checksum fields

Destination transport @

The SCTP transport service can be fragmented into several functionalities:

Association Startup and Teardown: An association is initiated by a request from the SCTP user. A cookie mechanism is employed during the initialization to provide protection against security attacks.

Sequenced Delivery within Streams: The SCTP user can specify at association startup time the number of streams to be supported by the association.

User Data Fragmentation: SCTP supports fragmentation and reassembly of user messages to ensure that the SCTP packet passed to the lower layer conforms to the path Multiple-Tenant Unit (MTU).

Acknowledgement and Congestion Avoidance: SCTP assigns a Transmission Sequence Number (TSN) to each user data message (fragmented or unfragmented). The receiving end acknowledges all TSNs

received, even if there are gaps in the sequence.

Chunk Bundling: The SCTP packet delivered to the lower layer consists of a common header followed by one or more chunks.

Packet Validation: A mandatory verification tag field and a 32-bit checksum field are included in the SCTP common header.

Path Management: 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

reach ability status of the eligible destination set.

Multiple chunks may be multiplexed into one packet up to the Path-MTU size.







1 SCTP Presentation

1.5 SCTP Packet Presentation

SCTP packet: Protocol Data Unit (PDU) of SCTP that forms the payload of an IP packet.

Composed of Common Header and Chunks

Chunks: A unit information within an STCP packet that can contain control information or user data

SCTP Common Header Chunk #1 Chunk #N

Source port Dest. port

Verification tag

Checksum

Type Lenght

User data

FlagsProvides a key to verify if the packet in the correct association

Common Header

The common header consists of 12 bytes. For the identification of an association, SCTP uses the same

port concept as TCP and UDP. For the detection of transmission errors, each SCTP packet is protected by

a 32-bit checksum (CRC-32c algorithm), which is more robust than the 16-bit checksum of TCP and UDP.

SCTP packets with an invalid checksum are silently discarded. The common header also contains a 32-bit

value called verification tag. The verification tag is association specific, and exchanged between the endpoints at association startup. So there are two tag values used in one association.

Chunk

Each chunk begins with a chunk type field, which is used to distinguish data chunks and different types

of control chunks, followed by chunk specific flags and a chunk length field needed because chunks have

a variable length. The value field contains the actual payload of the chunk. An SCTP receiver MUST be

able to receive a minimum of 1500 bytes in one SCTP packet. This means that an SCTP endpoint MUST

NOT indicate less than 1500 bytes in its Initial a_rwnd sent in the INIT or INIT ACK. For transmission

efficiency, SCTP defines mechanisms for bundling of small user messages and fragmentation of large user

messages.

The Verification Tag value: Provides a key that allows a receiver to verify that an SCTP packet belongs to the current association; is chosen by each end of the association during association startup. Packets

received without the expected Verification Tag value are discarded. The Verification tag is randomly

generated.







1 SCTP Presentation

1.6 SCTP Packet and Chunks

SCTP Common Header

Chunk Id (8)

0x00 DATA 0x01 INIT **

0x02 INIT ACK **

0x03 SELECTIVE ACK

0x04 HEARTBEAT

0x05 HEARTBEAT ACK 0x06 ABORT **

0x07 SHUTDOWN

0x08 SHUTDOWN ACK **

0x09 ERROR

0x0A COOKIE 0x0B COOKIE ACK

0x0C ECNE reserved

0x0D CWR reserved

VENDOR SPECIFIC

** Cant be bundled with DATA

Chunk #1 Chunk #N

Chunk Flags (8)

Chunk Dependent

Chunk Length (16) Chunk Value

Parameter Type (16) Parameter Length (16)

Source Port 16 bitsDestination Port 16 bits

Verification Tag 32 bits

CRC-32c Checksum 32 bits

Control Chunks precede Data

Chunks if both are present in

same SCTP PDU

Fixed Parameters

Chunk Value

Parameter Value

Optional / Variable Parameter

VP #1 VP #N

Length (octets) =

len Chunk Id +

len Chunk Flags +

len Chunk Length +

len Chunk Value

Chunk

Common Header

The common header consists of 12 bytes. For the identification of an association, SCTP uses the same

port concept as TCP and UDP. For the detection of transmission errors, each SCTP packet is protected by

a 32-bit checksum (CRC-32c algorithm), which is more robust than the 16-bit checksum of TCP and UDP.

SCTP packets with an invalid checksum are silently discarded. The common header also contains a 32-bit

value called verification tag. The verification tag is association specific, and exchanged between the endpoints at association startup. So there are two tag values used in one association.

Chunk

Each chunk begins with a chunk type field, which is used to distinguish data chunks and different types

of control chunks, followed by chunk specific flags and a chunk length field needed because chunks have

a variable length. The value field contains the actual payload of the chunk.

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 padding.







1 SCTP Presentation

1.7 Chunks

Initiation (INIT)

Initiation Acknowledgement (INIT ACK)

Cookie Echo (COOKIE ECHO)

Cookie Acknowledgement (COOKIE ACK)

Shutdown Association (SHUTDOWN)

Shutdown Acknowledgement (SHUTDOWN ACK)

Shutdown Complete (SHUTDOWN COMPLETE)

Abort Association (ABORT)

Payload Data

Selective Acknowledgement (SACK)

Heartbeat Request (HEARBEAT)

Heartbeat Acknowledgement (HEARTBEAT ACK)

Operation error (ERROR)

To establish an association

To gracefully shutdown or terminate an association

Data transfer and selective acknowledgement

To test reachability of a particular destination transport address defined in the association

The Initiation chunk (INIT) is used to initiate an SCTP association between two endpoints.

The Initiation Acknowledgement chunk (INIT ACK) is used to acknowledge the initiation of an SCTP association.

The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable

parameters:

the State Cookie

the Unrecognized Parameter.

The Cookie Echo chunk (COOKIE ECHO) is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk MUST

precede any DATA chunk sent within the association, but MAY be bundled with one or more DATA chunks

in the same packet.

The Cookie Acknowledgement chunk (COOKIE ACK) is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE ECHO chunk. This chunk MUST precede

any DATA or SACK chunk sent within the association, but MAY be bundled with one or more DATA chunks

or SACK chunk in the same SCTP packet.

The Shutdown Association chunk (SHUTDOWN) MUST be used by an endpoint in an association to initiate a graceful close of the association with its peer.

The Shutdown Acknowledgement chunk (SHUTDOWN ACK) MUST be used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. The SHUTDOWN ACK chunk has no

parameters.

The Shutdown Complete chunk (SHUTDOWN COMPLETE) MUST be used to acknowledge the receipt of the SHUTDOWN ACK chunk at the completion of the shutdown process. The SHUTDOWN COMPLETE chunk

has no parameters.




The Abort Association chunk (ABORT) is sent to the peer of an association to close the association. The ABORT chunk may contain Cause Parameters to inform the receiver of the reason for the abort. DATA

chunks MUST NOT be bundled with ABORT. Control chunks (except for INIT, INIT ACK and SHUTDOWN

COMPLETE) MAY be bundled with an ABORT but they MUST be placed before the ABORT in the SCTP

packet, or they will be ignored by the receiver.

If an endpoint receives an ABORT with a format error or for an association that doesn't exist, it MUST

silently discard it. Moreover, under any circumstances, an endpoint that receives an ABORT MUST NOT

respond to that ABORT by sending an ABORT of its own.

The Payload Data chunk is used to send user messages.

The Selective Acknowledgement chunk (SACK) is sent to the peer endpoint to acknowledge received DATA chunks and to inform the peer endpoint of gaps in the received subsequences of DATA chunks as

represented by their TSNs. The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver

Window Credit (a_rwnd) parameters.

The Heartbeat Request chunk (HEARTBEAT) is sent by an endpoint to its peer endpoint to probe the reachability of a particular destination transport address defined in the present association.

The parameter field contains the Heartbeat Information which is a variable length opaque data structure

understood only by the sender.

The Heartbeat Acknowledgement chunk (HEARTBEAT ACK) is sent by an endpoint to its peer endpoint as a response to a HEARTBEAT chunk. A HEARTBEAT ACK is always sent to the source IP address of the IP

datagram containing the HEARTBEAT chunk to which this ack is responding.

The parameter field contains a variable length opaque data structure.

The Operation error chunk (ERROR) is sent by an endpoint to its peer endpoint to notify it of certain error conditions. It contains one or more error causes. An Operation Error is not considered fatal in and

of itself, but may be used with an ABORT chunk to report a fatal condition.

Each error cause may carry its own set of parameters. The error causes that have been defined are:

Cause Code Value Cause Code

1 Invalid Stream Identifier

2 Missing Mandatory Parameter

3 Stale Cookie Error

4 Out of Resource

5 Unresolvable Address

6 Unrecognized Chunk Type

7 Invalid Mandatory Parameter

8 Unrecognized Parameters

9 No User Data

10 Cookie Received While Shutting Down








What is an association?

What is a chunk?

What is a transport address?

What is the composition of an SCTP packet?







2 Association







2 Association

2.1 Association Establishment

SCTP Endpoint A SCTP Endpoint B

INIT

INIT ACK

COOKIE ECHO

COOKIE ACK

Association is established

Closed

Established

Cookie wait

CookieEchoed

Established

Cookie with values, IP@, secret keyCookie with values,

IP@ secret key

Unpacks data, verifysecret key

Ready to send and receive data through a destination transport address

The server receives an association setup request (an INIT chunk) usually in the CLOSED state and analyzes

the data contained in that chunk. From that, it generates all the values needed on its side to enter an

established association, and generates a secure hash of these values and a secret key. The values are

then put into the so-called COOKIE, along with the derived Message Authentication Code (MAC). This

COOKIE is returned to the sender of the INIT chunk in an INIT ACK chunk. The server remains in the

CLOSED state and forgets all about the received INIT chunk.

Upon reception of a COOKIE ECHO chunk (which contains a COOKIE data structure as parameter), the

server unpacks the data contained in this COOKIE and uses again the MAC contained therein to verify

whether it was the originator of this COOKIE. If the MAC computes okay, it is a valid COOKIE that this

server had created before, and the data values contained in the COOKIE are used to initialize the SCTP

instance. The server will send a COOKIE-ACK to the client (optionally bundling a data chunk with this

COOKIE-ACK chunk) and enter the ESTABLISHED state. It is then ready to accept data or send data chunks

itself.

The INIT chunk can contain one or more IPv4 (4 bytes) or IPv6 (16 bytes) addresses, or it can contain a

host name that can be resolved to one or more IP addresses.

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.







2 Association

2.2 Graceful Termination of an Association


SHUTDOWN

SHUTDOWN ACK

SHUTDOWN COMPLETE

Closed

Closed

Data acknowledgement

Shutdown primitive

Stops accepting data, outstanding data acknowledgement

Removes all data from this association

Remove all data from this association

An association begins with an "initiation" and is maintained until all data has been successfully

transmitted and received. Once all data is successfully received, the association is gracefully terminated

through a "shutdown."

Upon receiving the SHUTDOWN primitive from its upper layer user process, an SCTP instance should stop

accepting data from this process, and start sending a SHUTDOWN chunk, as soon as all of its outstanding

data has been acknowledged. This process is secured by a timer, that repeats this process, should the

SHUTDOWN be lost.

The peer will, at one point, receive the SHUTDOWN, and reply by sending a SHUTDOWN ACK chunk, as

soon as all of its data has been acknowledged (also secured by a timer!).When the first peer (that started the shutdown procedure) receives the SHUTDOWN ACK, it will stop the

timer, send a SHUTDOWN COMPLETE and remove all data still belonging to that association, and enter

the CLOSED state.

The peer that receives this SHUTDOWN COMPLETE chunk may then also remove all record of this

association, and enter the CLOSED state. Should the last SHUTDOWN COMPLETE message be lost, the

peer will repeat sending SHUTDOWN ACK chunks, until an error counter has been exceeded, which

reports the other peer unreachable.







2 Association

2.3 Aborting the Association

ABORT (no data chuck)

ClosedClosed

Validates the chunk Removes the association Reports termination to its upper layer process

The peers Verification Tag in the outbound packet must be filled

SCTP SCTP

An endpoint may also decide to abort an existing association, taking into account that data still in flight

may not be acknowledged, by sending an ABORT chunk to its peer endpoint. The sender MUST fill in the

peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT.

The receiver of the ABORT does not reply, but validates the chunk and removes the association, if the

ABORT contains the correct tag value. If so, it also reports termination to its upper layer process.

Should the ABORT be lost, and the endpoint sending it terminates directly after sending it, it will take a

rather long time to determine that the peer has gone (i.e., after the Peer Error Counter has been

exceeded).

The ABORT chunk is sent by an endpoint to end an association abruptly. It may contain cause information

regarding the reason for aborting the association. The ABORT chuck may be multiplexed with other

control chucks into one packet. In this case, the ABORT should be the last chuck in the packet. If it is not

the case, then subsequent chucks in the packet are ignored. DATA chuck should not be included in the

same packet as an ABORT chuck.

Special cases:

Peer restart case, where the peer uses a new tag value.

Cross initialization, where both peers send an INIT chunk at the same time.

Excessive delay of COOKIE chunk.

One peer trying to re-establish an association, while the other one tries to terminate it.








Mention the parameters that are negotiated during the association establishment.

What is the difference between "shutdown" and "abort" an association?







3 Data Transmission







3 Data Transmission

3.1 SCTP Data Transmission

Reliable transfer

Flexible delivery

Multi-homing








3.1.1 Reliable Transfer

Checksum

Transmission Sequence Number (TSN)

Selective retransmission mechanism








3.1.1.1 Checksum

SCTP Endpoint

ASender

HeaderVerification tag: Chosen during

Association startup

CRC-32c calculated by sender

HeaderVerification tag: Chosen during

Association startup

CRC-32c calculated by sender

DataheaderDataheader

CtrlchunkCtrlchunk

Data chunkTSN

Data chunkTSN

CRC-32c calculated by receiverCRC-32c calculated by sender

PACKET OK

CRC-32c calculated by receiverCRC-32c calculated by sender

INVALID PACKET

Checksum = 0

Checksum = Value

SCTP Endpoint

AReceiver

1

2

3

Checksum = Value

Checksum = 0 and calculates a new checksum

1

3

2

PACKET RECEIVED WITHOUT THE EXPECTED VERIFICATION TAG ARE DISCARDED!

The CRC-32c 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 CRC-32c

checksum silently discards the packet.

After the packet is constructed (containing the SCTP common header and one or more control or DATA

chunks), the transmitter shall:

1. Fill in the proper Verification Tag in the SCTP common header and initialize the checksum field to 0's.

2. Calculate the CRC-32c checksum of the whole packet, including the SCTP common header and all the

chunks.

3. Put the resultant value into the checksum field in the common header and leave the rest of the bits

unchanged.

The receiver must (numbers in green):

1. Store the received CRC-32c checksum value aside,

2. Replace the 32 bits of the checksum field in the received SCTP packet with all '0's and calculate an

CRC-32c checksum value of the whole received packet.

3. Verify that the calculated CRC-32c checksum is the same as the received CRC-32c checksum. If not,

the receiver must treat the packet as an invalid SCTP packet.

Details about SCTP checksum calculation can be found in the RFC 3309, that updates RFC 2960

concerning Cheksum.








3.1.1.2 Transmission Sequence Number


PAYLOAD DATA (TSN)

SACK Lost and Duplicated TSNs

TSN: Gaps and Duplication detection

Detection of loss and duplication of data chunk is enabled by numbering

all data chunks in the sender with a TSN.

The acknowledgements sent from the receiver to the sender are based on TSN numbers.

Retransmissions are time controlled. The timer duration is derived from continuous measurements of the round trip delay. Whenever such a transmission timer expires (and congestion control allows transmissions), all non-acknowledged data chunks are retransmitted and the timer is started again doubling its initial duration (like TCP).

When the receiver detects one or more gaps in the sequence of data chunks, each received SCTP packet is acknowledged by sending a SACK which reports all gaps. The SCAK is contained in a specific control chunk. Whenever the sender receives 4 consecutive SACKs reporting the same data chunk missing, this data chunk is immediately retransmitted (fast retransmit).








3.1.1.3 SACK Mechanism

SCTP Sender SCTP receiver

CHDH CtrlDataTSN 1

DataTSN 2

DataTSN 3

DH DHDHDataTSN 4

CHCHSACK

TSN 8, a_rwnd = 4600SACK

TSN 8, a_rwnd = 4600

One SACK:

is sent for at least every second data packet received

acknowledges multiple data chunks

CHDH CtrlDataTSN 9

DataTSN 10

DataTSN 11

DH DHDHDataTSN 12

cwnd

Payload data packet 1

CHDH CtrlDataTSN 5

DataTSN 6

DataTSN 7

DH DHDHDataTSN 8

Payload data packet 2

An SCTP endpoint must always acknowledge the reception of each valid data chunk.

CH: Common Header

DH: Data Header

The acknowledgements sent from the receiver to the sender are based on TSN numbers.

Retransmissions are time controlled. The timer duration is derived from continuous measurements of the round trip delay. Whenever such a transmission timer expires (and congestion control allows transmissions), all non-acknowledged data chunks are retransmitted and the timer is started again doubling its initial duration (like TCP).

When the receiver detects one or more gaps in the sequence of data chunks, each received SCTP packet is acknowledged by sending a SACK which reports all gaps. The SCAK is contained in a specific control chunk. Whenever the sender receives four consecutive SACKs reporting the same data chunk missing, this data chunk is immediately retransmitted (fast retransmit).

ACK generated within 200ms of the arrival of any unknowledgeable data chunk

If a_rwnd = 0 the sender must not transmit new data.

The sender must not transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address.

When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks which are marked for retransmission (limited by the currentcwnd).

The current congestion window (Cwnd) is 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.








3.1.1.3 SACK Mechanism [cont.]

11

10

9

8

7

6

5

4

3

2

1

11

10

8

7

4

3

2

1

11

Gap

Cumulative TSN ACK = 4

Gap

Nb of Gap Ack

Blocks N = 2

Nb of Duplicate

TSNs X = 1

Tx Rx

7 4 = 3

8 4 = 4

10 4 = 6

11 4 = 7

Gap Ack Block # 1 and 2

Start and End

calculation

The reliable transfer of user data is achieved by the use of two SCTP chunks:

Payload Data Chunk.

Selective Acknowledgement (SACK).

Detection of loss and duplication of data chunks is enabled by numbering all data chunks in the sender

with the so-called Transmission Sequence Number (TSN). The acknowledgements sent from the receiver

to the sender are based on these sequence numbers.

Retransmissions are timer-controlled.

When the receiver detects one or more gaps in the sequence of data chunks, each received SCTP packet

is acknowledged by sending a SACK which reports all gaps. The SACK is contained in a specific control

chunk. Whenever the sender receives four consecutive SACKs reporting the same data chunk missing, this

data chunk is immediately retransmitted (fast retransmit).

Let's assume that an endpoint has transmitted data chunk 1 through 11. Let's also assume that chunks

with TSNs 1 through 4 and those with TSNs 7, 8, 10 and 11 have been received. Hence, chunk 5, 6, and 9

are missing. Lets also assume that chunks with TSN 8 and 11 have been received twice.

The Cumulative TSN ACK parameter contains the highest TSN value received without any gaps.

The number of Gap Ack Blocks (N) indicates the number of fragments received after the unbroken sequence. So, N=2 (from 7 to 8 and from 10 to 11).

The number of Duplicate TSNs (X) indicates the number of TSNs that have been received more than once.

The Gap Ack Block number 1 start field indicates the offset of the first segment from the unbroken sequence. This is the difference between the TSN value in the Cumulative TSN ACK field and the lowest

TSN value of the first segment.








3.1.2 Flexible Delivery

User application

SCTP layer

IP layer

User messages

2B 2A 1

Fragmentation

Bundling

2B 2A 1

DATA chunk queue

Control chunks

Message 1 Message 2

Data chunk headerSCTP control chunks

SCTP common header

IP header

Fragmentation

Flexible delivery is based on the notion of several independent streams of datagrams within an

association.

Chunks belonging to one or several streams may be bundled and transmitted in one SCTP packet.

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.

Bundling

Multiple Data and control chunks may be bundled by the sender into a single SCTP packet for

transmission, as long as the final size of the packet does not exceed the current path MTU. Each user

message occupies its own data chuck. The receiver will unbundled the packet back into the original

chunks. Control chunks must come before Data chunks in the packet. The fragmentation and bundling

mechanisms are optional. The chunk bundling function of SCTP is responsible for assembly of the

complete SCTP packet and its disassembly at the receiving end.

An endpoint bundles chunks by simply including multiple chunks in one outbound SCTP packet. The total

size of the resultant IP datagram, including the SCTP packet and IP headers, MUST be less or equal to the

current Path MTU. If its peer endpoint is multi-homed, the sending endpoint shall choose a size not

larger than the latest MTU of the current primary path.








3.1.2 Flexible Delivery [cont.]

SCTP layer

Stream reordering queues

DATA chunks

Fragmented DATA chunks

Message 1 Message 2

IP layer

Control chunk

UnbundlingReassembly

12B 2AUser messages

User application








3.1.3 Multi-Homing

Primary path

Rules to transmit to the destination address

Heartbeat

Error







3.1.3 Multi-Homing

3.1.3.1 Primary Path

Is there any IP IP addressaddress(es) or host name present in

INIT or INIT ACK?

Is there any host host namenameparameter present in INIT or INIT ACK?

Endpoint derives the transport transport addressaddress(es)

Endpoint takes the source IP source IP addressaddresswhich the chunk arrives and derives the transport transport addressaddress

After all the transport addresses are derived, the Endpoint shall select one of the transport addresses as initial Primary Path

Yes No

Yes No

Endpoint resolves the list of IP address(es) and derives the transport transport addressaddress(es)

An SCTP endpoint is considered multi-homed if there are more than one transport address that can be

used as a destination address to reach that endpoint.

Endpoint derives the transport address combining IP address(es) and SCTP source port (from common

header).

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.

In case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported

type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address

Types' parameter in the new INIT to indicate what types of address it prefers.

The receiver of the INIT or INIT ACK MUST NOT send user data (piggy-backed or stand-alone) to its peer

until the host name is successfully resolved.

If the name resolution is not successful, the endpoint MUST immediately send an ABORT with

"Unresolvable Address" error cause to its peer. The ABORT shall be sent to the source IP address from

which the last peer packet was received.

An endpoint should transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination

transport address from which it received the DATA or control chunk to which it is replying. This rule

should also be followed if the endpoint is bundling DATA chunks together with the reply chunk. However,

when acknowledging multiple DATA chunks received in packets from different source addresses in a

single SACK, the SACK chunk may be transmitted to one of the destination transport addresses from

which the DATA or control chunks being acknowledged were received.

When a receiver of a duplicate DATA chunk sends a SACK to a multi-homed endpoint, it MAY be

beneficial to vary the destination address and not use the source address of the DATA chunk. The reason

being that receiving a duplicate from a multi-homed endpoint might indicate that the return path (as

specified in the source address of the DATA chunk) for the SACK is broken.







3.1.3 Multi-Homing

3.1.3.2 Transport address states

Active destination transport address:

A transport address on a peer endpoint which a transmitting endpoint considers available for receiving user messages.

Idle destination transport address:

An address that has not had user messages sent to it within some length of time, normally the HEARTBEAT interval or greater.

Inactive destination transport address:

An address which is considered inactive due to errors and unavailable to transport user messages.







3.1.3 Multi-Homing

3.1.3.3 Rules to Transmit to the Destination Address

A. By default, an endpoint should always transmit to the primary path.

B. An endpoint should transmit reply chunks (e.g. SACK) to the same destination transport address from which it received the DATA or control chunk to which it is replying.

C. When a receiver of a duplicate DATA chunk sends a SACK to a multi-homed endpoint, it may be beneficial to vary the destination addressand not use the source address of the DATA chunk.

D. When the peer is multi-homed, an endpoint should try to retransmit a chunk to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.

A. Unless the SCTP user explicitly specifies the destination transport address (and possibly source transport address) to use.

B. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk.

C. However, when acknowledging multiple DATA chunks received in packets from different source addresses in a single SACK, the SACK chunk may be transmitted to one of the destination transport addresses from which the DATA or control chunks being acknowledged were received. The reason being that receiving a duplicate from a multi-homed endpoint might indicate that the return path (as specified in the source address of the DATA chunk) for the SACK is broken.

D. Retransmissions do not affect the total outstanding data count. However, if the DATA chunk is retransmitted onto a different destination address, both the outstanding data counts on the new destination address and the old destination address to which the data chunk was last sent shall be adjusted accordingly.







3.1.3 Multi-Homing

3.1.3.4 Path failure detection

End point 1 End point 2

10.102.1.1 10.102.1.17

10.102.1.1810.102.1.2

DATA TSN = 1

Path.max.Retrans = Y

Error Counter Destination Transport @ 1 = X

T3-rtx

T3-rtx expires

T3-rtx

T3-rtx cancel

X > Y Destination Transport Address is marked as InactiveInactive, Notification is sent to the Upper Layer

DATA TSN = 1

Destination @ 1

Destination @ 2

SACK TSN = 1

Destination @ 1 is unavailable

When its peer endpoint is multi-homed, an endpoint should keep a error counter for each of the

destination transport addresses of the peer endpoint.

Each time the T3-rtx timer expires on any address, or when a HEARTBEAT sent to an idle address is not

acknowledged within a RTO, the error counter of that destination address will be incremented.

When the value in the error counter exceeds the protocol parameter 'Path.Max.Retrans' of that

destination address, the endpoint should mark the destination transport address as inactive, and a

notification SHOULD be sent to the upper layer.

When the primary path is marked inactive (due to excessive retransmissions, for instance), the sender

MAY automatically transmit new packets to an alternate destination address if one exists and is active.

If more than one alternate address is active when the primary path is marked inactive only ONE

transport address SHOULD be chosen and used as the new destination transport address.







3.1.3 Multi-Homing

3.1.3.5 End point failure detection

End point 1 End point 2

10.102.1.1 10.102.1.17

10.102.1.1810.102.1.2

DATA TSN = 1

DATA TSN = 1

Association.max.Retrans = M

DATA TSN = 1DATA

TSN = 1

Counter = N

SACK TSN = 1Counter = 0

If N > MN > M End point 2 is unreachable!End point 2 is unreachable! Stop transmission to it, associations will pass to CLOSE state; SCTP reports to upper layer

T3-rtx

An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer

(including retransmissions to all the destination transport addresses of the peer if it is multi-homed).

If the value of this counter exceeds the limit indicated in the protocol parameter

'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop

transmitting any more data to it (and thus the association enters the CLOSED state).

In addition, the endpoint shall report the failure to the upper layer, and optionally report back all

outstanding user data remaining in its outbound queue.

The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the

reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint.

When configuring the SCTP endpoint, the user should avoid having the value of 'Association.Max.Retrans'

larger than the summation of the 'Path.Max.Retrans' of all the destination addresses for the remote

endpoint. Otherwise, all the destination addresses may become inactive while the endpoint still

considers the peer endpoint reachable. When this condition occurs, how the SCTP chooses to function

is implementation specific.







3.1.3 Multi-Homing

3.1.3.6 Network resilience example

SGP 1SGP 1

SCTP endpoint A

IP5 IP6

IP1 IP2

IP

network

ASP 1ASP 1

SCTP associations

Endpoint A -> Endpoint B

IP1IP3

IP1- IP4

IP2-IP3

IP2-IP4

primary path = IP1 IP3

Endpoint A -> Endpoint C

IP1-IP5

IP1-IP6

IP2-IP5

IP2-IP6


SCTP associations

Endpoint A -> Endpoint B

IP1IP3

IP1- IP4

IP2-IP3

IP2-IP4


Endpoint A -> Endpoint C

IP1-IP5

IP1-IP6

IP2-IP5

IP2-IP6

primary path = IP2 IP6SGP 1SGP 1

IP3 IP4

SCTP endpoint B SCTP endpoint C

Network resilience provided through SCTP is :

independent of the transport technology and its redundancy mechanisms

provide end-to-end protection (network, access routers, platform switches, NICs ..)

provides fast recovery (~500 ms)

But

leads to IP routing configuration complexity in core network and NEs

need to dominate source IP address assignment and SCTP primary paths assignments at local and

remote nodes

leads to high CPU processing for heartbeat messages processing (or dedicated offload hardware)







3.1.3 Multi-Homing

3.1.3.6 Network resilience example [cont.]

SCTP active path:

primary path

SCTP inactive path

IPnetworks

SCTP endpoint A

IP1 IP2

ASP 1ASP 1

SGP 1SGP 1

IP5IP6

SGP 1SGP 1

IP3 IP4

Endpoint B Endpoint C







3.1.3 Multi-Homing

3.1.3.6 Network resilience example [cont.]

IPnetworks

SCTP inactive path

SCTP Active path:

primary path

SCTP endpoint A

IP1 IP2

ASP 1ASP 1

SGP 1SGP 1

IP5IP6

Endpoint CSGP 1SGP 1

IP3 IP4

Endpoint B







3.1.3 Multi-Homing

3.1.3.7 HEARTBEAT


HEARBEAT (source IP@)

HEARBEAT ACK

IP@

Is an association Is idle

The HEARTBEAT chunk is used to query the reachability of a particular endpoint. Let's assume that no chunks need to be sent from endpoint A to endpoint B during a particular period of time. In that case, endpoint A will sent periodic HEARTBEAT messages to endpoint B, just to make sure that endpoint B is still alive. The HEARTBEAT contains sender-specific information and the receiver should respond with a HEARTBEAT ACK chunk containing heartbeat information copied form the receiver HEARBEAT chunk.







3 Data Transmission

3.2 SCTP Robustness

SCTP implements congestion control mechanisms:

a_rwnd

Path MTU

Multi-homed:

INIT

INIT ACK

SCTP ensures that an endpoint is aware of the reachability of another endpoint:

SACK

HEARTBEAT

Robustness means the network should implement procedures whereby failures or undesired occurrences are minimized. It is also the capability to handle a certain amount of failure in the network without a

significant reduction of quality. Furthermore, the network should provide a graceful rather than a drastic

degradation in the event of failure or overload.

Congestion control mechanisms

SCTP implements congestion control mechanisms to ensure that one endpoint does not flood another

with messages. SCTP incorporates Path MTU discovery so that messages are not send if they are too long

to be handled by the intervening transport network.

Multi-homed

Common header contains source and destination port numbers. INIT and INIT ACK chunks may contain

one or more IP addresses or a host name that can be resolved to one or more addresses. The inclusion of

theses parameters enables a given endpoint to be multi-homed (to have multiple addresses). If

Date post:	26-Nov-2015
Category:	Documents
Upload:	bleuhawk
View:	26 times
Download:	7 times

3FL12936AAAAWBZZA_02

Documents