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]
