[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Transport Working Group                                            L. Ong
Internet-Draft                                            Nortel Networks
draft-ietf-sigtran-sctptunnel-00.txt                           R. Stewart
March    2000                                                      Q. Xie
Expires: August 2000                                             Motorola


                  Tunneling of SCTP over Single UDP Port

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
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

The Simple Control Transmission Protocol (SCTP) [1] provides a
standard method for transporting messages over IP, with features
such as multi-homing and multi-stream built into the protocol
for additional reliability and real-time delivery.  This memo
defines a method for tunneling SCTP over a single UDP port in
order to simplify initial implementations.  This memo is intended
to become an Experimental document and is not intended as a
standard of any kind.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . .  2
   2.   Brief background to the SCTP Protocol. . . . . . . . . . .  2
   3.   Interim Implementation over UDP. . . . . . . . . . . . . .  2
   4.   Use of Single UDP Port . . . . . . . . . . . . . . . . . .  2
   5.   Impacts on SCTP Protocol . . . . . . . . . . . . . . . . .  3
   6.   Possible applications  . . . . . . . . . . . . . . . . . .  4
   7.   Implementation considerations  . . . . . . . . . . . . . .  4
   8.   Security considerations  . . . . . . . . . . . . . . . . .  4
   9.   References . . . . . . . . . . . . . . . . . . . . . . . .  5
   10.  Author's Addresses . . . . . . . . . . . . . . . . . . . .  5

Ong,Stewart & Xie   draft-ietf-sigtran-sctptunnel-00.txt           [Page 1]


Internet Draft        Tunneling of SCTP Over UDP              March 2000

1.  Introduction

This memo describes the methods for tunneling of Simple Control Trans-
mission Protocol (SCTP) over UDP.  Tunneling of SCTP can be done without
change to the protocol formats and basic procedures.  Since SCTP provides
a means of de-multiplexing sessions using the SCTP source and destination
port numbers, only a single UDP port is necessary for tunneling.

2. Background

SCTP is designed to transport PSTN signaling messages over
IP networks, but is capable of broader applications.

SCTP is a reliable datagram transfer protocol operating on top of an
unreliable routed packet network such as IP. It offers the following
services to its users:

  -- acknowledged error-free non-duplicated transfer of user data,
  -- data segmentation to conform to discovered path MTU size,
  -- sequenced delivery of user datagrams within multiple streams,
     with an option for order-of-arrival delivery of individual
     datagrams,
  -- optional multiplexing of user messages into SCTP datagrams, and
  -- network-level fault tolerance through supporting of multi-homing
     at either or both ends of an association.

3. Interim Implementation over UDP

Implementation of SCTP directly over IP requires use of  the raw_IP
socket interface and/or modification to the kernel.  To allow more
rapid implementation and implementation on systems that do not at
this time support the raw_IP socket interface, this memo defines a
method of tunneling SCTP over a single registered UDP port number.

Tunneling of SCTP over UDP adds some unnecessary processing to the
protocol, including redundant source and destination port fields
and greater interprocess communication.  It is therefore provided
only as an interim measure until implementation of SCTP over IP is
available.

4. Use of Single UDP Port

UDP port 9899 has been registered with IANA for SCTP Tunneling.
The use of a single port number still allows multiplexing of SCTP
sessions, using the SCTP's own source and destination port numbers.
At the same time, the use of a single registered port number allows
intermediate systems such as routers and firewalls to immediately
identify SCTP packets and provide any associated treatment that is
desired.

Ong,Stewart & Xie   draft-ietf-sigtran-sctptunnel-00.txt           [Page 2]


Internet Draft        Tunneling of SCTP Over UDP              March 2000

5. Impacts on SCTP Protocol

There are minimal impacts on SCTP fields and basic procedures from the
use of tunneling over UDP. In general SCTP functions such as
initiation, data transfer, congestion control and heartbeat operate
exactly as defined in the standard SCTP specification.

5.1 Impact on MTU discovery

SCTP requires the use of path MTU discovery [2] [3] . However many
operating systems do not allow a user to implement changes to the DF
bit (in the IP header) without opening a RAW IP socket. In some
operating systems facilities are available to allow a UDP user to
enable MTU discovery, these require some minor modification to the
SCTP procedures.

5.1.1 Where MTU discovery is NOT allowed

In cases where MTU discovery requires a RAW IP socket to implement, it
is expected that the UDP tunnel would NOT be capable of supporting
MTU discovery. This feature should remain disabled when implementing
on these systems.

5.1.2 Where MTU discovery IS allowed

In cases where a MTU discovery feature is enabled by a kernel
interface, the following modifications need to be made to the
SCTP path MTU discovery procedures:

1) Whenever the kernel reports an unreachable destination due to
   an ICMP unreachable destination message. Within the message
   a size value is passed to indicate the size of the largest MTU
   value that the reporting network element can send. This size
   must be reduced by the size of the UDP header before passing
   it to the SCTP stack.

2) When a report is made and SCTP is unable to re-fragment the
   datagram by changing the bundling, the UDP interface layer must
   re-enable IP fragmentation by clearing the DF bit until the larger
   datagram is retransmitted. Once the larger, datagram has been
   retransmitted the IP fragmentation must be disabled.


5.2 Impact on Multi-homing

SCTP explicitly uses multi-homing to provide for fast recovery
from network error conditions (when the peer is multi-homed). In
cases where a tunneled endpoint is multi-homed, the endpoint MUST
bind all addresses to the reserved UDP port numbers. This will allow
the SCTP multi-homing to work seamlessly.

Ong,Stewart & Xie   draft-ietf-sigtran-sctptunnel-00.txt           [Page 3]


Internet Draft        Tunneling of SCTP Over UDP              March 2000

6. Possible Applications

Tunneled SCTP has the same range of applications as SCTP over IP, such
as transport of Signaling System 7, ISUP [4] or other telephony signaling
protocols.  The only new consideration is that tunneled SCTP should
eventually be deprecated in favor of SCTP over IP for transport.

It must be noted that there is NO inter-operability between a tunneled
SCTP endpoint and a SCTP endpoint running directly on top of IP. This
provides a limitation that when one endpoint moves directly on
top of IP all endpoints it communicates with must also move at the
same time.

7. Implementation considerations

As discussed in section 5.2, a daemon providing tunneling of SCTP
MUST bind all addresses to the SCTP reserved port. Other considerations
such as:

A) How the application process(es) communicate with the SCTP tunneling
   point.

B) How the tunneling point de-multiplexes the SCTP port number to
   find the real endpoint to send a datagram to.

are beyond the scope of this document and are implementation specific.

8. Security Considerations

Tunneled SCTP is subject to the same security concerns as SCTP over IP.
However, the same security mechanisms can be used, i.e., application of
IPSEC to provide authentication and/or encryption of the transported
signaling and control information.  In this case, IPSEC could be applied
as for any UDP stream, whereas for SCTP over IP, application to an
SCTP protocol type is required.

Ong,Stewart & Xie   draft-ietf-sigtran-sctptunnel-00.txt           [Page 4]


Internet Draft        Tunneling of SCTP Over UDP              March 2000

9. References

[1] Simple Control Transport Protocol <draft-ietf-sigtran-sctp-
     07.txt>, Mar. 2000, Work in Progress

[2] Mogul, J., and Deering, S., "Path MTU Discovery", RFC 1191,
      November 1990.

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

[4] ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7)
    - ISDN User Part (ISUP)'


10. Author's Addresses

Lyndon Ong                              Tel: +1-408-495-5072
Nortel Networks                         EMail: long@nortelnetworks.com
4401 Great America Pkwy
Santa Clara, CA, USA  95054

Randall R. Stewart                      Tel: +1-847-632-7438
Motorola, Inc.                          EMail: rstewar1@email.mot.com
1501 W. Shure Drive, #2315
Arlington Heights, IL 60004
USA

Qiaobing Xie                            Tel: +1-847-632-3028
Motorola, Inc.                          EMail: qxie1@email.mot.com
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA


This draft expires in August 2000.










Ong,Stewart & Xie   draft-ietf-sigtran-sctptunnel-00.txt           [Page 5]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/