draft-ietf-nsis-ntlp-sctp-04.txt   draft-ietf-nsis-ntlp-sctp-05.txt 
Network Working Group X. Fu Network Working Group X. Fu
Internet-Draft C. Dickmann Internet-Draft C. Dickmann
Intended status: Standards Track University of Goettingen Intended status: Standards Track University of Goettingen
Expires: August 23, 2008 J. Crowcroft Expires: April 29, 2009 J. Crowcroft
University of Cambridge University of Cambridge
February 20, 2008 October 26, 2008
General Internet Signaling Transport (GIST) over SCTP General Internet Signaling Transport (GIST) over SCTP
draft-ietf-nsis-ntlp-sctp-04.txt draft-ietf-nsis-ntlp-sctp-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-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.
This Internet-Draft will expire on August 23, 2008. This Internet-Draft will expire on April 29, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The General Internet Signaling Transport (GIST) protocol currently The General Internet Signaling Transport (GIST) protocol currently
uses TCP or TLS over TCP for connection mode operation. This uses TCP or TLS over TCP for connection mode operation. This
document describes the usage of GIST over the Stream Control document describes the usage of GIST over the Stream Control
Transmission Protocol (SCTP). The use of SCTP can take advantage of Transmission Protocol (SCTP). The use of SCTP can take advantage of
features provided by SCTP, namely streaming-based transport, support features provided by SCTP, namely streaming-based transport, support
of multiple streams to avoid head of line blocking, and the support of multiple streams to avoid head of line blocking, the support of
of multi-homing to provide network level fault tolerance. multi-homing to provide network level fault tolerance, as well as
Additionally, the support for the Partial Reliability Extension of partial reliability extension for partially reliable data
SCTP is discussed. transmission. Additionally, the support for datagram TLS is also
discussed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Association Setup . . . . . . . . . . . . . . . . 4 3.1. Message Association Setup . . . . . . . . . . . . . . . . 4
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 4 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 4
3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1. Introduction 1. Introduction
This document describes the usage of the General Internet Signaling This document describes the usage of the General Internet Signaling
Transport (GIST) protocol [1] over the Stream Control Transmission Transport (GIST) protocol [1] over the Stream Control Transmission
Protocol (SCTP) [2]. Protocol (SCTP) [2].
GIST, in its initial specification for connection mode operation, GIST, in its initial specification for connection mode operation,
runs on top of a byte-stream oriented transport protocol providing a runs on top of a byte-stream oriented transport protocol providing a
reliable, in-sequence delivery, i.e., using the Transmission Control reliable, in-sequence delivery, i.e., using the Transmission Control
Protocol (TCP) [5] for signaling message transport. However, some Protocol (TCP) [6] for signaling message transport. However, some
NSLP context information has a definite lifetime, therefore, the GIST NSLP context information has a definite lifetime, therefore, the GIST
transport protocol could benefit from flexible retransmission, so transport protocol could benefit from flexible retransmission, so
stale NSLP messages that are held up by congestion can be dropped. stale NSLP messages that are held up by congestion can be dropped.
Together with the head-of-line blocking issue and other issues with Together with the head-of-line blocking issue and other issues with
TCP, these considerations argue that implementations of GIST should TCP, these considerations argue that implementations of GIST should
support the Stream Control Transport Protocol (SCTP)[2] as an support the Stream Control Transport Protocol (SCTP)[2] as an
optional transport protocol for GIST, especially if deployment over optional transport protocol for GIST, especially if deployment over
the public Internet is contemplated. Like TCP, SCTP supports the public Internet is contemplated. Like TCP, SCTP supports
reliability, congestion control and fragmentation. Unlike TCP, SCTP reliability, congestion control and fragmentation. Unlike TCP, SCTP
provides a number of functions that are desirable for signaling provides a number of functions that are desirable for signaling
transport, such as multiple streams and multiple IP addresses for transport, such as multiple streams and multiple IP addresses for
path failure recovery. In addition, its Partial Reliability path failure recovery. In addition, its Partial Reliability
extension (PR-SCTP) [3] supports partial retransmission based on a extension (PR-SCTP) [3] supports partial retransmission based on a
programmable retransmission timer. programmable retransmission timer. Furthermore, Datagram Transport
Layer Security (DTLS) over SCTP [4] provides a viable solution for
securing SCTP.
This document defines the use of SCTP as a transport protocol for This document defines the use of SCTP as a transport protocol for
GIST Messaging Associations and discusses the implications on GIST GIST Messaging Associations and discusses the implications on GIST
State Maintenance and API between GIST and NSLPs. Furturemore, this State Maintenance and API between GIST and NSLPs. Furturemore, this
document shows how GIST SHOULD be used to provide the additional document shows how GIST SHOULD be used to provide the additional
features offered by SCTP to deliver the GIST C-mode messages (which features offered by SCTP to deliver the GIST C-mode messages (which
can in turn carry NSIS Signaling Layer Protocol (NSLP) [6] messages can in turn carry NSIS Signaling Layer Protocol (NSLP) [7] messages
as payload). More specifically: as payload). More specifically:
o How to use the multiple streams feature of SCTP. o How to use the multiple streams feature of SCTP.
o How to use the PR-SCTP extention of SCTP. o How to use the PR-SCTP extention of SCTP.
o How to take advantage of the multi-homing support of SCTP. o How to take advantage of the multi-homing support of SCTP.
The method described in this document does not require any changes of The method described in this document does not require any changes of
GIST or SCTP. However, SCTP implementations MUST support the GIST or SCTP. However, SCTP implementations MUST support the
optional feature of fragmentation of SCTP user messages. optional feature of fragmentation of SCTP user messages.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [4]. Other document are to be interpreted as described in [5]. Other
terminologies and abbreviations used in this document are taken from terminologies and abbreviations used in this document are taken from
related specifications (e.g., [1] and [2]) as follows: related specifications (e.g., [1] and [2]) as follows:
o SCTP - Stream Control Transmission Protocol o SCTP - Stream Control Transmission Protocol
o PR-SCTP - SCTP Partial Reliability Extension o PR-SCTP - SCTP Partial Reliability Extension
o MRM - Message Routing Method o MRM - Message Routing Method
o MRI - Message Routing Information o MRI - Message Routing Information
o MRS - Message Routing State o MRS - Message Routing State
o MA - A GIST Messaging Association is a single connection between o MA - A GIST Messaging Association is a single connection between
two explicitly identified GIST adjacent peers on the data path. A two explicitly identified GIST adjacent peers on the data path. A
messaging association may use a specific transport protocol and messaging association may use a specific transport protocol and
known ports. If security protection is required, it may use a known ports. If security protection is required, it may use a
specific network layer security association, or use a transport specific network layer security association, or use a transport
skipping to change at page 8, line 21 skipping to change at page 8, line 21
sessions, using TCP as transport GIST signaling messages belonging to sessions, using TCP as transport GIST signaling messages belonging to
different sessions may be blocked if another message is dropped. In different sessions may be blocked if another message is dropped. In
the case of SCTP, this can be avoided as different sessions having the case of SCTP, this can be avoided as different sessions having
different requirements can belong to different streams, thus a different requirements can belong to different streams, thus a
message loss or reordering in a stream will only affect the delivery message loss or reordering in a stream will only affect the delivery
of messages within that particular stream, and not any other streams. of messages within that particular stream, and not any other streams.
6. Security Considerations 6. Security Considerations
The security considerations of both [1] and [2] apply. For securing The security considerations of both [1] and [2] apply. For securing
GIST over SCTP channel, it is recommended to use DTLS [7], to take GIST over SCTP channel, it is recommended to use DTLS [8], to take
the advantage of all the features provided by SCTP and its the advantage of all the features provided by SCTP and its
extensions. DTLS over SCTP is currently being specified in [8]. The extensions. DTLS over SCTP is specified in [4]. The usage of DTLS
usage of DTLS for GIST over SCTP is similar to TLS for GIST as for GIST over SCTP is similar to TLS for GIST as specified in [1],
specified in [1], where a stack-proposal containing both MA-Protocol- where a stack-proposal containing both MA-Protocol-IDs for SCTP and
IDs for SCTP and DTLS during the GIST handshake phase. DTLS during the GIST handshake phase.
7. IANA Considerations 7. IANA Considerations
Two new MA-Protocol-IDs (Forwards-SCTP and Fowards-DTLS) need to be Two new MA-Protocol-IDs (Forwards-SCTP and Fowards-DTLS) need to be
assigned, with a recommended values of 3 and 4. assigned, with a recommended values of 3 and 4.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank John Loughney, Robert Hancock, Andrew The authors would like to thank John Loughney, Robert Hancock, Andrew
McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter for their McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, and Michael
helpful suggestions. Tuexen for their helpful suggestions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Schulzrinne, H. and R. Hancock, "GIST: General Internet [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-15 (work in Signalling Transport", draft-ietf-nsis-ntlp-16 (work in
progress), February 2008. progress), July 2008.
[2] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, [2] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007. September 2007.
[3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad,
"Stream Control Transmission Protocol (SCTP) Partial Reliability "Stream Control Transmission Protocol (SCTP) Partial Reliability
Extension", RFC 3758, May 2004. Extension", RFC 3758, May 2004.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [4] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport
Layer Security for Stream Control Transmission Protocol",
draft-ietf-tsvwg-dtls-for-sctp-00 (work in progress),
October 2008.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[5] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[6] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [7] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005. June 2005.
[7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[8] Tuexen, M. and E. Rescorla, "Datagram Transport Layer Security
for Stream Control Transmission Protocol",
draft-tuexen-dtls-for-sctp-02 (work in progress), November 2007.
Authors' Addresses Authors' Addresses
Xiaoming Fu Xiaoming Fu
University of Goettingen University of Goettingen
Institute of Computer Science Institute of Computer Science
Lotzestr. 16-18 Goldschmidtstr. 7
Goettingen 37083 Goettingen 37077
Germany Germany
Email: fu@cs.uni-goettingen.de Email: fu@cs.uni-goettingen.de
Christian Dickmann Christian Dickmann
University of Goettingen University of Goettingen
Institute of Computer Science Institute of Computer Science
Lotzestr. 16-18 Goldschmidtstr. 7
Goettingen 37083 Goettingen 37077
Germany Germany
Email: mail@christian-dickmann.de Email: mail@christian-dickmann.de
Jon Crowcroft Jon Crowcroft
University of Cambridge University of Cambridge
Computer Laboratory Computer Laboratory
William Gates Building William Gates Building
15 JJ Thomson Avenue 15 JJ Thomson Avenue
Cambridge CB3 0FD Cambridge CB3 0FD
UK UK
skipping to change at page 11, line 44 skipping to change at line 446
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 22 change blocks. 
38 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/