IPFIX Working Group Sujay Gupta
Internet-Draft Infosys Tech. Ltd.
Intended Status: Informational December 4, 2009
Reliability Extension for IPFIX
draft-ietf-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 7, 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 7, 2010 [Page 1]
Internet-Draft Reliability Extension for IPFIX December 4, 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 7, 2010 [Page 2]
Internet-Draft Reliability Extension for IPFIX December 4, 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 7, 2010 [Page 3]
Internet-Draft Reliability Extension for IPFIX December 4, 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 7, 2010 [Page 4]
Internet-Draft Reliability Extension for IPFIX December 4, 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 7, 2010 [Page 5]
Internet-Draft Reliability Extension for IPFIX December 4, 2009
gather any data.
Gupta,Sujay Expires June 7, 2010 [Page 6]
Internet-Draft Reliability Extension for IPFIX December 4, 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 7, 2010 [Page 7]
Internet-Draft Reliability Extension for IPFIX December 4, 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 7, 2010 [Page 8]
Internet-Draft Reliability Extension for IPFIX December 4, 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 7, 2010 [Page 9]
Internet-Draft Reliability Extension for IPFIX December 4, 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 7, 2010 [Page 10]
Internet-Draft Reliability Extension for IPFIX December 4, 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 7, 2010 [Page 11]
