One document matched: draft-stewart-sctpstrrst-00.txt
Network Working Group R. Stewart
Internet-Draft P. Lei
Expires: February 27, 2006 Cisco Systems, Inc.
M. Tuexen
Muenster Univ. of Applied Sciences
August 26, 2005
Stream Control Transmission Protocol (SCTP) Stream Reset
draft-stewart-sctpstrrst-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Many applications that desire to use SCTP have requested the ability
to "reset" a stream. The intention of resetting a stream is to start
the numbering sequence of the stream back at 'zero' with a
corresponding notification to the upper layer that this act as been
performed. The applications that have requested this feature
normally desire it so that they can "re-use" streams for different
Stewart, et al. Expires February 27, 2006 [Page 1]
Internet-Draft SCTP Stream Reset August 2005
purposes but still utilize the stream sequence number for the
application to track the message flows. Thus, without this feature,
a new use on an old stream would result in message numbers larger
than expected without a protocol mechanism to "start the streams back
at zero".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. STREAM RESET Chunk . . . . . . . . . . . . . . . . . . . . 3
3.2. New Parameters . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Stream Reset Request Parameter . . . . . . . . . . . . 4
3.2.2. Stream Reset Response Parameter . . . . . . . . . . . 5
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Sender side procedures for the Stream Reset Chunk . . . . 7
4.1.1. Sender side procedures for a user requested Stream
Reset Request Parameter . . . . . . . . . . . . . . . 7
4.1.2. Sender side procedures for a peer requested Stream
Reset Request Parameter . . . . . . . . . . . . . . . 8
4.1.3. Sender side procedures for the Stream Reset
Response Parameter . . . . . . . . . . . . . . . . . . 8
4.2. Receiver side procedures for the Stream Reset Chunk . . . 9
4.2.1. Receiver side procedures for the Stream Reset
Request Parameter . . . . . . . . . . . . . . . . . . 9
4.2.2. Receiver side procedures for the Stream Reset
Response Parameter . . . . . . . . . . . . . . . . . . 10
4.3. Various Examples of the Stream Reset procedures . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Iana Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Stewart, et al. Expires February 27, 2006 [Page 2]
Internet-Draft SCTP Stream Reset August 2005
1. Introduction
Many applications that desire to use RFC2960 [5] have requested the
ability to "reset" a stream. The intention of resetting a stream is
to start the numbering sequence of the stream back at 'zero' with a
corresponding notification to the upper layer that this act as been
performed. The applications that have requested this feature
normally desire it so that they can "re-use" streams for different
purposes but still utilize the stream sequence number for the
application to track the message flows. Thus, without this feature,
a new use on an old stream would result in message numbers larger
than expected without a protocol mechanism to "start the streams back
at zero".
[ Editors note: We probably need to add more text here ]
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
RFC2119 [4].
3. Data Formats
This section examines all new data formats defined by this document.
All transported integer numbers are in "network byte order" a.k.a.,
Big Endian, unless otherwise noted.
3.1. STREAM RESET Chunk
This document adds one new chunk type to SCTP. The suggested value
for this chunk is 0x82 hex or 130 decimal. The range selected by
IANA must have the upper bit (or ignore big) set and the next to
highest bit (or the report bit) cleared. The chunk has the following
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x82 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stewart, et al. Expires February 27, 2006 [Page 3]
Internet-Draft SCTP Stream Reset August 2005
Chunk Type This field holds the IANA defined chunk type for the
STREAM RESET chunk.
Chunk Flags This field is set to 0 by the sender and ignored by the
receiver.
Chunk Length This field holds the length of the chunk, including the
Chunk Type, Chunk Flags and Chunk Length.
Stream Reset Parameter This field holds exactly one and only one
Stream Reset Request Parameter or Stream Reset Response Parameter.
Note each STREAM RESET chunk holds one and only one parameter. A
STREAM RESET chunk MUST NOT have multiple parameters contained within
it. This rule is made to simplify stream reset processing. Note
also that a sender may only have two STREAM RESET chunks in flight at
any one single time. One being a STREAM RESET holding a request
parameter, and optionally a second being a STREAM RESET holding a
response parameter.
3.2. New Parameters
This section identifies two new parameters, their formats, and in
what chunk type these parameters may appear.
3.2.1. Stream Reset Request Parameter
This parameter is used by the sender to request a stream, a list of
streams or all streams to be reset.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x000d | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |R|Y| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number 1 (optional) | Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ...... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number N-1 (optional) | Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stewart, et al. Expires February 27, 2006 [Page 4]
Internet-Draft SCTP Stream Reset August 2005
Parameter Type - This field holds the IANA defined parameter type for
Stream Reset Request Parameter. The suggested value of this field
for IANA is 0x000d.
Parameter Length - This field holds the length of the parameter.
Y bit - The 'Y' Bit, when set to '1' indicates that the receiver is
requested to reset the stream sequence numbers it is sending. If
the 'Y' bit is '0' then this message requests no action on the
receivers sending stream sequence numbers.
R bit - The 'R' bit, if set to '1', requests that the receiver send a
stream reset request to the sender, asking to reset its sending
stream sequence numbers. If the 'R' bit is clear, then no
reciprocal reset request is asked for.
Stream Reset Sequence Number - This field(s) hold a 32 bit unsigned
integer. The value is a monotonically increasing number that is
initialized to the same value as the Initial TSN number.
Stream Number N - This optional field, if included, is used to
indicates specific streams that are to be reset. If no streams
are listed, then ALL streams are to be reset.
Parameter Appearance - This parameter can appear in a STREAM RESET
chunk. This parameter MUST NOT appear in any other chunk type.
Note also that only ONE Stream Reset Parameter SHOULD appear in
any single Stream Reset Chunk. However a sender MAY place a
'Stream Reset Parameter' and a 'Stream Reset Response Parameter'
in separate STREAM RESET chunks, bundled together in one packet.
3.2.2. Stream Reset Response Parameter
This parameter is used by the receiver of a stream reset request
parameter to respond to the stream reset request.
Stewart, et al. Expires February 27, 2006 [Page 5]
Internet-Draft SCTP Stream Reset August 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x000e | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |D|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Unassigned TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Acknowledgment Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number 1 (optional) | Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ...... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number N-1 (optional) | Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type - This field holds the IANA defined parameter type for
Stream Reset Response Parameter. The suggested value of this
field for IANA is 0x000e.
Parameter Type Length - This field holds the length of the parameter.
P bit - The 'P' Bit, when set to '1', indicates that the sender of
the stream reset request has performed the stream reset that was
requested.
D bit - The 'D' bit, if set to '1', indicates that the stream reset
that was requested is denied. - These two bits are mutually
exclusive. A response parameter MUST have only one of these two
bits set and MUST NOT have both of these two bits set. Note that
both bits MAY be set to 0.
Stream Reset Sequence Number This field(s) hold a 32 bit unsigned
integer. The value is copied from the Stream Reset Request
parameter and is used by the receiver to tie the request to the
response.
Next Unassigned TSN This value holds the NEXT TSN that the sender
will assign for a new data chunk. This value is sometimes called
SND.NXT.
Stewart, et al. Expires February 27, 2006 [Page 6]
Internet-Draft SCTP Stream Reset August 2005
Cumulative Acknowledgement Point This value holds the cumulative TSN
that the sender has acknowledged. In other words, this value is
the same one that will be placed in the next outgoing SACK.
Stream Number N These fields are filled with the stream numbers that
were RESET. If no stream numbers are listed ALL streams were
reset.
Parameter Appearance This parameter can appear in a STREAM RESET
chunk. This parameter MUST NOT appear in any other chunk type.
4. Procedures
This section defines the procedures used by both the sender and
receiver of a stream reset. We also give various example stream
reset scenarios.
4.1. Sender side procedures for the Stream Reset Chunk
This section describes the procedures related to the sending of
Stream Reset Chunks. A Stream Reset Chunk is a composition of a Tag
Length Value (TLV) parameters. A single Stream Reset Chunk normally
carries either a 'Stream Reset Request Parameter', or a 'Stream Reset
Response Parameter'.
4.1.1. Sender side procedures for a user requested Stream Reset Request
Parameter
On occasion an SCTP sender will request a reset for all of its
streams, a list of streams, or a single stream by its upper layer.
When such a request is made the SCTP sender MUST determine if the
request is:
A1) To be made to the local sender side streams (in other words, the
outgoing streams sequence numbers of the sender of this message).
In such a case the R bit MUST be set to '1' and the Y bit MUST be
set to '0' in the outgoing Stream Reset Request.
A2) To be made to the peer's sender side streams (i.e. the incoming
stream sequence numbers of the sender of this message). In such a
case the sender MUST set the R bit to '0' and set the Y bit to '1'
in the outgoing Stream Reset Request.
A3) To be made to both the local and the remote peer streams sequence
numbers. In such a case the sender MUST set the R bit AND the Y
bit to '1'.
Stewart, et al. Expires February 27, 2006 [Page 7]
Internet-Draft SCTP Stream Reset August 2005
Next the sender should assign the next stream reset sequence number.
After assigning the sequence number to the Stream Reset Request the
number MUST be incremented by '1'.
Finally if a list of streams is provided these should be appended to
the Stream Reset Request. Once the parameter is assembled it MUST be
placed inside a Stream Reset Chunk. One and only one Stream Reset
Request SHOULD be placed in a Stream Reset Chunk. A sender MUST NOT
place more than one Stream Reset Request Parameter into a Stream
Reset Chunk and a sender MUST NOT have more than one Stream Reset
Request outstanding at any one time. Note that if the sender has a
Stream Reset Response it MAY be included in a separate outgoing
Stream Reset Chunk.
After packaging the Stream Reset Chunk and sending it to the peer the
sender MUST start a 'Stream Reset Timer'. This timer MUST use the
same value as SCTP's Data transmission timer (i.e. the RTO timer) and
MUST use exponential backoff doubling the value at every expiration.
If the timer does expire, besides doubling the value, the sender MUST
retransmit the Stream Reset Chunk, increment the appropriate error
counts (both for the association and the destination), and do
threshold management possibly destroying the association if SCTP
retransmission thresholds are surpassed.
4.1.2. Sender side procedures for a peer requested Stream Reset Request
Parameter
When a Stream Reset Request Parameter arrives from a peer and has the
'R' bit set to 1, a automatic Stream Reset Request MUST be generated
if the response to the request will have the P bit set to 1. In such
a case the sender MUST compose the Stream Reset Request Parameter in
the following way:
B1) The R bit MUST be set to '0'.
B3) The Y bit MUST be set to '1'.
B4) The list of streams MUST be copied from the incoming Stream Reset
Request that is causing this request to be generated if one is
attached.
B5) An outgoing stream reset sequence number must be assigned using
the same method as described previously in Section 4.1.1.
4.1.3. Sender side procedures for the Stream Reset Response Parameter
When an implementation receives a Stream Reset Request it MUST
respond with a Stream Reset Response in the following manner:
Stewart, et al. Expires February 27, 2006 [Page 8]
Internet-Draft SCTP Stream Reset August 2005
C1) The implementation MUST set either the P bit or the D bit to '1'.
The P bit MUST only be set if the operation was performed. The D
bit MUST only be set if the operation is refused. If no operation
was requested (the Y bit was set to 0) then both the P and D bit
MUST be set to 0.
C2) If the P bit is set to 1 and the R bit was set on the incoming
request, a stream reset request must be generated as defined in
Section 4.1.2.
C3) The Stream Sequence number is copied from the Stream Sequence
field of the incoming request.
C4) The Next Unassigned TSN MUST be set to the next TSN that will be
assigned. Note this is NOT necessarily the next TSN that will be
transmitted.
C5) The Cumulative Acknowledgment Point MUST be set to the same value
that would be placed in any outgoing SACK.
C6) Any Stream Number's MUST be copied from the Stream Reset Request
Parameter to the outgoing Stream Reset Response.
[Editors note: The above may be redundant with the next section and
we may want to remove it, I am not sure and must reread this
carefully since it is tricky to get the synchronization right and
this may be why things appear to be double listed. ]
4.2. Receiver side procedures for the Stream Reset Chunk
Upon reception of a Stream Reset Chunk each parameter within it
should be processed as described in the following sections.
4.2.1. Receiver side procedures for the Stream Reset Request Parameter
When a Stream Reset Request arrives the receiver MUST always respond
with a stream reset response. Its response MUST either indicate that
the operation was performed with the P bit set to '1' and the D bit
set to '0', that the operation was denied with the D bit set to '1'
and the P bit set to '0', or that no operation was performed (The Y
bit in the request was '0') by setting the P and D bit to '0'.
The decision to deny a stream reset request is an administrative
decision and may be user configurable even after the association has
formed. If for whatever reason the endpoint does NOT wish to reset
any streams it MUST send a stream reset response as described in
Section 4.1.3 setting the D bit to '1' and take no further action.
Stewart, et al. Expires February 27, 2006 [Page 9]
Internet-Draft SCTP Stream Reset August 2005
In the case that the endpoint is willing to perform a stream reset
the following steps SHOULD be followed after sending a stream reset
response. Note that if the Y bit is set to '0' in the request then
the response SHOULD have both P and D bit set to '0'. If the Y bit
is set to '1' then the P bit MUST be set to '1'.
D1) If the R bit is set, a stream reset request MUST be formulated as
described in Section 4.1.2 and sent to the peer. This request
SHOULD be held and sent with the Stream Reset Response generated
by processing the incoming request.
D2) If the Y bit is set to 0 no action is performed on the local
streams and processing of this parameter is complete (no further
steps are taken).
D3) If no stream number are listed in the parameter, then all
outgoing streams MUST be reset to '0'. If specific stream number
are listed, then only these specific streams MUST be reset to '0'
and all other non-listed streams remain unchanged.
4.2.2. Receiver side procedures for the Stream Reset Response Parameter
On receipt of a Stream Reset Response Parameter the following MUST be
performed:
E1) Compare the Stream Reset Sequence Number to the sending stream
reset sequence number. If the sequence numbers DO NOT match
silently discard this response. If the sequence numbers DO match,
increment the sending stream reset sequence number by 1 and
continue processing this response with steps E2 - E4.
E2) Stop the Stream Reset Timer, if one is running.
E3) Examine the Next Unassigned TSN number. If the next unassigned
TSN number is one greater than the Cumulative Ack point that the
local endpoint is sending to the peer then all TSN's in flight are
accounted for. Perform the following steps:
E3.1) If no streams are listed in the incoming parameter then
reset all incoming stream sequence numbers to next expect
stream sequence '0'.
E3.2) If the specific streams are listed in the incoming parameter
then for each stream listed in the Stream Number fields, reset
the next expected incoming stream number to 0.
Stewart, et al. Expires February 27, 2006 [Page 10]
Internet-Draft SCTP Stream Reset August 2005
E3.3) Optionally an Upper Layer Notification SHOULD be sent to
inform the local endpoint that the streams have been reset.
E3.4) When all streams effected have been reset the processing for
this parameter is complete.
E4) If the Next Unassigned TSN number is greater than the cumulative
acknowledgment point by 1, then the endpoint must enter "deferred
reset processing". In this mode, any TSN number for the effected
streams MUST be queued locally and held until the Cumulative
Acknowledgment point reaches one less then the 'Next Unassigned
TSN number'. When the Cumulative Acknowledgment point reaches 1
less than the Next Unassigned TSN number then steps E3.1 - E3.3
MUST be followed. After which all queued chunks should be de-
queued and processed in the normal manner.
Note that the effect of deferred reset processing is that each
receiving side will synchronize its expected stream sequence numbers
at the precise time that the peer reset its sending sequence numbers.
This allows the receiver to always stay in correct sequence with its
peer's stream sequence numbers.
4.3. Various Examples of the Stream Reset procedures
The following examples illustrates an Endpoint A resetting all
streams in both directions.
E-A E-Z
-------[STR_RESET(REQ:Y=1,R=1)]------------------->
<---[STR_RESET (RESP:P=1,D=0)STR_RESET(REQ:Y=1,R=0)]-
-------[STR_RESET(RESP:P=1,D=0)]-------------------------->
The following example illustrates an Endpoint A resetting stream 1
and 2 for just its outgoing streams.
E-A E-Z
-------[STR_RESET(REQ:Y=0,R=1)1,2]------------------>
<-[STR_RESET({RESP:P=0,D=0}1,2)STR_RESET({REQ:Y=1,R=0}1,2)]--
------[STR_RESET(RESP:P=1,D=0)1,2]--------------------->
Stewart, et al. Expires February 27, 2006 [Page 11]
Internet-Draft SCTP Stream Reset August 2005
The following example illustrates an Endpoint A resetting stream 1
and 2 for just its incoming streams.
E-A E-Z
------[STR_RESET(REQ:Y=1,R=0)1,2]-------->
<-----[STR_RESET(RESP:P=1,D=0)1,2]-------
5. Security Considerations
Having the ability to reset a stream should not pose any additional
security risk to SCTP. An attacker that can successfully inject a
stream reset would also be able to inject data or other malicious
information into an association such as an ABORT.
6. Iana Considerations
This document defines one new chunk type and two new parameter types.
This document recommends the values of 0x82 for the chunk type and
0x000d and 0x000e for the new parameter types. However IANA may
assign any free chunk or parameter type as long it is from the same
chunk or parameter pool. In the case of the chunk, it MUST be from
the pool of chunks with the upper two bits set to '10'. In the case
of the parameters, it MUST be from the pool whose upper bits are set
to '00'.
7. Normative References
[1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996.
[2] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[3] Bradner, S., "IETF Rights in Contributions", RFC 3667,
February 2004.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
Stewart, et al. Expires February 27, 2006 [Page 12]
Internet-Draft SCTP Stream Reset August 2005
"Stream Control Transmission Protocol", RFC 2960, October 2000.
Stewart, et al. Expires February 27, 2006 [Page 13]
Internet-Draft SCTP Stream Reset August 2005
Authors' Addresses
Randall R. Stewart
Cisco Systems, Inc.
4875 Forest Drive
Suite 200
Columbia, SC 29206
USA
Phone:
Email: rrs@cisco.com
Peter Lei
Cisco Systems, Inc.
8735 West Higgins Road
Suite 300
Chicago, IL 60631
USA
Phone:
Email: peterlei@cisco.com
Michael Tuexen
Muenster Univ. of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany
Email: tuexen@fh-muenster.de
Stewart, et al. Expires February 27, 2006 [Page 14]
Internet-Draft SCTP Stream Reset August 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stewart, et al. Expires February 27, 2006 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 13:05:46 |