draft-ietf-sigtran-sctp-02.txt   draft-ietf-sigtran-sctp-03.txt 
skipping to change at line 23 skipping to change at line 23
M. Kalla M. Kalla
Telcordia Telcordia
L. Zhang L. Zhang
UCLA UCLA
V. Paxson V. Paxson
ACIRI ACIRI
expires in six months October 20,1999 expires in six months October 20,1999
Simple Control Transmission Protocol Simple Control Transmission Protocol
<draft-ietf-sigtran-sctp-02.txt> <draft-ietf-sigtran-sctp-03.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at line 140 skipping to change at line 140
5.9 Segmentation 5.9 Segmentation
5.10 Bundling and Multiplexing 5.10 Bundling and Multiplexing
6. Congestion Control 6. Congestion Control
6.1 SCTP Differences from TCP Congestion Control 6.1 SCTP Differences from TCP Congestion Control
6.2 SCTP Slow-Start and Congestion Avoidance 6.2 SCTP Slow-Start and Congestion Avoidance
6.2.1 Slow-Start 6.2.1 Slow-Start
6.2.2 Congestion Avoidance 6.2.2 Congestion Avoidance
6.2.3 Congestion Control 6.2.3 Congestion Control
6.2.4 Fast Retransmit on Gap Reports 6.2.4 Fast Retransmit on Gap Reports
6.3 Path MTU Discovery 6.3 Path MTU Discovery
6.4 Discussion
7. Fault Management 7. Fault Management
7.1 Endpoint Failure Detection 7.1 Endpoint Failure Detection
7.2 Path Failure Detection 7.2 Path Failure Detection
7.3 Path Heartbeat 7.3 Path Heartbeat
7.4 Verification Tag 7.4 Verification Tag
8. Termination of Association 8. Termination of Association
8.1 Close of an Association 8.1 Close of an Association
8.2 Shutdown of an Association 8.2 Shutdown of an Association
9. Interface with Upper Layer 9. Interface with Upper Layer
9.1 ULP-to-SCTP 9.1 ULP-to-SCTP
skipping to change at line 196 skipping to change at line 195
reliable data transfer in IP networks. However, an increasing number reliable data transfer in IP networks. However, an increasing number
of recent applications have found TCP too limiting, and have of recent applications have found TCP too limiting, and have
incorporated their own reliable data transfer protocol on top of UDP incorporated their own reliable data transfer protocol on top of UDP
[RFC 768, "User Datagram Protocol", Jon Postel, August 1980]. The [RFC 768, "User Datagram Protocol", Jon Postel, August 1980]. The
limitations which users have wished to bypass relate both to the limitations which users have wished to bypass relate both to the
intrinsic nature of TCP and to its typical implementation. intrinsic nature of TCP and to its typical implementation.
Intrinsic limitations: Intrinsic limitations:
-- TCP provides both reliable data transfer and strict order- -- TCP provides both reliable data transfer and strict order-
of-arrival delivery of data. Some applications need reliable of-transmission delivery of data. Some applications need reliable
transfer without sequence maintenance, while others would be transfer without sequence maintenance, while others would be
satisfied with partial ordering of the data. In both of these satisfied with partial ordering of the data. In both of these
cases the head-of-line blocking offered by TCP causes cases the head-of-line blocking offered by TCP causes
unnecessary delay. unnecessary delay.
-- The stream-oriented nature of TCP is often an inconvenience. -- The stream-oriented nature of TCP is often an inconvenience.
Applications must add their own record marking to delineate Applications must add their own record marking to delineate
their messages, and must make explicit use of the push facility their messages, and must make explicit use of the push facility
to ensure that a complete message is transferred in a to ensure that a complete message is transferred in a
reasonable time. reasonable time.
skipping to change at line 236 skipping to change at line 235
for which all of these limitations of TCP are relevant. While this for which all of these limitations of TCP are relevant. While this
application directly motivated the development of SCTP, other application directly motivated the development of SCTP, other
applications may find SCTP a good match to their requirements. applications may find SCTP a good match to their requirements.
1.2 Architectural View of SCTP 1.2 Architectural View of SCTP
SCTP is viewed as a layer between the SCTP user application ("SCTP SCTP is viewed as a layer between the SCTP user application ("SCTP
user" for short) and an unreliable end-to-end datagram service such as user" for short) and an unreliable end-to-end datagram service such as
UDP. The basic service offered by SCTP is the reliable transfer of UDP. The basic service offered by SCTP is the reliable transfer of
user datagrams between peer SCTP users. It performs this service user datagrams between peer SCTP users. It performs this service
within the context of an association between two SCTP Hosts. Chapter 9 within the context of an association between two SCTP nodes. Chapter 9
of this document sketches the API which should exist at the boundary of this document sketches the API which should exist at the boundary
between the SCTP and the SCTP user layers. between the SCTP and the SCTP user layers.
SCTP is connection-oriented in nature, but the SCTP association is a SCTP is connection-oriented in nature, but the SCTP association is a
broader concept than the TCP connection. SCTP provides the means for broader concept than the TCP connection. SCTP provides the means for
each SCTP endpoint to provide the other during association startup each SCTP endpoint (Section 1.4) to provide the other during
with a list of transport addresses (e.g. address/UDP port association startup with a list of transport addresses (e.g.
combinations) through which that endpoint can be reached and from address/UDP port combinations) through which that endpoint can be
which it will originate messages. The association spans transfers reached and from which it will originate messages. The association
over all of the possible source/destination combinations which may be spans transfers over all of the possible source/destination
generated from the two endpoint lists. combinations which may be generated from the two endpoint lists.
_____________ _____________ _____________ _____________
| SCTP User | | SCTP User | | SCTP User | | SCTP User |
| Application | | Application | | Application | | Application |
|-------------| |-------------| |-------------| |-------------|
| SCTP | | SCTP | | SCTP | | SCTP |
| Transport | | Transport | | Transport | | Transport |
| Service | | Service | | Service | | Service |
|-------------| |-------------| |-------------| |-------------|
| Unreliable |One or more ---- One or more| Unreliable | | Unreliable |One or more ---- One or more| Unreliable |
| Datagram |port/address \/ port/address| Datagram | | Datagram |port/address \/ port/address| Datagram |
| Service |appearances /\ appearances| Service | | Service |appearances /\ appearances| Service |
|_____________| ---- |_____________| |_____________| ---- |_____________|
SCTP Host A |<-------- Network transport ------->| SCTP Host B SCTP Node A |<-------- Network transport ------->| SCTP Node B
Figure 1: An SCTP Association Figure 1: An SCTP Association
It is possible to have multiple associations active between the same
pair of SCTP Hosts.
1.3 Functional View of SCTP 1.3 Functional View of SCTP
The SCTP transport service can be decomposed into a number of The SCTP transport service can be decomposed into a number of
functions. These are depicted in Figure 2 and explained in the functions. These are depicted in Figure 2 and explained in the
remainder of this section. remainder of this section.
SCTP User Application SCTP User Application
..----------------------------------------------------- ..-----------------------------------------------------
.. _____________ ____________________ .. _____________ ____________________
skipping to change at line 338 skipping to change at line 334
streams to be supported by the association. This number is negotiated streams to be supported by the association. This number is negotiated
with the remote end (see section 4.1.1). User datagrams are associated with the remote end (see section 4.1.1). User datagrams are associated
with stream numbers (SEND, RECEIVE primitives, Chapter 9). Internally, with stream numbers (SEND, RECEIVE primitives, Chapter 9). Internally,
SCTP assigns a stream sequence number to each datagram passed to it by SCTP assigns a stream sequence number to each datagram passed to it by
the SCTP user. On the receiving side, SCTP ensures that datagrams are the SCTP user. On the receiving side, SCTP ensures that datagrams are
delivered to the SCTP user in sequence within a given stream. However, delivered to the SCTP user in sequence within a given stream. However,
while one stream may be blocked waiting for the next in-sequence user while one stream may be blocked waiting for the next in-sequence user
datagram, delivery from other streams may proceed. datagram, delivery from other streams may proceed.
SCTP provides a mechanism for bypassing the sequenced delivery SCTP provides a mechanism for bypassing the sequenced delivery
service. Usr datagrams sent using this mechanism are delivered to the service. User datagrams sent using this mechanism are delivered to the
SCTP user as soon as they are received. SCTP user as soon as they are received.
1.3.3 User Data Segmentation 1.3.3 User Data Segmentation
SCTP can segment user datagrams to ensure that the SCTP datagram SCTP can segment user datagrams to ensure that the SCTP datagram
passed to the lower layer conforms to the path MTU. Segments are passed to the lower layer conforms to the path MTU. Segments are
reassembled into complete datagrams before being passed to the SCTP reassembled into complete datagrams before being passed to the SCTP
user. user.
1.3.4 Acknowledgement and Congestion Avoidance 1.3.4 Acknowledgement and Congestion Avoidance
skipping to change at line 434 skipping to change at line 430
interface between SCTP and its user. interface between SCTP and its user.
o User data: the content of user datagrams. o User data: the content of user datagrams.
o SCTP datagram: the unit of data delivery across the interface o SCTP datagram: the unit of data delivery across the interface
between SCTP and the unreliable datagram service (e.g. UDP) which between SCTP and the unreliable datagram service (e.g. UDP) which
it is using. An SCTP datagram includes the common SCTP header, it is using. An SCTP datagram includes the common SCTP header,
possible SCTP control chunks, and user data encapsulated within possible SCTP control chunks, and user data encapsulated within
SCTP DATA chunks. SCTP DATA chunks.
o SCTP host: a logical unit within which SCTP is running.
o Transport address: an address which serves as a source or o Transport address: an address which serves as a source or
destination for the unreliable datagram transport service used by destination for the unreliable datagram transport service used by
SCTP. In IP networks, a transport address is defined by the SCTP. In IP networks, a transport address is defined by the
combination of an IP address and a UDP port number. combination of an IP address and a UDP port number.
o SCTP endpoint: a logical entity, comprising a set of eligible o SCTP endpoint: a logical entity, comprising a set of eligible
transport addresses at an SCTP host, which SCTP datagrams will be transport addresses at a host, which SCTP datagrams will be
sent to and received from. Note, a transport address can only be sent to and received from. Note, a transport address can only be
included in one unique SCTP endpoint, i.e., it is NOT allowed to included in one unique SCTP endpoint, i.e., it is NOT allowed to
have the same SCTP transport address appear in more than one have the same SCTP transport address appear in more than one
endpoints. endpoints.
o SCTP association: a protocol relationship between SCTP endpoints, o SCTP association: a protocol relationship between SCTP endpoints,
comprising the two SCTP endpoints and protocol state information comprising the two SCTP endpoints and protocol state information
including verification tags and the currently active set of including verification tags and the currently active set of
Transmission Sequence Numbers (TSNs), etc. Transmission Sequence Numbers (TSNs), etc.
skipping to change at line 1022 skipping to change at line 1016
destination address for the session. destination address for the session.
Cookie Preservative Cookie Preservative
The sender of the INIT shall use this parameter to suggest to the The sender of the INIT shall use this parameter to suggest to the
receiver of the INIT for a longer life-span of the Responder Cookie. receiver of the INIT for a longer life-span of the Responder Cookie.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Cookie Life-span Increment (msec.) | | Suggested Cookie Life-span Increment (msec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Cookie Life-span Increment: 32bit u_int Suggested Cookie Life-span Increment: 32bit u_int
This parameter indicates to the receiver the need for a cookie that This parameter indicates to the receiver the need for a cookie that
expires in a longer period of time than that of the previous one. It expires in a longer period of time than that of the previous one. It
is normally added to the INIT message during the second attempt of is normally added to the INIT message during the second attempt of
establishing an association with a peer after the first attempt establishing an association with a peer after the first attempt
skipping to change at line 1089 skipping to change at line 1083
Variable Parameters Status Type Value Variable Parameters Status Type Value
------------------------------------------------------------- -------------------------------------------------------------
Responder Cookie Mandatory 0x0007 Responder Cookie Mandatory 0x0007
IPv4 Address (Note 1) Optional 0x0005 IPv4 Address (Note 1) Optional 0x0005
IPv6 Address (Note 1) Optional 0x0006 IPv6 Address (Note 1) Optional 0x0006
Unrecognized Parameters Optional 0x0008 Unrecognized Parameters Optional 0x0008
Note 1: The INIT ACK chunks may contain multiple addresses that Note 1: The INIT ACK chunks may contain multiple addresses that
may be IPv4 and/or IPv6 in any combination. may be IPv4 and/or IPv6 in any combination.
Same as with INIT, more than one IP Address parameter can be included
in an INIT ACK chunk.
If the INIT ACK contains a least one IP Address parameter, then only
The transport addresses provided within the INIT ACK may be used as
destinations by the responding end. If the INIT ACK does not contain
any IP Address parameters, the responding end MUST use the source
address associated with the received SCTP datagram as its sole
destination address for the session.
The Responder Cookie and Unrecognized Parameters use the Type-Length- The Responder Cookie and Unrecognized Parameters use the Type-Length-
Value format as defined in Section 2.2.1 and are described below. The Value format as defined in Section 2.2.1 and are described below. The
other fields are defined the same as their counterparts in the INIT other fields are defined the same as their counterparts in the INIT
message. message.
2.3.2.1 Optional or Variable Length Parameters 2.3.2.1 Optional or Variable Length Parameters
Responder Cookie: variable size, depending on Size of Cookie Responder Cookie: variable size, depending on Size of Cookie
This field MUST contain all the necessary state and parameter This field MUST contain all the necessary state and parameter
skipping to change at line 1166 skipping to change at line 1170
| Fragment #N Start | Fragment #N End | | Fragment #N Start | Fragment #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: Chunk Flags:
Set to all zeros on transmit and ignored on receipt. Set to all zeros on transmit and ignored on receipt.
Highest Consecutive TSN ACK: 32 bit u_int Highest Consecutive TSN ACK: 32 bit u_int
This parameter contains the TSN of the last DATA chunk received in This parameter contains the TSN of the last DATA chunk received in
sequence before a gap. Therefore, it must be lower than the sequence before a gap.
Start TSN of the first fragment, if present.
Receive Window Credit (rwnd): 32 bit u_int Receive Window Credit (rwnd): 32 bit u_int
This field defines the new maximum number of octets of outbound data This field defines the new maximum number of octets of outbound data
the receiver of this SACK is allowed to have outstanding (i.e. sent the receiver of this SACK is allowed to have outstanding (i.e. sent
and not acknowledged). and not acknowledged).
Number of Fragments: 16 bit u_int Number of Fragments: 16 bit u_int
Indicates the number of TSN fragments included in this Selective Indicates the number of TSN fragments included in this Selective
skipping to change at line 1433 skipping to change at line 1436
Currently SCTP defines the following error causes: Currently SCTP defines the following error causes:
Cause of error Cause of error
--------------- ---------------
Invalid Stream Identifier Invalid Stream Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=1 | Cause Length=8 | | Cause Code=1 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | | Stream Identifier | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error Cause of error
--------------- ---------------
Missing Mandatory Parameter Missing Mandatory Parameter
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=2 | Cause Length=8+N*2 | | Cause Code=2 | Cause Length=8+N*2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params=N | | Number of missing params=N |
skipping to change at line 1871 skipping to change at line 1874
decides not to establish the new association due to lack of resources, decides not to establish the new association due to lack of resources,
etc., it shall respond to the chunk with an ABORT chunk. The etc., it shall respond to the chunk with an ABORT chunk. The
Verification Tag field of the common header must be set to equal the Verification Tag field of the common header must be set to equal the
Initiate Tag value of the peer. Initiate Tag value of the peer.
Note: After the reception of the first data chunk in an association Note: After the reception of the first data chunk in an association
the receiver MUST immediately respond with a SACK to acknowledge the receiver MUST immediately respond with a SACK to acknowledge
the data chunk, subsequent acknowledgements should be done as the data chunk, subsequent acknowledgements should be done as
described in section 5.2. described in section 5.2.
Note: When a SCTP endpoint sends a INIT or INIT ACK it MUST include Note: When a SCTP endpoint sends an INIT or INIT ACK it MUST include
all of its transport addresses in the parameter section. This is all of its transport addresses in the parameter section. This is
because it may NOT be possible to control the "sending" address that because it may NOT be possible to control the "sending" address that
a receiver of a SCTP datagram sees. A receiver thus MUST know every a receiver of a SCTP datagram sees. A receiver thus MUST know every
address that may be a source address for a peer SCTP endpoint, this address that may be a source address for a peer SCTP endpoint, this
assures that the inbound SCTP datagram can be matched to the proper assures that the inbound SCTP datagram can be matched to the proper
association. association.
4.1.1 Handle Stream Parameters 4.1.1 Handle Stream Parameters
In the INIT and INIT ACK messages, the sender of the message shall In the INIT and INIT ACK messages, the sender of the message shall
skipping to change at line 2522 skipping to change at line 2525
discussed in rule C7 above may be used to provide an upper bound discussed in rule C7 above may be used to provide an upper bound
to this doubling operation. to this doubling operation.
E4) Start the retransmission timer, per rule R1 above. E4) Start the retransmission timer, per rule R1 above.
Note, the data sender MAY use a value smaller than the RTO when Note, the data sender MAY use a value smaller than the RTO when
start the retransmission timer IF the sender has fewer than start the retransmission timer IF the sender has fewer than
cwnd octets of outstanding data on the transport address to which cwnd octets of outstanding data on the transport address to which
the retransmission is being sent. the retransmission is being sent.
[Editors Note: if the receiver is multi-homed and the retrans
is to be sent to an alternate address, how this rapid retran
rule should apply??]
Note that after retransmitting, once a new RTT measurement is obtained Note that after retransmitting, once a new RTT measurement is obtained
(which can only happen when new data has been sent and acknowledged, (which can only happen when new data has been sent and acknowledged,
per rule C5, or for a measurement made from a Heartbeat [see Section per rule C5, or for a measurement made from a Heartbeat [see Section
7.3]), the computation in rule C3 is performed, including the 7.3]), the computation in rule C3 is performed, including the
computation of RTO, which may result in "collapsing" RTO back down computation of RTO, which may result in "collapsing" RTO back down
after it has been subject to doubling (rule E3). after it has been subject to doubling (rule E3).
The final rule for managing the retransmission timer concerns failover: The final rule for managing the retransmission timer concerns failover:
F1) Whenever SCTP switches from the current destination transport F1) Whenever SCTP switches from the current destination transport
skipping to change at line 2754 skipping to change at line 2753
IMPLEMENTATION NOTE: if segmentation is not support by the sender, IMPLEMENTATION NOTE: if segmentation is not support by the sender,
an error should be reported to the sender's SCTP user if the data to be an error should be reported to the sender's SCTP user if the data to be
sent has a size exceeding the current MTU. In such cases the Send sent has a size exceeding the current MTU. In such cases the Send
primitive discussed in Section 9.1 would need to return an error primitive discussed in Section 9.1 would need to return an error
to the upper layer. to the upper layer.
Segmentation takes the following steps: Segmentation takes the following steps:
1) the data sender SHALL break the large user message into a series of 1) the data sender SHALL break the large user message into a series of
DATA chunks, each with a total size smaller than the current MTU DATA chunks, such that each of the chunks can be fit into an IP
minus the SCTP common header size (i.e., 8 octets), datagram smaller than the current MTU,
2) the data sender MUST then assign, in sequence, a separate TSN to 2) the data sender MUST then assign, in sequence, a separate TSN to
each of the DATA chunks in the series, each of the DATA chunks in the series,
3) the data sender MUST also set the B/E bits of the first DATA chunk 3) the data sender MUST also set the B/E bits of the first DATA chunk
in the series to '10', the B/E bits of the last DATA chunk in the in the series to '10', the B/E bits of the last DATA chunk in the
series to '01', and the B/E bits of all other DATA chunks in the series to '01', and the B/E bits of all other DATA chunks in the
series to '00'. series to '00'.
The data receiver MUST recognize the segmented DATA chunks, by The data receiver MUST recognize the segmented DATA chunks, by
skipping to change at line 2797 skipping to change at line 2796
Partial chunks MUST NOT be placed in a SCTP datagram. Partial chunks MUST NOT be placed in a SCTP datagram.
The receiver MUST process the chunks in order in the datagram. The The receiver MUST process the chunks in order in the datagram. The
receiver uses the chunk length field to determine the end of a chunk receiver uses the chunk length field to determine the end of a chunk
and beginning of the next chunk taking account of the fact that all and beginning of the next chunk taking account of the fact that all
chunks end on a thirty-two-bit word boundary. If the receiver detects chunks end on a thirty-two-bit word boundary. If the receiver detects
a partial chunk, it MUST drop the chunk. a partial chunk, it MUST drop the chunk.
6. Congestion control 6. Congestion control
[ Editors Notes.. this section is still being reworked and may
have some changes ]
Congestion control is one of the basic functions in the SCTP protocol. Congestion control is one of the basic functions in the SCTP protocol.
It is likely that adequate resources will be allocated to SCTP traffic It is likely that adequate resources will be allocated to SCTP traffic
to assure prompt delivery of time-critical SCTP data, thus it would be to assure prompt delivery of time-critical SCTP data, thus it would be
unlikely, during normal operations, that SCTP transmissions encounter unlikely, during normal operations, that SCTP transmissions encounter
severe congestion condition. However SCTP must prepare itself for severe congestion condition. However SCTP must prepare itself for
adverse operational conditions, which can develop upon partial network adverse operational conditions, which can develop upon partial network
failures or unexpected traffic surge. In such situations SCTP must failures or unexpected traffic surge. In such situations SCTP must
follow correct congestion control steps to recover from congestion follow correct congestion control steps to recover from congestion
quickly in order to get data delivered as soon as possible. In the quickly in order to get data delivered as soon as possible. In the
absence of network congestion, these preventive congestion control absence of network congestion, these preventive congestion control
skipping to change at line 2911 skipping to change at line 2907
max(cwnd / 2, 2*MTU) per RTT. max(cwnd / 2, 2*MTU) per RTT.
Note: a piggy-backed SACK is one that is bundled with a DATA chunk. Note: a piggy-backed SACK is one that is bundled with a DATA chunk.
6.2.2 Congestion Avoidance 6.2.2 Congestion Avoidance
Whenever cwnd is increased to be equal or greater than ssthresh, cwnd Whenever cwnd is increased to be equal or greater than ssthresh, cwnd
should be incremented by MTU per RTT if at time the sender has cwnd or should be incremented by MTU per RTT if at time the sender has cwnd or
more octets of data outstanding on that transport address. more octets of data outstanding on that transport address.
In practice an implementation can In practice an implementation can achieve this goal in the
achieve this goal in the following way: following way:
o cwnd2 is initialized to 0. o cwnd2 is initialized to 0.
o Whenever cwnd is equal or greater than ssthresh, upon each SACK o Whenever cwnd is equal or greater than ssthresh, upon each SACK
arrival, increase cwnd2 by the total number of octets of all new arrival, increase cwnd2 by the total number of octets of all new
chunks acknowledged in that SACK. chunks acknowledged in that SACK.
o When cwnd2 is equal or greater than cwnd and before the arrival of the o When cwnd2 is equal or greater than cwnd and before the arrival of the
SACK the sender has cwnd or more octets of data outstanding, SACK the sender has cwnd or more octets of data outstanding,
increase cwnd by MTU, and reset cwnd2 to (cwnd2 - cwnd). increase cwnd by MTU, and reset cwnd2 to (cwnd2 - cwnd).
o Same as in the slow start, when the sender does not transmit data on
a given transport address, the cwnd of the transport address should
be adjusted to max(cwnd / 2, 2*MTU) per RTT.
6.2.3 Congestion Control 6.2.3 Congestion Control
Upon detection of packet losses from SACK, the sender should do the Upon detection of packet losses from SACK, the sender should do the
following: following:
ssthresh = max(cwnd/2, 2*MTU) ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh/2 cwnd = ssthresh/2
Basically, a packet loss causes cwnd to be cut in half(or 1/4??). Basically, a packet loss causes cwnd to be cut in half(or 1/4??).
skipping to change at line 2961 skipping to change at line 2960
3) Restart T3-rxt timer if it is running, and 3) Restart T3-rxt timer if it is running, and
4) start retransmission procedure, as described in Section 5.3.3. 4) start retransmission procedure, as described in Section 5.3.3.
A straightforward implementation of the above requires that the sender A straightforward implementation of the above requires that the sender
keeps a counter for each TSN hole first reported by a SACK; the keeps a counter for each TSN hole first reported by a SACK; the
counter keeps track of whether 3 subsequent SACKs have reported the counter keeps track of whether 3 subsequent SACKs have reported the
same hole. same hole.
Because cwnd in SCTP bounds the number of outstanding TSN's, Because cwnd in SCTP bounds the number of outstanding TSN's,
the effect of TCP fast-recovery is achieved automatically with no the effect of TCP fast-recovery is achieved automatically with no
adjustment to the control window size. [Is this still true??] adjustment to the control window size.
6.3 Path MTU Discovery 6.3 Path MTU Discovery
RFC 1191 discusses "Path MTU Discovery", whereby a sender maintains an RFC 1191 discusses "Path MTU Discovery", whereby a sender maintains an
estimate of the maximum transmission unit (MTU) along a given Internet path estimate of the maximum transmission unit (MTU) along a given Internet path
and refrains from sending datagrams along that path which exceed the MTU, and refrains from sending datagrams along that path which exceed the MTU,
other than occasional attempts to probe for a change in the path MTU. other than occasional attempts to probe for a change in the path MTU.
RFC 1191 is thorough in its discussion of the MTU discovery mechanism and RFC 1191 is thorough in its discussion of the MTU discovery mechanism and
strategies for determining the current end-to-end MTU setting as well as strategies for determining the current end-to-end MTU setting as well as
detecting changes in this value. RFC 1981 discusses applying the same detecting changes in this value. RFC 1981 discusses applying the same
skipping to change at line 3007 skipping to change at line 3006
discussion in section 6.5 of RFC 1191 applies: when retransmitting discussion in section 6.5 of RFC 1191 applies: when retransmitting
a datagram to a remote address for which the datagram appears a datagram to a remote address for which the datagram appears
too large for the path MTU to that address, the datagram SHOULD too large for the path MTU to that address, the datagram SHOULD
be retransmitted without the DF bit set, allowing it to possibly be retransmitted without the DF bit set, allowing it to possibly
be fragmented. Transmissions of new datagrams MUST have DF set. be fragmented. Transmissions of new datagrams MUST have DF set.
Other than these differences, the discussion of TCP's use of MTU discovery Other than these differences, the discussion of TCP's use of MTU discovery
in RFCs 1191 and 1981 applies to SCTP, too, on a per-destination-address in RFCs 1191 and 1981 applies to SCTP, too, on a per-destination-address
basis. basis.
6.4 Discussion
[The following discussion needs to be updated for byte-based algorithm]
There is one important difference between the SCTP congestion control,
as described above, and TCP congestion control. In the latter the
control behavior is measured in unit of packets. That is, upon slow
start, a TCP connection doubles cwnd value per RTT as measured by the
number of packets. In SCTP, cwnd value is doubled per RTT as measured
by the number of DATA chunks. Similarly, during congestion avoidance,
in the absence of packet losses a TCP connection increases cwnd by one
data packet per RTT, while a SCTP association increases cwnd by one DATA
chunk per RTT.
Ideally, congestion control should be performed by controlling the
number of outstanding packets. However because the DATA chunk size is a
variable, there does not seem a simple and reliable way to translate "one
datagram" to a suitable number of chunks. Although the SCTP congestion
control design, as described in this section, represents a simple
starting point, it may have potential negative impact on the application
performance depending on the relative sizes of DATA chunks and packet
MTU. For example, if the MTU is 5 times of the average DATA chunk size,
it would take 5 times longer for a SCTP association to open up its cwnd
to the same size of that of a TCP connection. During a slow start
congestion recovery, limiting the transmission to cwnd DATA chunks may
lead to sending half-full packets, even when more application data is
waiting to be transmitted.
We suggest that the current design be discussed, and revised if deemed
necessary.
7. Fault Management 7. Fault Management
7.1 Endpoint Failure Detection 7.1 Endpoint Failure Detection
The data sender shall keep a counter on the total number of The data sender shall keep a counter on the total number of
consecutive retransmissions to its peer (including retransmissions to consecutive retransmissions to its peer (including retransmissions to
ALL the destination transport addresses of the peer if it is ALL the destination transport addresses of the peer if it is
multi-homed). multi-homed).
If the value of this counter exceeds the limit defined in the protocol If the value of this counter exceeds the limit defined in the protocol
skipping to change at line 3283 skipping to change at line 3251
None. None.
Optional attributes: Optional attributes:
The following types of attributes may be passed along with The following types of attributes may be passed along with
the primitive: the primitive:
o local port - UDP port number, if ULP wants it to be specified; o local port - UDP port number, if ULP wants it to be specified;
o local eliglible transport address list - A list of eliglible o local eliglible transport address list - A list of eliglible
transport transport addresses that the local SCTP endpoint should bind. By
addresses that the local SCTP endpoint should bind. By default default all transport interface cards should be used by the local
all transport interface cards should be used by the local SCTP
host if no list is given. host if no list is given.
B) Associate B) Associate
Format: ASSOCIATE(local SCTP instance name, destination addr info, Format: ASSOCIATE(local SCTP instance name, destination addr info,
stream count [,eligible transport address list] [,timer info]) stream count [,eligible transport address list] [,timer info])
-> association id [,destination net list] [,outbound stream count] -> association id [,destination net list] [,outbound stream count]
This primitive allows the upper layer to initiate an association to a This primitive allows the upper layer to initiate an association to a
specific peer endpoint. The peer endpoint shall be specified by one of specific peer endpoint. The peer endpoint shall be specified by one of
skipping to change at line 3559 skipping to change at line 3526
result can be an intager containing the most recent RTT in result can be an intager containing the most recent RTT in
milliseconds. milliseconds.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o transport address - the transport address of the association o transport address - the transport address of the association
on which the RTT measurement is to be reported. on which the RTT measurement is to be reported.
L) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id, protocol parameter list)
-> result
This primitive allows the local SCTP to customize the protocol
parameters.
Mandatory attributes:
o association id - local handle to the SCTP association
o protocol parameter list - The specific values of the protocol
parameters (e.g., RTO.Initial, Max.Retransmits, [see Section 12])
that the SCTP user wishes to customized.
9.2 SCTP-to-ULP 9.2 SCTP-to-ULP
It is assumed that the operating system or application environment It is assumed that the operating system or application environment
provides a means for the SCTP to asynchronously signal the ULP provides a means for the SCTP to asynchronously signal the ULP
process. When SCTP does signal an ULP process, certain information is process. When SCTP does signal an ULP process, certain information is
passed to the ULP. passed to the ULP.
A) DATA ARRIVE notification A) DATA ARRIVE notification
SCTP shall invoke this notification on the ULP when a datagram is SCTP shall invoke this notification on the ULP when a datagram is
skipping to change at line 3699 skipping to change at line 3682
As a common transport protocol designed to reliably carry time- As a common transport protocol designed to reliably carry time-
sensitive user messages, such as billing or signalling messages for sensitive user messages, such as billing or signalling messages for
telephony services, between two networked endpoints, SCTP has the telephony services, between two networked endpoints, SCTP has the
following security objectives. following security objectives.
- availability of reliable and timely data transport services - availability of reliable and timely data transport services
- integrity of the user-to-user information carried by SCTP - integrity of the user-to-user information carried by SCTP
10.2 SCTP Responses To Potential Threats 10.2 SCTP Responses To Potential Threats
It is clear that SCTP may potentially be used in a wide variety of It is clear that SCTP may potentially be used in a wide variety of
risk situations. It is important for operator(s) of the SCTP Hosts risk situations. It is important for operator(s) of the systems
concerned to analyze their particular situations and decide on the concerned to analyze their particular situations and decide on the
appropriate counter-measures. appropriate counter-measures.
Where the SCTP Host serves a group of users, it is probably Where the SCTP system serves a group of users, it is probably
operating as part of a professionally managed corporate or service operating as part of a professionally managed corporate or service
provider network. It is reasonable to expect that this management provider network. It is reasonable to expect that this management
includes an appropriate security policy framework. [RFC 2196, "Site includes an appropriate security policy framework. [RFC 2196, "Site
Security Handbook", B. Fraser Ed., September 1997] should be Security Handbook", B. Fraser Ed., September 1997] should be
consulted for guidance. consulted for guidance.
The case is more difficult where the SCTP Host is operated by a The case is more difficult where the SCTP system is operated by a
private user. The service provider with whom that user has a private user. The service provider with whom that user has a
contractual arrangement SHOULD provide help to ensure that the contractual arrangement SHOULD provide help to ensure that the
user's site is secure, ranging from advice on configuration through user's site is secure, ranging from advice on configuration through
downloaded scripts and security software. downloaded scripts and security software.
10.2.1 Countering Insider Attacks 10.2.1 Countering Insider Attacks
The principles of the Site Security Handbook [ ] should be applied The principles of the Site Security Handbook [ ] should be applied
to minimize the risk of theft of information or sabotage by to minimize the risk of theft of information or sabotage by
insiders. These include publication of security policies, control insiders. These include publication of security policies, control
skipping to change at line 3753 skipping to change at line 3736
may be considered. As with the supplementary checksum service, user may be considered. As with the supplementary checksum service, user
data encryption may be performed either by the SCTP user application data encryption may be performed either by the SCTP user application
or as a service of SCTP itself. If it is performed by SCTP, the or as a service of SCTP itself. If it is performed by SCTP, the
user data must be encrypted before any checksum is applied. user data must be encrypted before any checksum is applied.
Particularly for mobile users, the requirement for confidentiality Particularly for mobile users, the requirement for confidentiality
may include the masking of IP addresses and ports. In this case may include the masking of IP addresses and ports. In this case
IPSEC ESP should be used instead of application-level encryption. IPSEC ESP should be used instead of application-level encryption.
Similarly, where other reasons prompt the use of the IPSEC ESP Similarly, where other reasons prompt the use of the IPSEC ESP
service, application-level encryption is unnecessary. It will be up service, application-level encryption is unnecessary. It will be up
to the SCTP Host operators to configure the application to the SCTP system operators to configure the application
appropriately. appropriately.
Regardless of which level performs the encryption, the IPSEC ISAKMP Regardless of which level performs the encryption, the IPSEC ISAKMP
service should be used for key management. service should be used for key management.
Operators should consult [RFC 2401, "Security Architecture for the Operators should consult [RFC 2401, "Security Architecture for the
Internet Protocol", S. Kent, R. Atkinson, November 1998] for Internet Protocol", S. Kent, R. Atkinson, November 1998] for
information on the configuration of IPSEC services between hosts information on the configuration of IPSEC services between hosts
with and without intervening firewalls. with and without intervening firewalls.
10.2.4 Protecting against Blind Denial of Service Attacks 10.2.4 Protecting against Blind Denial of Service Attacks
A blind attack is one where the attacker is unable to intercept or A blind attack is one where the attacker is unable to intercept or
otherwise see the content of data flows passing to and from the otherwise see the content of data flows passing to and from the
target SCTP Host where it is not a party to the association. Blind target SCTP node where it is not a party to the association. Blind
denial of service attacks may take the form of flooding, masquerade, denial of service attacks may take the form of flooding, masquerade,
or improper monopolization of services. or improper monopolization of services.
10.2.4.1 Flooding 10.2.4.1 Flooding
The objective of flooding is to cause loss of service and incorrect The objective of flooding is to cause loss of service and incorrect
behaviour at target systems through resource exhaustion, interference behaviour at target systems through resource exhaustion, interference
with legitimate transactions, and exploitation of buffer-related with legitimate transactions, and exploitation of buffer-related
software bugs. Flooding may be directed either at the SCTP Host or at software bugs. Flooding may be directed either at the SCTP node or at
resources in the intervening IP Access Links or the Internetwork. resources in the intervening IP Access Links or the Internetwork.
Where the latter entities are the target, flooding will manifest Where the latter entities are the target, flooding will manifest
itself as loss of network services, including potentially the breach itself as loss of network services, including potentially the breach
of any firewalls in place. of any firewalls in place.
In general, protection against flooding begins at the equipment In general, protection against flooding begins at the equipment
design level, where it includes measures such as: design level, where it includes measures such as:
- avoiding commitment of limited resources before determining that - avoiding commitment of limited resources before determining that
the request for service is legitimate the request for service is legitimate
- giving priority to completion of processing in progress over the - giving priority to completion of processing in progress over the
acceptance of new work acceptance of new work
- identification and removal of duplicate or stale queued requests - identification and removal of duplicate or stale queued requests
for service. for service.
Network equipment should be capable of generating an alarm and log Network equipment should be capable of generating an alarm and log
if a suspicious increase in traffic occurs. The log should provide if a suspicious increase in traffic occurs. The log should provide
information such as the identity of the incoming link and source information such as the identity of the incoming link and source
address(es) used which will help the network or SCTP Host operator address(es) used which will help the network or SCTP system operator
to take protective measures. Procedures should be in place for the to take protective measures. Procedures should be in place for the
operator to act on such alarms if a clear pattern of abuse emerges. operator to act on such alarms if a clear pattern of abuse emerges.
The design of SCTP is resistant to flooding attacks, particularly in The design of SCTP is resistant to flooding attacks, particularly in
its use of a four-way start-up handshake, its use of a cookie to its use of a four-way start-up handshake, its use of a cookie to
defer commitment of resources at the responding SCTP Host until the defer commitment of resources at the responding SCTP node until the
handshake is completed, and its use of a verification tag to prevent handshake is completed, and its use of a verification tag to prevent
insertion of extraneous messages into the flow of an established insertion of extraneous messages into the flow of an established
association. association.
10.2.4.2 Masquerade 10.2.4.2 Masquerade
Masquerade can be used to deny service in several ways: Masquerade can be used to deny service in several ways:
- by tying up resources at the target SCTP Host to which the - by tying up resources at the target SCTP node to which the
impersonated host has limited access. For example, the target host impersonated node has limited access. For example, the target node
may by policy permit a maximum of one SCTP association with the may by policy permit a maximum of one SCTP association with the
impersonated SCTP Host. The masquerading attacker may attempt to impersonated SCTP node. The masquerading attacker may attempt to
establish an association purporting to come from the impersonated establish an association purporting to come from the impersonated
host so that the latter cannot do so when it requires it. node so that the latter cannot do so when it requires it.
- by deliberately allowing the impersonation to be detected, - by deliberately allowing the impersonation to be detected,
thereby provoking counter-measures which cause the impersonated host thereby provoking counter-measures which cause the impersonated node
to be locked out of the target SCTP Host to be locked out of the target SCTP node.
- by interfering with an established association by inserting - by interfering with an established association by inserting
extraneous content such as a SHUTDOWN request. extraneous content such as a SHUTDOWN request.
SCTP prevents masquerade through IP spoofing by use of the four-way SCTP prevents masquerade through IP spoofing by use of the four-way
startup handshake. Because the initial exchange is memoryless, no startup handshake. Because the initial exchange is memoryless, no
lockout mechanism is triggered by masquerade attacks. SCTP protects lockout mechanism is triggered by masquerade attacks. SCTP protects
against insertion of extraneous messages into the flow of an against insertion of extraneous messages into the flow of an
established association by use of the verification tag. established association by use of the verification tag.
Logging of received INIT requests and abnormalities such as Logging of received INIT requests and abnormalities such as
unexpected INIT ACKs might be considered as a way to detect patterns unexpected INIT ACKs might be considered as a way to detect patterns
of hostile activity. However, the potential usefulness of such of hostile activity. However, the potential usefulness of such
logging must be weighed against the increased SCTP startup logging must be weighed against the increased SCTP startup
processing it implies, rendering the SCTP Host more vulnerable to processing it implies, rendering the SCTP node more vulnerable to
flooding attacks. Logging is pointless without the establishment of flooding attacks. Logging is pointless without the establishment of
operating procedures to review and analyze the logs on a routine operating procedures to review and analyze the logs on a routine
basis. basis.
10.2.4.3 Improper Monopolization of Services 10.2.4.3 Improper Monopolization of Services
Attacks under this heading are performed openly and legitimately by Attacks under this heading are performed openly and legitimately by
the attacker. They are directed against fellow users of the target the attacker. They are directed against fellow users of the target
SCTP Host or of the shared resources between the attacker and the SCTP node or of the shared resources between the attacker and the
target host. Possible attacks include the opening of a large number target node. Possible attacks include the opening of a large number
of associations between the attacker's host and the target, or of associations between the attacker's node and the target, or
transfer of large volumes of information within a legitimately- transfer of large volumes of information within a legitimately-
established association. established association.
Such attacks take advantage of policy deficiencies at the target Such attacks take advantage of policy deficiencies at the target
SCTP Host. Defense begins with a contractual prohibition of SCTP node. Defense begins with a contractual prohibition of
behaviour directed to denial of service to others. Policy limits behaviour directed to denial of service to others. Policy limits
should be placed on the number of associations per adjoining SCTP should be placed on the number of associations per adjoining SCTP
Host. SCTP user applications should be capable of detecting large node. SCTP user applications should be capable of detecting large
volumes of illegitimate or "no-op" messages within a given volumes of illegitimate or "no-op" messages within a given
association and either logging or terminating the association as a association and either logging or terminating the association as a
result, based on local policy. result, based on local policy.
10.3 Protection against Fraud and Repudiation 10.3 Protection against Fraud and Repudiation
The objective of fraud is to obtain services without authorization The objective of fraud is to obtain services without authorization
and specifically without paying for them. In order to achieve this and specifically without paying for them. In order to achieve this
objective, the attacker must induce the SCTP user application at the objective, the attacker must induce the SCTP user application at the
target SCTP Host to provide the desired service while accepting target SCTP node to provide the desired service while accepting
invalid billing data or failing to collect it. Repudiation is a invalid billing data or failing to collect it. Repudiation is a
related problem, since it may occur as a deliberate act of fraud or related problem, since it may occur as a deliberate act of fraud or
simply because the repudiating party kept inadequate records of simply because the repudiating party kept inadequate records of
service received. service received.
Potential fraudulent attacks include interception and misuse of Potential fraudulent attacks include interception and misuse of
authorizing information such as credit card numbers, blind authorizing information such as credit card numbers, blind
masquerade and replay, and man-in-the middle attacks which modify masquerade and replay, and man-in-the middle attacks which modify
the messages passing through a target SCTP association in real time. the messages passing through a target SCTP association in real time.
skipping to change at line 3888 skipping to change at line 3871
association. association.
However, SCTP does not protect against man-in-the-middle attacks However, SCTP does not protect against man-in-the-middle attacks
where the attacker is able to intercept and alter the messages sent where the attacker is able to intercept and alter the messages sent
and received in an association. Where a significant possibility of and received in an association. Where a significant possibility of
such attacks is seen to exist, or where possible repudiation is an such attacks is seen to exist, or where possible repudiation is an
issue, the use of the IPSEC AH service is recommended to ensure both issue, the use of the IPSEC AH service is recommended to ensure both
the integrity and the authenticity of the messages passed. the integrity and the authenticity of the messages passed.
SCTP also provides no protection against attacks originating at or SCTP also provides no protection against attacks originating at or
beyond the SCTP Host and taking place within the context of an beyond the SCTP node and taking place within the context of an
existing association. Prevention of such attacks should be covered existing association. Prevention of such attacks should be covered
by appropriate security policies at the host site, as discussed in by appropriate security policies at the host site, as discussed in
section 10.2.1. section 10.2.1.
11. IANA Consideration 11. IANA Consideration
This protocol may be extended through IANA in three ways: This protocol may be extended through IANA in three ways:
-- through definition of additional chunk types, -- through definition of additional chunk types,
-- through definition of additional parameter types, or -- through definition of additional parameter types, or
-- through definition of additional cause codes within Operation -- through definition of additional cause codes within Operation
skipping to change at line 4023 skipping to change at line 4006
12. Suggested SCTP Protocol Parameter Values 12. Suggested SCTP Protocol Parameter Values
The following protocol parameters are recommended: The following protocol parameters are recommended:
RTO.Initial - 3 seconds RTO.Initial - 3 seconds
Valid.Cookie.Life - 5 seconds Valid.Cookie.Life - 5 seconds
Max.Retransmits - 10 attempts Max.Retransmits - 10 attempts
Max.Init.Retransmit - 8 attempts Max.Init.Retransmit - 8 attempts
Max.HeartBeat.Misses - 3 attempts Max.HeartBeat.Misses - 3 attempts
IMPLEMENTATION NOTE: The SCTP implementation SHOULD allow ULP to
customize these protocol parameters.
Miscellaneous protocol variables/counters: Miscellaneous protocol variables/counters:
'retrans.count' - per association counter 'retrans.count' - per association counter
'heartbeat.sent.count' - per destination transport address counter 'heartbeat.sent.count' - per destination transport address counter
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Mark Allman, Richard Band, Scott Bradner, The authors wish to thank Mark Allman, Richard Band, Scott Bradner,
Ram Dantu, R. Ezhirpavai, Sally Floyd, Matt Holdrege, Henry Houh, Gary Ram Dantu, R. Ezhirpavai, Sally Floyd, Matt Holdrege, Henry Houh, Gary
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/