draft-ietf-nsis-ntlp-sctp-00.txt   draft-ietf-nsis-ntlp-sctp-01.txt 
Network Working Group X. Fu Network Working Group X. Fu
Internet-Draft C. Dickmann Internet-Draft C. Dickmann
Expires: December 20, 2006 University of Goettingen Expires: September 5, 2007 University of Goettingen
J. Crowcroft J. Crowcroft
University of Cambridge University of Cambridge
June 18, 2006 March 4, 2007
General Internet Signaling Transport (GIST) over SCTP General Internet Signaling Transport (GIST) over SCTP
draft-ietf-nsis-ntlp-sctp-00.txt draft-ietf-nsis-ntlp-sctp-01.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 December 20, 2006. This Internet-Draft will expire on September 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 the advantage Transmission Protocol (SCTP). The use of SCTP can take advantage of
of features provided by SCTP, namely streaming-based transport, features provided by SCTP, namely streaming-based transport, support
support of multiple streams to avoid head of line blocking, and the of multiple streams to avoid head of line blocking, and the support
support of multi-homing to provide network level fault tolerance. of multi-homing to provide network level fault tolerance.
Additionally, the support for some extensions of SCTP is also Additionally, the support for the Partial Reliability Extension of
discussed, namely its Partial Reliability Extension and the usage of SCTP is discussed.
TLS over SCTP.
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.2. Stack-Configuration-Data information for SCTP . . . . . . 4 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 4
3.4. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 5 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5
3.5. API between GIST and NSLP . . . . . . . . . . . . . . . . 5 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6
3.5.1. SendMessage . . . . . . . . . . . . . . . . . . . . . 6 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6
3.5.2. NetworkNotification . . . . . . . . . . . . . . . . . 6 3.4.1. SendMessage . . . . . . . . . . . . . . . . . . . . . 6
3.6. TLS over SCTP Support . . . . . . . . . . . . . . . . . . 6 3.4.2. NetworkNotification . . . . . . . . . . . . . . . . . 6
4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 10
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) [4] for signaling message transport. However, some Protocol (TCP) [5] 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 must accommodate flexible retransmission, so stale transport protocol could benefit from flexible retransmission, so
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, 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) [5] supports partial retransmission based on a extension (PR-SCTP) [3] supports partial retransmission based on a
programmable retransmission timer. programmable retransmission timer.
This document shows how GIST should be used with SCTP to provide This document defines the use of SCTP as a transport protocol for
these additional features to deliver the GIST C-mode messages (which GIST Messaging Associations and discusses the implications on GIST
State Maintenance and API between GIST and NSLPs. Furturemore, this
document shows how GIST should be used to provide the additional
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) [6] messages
as payload). More specifically: as payload). More specifically:
how to use the multiple streams feature of SCTP. o How to use the multiple streams feature of SCTP.
how to handle the message oriented nature of SCTP. o How to use the PR-SCTP extention of SCTP.
how to take the advantage of multi-homing support of SCTP. o How to take advantage of the 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 The method described in this document does not require any changes of
GIST or SCTP. It is only required that SCTP implementations support GIST or SCTP. However, SCTP implementations MUST support the
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 keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", in this document are to be interpreted as described in "OPTIONAL", in this document are to be interpreted as described in
BCP 14, RFC 2119 [3]. Other terminologies and abbreviations used in BCP 14, RFC 2119 [4]. Other terminologies and abbreviations used in
this document are taken from related specifications (e.g., [1] and this document are taken from related specifications (e.g., [1] and
[2]) as follows: [2]) as follows:
o TLS - Transport Layer Security
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 4, line 33 skipping to change at page 4, line 32
endpoints MUST NOT have more than one SCTP association between endpoints MUST NOT have more than one SCTP association between
them at any given time. them at any given time.
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
The basic GIST protocol specification defines two possible protocols The basic GIST protocol specification defines two possible protocols
to be used in message 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 This document adds Forwards-SCTP as another possible protocol. In
Forwards-SCTP, analog to Forwards-TCP, connections between peers are Forwards-SCTP, analog to Forwards-TCP, connections between peers are
opened in the forwards direction, from the querying node, towards the opened in the forwards direction, from the querying node, towards the
responder. SCTP connections may carry NSLP messages with the responder.
transfer attribute 'reliable'.
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. document for using SCTP as GIST transport protocol. A formal
definition of Forwards-SCTP is given in the following section.
3.2. Stack-Configuration-Data information for SCTP 3.1.2. Protocol-Definition: Forwards-SCTP
In order to run GIST over SCTP, the Stack-Proposal and Stack- This MA-Protocol-ID denotes a basic use of SCTP between peers.
Configuration-Data objects need to recognize the Forwards-SCTP MA- Support for this protocol is OPTIONAL. If this protocol is offered,
Protocol-ID type, and interpret it for the transport protocol MA-protocol-options data MUST also be carried in the SCD object. The
negotiation during the GIST MA setup handshake (e.g., whether SCTP MA-protocol-options field formats are:
runs alone or together with TLS).
In turn, the "MA-protocol-options" field for Forwards-SCTP needs to o in a Query: no information apart from the field header.
be defined for the Stack-Configuration-Data object defined by GIST. o in a Response: 2 byte port number at which the connection will be
This "MA-protocol-options" contains proposed values for the initial accepted, followed by 2 pad bytes.
and maximum retransmission timeout (RTO) as well as a port number in
the case of Response messages. The proposed values for RTO are only
suggestions to the peer and may be overridden by local policy. In
fact, in order to avoid denial of service attacks, the minimum RTO
value is not included in the proposal and in addition implementations
should only accept reasonable RTO proposals.
The MA-protocol-options formats are: The connection is opened in the forwards direction, from the querying
o in a Query: 4 byte RTO initial value and 4 byte RTO maximum value node towards the responder. The querying node MAY use any source
o in a Response: 4 byte RTO initial value, 4 byte RTO maximum value address and source port. The destination information MUST be derived
and 2 byte port number at which the connection will be accepted. from information in the Response: the address from the interface-
address from the Network-Layer-Information object and the port from
the SCD object as described above.
3.3. Effect on GIST State Maintenance Associations using Forwards-SCTP can carry messages with the transfer
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
condition, GIST MUST report this to NSLPs as discussed in Section
4.1.2 of [1].
A GIST MA is established over an SCTP association, which comprises 3.2. Effect on GIST State Maintenance
one or more SCTP streams. Each of such streams can be used for one
or multiple 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 all messages
along the same transport connection/association in a correlated
fashion as TCP (which imposes strict (re)ordering and reliability per
transport level).
3.4. PR-SCTP Support This document defines the use of SCTP as a transport protocol for
GIST Messaging Associations. As SCTP provides additional
functionality over TCP, this section dicusses the implications of
using GIST over SCTP on GIST State Maintenance.
A variant of SCTP, PR-SCTP [5] provides a "timed reliability" While SCTP defines uni-directional streams, for the purpose of this
document, the concept of a bi-direction stream is used.
Implementations MUST establish downstream and upstream (uni-
directional) SCTP streams always together and use the same stream
identifier in both directions. Thus, the two uni-directional streams
(in opposite directions) form a bi-directional stream.
Due to the multi-streaming support of SCTP, it is possible to use
different SCTP streams for different resources (e.g., different NSLP
sessions), rather than maintaining all messages along the same
transport connection/association in a correlated fashion as TCP
(which imposes strict (re)ordering and reliability per transport
level). However, there are limitations to the use of multi-
streaming. All GIST messages for a particular session MUST be sent
over the same SCTP stream to assure the NSLP assumption of in-order
delivery. Multiple sessions MAY share the same SCTP stream based on
local policy.
The GIST concept of Messaging Association re-use is not affected by
this document or the use of SCTP. All rules defined in the GIST
specification remain valid in the context of GIST over SCTP.
3.3. PR-SCTP Support
A variant of SCTP, PR-SCTP [3] provides a "timed reliability"
service. It allows the user to specify, on a per message basis, the service. It allows the user to specify, on a per message basis, the
rules governing how persistent the transport service should be in rules governing how persistent the transport service should be in
attempting to send the message to the receiver. Because of the chunk attempting to send the message to the receiver. Because of the chunk
bundling function of SCTP, reliable and partial reliable messages can bundling function of SCTP, reliable and partial reliable messages can
be multiplexed over a single PR-SCTP association. Therefore, a GIST be multiplexed over a single PR-SCTP association. Therefore, a GIST
over SCTP implementation SHOULD attempt to establish a PR-SCTP over SCTP implementation SHOULD attempt to establish a PR-SCTP
association instead of a standard SCTP association, if available, to association 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.
3.5. API between GIST and NSLP 3.4. API between GIST and NSLP
GIST specification defines an abstract API between GIST and NSLPs. GIST specification defines an abstract API between GIST and NSLPs.
While this document does not change the API itself, the semantics of While this document does not change the API itself, the semantics of
some parameters have slightly different interpretation in the context some parameters have slightly different interpretation in the context
of SCTP. This section only lists those primitives and parameters, of SCTP. This section only lists those primitives and parameters,
that need special consideration when used in the context of SCTP. that need special consideration when used in the context of SCTP.
The relevant primitives are repeatet from [1] to improve readability, The relevant primitives are repeatet from [1] to improve readability,
but [1] remains authoritative. but [1] remains authoritative.
3.5.1. SendMessage 3.4.1. SendMessage
The SendMessage primitive is used by the NSLP to initiate sending of The SendMessage primitive is used by the NSLP to initiate sending of
messages. messages.
SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
NSLP-Id, Session-ID, MRI, NSLP-Id, Session-ID, MRI,
SSI-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC ) SSI-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC )
The following parameter has changed semantics: The following parameter has changed semantics:
Timeout: According to [1] this parameter represents the "length of Timeout: According to [1] this parameter represents the "length of
time GIST should attempt to send this message before indicating an time GIST should attempt to send this message before indicating an
error". When used with SCTP, this parameter is also used as the error". When used with SCTP, this parameter is also used as the
timeout for the "timed reliability" service of PR-SCTP. timeout for the "timed reliability" service of PR-SCTP.
3.5.2. NetworkNotification 3.4.2. NetworkNotification
The NetworkNotification primitive is passed from GIST to an NSLP. It The NetworkNotification primitive is passed from GIST to an NSLP. It
indicates that a network event of possible interest to the NSLP indicates that a network event of possible interest to the NSLP
occurred. occurred.
NetworkNotification ( MRI, Network-Notification-Type ) NetworkNotification ( MRI, Network-Notification-Type )
If SCTP detects a failure of the primary path, GIST should indicate If SCTP detects a failure of the primary path, GIST should indicate
this event to the NSLP by calling the NetworkNotification primitive this event to the NSLP by calling the NetworkNotification primitive
with Network-Notification-Type "Routing Status Change". This with Network-Notification-Type "Routing Status Change". This
notification should be done even if SCTP was able to remain an open notification should be done even if SCTP was able to remain an open
connection to the next peer due to its multi-homing capabilities. connection to the peer due to its multi-homing capabilities.
3.6. TLS over SCTP Support
GIST using TLS over SCTP is analog to GIST using TLS over TCP. Thus,
TLS over SCTP is triggered by a protocol stack consisting of the
Forwards-SCTP MA-protocol-ID and the TLS MA-protocol-ID ([1], Section
5.7.3). The GIST specification defines the versions of TLS that can
be used, as well as the authentication model. All these aspects are
not changed by this document and remain valid for TLS over SCTP.
Regarding GIST implementations, no special treatment is required in
the case of TLS over SCTP in contrast to the existing TLS over TCP
case. However, the SCTP and TLS implementations need to provide a
TLS over SCTP service as descriped in [7]. One should note that an
SCTP association with TLS support takes advantages of SCTP, such as
multi-streaming and multi-homing.
4. Bit-Level Formats 4. Bit-Level Formats
4.1. MA-Protocol-Options 4.1. MA-Protocol-Options
This section provides the bit-level format for the MA-protocol- This section provides the bit-level format for the MA-protocol-
options field that is used for SCTP protocol in the Stack- options field that is used for SCTP protocol in the Stack-
Configuration-Data object of GIST (see Section 3.2). Configuration-Data object of GIST.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial RTO value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum RTO value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SCTP port number | Reserved : : SCTP port number | Reserved :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initial RTO value = Initial RTO value (SCTP configuration) in msec
Maximum RTO value = Maximum RTO value (SCTP configuration) in msec
SCTP port number = Port number at which the responder will accept SCTP port number = Port number at which the responder will accept
SCTP connections SCTP connections
The SCTP port number is only supplied if sent by the responder. The SCTP port number is only supplied if sent by the responder.
5. Security Considerations 5. Application of GIST over SCTP
The security considerations of both [1] and [2] apply. Further 5.1. Multi-homing support of SCTP
security analysis is needed to consider any additional security
vulnerabilities, and will be included in an updated draft.
6. IANA Considerations In general, the multi-homing support of SCTP can be used to improve
fault-tolerance in case of a path- or link-failure. Thus, GIST over
SCTP would be able to deliver NSLP messages between peers even if the
primary path is not working anymore. However, for the Message
Routing Methods (MRMs) defined in the basic GIST specification such a
feature is only of limited use. The default MRM is path-coupled,
which means, that if the primary path is failing for the SCTP
association, it most likely is also for the IP traffic that is
signaled for. Thus, GIST would need to perform a refresh anyway to
cope with the route change. Nevertheless, the use of the multi-
homing support of SCTP provides GIST and the NSLP with another source
to detect route changes. Furthermore, for the time between detection
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
smoothly. Finally, future MRMs might have different properties and
therefore benefit from multi-homing more broadly.
6. Security Considerations
The security considerations of both [1] and [2] apply.
7. IANA Considerations
A new MA-Protocol-ID (Forwards-SCTP) needs to be assigned, with a A new MA-Protocol-ID (Forwards-SCTP) needs to be assigned, with a
recommended value of 3. recommended value of 3.
7. Acknowledgments 8. Acknowledgments
The authors would like to thank John Loughney, Robert Hancock and Jan The authors would like to thank John Loughney, Robert Hancock, Andrew
Demter for their helpful suggestions. McDonald, Fang-Chun Kuo and Jan Demter for their helpful suggestions.
8. References 9. References
8.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
Signaling Transport", draft-ietf-nsis-ntlp-09 (work in Signalling Transport", draft-ietf-nsis-ntlp-12 (work in
progress), February 2006. progress), March 2007.
[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad,
"Stream Control Transmission Protocol (SCTP) Partial Reliability
Extension", RFC 3758, May 2004.
[4] 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.
8.2. Informative References 9.2. Informative References
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [5] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. 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 [6] 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] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436,
December 2002.
Authors' Addresses Authors' Addresses
Xiaoming Fu Xiaoming Fu
University of Goettingen University of Goettingen
Institute for Informatics Institute for Informatics
Lotzestr. 16-18 Lotzestr. 16-18
Goettingen 37083 Goettingen 37083
Germany Germany
Email: fu@cs.uni-goettingen.de Email: fu@cs.uni-goettingen.de
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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
Email: jon.crowcroft@cl.cam.ac.uk Email: jon.crowcroft@cl.cam.ac.uk
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 10, line 29 skipping to change at page 10, line 45
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.
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 (2006). 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 53 change blocks. 
146 lines changed or deleted 157 lines changed or added

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