draft-ietf-tsvwg-addip-sctp-01.txt   draft-ietf-tsvwg-addip-sctp-02.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Cisco Systems Cisco Systems
Q. Xie Q. Xie
Motorola Motorola
M. Tuexen M. Tuexen
Siemens AG Siemens AG
I. Rytina I. Rytina
Ericsson Ericsson
P. Conrad P. Conrad
Temple University Temple University
expires in six months June 6, 2001 expires in six months June 29, 2001
SCTP Extensions for Dynamic Reconfiguration of IP Addresses SCTP Extensions for Dynamic Reconfiguration of IP Addresses
and Enforcement of Flow and Message Limits and Enforcement of Flow and Message Limits
<draft-ietf-tsvwg-addip-sctp-01.txt> <draft-ietf-tsvwg-addip-sctp-02.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts
are working documents of the Internet Engineering Task Force (IETF), are working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute 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 page 1, line 49 skipping to change at page 1, line 49
Transmission Protocol (SCTP) [RFC2960] that provide methods to (1) Transmission Protocol (SCTP) [RFC2960] that provide methods to (1)
reconfigure IP address information on an existing association and reconfigure IP address information on an existing association and
(2) request that a peer set flow limits in units of bytes or (2) request that a peer set flow limits in units of bytes or
messages, either on a per-stream or per-association basis. messages, either on a per-stream or per-association basis.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction............................................... 2 1. Introduction............................................... 2
2. Conventions................................................ 3 2. Conventions................................................ 3
3. Additional Chunks and Parameters........................... 3 3. Additional Chunks and Parameters........................... 3
3.1 New Chunk Types........................................... 4 3.1 New Chunk Types........................................... 4
3.1.1 Address Configuration Change Chunk (ASCONF)............ 4 3.1.1 Address/Stream Configuration Change Chunk (ASCONF)...... 4
3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK). 5 3.1.2 Address/Stream Configuration Acknowledgment Chunk
(ASCONF-ACK)............................................ 5
3.2 New Parameter Types....................................... 6 3.2 New Parameter Types....................................... 6
3.2.1 Add IP Address.......................................... 7 3.2.1 Add IP Address.......................................... 7
3.2.2 Delete IP Address....................................... 7 3.2.2 Delete IP Address....................................... 7
3.2.3 Stream Flow Limit Change................................ 8 3.2.3 Stream Flow Limit Change................................ 8
3.2.4 Error Cause Indication.................................. 9 3.2.4 Error Cause Indication.................................. 9
3.2.5 Set Primary IP Address.................................. 9 3.2.5 Set Primary IP Address.................................. 9
3.2.6 Success Indication......................................10 3.2.6 Success Indication......................................10
3.2.7 Stream Message Limit Change.............................10 3.2.7 Stream Message Limit Change.............................10
3.2.8 Association Message Limit Change........................11 3.2.8 Association Message Limit Change........................11
3.3 New Error Causes..........................................11 3.3 New Error Causes..........................................11
3.3.1 Error Cause: Request to Delete Last Remaining 3.3.1 Error Cause: Request to Delete Last Remaining IP
IP Address..............................................12 Address.................................................12
3.3.2 Error Cause: Operation Refused Due to Resource Shortage.12 3.3.2 Error Cause: Operation Refused Due to Resource Shortage.12
3.3.3 Error Cause: Request to Delete Source IP Address........13 3.3.3 Error Cause: Request to Delete Source IP Address........13
4. Procedures.................................................13 4. Procedures.................................................13
4.1 ASCONF Chunk Procedures...................................14 4.1 ASCONF Chunk Procedures...................................14
4.1.1 Congestion Control of ASCONF Chunks.....................15 4.1.1 Congestion Control of ASCONF Chunks.....................15
4.2 Upon reception of an ASCONF Chunk.........................16 4.2 Upon reception of an ASCONF Chunk.........................16
4.3 General rules for address manipulation....................18 4.3 General rules for address manipulation....................18
4.3.1 A special case for OOTB ABORT chunks....................20 4.3.1 A special case for OOTB ABORT chunks....................20
4.3.2 A special case for changing an address..................21 4.3.2 A special case for changing an address..................21
4.4 Setting of the primary address............................21 4.4 Setting of the primary address............................21
4.5 Stream Flow/Message Limit Procedures......................21 4.5 Stream Flow/Message Limit Procedures......................22
4.5.1 Stream receiver side procedures.........................22 4.5.1 Stream receiver side procedures.........................22
4.5.2 Stream sender side procedures...........................23 4.5.2 Stream sender side procedures...........................23
4.5.3 ULP considerations on the use of SCTP flow limit 4.5.3 ULP considerations on the use of SCTP flow limit
facility................................................24 facility................................................24
4.6 Association Message Limit Procedures......................24 4.6 Association Message Limit Procedures......................25
4.6.1 Receiver side procedures................................25 4.6.1 Receiver side procedures................................25
4.6.2 Sender side procedures..................................25 4.6.2 Sender side procedures..................................25
5. Security Considerations....................................25 5. Security Considerations....................................26
6. IANA considerations........................................26 6. IANA considerations........................................26
7. Authors' Addresses.........................................26 7. Authors' Addresses.........................................26
8. References.................................................27 8. References.................................................27
1. Introduction 1. Introduction
To extend the utility and application scenarios of SCTP, this To extend the utility and application scenarios of SCTP, this
document introduces optional extensions that provide SCTP with the document introduces optional extensions that provide SCTP with the
ability to reconfigure IP address information on an existing ability to reconfigure IP address information on an existing
association or to request that the peer set flow limits in units association or to request that the peer set flow limits in units
skipping to change at page 4, line 28 skipping to change at page 4, line 29
It should be noted that the ASCONF Chunk format requires the It should be noted that the ASCONF Chunk format requires the
receiver to report to the sender if it does not understand the receiver to report to the sender if it does not understand the
ASCONF Chunk. This is accomplished by setting the upper bits in the ASCONF Chunk. This is accomplished by setting the upper bits in the
chunk type as described in [RFC2960] section 3.2. Note that the chunk type as described in [RFC2960] section 3.2. Note that the
upper two bits in the ASCONF Chunk are set to one. As defined in upper two bits in the ASCONF Chunk are set to one. As defined in
[RFC2960] section 3.2, setting these upper bits in this manner will [RFC2960] section 3.2, setting these upper bits in this manner will
cause the receiver that does not understand this chunk to skip the cause the receiver that does not understand this chunk to skip the
chunk and continue processing, but report in an Operation Error chunk and continue processing, but report in an Operation Error
Chunk using the 'Unrecognized Chunk Type' cause of error. Chunk using the 'Unrecognized Chunk Type' cause of error.
3.1.1 Address Configuration Change Chunk (ASCONF) 3.1.1 Address/Stream Configuration Change Chunk (ASCONF)
This chunk is used to communicate to the remote endpoint one of the This chunk is used to communicate to the remote endpoint one of the
configuration change requests that MUST be acknowledged. The configuration change requests that MUST be acknowledged. The
information carried in the ASCONF Chunk uses the form of a information carried in the ASCONF Chunk uses the form of a
Tag-Length-Value (TLV), as described in "3.2.1 Tag-Length-Value (TLV), as described in "3.2.1
Optional/Variable-length Parameter Format" in [RFC2960], for Optional/Variable-length Parameter Format" in [RFC2960], for
all variable parameters. all variable parameters.
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
skipping to change at page 5, line 54 skipping to change at page 5, line 55
bit value into the ASCONF Correlation ID field of the bit value into the ASCONF Correlation ID field of the
ASCONF-ACK. The sender of the ASCONF can use this same value in the ASCONF-ACK. The sender of the ASCONF can use this same value in the
ASCONF-ACK to find which request the response is for. ASCONF-ACK to find which request the response is for.
ASCONF Parameter: TLV format ASCONF Parameter: TLV format
Each Address configuration change is represented by a TLV Each Address configuration change is represented by a TLV
parameter as defined in Section 3.2. One or more requests parameter as defined in Section 3.2. One or more requests
may be present in an ASCONF Chunk. may be present in an ASCONF Chunk.
3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK) 3.1.2 Address/Stream Configuration Acknowledgment Chunk (ASCONF-ACK)
This chunk is used by the receiver of an ASCONF Chunk to acknowledge This chunk is used by the receiver of an ASCONF Chunk to acknowledge
the reception. It carries zero or more results for any ASCONF the reception. It carries zero or more results for any ASCONF
Parameters that were processed by the receiver. Parameters that were processed by the receiver.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x80 | Chunk Flags | Chunk Length | | Type = 0x80 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 50 skipping to change at page 14, line 50
successful if not reported. All TLVs after the failed response are successful if not reported. All TLVs after the failed response are
considered unsuccessful unless a specific success indication is considered unsuccessful unless a specific success indication is
present for the parameter. present for the parameter.
A8) If there is no response(s) to specific TLV parameter(s), and no A8) If there is no response(s) to specific TLV parameter(s), and no
failures are indicated, then all request(s) are considered failures are indicated, then all request(s) are considered
successful. successful.
If the T-4 RTO timer expires the endpoint should do the following: If the T-4 RTO timer expires the endpoint should do the following:
B1) Increment the error counter and perform path failure detection B1) Increment the error counters and perform path failure detection
on the appropriate destination address as defined in [RFC2960] on the appropriate destination address as defined in [RFC2960]
section 8.2. section 8.1 and 8.2. Note error counters include the per destination
error counter as well as the overall association error counter.
B2) Increment the association error counter and perform endpoint B2) Increment the association error counters and perform endpoint
failure detection on the association as defined in [RFC2960] section failure detection on the association as defined in [RFC2960] section
8.1. 8.1 and 8.2. Note error counters include the per destination
error counter as well as the overall association error counter.
B3) Back-off the destination address RTO timer to which the ASCONF B3) Back-off the destination address RTO timer to which the ASCONF
chunk was sent by doubling the RTO timer value. chunk was sent by doubling the RTO timer value.
B4) Re-transmit the ASCONF Chunk last sent and if possible choose an B4) Re-transmit the ASCONF Chunk last sent and if possible choose an
alternate destination address (please refer to [RFC2960] section alternate destination address (please refer to [RFC2960] section
6.4.1). An endpoint MUST NOT add new parameters to this chunk, it 6.4.1). An endpoint MUST NOT add new parameters to this chunk, it
MUST be the same (including its serial number) as the last ASCONF MUST be the same (including its serial number) as the last ASCONF
sent. sent.
skipping to change at page 15, line 51 skipping to change at page 15, line 54
chunk is using an alternate source address as the source in chunk is using an alternate source address as the source in
the IP header, then NO other chunks may be bundled with the ASCONF the IP header, then NO other chunks may be bundled with the ASCONF
chunk. chunk.
R4) A ASCONF-ACK may be bundled with any other chunk type except R4) A ASCONF-ACK may be bundled with any other chunk type except
other ASCONF-ACKs. other ASCONF-ACKs.
R5) Both ASCONF and ASCONF-ACK chunks MUST NOT be sent in any SCTP R5) Both ASCONF and ASCONF-ACK chunks MUST NOT be sent in any SCTP
state except ESTABLISHED. state except ESTABLISHED.
R6) An ASCONF and respective ASCONF-ACK MUST NOT be larger than the R6) An ASCONF MUST NOT be larger than the path MTU of the destination.
path MTU of the destination.
R7) An ASCONF-ACK SHOULD not be larger than the path MTU. In some
circumstances a ASCONF-ACK may exceed the path MTU and in such
a case IP fragmentation must be used.
If the sender of an ASCONF Chunk receives a Operational Error If the sender of an ASCONF Chunk receives a Operational Error
indicating that the ASCONF chunk type is not understood, then the indicating that the ASCONF chunk type is not understood, then the
sender MUST not send subsequent ASCONF Chunks to the peer. The sender MUST not send subsequent ASCONF Chunks to the peer. The
endpoint should also inform the upper layer application that the endpoint should also inform the upper layer application that the
peer endpoint does not support any of the extensions detailed in this peer endpoint does not support any of the extensions detailed in this
document. document.
4.2 Upon reception of an ASCONF Chunk. 4.2 Upon reception of an ASCONF Chunk.
skipping to change at page 18, line 23 skipping to change at page 18, line 27
arrives. This means that until such time as the ASCONF containing arrives. This means that until such time as the ASCONF containing
the add is acknowledged the sender MUST NOT use the new IP address the add is acknowledged the sender MUST NOT use the new IP address
as a source for ANY SCTP chunks besides an ASCONF Chunk. as a source for ANY SCTP chunks besides an ASCONF Chunk.
The receiver of the add IP address request may use the The receiver of the add IP address request may use the
address as a destination immediately. address as a destination immediately.
D2) After the ASCONF-ACK of an IP address add arrives, the D2) After the ASCONF-ACK of an IP address add arrives, the
endpoint MAY begin using the added IP address as a source endpoint MAY begin using the added IP address as a source
address for any type of SCTP chunk. address for any type of SCTP chunk.
D3) If an endpoint receives an Error Cause TLV indicating that the D3a) If an endpoint receives an Error Cause TLV indicating that the
IP address Add, IP address Deletion, or Set Primary IP Address IP address Add or IP address Deletion parameters was not understood,
parameters was not understood, the endpoint MUST consider the the endpoint MUST consider the operation failed and MUST NOT attempt
operation failed and MUST NOT attempt to send any subsequent Add, to send any subsequent Add or Delete requests to the peer.
Delete or Set Primary requests to the peer.
D3b) If an endpoint receives an Error Cause TLV indicating that the
IP address Set Primary IP Address parameter was not understood,
the endpoint MUST consider the operation failed and MUST NOT attempt
to send any subsequent Set Primary IP Address requests to the peer.
D4) When deleting an IP address from an association, the IP address D4) When deleting an IP address from an association, the IP address
MUST be considered a valid destination address for the reception of MUST be considered a valid destination address for the reception of
SCTP packets until the ASCONF-ACK arrives and MUST NOT be used as a SCTP packets until the ASCONF-ACK arrives and MUST NOT be used as a
source address for any subsequent packets. This means that any source address for any subsequent packets. This means that any
datagrams that arrive before the ASCONF-ACK destined to the IP address datagrams that arrive before the ASCONF-ACK destined to the IP address
being deleted MUST be considered part of the current being deleted MUST be considered part of the current
association. One special consideration is that ABORT chunks arriving association. One special consideration is that ABORT chunks arriving
destined to the IP address being deleted MUST be ignored (see destined to the IP address being deleted MUST be ignored (see
Section 4.3.1 for further details). Section 4.3.1 for further details).
skipping to change at page 23, line 18 skipping to change at page 23, line 29
the cookie, provided that the peer indicates that it understands the the cookie, provided that the peer indicates that it understands the
requested limit by NOT placing an 'unrecognized parameter' error in requested limit by NOT placing an 'unrecognized parameter' error in
the cookie. the cookie.
To send initial limits, ASCONF chunks are NOT bundled with the INIT To send initial limits, ASCONF chunks are NOT bundled with the INIT
or INIT-ACK. Instead the TLV is added to the variable parameters or INIT-ACK. Instead the TLV is added to the variable parameters
section of the INIT or INIT-ACK. section of the INIT or INIT-ACK.
Note that the parameter type field upper two bits dictates that any Note that the parameter type field upper two bits dictates that any
parameter not understood should be skipped and reported to the parameter not understood should be skipped and reported to the
sender with an Operational Error. If an Operational Error is sender with an Operational Error. With this in mind we make the
received that indicates that the 'Stream Byte Limit Request' or following rules for the sender of the request:
'Stream Message Limit Request' is not understood, the sender of the
limit request MUST not send subsequent limit requests. The endpoint Z1) If an Operational Error is received that indicates that the
SHOULD also inform the upper layer application that the peer 'Stream Byte Limit Request' is not understood, the sender of the
endpoint does not support this feature. limit request MUST not send subsequent limit requests. The
endpoint SHOULD also inform the upper layer application that
the peer endpoint does not support this feature.
Z2) If an Operational Error is received that indicates that the
'Stream Message Limit Request' is not understood, the sender of
the limit request MUST not send subsequent limit requests. The
endpoint SHOULD also inform the upper layer application that the
peer endpoint does not support this feature.
4.5.2 Stream Sender side procedures 4.5.2 Stream Sender side procedures
When a 'Stream Byte Limit Request' or 'Stream Message Limit When a 'Stream Byte Limit Request' or 'Stream Message Limit
Request' is received the sender MUST record each limit with its Request' is received the sender MUST record each limit with its
appropriate stream. appropriate stream.
After a limit is set on a stream the sender MUST obey the following After a limit is set on a stream the sender MUST obey the following
rules when sending to the peer on that stream: rules when sending to the peer on that stream:
skipping to change at page 24, line 18 skipping to change at page 24, line 37
is larger than the current limit for this stream, the SCTP endpoint is larger than the current limit for this stream, the SCTP endpoint
MUST reject the request and NOT queue the data for transmit and MUST reject the request and NOT queue the data for transmit and
instead SHOULD return an error to the application. instead SHOULD return an error to the application.
S3b) If the number of outstanding messages is less than the current S3b) If the number of outstanding messages is less than the current
limit, accept the data for transmit and queue the user data limit, accept the data for transmit and queue the user data
(increasing the number of outstanding messages on this stream). (increasing the number of outstanding messages on this stream).
S4) Any time a stream limit is updated to the value of 0, consider S4) Any time a stream limit is updated to the value of 0, consider
this indication to mean no limit is in effect for this stream. this indication to mean no limit is in effect for this stream.
S5) Any stream number NOT mentioned in a limit request MUST be left
unchanged. In other words failure to mention a stream in a
limit request leaves the un-mentioned stream unchanged.
S6) If a stream limit is reduced and the stream already exceeds
the stream limit, no changes are made with respect to the
outstanding data. New data request MUST be rejected however,
until the streams limit will allow the sending of data (rules
S2 and S3 above).
NOTE: Stream limits do NOT change the underlying SCTP rwnd and NOTE: Stream limits do NOT change the underlying SCTP rwnd and
its usage as defined in [RFC2960]. The association MUST still its usage as defined in [RFC2960]. The association MUST still
honor the rwnd when sending to the peer endpoint as defined in honor the rwnd when sending to the peer endpoint as defined in
[RFC2960]. [RFC2960].
4.5.3 ULP considerations on the use of SCTP flow limit facility 4.5.3 ULP considerations on the use of SCTP flow limit facility
A side-effect of rule S3 in section 4.5.2 is that an upper limit A side-effect of rule S3 in section 4.5.2 is that an upper limit
is imposed on the size of messages that may be sent to any stream is imposed on the size of messages that may be sent to any stream
 End of changes. 

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