[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                    R. R. Stewart
INTERNET-DRAFT                                           Cisco Systems
                                                                Q. Xie
                                                              Motorola
                                                             M. Tuexen
                                                            Siemens AG
                                                             I. Rytina
                                                              Ericsson

expires in six months                                February 23, 2001


         Generic Method for Transmitting Reliable SCTP Control Chunks
                   <draft-ietf-sigtran-relreq-sctp-01.txt>

    Status of This Memo

    This document is an Internet-Draft and is in full conformance with all
    provisions of Section 10 of RFC 2026 [RFC2026]. 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.

    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.

    Abstract

    This document describes an extension to the Stream Control
    Transmission Protocol (SCTP) [RFC2960] to provide a generic method
    for transmitting a reliable control chunk. This provides a framework
    whereby future applications which require a specific SCTP control
    chunk(s) to be sent reliably can use this extension to provide the
    required functionality.

                        TABLE OF CONTENTS
    1. Introduction............................................... 2
    2. Conventions................................................ 2
    3. Chunk and Parameter Format................................. 2
    3.1 New Chunk Types........................................... 2
    3.1.1  Reliable Request Chunk (REL-REQ)....................... 2
    3.1.2 Reliable Request Acknowledgement (REL-ACK).............. 4
    4. Procedures................................................. 5
    4.1 Reliable Chunk Procedures................................. 6
    4.1.1 Congestion Control of Reliable Chunks................... 7
    4.2 Upon reception of a REL-REQ Chunk......................... 7
    5. Security Considerations.................................... 9
    6. IANA considerations........................................ 9
    7. Authors' Addresses.........................................10
    8. References.................................................10

    1. Introduction

Stewart et.al                                                   [Page 1]


Internet draft Generic Reliable Request Mechanism for SCTP February 2001


    Taking advantage of the extensibility of SCTP, this document adds a
    standard method to SCTP to send and receive reliable control
    information. This method is designed to be friendly to the TCP type
    congestion control within the the network. The following are some of
    the deemed advantages to this extension:

    A) An uniform method for adding control information that must be
        sent reliably.

    B) The reliable transfer extension is designed NOT to interfere with
        the currently defined congestion control mechanisms within SCTP
        and the network. This is accomplished by limiting when and how
        often a reliable control chunk may be sent.

    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
    RFC 2119 [RFC2119].

    3. Chunk and Parameter Formats

    This section specifies the two chunks that are used by the reliable
    control chunk transfer. Each new chunk is detailed and described.

    3.1 New Chunk Types

    This section defines the two new Chunk types that will be used to
    transfer reliable control information. Table 1 illustrates the two
    new chunk types.

    Chunk Type    Chunk Name
    --------------------------------------------------------------
    11000001      Reliable Request Chunk                 (REL-REQ)
    11000010      Reliable Request Acknowledgement Chunk (REL-ACK)

                  Table 1 - New Chunk types

    It should be noted that the two reliable Chunk formats also call for
    the receiver to report to the sender if it does not understand
    either of the new chunk formats. This is accomplished by setting the
    upper bit in the Chunk type as described in [RFC2960] section
    3.2. The upper two bits in both chunk types are set to one.  As
    defined in [RFC2960] section 3.2, these upper bits set in this
    manner will cause the receiver that does not understand these chunks
    to skip these chunks and continue processing, but report in an
    Operation Error Chunk using the 'Unrecognized Chunk Type' cause of
    error.

    3.1.1  Reliable Request Chunk (REL-REQ)

    This chunk is used to communicate to the remote endpoint reliable

Stewart et.al                                                   [Page 2]


Internet draft Generic Reliable Request Mechanism for SCTP February 2001

    information that must be acknowledged. The information that is being
    transfered reliably is always in the form of a Tag-Length-Value
    (TLV) as described in "3.2.1 Optional/Variable-length Parameter
    Format" in [RFC2960].

     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 = 0xC1   |  Chunk Flags  |      Chunk Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Serial Number                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Rel-Request Correlation ID #1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     REL-REQ Parameter #1                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                             ....                              /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Rel-Request Correlation ID #N                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     REL-REQ Parameter #N                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Serial Number : 32 bits (unsigned integer)

    This value represents a Serial Number for the Reliable Chunk. The
    valid range of Serial Number is from 0 to 4294967295 (2**32 - 1).
    Serial Numbers wrap back to 0 after reaching 4294967295.

    Rel-Request Correlation ID: 32 bits (unsigned integer)

    This is an opaque integer assigned by the sender to identify each
    request parameter. It is in host byte order and is only meaningful
    to the sender. The receiver of the REL-REQ will copy this 32 bit
    value into the Rel-Request Correlation ID field of the REL-AC. The
    sender of the REL-REQ can use this same value in the REL-ACK to find
    which request the response is for.

    REL-REQ Parameter: TLV format

    Each piece of information that the sending endpoint wishes to
    communicate reliably is incorporated in a TLV format. Multiple
    REL-REQ Parameters may be included in a REL-REQ.

    The REL-REQ Parameter Types are encoded such that the highest-order
    two bits specify the action that must be taken if the processing
    endpoint does not recognize the REL-REQ Parameter Type.

    00 - Reserved (Not Allowed).

    01 - Stop processing this SCTP packet and discard it, do not process
        any further chunks within it, and report the 'Unrecognized

Stewart et.al                                                   [Page 3]


Internet draft Generic Reliable Request Mechanism for SCTP February 2001

        Parameter Type' (in an Error cause placed within the
        REL-ACK chunk).

    10 - Reserved (Not Allowed).

    11 - Skip this REL-REQ parameter and continue processing but report
        the unrecongized parameter in an 'Unrecognized Parameter Type'
        (in an Error cause placed within the REL-ACK chunk).

    3.1.2 Reliable Request Acknowledgement Chunk (REL-ACK)

    This chunk is used by the receiver of a REL-REQ chunk to acknowledge
    its reception. It carries zero or more error causes for any REL-REQ
    Parameters that were not understood (based on the reporting bits as
    defined in 3.1.1 or refused by the receiver.

     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 = 0xC2   |  Chunk Flags  |      Chunk Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Serial Number                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Rel-Request Correlation ID #1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  REL-REQ Parameter Response #1                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                             ....                              /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Rel-Request Correlation ID #N                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  REL-REQ Parameter Response #N                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Serial Number : 32 bits (unsigned integer)

    This value represents the Serial Number for the Reliable Chunk that
    was received to which this Chunk is acknowledgment of. This value is
    copied from the received REL-REQ message.

    Rel-Request Correlation ID: 32 bits (unsigned integer)

    This value is copied from the REL-REQ Correlation ID received in the
    REL-REQ. It is used by the receiver of the REL-ACK to identify which
    REL-REQ parameter this response is associated with.

    REL-REQ Parameter Response : TLV format

    The REL-REQ Parameter Error or response is used in the REL-ACK to
    report errors. By default if a responder does not include a an Error
    cause, for any requested TLV, a success is indicated. Thus a sender
    of a REL-ACK MAY indicate complete success of all TLV's in a REL-REQ

Stewart et.al                                                   [Page 4]


Internet draft Generic Reliable Request Mechanism for SCTP February 2001

    by returning only the Chunk Type, Chunk Flags, Chunk Length (set to
    8) and the Serial Number.


    REL-REQ Parameter Error          Type Value
    -------------------------------------------------
    Error Cause TLV                  49157 (0xC005)
    Success report                   49158 (0xC008)

     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 = 49157 or 49158  |      Length = Variable        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Error Cause(s) or Return Info on Success          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    When reporting an error, the response parameter is used to "wrap"
    one or more standard error cause normally found within an SCTP
    Operational Error or SCTP Abort (as defined in [RFC2960]). The
    Error Cause(s) follow the format defined in section 3.3.10 of
    [RFC2960].

    New error causes may be defined according to the application which
    is using the reliable chunk transfer mechanism. These error causes
    would be primarily defined to be used as part of the REL-REQ
    Parameter Error in the REL-ACK (as outlined above), but may be also
    be used with an Operational Error or an Abort (as defined in
    [RFC2960]).

    By default if a responder does not report an error for any
    requested TLV, a success is implicitly indicated. Thus a sender of
    a REL-ACK MAY indicate complete success of all TLV's in a REL-REQ
    by returning only the Chunk Type, Chunk Flags, Chunk Length (set
    to 8) and the Serial Number.

    The responder MAY also choose to explicitly report a success
    for a requested TLV, by returning a success report REL-REQ
    Parameter Response, and MAY also attach a return value (in TLV
    format) to the success report. The return value TLVs may be
    defined according to the application which is using the reliable
    chunk transfer mechanism.


    4. Procedures

    This section will lay out the procedures for the reliable chunk
    transfer. Future SCTP extensions that wish to use the reliable chunk
    transfer MUST NOT change the procedures of the chunk transfer
    itself. Extensions SHOULD detail only procedures related to the
    REL-REQ Parameters being defined by them.

Stewart et.al                                                   [Page 5]


Internet draft Generic Reliable Request Mechanism for SCTP February 2001

    4.1 Reliable Chunk Procedures

    When an endpoint has reliable control information to be sent to the
    remote endpoint it should do the following:

    A1) Create a Reliable Request Chunk as defined in section 3.1.1. The
        chunk should contain all of the TLV('s) of information necessary
        to be sent to the remote endpoint, and unique correlation
        identities for each request.

    A2) A serial number should be assigned to the Chunk. The serial
        number should be a monotonically increasing number. All serial
        numbers are defined to be initialized at the start of the
        association to the same value as the Initial TSN.

    A3) If no REL-REQ chunk is outstanding (un-acknowledged) with the
        remote peer AND there is less than cwnd bytes of user data
        outstanding send the chunk.

    A4) Start a T-4 RTO timer, using the RTO value of the selected
        destination address (normally the primary path see [RFC2960]
        section 6.4 for details).

    A5) When the REL-ACK which acknowledges the serial number last sent
        arrives, stop the T-4 RTO timer and clear the appropriate
        association and destination error counters as defined in
        [RFC2960] section 8.1 and 8.2.

    A6) Process all of the TLV's within the REL-ACK to find out
        particular status information returned in the various requests
        that were sent. Use the Correlation IDs to correlate the request
        and the responses.

    A7) If an error response is received to a TLV whose parameter type
        begins 01, all TLVs with no response before the failed TLV are
        considered successful if not reported.  All TLVs after the failed
        response are considered unsuccessful.

    A8) If there are no responses to TLVs whose parameter type begins
        01, all TLVs not responded to are considered successful.

If the T-4 RTO timer expires the endpoint should do the following:

    B1) Increment the error counter and perform path failure detection
        on the appropriate destination address as defined in [RFC2960]
        section 8.2.

    B2) Increment the association error counter and perform endpoint
        failure detection on the association as defined in [RFC2960]
        section 8.1.

    B3) Retransmit the REL-REQ chunk last sent and if possible choose an
        alternate destination address (please refer to [RFC2960] section
        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
        REL-REQ sent.

Stewart et.al                                                   [Page 6]


Internet draft Generic Reliable Request Mechanism for SCTP February 2001


    B4) Restart the T-4 RTO timer.

    Note: That the the total number of retransmissions is limited by B2
    above. If the maximum is reached the association will fail and enter
    a CLOSED state (see [RFC2960] section 6.4.1 for details).

    4.1.1 Congestion Control of Reliable Chunks

    In defining the reliable chunk transfer procedures it is essential
    that these transfers MUST NOT cause congestion within the network.
    To achieve this we place these restrictions on the transfer of
    reliable chunks:

    R1) One and only one REL-REQ Chunk MAY be in flight and
        unacknowledged at any one time.  If a sender, after sending a
        reliable chunk, decides it needs to transfer another REL-REQ
        Chunk, it MUST wait until the REL-ACK Chunk returns from the
        previous Chunk before sending a subsequent REL-REQ. Note this
        restriction binds each side, so at any time two REL-REQ may be
        in-flight on any given association (one sent from each
        endpoint).

    R2) A REL-REQ MUST NOT be sent if there is no room in the current
        cwnd. If there is room in the cwnd of the destination network
        the Chunk may be sent regardless of the value of rwnd.

    R3) A REL-REQ MUST carry only information to be used by the peer
        SCTP Endpoint (not by the user application).

    R4) A REL-REQ may be bundled with any other Chunk type except other
        REL-REQ's.

    R5) A REL-ACK may be bundled with any other Chunk type except other
        REL-ACK's.

    R6) Both REL-ACK and REL-REQ chunks MUST NOT be sent in any SCTP
        state except ESTABLISHED.

    R7) A REL-REQ and respective REL-ACK MUST NOT be larger than the
        path MTU of the destination.

    4.2 Upon reception of a REL-REQ Chunk.

    When an endpoint receives a REL-REQ chunk from the remote peer it
        should perform the following:

    C1) Compare the value of the serial number to the value the endpoint
        stored in a new association variable 'Peer-Serial-Number'.  This
        value MUST be initialized to the Initial TSN value minus 1.

    C2) If the value found in the serial number is equal to the
        the ('Peer-Serial-Number' + 1), the endpoint should:


Stewart et.al                                                   [Page 7]


Internet draft Generic Reliable Request Mechanism for SCTP February 2001

        V1) Process the TLV's contained within the Chunk performing the
            appropriate actions as indicated by each TLV type.  The
            TLV's MUST be processed in order within the Chunk. In other
            words if the sender puts 3 TLV's in one chunk the first TLV
            (the one closest to the Chunk Header) in the Chunk MUST be
            processed first. The next TLV in the chunk (the middle one)
            would be processed second and finally the last TLV in the
            Chunk would be processed last.

        V2) In processing the chunk, the receiver should build a
            response message with the appropriate error TLV's, as
            specified in the REL-REQ Parameter type bits for any REL-REQ
            Parameter it does not understand.  To indicate an
            unrecognized parameter, parameter type 8 as defined in in
            the INIT-ACK in 3.3.3 of [RFC2960] should be used. It may
            also use the response to carry rejections for other reasons
            such as resource shortages etc using the Error Cause TLV and
            an appropriate error condition.

            Note: a postive response is implied if no error is indicated
            by the sender.

        V3) All error responses must copy the Rel-Request Correlation ID
            field received in the REL-REQ, from the TLV the TLV being
            responded to, into the Rel-Request Correlation ID field. The
            Rel-Request Correlation ID always preceeds the request TLV.

        V4) After processing the entire Chunk, it MUST send all TLV's
            for both unrecognized parameters and any other status TLV's
            inside the REL-ACK chunk that acknowledges the arrival and
            processing of the REL-REQ Chunk.

        V5) Update the 'Peer-Serial-Number' to the value found in the
            serial number field.

    C3) If the value found in the serial number is equal to
        the value stored in the 'Peer-Serial-Number', the endpoint
        should:

        X1) Parse the REL-REQ Chunk TLV's but the endpoint MUST not take
            any action on the TLV's parsed (since it has already
            performed these actions).

        X2) Build a response message with the appropriate response TLV's
            as specified in the REL-REQ Parameter type bits, for any
            parameter it does not understand or could not process.

        X3) After parsing the entire Chunk, it MUST send any response
            TLV errors and status with a REL-ACK chunk acknowledging the
            arrival and processing of the REL-REQ Chunk.

        X4) The endpoint MUST NOT update its 'Peer-Serial-Number'.

    IMPLEMENTATION NOTE: As an optimization a receiver is allowed to

Stewart et.al                                                   [Page 8]


Internet draft Generic Reliable Request Mechanism for SCTP February 2001

    save the last REL-ACK for some predetermined period of time and
    instead of re-processing the REL-REQ with the same serial number it
    may jut retransmit the REL-ACK. It may wish to use the arrival of a
    new serial number to discard the previously saved REL-ACK or any
    other means it may choose to expire the saved REL-ACK.

    C4) Otherwise, the REL-REQ chunk is discarded since it must be
        either a stale packet or from an attacker.

    C5) In both cases C2:V5 and C3:X3 the REL-ACK MUST be sent back to
        the source address contained in the IP header of the REL-REQ
        being responded to.

    5. Security Considerations

    The reliable chunk passing mechanism itself does not add any
    security considerations other than those addressed by the base level
    SCTP protocol. However each new extension MAY result in new security
    threats and each extension SHOULD make appropriate consideration of
    these threats.

    6. IANA considerations

    Two new SCTP Chunk types are being allocated for use by this feature.

    The assignment of new REL-REQ Parameter type codes is done through
    an IETF Consensus action as defined in [RFC2434]. Documentation of
    the new REL-REQ Parameter MUST contain the following information:

    a) Name of the REL-REQ Parameter type.

    b) Detailed description of the structure of the REL-REQ Parameter
        field. This structure MUST conform to the general
        type-length-value format described in Section 3.1.1.

    c) Detailed definition of each component of the REL-REQ Parameter
        value.

    d) Detailed description of the intended use of this REL-REQ
        Parameter type, and an indication of whether and under what
        circumstances multiple instances of this REL-REQ Parameter type
        may be found within the same Reliable Request chunk.

    The assignment of new error causes carried in the REL-ACK is
    outlined in [RFC2960] section 13.3.


Stewart et.al                                                   [Page 9]


Internet draft Generic Reliable Request Mechanism for SCTP February 2001

    7. Authors' Addresses

    Randall R. Stewart                      Tel: +1-815-477-2127
    Cisco Systems, Inc.                     EMail: rrs@cisco.com
    8745 W. Higgins Road, Suite 200
    Chicago, Ill  60631
    USA

    Qiaobing Xie                            Tel: +1-847-632-3028
    Motorola, Inc.                    EMail: qxie1@email.mot.com
    1501 W. Shure Drive, #2309
    Arlington Heights, IL 60004
    USA

    Michael Tuexen                          Tel: +49-89-722-47210
    SIEMENS AG               EMail: Michael.Tuexen@icn.siemens.de
    Hofmannstr. 51
    81359 Munich
    Germany

    Ian Rytina                              Tel: +61-3-9301-6164
    Ericsson Australia                      EMail:ian.rytina@ericsson.com
    37/360 Elizabeth Street
    Melbourne, Victoria 3000
    Australia


    8. References

    [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
        H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
        and, V. Paxson, "Stream Control Transmission Protocol," RFC
        2960, October 2000.

    [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
        3", RFC 2026, October 1996.

    [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.", RFC
        2402, November 1998.

    [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
        IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
        1998.



      This Internet Draft expires in 6 months from February, 2001



Stewart et.al                                                  [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/