Internet DRAFT - draft-asveren-dime-ansack

draft-asveren-dime-ansack







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]