Network Working Group X. Fu
Internet-Draft C. Dickmann
Expires: April 19, 2006 University of Goettingen
J. Crowcroft
University of Cambridge
October 16, 2005
General Internet Signaling Transport (GIST) over SCTP
draft-fu-nsis-ntlp-sctp-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The General Internet Signaling Transport (GIST) protocol currently
uses TCP or TLS over TCP for connection mode operation. This
document describes the usage of GIST over the Stream Control
Transmission Protocol (SCTP). The use of SCTP can take the advantage
of features provided by SCTP, namely streaming-based transport,
support of multiple streams to avoid head of line blocking, and the
Fu, et al. Expires April 19, 2006 [Page 1]
Internet-Draft GIST over SCTP October 2005
support of multi-homing to provide network level fault tolerance.
Additionally, the support for some extensions of SCTP is also
discussed, namely its Partial Reliability Extension and the usage of
TLS over SCTP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . . 3
3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Stack-Configuration-Data information for SCTP . . . . . . . 4
3.2. Changes to GIST State Maintenance . . . . . . . . . . . . . 5
3.3. Multi-homing Consideration . . . . . . . . . . . . . . . . 5
3.4. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . . 5
3.4.1. Changes to API between GIST and NSLP . . . . . . . . . 6
3.5. TLS over SCTP Support . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Fu, et al. Expires April 19, 2006 [Page 2]
Internet-Draft GIST over SCTP October 2005
1. Introduction
This document describes the usage of the General Internet Signaling
Transport (GIST) protocol [1] over the Stream Control Transmission
Protocol (SCTP) [2].
GIST, in its initial specification for connection mode operation,
runs on top of a byte-stream oriented transport protocol providing a
reliable, in-sequence delivery, i.e., using the Transmission Control
Protocol (TCP) [4] for signaling message transport. However, some
NSLP context information has a definite lifetime, therefore, the GIST
transport protocol must accommodate flexible retransmission, so stale
NSLP messages that are held up by congestion can be dropped.
Together with the head-of-line blocking issue and other issues with
TCP, these considerations argue that implementations of GIST should
support the Stream Control Transport Protocol (SCTP)[2] as an
optional transport protocol for GIST, especially if deployment over
the public Internet is contemplated. Like TCP, SCTP supports
reliability, congestion control, fragmentation. Unlike TCP, SCTP
provides a number of functions that are desirable for signaling
transport, such as multiple streams and multiple IP addresses for
path failure recovery. In addition, its Partial Reliability
extension (PR-SCTP) [5] supports partial retransmission based on a
programmable retransmission timer.
This document shows how GIST should be used with SCTP to provide
these additional features to deliver the GIST C-mode messages (which
can in turn carry NSIS Signaling Layer Protocol (NSLP) [6] messages
as payload). More specifically:
how to use the multiple streams feature of SCTP.
how to handle the message oriented nature of SCTP.
how to take the advantage of multi-homing support of SCTP.
Additionally, this document also discusses how to support two
extensions of SCTP, namely PR-SCTP [5] and TLS over SCTP [7].
The method described in this document does not require any changes of
GIST or SCTP. It is only required that SCTP implementations support
the optional feature of fragmentation of SCTP user messages.
2. Terminology and Abbreviations
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", in this document are to be interpreted as described in
BCP 14, RFC 2119 [3]. Other terminologies and abbreviations used in
this document are taken from related specifications (e.g., [1] and
Fu, et al. Expires April 19, 2006 [Page 3]
Internet-Draft GIST over SCTP October 2005
[2]) as follows:
o TLS - Transport Layer Security
o SCTP - Stream Control Transmission Protocol
o PR-SCTP - SCTP Partial Reliability Extension
o MRM - Message Routing Method
o MRI - Message Routing Information
o MRS - Message Routing State
o MA - A GIST Messaging Association is a single connection between
two explicitly identified GIST adjacent peers on the data path. A
messaging association may use a specific transport protocol and
known ports. If security protection is required, it may use a
specific network layer security association, or use a transport
layer security association internally. A messaging association is
bidirectional; signaling messages can be sent over it in either
direction, and can refer to flows of either direction.
o SCTP Association - A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information.
An association can be uniquely identified by the transport
addresses used by the endpoints in the association. Two SCTP
endpoints MUST NOT have more than one SCTP association between
them at any given time.
o Stream - A sequence of user messages that are to be delivered to
the upper-layer protocol in order with respect to other messages
within the same stream.
3. GIST Over SCTP
3.1. Stack-Configuration-Data information for SCTP
A new MA-Protocol-ID type, "SCTP", is defined in this document for
using SCTP as GIST transport protocol.
In order to run GIST over SCTP, the Stack-Proposal and Stack-
Configuration-Data objects need to recognize the SCTP MA-Protocol-ID
type, and interpret it for the transport protocol negotiation during
the GIST MA setup handshake (e.g., whether SCTP runs alone or
together with TLS). As an example, assuming SCTP MA-Protocol-ID type
is 3, TLS is 2 and TCP is 1, then Stack-Proposal for different
transport will be:
SCTP only: 3
TLS over SCTP: 3, 2
TCP only: 1
TLS over TCP: 1, 2
An SCTP association is opened in the downstreaming direction, i.e.,
from the querying node towards the responder node. In order to
establish an association, a port needs to be negotiated. Therefore,
Fu, et al. Expires April 19, 2006 [Page 4]
Internet-Draft GIST over SCTP October 2005
a Higher-Layer-Addressing format for the GIST Stack-Configuration-
Data object needs to be defined. The content of Higher-Layer-
Addressing depends on the node type:
o Querying node: No information (only padding)
o Responding node: 2-byte port number at which the connection will
be accepted
TBD: The number of streams may also be part of it and negotiated
between a GIST Querying node and Responding node.
3.2. Changes to GIST State Maintenance
A GIST MA is established over an SCTP association, which comprises
one or more SCTP streams. Each of such streams can be used for one
or multiple NSLP sessions (i.e., one or more MRSs). After completing
a GIST MA setup, which implicitly establishes a bi-directional SCTP
stream, C-mode messages can be sent over the SCTP association in
either direction. Due to multi-streaming support of SCTP, it is easy
to maintain sequencing of messages that affect the same resource
(e.g., the same NSLP session), rather than maintaining the all
messages along the same transport connection/association in a
correlated fashion as TCP (which imposes strict (re)ordering and
reliability per transport level).
It is up to local policy when to create a new stream within an SCTP
association.
3.3. Multi-homing Consideration
Multi-homing support is an important feature of SCTP and potentially
provides a better path failure recovery for GIST transport. However,
this feature requires appropriate interpretation (even re-adjustment)
of the keying information for both MA and MRI tables. For instance,
if the communicating end hosts have multiple IP addresses and use
them for signaling, usually the primary IP addresses will be used for
creating and maintaining corresponding MRS. This will also involve
how to reuse MA table. It may be beneficial if additional MRM and
state keying methods for multi-homed signaling scenarios. A future
version of this document will add more text on this aspect.
3.4. PR-SCTP Support
A variant of SCTP, PR-SCTP [5] provides a "timed reliability"
service. It allows the user to specify, on a per message basis, the
rules governing how persistent the transport service should be in
attempting to send the message to the receiver. Because of the chunk
bundling function of SCTP, reliable and unreliable messages can be
multiplexed over a single PR-SCTP association. Therefore, a GIST
Fu, et al. Expires April 19, 2006 [Page 5]
Internet-Draft GIST over SCTP October 2005
over SCTP implementation SHOULD attempt to establish a PR-SCTP
association instead of a standardq SCTP association, if available, to
support more flexible transport features for potential needs of
different NSLPs. Concerning the use of PR-SCTP in GIST, at least the
following change to the API between GIST and NSLP needs to be
considered.
3.4.1. Changes to API between GIST and NSLP
In the GIST-NSLP API SendMessage() primitive, the current values of
the Transfer-Attribute "Reliability" can be either 'unreliable' or
'reliable' as specified in [1]. When PR-SCTP is used, some
distinction from standard SCTP needs to be introduced. The
SendMessage() primitive already contains a Timeout value, which
specifies how long GIST should attempt to send a message before
indicating an error. In the case of PR-SCTP this value should be
used as the timer value for the "timed reliablity". If no "timed
reliability" is available, the Timeout parameter should have no
impact on SCTP.
3.5. TLS over SCTP Support
GIST using TLS over SCTP is similar to GIST using TLS over TCP ([1],
Section 5.7.3). One should note that an SCTP association with TLS
support takes advantages of SCTP, such as multi-streaming and multi-
homing.
4. Security Considerations
The security considerations of both [1] and [2] apply. Further
security analysis is needed to consider any additional security
vulnerabilities, and will be included in an updated draft.
5. IANA Considerations
A new MA-Protocol-ID (SCTP) needs to be assigned, with a recommended
value of 3.
6. Acknowledgments
The authors would like to thank John Loughney and Jan Demter for
their helpful suggestions.
7. References
Fu, et al. Expires April 19, 2006 [Page 6]
Internet-Draft GIST over SCTP October 2005
7.1. Normative References
[1] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-08 (work in
progress), September 2005.
[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[5] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad,
"Stream Control Transmission Protocol (SCTP) Partial Reliability
Extension", RFC 3758, May 2004.
[6] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005.
[7] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436,
December 2002.
Fu, et al. Expires April 19, 2006 [Page 7]
Internet-Draft GIST over SCTP October 2005
Authors' Addresses
Xiaoming Fu
University of Goettingen
Institute for Informatics
Lotzestr. 16-18
Goettingen 37083
Germany
Email: fu@cs.uni-goettingen.de
Christian Dickmann
University of Goettingen
Institute for Informatics
Lotzestr. 16-18
Goettingen 37083
Germany
Email: mail@christian-dickmann.de
Jon Crowcroft
University of Cambridge
Computer Laboratory
William Gates Building
15 JJ Thomson Avenue
Cambridge CB3 0FD
UK
Email: jon.crowcroft@cl.cam.ac.uk
Fu, et al. Expires April 19, 2006 [Page 8]
Internet-Draft GIST over SCTP October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fu, et al. Expires April 19, 2006 [Page 9]