Network Working Group U. Bodin Internet-Draft Operax Intended status: Informational A. Doria Expires: April 24, 2007 LTU B. Chatras France Telecom S. Norreys BT October 21, 2006 Requirement for the addition of Auditing Functionality to Diameter draft-bodin-dime-auditing-reqs-01.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 April 24, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Diameter is being increasingly included in the work of other standards organizations and has become a key protocol in many architectures. One of the uses of Diameter includes setting and Bodin, et al. Expires April 24, 2007 [Page 1] Internet-Draft Auditing with Diameter October 2006 maintaining hard-state and soft-state during failover and in the event of delayed refresh messages respectively. Often there is a need to query for information on active sessions for backup or synchronization purposes. 1. Terminology and Conventions The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Introduction Diameter has been widely adopted as a base protocol for different interfaces of next generation network (NGN) architectures developed by 3GPP, ETSI TISPAN and the ITU-T. Some of these interfaces are used to support hard state as well as to support soft state. For example, in the ETSI TISPAN NGN architecture the service policy decision function (SPDF) offers a Diameter based interface facing application functions over which they can issue resource reservation requests for various media flows. Such an application function can, e.g., be a SIP based soft-switch or a portal for media streaming. The interface between the SPDF and applications functions must support both hard and soft state. This contribution offers three failover use cases, two for hard-state and one for soft-state, that would benefit from the addition of an auditing function to Diameter. The primary requirement being set out in this draft is the requirement for retrieving state for failover and synchornization purposes. 2.1. Definitions of hard and soft state reservations In this draft, hard-state reservations and soft-state reservation will be used in the meanings documented by ETSI TISPAN[ETSI06]. o Hard-state reservation: type of reservation whereby the requested resources are reserved without time limit. Hard-state reservations are terminated if the DIAMETER session is terminated. o Soft-state reservation: type of reservation whereby the requested resources are reserved for a finite amount of time. Soft-state reservations are terminated when the DIAMETER session is terminated. Bodin, et al. Expires April 24, 2007 [Page 2] Internet-Draft Auditing with Diameter October 2006 2.2. Replication The replication of session data can be performed regularly to facilitate instantiation of fresh server platform using replicated data. This approach is herein referred to as replication for warm standby. Another approach is to replicate session data in real-time to a parallel server platform, which immediately can take over the primary server's tasks in case it fails or becomes unavailable. This approach is referred to as replication for hot standby. The case when no session data is replicated, a fresh server platform taking over the primary server's tasks is referred to as a cold standby. It should be noted that refresh messages may be desirable not only for soft-state reservations. By having clients refreshing their active sessions before a timeout in the server it can be ensured that the clients remain in sync with the server. When a timeout occurs at the absence of an expected refresh message the server would, in this scenario, keep the session and issue a callback to the client informing it that a session exists that has not been refreshed accordingly. The client may then either provide a refresh or explicitly terminate the session by replying to this callback. The behavior of issuing a callback to the client when a session timeout occurs can clearly be useful also for soft-state sessions. For example, clients failing in refreshing sessions would with such callbacks not need to re-establish sessions that should not have been allowed to expire and handle possible consequences of session data being wrongly removed. Refresh failures may for example occur if a delayed refresh arrives after a session has already been deleted. However, in contrst to when hard-state is maintained, a soft-state server needs to eventually terminate a session which is not being refreshed in time (e.g. after a short period following a callback). Issuing a callback to ask whether a session is still active is generally a useful mechanism to assure that clients and their server remain syncronized. That is, a client or a server can benefit from the ability to issue such a question triggered by any internal or external event to make sure a particular session (or set of sessions) is still active in the peer node. For example, in case refresh messages are not used for a hard-state server, the Diameter server could issue a callback for sessions that have been active for a longer period to make sure they are still active in the corresponding client. 2.3. Diameter used for hard-state reservations There are at least two common use cases when Diameter is used for hard-state reservations: Bodin, et al. Expires April 24, 2007 [Page 3] Internet-Draft Auditing with Diameter October 2006 o without replication o with replication 2.3.1. In the case of failover without replication In cases where hard state is used over a Diameter interface in an environment where nodes have backups in case of failure, client nodes need a mechanism to audit their server for active sessions. That is, in case a Diameter client node crashes, its backup needs to audit the server node for active sessions. Otherwise the backup node cannot know which states are active and can't terminate them when they are no longer needed. These cases show that an auditing mechanism is needed to support hard-state whenever session information is replicated for resilience purposes. It is also clear that the auditing mechanisms needs to be symmetrical in order to support both the client auditing for session information in the server and the server auditing the client. 2.3.2. In the case of failover with replication A Diameter client, server, or both may replicate session state information over several database instances at different nodes to facilitate seamless node failovers. Replication of data over several database instances are often done asynchronously to keep response times low. That is, with asynchronous replication (i.e., unacknowledged database writes) a Diameter server can answer immediately to a client request instead of waiting for data to be properly replicated before answering. When using hard-state Diameter clients and their server face the risk of getting out of sync after a failover. As a consequence of asynchronous replication, session state requested and established in a Diameter server node may not have been properly replicated before the server crashes and is seamlessly replaced by its backup (e.g., through IP takeover or SCTP multi-homing). The server may, however, have responded to the request before crashing. The Diameter client could, therefore, record that lost (hard) session state is still active in the server when it is not. On the other hand, in case the client is terminating an active session and the server fails in replicating the state removal before crashing the backup server node will maintain a hard session state of which the client is unaware and which is invalid. 2.4. Diameter used for soft-state reservations In the case of soft-state reservations, an auditing mechanism can still be beneficial at failover between servers and between clients. Bodin, et al. Expires April 24, 2007 [Page 4] Internet-Draft Auditing with Diameter October 2006 At failover between servers the backup server taking over can request clients to re-establish their sessions. Instead waiting for refresh messages to arrive is likely to increase the time needed to get in sync. This is particularly true when long timeout periods are used. At failover between clients that do not replicate data (i.e., cold standby), an auditing mechanism would may allow a backup client to re-establish at least part of the original session data. In case all or part of the data possible to obtain from the server is useless to the backup client, it can choose to explicitly terminate the corresponding sessions. This would shorten the period at which clients and their server are out of sync after a failover. 2.5. Required Mechanisms The cases outlined above require that auditing mechanisms support both queries for a list of active sessions and support specific queries for detailed session information kept by the queried node (i.e., either the client or the server node). A further requirement for an auditing mechanism is that it must be able to work in parallel with the basic runtime operation of the Diameter signaling and interrupt that signaling. For example, in case a large number of audit messages is needed to synchronize, the rate of those messages must be possible to limit leaving enough capacity to the basic runtime signaling to handle ordinary session setup and teardown. Support for queries to check if a particular session or a set (list) of sessions are still active in the peer node is also required (i.e. either the server or a client node). 3. Proposal In keeping with the charter goal of updating Diameter in support with its current uses, the DIME WG is requested to add support of a two step approach to its list of work items. After the requirements have been discussed, updated and verified as being of interest to enough of the participants, the DIME WG is then requested to make the necessary changes to the base protocol to support auditing functionality. It is also suggested the DIME WG coordinate with other SDOs, especially those who have integrated Diameter into their architectures, in establishing the auditing functionality requirements. Bodin, et al. Expires April 24, 2007 [Page 5] Internet-Draft Auditing with Diameter October 2006 3.1. Existing work A two step approach to retrieving state information was recommended by draft-calhoun-diameter-res-mgmt-08.txt [id-res-mgmt] which was last updated in 2002. If the requirements are accepted by the WG it is recommended that this might be good starting point for work on adding auditing to Diameter. 4. References 4.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 4.2. Informational References [ETSI06] ETSI TISPAN, "Telecommunications and Internet converged Services and Protocols for Advanced Networking", 2006. [id-res-mgmt] Pat, P., "Diameter - Resource Management Extensions", 2001. Appendix A. changes in -01 1. Add some specificity on the purpose of the requirements 2. Added a soft state use case for synchronization. 3. Added a section on replication 4. Added informational reference to ETSI ES 283 026 with definitions of soft and hard state Appendix B. IANA considerations None at this time. Bodin, et al. Expires April 24, 2007 [Page 6] Internet-Draft Auditing with Diameter October 2006 Authors' Addresses Ulf Bodin Operax Lulea S-977 75 Sweden Email: Ulf.Bodin@operax.com URI: www.operax.com Avri Doria LTU Lulea Sweden Email: avri@ltu.se URI: psg.com/~avri Bruno Chatras France Telecom Email: bruno.chatras@orange-ft.com URI: Steve Norreys BT Email: steve.norreys@bt.com URI: Bodin, et al. Expires April 24, 2007 [Page 7] Internet-Draft Auditing with Diameter October 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bodin, et al. Expires April 24, 2007 [Page 8]