HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:07:43 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 02 Mar 1999 19:56:00 GMT ETag: "2e7ee9-84e9-36dc4250" Accept-Ranges: bytes Content-Length: 34025 Connection: close Content-Type: text/plain INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-reliable-01.txt Allan C. Rubens Date: February 1999 Ascend Communications DIAMETER Reliable Transport Extensions Status of this Memo This document is an individual contribution for consideration by the AAA Working Group of the Internet Engineering Task Force. Comments should be submitted to the diameter@ipass.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of 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. 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. Abstract Many services that require DIAMETER need retransmission and timeout faster than TCP can provide. An example would be in a NAS environment where DIAMETER is used for the authentication and authorization of users. The amount of time that it takes for TCP to determine that a connection to a server is Calhoun, Rubens expires August 1999 [Page 1] INTERNET DRAFT February 1999 broken is longer than the disonnect timeout of the PPP clients on whose behalf the server is being contacted. RADIUS has been able to handle this situation by operating over UDP. However, RADIUS fails to define a standard retransmission and timeout scheme, which has resulted in many different methods across implementations. This DIAMETER specification defines the extensions necessary for the base protocol to operate over a non-reliable transport (e.g. UDP). Calhoun, Rubens expires August 1999 [Page 2] INTERNET DRAFT February 1999 Table of Contents 1.0 Introduction 1.1 Definitions 2.0 Protocol Overview 2.1 Flow Control 2.2 Suggested implementation 2.3 Peer failure recovery 3.0 Extended Header Format 3.1 ZLB Message Format 4.0 DIAMETER AVPs 4.1 Receive-Window 5.0 References 6.0 Acknowledgements 7.0 Author's Address Appendix A: Acknowledgment Timeouts A.1 Calculating Adaptive Acknowledgment Timeout A.2 Flow Control: Adjusting for Timeout Appendix B: Examples of sequence numbering B.1 Lock-step tunnel establishment B.2 Multiple packets acknowledged B.3 Lost packet with retransmission 1.0 Introduction The extensions defined in this specification are mandatory for all DIAMETER extensions operating over a non-reliable transport (e.g. UDP). 1.1 Definitions In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. Calhoun, Rubens expires August 1999 [Page 3] INTERNET DRAFT February 1999 MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 2.0 Protocol Overview This section provides a detailed overview of how reliable transport can be optionally provided by DIAMETER. No negotiation mechanism for determining if this optional capability is required by either peer of a DIAMETER session is defined herein. The mechanism for deciding this is beyond the scope of this document. 2.1 Flow Control There are two different types of DIAMETER messages; A DIAMETER message that only contains the header and no Attribute-Value Pairs (AVPs) is known as a zero length body message (ZLB). ZLB messages are used for explicitly acknowledging packets to the peer, and contain no additional data. Two optional fields in the DIAMETER header that are important to the operation of DIAMETER when it is not being run over TCP are Nr (Next Received) Ns (Next Send). A single sequence number state is maintained for all DIAMETER messages to a given peer. The sequence number starts at 0. Each subsequent non-ZLB packet is sent with the next increment of the sequence number. The sequence number is thus a free running counter represented modulo 65536. For purposes of detecting duplication, a received sequence value is considered less than or equal to the last received value if its value lies in the range of the last value and its 32767 successor values. For example, if the last received sequence number was 15, then received packets with Ns values in the range ( 32783, ... 65535, 0, ... 15 ) would be considered duplicates and would be silently discarded. A packet with sequence number 16 would be treated as the next in-sequence packet and packets with other sequences numbers are out-of-order. It is an implementation decision as to whether DIAMETER Messages received out-of-order are queued for later processing or silently discarded. The former is recommended when possible. In this document, the sequence number state for each peer is represented for clarity of discussion by distinct pairs of state Calhoun, Rubens expires August 1999 [Page 4] INTERNET DRAFT February 1999 variables, Sr and Ss. Sr represents the value of the next in-sequence message expected to be received for a given session by a peer. Ss represents the sequence number to be placed in the Ns field of the next message sent to a given peer. Each state is initialized such that the first message sent and the first message expected to be received to/from each peer has an Ns value of 0. This corresponds to initializing Ss and Sr to 0 for each peer. As messages are sent to a given peer, Nr is set in these messages to reflect one more than the Ns value of the highest (modulo 2^16) in- order message received from that peer; if sent before any packet is received Nr will be 0, indicating that the peer expects the next new Ns value to be 0. When a non-ZLB message is received with an Ns value that matches the peer's current Sr value, Sr is incremented by 1 (modulo 2^16). It is important to note that Sr is not modified if a message is received with a value of Ns greater than the current Sr value. Retransmission of lost packets will eventually provide the receiving peer with its next expected message. Every time a peer sends a non-ZLB message it increments its Ss value for that peer by 1 (modulo 2^16). This increment takes place after the current Ss value is copied to Ns in the message to be sent. New outgoing messages normally include the current value of Sr for the corresponding peer in their Nr field. A peer may not wish to send the latest Sr value back to its peer due to congestion (i.e., its receive buffer for the session is full). In this case it is permissible for the peer to send back an Nr value containing the Ns value of the first message in the window. It is preferable to return an acknowledgment with this old Nr value rather than to withhold acknowledgments entirely when the receive window is full. Retransmitted messages should also include the current value of Sr in their Nr field, but some implementations may choose not to update Nr to avoid having to perform another hash in the Integrity-Check-Vector AVP. Note that the hash would only have to be recomputed if the Nr value had changed. This restriction does not apply to end-to-end integrity since the Ns and Nr fields are mutable. When retransmitting a message the identifier in the protocol header MUST NOT be changed. When transmitting packets, a DIAMETER peer must obey the receive window size offerred by its peer. The default window size is 7. A DIAMETER peer MUST NOT send new packets when its peer's window is closed (the number of packets unacknowledged is equal to the advertised, or assumed, window size). Previously transmitted packets may be retransmitted while the peer's window is closed. A peer communicating via UDP can specify the window size it is providing to Calhoun, Rubens expires August 1999 [Page 5] INTERNET DRAFT February 1999 its peer by specifying this value in the Device-Reboot-Ind message. A ZLB message is used to communicate Nr and Ns fields. The Nr and the Ns fields are filled in as above, but the sequence number state, Ss, is not modified. Thus a ZLB message sent after a non-ZLB message will contain the new Ss value while a non-ZLB message sent after a ZLB message will contain the same value of Ns as the ZLB message did. Upon receipt of an in-order non-ZLB message, the receiving peer must increment its Sr value and may acknowledge the message by sending back the updated value of Sr in the Nr field of the next outgoing message. This updated Sr value can be piggybacked in the Nr field of any outgoing messages that the peer may happen to send back. If a peer does not have a message queued to transmit at the time a non-ZLB message is received then it should delay a short time before sending a ZLB message containing the latest values of Sr and Ss, as described above. This short delay is to allow for the possible arrival of a message to be transmitted back to its peer, thus avoiding the need to issue a ZLB. The suggested value for this time delay is 1/4 the receiving peer's value of Round-Trip-Time (RTT - see Appendix A), if it computes RTT, or a maximum of 1/2 of its fixed acknowledgment timeout interval otherwise. This timeout should provide a reasonable opportunity for the receiving peer to obtain a payload message destined for its peer, upon which the ACK of the received message can be piggybacked. Note that if a peer's window is full, it MAY advertise an older Nr value if it is not ready to accept new messages. This delay value should be treated as a suggested maximum; an implementation could make this delay quite small without adversely affecting the protocol. The default time delay is 2 seconds. To provide for better throughput, the receiving peer should skip this delay entirely and send a ZLB message immediately in the case where its receive window is filled and it has no queued data to send for this connection or it can't send queued data because the transmit window is closed. See Appendix B for some examples of how sequence numbers progress. 2.2 Suggested implementation A suggested implementation of this delay is as follows: Upon receiving a non-ZLB message, the receiver starts a timer that will expire in the recommended time interval. A variable, Lr (Last Nr value sent), is used by the transmitter to store the last value sent in the Nr field of a transmitted payload message for this connection. Calhoun, Rubens expires August 1999 [Page 6] INTERNET DRAFT February 1999 Upon expiration of this timer, Sr is compared to Lr and, if they are not equal, a ZLB ACK is issued. If they are equal, then no ACK's are outstanding and no action needs to be taken. This timer should not be reinitialized if a new message is received while it is active since such messages will be acknowledged when the timer expires. This ensures that periodic ACK's are issued with a maximum period equal to the recommended delay time interval. This interval should be short enough to not cause false acknowledgement timeouts at the transmitter when payload messages are being sent in one direction only. Since such ACK's are being sent on what would otherwise be an idle data path, their affect on performance should be small, of not negligible. In order for a DIAMETER implementation to be able to retransmit messages, it MUST queue transmitted messages until the messages are acknowledged. It must also maintain a retransmission timer that determines when to assume that either a sent message did not arrive at the peer or the acknowledgment sent by the peer was lost. See Appendix A for a recommended retransmit timer implementation. There are two recommended methods for implementing the retransmission procedure. One method is for the sender to resend the entire window of unacknowledged messages when the retransmit timeout expires. This is the simplest method, but is inefficient when a receiver is not rotating the window due to congestion. The alternative method is to only resend the first message in the window (the first unacknowledged message) until an acknowledgment is received. This acknowledgment will indicate to the receiver the next, if any, message in the current window that needs to be retransmitted. A particular implementation may use either or both methods if desired. When a DIAMETER node has retransmitted a message to a given peer the maximum number of times (the recommended value is 3), it may send the request to an alternate DIAMETER server. This procedure may continue until either all of the servers have been tried, or the node selectively issues a failure to the requestor. 2.3 Peer failure recovery A DIAMETER message with the Command-Code AVP set to Device-Reboot-Ind and the Ns and Nr values set to zero (0) indicates that the peer has rebooted. This message MUST be recognized and supported by a DIAMETER implementation. When this event occurs, the Ss and Sr values must be reset and the retransmission queue MUST be cleared. Since the protocol requires that all new messages include a random identifier in the protocol header, a Device-Reboot-Ind that is received with the same identifier as the last processed Device-Reboot-Ind is considered Calhoun, Rubens expires August 1999 [Page 7] INTERNET DRAFT February 1999 a retransmission and SHOULD NOT change the peer's state to inactive. Messages other than the Device-Reboot-Ind MUST NOT be sent to the peer until both the acknowledgement for the transmitted Device- Reboot-Ind AND the peer's Device-Reboot-Ind have been received. When both of these have been received, the peer is considered to be in the active state. 3.0 Extended Header Format The DIAMETER Base Protocol [12] assumes that the underlying transport is reliable (e.g. TCP). This section defines the optional fields in the DIAMETER header that allow DIAMETER to provide reliability. See [12] for a full description of the header fields not introduced in this document. A summary of the DIAMETER data format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RADIUS PCC |Flags|A|W| Ver | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Send (Ns) | Next Received (Nr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- PKT Flags The Packet Flags field is five bits, and is used in order to identify any options. This field MUST be initialized to zero. The following flags may be set: The 'W' bit (Window-Present) is set when the Next Send (Ns) and Next Received (Nr) fields are present in the header. This SHOULD be set unless the underlying layer provides reliability (i.e. TCP). The 'A' bit is set to indicate that the packet is an acknowledgement only and does not contain a Command-Code AVP following the header. Note that the Security AVPs MUST still be present within an acknowledgment message. Calhoun, Rubens expires August 1999 [Page 8] INTERNET DRAFT February 1999 Next Send This field is present when the Window-Present bit is set in the header flags. The Next Send (Ns) is copied from the send sequence number state variable, Ss, at the time the message is transmitted. Ss is incremented after copying if the message is not a ZLB ACK. Next Received This field is present when the Window-Present bit is set in the header flags. Nr is copied from the receive sequence number state variable, Sr, and indicates the sequence number, Ns, +1 of the highest (modulo 2^16) in-sequence message received. See section 2.0 for more information. 3.1 ZLB Message Format Zero Length Body messages are used to explicitly acknowledge one or more DIAMETER message, and contain no additional Authentication, Authorization or Accounting related AVPs. ZLB messages must contain authentication AVPx, otherwise attacks could be mounted against DIAMETER nodes. Consider the following figure: +------+ -----> +------+ | | Ns=10 | | | DIA1 +--------------------+ DIA3 | | | Ns=40 | | +------+ <----- +-+----+ / / +------+ / Nr = 41 |Malici| / | ous +-/ | Node | +------+ In the above figure, DIAMETER nodes 1 and 3 are communicating using UDP. DIA3 sends a stream of messages to DIA, with sequence number 40 being the last message sent. A malicious user could send an acknowledgement for Ns 40 to DIA3, effectively opening up the window. Furthermore, if any of the messages from DIA3 were lost in transit to DIA1, DIA3 would not attempt to retransmit them since it received an acknowledgement. The format of a ZLB message will be as follows: Calhoun, Rubens expires August 1999 [Page 9] INTERNET DRAFT February 1999 ::= { || Device-Reboot-Ind Nr: 0, Ns: 0 (ZLB) <- Nr: 1, Ns: 0 -> Device-Watchdog-Ind Nr: 0, Ns: 1 (delay) (ZLB) <- Nr: 2, Ns: 0 B.2 Multiple packets acknowledged This example shows a flow of packets from DIAMETER Host B to Host A, with Host A having no traffic of its own. Host A is waiting 1/4 of its timeout interval, and then acknowledging all packets seen since the last interval. DIAMETER Host A DIAMETER Host B (previous packet flow precedes this) -> (ZLB) Nr: 7000, Ns: 1000 (non-ZLB) <- Nr: 1000, Ns: 7000 (non-ZLB) <- Nr: 1000, Ns: 7001 (non-ZLB) <- Nr: 1000, Ns: 7002 (Host A's timer indicates it should acknowledge pending traffic) -> (ZLB) Nr: 7003, Ns: 1000 B.3 Lost packet with retransmission Host A attempts to communicate with Host B. The Device-Reboot-Ind sent from B to A is lost and must be retransmitted by Host B. Calhoun, Rubens expires August 1999 [Page 16] INTERNET DRAFT February 1999 DIAMETER Host A DIAMETER Host B -> Device-Reboot-Ind Nr: 0, Ns: 0 (packet lost) Device-Reboot-Ind <- Nr: 1, Ns: 0 (pause; Host A's timer started first, so fires first) -> Device-Reboot-Ind Nr: 0, Ns: 0 (Host B realizes it has already seen this packet) (Host B might use this as a cue to retransmit, as in this example) Device-Reboot-Ind <- Nr: 1, Ns: 0 -> Device-Watchdog-Ind Nr: 1, Ns: 1 (delay) (ZLB) <- Nr: 2, Ns: 1 Calhoun, Rubens expires August 1999 [Page 17]