Sigtran Ppt Final

Internet Telephony 1

SIGTRAN

o SIGTRAN (Signaling Transport) is a working group within the IETF Standard Organization.

o The SigTran Working Group defined the framework architecture and performance requirements in RFC 2719

o Main Network Elements (SS7-IP interface) a.MG b.MGC c.SG

Internet Telephony

Sigtran Advantages

o Ease of deploymento Less costly equipmento Better efficiencyo Higher bandwidtho Enhanced Services

3


SIGTRAN Architecture RFC 2719

Signaling over standard IP uses a common transport protocol that ensures reliable signaling delivery.

Error-free and in-sequence Stream Control Transmission Protocol (SCTP)

An adaptation layer is used to support specific primitives as required by a particular signaling application.

The standard SS7 applications (e.g., ISUP) do not realize that the underlying transport is IP.


SIGTRAN Protocol Stack

SCTP: fast delivery of messages (error-free, in sequence delivery), network-level fault tolerance


Why SCTP? (SCTP RFC 2960)

To offer the fast transmission and reliability required for signaling carrying.

SCTP provides a number of functions that are critical for telephony signaling transport. It can potentially benefit other applications needing

transport with additional performance and reliability. SCTP must meet the Functional Requirements

of SIGTRAN.


Why not use TCP?

TCP provides both reliable data transfer and strict order-of-transmission, but SS7 may not need ordering. TCP will cause delay for supporting order-of-

transmission. TCP parameters have large values and are not

tunable. TCP is relatively vulnerable to DoS attack,

such as SYN attacks.


What Supported By Using SCTP?

To ensure reliable, error-free, in-sequence delivery of user messages (optional).

To support fast delivery of messages and avoid head-of-line blocking.

To support network-level fault tolerance that is critical for carrier-grade network performance by using multi-home hosts.

To provide protection against DoS attack by using 4-way handshake and cookie.


SCTP Endpoint & Association

Endpoint The logical sender/receiver of SCTP packets. Transport address = IP address + SCTP port

number An endpoint may have multiple transport

addresses (for multi-homed host, all transport addresses must use the same port number.)

Association A protocol relationship between SCTP

endpoints. Two SCTP endpoints MUST NOT have more

than one SCTP association.


Multi-Homed Host

Host A

SCTP User

Host B

One IP address

One SCTP association with multi-homed redundant

SCTP

SCTP User

SCTP

One IP address One IP address


SCTP Streams

A stream is a one-way logical channel between SCTP endpoints. The number of streams supported in an

association is specified during the establishment of the association.

To avoid head-of-line blocking and to ensure in-sequence delivery In-sequence delivery is ensured within a

single stream.


SCTP Functional View

SCTP User Application

Acknowledgement and Congestion Avoidance

Chunk Bundling

Packet Validation

Path Management

Association startup and takedown

Sequenced delivery within streams

User Data Fragmentation

Internet Telephony

SCTP common header format

14

Internet Telephony

Chunk building

15


SCTP Packets & Chunks

A SCTP packet can comprise several chunks.

Chunk Data or control

Source Port Number Destination Port Number

Verification Tag

Checksum

Chunk Type Chunk Flags Chunk Length

Chunk Value

. . .

Common Header

Chunk 1

Chunk N

0 16 3115. . . . . .


Chunk Type 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) 12 - Reserved for Explicit Congestion Notification Echo (ECNE) 13 - Reserved for Congestion Window Reduced (CWR) 14 - Shutdown Complete (SHUTDOWN COMPLETE) … - Reserved for IETF


SCTP control chunks

INIT chunk Initiate an SCTP association between two

endpoints Cannot share an SCTP packet with any other

chunk INIT ACK

Acknowledge the initiation Must not share a packet with any other chunk

SACK Acknowledge the receipt of Data chunks Inform the sender of any gaps

Only the gaps need to be resent


HEARTBEAT When no chunks need to be sent Send periodic HEARTBEAT messages Contain sender-specific information

HEARTBEAT ACK Containing heartbeat information copied form

HEARTBEAT ABORT

End an association abruptly Cause information Can be multiplexed with other SCTP control

chunks Should be the last chunk, or …


SHUTDOWN A graceful termination of an association Stop sending any new data Wait until all data sent has been

acknowledged Send a SHUTDOWN to the far end

Indicate the chunk received Upon receipt of a SHUTDOWN

Retransmit data that are not acknowledged Send a SHUTDOWN ACK

SHUTDOWN ACK SHUTDOWN COMPLETE


ERROR Some error condition detected

E.g., a chunk for a non-existent stream

COOKIE ECHO Used only during the initiation of an association An INIT ACK includes a cookie parameter Information specific to the endpoint, a timestamp, a

cookie lifetime Upon receipt of an INIT ACK

Return the cookie information in COOKIE ECHO Can be multiplexed; must be the first chunk

COOKIE ACK Can be multiplexed; must be the first chunk


INIT Chunk

Advertised Receiver Window Credit (a_rwnd)

Number of Outbound Streams

Type = 1 Chunk Flags Chunk Length

Initial TSN (Transmission Sequence Number)

. . .

0 16 3115. . . . . .

Initial Tag

Number of Inbound Streams

Optional / Variable-Length Parameter


Association Establishment

A Z

INIT [I-Tag=Tag_A]

INIT ACK [V-Tag=Tag_A, I-Tag=Tag_Z, Cookie_Z]

COOKIE [Cookie_Z]

COOKIE ACK

allocating resources


User Data Transfer

SCTP user

SCTP Control Chunks

SCTP

SCTP DATA Chunks

User Messages

SCTP packets

Connectionless Packet Transfer Service (e.g. IP)


DATA Chunk

Stream ID = S

Type = 0 Reserved Chunk Length

Payload Protocol ID

. . .

0 16 3115. . . . . .

TSN

Stream Sequence Number = n

User Data (Sequence n of Stream S)

U B E

U : unorderedB : beginE : end


Payload data chunk Carry information to and from the ULP U: unordered bit

The information should be passed to the ULP without regard to sequencing

B and E: beginning and end bits Segment a given user message

TSN: Transmission Sequence Number (32-bit) Independent of any streams Assigned by SCTP An INIT has the same TSN as the first DATA chunk TSN ++ for each new DATA chunk


S: Stream Identifier (16-bit) n: stream sequence number (16-bit)

Begins at zero Increments for each new message

Payload protocol identifier For the users to pass further information about

the chunk but is not examined by the SCTP


SACK Chunk

Advertised Receiver Window Credit (a_rwnd)

Number of Gap Ack Blocks = n

Type = 3 Chunk Flags Chunk Length

0 16 3115. . . . . .

Cumulative TSN Ack

Number of Duplicate TSNs = x

Gap Ack Block #1 Start Gap Ack Block #1 End

. . .

. . .

Duplicate TSN #1


Transferring data Reliable transfer SACK chunk

Cumulative TSN The highest TSN value received without any gaps 4

The number of Gap Ack Blocks The number of fragments received after the

unbroken sequence 2

The number of duplicate TSNs 2


Gap Ack Block number 1 start The offset of the first segment from the unbroken

sequence 3 (7-4)

Gap Ack Block number 1 end The offset of the first segment from the unbroken

sequence 8 (8-4)

a_rwnd The updated buffer space of the sender


SCTP Robustness

Robustness is a key characteristic of any carrier-grade network.

To handle a certain amount of failure in the network without a significant reduction in quality

INIT and INIT ACK chunks may optionally include one or more IP addresses (a primary address + several secondary addresses).

Multi-homes hosts SCTP ensures that endpoint is aware of the

reachability of another endpoint through the following mechanisms.

SACK chunks if DATA chunk have been sent HEARTBEAT chunks if an association is idle

Internet Telephony

User Adaptation Layers

M2UA: SS7 MTP2 user adaptation layer (RFC 3331)

M2PA: SS7 MTP2 user peer-to-peer adaptation layer (RFC 4165)

M3UA: SS7 MTP3 user adaptation layer (RFC 4666)

IUA: ISDN user adaptation layer (RFC 4233) DUA: DPNSS/DASS 2 extensions to the IUA

protocol (RFC 4129) V5UA: V5.2 user adaptation layer (RFC 3807) SUA: signaling connection part user adaptation

layer (RFC 3868, Implementer's guide)

33

Internet Telephony

The Sigtran adaptation layers all serve a number of common purposes:

To carry upper layer Signaling Protocols over a reliable IP-based transport.

To provide the same class of service offered at the interface of the PSTN equivalent.

To be transparent: The user of the service should be unaware that the adaptation layer has replaced the original protocol (although this is largely dependant on the implementation).

To remove as much need for the lower SS7 layers as possible.

34

Internet Telephony

Transport Adaptation Layer Interface (TALI)

Proprietary solution by Tekelec RFC 3094 same functionality as M3UA and SUA uses TCP as its transport layer.

35

Internet Telephony

M2UA

Transfer MTP2-user data Extend SS7 into the IP network Used for backhauling of signalling

messages. provides an interface to a remote MTP2

service

36

Internet Telephony

This architecture is most applicable in the following circumstances:

There is a low density of SS7 links at a particular physical point in the network (perhaps as low as one)

There are a large number of physically separate SG functions (due to the SS7 links being physically located remotely from each other)

The SG function is co-located with an MG (usually due to one or more of the previous conditions)

37

Internet Telephony

M2PA

Peer-to-peer equivalent of M2UA replaces an MTP2 link beneath MTP3 extends the reach of SS7 over the IP

network No interworking function architecture most applicable for an SG to SG

connection MTP3 is present on each SG to provide

routing and management Can be considered as IP SS7 link

39

Internet Telephony

Provides an MTP2-like service itself

This means that M2PA is responsible for: Link activation/deactivation (in response

to requests from MTP3) Maintaining link status information Maintaining sequence numbers and

retransmit buffers, for retrieval by MTP3 Maintaining local and remote processor

outage status

40

Internet Telephony

M2PA allows the classical SS7 link to be replaced by SS7 over IP while maintaining the SS7 link topology.

41

Internet Telephony

M3UA

Transports MTP3 user message extend the reach of SS7 into the IP

network. maintain the MTP3-MTP3 user interface

across an SCTP connection.

46

Internet Telephony

This architecture is most appropriate in the following circumstances:

There is a high enough density of SS7 links to make a standalone SG viable

The SS7 links are physically accessible at a single point

These conditions are common in North American networks, where the SS7 links are physically separate from the voice circuits. In this case, a number of links are gathered together into a single physical medium (for example, a T1 line.)

47

Internet Telephony

SUA

Transports SCCP users Application part (such as TCAP) on an IP SCP

may be reached via an SG. Multiple IP SCPs to be reached via a single

SG(IP SCP’s do not require their own S7 pointcodes )

provides the mapping between SCCP addresses and IP addresses (at the SG).

services of individual databases are addressed via Subsystem Number (SSN).

Service Databases in the SS7 network can be accessed from the IP network.

50

Internet Telephony

UA’s in Detail

54


M3UA Operation

M3UA over SCTP Application Server

A logical entity handling signaling for a scope

A CA handles ISUP signaling for a SS7 DPC/OPC/CIC-range

An AS contains a set of Application Server Processes (ASPs)

ASP A process instance of an AS Can be spread across multiple IP addresses Active ASPs and standby ASPs


Routing Key A set of SS7 parameters that identifies the

signaling for a given AS OPC/DPC/CIC-range

Network Appearance A mechanism for separating signaling traffic

between an SG and an ASP E.g., international signaling gateway


Signaling Network Architecture

No single point of failure SGs should be set up at least in pairs ASPs

A redundant or load-sharing configuration Spread over different hosts

Point code All ASPs and the connected SG share the

same PC A single SS7 signaling endpoint

All ASPs share a PC != that of the SG ASPs: a signaling endpoint; SG: an STP

A group of ASPs share a PC


Services Provided by M3UA

Offer the same primitives as offered by MTP3 MTP-Transfer request MTP-Transfer indication MTP-Pause indication

Signaling to a particular destination should be suspended

MTP-Resume indication Signaling to a particular destination can resume

MTP-Status indication Some change in the SS7 network E.g., network congestion or a destination user part

becoming unavailable


Transferring application message A CA sends an ISUP message MTP-Transfer request A SCTP DATA chunk Transmitted to a SG M3UA – MTP3 To the SS7 network


M3UA Messages Messages between peer M3UA entities A header + the M3UA message content The entities can communicate information

regarding the SS7 network If a remote destination becomes unavailable The SG becomes aware of this through SS7

signaling-network management messages The SG pass M3UA messages to the CA The ISUP application at the CA is made aware

MTP-Pause indication


Signaling Network Management MSGs

S7ISO – SS7 Network Isolation When all links to the SS7 network have been lost

DUNA – Destination Unavailable Sent from the SG to all connected ASPs Destination(s) within the SS7 network is not

available Allocate 24 bits for each DPC

DUNA is generated at the SG It determines from MTP3 network management

message The M3UA of the ASP

Create MTP-Pause indication


DAVA - Destination Available Sent from SG to all concerned ASPs Mapped to the MTP-Resume indication

DAUD – Destination State Audit Sent from an ASP to an SG To query the status of one or more

destination The SG responds with DAVA, DUNA, or SCON

SCON – SS7 Network Congestion Sent from the SG to ASPs The route to an SS7 destination is congested Mapped to the MTP-Status indication


DUPU – Destination User Part Unavailable Sent from the SG to ASPs A given user part at a destination is not

available The DPC and the user part in question Mapped to MTP-Status indication Cause codes

DRST – Destination Restricted Sent from the SG to ASPs One or more SS7 destinations are restricted

from The M3UA may use a different SG


ASP management

ASPUP – ASP Up Used between M3UA peers The adaptation layer is ready to receive

traffic or maintenance messages ASPDN – ASP Down

An ASP is not ready UP ACK – ASP Up Ack DOWN ACK – ASP Down Ack


ASPAC – ASP Active Sent by an ASP Indicate that it is ready to be used To receive all messages or in a load-sharing

mode Routing context

Indicate the scope is applicable to the ASP DPC/OPC/CIC-range

ASPIA – ASP Inactive ACTIVE ACK – ASP Active Ack INACTIVE ACK – ASP Inactive Ack


BEAT – Heartbeat Between M3UA peers Still available to each other When M3UA use the services of SCTP

The BEAT message is not required at the M3UA level

SCTP includes functions for reachability information

ERR – Error message A received message with invalid contents

NFTY – Notify Between M3UA peers To communicate the occurrence of certain

events


Routing Key Management Messages

Registration Request (REG REQ) An ASP = a DPC/OPC/CIC range

Registration Response Deregistration Request Deregistration Response

Internet Telephony

Adaptation Layer [3/3] M3UA (MTP3-User Adaptation Layer) SUA (SCCP-User Adaptation Layer)

Applications such as TCAP use the services of SUA. IUA (ISDN Q.921-User Adaptation Layer) V5UA (V5.2-User Adaptation Layer)


M2UA Operation

MTP3/M2UA/SCTP The CA has more visibility of the SS7

network More tightly coupled to the SG

MTP3 Routing and distribution capabilities

M2UA uses similar concepts to those used by M3UA ASPUP, ASPDN, ASPAC, ASPIA and ERR Exactly the same functions In M2UA, the ASP is an instance of MTP3


Adaptation Layer [1/3] M2UA (MTP-2 User Adaptation Layer)


M2UA-specific messages DATA

Carry an MTP2-user Protocol Data Unit ESTABLISH REQUEST

To establish a link to the SG ESTABLISH CONFIRMATION RELEASE REQUEST

Request the SG to take a particular signaling link out of service

RELEASE CONFIRM RELEASE INDICATION

The SG autonomously take a link out of service


STATE REQUEST Sent from a CA to the SG to cause the SG to

perform some action on a signaling link Link alignment, or flushing transmit buffers

STATE CONFIRM STATE INDICATION

The SG can autonomously send During link changeover

The CA must retrieve certain information from the SG

DATA RETRIEVAL REQUEST DATA RETRIEVAL CONFIRM DATA RETRIEVAL INDICATION


M2PA Operation

IP-based SS7 links No FISUs sent; only LSSUs and MSUs Establish SCTP associations between

M2PA peers Two streams One for MSU The other for LSSU


Adaptation Layer [2/3]

M2PA (MTP-2 Peer-to-Peer Adaptation Layer) An SG that utilizes M2PA is a signaling node for the

MGC. It is effectively an IP-based STP.

SG can processing higher-layer signaling functions, such as SCCP GTT.

Internet Telephony

More on M2UA and M2PA

M2UA M2PA Differences between M2UA and M2PA Conclusion References

Internet Telephony

Introduction (M2UA)

M2UA is a protocol for transporting SS7 MTP2-User signaling e.g., MTP3 messages over IP using the services of the Stream Control Transmission Protocol (SCTP).

The M2UA protocol is the layer between SCTP and MTP3 that separates the physical SS7 termination from the actual signaling point within the network.

Internet Telephony

M2UA Overview

M2UA deployments consist of 2 entities, the client and the server.

The server provides physical SS7 termination and communicates with the client over an SCTP association using IP.

The client houses the MTP3 and thus is the point code addressable element within the SS7 network.

Internet Telephony

M2UA in the SG to MGC Application

Internet Telephony

Architecture of M2UA

Internet Telephony

Common Message Header

Internet Telephony

M2UA Message Header

Internet Telephony

Applications

M2UA serves several purposes. The first purpose is to provide a

mechanism for the transport of SS7 MTP2 user signaling (e.g., MTP3 messages) over IP using SCTP.

The second purpose is to allow remote placement of SS7 link terminations and back haul SS7 traffic to a centralized point in the network.

Internet Telephony

Services Provided by the M2UA Adaptation Layer

The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination point in the IP network, so that the M2UA protocol layer is required to provide the equivalent set of services to its users as provided by the MTP Level 2 to MTP Level 3.

Support for MTP Level 2 / MTP Level 3 interface boundary

Support for communication between Layer Management modules on SG and MGC

Support for management of active associations between SG and MGC

Internet Telephony

Functions Provided by the M2UA Layer

Mapping Flow Control / Congestion SCTP Stream Management Seamless SS7 Network Management

Interworking Active Association Control

Internet Telephony

Security

M2UA is designed to carry signaling messages for telephony services. As such, M2UA MUST involve the security needs of several parties: the end users of the services; the network providers and the applications involved.

As a transport protocol, M2UA has the following security objectives:

* Availability of reliable and timely user data transport.

* Integrity of user data transport. * Confidentiality of user data.

Internet Telephony

Threats

* Blind Denial of Service Attacks * Flooding * Masquerade * Improper Monopolization of Services When the network in which M2UA runs in

involves more than one party, it MAY NOT be reasonable to expect that all parties have implemented security in a sufficient manner. In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload.

Internet Telephony

M2PA-Message Transport protocol peer-to-peer adaptation layer

M2PA is the peer-to-peer equivalent of M2UA.

M2PA allows communication between SS7 systems over IP rather than T-1 or E-1 TDM links.

An M2PA link may be used in place of an MTP2 link, removing the need for dedicated and expensive SS7 hardware.

The M2PA protocol is the layer between SCTP and MTP Level 3.

M2PA provides a means for peer MTP3 layers in SGs to communicate directly, it extends the reach of SS7 over the IP network.

Internet Telephony

Role of M2PA in Evolution to SS7 over IP

M2PA allows the classical SS7 link to be replaced by SS7 over IP while maintaining the SS7 link topology.

Internet Telephony

Purpose of M2PA

Provides a mechanism for the transport of SS7 MTP2 user signaling (e.g., MTP3 messages) over IP using SCTP.

Enables seamless operation between MTP2 user peers in the SS7 and IP space.

Internet Telephony

M2PA Symmetrical Peer-to-Peer Architecture

Internet Telephony

M2PA Symmetrical Peer-to-Peer Architecture

MTP3 is adapted to the SCTP layer using M2PA.

All primitives between MTP3 and MTP2 are supported by M2PA.

Internet Telephony

Architecture of M2PA in a Signaling Gateway

Internet Telephony

M2PA in IP Signaling Gateway

Internet Telephony

Architecture of M2PA in a Signaling Gateway SG is an IPSP that is equipped with both

traditional SS7 and IP network connections. Architecture is applicable for an SG to SG

connection, used to bridge SS7 network islands.

SG and the IPSP communicate through an IP link using the M2PA protocol. Messages sent from the SEP to the IPSP (and vice versa) are routed by the SG.

MTP3 is present on each SG to provide routing and management of the MTP2/M2PA links. Because of the presence of MTP3, each SG would require its own SS7 point code.

M2PA has no knowledge of the upper SS7 layer.

Internet Telephony

M2PA in IP Signaling Gateway

The IPSP's MTP3 uses its underlying M2PA as a replacement for MTP2.

Communication between the two layers MTP3/M2PA is defined by the same primitives as in SS7 MTP3/MTP2.

M2PA uses the SCTP association as an SS7 link. The M2PA/SCTP/IP stack can be used in place of an MTP2/MTP1 stack.

Internet Telephony

Functions Provided by M2PA

MTP2 Functionality: M2PA provides MTP2 functionality that is not provided by SCTP; thus, together M2PA and SCTP provide functionality similar to that of MTP2.

SCTP provides reliable, sequenced delivery of messages.

M2PA functionality includes: Data retrieval to support the MTP3 changeover

procedure. Reporting of link status changes to MTP3. Processor outage procedure. Link alignment procedure.

Internet Telephony

SCTP Association Management SCTP allows a user-specified number of streams to

be opened during initialization. Responsibility of M2PA to ensure proper

management of the streams. M2PA uses two streams in each direction for each

association. - Stream 0 is designated for Link Status messages. - Stream 1 is designated for User Data messages, as

well as Link Status messages that must remain in sequence with the User Data messages.

Separating results in M2PA to prioritize the messages in a manner similar to MTP2.

Internet Telephony

M2PA Association State Transition Diagram

Internet Telephony

Description of M2PA Association states

IDLE: State of the association during power up initialization

ASSOCIATING: M2PA is attempting to establish an SCTP association.

ESTABLISHED: SCTP association is established.

Internet Telephony

M2PA Link State Control

M2PA link moves from one state to another in response to various events. The events that may result in a change of state include:

- MTP3 primitive requests - Receipt of messages from the peer

M2PA- Expiration of timers - SCTP notifications

Internet Telephony

M2PA Applications

Internet Telephony

M2PA Applications

M2PA used in SS7 offloading applicationsCommunication between node SEP1 and SEP2 is done via two SGs. Both SEP1 and SEP2 are connected to two different Signaling Gateways via SS7 interface. These Signaling Gateways are connected to each other via SIGTRAN (M2Pa + SCTP) and acts as STP Nodes. Signaling messages from SEP1 and SEP2 are passed via these two Signaling Gateways. This application can be termed as SS7 offload.

M2PA used in IP based signaling pointsIn this case Signaling Points are connected to each other using IP network. These IP based signaling points (IPSP) uses M2PA links instead of MTP2 links. These IP bases signaling points can also connect to signaling points in SS7 network, via M2PA based Signaling Gateway.

Internet Telephony

Services provided by M2PA

M2PA receives the primitives sent from MTP3 to its lower layer.

M2PA processes these primitives or maps them to appropriate primitives at the M2PA/SCTP interface.

Also M2PA sends primitives to MTP3 similar to those used in the MTP3/MTP2 interface.

Internet Telephony

Types of messages

Message Signal Units (MSUs) Link Status Signal Units (LSSUs) Fill-In Signal Units (FISUs)

Internet Telephony

Types of messages (contd..)

MSUs originate at a higher level than MTP2, and are destined for a peer at another node. M2PA passes these messages from MTP3 to SCTP as data for transport across a link. These are called User Data messages in M2PA.

LSSUs allow peer MTP2 layers to exchange status information. Analogous messages are needed for M2PA. The Link Status message serves this purpose.

FISUs are transmitted continuously when no other signal units are waiting to be sent. FISUs also carry acknowledgement of messages. Since an IP network is a shared resource, it would be undesirable to have a message type that is sent continuously as is the case with FISUs. Furthermore, SCTP does not require its upper layer to continuously transmit messages. Therefore, M2PA does not provide a protocol data unit like the FISU. The M2PA User Data message is used to carry acknowledgement of messages. If M2PA needs to acknowledge a message, and it has no MTP3 message of its own to send, an empty User Data message can be sent.

Internet Telephony

SIGTRAN RFC’s

o Framework Architecture for Signaling Transport-RFC 2719

o Stream Control Transmission Protocol-RFC 2960

o ISDN Q.921-User Adaptation Layer-RFC 3057

o Tekelec's Transport Adapter Layer Interface-RFC 3094

o Stream Control Transmission Protocol Applicability Statement-RFC 3257

o Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)-User Adaptation Layer-RFC 3331

o Signaling System 7 (SS7) Message Transfer Part 3 (MTP3)-User Adaptation Layer (M3UA)-RFC 3332

o Security Considerations for Signaling Transport (SIGTRAN) Protocols-RFC 3788

106

Internet Telephony

o V5.2-User Adaptation Layer (V5UA)-RFC 3807

o Signaling Connection Control Part User Adaptation Layer (SUA)-RFC 3868

o Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)-RFC 3873

o Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)-User Peer-to-Peer Adaptation Layer (M2PA)-RFC 4165

o Telephony Signaling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement-RFC 4166

o Signaling System 7 (SS7) Message Transfer Part 3 (MTP3)-User Adaptation Layer (M3UA)-RFC 4666

o Stream Control Transmission Protocol-RFC 4960

107

Internet Telephony

References

SS7 over IP Signalling Transport & SCTP from http://www.iec.org

DRAFT NATIONAL STANDARDS FOR SIGTRAN No. SD/ SGT-01/01 DRAFT 2007 by DEPARTMENT OF TELECOMMUNICATIONS TELECOMMUNICATION ENGINEERING CENTRE

Why is SCTP needed given TCP and UDP are widely available? ISOC MEMBER BRIEFING #17 from http://www.isoc.org

SS7 by Travis Russel Cisco Press, Signaling System No.7 SS7 C7 Protocol ,

Architecture and Services(2004)

108

Sigtran Ppt Final

Documents

Transcript of Sigtran Ppt Final