draft-ietf-nsis-ntlp-sctp-08.txt   draft-ietf-nsis-ntlp-sctp-09.txt 
Network Working Group X. Fu Network Working Group X. Fu
Internet-Draft C. Dickmann Internet-Draft C. Dickmann
Intended status: Experimental University of Goettingen Intended status: Experimental University of Goettingen
Expires: July 24, 2010 J. Crowcroft Expires: August 24, 2010 J. Crowcroft
University of Cambridge University of Cambridge
January 20, 2010 February 20, 2010
General Internet Signaling Transport (GIST) over SCTP and Datagram TLS General Internet Signaling Transport (GIST) over SCTP and Datagram TLS
draft-ietf-nsis-ntlp-sctp-08.txt draft-ietf-nsis-ntlp-sctp-09.txt
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) and Datagram Transport Layer Security Transmission Protocol (SCTP) and Datagram Transport Layer Security
(DTLS). The use of SCTP can take advantage of features provided by (DTLS). The use of SCTP can take advantage of features provided by
SCTP, namely streaming-based transport, support of multiple streams SCTP, namely streaming-based transport, support of multiple streams
to avoid head of line blocking, the support of multi-homing to to avoid head of line blocking, the support of multi-homing to
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 July 24, 2010. This Internet-Draft will expire on August 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5
3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5
3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6
3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7
4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7
5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8
5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 8
5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 8 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 8
6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8
7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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) [7] for signaling message transport. However, some Protocol (TCP) [7] for signaling message transport. However, some
NSLP context information has a definite lifetime, therefore, the GIST NSIS Signaling Layer Protocol (NSLP) [8] context information has a
transport protocol could benefit from flexible retransmission, so definite lifetime, therefore, the GIST transport protocol could
stale NSLP messages that are held up by congestion can be dropped. benefit from flexible retransmission, so stale NSLP messages that are
Together with the head-of-line blocking issue and other issues with held up by congestion can be dropped. Together with the head-of-line
TCP, these considerations argue that implementations of GIST should blocking issue and other issues with TCP, these considerations argue
support the Stream Control Transport Protocol (SCTP)[2] as an that implementations of GIST should support the Stream Control
optional transport protocol for GIST, especially if deployment over Transport Protocol (SCTP)[2] as an optional transport protocol for
the public Internet is contemplated. Like TCP, SCTP supports GIST, especially if deployment over the public Internet is
reliability, congestion control and fragmentation. Unlike TCP, SCTP contemplated. Like TCP, SCTP supports reliability, congestion
provides a number of functions that are desirable for signaling control and fragmentation. Unlike TCP, SCTP provides a number of
transport, such as multiple streams and multiple IP addresses for functions that are desirable for signaling transport, such as
path failure recovery. Furthermore, SCTP offers an advantage of multiple streams and multiple IP addresses for path failure recovery.
message-oriented transport instead of using the byte stream oriented Furthermore, SCTP offers an advantage of message-oriented transport
TCP where one has to provide its own framing mechanisms. In instead of using the byte stream oriented TCP where one has to
addition, its Partial Reliability extension (PR-SCTP) [3] supports provide its own framing mechanisms. In addition, its Partial
partial retransmission based on a programmable retransmission timer. Reliability extension (PR-SCTP) [3] supports partial retransmission
Furthermore, Datagram Transport Layer Security (DTLS) [4] provides a based on a programmable retransmission timer. Furthermore, Datagram
viable solution for securing datagram transport protocols, e.g., by Transport Layer Security (DTLS) [4] provides a viable solution for
using DTLS over SCTP [5]. securing SCTP [5], which allows SCTP to use almost all its transport
features and its extensions.
This document defines the use of SCTP as a transport protocol and the This document defines the use of SCTP as a transport protocol and the
use of DTLS as a security mechanism for GIST Messaging Associations use of DTLS as a security mechanism for GIST Messaging Associations
and discusses the implications on GIST State Maintenance and API and discusses the implications on GIST State Maintenance and API
between GIST and NSLPs. Furthermore, this document shows how GIST between GIST and NSLPs. Furthermore, this document descibes how GIST
SHOULD be used to provide the additional features offered by SCTP to should be interfaced to SCTP and used by NSLPs in order to exploit
deliver the GIST C-mode messages (which can in turn carry NSIS the additional capabilties offered by SCTP to deliver GIST C-mode
Signaling Layer Protocol (NSLP) [8] messages as payload). More messages more effectively. More specifically:
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 extension of SCTP. o How to use the PR-SCTP extension 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 methods of using an unchanged SCTP with GIST described in this
GIST or SCTP. However, SCTP implementations MUST support the document do not require any changes to the high level operation and
optional feature of fragmentation of SCTP user messages. structure of GIST. Addition of new transport options requires
additional interface code and configuration support to allow
applications to exploit the additional transport when appropriate.
In addition, SCTP implementations MUST support the optional feature
of fragmentation of SCTP user messages.
Additionally, this document specifies the use of DTLS for securing Additionally, this document also specifies how to establish GIST
GIST over datagram transport protocols such as SCTP. security using DTLS for use in combination with e.g., SCTP and UDP.
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 [6]. Other document are to be interpreted as described in [6]. 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
skipping to change at page 4, line 28 skipping to change at page 4, line 32
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
layer security association internally. A messaging association is layer security association internally. A messaging association is
bidirectional; signaling messages can be sent over it in either bidirectional; signaling messages can be sent over it in either
direction, and can refer to flows of either direction. direction, and can refer to flows of either direction.
o SCTP Association - A protocol relationship between SCTP endpoints, o SCTP Association - A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information. composed of the two SCTP endpoints and protocol state information.
An association can be uniquely identified by the transport An association can be uniquely identified by the set of transport
addresses used by the endpoints in the association. All transport addresses used by the endpoints in the association. All transport
addresses used by an SCTP endpoint must use the same port number, addresses used by an SCTP endpoint must use the same port number,
but can use multiple IP addresses. A transport address used by an but can use multiple IP addresses. A transport address used by an
SCTP endpoint must not be used by another SCTP endpoint. In other SCTP endpoint must not be used by another SCTP endpoint. In other
words, a transport address is unique to an SCTP endpoint. Two words, a transport address is unique to an SCTP endpoint. Two
SCTP endpoints MUST NOT have more than one SCTP association SCTP endpoints MUST NOT have more than one SCTP association
between them at any given time [2]. between them at any given time [2].
o Stream - A sequence of user messages that are to be delivered to o Stream - A sequence of user messages that are to be delivered to
the upper-layer protocol in order with respect to other messages the upper-layer protocol in order with respect to other messages
within the same stream. within the same stream.
skipping to change at page 4, line 43 skipping to change at page 5, line 4
words, a transport address is unique to an SCTP endpoint. Two words, a transport address is unique to an SCTP endpoint. Two
SCTP endpoints MUST NOT have more than one SCTP association SCTP endpoints MUST NOT have more than one SCTP association
between them at any given time [2]. between them at any given time [2].
o Stream - A sequence of user messages that are to be delivered to o Stream - A sequence of user messages that are to be delivered to
the upper-layer protocol in order with respect to other messages the upper-layer protocol in order with respect to other messages
within the same stream. within the same stream.
3. GIST Over SCTP 3. GIST Over SCTP
3.1. Message Association Setup 3.1. Message Association Setup
3.1.1. Overview 3.1.1. Overview
The basic GIST protocol specification defines two possible protocols The basic GIST protocol specification defines two possible protocols
to be used in Messaging Associations, namely Forwards-TCP and TLS. to be used in Messaging Associations, namely Forwards-TCP and TLS.
This document adds Forwards-SCTP as another possible protocol. In These information are main part of the Stack Configuration Data [1].
Forwards-SCTP, analog to Forwards-TCP, connections between peers are This document adds Forwards-SCTP as another possible protocol option.
opened in the forwards direction, from the querying node, towards the In Forwards-SCTP, analog to Forwards-TCP, connections between peers
responder. are opened in the forwards direction, from the querying node, towards
the responder.
A new MA-Protocol-ID type, "Forwards-SCTP", is defined in this A new MA-Protocol-ID type, "Forwards-SCTP", is defined in this
document for using SCTP as GIST transport protocol. A formal document for using SCTP as GIST transport protocol. A formal
definition of Forwards-SCTP is given in the following section. definition of Forwards-SCTP is given in the following section.
3.1.2. Protocol-Definition: Forwards-SCTP 3.1.2. Protocol-Definition: Forwards-SCTP
This MA-Protocol-ID denotes a basic use of SCTP between peers. This MA-Protocol-ID denotes a basic use of SCTP between peers.
Support for this protocol is OPTIONAL. If this protocol is offered, Support for this protocol is OPTIONAL. If this protocol is offered,
MA-protocol-options data MUST also be carried in the SCD object. The MA-protocol-options data MUST also be carried in the SCD object. The
skipping to change at page 5, line 29 skipping to change at page 5, line 38
The connection is opened in the forwards direction, from the querying The connection is opened in the forwards direction, from the querying
node towards the responder. The querying node MAY use any source node towards the responder. The querying node MAY use any source
address and source port. The destination for establishing the address and source port. The destination for establishing the
message association MUST be derived from information in the Response: message association MUST be derived from information in the Response:
the address from the interface- address from the Network-Layer- the address from the interface- address from the Network-Layer-
Information object and the port from the SCD object as described Information object and the port from the SCD object as described
above. above.
Associations using Forwards-SCTP can carry messages with the transfer Associations using Forwards-SCTP can carry messages with the transfer
attribute Reliable=True. If an error occurs on the SCTP connection attribute Reliable=True. If an error occurs on the SCTP connection
such as a reset, as can be detected for example by a socket exception such as a reset, as can be reported by an SCTP socket API
condition, GIST MUST report this to NSLPs as discussed in Section notification[9], GIST MUST report this to NSLPs as discussed in
4.1.2 of [1]. Section 4.1.2 of [1]. For the multi-homing scenario, when a
destination address of a GIST over SCTP peer encounters a change, the
SCTP API will notify GIST about the availability of different SCTP
endpoint addresses and possible change of the primary path.
3.2. Effect on GIST State Maintenance 3.2. Effect on GIST State Maintenance
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. As SCTP provides additional GIST Messaging Associations. As SCTP provides additional
functionality over TCP, this section dicusses the implications of functionality over TCP, this section dicusses the implications of
using GIST over SCTP on GIST State Maintenance. using GIST over SCTP on GIST State Maintenance.
While SCTP defines uni-directional streams, for the purpose of this While SCTP defines uni-directional streams, for the purpose of this
document, the concept of a bi-direction stream is used. document, the concept of a bi-directional stream is used.
Implementations MUST establish downstream and upstream (uni- Implementations MUST establish downstream and upstream (uni-
directional) SCTP streams always together and use the same stream directional) SCTP streams always together and use the same stream
identifier in both directions. Thus, the two uni-directional streams identifier in both directions. Thus, the two uni-directional streams
(in opposite directions) form a bi-directional stream. (in opposite directions) form a bi-directional stream.
Due to the multi-streaming support of SCTP, it is possible to use Due to the multi-streaming support of SCTP, it is possible to use
different SCTP streams for different resources (e.g., different NSLP different SCTP streams for different resources (e.g., different NSLP
sessions), rather than maintaining all messages along the same sessions), rather than maintaining all messages along the same
transport connection/association in a correlated fashion as TCP transport connection/association in a correlated fashion as TCP
(which imposes strict (re)ordering and reliability per transport (which imposes strict (re)ordering and reliability per transport
skipping to change at page 6, line 20 skipping to change at page 6, line 34
this document or the use of SCTP. All rules defined in the GIST this document or the use of SCTP. All rules defined in the GIST
specification remain valid in the context of GIST over SCTP. specification remain valid in the context of GIST over SCTP.
3.3. PR-SCTP Support 3.3. PR-SCTP Support
A variant of SCTP, PR-SCTP [3] provides a "timed reliability" A variant of SCTP, PR-SCTP [3] provides a "timed reliability"
service, which would be particular useful for delivering GIST service, which would be particular useful for delivering GIST
Connection mode messages. It allows the user to specify, on a per Connection mode messages. It allows the user to specify, on a per
message basis, the rules governing how persistent the transport message basis, the rules governing how persistent the transport
service should be in attempting to send the message to the receiver. service should be in attempting to send the message to the receiver.
Because of the chunk bundling function of SCTP, reliable and partial Because of the chunk bundling function of SCTP, reliable and
reliable messages can be multiplexed over a single PR-SCTP partially reliable messages can be multiplexed over a single PR-SCTP
association. Therefore, a GIST over SCTP implementation SHOULD association. Therefore, a GIST over SCTP implementation SHOULD
attempt to establish a PR-SCTP association using "timed reliability" attempt to establish a PR-SCTP association using "timed reliability"
service instead of a standard SCTP association, if available, to service instead of a standard SCTP association, if available, to
support more flexible transport features for potential needs of support more flexible transport features for potential needs of
different NSLPs. different NSLPs.
In a standard SCTP, instead, if a node has sent the first In a standard SCTP, instead, if a node has sent the first
transmission before the lifetime expires, then the message MUST be transmission before the lifetime expires, then the message MUST be
sent as a normal reliable message. During episodes of congestion sent as a normal reliable message. During episodes of congestion
this is particularly unfortunate, as retransmission wastes bandwidth this is particularly unfortunate, as retransmission wastes bandwidth
skipping to change at page 8, line 12 skipping to change at page 8, line 31
of the route change and recovering from it, the alternative path of the route change and recovering from it, the alternative path
offered by SCTP can be used by the NSLP to make the transition more offered by SCTP can be used by the NSLP to make the transition more
smoothly. Finally, future MRMs might have different properties and smoothly. Finally, future MRMs might have different properties and
therefore benefit from multi-homing more broadly. therefore benefit from multi-homing more broadly.
5.2. Streaming support in SCTP 5.2. Streaming support in SCTP
Streaming support in SCTP is advantageous for GIST. It allows better Streaming support in SCTP is advantageous for GIST. It allows better
parallel processing, in particular by avoiding head of line blocking parallel processing, in particular by avoiding head of line blocking
issue in TCP. Since a same GIST MA may be reused by multiple issue in TCP. Since a same GIST MA may be reused by multiple
sessions, using TCP as transport GIST signaling messages belonging to sessions, using TCP as transport for GIST signaling messages
different sessions may be blocked if another message is dropped. In belonging to different sessions may be blocked if another message is
the case of SCTP, this can be avoided as different sessions having dropped. In the case of SCTP, this can be avoided as different
different requirements can belong to different streams, thus a sessions having different requirements can belong to different
message loss or reordering in a stream will only affect the delivery streams, thus a message loss or reordering in a stream will only
of messages within that particular stream, and not any other streams. affect the delivery of messages within that particular stream, and
not any other streams.
6. NAT Traversal Issue 6. NAT Traversal Issue
NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and
the GIST extensibility capabilities defined in [9]. This the GIST extensibility capabilities defined in [10]. This
specification does not define NAT traversal procedure for GIST over specification does not define NAT traversal procedure for GIST over
SCTP, although an approach for SCTP NAT traversal is described in SCTP, although an approach for SCTP NAT traversal is described in
[10]. [11].
7. Use of DTLS with GIST 7. Use of DTLS with GIST
The MA-Protocol-ID for DTLS denotes a basic use of datagram transport The MA-Protocol-ID for DTLS denotes a basic use of datagram transport
layer channel security, initially in conjunction with SCTP. It layer channel security, initially in conjunction with SCTP. It
provides authentication, integrity and optionally replay protection provides authentication, integrity and optionally replay protection
for control packets. The use of DTLS for securing GIST over SCTP for control packets. The use of DTLS for securing GIST over SCTP
allows GIST to take the advantage of features provided by SCTP and allows GIST to take the advantage of features provided by SCTP and
its extensions. Note replay protection is not available for DTLS its extensions. Note replay protection is not available for DTLS
over SCTP [5]. The usage of DTLS for GIST over SCTP is similar to over SCTP [5]. The usage of DTLS for GIST over SCTP is similar to
skipping to change at page 10, line 18 skipping to change at page 10, line 40
[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 "Stream Control Transmission Protocol (SCTP) Partial
Reliability Extension", RFC 3758, May 2004. Reliability Extension", RFC 3758, May 2004.
[4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[5] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram [5] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security for Stream Control Transmission Transport Layer Security for Stream Control Transmission
Protocol", draft-ietf-tsvwg-dtls-for-sctp-02 (work in Protocol", draft-ietf-tsvwg-dtls-for-sctp-04 (work in
progress), October 2009. progress), February 2010.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] 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.
11.2. Informative References 11.2. Informative References
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[8] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [8] 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.
[9] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and [9] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei,
"Sockets API Extensions for Stream Control Transmission
Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-21 (work in
progress), February 2010.
[10] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and
Extending the NSIS Protocol Family", draft-ietf-nsis-ext-05 Extending the NSIS Protocol Family", draft-ietf-nsis-ext-05
(work in progress), December 2009. (work in progress), December 2009.
[10] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control [11] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
Transmission Protocol (SCTP) Network Address Translation", Transmission Protocol (SCTP) Network Address Translation",
draft-ietf-behave-sctpnat-02 (work in progress), December 2009. draft-ietf-behave-sctpnat-02 (work in progress), December 2009.
Authors' Addresses Authors' Addresses
Xiaoming Fu Xiaoming Fu
University of Goettingen University of Goettingen
Institute of Computer Science Institute of Computer Science
Goldschmidtstr. 7 Goldschmidtstr. 7
Goettingen 37077 Goettingen 37077
 End of changes. 25 change blocks. 
65 lines changed or deleted 78 lines changed or added

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