IPFIX Working Group Sujay Gupta Internet-Draft Infosys Tech. Ltd. Intended Status: Informational December 7, 2009 Reliability Template Extension for IPFIX draft-gupta-ipfix-reliability-template-ext-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. This Internet-Draft will expire on June 10, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Gupta,Sujay Expires June 10, 2010 [Page 1] Internet-Draft Reliability Template Extension December 7, 2009 IPFIX[RFC3917] mandates the IPFIX device should be reliable.To be reliable the individual components like the Metering process or the Exporting process should not fail to meter & export the flow information to the collector, else indicate its incapability explicitly. Currently, IPFIX transmits failure by sending count of packets,flows it failed to process along with the duration of the failure. This document outlines some of the limitations an IPFIX device may have and suggests solutions. Gupta,Sujay Expires June 10, 2010 [Page 2] Internet-Draft Reliability Template Extension December 7, 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Reliability Information Template . . . . . . . . . . . . . . . 5 3. Existing format of Reliability Information Template and Proposed change . . . . . . . . . . . . . . . . . . . . . . . . 7 4. reliabilityReasonCode . . . . . . . . . . . . . . . . . . . . . 9 5. Usage & interpretation of reliabilityReasonCode . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 10. Informative References . . . . . . . . . . . . . . . . . . . 11 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 Gupta,Sujay Expires June 10, 2010 [Page 3] Internet-Draft Reliability Template Extension December 7, 2009 1. Introduction Every IPFIX Observation point is associated with at least one Metering process. The records generated by the Metering process is exported as flow-records by a Exporting Process. To ensure correct measurement of flows-records IPFIX mandates the IPFIX device to be reliable. To be reliable the IPFIX device should either always meter or export the packets else indicate its inability to do so. The Metering Process sends it incapacity to meter in the form of ignoredpacket counts, time duration etc. [RFC5101] as the Reliablity Information. The Exporting Process similarly sends this Reliability information using notSentFlow counts, time duration etc. [RFC5101] as the Reliability Information. The conditions under which Metering and Exporting process send this Information could range from Overload behavior, user intervention to Soft-reset. This document outlines these cases and the limitations an IPFIX device may have in sending Reliability Information with suggested solutions. Gupta,Sujay Expires June 10, 2010 [Page 4] Internet-Draft Reliability Template Extension December 7, 2009 2. Reliability Information Template The Metering Process sends reliability information using the Reliability Statistics Option Templates Section 4.2 & 4.3 [RFC5101]. This optional template SHOULD contain observationDomainId, ignoredPacketTotalCount, ignoredOctetTotalCount, time first ignored, time last ignored & optionally meteringProcessId. Similarly, the Exporting Process sends reliability information using the Exporting Process Statistics Option Template [RFC5101]. This optional template SHOULD contain ExportingProcessId, notSentFlowTotalCount, notSentPacketTotalCount, notSentOctetTotalCount ,time first flow dropped, time last flow dropped. These optional template are sent either periodically or based on some export policy. The statistics may get incremented during; 1. Overload behavior Where a device when under overload may choose not to meter or export packets for a defined duration. 2. Device State Where the metering process has failed to meter owing to dependency on other processes or on the device state. In all of the above cases it is assumed that the Metering process or the Exporting process will manage to gather all the required statistics and send it to the Collector. However; in certain specific states the device MAYBE unable to gather the required data, For example; 1. Overload Behavior Here a device maybe unable to collect any data, until the system is out of Overload. This maybe the case for small scale devices. 2. Device State Here a process may undergo for example a soft-restart preventing any statistics collection. Soft restart often is a planned restart. However, in order for the IPFIX device to be reliable, it should still at least send the duration for which the device could not Gupta,Sujay Expires June 10, 2010 [Page 5] Internet-Draft Reliability Template Extension December 7, 2009 gather any data. Gupta,Sujay Expires June 10, 2010 [Page 6] Internet-Draft Reliability Template Extension December 7, 2009 3. Existing format of Reliability Information Template and Proposed change The existing Reliability Template is split across two templates some for the Metering process reliability Section 4.2, [RFC5101] and other for Exporting process reliability Section 4.3, [RFC5101]. 1. observationDomainId- this is sent in the metering process's reliability template. 2. time first ignored- this is time stamp of the first IP packet which was ignored by the Metering Process. 3. time last ignored- this is time stamp of the last IP packet that was ignored by the Metering Process. 4. ignoredPacketTotalCount- the total number of IP packets that the Metering Process did not process. 5. ignoredOctetTotalCount- the total number of octets that the Metering Process did not process. 6. meteringProcessId- this is sent in the Metering Process's reliability template. 7. exportingProcessId- this is sent in the Exporting Process's reliability template. 8. notSentFlowTotalCount- the total number of flows dropped by the Exporting Process. 9. notSentPacketTotalCount- the total number of packets dropped by the Exporting Process. 10.notSentOctetTotalCount- the total number of octets in packets dropped by the Exporting Process. 11.time first flow dropped- this is the time stamp when the first flow was dropped by the Exporting Process. 12.time last flow dropped- this is the time stamp when the last flow was dropped by the Exporting Process. In the event a IPFIX device is unable to accumulate counters for items (4),(5),(8),(9) & (10) above, as it may happen and is described in Section 2, it is proposed it SHOULD still send the time duration for which it was unable to meter using Items (2) & (3) or (11) & (12) above, in addition to which it is MUST also send a "reasoncode" in a new Information Element, informing the collector process of its Gupta,Sujay Expires June 10, 2010 [Page 7] Internet-Draft Reliability Template Extension December 7, 2009 incapacity to collect any data. This new Information Element is called as "reliabilityReasonCode", and is defined below. It essentially carries information conveying the device status as to when the reliability information was collected. Gupta,Sujay Expires June 10, 2010 [Page 8] Internet-Draft Reliability Template Extension December 7, 2009 4. reliabilityReasonCode Description: The reason code specifies the value matching the state of the IPFIX Device sending the Reliability Options template. It MUST have the one of the following values; 0x00: General - This value is used when the device increments reliability statistics on account of Overload, User Intervention etc. In this state the device is assumed to have the capacity to accumulate all counters. 0x01: Reset - This value is used when the device sends reliability statistics but has been unable to accumulate any or all counters. Abstract Data Type: unsigned8 ElementId: 239 Status: current Units: range {0-1} 5. Usage & interpretation of reliabilityReasonCode According to the IPFIX protocol specification [RFC5101], the Metering Process SHOULD send Reliability Options Template as defined in Section 4.2, [RFC5101] and the Exporting Process should send the Reliability Options template as in Section 4.3, [RFC5101]. Following are the changes suggested; 1. Metering Process Reliability Statistics Option template SHOULD Contain the additional Information Element, "reliabilityReasonCode" If the value of this Information Element is "Reset", the IPFIX device MAY not provide "ignoredPacketTotalCount" and "ignoredOctetTotalCount" fields, it MUST provide the "time first ignored" and "time last ignored". If the value of the Information Element is "General", the IPFIX device is to follow the specification as in Section 4.2, [RFC5101] 2. Exporting Process Reliability Statistics Option template SHOULD Contain the additional Information Element, "reliabilityReasonCode" If the value of this Information Element is "Reset", the IPFIX device MAY not provide "notSentFlowTotalCount", "notSentPacketTotalCount" and "notSentOctetTotalCount" fields, it MUST provide the "time first flow dropped" and "time last flow dropped". If the value of the Information Element is "General", the IPFIX device is to follow the specification as in Section 4.3, [RFC5101]. The Collector Process SHOULD ignore the counter fields if the "reliabilityReasonCode" value is "Reset" for both Metering and Exporting Process reliability templates. The Collector Process may choose to interpret the time duration received in the template as a Gupta,Sujay Expires June 10, 2010 [Page 9] Internet-Draft Reliability Template Extension December 7, 2009 reset period and thus having no flow data, or approximate the flow data lost in the duration. 6. Security Considerations This draft does not directly introduce any security issues, other than that in [RFC5102]. 7. Acknowledgements The author would like to thank Gerhard Muenz for review and Juergen Quittek for support. 8. IANA Considerations This document specifies a new IPFIX Information Element. The proposed Information Element "reliabilityReasonCode" does not duplicate any Existing Information Elements. The proposed Information Element value is XXX, Section 4,[RFC5102] and is subject to Expert Review[RFC5226]. The value of XXX will be replaced as per IANA recommendation. 9. Normative References [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export", RFC 3917, October 2004. [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Gupta,Sujay Expires June 10, 2010 [Page 10] Internet-Draft Reliability Template Extension December 7, 2009 10. Informative References [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J.Quittek, "Architecture Model for IP Flow Information Export", RFC5470, March 2009. 11. Authors' Addresses Sujay Gupta Infosys Tech. Limited Bangalore,India Email: sujay_gupta@infosys.com Gupta,Sujay Expires June 10, 2010 [Page 11]