Network Working Group T. Asveren Internet-Draft Ulticom Inc. Expires: September 28, 2006 March 27, 2006 Diameter Acknowledgement Mechanism draft-asveren-dime-ansack-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 September 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Diameter transport mechanism relies on storing data about received requests to detect duplicate requests. This document discusses the problems associated with this approach and defines new procedures to improve the efficiency of duplicate detection mechanism. Asveren Expires September 28, 2006 [Page 1] Internet-Draft Diameter Acknowledgement Mechanism March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Duplicate Detection in Diameter . . . . . . . . . . . . . . . 3 3. Answer Acknowledgement Mechanism . . . . . . . . . . . . . . . 5 3.1. Answer Acknowledgement Mechanism AVPs . . . . . . . . . . 5 3.1.1. E2E-Instance-Id AVP . . . . . . . . . . . . . . . . . 5 3.1.2. E2E-Sequence-Number AVP . . . . . . . . . . . . . . . 5 3.1.3. E2E-Sequence-Info AVP . . . . . . . . . . . . . . . . 5 3.1.4. Req-Seq AVP . . . . . . . . . . . . . . . . . . . . . 6 3.1.5. Ans-Ack AVP . . . . . . . . . . . . . . . . . . . . . 6 3.1.6. Cumulative-Ans-Ack AVP . . . . . . . . . . . . . . . . 6 3.2. Anser Acknowledment Mechanism Messages . . . . . . . . . . 6 3.2.1. Acknowledgement Request . . . . . . . . . . . . . . . 6 3.3. Answer Acknowledgement Procedures . . . . . . . . . . . . 7 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Successful Answer Acknowledgement . . . . . . . . . . . . 8 4.2. Client Reboot . . . . . . . . . . . . . . . . . . . . . . 9 4.3. ACK Retransmission . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Asveren Expires September 28, 2006 [Page 2] Internet-Draft Diameter Acknowledgement Mechanism March 2006 1. Introduction Diameter Base Protocol defines the transport mechanism to be used for sending/receiving requests/answers. The capability to detect duplicate requests is also included in this mechanism to prevent multiple processing of the same request. This capability relies on storing data about received requests on the server. Because there is no acknowledgement mechanism present for answers, data stored for requests should be stored for an arbitrary amount of time, decreasing the efficiency of the mechanism. 2. Duplicate Detection in Diameter Diameter transport reliability is achieved by clients retransmitting requests, when they detect a failure, e.g. failure of a SCTP association. This requires servers to perform duplicate detection, so that the same request is not processed twice from application semantics point of view. Duplicate detection MAY be performed based on E2E-Id and Origin-Host AVP values, because they combined uniquely and globally identify a request. Application state MAY also be used for certain cases to aid for identifying duplicates but can't be used as a generic solution, e.g. if application logic is stateless or if the expected message flow/AVPs present in the messages do not provide enough information to detect duplicates. (1)X +---------+ (2)Req +---------+ +---------+ | Client |------> |Relay A.1| | Server | +---------+ +---------+ +---------+ ^ | ^ | | | | | | | | | | |(3)Req +---------+ (4)Req | | | +-------> |Relay A.2| ------------+ | +------------- +---------+ <----------------+ (6)Ans (5)Ans Figure 1: Retransmission of request arriving to server as original request 1) Relay Agent1 goes down. 2) Client did not detect yet that Relay Agent1 is down and sends Req to it. 3) Client detects that connection to Relay Agent1 is down and retransmits Req to Relay Agent2. Asveren Expires September 28, 2006 [Page 3] Internet-Draft Diameter Acknowledgement Mechanism March 2006 4) Relay Agent2 forwards Req to Server. 5) Server processes Req and sends Ans to Relay Agent2. 6) Relay Agent2 forwards Ans to Client. (3)X (2)Req +---------+ (1)Req +---------+ --------> +---------+ | Client |------> |Relay A.1| <-------- | Server | +---------+ +---------+ (4)Ans +---------+ ^ | ^ | | | | | | | | | | |(5)Req +---------+ (6)Req | | | +-------> |Relay A.2| ------------+ | +------------- +---------+ <----------------+ (8)Ans (7)Ans Figure 2: Retransmission of request arriving to server as a duplicate request 1) Client sends Req to Relay Agent1. 2) Relay Agent1 forwards Req to Server. 3) Relay Agent1 goes down. 4) Server processes Req and sends Ans to Relay Agent1 because it did not detect yet that Relay Agent1 is down. 5) Client detects that Relay Agent1 is down and retransmits Req to Relay Agent2. 6) Relay Agent2 forwards Req to Server. 7) Server detects that Req is a duplicate and sends the original Ans to Relay Agent2. 8) Relay Agent2 forwards Ans to Client. To be able to distinguish between the two cases presented in the above examples, server needs to keep the history of requests received. There are multiple factors like number of intermediares between client and server, connection failure detection time between Diameter entities, maximum amount of downtime for a client, which could effect the time necessary to store data related with requests received at the server. This time could be in the order of multiple tens of minutes if one considers cases like client storing requests sent in non-volatile storage, going down for a reason requiring hardware replacement, coming up again and retransmitting requests from the non-volatile storage. Considering that storing large amounts of data for received requests consumes both memory and increases search times for duplicate detection processing, it is not optimal. Asveren Expires September 28, 2006 [Page 4] Internet-Draft Diameter Acknowledgement Mechanism March 2006 3. Answer Acknowledgement Mechanism This section describes the answer acknowledgement mechanism. The mechanism relies on acknowledging answer messages, so that server can determine that it does not need to store data corresponding to a specific request anymore. 3.1. Answer Acknowledgement Mechanism AVPs 3.1.1. E2E-Instance-Id AVP E2E-Instance-Id AVP is of type Unsigned64. It is used to distinguish between different boot life cycles of a Diameter entity and MUST be unique and monotonicaly increasing across reboots. Using elapsed time in milliseconds granularity from a prefixed time can satify this requirement, e.g. POSIX gettimeofday function, if the system time is not changed manually and if reboots don't happen in less than a millisecond. 3.1.2. E2E-Sequence-Number AVP E2E-Sequence-Number AVP is of type Unsigned64. It is used to uniquely identify requests during a boot cycle. It MUST be unique and sequentially increasing for requests in a boot cycle. E2E- Sequence-Number MUST begin with "1" after a reboot. 3.1.3. E2E-Sequence-Info AVP E2E-Sequence-Info AVP is of type Grouped. < E2E-Sequence-Info > ::= < AVP Header: XYZ> [ E2E-Instance-Id ] [ E2E-Sequence-Number ] E2E-Sequence-Info AVP is used to uniqiely identify a request sent by a client eternally. It MUST increase monotonically, and the following rule is used when comparing two E2E-Sequence-Info AVPs: If E2E-Instance-Id AVP values are not equal, the one with numerically bigger E2E-Instance-Id is the bigger E2E-Sequence-Info AVP. If E2E-Instance-Id AVP values are equal, the one with numerically bigger E2E-Sequence-Number AVP is the bigger E2E-Sequence-Info AVP. If both E2E-Instance-Id AVPs and E2E-Sequence-Number AVPs are numerically equal, the E2E-Sequence-Info AVPs are equal. Asveren Expires September 28, 2006 [Page 5] Internet-Draft Diameter Acknowledgement Mechanism March 2006 3.1.4. Req-Seq AVP Req-Seq AVP is of type Grouped. < Req-Seq > ::= < AVP Header: XYZ > [ E2E-Sequence-Info ] Req-Seq AVP is used to include sequencing information in requests. All requests MUST contain a Req-Seq AVP. 3.1.5. Ans-Ack AVP Ans-Ack AVP is of type Grouped. < Ans-Ack > ::= < AVP Header: XYZ > 1*[ E2E-Sequence-Info ] Ans-Ack AVP is used to acknowledge received answers. It contains the sequencing information for a request, for which the corresponding answer has been received. It can contain multiple E2E-Sequence-Info AVPs and each of them acknowledge a single answer. 3.1.6. Cumulative-Ans-Ack AVP Cumulative-Ans-Ack is of type Grouped. < Cumulative-Ans-Ack > ::= < AVP Header: XYZ > { E2E-Sequence-Info } Cumulative-Ans-Ack is used to acknowledge a group of received answers. Particularly it acknowledges all anwers, which are sent for requests with equal or smaller sequence information than present in the Cumulative-Ans-Ack AVP. 3.2. Anser Acknowledment Mechanism Messages 3.2.1. Acknowledgement Request Acknowledgement request is used to acknowledge answers, when there is no request to be sent, where answer acknowledgement related AVPs may be attached to. This request MUST NOT be replied with an answer. < ACK > ::= < Diameter Header: XYZ, REQ > [Destination-Host etc...] *[ Ans-Ack ] [Cumulative-Ans-Ack] Asveren Expires September 28, 2006 [Page 6] Internet-Draft Diameter Acknowledgement Mechanism March 2006 3.3. Answer Acknowledgement Procedures Each request MUST include Req-Seq AVP, which uniquely identifies the request among requests sent by the same node. For each request they received, servers SHOULD keep enough data to perform duplicate detection. This data SHOULD be deleted, when an acknowledgement received from the client indicating that the answer for this request has been received by the client. Clients MUST send acknowledgement information for answers they received by adding Ans-Ack AVP, Cumulative-Ans-Ack AVP either to a request message they are going to send to the same server or to an ACK message request specifically sent for that purpose to the server. After a reboot, clients MUST acknowledge all requests, which did not survive the reboot, e.g. which were not stored in a non-volatile storage. This MAY be done by sending an ACK message with a Cumulative-Ans-Ack AVP, where the sequencing information uses the current instance-Id and 0 as sequence number. Such a message would cause all data stored related with previous requests to be released on the server. When a server receives acknowledgement information, where sequence information is not corresponding to any of the data stored for duplicate detection, the acknowledgement SHOULD be silently discarded. ACK request is routed and retransmitted as any other request message. ACK request is answered as any other request. ACK request is not subject to duplicate detection, hence it MUST NOT contain REQ-SEQ AVP. A server receiving ACK MUST NOT store any data to perform duplicate detection. 4. Examples The following symbolic representation is used in example message flows: 1) REQ stands for any request and ANS stands for any answer. A number is added to symbolize different requests and their corresponding answers. 2) The quadruple after each message shows the values for answer acknowledgement related AVPs. The first number shows the E2E- Instance-Id for a request, the second number shows the E2E-Sequence- Number for a request, the third number shows the E2E-Instance-Id for Asveren Expires September 28, 2006 [Page 7] Internet-Draft Diameter Acknowledgement Mechanism March 2006 an answer acknowledgement and the fourth number shows the E2E- Sequence-Number for an answer acknowledgement. For example REQ1(1, 27, 1, 24) means that the request is sent with E2E-Instance-Id 1, E2E-Sequence-Number 27 and is acknowledging receipt of answer corresponding to request sent with E2E-Instance-Id 1 and E2E- Sequence-Number 24. Grouped acknowledgements are symbolized with a 'C'. '-' is used to present lack of certain data. Data for a specific request, which is stored at the server is also shown in the example message flows. 4.1. Successful Answer Acknowledgement Client Server | | |----REQ1(0,1,-,-)-->| | | 0,1 | | |<-----ANS1----------| | | | | |---REQ2(0,2,0,1)--->| | |0,2 | | |<-----ANS2----------| | | | | |---REQ3(0,3,-,-)--->| | |0,2 | |0,3 | | |<------ANS3---------| | | | | |----REQ4(0,4,0,C2)->| | |0,4 | | |<------ANS4---------| | | | | |----ACK(-,-,0,4)--->| | | | | Asveren Expires September 28, 2006 [Page 8] Internet-Draft Diameter Acknowledgement Mechanism March 2006 4.2. Client Reboot Client Server | | |----REQ1(0,0,-,-)-->| | | 0,0 | | |<-----ANS1----------| | | | | |---REQ2(0,1,0,0)--->| | |0,1 | | |---REQ3(0,2,-,-)--->| | |0,1 | |0,2 Client | reboots | | | |----ACK(-,-,17,0)-->| | | 4.3. ACK Retransmission Asveren Expires September 28, 2006 [Page 9] Internet-Draft Diameter Acknowledgement Mechanism March 2006 Client Relay Relay Server Agent1 Agent2 | | | | | | | | |-REQ1(0,0,-,-)->| | | | | | | | |-----REQ1(0,0,-,-)--------->| | | | |0,0 | | | | | |<-------ANS1----------------| | | | | |<----ANS1-------| | | | | | | | Relay | | | Agent1 | | | goes down | | | | | | |--ACK(-,-,0,0)->| | | | | | | Client | | | detects that | | | Relay Agent1 is | | | down | | | | | | | | ---------ACK(-,-,0,0)----->| | | | |--ACK(-,-,0,0)->| | | | | | | | | | | | 5. IANA Considerations 6. Security Considerations 7. Acknowledgments The authors would like to thank David Lehmann for his careful review and suggestions. 8. Normative References [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Asveren Expires September 28, 2006 [Page 10] Internet-Draft Diameter Acknowledgement Mechanism March 2006 Author's Address Tolga Asveren Ulticom Inc. 1020 Briggs Road Mount Laurel, NJ, 08054 USA Email: asveren@ulticom.com Asveren Expires September 28, 2006 [Page 11] Internet-Draft Diameter Acknowledgement Mechanism March 2006 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 (2006). 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. Asveren Expires September 28, 2006 [Page 12]