IPFIX Working Group B. Claise
Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track A. Kobayashi
Expires: April 19, 2010 NTT PF Lab.
B. Trammell
Hitachi Europe
October 19, 2009
Specification of the Protocol for IPFIX Mediations
draft-claise-ipfix-mediation-protocol-00
Abstract
This document specifies the IP Flow Information Export
(IPFIX) protocol specific to the Mediation.
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
This Internet-Draft will expire on April, 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
(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
<Claise, et. Al> Expires April 19 2009 [Page 1]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
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 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.................................................3
2.1. IPFIX Documents Overview...............................7
2.2. Relationship with IPFIX and PSAMP......................7
3. Specifications..............................................8
3.1. Encoding of IPFIX Message Header ......................8
3.2. Template Management....................................9
3.2.1. Template Management Without Template Record Change9
3.2.2. Template Management With Template Record Change..10
3.3. Time Management.......................................10
3.4. Observation Point Management..........................11
3.4.1. Observation Domain Management....................11
3.5. Specific Reporting Requirements.......................12
3.5.1. The Flow Keys Options Template...................13
3.5.2. IPFIX Protocol Options Template..................13
3.5.3. IPFIX Mediator Options Template..................13
3.6. Transport Session Management..........................14
3.7. The Collecting Process's Side.........................14
3.8. Sampling Management...................................14
3.9. Filtering Management..................................14
4. New Intermediate Function..................................15
5. Security Considerations ...................................15
6. IANA Considerations........................................15
7. References.................................................15
7.1. Normative References..................................15
7.2. Informative References................................15
8. Author's Addresses.........................................16
TO DO
<Claise, et. Al> Expires April 19, 2010 [Page 2]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
- This draft is basically a starting point: multiple open issues
must be discussed throughout the draft
- What should we export in terms of Original Exporter? A
specific Options Template?
- Should we export the aggregation function for an IPFIX
Concentrator?
- Do we want to have an aggregate observation point?
- Review the problem statement, section 6 "IPFIX Mediators
Implementation Specific Problems" to see if we covered all
problems
- See the EDITOR'S NOTE within the document
1. Introduction
The IPFIX architectural components in [RFC5470] consist of
IPFIX Devices and IPFIX Collectors communicating using the
IPFIX protocol [RFC5101], which specifies how to export IP
Flow information. This protocol is designed to export
information about IP traffic Flows and related measurement
data, where a Flow is defined by a set of key attributes
(e.g. source and destination IP address, source and
destination port, etc.).
The specifications in the IPFIX protocol [RFC5101] have not
been defined in the context of an IPFIX Mediator
receiving/aggregating/correlating/anonymizing/etc... Flow
Records from the one or multiple Exporters. Indeed, the
IPFIX protocol must be adapted for Intermediate Processes, as
defined in the IPFIX Mediation Reference Model (Figure A of
[IPFIX-MED-FMWK].
2. Terminology
The IPFIX-specific and PSAMP-specific terminology used in this
document is defined in [RFC5101] and [RFC5476], respectively.
The IPFIX Mediation-specific terminology used in this document
is defined in [IPFIX-MED-PS]. However, as reading the problem
statements document is not a prerequisite to reading this
framework document, the definitions have been reproduced here
along with additional definitions. In this document, as in
[RFC5101] and [RFC5476], the first letter of each IPFIX-specific
and PSAMP-specific term is capitalized along with the IPFIX
Mediation-specific term defined here.
In this document, we use the generic term "record stream" to
denote a set of flow- or packet-based data records and their
<Claise, et. Al> Expires April 19, 2010 [Page 3]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
additional information that flows from data sources, whether
encoded in IPFIX protocol or non-IPFIX protocols. Regarding
IPFIX and PSAMP, we use the generic term "Data Records" for
IPFIX Flow Records, PSAMP Packet Reports, and Data Records
defined by Options Templates, unless an explicit distinction is
required.
Transport Session Information
The Transport Session is specified in [RFC5101]. In SCTP, the
Transport Session Information is the SCTP association. In TCP
and UDP, the Transport Session Information corresponds to a 5-
tuple {Exporter IP address, Collector IP address, Exporter
transport port, Collector transport port, transport protocol}.
Original Exporter
An Original Exporter is an IPFIX Device that hosts the
Observation Points where the metered IP packets are observed.
IPFIX Mediation
IPFIX Mediation is the manipulation and conversion of a record
stream for subsequent export using the IPFIX protocol.
The following terms are used in this document to describe the
architectural entities used by IPFIX Mediation.
Intermediate Process
An Intermediate Process takes a record stream as its input
from Collecting Processes, Metering Processes, IPFIX File
Readers, other Intermediate Processes, or other record
sources; performs some transformations on this stream, based
upon the content of each record, states maintained across
multiple records, or other data sources; and passes the
transformed record stream as its output to Exporting
Processes, IPFIX File Writers, or other Intermediate
Processes, in order to perform IPFIX Mediation. Typically, an
Intermediate Process is hosted by an IPFIX Mediator.
Alternatively, an Intermediate Process may be hosted by an
Original Exporter.
Specific Intermediate Processes are described below. However,
this is not an exhaustive list.
Intermediate Conversion Process
<Claise, et. Al> Expires April 19, 2010 [Page 4]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
An Intermediate Conversion Process is an Intermediate Process
that transforms non IPFIX into IPFIX, or manages the relation
among Templates and states of incoming/outgoing transport
sessions in the case of transport protocol conversion (e.g.,
from UDP to SCTP).
Intermediate Aggregation Process
An Intermediate Aggregation Process is an Intermediate Process
that aggregates records based upon a set of Flow Keys or
functions applied to fields from the record (e.g., binning and
subnet aggregation).
Intermediate Correlation Process
An Intermediate Correlation Process is an Intermediate Process
that adds information to records, noting correlations among
them, or generates new records with correlated data from
multiple records (e.g., the production of bidirectional flow
records from unidirectional flow records).
Intermediate Selection Process
An Intermediate Selection Process is an Intermediate Process
that selects records from a sequence based upon criteria-
evaluated record values and passes only those records that
match the criteria (e.g., filtering only records from a given
network to a given Collector).
Intermediate Anonymization Process
An Intermediate Anonymization Process is an Intermediate
Process that transforms records in order to anonymize them, to
protect the identity of the entities described by the records
(e.g., by applying prefix-preserving pseudonymization of IP
addresses).
IPFIX Mediator
An IPFIX Mediator is an IPFIX Device that provides IPFIX
Mediation by receiving a record stream from some data sources,
hosting one or more Intermediate Processes to transform that
stream, and exporting the transformed record stream into IPFIX
Messages via an Exporting Process. In the common case, an
IPFIX Mediator receives a record stream from a Collecting
Process, but it could also receive a record stream from data
sources not encoded using IPFIX, e.g., in the case of
<Claise, et. Al> Expires April 19, 2010 [Page 5]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
conversion from the NetFlow V9 protocol [RFC3954] to IPFIX
protocol.
Specific types of IPFIX Mediators are defined below.
IPFIX Proxy
An IPFIX Proxy is an IPFIX Mediator that converts a record
stream for the purpose of protocol conversion.
IPFIX Concentrator
An IPFIX Concentrator is an IPFIX Mediator that receives a
record stream from one or more Exporters and performs
correlation, aggregation, and/or modification.
IPFIX Distributor
An IPFIX Distributor is an IPFIX Mediator that receives a
record stream from one or more Exporters and exports each
record to one or more Collectors, deciding to which
Collector(s) to export each record depending on the decision
of an Intermediate Process.
IPFIX Masquerading Proxy
An IPFIX Masquerading Proxy is an IPFIX Mediator that receives
a record stream from one or more Exporters to screen out parts
of records according to configured policies in order to
protect the privacy of the network's end users or to retain
sensitive data of the exporting organization.
The following is a summary table for specific IPFIX Mediator
types. The abbreviation "IP" stands for Intermediate Process.
Table A: IPFIX Mediator Type Summary Table.
+-------------------+------------+-----------------------------+
IPFIX Mediator Number of Intermediate Process Type
Type hosted IPs
+===================+============+=============================+
IPFIX Proxy one or more Intermediate Conversion
Process
+-------------------+------------+-----------------------------+
IPFIX Distributor one or more Intermediate Selection
Process
+-------------------+------------+-----------------------------+
IPFIX Concentrator one or more Intermediate Aggregation
Process
<Claise, et. Al> Expires April 19, 2010 [Page 6]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
Intermediate Correlation
Process
+-------------------+------------+-----------------------------+
IPFIX Masquerading one or more Intermediate Anonymization
Proxy Process
+-------------------+------------+-----------------------------+
2.1. IPFIX Documents Overview
The IPFIX Protocol [RFC5101] provides network administrators
with access to IP Flow information.
The architecture for the export of measured IP Flow
information out of an IPFIX Exporting Process to a Collecting
Process is defined in the IPFIX Architecture [RFC5470], per
the requirements defined in RFC 3917 [RFC3917].
The IPFIX Architecture [RFC5470] specifies how IPFIX Data
Records and Templates are carried via a congestion-aware
transport protocol from IPFIX Exporting Processes to IPFIX
Collecting Processes.
IPFIX has a formal description of IPFIX Information Elements,
their name, type and additional semantic information, as
specified in the IPFIX Information Model [RFC5102].
The IPFIX Applicability Statement [RFC5472] describes what
type of applications can use the IPFIX protocol and how they
can use the information provided. It furthermore shows how
the IPFIX framework relates to other architectures and
frameworks.
"IPFIX Mediation: Problem Statement" [IPFIX-MED-PS], describing
the IPFIX Mediation applicability examples, along with some
problems that network administrators have been facing, is the
basis for the "IPFIX Mediation: Framework" [IPFIX-MED-FMWK].
This framework details the IPFIX Mediation reference model and
the components of an IPFIX Mediator.
2.2. Relationship with IPFIX and PSAMP
The specification in this document applies to the IPFIX
protocol specifications [RFC5101]. All specifications from
[RFC5101] apply unless specified otherwise in this document.
<Claise, et. Al> Expires April 19, 2010 [Page 7]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
As the Packet Sampling (PSAMP) protocol specifications
[RFC5476] are based on the IPFIX protocol specifications, the
specifications in this document are also valid for the PSAMP
protocol. Therefore, the method specified by this document
also applies to PSAMP.
3. Specifications
This section describes the IPFIX specifications for Mediation.
These new specifications, which are more specific compared to
[RFC5101], are described with the key words described in
[RFC2119].
3.1. Encoding of IPFIX Message Header
The format of the IPFIX Message Header is shown in Figure A.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A: IPFIX Message Header format
Message Header Field Descriptions
Version
Version of Flow Record format exported in this message.
The value of this field is 0x000a for the current
version, incrementing by one the version used in the
NetFlow services export version 9 [RFC3954].
Length
Total length of the IPFIX Message, measured in octets,
including Message Header and Set(s).
<Claise, et. Al> Expires April 19, 2010 [Page 8]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
Export Time
Time in seconds since 0000 UTC Jan 1st 1970, at which
the IPFIX Message Header leaves the IPFIX Mediator.
Sequence Number
Incremental sequence counter modulo 2^32 of all IPFIX
Data Records sent on this PR-SCTP stream from the
current Observation Domain by the Exporting Process.
Check the specific meaning of this field in the sub-
sections of section 10 when UDP or TCP is selected as
the transport protocol. This value SHOULD be used by
the Collecting Process to identify whether any IPFIX
Data Records have been missed. Template and Options
Template Records do not increase the Sequence Number.
Observation Domain ID
A 32-bit identifier of the Observation Domain that is
locally unique to the Exporting Process. The Exporting
Process uses the Observation Domain ID to uniquely
identify to the Collecting Process the Observation
Domain that metered the Flows. It is RECOMMENDED that
this identifier is also unique per IPFIX Device.
Collecting Processes SHOULD use the Transport Session
and the Observation Domain ID field to separate
different export streams originating from the same
Exporting Process. The Observation Domain ID SHOULD be
0 when no specific Observation Domain ID is relevant for
the entire IPFIX Message. For example, when exporting
the Exporting Process Statistics, or in case of
hierarchy of Collector when aggregated data records are
exported.
EDITOR'S NOTE: make the link with section 3.4.1.
3.2. Template Management
3.2.1. Template Management Without Template Record Change
The first case is a situation where the IPFIX Mediator,
typically an IPFIX Distributor, relays an (Options) Template
without changing its content.
As in [RFC5101], the Template IDs are unique per Exporter, per
Transport Session, and per Observation Domain. As there is no
<Claise, et. Al> Expires April 19, 2010 [Page 9]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
guarantee that, for similar Template Records, the Template IDs
received on the incoming Transport Session and exported to the
outgoing Transport Session would be same, the IPFIX Mediator
MUST maintain a mapping database between received and exported
(Options) Template Records:
- for each Received (Options) Template Record: Template Record
Flow Keys and non Flow Keys, Template ID, Original Exporter,
Observation Domain, and Transport Session
- for each Exported (Options) Template Record: Template Record
Flow Keys and non Flow Keys, Template ID, Collector,
Observation Domain, and Transport Session
If an IPFIX Mediator receives an IPFIX Withdrawal Message for a
(Options) Template Record that is not used anymore in any
outgoing Transport Sessions, the IPFIX Mediator SHOULD send the
appropriate IPFIX Withdrawal Message(s) on the outgoing
Transport Session, and remove the corresponding entry in its
mapping database.
If an incoming Transport Session is gracefully shutdown or
reset, the (Options) Template Records corresponding to that
Transport Session MUST be removed from the mapping database.
If a (Options) Template Record is not used anymore in outgoing
Transport Session, it MUST be withdrawn with an IPFIX Withdrawal
Message on that specific outgoing Transport Session.
3.2.2. Template Management With Template Record Change
The second case is a situation where the IPFIX Mediator,
typically an IPFIX Concentrator or an IPFIX Masquerading Proxy,
generates new (Options) Template compared to what it receives
from the Original Exporters.
EDITOR'S NOTE: to be completed. This is slightly more complex as
we have to introduce the notion of derived (Options) Template
Records.
3.3. Time Management
The IPFIX Message Header "Export Time" field is the time in
seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message
Header leaves the Mediator.
<Claise, et. Al> Expires April 19, 2010 [Page 10]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
It is RECOMMENDED that Mediators handle time using absolute
timestamps (e.g. flowStartSeconds, flowStartMilliseconds,
flowStartNanoseconds), which are specified relative to the UNIX
epoch (00:00 UTC 1 Jan 1970), where possible, rather than
relative timestamps (e.g. flowStartSysUpTime,
flowStartDeltaMicroseconds), which are specified relative to
protocol structures such as system initialization or message
export time.
The latter are difficult to manage for two reasons. First, they
require constant translation, as the system initialization time
of an intermediate system and the export time of an intermediate
message will change across mediation operations. Further,
relative timestamps introduce range problems.
For example, when using the flowStartDeltaMicroseconds and
flowEndDeltaMicroseconds Information Elements [RFC5102], the
Data Record must be exported within a maximum of 71 minutes
after its creation. Otherwise, the 32-bit counter would not be
sufficient to contain the flow start time offset. Those time
constraints might be incompatible with some of the Intermediate
Processes: Intermediate Aggregation Process (temporal) and
Intermediate Correlation Process, for example.
EDITOR'S NOTE: when an IPFIX Concentrator aggregates information
from different Flow Records, what should be the time reported?
3.4. Observation Point Management
EDITOR'S NOTE: Do we want to aggregate the observation points?
EDITOR'S NOTE: Do we want to export the
originalExporterIPaddress? Do we want a series of new IEs for
that?
3.4.1. Observation Domain Management
EDITOR'S NOTE: to be discussed
Solution 1: if we observe from different ODs, then the new OD
must always be 0.
Solution 2: if we observe from different ODs, the MD must
compute a new OD id, unique to the MD
Solution 3: if we observe from different ODs, then the new OD
must always be 0 and a new Options Template must contain the
list of OD.
<Claise, et. Al> Expires April 19, 2010 [Page 11]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
Solution 4: we always introduce the Original Exporter ID so that
the (Original Exporter, Original OD) pair is unique
Solution 5: If we observe from different ODs, ODs are preserved
when 1) data records are not moved to different messages and 2)
ODs don't collide. In case 2, ODs are mapped by the mediator.
Mediators should attempt the minimum possible OD mapping. Keep
in mind ODs are a protocol-specific identifier meant to keep
templates and scopes from colliding, NOT to export any actual
information about the collection infrastructure. A first pass at
text for this alternative appears below.
A Mediator SHOULD attempt to preserve the Observation Domain IDs
of incoming messages when processing IPFIX data on a per IPFIX
Message basis in order to preserve the scope of mediated
(Options) Templates. When information comes to a IPFIX Mediator
from two separate Exporting Processes bearing the same
Observation Domain ID, the Mediator SHOULD assign a new
Observation Domain ID for one of the Observation Domains.
Keeping Observation Domains separate ensures that re-exported
Templates and Options will not collide without requiring
rewriting.
When mixing Data Records from multiple Messages received from
multiple Observation Domains, or generating new Data Records
from the result of some intermediate function on Data Records
from multiple IPFIX Messages received from multiple Observation
Domains, a Mediator SHOULD assign a new Observation Domain ID
for the exported IPFIX Messages. This is consistent with the
preservation guideline above, as in most if not all such
circumstances, the IPFIX Mediator will be generating new
Templates itself as a consequence of the mediation being
performed.
3.5. Specific Reporting Requirements
Some specific Options Templates and Options Template Records are
necessary to provide extra information about the Flow Records
and about the Metering Process.
The Option Template and Options Template Records defined in
these subsections, which impose some constraints on the Metering
Process and Exporting Process implementations, MAY be
implemented. If implemented, the specific Option Templates
SHOULD be implemented as specified in these subsections.
<Claise, et. Al> Expires April 19, 2010 [Page 12]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
The minimum set of Information Elements is always specified in
these Specific IPFIX Options Templates. Nevertheless, extra
Information Elements may be used in these specific Options
Templates.
3.5.1. The Flow Keys Options Template
Exactly like the IPFIX protocol [RFC5101], the Flow Keys Option
Template specifies the structure of a Data Record for reporting
the Flow Keys of reported Flows. A Flow Keys Data Record
extends a particular Template Record that is referenced by its
templateId identifier. The Template Record is extended by
specifying which of the Information Elements contained in the
corresponding Data Records describe Flow properties that serve
as Flow Keys of the reported Flow.
The Flow Keys Option Template SHOULD contain the following
Information Elements that are defined in [RFC5102]
templateId An identifier of a Template. This
Information Element MUST be defined
as a Scope Field.
flowKeyIndicator Bitmap with the positions of the Flow
Keys in the Data Records.
When any Intermediate Process changes the Flow Keys, the Flow
Keys Option Template MUST include the new set of Flow Keys.
Typically, an Intermediate Aggregation Process reduces the
number of Flow Keys
3.5.2. IPFIX Protocol Options Template
The "Metering Process Statistics Options Template", "The
Metering Process Reliability Statistics Options Template", and
"The Exporting Process Reliability Statistics Options Template",
as specified in [RFC5101], SHOULD be implemented on the IFPIX
Mediator.
3.5.3. IPFIX Mediator Options Template
EDITOR'S NOTE: we don't think we need a specific Options
Template for the IPFIX Mediator; instead, each mediation
function which has some useful metadata (for example, [IPFIX-
ANON] should define its own Options Template Record(s). They
should simply all look like each others.
For example, a specification of IPFIX flow anonymisation
including an Options Template for the export of metadata about
anonymised flows is described in [IPFIX-ANON]; when anonymising
<Claise, et. Al> Expires April 19, 2010 [Page 13]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
Flows Records, IPFIX Mediators SHOULD add the Options Template
specified therein to annotate the exported data.
3.6. Transport Session Management
We should be allowing the three transport protocols, i.e. UDP,
TCP, SCTP [RFC4960] [RFC3758], as input with the caveats that go
along with each transport protocol (i.e., never use UDP unless
on a dedicated network...)
EDITOR'S NOTE: to be completed
3.7. The Collecting Process's Side
If we change something on the protocol, the Collecting Process
must be able to support it.
For example, if we impose that the new O.P. is a structured data
composed of different remote O.P., then the C.P. must support
structured data.
EDITOR'S NOTE: to be completed
3.8. Sampling Management
EDITOR'S NOTE: What about the accuracy of aggregated Flow
Records with the sampling rates? With different sampling rates?
EDITOR'S NOTE: similarly, shouldn't this section be handled in
the adopted -sampling draft?
Potentially. Maybe but we could write a sentence such:
"if the Mediation aggregates flow records with sampling rate,
the new sampling rate must be calculated"
Or maybe
"the Mediation can't aggregate flow records with different
sampling rate"
Or...
3.9. Filtering Management
QUESTION: What should we do in terms of filtering? Should we try
to export the filtering function?
<Claise, et. Al> Expires April 19, 2010 [Page 14]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
4. New Intermediate Function
How should new intermediate functions be plugged into this
protocol? OR maybe this is a framework question?
5. Security Considerations
The same security considerations as for the IPFIX Protocol
[RFC5101] apply.
6. IANA Considerations
EDITOR'S NOTE: to be updated with any Mediation's specific new
Information Elements.
7. References
7.1. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997
[RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP),
Partial Reliability Extension", May 2004
[RFC4960] Stewart, R., Ed., "Stream Control Transmission
Protocol", RFC 4960, September 2007.
[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.
7.2. Informative References
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export", RFC
3917, October 2004
<Claise, et. Al> Expires April 19, 2010 [Page 15]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
[RFC3954] Claise, B. (Ed), "Cisco Systems NetFlow Services
Export Version 9", RFC 3954, October 2004
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J.
Quittek, "Architecture Model for IP Flow Information
Export", RFC5470, March 2009
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
"IP Flow Information Export (IPFIX) Applicability", RFC
5472, March 2009
[RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet
Sampling (PSAMP) Protocol Specifications", RFC 5476,
March 2009.
[IPFIX-MED-PS] Kobayashi, A. (Ed), Claise, B. (Ed), "IPFIX
Mediation: Problem Statement", draft-ietf-ipfix-
mediators-problem-statement-06, Internet-Draft work in
progress, October 2009.
[IPFIX-MED-FMWK] Kobayashi, A., Claise, B., and K. Ishibashi,
"IPFIX Mediation: Framework", draft-ietf-ipfix-
mediators-framework-04, Internet-Draft work in
progress, October 2009.
[IPFIX-ANON] Boschi, E., Trammell, B. "IPFIX Mediation:
Framework", draft-ietf-ipfix-anon-00.txt, Internet-
Draft work in progress, October 2009.
8. Author's Addresses
Benoit Claise
Cisco Systems Inc.
De Kleetlaan 6a b1
Diegem 1813
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Atsushi Kobayashi
<Claise, et. Al> Expires April 19, 2010 [Page 16]
Internet-Draft <IPFIX Export per SCTP Stream> October 2009
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81-422-59-3978
Email: akoba@nttv6.net
URI: http://www3.plala.or.jp/akoba/
Brian Trammell
Hitachi Europe
c/o ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Phone: +41 44 632 70 13
EMail: brian.trammell@hitachi-eu.com
<Claise, et. Al> Expires April 19, 2010 [Page 17]