draft-ietf-sigtran-signalling-over-sctp-applic-02.txt   draft-ietf-sigtran-signalling-over-sctp-applic-03.txt 
INTERNET-DRAFT L. Coene
Internet Engineering Task Force M. Tuexen INTERNET-DRAFT L. Coene(Ed)
Issued: December 2000 G. Verwimp Internet Engineering Task Force Siemens
Expires: June 2001 Siemens Issued: January 2002
J. Loughney Expires: July 2002
Nokia
R.R. Stewart
Cisco
Qiaobing Xie
Motorola
M.C. Belinchon
I. Rytina
Ericsson
L. Ong
Nortel Networks
Telephony Signalling Transport over SCTP applicability statement Telephony Signalling Transport over SCTP applicability statement
<draft-ietf-sigtran-signalling-over-sctp-applic-02.txt> <draft-ietf-sigtran-signalling-over-sctp-applic-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1ID-abstracts.txt The list of Internet- http://www.ietf.org/ietf/1ID-abstracts.txt
Draft Shadow Directories can be accessed at
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes the applicability of the Stream Control This document describes the applicability of the Stream Control
Transmission Protocol (SCTP)[RFC2960] for transport of telephony Transmission Protocol (SCTP)[RFC2960] for transport of telephony
signalling information over IP infrastructure. Special considerations signalling information over IP infrastructure. Special
for using SCTP to meet the requirements of transporting telephony considerations for using SCTP to meet the requirements of
signalling [RFC2719] are discussed. transporting telephony signalling [RFC2719] are discussed.
Draft Telephony Signalling Transport over SCTP AS December 2000 Draft SCTP & Telephony signalling January 2002
TABLE OF CONTENTS Table of contents
Telephony Signalling transport over SCTP Applicability state- Telephony signalling over SCTP Applicability statement ......... ii
ment ........................................................... ii
Chapter 1: Introduction ........................................ 2 Chapter 1: Introduction ........................................ 2
Chapter 1.1: Terminology ....................................... 2 Chapter 1.1: Terminology ....................................... 2
Chapter 1.2: Overview .......................................... 3 Chapter 1.2: Contributors ...................................... 3
Chapter 2: Applicability of Telephony Signalling transport Chapter 1.3: Overview ......................................... 3
Chapter 2: Applicability of telephony signalling transport
using SCTP ..................................................... 4 using SCTP ..................................................... 4
Chapter 3: Issues for transporting Telephony signalling Chapter 3: Issues for transporting Telephony signalling
information over SCTP .......................................... 5 information over SCTP .......................................... 4
Chapter 3.1: Congestion control ................................ 5 Chapter 3.1: Congestion control ................................ 4
Chapter 3.2: Detection of failures ............................. 5 Chapter 3.2: Detection of failures ............................. 5
Chapter 3.2.1: Retransmission TimeOut (RTO) calculation ........ 5 Chapter 3.2.1: Retransmission TimeOut (RTO) calculation ........ 5
Chapter 3.2.2: Heartbeat ....................................... 6 Chapter 3.2.2: Heartbeat ....................................... 5
Chapter 3.2.3: Maximum Number of retransmissions ............... 6 Chapter 3.2.3: Maximum Number of retransmissions ............... 5
Chapter 3.3: Shorten end-to-end message delay .................. 6 Chapter 3.3: Shorten end-to-end message delay ................. 6
Chapter 3.4: Bundling considerations ............................ 6 Chapter 3.4: Bundling considerations ........................... 6
Chapter 3.5: Stream Usage ...................................... 6 Chapter 3.5: Stream Usage ...................................... 6
Chapter 4: Security considerations ............................. 7 Chapter 4: Security considerations ............................. 6
Chapter 5: References and related work ......................... 7 Chapter 5: References and related work ......................... 7
Chapter 6: Acknowledgments ..................................... 8 Chapter 6: Acknowledgments ..................................... 7
Chapter 7: Authors address ..................................... 8 Chapter 7: Author's address .................................... 7
1 INTRODUCTION 1 INTRODUCTION
Transport of telephony signalling requires special considerations. Transport of telephony signalling requires special
In order to use SCTP, special care must be taken to meet the perfor- considerations. In order to use SCTP, special care must be taken to
mance, timing and failure management requirements. meet the performance, timing and failure management requirements.
1.1 Terminology 1.1 Terminology
The following terms are commonly identified in related work: The following terms are commonly identified in related work:
Association: SCTP connection between two endpoints. Association: SCTP connection between two endpoints.
Stream: A uni-directional logical channel established within an Stream: A uni-directional logical channel established within an
association, within which all user messages are delivered in
sequence except for those submitted to the unordered delivery
service.
Draft Telephony Signalling Transport over SCTP AS December 2000 Draft SCTP & Telephony signalling January 2002
association, within which all user messages are delivered in 1.2 Contributors
sequence except for those submitted to the unordered delivery ser-
vice.
1.2 Overview The following people contributed to the document: L. Coene(Editor),
M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie,
M. Holdrege, M.C. Belinchon, A. Jungmaier, and L. Ong.
SCTP provides a general purpose, reliable transport between two end- 1.3 Overview
points.
SCTP provides a general purpose, reliable transport between two
endpoints.
The following functions are provided by SCTP: The following functions are provided by SCTP:
- Reliable Data Transfer - Reliable Data Transfer
- Multiple streams to help avoid head-of-line blocking - Multiple streams to help avoid head-of-line blocking
- Ordered and unordered data delivery on a per-stream basis - Ordered and unordered data delivery on a per-stream basis
- Bundling and fragmentation of user data - Bundling and fragmentation of user data
skipping to change at page 4, line 5 skipping to change at page 3, line 40
- Support continuous monitoring of reachability - Support continuous monitoring of reachability
- Graceful termination of association - Graceful termination of association
- Support of multi-homing for added reliability - Support of multi-homing for added reliability
- Protection against blind denial-of-service attacks - Protection against blind denial-of-service attacks
- Protection against blind masquerade attacks - Protection against blind masquerade attacks
Draft Telephony Signalling Transport over SCTP AS December 2000
Telephony Signalling transport over IP normally uses the following Telephony Signalling transport over IP normally uses the following
architecture: architecture:
Telephony Application Telephony Application
| |
+------------------------------------+ +------------------------------------+
| Signalling Adaptation module | | Signalling Adaptation module |
+------------------------------------+ +------------------------------------+
| |
+------------------------------------+ +------------------------------------+
|Stream Control Transmission Protocol| |Stream Control Transmission Protocol|
| (SCTP) | | (SCTP) |
+------------------------------------+ +------------------------------------+
| |
Internet Protocol (IPv4/IPv6) Internet Protocol (IPv4/IPv6)
Figure 1.1: Telephony signalling transport protocol stack Figure 1.1: Telephony signalling transport protocol stack
Draft SCTP & Telephony signalling January 2002
The components of the protocol stack are : The components of the protocol stack are :
(1) Adaptation modules are used when the telephony application needs to (1) Adaptation modules are used when the telephony application needs
preserve an existing primitive interface. (e.g. management indica- to preserve an existing primitive interface. (e.g. management
tions, data operation primitives, ... for a particular indications, data operation primitives, ... for a particular
user/application protocol). user/application protocol).
(2) SCTP, specially configured to meet the telephony application per- (2) SCTP, specially configured to meet the telephony application
formance requirements. performance requirements.
(3) The standard Internet Protocol. (3) The standard Internet Protocol.
2 Applicability of Telephony Signalling transport using SCTP 2 Applicability of Telephony Signalling transport using SCTP
SCTP can be used as the transport protocol for telephony applications. SCTP can be used as the transport protocol for telephony
Message boundaries are preserved during data transport and so no message applications. Message boundaries are preserved during data
delineation is needed. The user data can be delivered by the order of transport and so no message delineation is needed. The user data can
transmission within a stream(in sequence delivery) or the order of be delivered by the order of transmission within a stream(in
arrival. sequence delivery) or the order of arrival.
SCTP can be used to provide redundancy and fault tolerance at the tran-
sport layer and below. Telephony applications needing this level of
fault tolerance can make use of SCTP's multi-homing support.
SCTP can be used for telephony applications where head-of-line blocking
is a concern. Such an application should use multiple streams to provide
Draft Telephony Signalling Transport over SCTP AS December 2000 SCTP can be used to provide redundancy and fault tolerance at the
transport layer and below. Telephony applications needing this level
of fault tolerance can make use of SCTP's multi-homing support.
independent ordering of telephony signalling messages. SCTP can be used for telephony applications where head-of-line
blocking is a concern. Such an application should use multiple
streams to provide independent ordering of telephony signalling
messages.
3 Issues for transporting telephony signalling over SCTP 3 Issues for transporting telephony signalling over SCTP
3.1 Congestion Control 3.1 Congestion Control
The basic mechanism of congestion control in SCTP have been described in The basic mechanism of congestion control in SCTP have been
[RFC2960]. SCTP congestion control sometimes conflicts with the timing described in [RFC2960]. SCTP congestion control sometimes conflicts
requirements of telephony signalling transport. with the timing requirements of telephony signalling transport.
In an engineered network (e.g. a private intranet), in which network In an engineered network (e.g. a private intranet), in which network
capacity and maximum traffic is very well understood, some telephony capacity and maximum traffic is very well understood, some telephony
signalling applications may choose to relax the congestion control rules signalling applications may choose to relax the congestion control
in order to satisfy the timing requirements. But this should be done rules in order to satisfy the timing requirements. But this should
without destabilising the network, otherwise this would lead to poten- be done without destabilising the network, otherwise this would lead
tial congestion collapse of the network. to potential congestion collapse of the network.
Some telephony signalling applications may have their own congestion Some telephony signalling applications may have their own congestion
control and flow control techniques. These techniques may interact with
the congestion control procedures in SCTP. Additionally, telephony Draft SCTP & Telephony signalling January 2002
applications may use SCTP stream based flow control [SCTPFLOW].
control and flow control techniques. These techniques may interact
with the congestion control procedures in SCTP. Additionally,
telephony applications may use SCTP stream based flow control
[SCTPFLOW].
3.2 Detection of failures 3.2 Detection of failures
Telephony systems often must achieve high availability in operation. For Telephony systems often must achieve high availability in operation.
example, they are often required to be able to preserve stable calls For example, they are often required to be able to preserve stable
during a component failure. Therefore error situations at the transport calls during a component failure. Therefore error situations at the
layer and below must be detected very fast so that the application can transport layer and below must be detected very fast so that the
take approriate steps to recover and preserve the stable calls. This application can take approriate steps to recover and preserve the
poses special requirements on SCTP to discover unreachablility of a des- stable calls. This poses special requirements on SCTP to discover
tination address or a peer. unreachablility of a destination address or a peer.
3.2.1 Retransmission TimeOut (RTO) calculation 3.2.1 Retransmission TimeOut (RTO) calculation
The SCTP protocol parameter RTO.Min value has a direct impact on the The SCTP protocol parameter RTO.Min value has a direct impact on the
calculation of the RTO itself. Some telephony applications want to lower calculation of the RTO itself. Some telephony applications want to
the value of the RTO.Min to less than 1 second. This would allow the lower the value of the RTO.Min to less than 1 second. This would
message sender to reach the maximum number-of-retransmission threshold allow the message sender to reach the maximum
faster in the case of network failures. However, lowering RTO.Min may number-of-retransmission threshold faster in the case of network
have a negative impact on network behaviour [ALLMAN99]. failures. However, lowering RTO.Min may have a negative impact on
network behaviour [ALLMAN99].
In some rare cases, telephony applications might not want to use the In some rare cases, telephony applications might not want to use the
exponential timer back-off concept in RTO calculation in order to speed exponential timer back-off concept in RTO calculation in order to
speed up failure detection. The danger of doing this is that, when
Draft Telephony Signalling Transport over SCTP AS December 2000 network congestion occurs, not backing off the timer may worsen the
congestion situation. Therefore, this strategy should never be used
up failure detection. The danger of doing this is that, when network in public Internet.
congestion occurs, not backing off the timer may worsen the congestion
situation. Therefore, this strategy should never be used in public
Internet.
It should be noted that not using delayed SACK will also help faster It should be noted that not using delayed SACK will also help faster
failure detection. failure detection.
3.2.2 Heartbeat 3.2.2 Heartbeat
For faster detection of (un)availability of idle paths, the telephony For faster detection of (un)availability of idle paths, the
application may consider lowering the SCTP parameter HB.interval. It telephony application may consider lowering the SCTP parameter
should be noted this will result in a higher traffic load. HB.interval. It should be noted this will result in a higher traffic
load.
3.2.3 Maximum number of retransmissions 3.2.3 Maximum number of retransmissions
Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters to Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters
lower values will speed up both destination address and peer failure to lower values will speed up both destination address and peer
detection. However, if these values are set too low, the probability of
false detections will increase. Draft SCTP & Telephony signalling January 2002
failure detection. However, if these values are set too low, the
probability of false detections will increase.
3.3 Shorten end-to-end message delay 3.3 Shorten end-to-end message delay
Telephony applications often require short end-to-end message delays. Telephony applications often require short end-to-end message
The methods described in section 3.2.1 on lowering RTO and not using delays. The methods described in section 3.2.1 on lowering RTO and
delayed SACK may be considered. not using delayed SACK may be considered.
3.4 Bundling considerations 3.4 Bundling considerations
Bundling small telephony signalling messages at transmission helps Bundling small telephony signalling messages at transmission helps
improve the bandwidth usage efficiency of the network. On the downside, improve the bandwidth usage efficiency of the network. On the
bundling may introduce additional delay to some of the messages. This downside, bundling may introduce additional delay to some of the
should be taken into consideration when end-to-end delay is a concern. messages. This should be taken into consideration when end-to-end
delay is a concern.
3.5 Stream Usage 3.5 Stream Usage
Telephony signalling traffic is often composed of multiple, independent Telephony signalling traffic is often composed of multiple,
message sequences. It is highly desirable to transfer those independent independent message sequences. It is highly desirable to transfer
message sequences in separate SCTP streams. This reduces the probability those independent message sequences in separate SCTP streams. This
of head-of-line blocking in which the retransmission of a lost message reduces the probability of head-of-line blocking in which the
affects the delivery of other messages not belonging to the same message retransmission of a lost message affects the delivery of other
sequence. messages not belonging to the same message sequence.
Draft Telephony Signalling Transport over SCTP AS December 2000
4 Security considerations 4 Security considerations
SCTP only tries to increase the availability of a network. SCTP does not SCTP only tries to increase the availability of a network. SCTP does
contain any protocol mechanisms which are directly related to user mes- not contain any protocol mechanisms which are directly related to
sage authentication, integrity and confidentiality functions. For such user message authentication, integrity and confidentiality
features, it depends on the IPSEC protocols and architecture and/or on functions. For such features, it depends on the IPSEC protocols and
security features of its user protocols. architecture and/or on security features of its user protocols.
Mechanisms for reducing the risk of blind denial-of-service attacks and Mechanisms for reducing the risk of blind denial-of-service attacks
masquerade attacks are built into SCTP protocol. See RFC2960, section 11 and masquerade attacks are built into SCTP protocol. See RFC2960,
for detailed information. section 11 for detailed information.
Currently the IPSEC working group is investigating the support of mul- Currently the IPSEC working group is investigating the support of
tihoming by IPSEC protocols. At the present time to use IPSEC, one must multihoming by IPSEC protocols. At the present time to use IPSEC,
use 2 * N * M security associations if one endpoint uses N addresses and one must use 2 * N * M security associations if one endpoint uses N
the other M addresses. addresses and the other M addresses.
Draft SCTP & Telephony signalling January 2002
5 References and related work 5 References and related work
[RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , ,
Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, L. Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang,
and Paxson, V, "Stream Control Transmission Protocol", RFC2960, L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960,
October 2000. October 2000.
[RFCOENE] Coene, L., Tuexen, M., Verwimp, G., Loughney, J., Stewart, R. [RFCOENE] Coene, L., Tuexen, M., Verwimp, G., Loughney, J., Stewart,
R., Xie, Q., Holdrege, M., Belinchon, M.C., and Jungmayer, A., R. R., Xie, Q., Holdrege, M., Belinchon, M.C., and Jungmayer, A.,
"Stream Control Transmission Protocol Applicability statement", "Stream Control Transmission Protocol Applicability statement",
<draft-ietf-sigtran-sctp-applicability-03.txt>, December 2000. Work <draft-ietf-sigtran-sctp-applicability-03.txt>, December 2000. Work
In Progress. In Progress.
[RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework Architec- L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework
ture for Signalling Transport", RFC2719, October 1999 Architecture for Signalling Transport", RFC2719, October 1999
[SCTPFLOW] Stewart, R., Ramalho, M., Xie, Q., Conrad, P. and Rose, M.,
"SCTP Stream based flow control", September 2000, Work in Progress.
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network [SCTPFLOW] Stewart, R., Ramalho, M., Xie, Q., Conrad, P. and Rose,
Path Properties", Proc. SIGCOMM'99, 1999. M., "SCTP Stream based flow control", September 2000, Work in
Progress.
Draft Telephony Signalling Transport over SCTP AS December 2000 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
6 Acknowledgments 6 Acknowledgments
The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, G. This document was initially developed by a design team consisting of
Sidebottom, K. Morneault, T. George, M. Stillman and many others for Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart,
their invaluable comments. Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas
Jungmaier, Gery Verwimp and Lyndon Ong.
The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor,
G. Sidebottom, K. Morneault, T. George, M. Stillman and many others
for their invaluable comments.
7 Author's Address 7 Author's Address
Lode Coene Phone: +32-14-252081 Lode Coene Phone: +32-14-252081
Siemens Atea EMail: lode.coene@siemens.atea.be Siemens Atea EMail: lode.coene@siemens.atea.be
Atealaan 34 Atealaan 34
B-2200 Herentals B-2200 Herentals
Belgium Belgium
John Loughney Phone: +358-9-43761 Draft SCTP & Telephony signalling January 2002
Nokia Research Center EMail: john.loughney@nokia.com
Itamerenkatu 11-13
FIN-00180 Helsinki
Finland
Michel Tuexen Phone: +49-89-722-47210
Siemens AG EMail: Michael.Tuexen@icn.siemens.de
Hofmannstr. 51
81359 Munich
Germany
Randall R. Stewart Phone: +1-815-477-2127
24 Burning Bush Trail. EMail: rrs@cisco.com
Crystal Lake, IL 60012
USA
Qiaobing Xie Phone: +1-847-632-3028
Motorola, Inc. EMail: qxie1@email.mot.com
1501 W. Shure Drive
Arlington Heights, IL 60004
USA
Maria-Carmen Belinchon Phone: +34-91-339-3535
Ericsson Espana S. A. EMail: Maria.C.Belinchon@ericsson.com
Network Communication Services
Retama 7, 5th floor
Madrid, 28045
Spain
Draft Telephony Signalling Transport over SCTP AS December 2000
Ian Rytina EMail:ian.rytina@ericsson.com
Ericsson Australia
37/360 Elizabeth Street
Melbourne, Victoria 3000
Australia
Lyndon Ong Phone: -
Nortel Networks EMail: long@nortelnetworks.com
4401 Great America Parkway
Santa Clara, CA 95054
USA
Gery Verwimp Phone: +32-14-253424
Siemens Atea EMail: gery.verwimp@siemens.atea.be
Atealaan 34
B-2200 Herentals
Belgium
Expires: June 2001 Expires: July 2002
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns. be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
Draft Telephony Signalling Transport over SCTP AS December 2000
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/