draft-ietf-tsvwg-addip-sctp-07.txt   draft-ietf-tsvwg-addip-sctp-08.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft M. Ramalho Internet-Draft M. Ramalho
Expires: August 27, 2003 Cisco Systems, Inc. Expires: March 24, 2004 Cisco Systems, Inc.
Q. Xie Q. Xie
Motorola, Inc. Motorola, Inc.
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster
I. Rytina I. Rytina
M. Belinchon M. Belinchon
Ericsson Ericsson
P. Conrad P. Conrad
Temple University Temple University
February 26, 2003 September 24, 2003
Stream Control Transmission Protocol (SCTP) Dynamic Address Stream Control Transmission Protocol (SCTP) Dynamic Address
Reconfiguration Reconfiguration
draft-ietf-tsvwg-addip-sctp-07.txt draft-ietf-tsvwg-addip-sctp-08.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 RFC2026. all provisions of Section 10 of RFC2026.
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 other
other groups may also distribute working documents as groups may also distribute working documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2003. This Internet-Draft will expire on March 24, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes extensions to the Stream Control Transmission This document describes extensions to the Stream Control Transmission
Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
address information on an existing association. address information on an existing association.
skipping to change at page 2, line 19 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Additional Chunks and Parameters . . . . . . . . . . . . . . 5 3. Additional Chunks and Parameters . . . . . . . . . . . . . . 5
3.1 New Chunk Types . . . . . . . . . . . . . . . . . . . . . . 5 3.1 New Chunk Types . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Address Configuration Change Chunk (ASCONF) . . . . . . . . 5 3.1.1 Address Configuration Change Chunk (ASCONF) . . . . . . . . 5
3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK) . . 6 3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK) . . 6
3.2 New Parameter Types . . . . . . . . . . . . . . . . . . . . 7 3.2 New Parameter Types . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Add IP Address . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1 Add IP Address . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Delete IP Address . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 Delete IP Address . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Error Cause Indication . . . . . . . . . . . . . . . . . . . 10 3.2.3 Error Cause Indication . . . . . . . . . . . . . . . . . . . 10
3.2.4 Set Primary IP Address . . . . . . . . . . . . . . . . . . . 11 3.2.4 Set Primary IP Address . . . . . . . . . . . . . . . . . . . 10
3.2.5 Success Indication . . . . . . . . . . . . . . . . . . . . . 12 3.2.5 Success Indication . . . . . . . . . . . . . . . . . . . . . 11
3.2.6 Adaptation Layer Indication . . . . . . . . . . . . . . . . 12 3.2.6 Adaptation Layer Indication . . . . . . . . . . . . . . . . 12
3.3 New Error Causes . . . . . . . . . . . . . . . . . . . . . . 13 3.3 New Error Causes . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1 Error Cause: Request to Delete Last Remaining IP Address . . 13 3.3.1 Error Cause: Request to Delete Last Remaining IP Address . . 13
3.3.2 Error Cause: Operation Refused Due to Resource Shortage . . 14 3.3.2 Error Cause: Operation Refused Due to Resource Shortage . . 14
3.3.3 Error Cause: Request to Delete Source IP Address . . . . . . 15 3.3.3 Error Cause: Request to Delete Source IP Address . . . . . . 15
3.3.4 Error Cause: Association Aborted due to illegal 3.3.4 Error Cause: Association Aborted due to illegal
ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . . . . 16 ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.5 Error Cause: Request refused - no authorization. . . . . . . 16 3.3.5 Error Cause: Request refused - no authorization. . . . . . . 16
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . . 17 4.1 ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . . 17
4.1.1 Congestion Control of ASCONF Chunks . . . . . . . . . . . . 18 4.1.1 Congestion Control of ASCONF Chunks . . . . . . . . . . . . 18
4.2 Upon reception of an ASCONF Chunk. . . . . . . . . . . . . . 19 4.2 Upon reception of an ASCONF Chunk. . . . . . . . . . . . . . 19
4.3 General rules for address manipulation . . . . . . . . . . . 21 4.3 General rules for address manipulation . . . . . . . . . . . 21
4.3.1 A special case for OOTB ABORT chunks . . . . . . . . . . . . 25 4.3.1 A special case for OOTB ABORT chunks . . . . . . . . . . . . 25
4.3.2 A special case for changing an address. . . . . . . . . . . 25 4.3.2 A special case for changing an address. . . . . . . . . . . 25
4.4 Setting of the primary address . . . . . . . . . . . . . . . 26 4.4 Setting of the primary address . . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . 27
6. IANA considerations . . . . . . . . . . . . . . . . . . . . 28 6. IANA considerations . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29
References . . . . . . . . . . . . . . . . . . . . . . . . . 30 References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
A. Abstract Address Handling . . . . . . . . . . . . . . . . . 32 A. Abstract Address Handling . . . . . . . . . . . . . . . . . 33
A.1 General remarks . . . . . . . . . . . . . . . . . . . . . . 32 A.1 General remarks . . . . . . . . . . . . . . . . . . . . . . 33
A.2 Generalized endpoints . . . . . . . . . . . . . . . . . . . 32 A.2 Generalized endpoints . . . . . . . . . . . . . . . . . . . 33
A.3 Associations . . . . . . . . . . . . . . . . . . . . . . . . 33 A.3 Associations . . . . . . . . . . . . . . . . . . . . . . . . 34
A.4 Relationship with RFC 2960 . . . . . . . . . . . . . . . . . 34 A.4 Relationship with RFC 2960 . . . . . . . . . . . . . . . . . 35
A.5 Rules for address manipulation . . . . . . . . . . . . . . . 34 A.5 Rules for address manipulation . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . 36
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: ability to:
1. reconfigure IP address information on an existing association. 1. reconfigure IP address information on an existing association.
2. set the remote primary path. 2. set the remote primary path.
3. exchange adaptation layer information during association setup. 3. exchange adaptation layer information during association setup.
These extensions enable SCTP to be utilized in the following These extensions enable SCTP to be utilized in the following
applications: applications:
1. For computational or networking platforms that allow addition/ 1. For computational or networking platforms that allow addition/
removal of physical interface cards this feature can provide a removal of physical interface cards this feature can provide a
graceful method to add to the interfaces of an existing graceful method to add to the interfaces of an existing
association. For IPv6 this feature allows renumbering of association. For IPv6 this feature allows renumbering of existing
existing associations. associations.
2. This provides a method for an endpoint to request that its peer 2. This provides a method for an endpoint to request that its peer
set its primary destination address. This can be useful when an set its primary destination address. This can be useful when an
address is about to be deleted, or when an endpoint has some address is about to be deleted, or when an endpoint has some
predetermined knowledge about which is the preferred address to predetermined knowledge about which is the preferred address to
receive SCTP packets upon. receive SCTP packets upon.
3. This feature can be used to extend the usability of SCTP without 3. This feature can be used to extend the usability of SCTP without
modifying it by allowing endpoints to exchange some information modifying it by allowing endpoints to exchange some information
during association setup. during association setup.
skipping to change at page 5, line 36 skipping to change at page 5, line 36
Chunk Type Chunk Name Chunk Type Chunk Name
-------------------------------------------------------------- --------------------------------------------------------------
0xC1 Address Configuration Change Chunk (ASCONF) 0xC1 Address Configuration Change Chunk (ASCONF)
0x80 Address Configuration Acknowledgment (ASCONF-ACK) 0x80 Address Configuration Acknowledgment (ASCONF-ACK)
Table 1: Address Configuration Chunks Table 1: Address Configuration Chunks
It should be noted that the ASCONF Chunk format requires the receiver It should be noted that the ASCONF Chunk format requires the receiver
to report to the sender if it does not understand the ASCONF Chunk. to report to the sender if it does not understand the ASCONF Chunk.
This is accomplished by setting the upper bits in the chunk type as This is accomplished by setting the upper bits in the chunk type as
described in RFC2960 [5] section 3.2. Note that the upper two bits described in RFC2960 [5] section 3.2. Note that the upper two bits in
in the ASCONF Chunk are set to one. As defined in RFC2960 [5] the ASCONF Chunk are set to one. As defined in RFC2960 [5] section
section 3.2, setting these upper bits in this manner will cause the 3.2, setting these upper bits in this manner will cause the receiver
receiver that does not understand this chunk to skip the chunk and that does not understand this chunk to skip the chunk and continue
continue processing, but report in an Operation Error Chunk using the processing, but report in an Operation Error Chunk using the
'Unrecognized Chunk Type' cause of error. 'Unrecognized Chunk Type' cause of error.
3.1.1 Address Configuration Change Chunk (ASCONF) 3.1.1 Address 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
Type-Length-Value (TLV), as described in "3.2.1 Optional/ Type-Length-Value (TLV), as described in "3.2.1 Optional/
Variable-length Parameter Format" in RFC2960 [5], forall variable Variable-length Parameter Format" in RFC2960 [5], forall variable
parameters. parameters.
skipping to change at page 6, line 25 skipping to change at page 6, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ .... / / .... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #N | | ASCONF Parameter #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serial Number : 32 bits (unsigned integer) Serial Number : 32 bits (unsigned integer)
This value represents a Serial Number for the ASCONF Chunk. The This value represents a Serial Number for the ASCONF Chunk. The valid
valid range of Serial Number is from 0 to 4294967295 (2**32 - 1). range of Serial Number is from 0 to 4294967295 (2**32 - 1). Serial
Serial Numbers wrap back to 0 after reaching 4294967295. Numbers wrap back to 0 after reaching 4294967295.
Address Parameter : 8 or 20 bytes (depending on type) Address Parameter : 8 or 20 bytes (depending on type)
This field contains an address parameter, either IPv6 or IPv4, from This field contains an address parameter, either IPv6 or IPv4, from
RFC2960 [5]. The address is an address of the sender of the ASCONF RFC2960 [5]. The address is an address of the sender of the ASCONF
chunk, the address MUST be considered part of the association by the chunk, the address MUST be considered part of the association by the
peer endpoint (the receiver of the ASCONF chunk). This field may be peer endpoint (the receiver of the ASCONF chunk). This field may be
used by the receiver of the ASCONF to help in finding the used by the receiver of the ASCONF to help in finding the
association. This parameter MUST be present in every ASCONF message association. This parameter MUST be present in every ASCONF message
i.e. it is a mandatory TLV parameter. i.e. it is a mandatory TLV parameter.
skipping to change at page 7, line 43 skipping to change at page 7, line 43
an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length
(set to 8) and the Serial Number. (set to 8) and the Serial Number.
3.2 New Parameter Types 3.2 New Parameter Types
The six new parameters added follow the format defined in section The six new parameters added follow the format defined in section
3.2.1 of RFC2960 [5]. Table 2 and 3 describes the parameters. 3.2.1 of RFC2960 [5]. Table 2 and 3 describes the parameters.
Address Configuration Parameters Parameter Type Address Configuration Parameters Parameter Type
------------------------------------------------- -------------------------------------------------
Set Primary Address 0xC004
Adaption Layer Indication 0xC006
Table 2: Parameters that can be used in INIT/INIT-ACK chunk
Address Configuration Parameters Parameter Type
-------------------------------------------------
Add IP Address 0xC001 Add IP Address 0xC001
Delete IP Address 0xC002 Delete IP Address 0xC002
Set Primary Address 0xC004 Set Primary Address 0xC004
Adaption Layer Indication 0xC006
Table 2: Parameters used in ASCONF Parameter Table 2: Parameters used in ASCONF Parameter
Address Configuration Parameters Parameter Type Address Configuration Parameters Parameter Type
------------------------------------------------- -------------------------------------------------
Error Cause Indication 0xC003 Error Cause Indication 0xC003
Success Indication 0xC005 Success Indication 0xC005
Table 3: Parameters used in ASCONF Parameter Response Table 3: Parameters used in ASCONF Parameter Response
3.2.1 Add IP Address 3.2.1 Add IP Address
0 1 2 3 0 1 2 3
skipping to change at page 8, line 26 skipping to change at page 8, line 30
| Type = 0xC001 | Length = Variable | | Type = 0xC001 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID | | ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Request Correlation ID: 32 bits ASCONF-Request Correlation ID: 32 bits
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. It is in host byte order and is only meaningful request parameter. It is in host byte order and is only meaningful to
to the sender. The receiver of the ASCONF Chunk will copy this 32 the sender. The receiver of the ASCONF Chunk will copy this 32 bit
bit value into the ASCONF Response Correlation ID field of the value into the ASCONF Response Correlation ID field of the ASCONF-ACK
ASCONF-ACK response parameter. The sender of the ASCONF can use this response parameter. The sender of the ASCONF can use this same value
same value in the ASCONF-ACK to find which request the response is in the ASCONF-ACK to find which request the response is for.
for.
Address Parameter: TLV Address Parameter: TLV
This field contains an IPv4 or IPv6 address parameter as described in This field contains an IPv4 or IPv6 address parameter as described in
3.3.2.1 of RFC2960 [5]. The complete TLV is wrapped within this 3.3.2.1 of RFC2960 [5]. The complete TLV is wrapped within this
parameter. It informs the receiver that the address specified is to parameter. It informs the receiver that the address specified is to
be added to the existing association. be added to the existing association.
An example TLV requesting that the IPv4 address 10.1.1.1 be added to An example TLV requesting that the IPv4 address 10.1.1.1 be added to
the association would look as follows: the association would look as follows:
skipping to change at page 9, line 35 skipping to change at page 9, line 31
| Type =0xC002 | Length = Variable | | Type =0xC002 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID | | ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Request Correlation ID: 32 bits ASCONF-Request Correlation ID: 32 bits
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. It is in host byte order and is only meaningful request parameter. It is in host byte order and is only meaningful to
to the sender. The receiver of the ASCONF Chunk will copy this 32 the sender. The receiver of the ASCONF Chunk will copy this 32 bit
bit value into the ASCONF Response Correlation ID field of the value into the ASCONF Response Correlation ID field of the ASCONF-ACK
ASCONF-ACK response parameter. The sender of the ASCONF can use this response parameter. The sender of the ASCONF can use this same value
same value in the ASCONF-ACK to find which request the response is in the ASCONF-ACK to find which request the response is for.
for.
Address Parameter: TLV Address Parameter: TLV
This field contains an IPv4 or IPv6 address parameter as described in This field contains an IPv4 or IPv6 address parameter as described in
3.3.2.1 of RFC2960 [5]. The complete TLV is wrapped within this 3.3.2.1 of RFC2960 [5]. The complete TLV is wrapped within this
parameter. It informs the receiver that the address specified is to parameter. It informs the receiver that the address specified is to
be removed from the existing association. be removed from the existing association.
An example TLV deleting the IPv4 address 10.1.1.1 from an existing An example TLV deleting the IPv4 address 10.1.1.1 from an existing
association would look as follows: association would look as follows:
skipping to change at page 10, line 35 skipping to change at page 10, line 29
| Type = 0xC003 | Length = Variable | | Type = 0xC003 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Response Correlation ID | | ASCONF-Response Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Cause(s) or Return Info on Success | | Error Cause(s) or Return Info on Success |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Response Correlation ID: 32 bits ASCONF-Response Correlation ID: 32 bits
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. The receiver of the ASCONF Chunk will copy this request parameter. The receiver of the ASCONF Chunk will copy this 32
32 bit value from the ASCONF-Request Correlation ID into the ASCONF bit value from the ASCONF-Request Correlation ID into the ASCONF
Response Correlation ID field so the peer can easily correlate the Response Correlation ID field so the peer can easily correlate the
request to this response. request to this response.
Error Cause(s): TLV(s) Error Cause(s): TLV(s)
When reporting an error this response parameter is used to wrap one When reporting an error this response parameter is used to wrap one
or more standard error causes normally found within an SCTP or more standard error causes normally found within an SCTP
Operational Error or SCTP Abort (as defined in RFC2960 [5]). The Operational Error or SCTP Abort (as defined in RFC2960 [5]). The
Error Cause(s) follow the format defined in section 3.3.10 of RFC2960 Error Cause(s) follow the format defined in section 3.3.10 of RFC2960
[5]. [5].
skipping to change at page 11, line 20 skipping to change at page 11, line 14
| Type =0xC004 | Length = Variable | | Type =0xC004 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID | | ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Request Correlation ID: 32 bits ASCONF-Request Correlation ID: 32 bits
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. It is in host byte order and is only meaningful request parameter. It is in host byte order and is only meaningful to
to the sender. The receiver of the ASCONF Chunk will copy this 32 the sender. The receiver of the ASCONF Chunk will copy this 32 bit
bit value into the ASCONF Response Correlation ID field of the value into the ASCONF Response Correlation ID field of the ASCONF-ACK
ASCONF-ACK response parameter. The sender of the ASCONF can use this response parameter. The sender of the ASCONF can use this same value
same value in the ASCONF-ACK to find which request the response is in the ASCONF-ACK to find which request the response is for.
for.
Address Parameter: TLV Address Parameter: TLV
This field contains an IPv4 or IPv6 address parameter as described in This field contains an IPv4 or IPv6 address parameter as described in
3.3.2.1 of RFC2960 [5]. The complete TLV is wrapped within this 3.3.2.1 of RFC2960 [5]. The complete TLV is wrapped within this
parameter. It requests the receiver to mark the specified address as parameter. It requests the receiver to mark the specified address as
the primary address to send data to (see section 5.1.2 of RFC2960 the primary address to send data to (see section 5.1.2 of RFC2960
[5]). The receiver MAY mark this as its primary upon receiving this [5]). The receiver MAY mark this as its primary upon receiving this
request. request.
skipping to change at page 11, line 52 skipping to change at page 11, line 45
| C-ID = 0x01023479 | | C-ID = 0x01023479 |
+--------------------------------+ +--------------------------------+
| Type=5 | Length = 8 | | Type=5 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0a010101 | | Value=0x0a010101 |
+----------------+---------------+ +----------------+---------------+
Valid Chunk Appearance Valid Chunk Appearance
The Set Primary IP Address parameter may appear in the ASCONF Chunk, The Set Primary IP Address parameter may appear in the ASCONF Chunk,
the INIT, or the INIT-ACK chunk type. The inclusion of this the INIT, or the INIT-ACK chunk type. The inclusion of this parameter
parameter in the INIT or INIT-ACK can be used to indicate an initial in the INIT or INIT-ACK can be used to indicate an initial preference
preference of primary address. of primary address.
3.2.5 Success Indication 3.2.5 Success Indication
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 = 0xC005 | Length = 8 | | Type = 0xC005 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Response Correlation ID | | ASCONF-Response Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 30 skipping to change at page 12, line 24
returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8) returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8)
and the Serial Number. and the Serial Number.
The responding endpoint MAY also choose to explicitly report a The responding endpoint MAY also choose to explicitly report a
success for a requested TLV, by returning a success report ASCONF success for a requested TLV, by returning a success report ASCONF
Parameter Response. Parameter Response.
ASCONF-Response Correlation ID: 32 bits ASCONF-Response Correlation ID: 32 bits
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. The receiver of the ASCONF Chunk will copy this request parameter. The receiver of the ASCONF Chunk will copy this 32
32 bit value from the ASCONF-Request Correlation ID into the ASCONF bit value from the ASCONF-Request Correlation ID into the ASCONF
Response Correlation ID field so the peer can easily correlate the Response Correlation ID field so the peer can easily correlate the
request to this response. request to this response.
Valid Chunk Appearance Valid Chunk Appearance
The Success Indication parameter may only appear in the ASCONF-ACK The Success Indication parameter may only appear in the ASCONF-ACK
chunk type. chunk type.
3.2.6 Adaptation Layer Indication 3.2.6 Adaptation Layer Indication
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 =0xC006 | Length = Variable | | Type =0xC006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaption Code point | | Adaption Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is specified for the communication of peer upper layer This parameter is specified for the communication of peer upper layer
protocols. It is envisioned to be used for flow control and other protocols. It is envisioned to be used for flow control and other
adaptation layers that require an indication to be carried in the adaptation layers that require an indication to be carried in the
INIT and INIT-ACK. Each adaptation layer that is defined that wishes INIT and INIT-ACK. Each adaptation layer that is defined that wishes
to use this parameter MUST specify a an adaption code point in an to use this parameter MUST specify a an adaption code point in an
appropriate RFC defining its use and meaning. This parameter SHOULD appropriate RFC defining its use and meaning. This parameter SHOULD
NOT be examined by the receiving SCTP implementation and should be NOT be examined by the receiving SCTP implementation and should be
passed opaquely to the upper layer protocol. passed opaquely to the upper layer protocol.
Valid Chunk Appearance Valid Chunk Appearance
The Adaptation Layer Indication parameter may appear in INIT or The Adaptation Layer Indication parameter may appear in INIT or
INIT-ACK chunk and SHOULD be passed to the receivers upper layer INIT-ACK chunk and SHOULD be passed to the receivers upper layer
protocol. protocol. This parameter MUST NOT appear in a ASCONF chunk.
3.3 New Error Causes 3.3 New Error Causes
Four new Error Causes are added to the SCTP Operational Errors, Five new Error Causes are added to the SCTP Operational Errors,
primarily for use in the ASCONF-ACK chunk. primarily for use in the ASCONF-ACK chunk.
Cause Code Cause Code
Value Cause Code Value Cause Code
--------- ---------------- --------- ----------------
0x0100 Request to Delete Last Remaining IP Address. 0x0100 Request to Delete Last Remaining IP Address.
0x0101 Operation Refused Due to Resource Shortage. 0x0101 Operation Refused Due to Resource Shortage.
0x0102 Request to Delete Source IP Address. 0x0102 Request to Delete Source IP Address.
0x0103 Association Aborted due to illegal ASCONF-ACK 0x0103 Association Aborted due to illegal ASCONF-ACK
0x0104 Request refused - no authorization. 0x0104 Request refused - no authorization.
skipping to change at page 14, line 4 skipping to change at page 13, line 44
rejected. rejected.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x0100 | Cause Length=Variable | | Cause Code=0x0100 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF / \ TLV-Copied-From-ASCONF /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An example of a failed delete in an Error Cause TLV would look as An example of a failed delete in an Error Cause TLV would look as
follows in the response ASCONF-ACK message: follows in the response ASCONF-ACK message:
+--------------------------------+ +--------------------------------+
| Type = 0xC003 | Length = 24 | | Type = 0xC003 | Length = 28 |
+----------------+---------------+
| C-ID = 0x01023476 |
+--------------------------------+ +--------------------------------+
| Cause=0x0100 | Length = 20 | | Cause=0x0100 | Length = 20 |
+----------------+---------------+ +----------------+---------------+
| Type= 0xC002 | Length = 16 | | Type= 0xC002 | Length = 16 |
+----------------+---------------+ +----------------+---------------+
| C-ID = 0x01023476 | | C-ID = 0x01023476 |
+--------------------------------+ +--------------------------------+
| Type=0x0005 | Length = 8 | | Type=0x0005 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0A010101 | | Value=0x0A010101 |
skipping to change at page 15, line 6 skipping to change at page 14, line 38
| Cause Code=0x0101 | Cause Length=Variable | | Cause Code=0x0101 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF / \ TLV-Copied-From-ASCONF /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An example of a failed addition in an Error Cause TLV would look as An example of a failed addition in an Error Cause TLV would look as
follows in the response ASCONF-ACK message: follows in the response ASCONF-ACK message:
+--------------------------------+ +--------------------------------+
| Type = 0xC003 | Length = 24 | | Type = 0xC003 | Length = 28 |
+--------------------------------+
| C-ID = 0x01023474 |
+--------------------------------+ +--------------------------------+
| Cause=0x0101 | Length = 20 | | Cause=0x0101 | Length = 20 |
+----------------+---------------+ +----------------+---------------+
| Type=0xC001 | Length = 16 | | Type=0xC001 | Length = 16 |
+--------------------------------+ +--------------------------------+
| C-ID = 0x01023474 | | C-ID = 0x01023474 |
+--------------------------------+ +--------------------------------+
| Type=0x0005 | Length = 8 | | Type=0x0005 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0A010101 | | Value=0x0A010101 |
+----------------+---------------+ +----------------+---------------+
3.3.3 Error Cause: Request to Delete Source IP Address 3.3.3 Error Cause: Request to Delete Source IP Address
Cause of error Cause of error
Request to Delete Source IP Address: The receiver of this error sent Request to Delete Source IP Address: The receiver of this error sent
a request to delete the source IP address of the ASCONF message. a request to delete the source IP address of the ASCONF message. This
This error indicates that the request is rejected. error indicates that the request is rejected.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x0102 | Cause Length=Variable | | Cause Code=0x0102 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF / \ TLV-Copied-From-ASCONF /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An example of a failed delete in an Error Cause TLV would look as An example of a failed delete in an Error Cause TLV would look as
follows in the response ASCONF-ACK message: follows in the response ASCONF-ACK message:
+--------------------------------+ +--------------------------------+
| Type = 0xC003 | Length = 24 | | Type = 0xC003 | Length = 28 |
+--------------------------------+
| C-ID = 0x01023476 |
+--------------------------------+ +--------------------------------+
| Cause=0x0102 | Length = 20 | | Cause=0x0102 | Length = 20 |
+----------------+---------------+ +----------------+---------------+
| Type=0xC002 | Length = 16 | | Type=0xC002 | Length = 16 |
+----------------+---------------+ +----------------+---------------+
| C-ID = 0x01023476 | | C-ID = 0x01023476 |
+--------------------------------+ +--------------------------------+
| Type=0x0005 | Length = 8 | | Type=0x0005 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0A010101 | | Value=0x0A010101 |
skipping to change at page 18, line 36 skipping to change at page 18, line 36
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 [5] section alternate destination address (please refer to RFC2960 [5] 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.
B5) Restart the T-4 RTO timer. Note that if a different destination B5) Restart the T-4 RTO timer. Note that if a different destination
is selected, then the RTO used will be that of the new destination is selected, then the RTO used will be that of the new destination
address. address.
Note: the total number of re-transmissions is limited by B2 above. Note: the total number of re-transmissions is limited by B2 above. If
If the maximum is reached, the association will fail and enter into the maximum is reached, the association will fail and enter into the
the CLOSED state (see RFC2960 [5] section 6.4.1 for details). CLOSED state (see RFC2960 [5] section 6.4.1 for details).
4.1.1 Congestion Control of ASCONF Chunks 4.1.1 Congestion Control of ASCONF Chunks
In defining the ASCONF Chunk transfer procedures, it is essential In defining the ASCONF Chunk transfer procedures, it is essential
that these transfers MUST NOT cause congestion within the network. that these transfers MUST NOT cause congestion within the network. To
To achieve this, we place these restrictions on the transfer of achieve this, we place these restrictions on the transfer of ASCONF
ASCONF Chunks: Chunks:
R1) One and only one ASCONF Chunk MAY be in transit and R1) One and only one ASCONF Chunk MAY be in transit and
unacknowledged at any one time. If a sender, after sending an unacknowledged at any one time. If a sender, after sending an
ASCONF chunk, decides it needs to transfer another ASCONF Chunk, ASCONF chunk, decides it needs to transfer another ASCONF Chunk,
it MUST wait until the ASCONF-ACK Chunk returns from the previous it MUST wait until the ASCONF-ACK Chunk returns from the previous
ASCONF Chunk before sending a subsequent ASCONF. Note this ASCONF Chunk before sending a subsequent ASCONF. Note this
restriction binds each side, so at any time two ASCONF may be restriction binds each side, so at any time two ASCONF may be
in-transit on any given association (one sent from each endpoint). in-transit on any given association (one sent from each endpoint).
R2) An ASCONF may be bundled with any other chunk type (except other R2) An ASCONF may be bundled with any other chunk type (except other
skipping to change at page 19, line 33 skipping to change at page 19, line 33
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 peer endpoint should also inform the upper layer application that the peer
endpoint does not support any of the extensions detailed in this 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.
When an endpoint receives an ASCONF Chunk from the remote peer When an endpoint receives an ASCONF Chunk from the remote peer
special procedures MAY be needed to identify the association the special procedures MAY be needed to identify the association the
ASCONF Chunk is associated with. To properly find the association ASCONF Chunk is associated with. To properly find the association the
the following procedures should be followed: following procedures should be followed:
L1) Use the source address and port number of the sender to attempt L1) Use the source address and port number of the sender to attempt
to identify the association (i.e. use the same method defined in to identify the association (i.e. use the same method defined in
RFC2960 [5] used for all other SCTP chunks). If found proceed to RFC2960 [5] used for all other SCTP chunks). If found proceed to
rule L4. rule L4.
L2) If the association is not found, use the address found in the L2) If the association is not found, use the address found in the
Address Parameter TLV combined with the port number found in the Address Parameter TLV combined with the port number found in the
SCTP common header. If found proceed to rule L4. SCTP common header. If found proceed to rule L4.
skipping to change at page 20, line 25 skipping to change at page 20, line 25
MUST be processed in order within the Chunk. For example, if MUST be processed in order within the Chunk. For example, if
the sender puts 3 TLVs in one chunk, the first TLV (the one the sender puts 3 TLVs in one chunk, the first TLV (the one
closest to the Chunk Header) in the Chunk MUST be processed closest to the Chunk Header) in the Chunk MUST be processed
first. The next TLV in the chunk (the middle one) MUST be first. The next TLV in the chunk (the middle one) MUST be
processed second and finally the last TLV in the Chunk MUST be processed second and finally the last TLV in the Chunk MUST be
processed last. processed last.
V2) In processing the chunk, the receiver should build a response V2) In processing the chunk, the receiver should build a response
message with the appropriate error TLVs, as specified in the message with the appropriate error TLVs, as specified in the
Parameter type bits for any ASCONF Parameter it does not Parameter type bits for any ASCONF Parameter it does not
understand. To indicate an unrecognized parameter, cause type understand. To indicate an unrecognized parameter, cause type 8
8 as defined in the ERROR in 3.3.10.8 of RFC2960 [5] should be as defined in the ERROR in 3.3.10.8 of RFC2960 [5] should be
used. The endpoint may also use the response to carry used. The endpoint may also use the response to carry
rejections for other reasons such as resource shortages etc, rejections for other reasons such as resource shortages etc,
using the Error Cause TLV and an appropriate error condition. using the Error Cause TLV and an appropriate error condition.
Note: a positive response is implied if no error is indicated Note: a positive response is implied if no error is indicated
by the sender. by the sender.
V3) All responses MUST copy the ASCONF-Request Correlation ID V3) All responses MUST copy the ASCONF-Request Correlation ID
field received in the ASCONF parameter, from the TLV being field received in the ASCONF parameter, from the TLV being
responded to, into the ASCONF-Request Correlation ID field in responded to, into the ASCONF-Request Correlation ID field in
skipping to change at page 22, line 6 skipping to change at page 22, line 6
C5) In both cases C2 and C3 the ASCONF-ACK MUST be sent back to the C5) In both cases C2 and C3 the ASCONF-ACK MUST be sent back to the
source address contained in the IP header of the ASCONF being source address contained in the IP header of the ASCONF being
responded to. responded to.
4.3 General rules for address manipulation 4.3 General rules for address manipulation
When building TLV parameters for the ASCONF Chunk that will add or When building TLV parameters for the ASCONF Chunk that will add or
delete IP addresses the following rules should be applied: delete IP addresses the following rules should be applied:
D0) If an endpoint receives an ASCONF-ACK that is greater than or D0) If an endpoint receives an ASCONF-ACK that is greater than or
equal to the next sequence number to be used but no ASCONF chunk equal to the next serial number to be used but no ASCONF chunk is
is outstanding the endpoint MUST ABORT the association. Note that outstanding the endpoint MUST ABORT the association. Note that a
a sequence number is greater than if it is no more than 2^^31-1 sequence number is greater than if it is no more than 2^^31-1
larger than the current sequence number (using serial arithmetic). larger than the current sequence number (using serial arithmetic).
D1) When adding an IP address to an association, the IP address is D1) When adding an IP address to an association, the IP address is
NOT considered fully added to the association until the ASCONF-ACK NOT considered fully added to the association until the ASCONF-ACK
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 packet except on carrying an ASCONF as a source for ANY SCTP packet except on carrying an ASCONF
chunk. The receiver of the add IP address request may use the chunk. The receiver of the add IP address request may use the
address as a destination immediately. address as a destination immediately.
skipping to change at page 23, line 31 skipping to change at page 23, line 31
Delete Last Remaining IP Address' is sent). Delete Last Remaining IP Address' is sent).
D9) If an endpoint receives an ADD IP address request and does not D9) If an endpoint receives an ADD IP address request and does not
have the local resources to add this new address to the have the local resources to add this new address to the
association, it MUST return an Error Cause TLV set to the new association, it MUST return an Error Cause TLV set to the new
error code 'Operation Refused Due to Resource Shortage'. error code 'Operation Refused Due to Resource Shortage'.
D10) If an endpoint receives an 'Out of Resource' error in response D10) If an endpoint receives an 'Out of Resource' error in response
to its request to ADD an IP address to an association, it must to its request to ADD an IP address to an association, it must
either ABORT the association or not consider the address part of either ABORT the association or not consider the address part of
the association. In other words if the endpoint does not ABORT the association. In other words if the endpoint does not ABORT the
the association, it must consider the add attempt failed and NOT association, it must consider the add attempt failed and NOT use
use this address since its peer will treat SCTP packets destined this address since its peer will treat SCTP packets destined to
to the address as Out Of The Blue packets. the address as Out Of The Blue packets.
D11) When an endpoint receiving an ASCONF to add an IP address sends D11) When an endpoint receiving an ASCONF to add an IP address sends
an 'Out of Resource' in its response, it MUST also fail any an 'Out of Resource' in its response, it MUST also fail any
subsequent add or delete requests bundled in the ASCONF. The subsequent add or delete requests bundled in the ASCONF. The
receiver MUST NOT reject an ADD and then accept a subsequent receiver MUST NOT reject an ADD and then accept a subsequent
DELETE of an IP address in the same ASCONF Chunk. In other words, DELETE of an IP address in the same ASCONF Chunk. In other words,
once a receiver begins failing any ADD or DELETE request, it must once a receiver begins failing any ADD or DELETE request, it must
fail all subsequent ADD or DELETE requests contained in that fail all subsequent ADD or DELETE requests contained in that
single ASCONF. single ASCONF.
skipping to change at page 24, line 41 skipping to change at page 24, line 41
/------------New DATA: /------------New DATA:
/ Destination / Destination
/ IP:X / IP:X
ASCONF [DEL-IP:X]---------/----------------> ASCONF [DEL-IP:X]---------/---------------->
<-----------------/------------------ASCONF-ACK <-----------------/------------------ASCONF-ACK
/ /
/ /
<-------------/ <-------------/
In this example we see a DATA chunk destined to the IP:X (which is In this example we see a DATA chunk destined to the IP:X (which is
about to be deleted) arriving after the deletion is complete. For about to be deleted) arriving after the deletion is complete. For the
the ADD case an endpoint SHOULD consider the newly adding IP address ADD case an endpoint SHOULD consider the newly adding IP address
valid for the association to receive data from during the interval valid for the association to receive data from during the interval
when awaiting the ASCONF-ACK. The endpoint MUST NOT source data from when awaiting the ASCONF-ACK. The endpoint MUST NOT source data from
this new address until the ASCONF-ACK arrives but it may receive out this new address until the ASCONF-ACK arrives but it may receive out
of order data as illustrated and MUST NOT treat this data as an OOTB of order data as illustrated and MUST NOT treat this data as an OOTB
datagram (please see RFC2960 [5] section 8.4). It MAY drop the data datagram (please see RFC2960 [5] section 8.4). It MAY drop the data
silently or it MAY consider it part of the association but it MUST silently or it MAY consider it part of the association but it MUST
NOT respond with an ABORT. NOT respond with an ABORT.
For the DELETE case, an endpoint MAY respond to the late arriving For the DELETE case, an endpoint MAY respond to the late arriving
DATA packet as an OOTB datagram or it MAY hold the deleting IP DATA packet as an OOTB datagram or it MAY hold the deleting IP
address for a small period of time as still valid. If it treats the address for a small period of time as still valid. If it treats the
DATA packet as an OOTB the peer will silently discard the ABORT DATA packet as an OOTB the peer will silently discard the ABORT
(since by the time the ABORT is sent the peer will have removed the (since by the time the ABORT is sent the peer will have removed the
IP address from this association). If the endpoint elects to hold IP address from this association). If the endpoint elects to hold the
the IP address valid for a period of time, it MUST NOT hold it valid IP address valid for a period of time, it MUST NOT hold it valid
longer than 2 RTO intervals for the destination being removed. longer than 2 RTO intervals for the destination being removed.
4.3.1 A special case for OOTB ABORT chunks 4.3.1 A special case for OOTB ABORT chunks
Another case worth mentioning is illustrated below: Another case worth mentioning is illustrated below:
Endpoint-A Endpoint-Z Endpoint-A Endpoint-Z
---------- ---------- ---------- ----------
New DATA:------------\ New DATA:------------\
skipping to change at page 25, line 43 skipping to change at page 25, line 43
For this case, during the deletion of an IP address, an Abort MUST be For this case, during the deletion of an IP address, an Abort MUST be
ignored if the destination address of the Abort message is that of a ignored if the destination address of the Abort message is that of a
destination being deleted. destination being deleted.
4.3.2 A special case for changing an address. 4.3.2 A special case for changing an address.
In some instances the sender may only have one IP address in an In some instances the sender may only have one IP address in an
association that is being renumbered. When this occurs, the sender association that is being renumbered. When this occurs, the sender
may not be able to send to the peer the appropriate ADD/DELETE pair may not be able to send to the peer the appropriate ADD/DELETE pair
and use the old address as a source in the IP header. For this and use the old address as a source in the IP header. For this reason
reason the sender MUST fill in the Address Parameter field with an the sender MUST fill in the Address Parameter field with an address
address that is part of the association (in this case the one being that is part of the association (in this case the one being deleted).
deleted). This will allow the receiver to locate the association This will allow the receiver to locate the association without using
without using the source address found in the IP header. the source address found in the IP header.
The receiver of such a chunk MUST always first use the source address The receiver of such a chunk MUST always first use the source address
found in the IP header in looking up the association. The receiver found in the IP header in looking up the association. The receiver
should attempt to use the address found in the Address Bytes field should attempt to use the address found in the Address Bytes field
only if the lookup fails using the source address from the IP header. only if the lookup fails using the source address from the IP header.
The receiver MUST reply to the source address of the packet in this The receiver MUST reply to the source address of the packet in this
case which is the new address that was added by the ASCONF (since the case which is the new address that was added by the ASCONF (since the
old address is no longer a part of the association after processing). old address is no longer a part of the association after processing).
4.4 Setting of the primary address 4.4 Setting of the primary address
skipping to change at page 31, line 14 skipping to change at page 31, line 14
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Phone: +1-847-632-3028 Phone: +1-847-632-3028
EMail: qxie1@email.mot.com EMail: qxie1@email.mot.com
Michael Tuexen Michael Tuexen
Univ. of Applied Sciences Muenster
Stegerwaldstr. 39
48565 Steinfurt
Germany Germany
Phone: EMail: tuexen@fh-muenster.de
EMail: tuexen@fr-muenster.de
Ian Rytina Ian Rytina
Ericsson Ericsson
37/360 Elizabeth Street 37/360 Elizabeth Street
Melbourne Victoria Melbourne Victoria
Australia Australia
Phone: +61-3-9301-6164 Phone: +61-3-9301-6164
EMail: ian.rytina@ericsson.com EMail: ian.rytina@ericsson.com
skipping to change at page 33, line 8 skipping to change at page 34, line 8
There is one fundamental rule which restricts all generalized There is one fundamental rule which restricts all generalized
endpoints: endpoints:
For two different generalized endpoints gE' and gE'' with the same For two different generalized endpoints gE' and gE'' with the same
port number Port(gE') = Port(gE'') the address sets Addr(gE')(t) and port number Port(gE') = Port(gE'') the address sets Addr(gE')(t) and
Addr(gE'')(t) must be disjoint at every point of time. Addr(gE'')(t) must be disjoint at every point of time.
A.3 Associations A.3 Associations
Associations consists of two generalized endpoints and the two Associations consists of two generalized endpoints and the two
address sets known by the peer at any time. The precise definition address sets known by the peer at any time. The precise definition is
is as follows: as follows:
An association A between to different generalized endpoints gE' and An association A between to different generalized endpoints gE' and
gE'' is given by gE'' is given by
A = (gE', S', gE'', S'') A = (gE', S', gE'', S'')
where S'(t) and S''(t) are set of addresses at any time t such that where S'(t) and S''(t) are set of addresses at any time t such that
S'(t) is a non-empty subset of Addr(gE')(t) and S''(t) is a non-empty S'(t) is a non-empty subset of Addr(gE')(t) and S''(t) is a non-empty
subset of Addr(gE'')(t). subset of Addr(gE'')(t).
skipping to change at page 34, line 34 skipping to change at page 35, line 34
A.5 Rules for address manipulation A.5 Rules for address manipulation
The rules for address manipulation can now be stated in a simple way: The rules for address manipulation can now be stated in a simple way:
1. An address can be added to a generalized endpoint gE only if this 1. An address can be added to a generalized endpoint gE only if this
address is not an address of a different generalized endpoint address is not an address of a different generalized endpoint
with the same port number. with the same port number.
2. An address can be added to an association A with generalized 2. An address can be added to an association A with generalized
endpoint gE if it has been added to the generalized endpoint gE endpoint gE if it has been added to the generalized endpoint gE
first. This means that the address must be an element of first. This means that the address must be an element of Addr(gE)
Addr(gE) first and then it can become an element of Addr(A, gE). first and then it can become an element of Addr(A, gE). But this
But this is not necessary. If the association does not allow the is not necessary. If the association does not allow the
reconfiguration of the addresses only Addr(gE) can be modified. reconfiguration of the addresses only Addr(gE) can be modified.
3. An address can be deleted from an association A with generalized 3. An address can be deleted from an association A with generalized
endpoint gE as long as Addr(A, gE) stays non-empty. endpoint gE as long as Addr(A, gE) stays non-empty.
4. An address can be deleted from an generalized endpoint gE only if 4. An address can be deleted from an generalized endpoint gE only if
it has been removed from all associations having gE as a it has been removed from all associations having gE as a
generalized endpoint. generalized endpoint.
These rules simply make sure that the rules for the endpoints and These rules simply make sure that the rules for the endpoints and
 End of changes. 

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