IPFIX Working Group P. Aitken
Internet-Draft Cisco Systems
Intended status: Standards Track
Expires: August 15th, 2013 February 15, 2013
Reporting Equivalent IPFIX Information Elements
draft-aitken-ipfix-equivalent-ies-00
Abstract
This document proposes a method for IPFIX Exporting Processes
to inform Collecting Processes of equivalent Information
Elements, so that the Collecting Process can understand the
equivalence and be enabled to process data across a change of
Information Elements.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF). Note that other groups may
also distribute working documents as Internet-Drafts. The
list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 15, 2013.
Aitken Expires Aug 2013 [Page 1]
Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013
Copyright Notice
Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date
of publication of this document. Please review these
documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD
License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in
the Simplified BSD License.
Conventions used in this document
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 [RFC2119].
Table of Contents
1 Introduction ........................................... 3
2 Terminology............................................. 4
3 Method ................................................. 4
3.1 Equivalence Message Format ............................ 4
4 The Collecting Process's Side .......................... 6
5 Security Considerations ................................ 6
6 IANA Considerations .................................... 6
7 References ............................................. 7
7.1 Normative References .................................. 7
7.2 Informative References ................................ 7
8 Acknowledgements ....................................... 7
9 Author's Addresses ..................................... 7
Aitken Expires Aug 2013 [Page 2]
Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013
1 Introduction
The IPFIX Protocol [RFC5101] can export a large number of
Information Elements, including standard elements specified in
the IPFIX information model [RFC5102, IANA-IPFIX], Enterprise-
Specific elements [RFC5101], and elements which are backwards
compatible with NetFlow Version 9 [RFC3954].
From time to time, an Exporting Process may export the same
information using different Information Elements from before.
Several scenarios (use cases) can be envisaged:
. Enterprise-specific Information Elements have been
standardised, so the Exporting Process is changed to export
the IANA standard Information Elements [IANA-IPFIX] rather
than the Enterprise-specific Information Elements.
. The Exporting Process is changed to export IANA standard
Information Elements [IANA-IPFIX] rather than NetFlow
version 9 fields [RFC3954].
. The Exporting Process is updated to export different
Enterprise-specific Information Elements.
. An updated Metering Process requests that the Exporting
Process exports using different Information Elements from
before.
In each case it's important to note that the same information is
being exported. The only change is in the Information Element
used to export the information.
Since different Information Elements are now being used to
express the same information, the Collecting Process cannot
process data received before the change with data received after
the change, because the Collecting Process does not know that
these Information Elements are related. e.g. it's not possible
to compare, aggregate, or sort data across such a change without
first understanding that the old and new Information Elements
are equivalent.
Furthermore, it's impossible for every Collecting Process to
know how each IANA standard Information Element [IANA-IPFIX]
relates to every company's Enterprise-Specific Information
Elements. ie, a Collecting Process from company X cannot be
expected to know that company Y's Exporting Process exports
Enterprise-specific field Z which is now equivalent to a certain
IANA standard element.
This document proposes a method for Exporting Processes to
inform Collecting Processes of such equivalence, so that the
Collecting Process is able to process data across the change.
Aitken Expires Aug 2013 [Page 3]
Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013
2 Terminology
Terms used in this document are defined in the Terminology
section of the IPFIX Protocol [RFC5101] and are to be
interpreted as defined there.
3 Method
An Exporting Process informs a Collecting Process of the
equivalence of a pair of IPFIX Information Elements by exporting
an IPFIX Equivalence Message. Equivalence Messages SHOULD be
sent by the Exporting Process upon opening a new Transport
Session, before any other IPFIX Messages are exported. They may
be sent in an Options Record Scoped to the Exporter. Multiple
Equivalence Messages may be sent using IPFIX Structured Data
[RFC6313].
3.1 Equivalence Message Format
The Equivalence Message consists of an original Information
Element in the "informationElementId" field (#303), followed by
the equivalent Information Element in the "equivalentElementId"
field (#TBD), using the Template shown in Figure 1 and Data
Record shown in Figure 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| informationElementId #303 | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| equivalentElementId #TBD | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Template for Equivalence Message
--+-+---------------+-+---------------+--
... |E| Original IE |E| Equivalent IE | ...
--+-+---------------+-+---------------+--
Figure 2: Equivalence Message Data Record
The encoding of these Information Elements follows the rules
specified in [RFC5101].
When the original Information Element and the equivalent
Information Element are both IANA standard elements
[IANA-IPFIX], both of the E bits are zero and the Equivalence
Message is as shown in Figure 1.
When the Original Information Element is Enterprise-Specific,
Aitken Expires Aug 2013 [Page 4]
Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013
the Original Information Element's E bit is set and the
Information Element number is immediately followed by the
corresponding Private Enterprise Number [PEN], as shown in
Figure 3:
+-+---------------+----------------------------------+-+---------------+
|1| Original IE | Private Enterprise Number |0| Equivalent IE |
+-+---------------+----------------------------------+-+---------------+
Figure 3: Equivalence Message with an Enterprise-Specific
Original Information Element
This allows an Enterprise-Specific Information Element to be
specified as equivalent to an IANA-standard Information Element.
When the Equivalent Information Element is Enterprise-Specific,
the Equivalent Information Element's E bit is set and the
Information Element number is immediately followed by the
corresponding Private Enterprise Number [PEN] as shown in
Figure 4:
+-+---------------+-+---------------+----------------------------------+
|0| Original IE |1| Equivalent IE | Private Enterprise Number |
+-+---------------+-+---------------+----------------------------------+
Figure 4: Equivalence Message with an Enterprise Specific
Equivalent Information Element
This allows an IANA-standard Information Element to be specified
as equivalent to an Enterprise-Specific Information Element.
When both of the Information Elements are Enterprise-Specific,
the E bits are set and both Information Element numbers are
immediately followed by their corresponding Private Enterprise
Number [PEN] as shown in Figure 5:
+-+---------------+----------------------------------+
|1| Original IE | Private Enterprise Number | ...
+-+---------------+----------------------------------+
+-+---------------+----------------------------------+
... |1| Equivalent IE | Private Enterprise Number |
+-+---------------+----------------------------------+
Figure 5: Equivalence Message with two Enterprise-Specific
Information Elements
This allows two Enterprise-Specific Information Elements to be
specified as equivalent.
Note that the Private Enterprise Numbers do not have to be
equal. ie, the Information Elements may belong to different
Private Enterprises.
Aitken Expires Aug 2013 [Page 5]
Internet-Draft Reporting Equivalent IPFIX IEs Feb 2013
4 The Collecting Process's Side
Equivalence Messages have global scope, unless they're sent in
an Options Message with a more restrictive scope, eg an Options
Record Scoped to the Exporter. ie, unless otherwise restricted,
the specified equivalence applies to all devices.
Therefore the Collecting Process does not need to maintain
equivalence per device.
5 Security Considerations
The same security considerations apply as for the IPFIX Protocol
[RFC5101].
6 IANA Considerations
A new Information Element "equivalentElementId" must be
allocated in IANA's IPFIX registry, [IANA-IPFIX]:
Description: An IPFIX Information Element
("equivalentElementId") that denotes an Information Element
identifier which is equivalent to another Information Element
identifier, specified in an IPFIX Equivalence Message [this
document].
Abstract Data Type: Unsigned16
Data Type Semantics: identifier
ElementId: TBD
Status: current
Reference: [this document]
Aitken Expires Aug 2013 [Page 6]
7 References
7.1 Normative References
[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.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P.,
and J. Meyer, "Information Model for IP Flow
Information Export", RFC 5102, January 2008.
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services
Export Version 9", RFC 3954, October 2004.
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
"Export of Structured Data in IP Flow Information Export
(IPFIX)", RFC 6313, July 2011.
[IANA-IPFIX]
IANA, "IPFIX Information Elements registry",
<http://www.iana.org/assignments/ipfix/ipfix.xml>.
[PEN] IANA, "Private Enterprise Numbers registry",
<http://www.iana.org/assignments/enterprise-numbers>.
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997
7.2 Informative References
8 Acknowledgements
Thanks to you, dear reader.
9 Author's Addresses
Paul Aitken
Cisco Systems, Inc.
96 Commercial Quay
Commercial Street
Edinburgh, EH6 6LX,
UK
Phone: +44 131 561 3616
Email: paitken@cisco.com