Signalling Transport Working Group               L. Coene, Siemens
Request for Comments:                           J. Loughney, Nokia
                                               I. Rytina, Ericsson
                                           L. Ong, Nortel Networks

   Simple Control Transmission Protocol(SCTP) applicability statement

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as 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 Internet-
   Draft Shadow Directories can be accessed at


   This document describes the applicability of the Simple Control
   Transmission Protocol for general usage. A few general application
   are descibed such as the transport of signalling information(SS7,
   DSS1/2...) over IP infrastructure. The use and specification of
   adaptation layers in conjuction with SCTP is described.

1 Introduction

        This document covers subject terminology and makes a overview of
   the solutions for transporting information over Internet Protocol

Coene, et al.                Informational                      [Page 1]

Draft                 SCTP applicability statement            March 2000

   infrastructure. The transport medium used is the Simple Control
   Transmission Protocol(SCTP). However some of the issues may also
   relate to the transport of information via TCP.

   SCTP provides the following services to its users:

        - acknowledged error-free non-duplicated transfer of user data

        - application-level segmentation to conform to discovered MTU

        - sequenced delivery of user datagrams within multiple streams,
        with an option for order-of-arrival delivery of individual

        - optional multiplexing of user datagrams into SCTP datagrams,
        subject to MTU size restrictions

        - enhanced reliability through support of multi-homing at either
         or both ends of the association.

        - Explicit indication in the message of the application protocol
        SCTP is carrying.

1.1 Terminology

        The following functions are commonly identified in related work:

        Portnumber:  Indicates on the tranport level which application
        needs to be reached in the layer above.

        Transport Address:  An IP address and a portnumber forms a tran-
        sport address which identifies a SCTP association.

        Protocol Identifier:  Indicates the upper layer protocol that is
        using SCTP for the tranport of its data.

        Chunk:  a unit of information within an SCTP datagram, consist-
        ing of a chunk header and chunk-specific content. Each chunk can
        contain user or data information about the particular SCTP

Coene, et al.                Informational                      [Page 2]

Draft                 SCTP applicability statement            March 2000


2  Simple Control Transmission Protocol -- SCTP

2.1  Introduction

   The Simple Control Transmission Protocol(SCTP) provides a high reli-
   alable, redundant transport between 2 endpoints. The interface
   between SCTP and its applications is handled via adaptation layers
   which provide a intermediation layer so that the upper layer proto-
   cols of a certain protocol stack architecture do not have to change
   their interface towards the transport medium and internal functional-
   ity when they start using SCTP instead of a other transport protocol

   The following function are provided by SCTP:

             - Initialization of transport association

             - Synchronization of association state

             - Synchronization of sequence numbering

             - Reliable Data Transfer

                  - Forward and backward sequence numbering

                  - Timers for transmission and acknowledgement

                  - Notification of out-of-sequence - Retransmission of
                  lost messages

             - Support of multiple control streams

                   - Separate sequence control and delivery of each

             - Congestion control

                  - Window flow control

                  - Congestion avoidance based on on TCP methods, e.g.
                   retransmission backoff, window reduction, etc.

             - Detection of session failure by active means, e.g. heart-

Coene, et al.                Informational                      [Page 3]

Draft                 SCTP applicability statement            March 2000

             - Termination of association

   SCTP does support a number of functions that are not provided by
   current TCP:

        - no head-of-line blocking, i.e. multiple streams

        - multilink failover for added reliability

        - keep-alive function for active rapid failure detection

        - message verses byte sequence numbering

        - tighter timer control (than standard TCP implementations)

        - greater fan out (than standard TCP implementations)

   By defining the approriate User adaptation module, a reliable
    transport mechanism can be provided:

        - relialable transmission of packets with end-to-end congestion
        control provided using methods similar to TCP

        - choice between sequenced and unsequenced, relialable msg

        - keep-alive msg

   Within a association between the 2 endpoint, 1 or more stream(s) may
   be avialable. These streams are visible to the adaptation layers but
   are invisible to any layer above the adaptation layer.

2.2 Issues affecting deployement of SCTP

2.2.1   SCTP Multihoming

   Redundant communication between 2 SCTP endpoints is achieved by using
   multihoming where the endpoint is able to send/receive over more than
   one IP address.

   Under the assumption that every IP address will have a different path
   towards the remote endpoint, (this is the responsability of the rout-
   ing protocols(3.2.4) or of manual configuration), if the transport to
   one of the IP address (= 1 particular path) fails then the traffic
   can migrate to the other remaining IP address(= other paths).

Coene, et al.                Informational                      [Page 4]

Draft                 SCTP applicability statement            March 2000

   Multihoming provides redundant communication in SCTP by allowing com-
   munication between two endpoints to continue in the event of failure
   along a path between the endpoints.

   SCTP will always send its traffic to a certain transport address(=
   destination address + portnumber combination) for as long as the
   transmission is uninterupted(=primary). The other transport
   addresses(secondary paths) will act as a backup in case the primary
   path goes out of service. The changeover between primary are backup
   will occur without packetloss and is completely transparent to the

   The portnumber is the same for all transport addresses of that
   specific association.

   Applications using directly SCTP may choose to control the multihom-
   ing service themselves. The applications has then to supply the
   specifc IP address to SCTP for each datagram. This might be done for
   reasons of loadsharing and loadbalancing across the different paths.
   This might not be advisable as the througput of any of the paths is
   not known in advance and constantly changes due to the actions of
   other associations and transport protocols along that particular
   path, would require very tight feedback of each of the paths to the
   loadsharing functions of the user.

   Applications using adaptation layers to run over SCTP do not have
   that kind of control. The adaptation layers will have to take care of

   By sending a keepalive message on all the multiple paths that are not
   used for active transmission of messages accross the association, it
   is possible for SCTP to detect whether one or more paths have failed.
   SCTP will not use these failed paths when a changeover is required.

   The transmission rate of sending keepalive msg should be engineerable
   and the possible loss of keepalive msg could be used for the monitor-
   ing and measurements of the concerned paths.

2.2.2 Fast retransmit of chunks

   The retransmission of a msg is basically governed by the retransmis-
   sion timer. So if no acknowledgement is received after a certain
   time, then the msg is retransmitted. However there is a faster way
   for retransmitting which is not dependant on that timer.

   Every second msg that a node received will be acknowledge to the

Coene, et al.                Informational                      [Page 5]

Draft                 SCTP applicability statement            March 2000

   remote peer. If gaps occur in the acknowledge msg at the remote side,
   then the remote side will wait 3 further gap
   reports(acknowledgements) before it retransmit the msg. This
   retransmission will happen far sooner than with a timer. Especially
   if the traffic volume increases in SCTP, those retransmissions of the
   chunks would happen faster and faster(and hopefully, they would also
   be faster acknowledged)

   See also the paragraph on congestion control and avoidance.

2.2.3 Use of SCTP in Network Adress Translator(NAT) networks

   When a NAT is present between two endpoints, the endpoint that is
   behind the NAT, i.e., one that does not have a publicly available
   network address, shall take one of the following options:

   A) Indicate that only one address can be used by including no tran-
   sport addresses in the INIT message. This will make the endpoint that
   receives this Initiation message to consider the sender as only hav-
   ing that one address. This method can be used for a dynamic NAT, but
   any multi-homing configuration at the endpoint that is behind the NAT
   will not be visible to its peer, and thus not be taken advantage of.

   B) Indicate all of its networks in the Initiation by specifying all
   the actual IP addresses and ports that the NAT will substitute for
   the endpoint. This method requires that the endpoint behind the NAT
   must have pre-knowledge of all the IP addresses and ports that the
   NAT will assign.

   This requires the adaptation of NAT boxes to go searching in SCTP
   outgoing INIT and incoming INIT_ACK for the addresses and replace
   them with the NAT internal address in addition to replace the
   addresses in the IP header.

   C) Use RSIP[] where the connection is tunnelled from host till the
   NAT border and the host layers above IP networklayer have no
   knowledge of the NAT internal addresses.

2.2.4 MTU path discovery

   SCTP discovers the minimal length of the msg that can be transported
   through the network to the final destination without having to frag-
   ment the msg in IP network layer. This avoids using IP fragmenting
   which if a segemented of a fragmented msg is discarded, only that
   segment will be transmitted by SCTP (contrasted with segementing in

Coene, et al.                Informational                      [Page 6]

Draft                 SCTP applicability statement            March 2000

   IP where the whole unsegmented msg will have to be retransmitted and
   after a longer time) -> fast retransmit of SCTP.  See [07].

2.2.5 Use of multiple streams

   The application can choose on which stream he can send it data. Some
   application level protocols may standardize some stream number usage
   convention, which, for instance, allows to send jpeg and gif portions
   of a page through certain stream while text through others, so as to
   avoid large graphics from blocking text content.

   Each stream within a association should be looked upon as a link
   between two points. If multiple streams are used then the application
   is dealing with mulitple links towards the destination. Some applica-
   tion require the use of sequence delivery, which would require for
   them to select a certain link to send their message on.

2.2.6  Congestion control & avoidance

   Congestion control and/or avoidance is of primordial importance in
   any connectionless network. Congestion is the result of approaching
   or exceeding the processing capacity of the link, network , applica-
   tion and/or transport layers. If the processing capacity is exceeded,
   then the congestion can be avoided(example taking a other non-
   congested path towards the destination) or controlled(example :
   reducing the rate of messages to that destination).

   The reaction of SCTP to congestion is detailed in the next para-

   Congestion can be controlled and/or avoided on  different levels:

        - Transport: congestion control/avoidance within SCTP, TCP(fig

        - Network : Congestion control/avoidance present in the network
        layers( example: SCCP, MTP ...)

        - Link layer: flow control

   SCTP conforms to the model of end-to-end congestion control(Fig while ISUP and SCCP model themselves on a link and network
   based congestion control/overload mechanism(Fig

Coene, et al.                Informational                      [Page 7]

Draft                 SCTP applicability statement            March 2000

     |                                                   |
     |         Application and/or transport layer        |
       |                                              A
       |                                              |
       |    +-------------------------------------+   |
       ---->|                                     |----
            |           Network layer             |
       ---->|                                     |----
       |    +-------------------------------------+   |
       |                                              |
       |                                              V
     |                                                   |
     |                    Link layer                     |

                Fig General Congestion model

     |               |
     |transport layer|       Congestion control present based on
     |     SCTP      |         windows
       |           A
       V           |
     |               |
     | Network layer |       No congestion control present
     |   IP(v4/v6)   |         in the IP layer
       |           A
       V           |
     |   Ethernet    |       No congestion control present
     |  Link layer   |         in the ethernnet link layer

                Fig End-to-End congestion control

Coene, et al.                Informational                      [Page 8]

Draft                 SCTP applicability statement            March 2000

     |                 |
     |Application layer|       Congestion control present for
     | TC + MAP,IN...  |         specific applications
     +-----------------+          - MAP: No congestion control
       |             A            - IN: Call gapping
       V             |
     |                 |
     |  Network layer  |       Congestion control present in the
     |   SCCP & MTP    |         in MTP and SCCP based on link and
     +-----------------+         destination status
       |             A
       V             |
     |   MTP lvl 2     |       Congestion control present
     |   Link layer    |         in the link layer

                Fig Distributed congestion control

   By default, SCTP associations do not have a fixed capacity assigned
   to them unless other QOS mechanisms are employed.Thus congestion
   within SCTP association can and will be affected by all traffic using
   the same links including other SCTP, TCP, RTP, UDP... traffic going
   through the same links of the path followed by the SCTP association. Application of Congestion control in SCTP - 3-SACK rule

   The Selective Acknowledgement(SACK) is one of the cornerstones of
   SCTP. It selective Acknowledges datagrams that have been successfully
   received by the remote node. It serves 2 purposes:

             - it indicates till a certain datagram that all previous
             datagrams have been received(without any holes in the
             sequence) and

             - it indicates the datagrams sequence ranges which have
             been received(and so does indicate the holes/gaps  between
             them). It provides us with a form of gap/hole report on
             messages that have been lost or delayed. A hole can consist
             of one or more messages.

   The SACK is always generated and send back to to the sender either

             - after every second message received(delayed ack).

Coene, et al.                Informational                      [Page 9]

Draft                 SCTP applicability statement            March 2000

             - after at most 200ms after receiving the last msg.

        The reason for the holes may be diverse:

             - simple message loss

             - different round trip times of messages being transmitted
             on different interfaces

   At the sender end, whenever the sender notices a hole in a SACK, it
   should wait for 3 further SACKs(identifying the same hole) before
   taking action. This is 3 strikes besides the first one, so that means
   4.  Thus after 4 SACK, the datagrams belonging to the hole should be
   retransmitted(and only those).

   The 3 SACKs rule might be relaxed in certain network provided certain
   condition are met:

             - private IP network

             - if the operator felt confident enough of his own closed

   The SACK rule might be configurable in such a networks. This would
   mean that in case of message drops, retransmission would be "immedi-
   ate". Congestion Control

   The number of messages in flight is determined by the Congestion
   window(Cwnd).  Every time a msg is SACK, a new msg might be send to
   the remote side(up till the Cwnd), even if gaps exists which might
   ultimatly lead to retransmissions.

   The value of the Cwnd is dependant on the slow start and/or conges-
   tion avoidance/control. Use of Explicit Congestion notification(ECN)

Coene, et al.                Informational                     [Page 10]

Draft                 SCTP applicability statement            March 2000

   Explicit Congestion control is a experimental method for communicat-
   ing congestion back to the end node. Duplicated messages

   SACK  can get lost. The receiving node would then received duppli-
   cated packets. A reason for such a behaviour is unbalance between the
   2 traffic direction, use of different up and down path.

2.2.7  Use of the protocol identifier in SCTP

   Indicates the sort of adaptation layers that is using the associa-
   tions. The protocol identifier is avialable to the application and is
   included in each chunk. 0 is the unknown protocol. This protocol id
   can be used by firewalls for filtering out certain protocols. If
   firewalls drops certain protocol id then then association will fail
   in the end because the TSN will be lost. If the chunk(without its
   user data) is simulated with the TSN in it, then the user data will
   be dropped, but the association is preserved.

   The protocol identifier is administreted by IANA.

2.2.8  Use of QOS methods

   SCTP is a end-to-end protocol which cannot guarantee the quality-of-
   service along the complete path(s) taken by the messages of that par-
   ticular association. If more guarantees are required for improving
   the relialability of the transport, some form of QOS mechanism may be

   The possible schemes are as follows. Overprovisioning

   Overprovisioning of the links so that the total traffic running over
   over the link never excedes the link capacity.  In practice, this may
   be difficult to ensure reliably. Private Internets

   Use of a private network solely for transport purposes. Private net-
   works may allow better control and monitoring of resources available.

Coene, et al.                Informational                     [Page 11]

Draft                 SCTP applicability statement            March 2000 Differentiated services

   By providing a certain codepoint in the Type-of-service field (TOS),
   certain Differential services can be selected. [09,10]

   Setting the code point for transport requires some thought. It is
   dependant on the kind of differentiate service selected. Also the use
   of traffic is important: example signalling info should have a higher
   priorty than the user data traffic for which the signalling is
   responsible(and that relation does not always exist). Integrated services

   By use of integrated services [08], resources are reserved for sig-
   naling transport.

   If resources are unavailable for to initiate a new signaling tran-
   sport, that request will be denied.  In practice, RSVP does not scale
   well and this solution may prove to be unfeasable.

   An example is Multi Protocol Label Switching.

2.2.9  SCTP Checksum

   SCTP uses the Adler-32 checksum algorithm. This algorithm will per-
   form better than a 16 bit(CRC or not) checksum or even a 32 bit CRC

   The msg can also be protected by IPSEC. In that case, the checksum
   migth be turned off(field set to 0).

2.2.10  Tunneling of SCTP association over UDP

   The basic operation of SCTP is to run directly on top of IP. However,
   due to restrictions placed on implementers by Operating Systems, not
   all implementations may be able to run over IP directly. Therefore an
   alternative is given which might circonvent some or all of the res-

   The STCP messages are transported over UDP instead. The following
   issues must be observed:
        - the portnumber in the UDP header should be the portnumber

Coene, et al.                Informational                     [Page 12]

Draft                 SCTP applicability statement            March 2000

        assigned to SCTP. The portnumber in the SCTP common header
        should be the one assigned to the user adaptation layer or to
        the application of SCTP. This means that portnumbers previously
        used in UDP and/or TCP can be reused for the same application
        using SCTP. SCTP DOES NOT change the semantics of the portnumber
        just because the protocol identifier is added to the SCTP mes-
        sage.  - the checksum field might be used as a additional guard
        against errors(particular errors in the UDP header). However,
        the SCTP checksum employed is far better at catching errors, but
        does not take the UDP header into account.

2.2.11  How to define and Use adaptation layers

   Many different applications may use SCTP for different purposes. They
   go from Filetransfer over HTTP transport till signalling information

   Some applications might want to have a unchanged interface with its
   lower layer(in this case SCTP) while for other applications, this
   does not pose a problem. A architecture has been devised to let the
   application chosse whether they want to run over SCTP directly(just a
   many applications run over TCP) or let application run on top of a
   adaptation layer over SCTP.

   The basic architecture is as in Figure 2.11.1 :

                   User/Application level Protocols
                            |    |    |
                |        User Adaptation modules     |
                |Simple Control Transmission protocol|
                |       Standard IP Transport        |
                         Network Layer (IP)

          Figure 2.11.1:  Transport Components

Coene, et al.                Informational                     [Page 13]

Draft                 SCTP applicability statement            March 2000

   The three components of the transport protocol are :

   (1)  Adaptation modules that support specific primitives, e.g.
        management indications, required by a particular user/ applica-
        tion protocol. The use of a adaptation protocol is optional. It
        is only used in case in which the application protocol does not
        want to change its interface with the underlaying layer.

   (2)  the Simple Control Transmission Protocol itself that supports a
        common set of reliable transport functions.

   (3)  a standard IP transport/network protocol  provided by the
        operating system. In some network scenarios, it has been recog-
        nised that TCP can provide limited (but sufficient) reliable
        transport functionality for some applications.

2.2.12 Security considerations

   The following aspects of security are :


        Information is sent/received from a known and/or trusted


        Information may not be modified while in transit. The integrity
        of a msg in a public network is not guaranteed.


        Confidentiality of the user data must be ensured.  User data can
        not be examined by unauthorized users.


        The communicating endpoint must remain in service in all

Coene, et al.                Informational                     [Page 14]

Draft                 SCTP applicability statement            March 2000

        circonstances. Some services have very high availability
        requirements: example , all SS7 nodes have to remain active for
        the 99.999% of the time.

   SCTP only tries to increase the availability of a network. SCTP does
   not contain any protocol elements in its messages which are directly
   related to Authentication, Intergrity and Confidentiality functions.
   It depends for such a features on the IPSEC protocols and architec-

   The only function which has some bearing on security of SCTP is the
   integrity of message in SCTP, which is guarded by a Checksum. This
   checksum is manadatory if IPSEC is NOT used. If IPSEC is used then
   the SCTP checksum becomes optional.  THe use of IPSEC in the SCTP
   association must in this case be END-TO-END. The use of IPSEC on a
   part of a path of a SCTP association does NOT relieve SCTP from using
   the checksum(as this ain't end-to-end transport)

   The general rule is that IPSEC should be turned on unconditionaly.

   The description of the internet security architecture and the use of
   it is described in [06].

3 Recommendations

4 References and related work

   [01] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , ,
        Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang,
        L. and  Paxson, V."Simple Control Transmission Protocol",
        RFCxxxx, March 2000.

   [02] SG11, ITU-T Recommendation Q.1400, " architecture  framework for
        the development of signaling and OA&M protocols using OSI con-
        cepts ",1993

   [03] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995.

Coene, et al.                Informational                     [Page 15]

Draft                 SCTP applicability statement            March 2000

   [03] Hinden, R. and Deering, S., "IP Version 6 Addressing Architec-
        ture", RFC 2373, July 1998.

   [04] Hinden, R. and Deering, S., "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [05] Clark, D.D., "Names, addresses, ports and routes", RFC 0814,
        July 1982.

   [06] Kent, S., and Atkinson, R., "Security Architecture for the
        Internet Protocol", RFC 2401,  November 1998.

   [07] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery for
        IP version 6", RFC 1981, August 1996.

   [08] Mankin, A. Ed., Baker, F., , Braden, B., Bradner, S.,, O`Dell,
        M., Romanow, A., Weinrib, A. and Zhang, L., "Resource ReSerVa-
        tion Protocol (RSVP) -- Version 1 Applicability Statement Some
        Guidelines on Deployment" , RFC 2208, September 1997.

   [09] Heinanen, J., Baker, F., Weiss, W. and Wroclawski, J., "Assured
        Forwarding PHB Group", RFC2597, June 1999

   [10] Jacobson, V., Nichols, K. and Poduri, K., "An Expedited Forward-
        ing PHB", RFC2598, June 1999

5. Acknowledgments

   The authors wish to thank Renee Revis and many others for their
   invaluable comments.

6  Author's Address

   Lode Coene
   Siemens Atea
   Atealaan 34
   B-2200    Herentals

Coene, et al.                Informational                     [Page 16]

Draft                 SCTP applicability statement            March 2000

   Phone: +32-14-252081

   John Loughney
   Research centre
   Itamerenkatu 11-13
   FIN-00180    Helsinki

   Phone: +358-9-43761

   Ian Rytina
   Ericsson Australia
   37/360 Elizabeth Street
   Melbourne, Victoria 3000

   Phone : -

   Lyndon Ong
   Nortel Networks
   4401 Great America Parkway
   Santa Clara, CA 95054

   Phone: -

   Expires: November 2000

   Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished
   others, and derivative works that comment on or otherwise explain
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph

Coene, et al.                Informational                     [Page 17]

Draft                 SCTP applicability statement            March 2000

   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by
   the copyright notice or references to the Internet Society or
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on

Coene, et al.                Informational                     [Page 18]