IPFIX Working Group B. Claise
Internet-Draft A. Johnson
Intended Status: Standards Track P. Aitken
Expires: October 30th, 2007 Cisco Systems,
Inc.
April 30th 2007
IPFIX Export per SCTP Stream
draft-claise-ipfix-export-per-sctp-stream-00
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 June, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
<Claise, et. Al> Expires October 30, 2007 [Page 1]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
Abstract
This document specifies an improvement to the use of SCTP as
specified in IPFIX: exporting each template record and the
associated data records within a unique SCTP stream. This
specification offers several advantages: the transmission order
is maintained, the data loss for each template record can be
deduced, and the collecting process's job is easier.
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. Open Issues and Action Items for the next draft version.....3
2. Introduction................................................3
2.1. IPFIX Documents Overview...............................4
2.2. PSAMP Documents Overview...............................5
3. Terminology.................................................5
3.1. Terminology Summary Table..............................8
4. High Level View of the Proposal and Advantages..............8
4.1. Advantage 1: Transmission Order........................8
4.2. Advantage 2: Data Record Loss per Template.............9
4.3. Advantage 3: Easier Job for the Collecting Process.....9
5. Specifications..............................................9
5.1. Template Management....................................9
5.2. The Collecting Process's Side.........................13
5.3. PR-SCTP...............................................14
6. IANA Considerations........................................15
7. Security Considerations....................................15
8. References.................................................15
8.1. Normative References..................................15
8.2. Informative References................................16
9. Acknowledgements...........................................17
10. Author's Addresses........................................17
11. Intellectual Property Statement...........................17
12. Copyright Statement.......................................18
13. Disclaimer................................................18
<Claise, et. Al> Expires October 30, 2007 [Page 2]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
1. Open Issues and Action Items for the next draft version
. Insert the functionality to add streams in SCTP, when
available in the SCTP reset draft.
. Verify if the terminology section is complete, and copied
over from [IPFIX-PROTO] when published
- In the section "High Level View of the Proposal and
Advantages", rather than giving the advantages of our
proposal perhaps we should highlight the shortcomings of the
IPFIX method and then give a proposal that solves these
issues.
- What if the option is used in multiple streams? It could be
sent multiple times, supposing each stream to operate
independently.
- Shall we use the counter reset mechanism in SCTP to indicate
that there was something wrong with this specific
Template/stream, that the template ID should be discarded on
the Collecting Process?
Proposal: presumably some indication of the stream reset is
given to the higher level process. If so, that indication can
be used for this purpose, yes.
2. Introduction
The IPFIX working group has specified a protocol to export IP
Flow information [IPFIX-PROTO]. 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.). However, thanks to its template
mechanism, the IPFIX protocol can export any type of
information, as long as the Information Element is specified in
the IPFIX Information Model [IPFIX-INFO], registered with IANA,
or specified as enterprise-specific.
The IPFIX protocol [IPFIX-PROTO] specifies that IP traffic
measurements for flows are exported using a TLV (type, length,
value) format. The information is exported using a Template
Record that is sent once to export the {type, length} pairs that
define a data format for one or more Data Records that are sent
for a flow. The Data Records specify values for each flow.
The IPFIX protocol [IPFIX-PROTO] specifies that all Template
Records SHOULD be sent on a Stream Control Transmission Protocol
(SCTP) association on stream 0 and that the templates MUST be
<Claise, et. Al> Expires October 30, 2007 [Page 3]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
sent reliably. The Data Records are sent on a different SCTP
stream, for which the reliably level can be chosen.
A Collecting Process must have received the Template Record
associated with the Data Records to be able to decode the
information in the Data Records. However, because the Template
is on a different stream from the corresponding Data Records,
the Template may not be received before the Data Records. For
example, a Template may be blocked pending reliable transmission
on stream 0 while the associated Data Records may be transmitted
immediately in an unreliable message on another stream.
Because the Collecting Process cannot decode the Data Records
without the Template, the Data Records may be discarded by the
Collector. Also, due to different stream congestion, it is
possible that even if the Template and Data Records are both
sent reliably, the Data Records sent on another stream still
might arrive before the associated Template. Again, the
Collecting Process cannot decode the Data Records without the
Template and the Data Records may be discarded. Also, because
Data Records pertaining to different templates may be sent on
the same SCTP stream, there is no way of knowing how much data
was lost for Data Records associated with a specific Template
because the collector cannot determine which Template the lost
Data Records were associated with. In some cases, it may be
important to know how many Data Records were lost (e.g., in the
case of billing), but conventionally IPFIX cannot provide this
information.
The section 6.3.2 of the Requirements for IP Flow Information
Export [RFC3917] discusses the data transfer reliability issues.
"Loss of flow records during the data transfer from the
exporting process to the collecting process must be indicated at
the collecting process." is clearly mentioned.
As the Packet Sampling (PSAMP) Protocol Specifications [PSAMP-
PROTO] are based on the IPFIX protocol specifications, the
explanations in this introduction as also valid for the PSAMP
protocol. Therefore, the advantages specified by this document
also apply to PSAMP.
2.1. IPFIX Documents Overview
The IPFIX Protocol [IPFIX-PROTO] provides network administrators
with access to IP flow information.
<Claise, et. Al> Expires October 30, 2007 [Page 4]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
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 [IPFIX-ARCH], per the
requirements defined in RFC 3917 [RFC3917].
The IPFIX Architecture [IPFIX-ARCH] 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 [IPFIX-INFO].
Finally the IPFIX Applicability Statement [IPFIX-AS] 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.
2.2. PSAMP Documents Overview
The document "A Framework for Packet Selection and Reporting"
[PSAMP-FMWK], describes the PSAMP framework for network elements
to select subsets of packets by statistical and other methods,
and to export a stream of reports on the selected packets to a
collector.
The set of packet selection techniques (sampling, filtering, and
hashing) supported by PSAMP are described in "Sampling and
Filtering Techniques for IP Packet Selection" [PSAMP-TECH].
The PSAMP protocol [PSAMP-PROTO] specifies the export of packet
information from a PSAMP Exporting Process to a PSAMP Collecting
Process. Like IPFIX, PSAMP has a formal description of its
information elements, their name, type and additional semantic
information. The PSAMP information model is defined in [PSAMP-
INFO].
Finally [PSAMP-MIB] describes the PSAMP Management Information
Base.
3. Terminology
The terms in this section are in line with the IPFIX terminology
section [IPFIX-PROTO].
<Claise, et. Al> Expires October 30, 2007 [Page 5]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
Template
Template is an ordered sequence of <type, length> pairs,
used to completely specify the structure and semantics of a
particular set of information that needs to be communicated
from an IPFIX Device to a Collector. Each Template is
uniquely identifiable by means of a Template ID.
Template Record
A Template Record defines the structure and interpretation
of fields in a Data Record.
Data Record
A Data Record is a record that contains values of the
parameters corresponding to a Template Record.
Options Template Record
An Options Template Record is a Template Record that
defines the structure and interpretation of fields in a
Data Record, including defining how to scope the
applicability of the Data Record.
IPFIX Message
An IPFIX Message is a message originating at the Exporting
Process that carries the IPFIX records of this Exporting
Process and whose destination is a Collecting Process. An
IPFIX Message is encapsulated at the transport layer.
Message Header
The Message Header is the first part of an IPFIX Message,
which provides basic information about the message such as
the IPFIX version, length of the message, message sequence
number, etc.
Set
Set is a generic term for a collection of records that have
a similar structure. In an IPFIX Message, one or more Sets
follow the Message Header.
<Claise, et. Al> Expires October 30, 2007 [Page 6]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
There are three different types of Sets: Template Set,
Options Template Set, and Data Set.
Template Set
A Template Set is a collection of one or more Template
Records that have been grouped together in an IPFIX
Message.
Options Template Set
An Options Template Set is a collection of one or more
Options Template Records that have been grouped together
in an IPFIX Message.
Data Set
A Data Set is one or more Data Records, of the same type,
that are grouped together in an IPFIX Message. Each Data
Record is previously defined by a Template Record or an
Options Template Record.
Information Element
An Information Element is a protocol and encoding
independent description of an attribute which may appear in
an IPFIX Record. The IPFIX information model [IPFIX-INFO]
defines the base set of Information Elements for IPFIX.
The type associated with an Information Element indicates
constraints on what it may contain and also determines the
valid encoding mechanisms for use in IPFIX.
<Claise, et. Al> Expires October 30, 2007 [Page 7]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
3.1. Terminology Summary Table
+------------------+---------------------------------------------+
| | contents |
| +--------------------+------------------------+
| Set | Template | record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+
Figure A: Terminology Summary Table
A Data Set is composed of Data Record(s). No Template Record is
included. A Template Record or an Options Template Record
defines the Data Record.
A Template Set contains only Template Record(s).
An Options Template Set contains only Options Template
Record(s).
4. High Level View of the Proposal and Advantages
Each (Options) Template and its associated Data Records would be
sent on a unique SCTP stream. The (Options) Template would still
be sent reliably, while the level of reliability for the Data
Records would be chosen depending on the specific application.
4.1. Advantage 1: Transmission Order
The first issue with the IPFIX specifications in [IPFIX-PROTO]
concerns ordered transmission: a Template could be blocked
pending reliable transmission on stream zero, while the
associated Data Records could already have been transmitted in
an unreliable message on another stream. Since the Collecting
Process can't decode the Data Records without the associated
Template, they will most probably be discarded.
<Claise, et. Al> Expires October 30, 2007 [Page 8]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
Even if the Data Records are sent reliably, the IPFIX protocol
imposes that the Data Sets MUST NOT be sent on stream zero. As
a consequence, due to different congestion in different streams,
the Data Records might arrive before the associated (Options)
Template Record. Again, since the Collecting Process can't
decode these Data Records without the associated (Options)
Template, they will most probably be discarded.
4.2. Advantage 2: Data Record Loss per Template
The second issue with the IPFIX specifications in [IPFIX-PROTO]
is that, as we can only know how much data was lost per stream,
if multiple Data Records associated with different Templates are
sent in one SCTP stream, there's no way of knowing how much data
was lost for Data Records defined by a specific Template. It's
especially important to know how many Data Records are lost in
case of billing. By using an unique SCTP stream to export all
the Data Records associated with a single Template ID, the loss
pertaining to a specific Template ID can be deduced from the
SCTP stream loss information.
4.3. Advantage 3: Easier Job for the Collecting Process
The third advantage is that the Collecting Process's job is now
easier. [IPFIX-PROTO] specifies : "If the Template Records have
not been received at the time Data Records are received, the
Collecting Process MAY store the Data Records for a short period
of time and decode them after the Template Records are
received". With the new specifications in this document, the
Collecting Process doesn't have the store the Data Records while
waiting for the Template Records, as the transmission order is
guaranteed.
5. Specifications
This document is based on the specifications in [IPFIX-PROTO].
However, it only applies to the PR-SCTP transport protocol. All
specifications from [IPFIX-PROTO] applies unless specified
otherwise in this document.
5.1. Template Management
<Claise, et. Al> Expires October 30, 2007 [Page 9]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
This refers to the Template Management section 8 in [IPFIX-
PROTO].
While [IPFIX-PROTO] imposes that Template Sets and Options
Template Sets SHOULD be sent on the SCTP stream zero, this
document specifies that the Template Sets and Options Template
Sets SHOULD be sent on the same unique stream as their
associated Data Sets. Template Sets and Options Template Sets
MUST be sent reliably. In other words, any IPFIX Message
containing a (Options) Template Set MUST be sent reliably. As
such, the Collecting Process MUST store the Template Record
information for the duration of the association so that it can
interpret the corresponding Data Records that are received in
subsequent Data Sets until the Template is deleted with a
Template Withdrawal Message.
If an Options Template is necessary to understand the content of
a Data Record (i.e. the scope in the Options Template Record is
an Information Element contained in the Data Record), then the
Options Template Record and associated Data Records MAY be sent
in the same stream. The Data Records associated with the Options
Template SHOULD be sent reliably. A typical example is the
export of the redundancy draft information [IPFIX-RED-RED], or
the export of the sampling rate.
The Exporting Process MUST transmit the Template Set and Options
Template Set in advance of any Data Sets that use that (Options)
Template ID. The Exporting Process MAY transmit the Template
Set and Options Template Set in advance of any Data Sets that
use that (Options) Template ID., to help ensure that the
Collector has the Template Record before receiving the first
Data Record. Data Records that correspond to a Template Record
MAY appear in the same and/or subsequent IPFIX Message(s).
+--------+ +----------+ +----------+
| | | | | |
stream 10 ----| Data | . . . | Data |---| Template |---->
| 256 | | 256 | | 256 |
| PR| | PR| | FR|
+--------+ +----------+ +----------+
Figure 1
The figure 1 display an example where the stream 10 carries a
Template with the Template ID 256 transmitted with full
reliability (FR), together with associated Data Records
<Claise, et. Al> Expires October 30, 2007 [Page 10]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
transmitted with partial reliabilty (PR).
+----------+ +----------+
| | | Options |
stream 20 ... -------| Data |-------| Template |------>
| 257 | | 257 |
| PR| | FR|
+----------+ +----------+
Figure 2
The figure 2 display an example where the stream 20 carries an
Options Template with the Template ID 257 transmitted with full
reliability (FR), together with an associated Data Record
transmitted with partial reliabilty (PR). In this example the
Option Template contains system meta information which is not
directly related to specific Data Records.
+--------+ +----------+ +----------+
| | | | | |
stream 30 ... ---| Data |...| Data |-----| Template |---
| 259 | | 259 | | 259 |
| PR| | PR| | FR|
+--------+ +----------+ +----------+
+----------+ +----------+
| | | Options |
---| Data |-------| Template |------>
| 258 | | 258 |
| FR| | FR|
+----------+ +----------+
Figure 3
The figure 3 display an example where tream 30 carries an
Options Template with Template ID 258 transmitted with full
reliability (FR), an associated Data Record transmitted with
full reliability (FR), a Template with Template ID 259
transmitted with full reliability (FR), and associated Data
Records transmitted with partial reliability. In this example
the Option contains information required to decode the latter
Data Records, such as Common Properties information [IPFIX-RED-
RED].
The Templates that are not used anymore SHOULD be deleted.
Before reusing a Template ID, the Template MUST be deleted. In
order to delete an allocated Template, the Template is withdrawn
<Claise, et. Al> Expires October 30, 2007 [Page 11]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
through the use of a Template Withdrawal Message. The Template
Withdrawal Message MUST be sent in the stream that carries the
Template ID to be removed. After the Template Withdrawal Message
is sent, the Exporting Process SHOULD reset the SCTP stream
sequence number to 0 according to [SCTP-RESET] if there are no
other Template Record sent on that stream and if the stream is
not the stream zero.
The Template Withdrawal Message MUST be sent reliably. The SCTP
stream MUST be ordered so that the reliable IPFIX Message
containing the Template Withdrawal Message would not be sent
before associated Data Records.
The Template ID from a withdrawn Template MAY be reused directly
after the Template Withdrawal Message at the condition that the
same stream is reused. If a different stream is reused, the
Template ID from a withdrawn Template MUST NOT be reused until
sufficient time has elapsed to allow for the Collecting Process
to receive and process the Template withdrawal message.
A Template Withdrawal Message to withdraw all Templates for the
Observation Domain ID specified in the IPFIX Message header MAY
be used. Refer to "All Data Templates Withdrawal Message" in
[IPFIX-PROTO]. The Template Withdrawal Message to withdraw all
Templates for the Observation Domain ID MUST be sent reliably on
the stream 0. After a Template Withdrawal Message to withdraw
all Templates, Template MUST NOT be reused until sufficient time
has elapsed to allow for the Collecting Process to receive and
process the Template withdrawal message.
If the measurement parameters change, the Template MUST be
withdrawn (using a Template Withdrawal Message and a new
Template definition) or an unused Template ID MUST be used.
Examples of the measurement changes are: a new sampling rate, a
new flow expiration process, a new filtering definition, etc. If
a Template is changed, a Template Withdrawal Message MUST be
sent to delete the Template.
If the Metering Process restarts, the Exporting Process MUST
reuse the previously assigned Template ID for each Template and
it MUST reuse the corresponding previously assigned stream for
each Template ID. Alternatively, it MUST withdraw the previously
issued Template IDs by sending Template Withdrawal Message(s)
before reusing them. It can then use any available stream for
the Template ID.
<Claise, et. Al> Expires October 30, 2007 [Page 12]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
5.2. The Collecting Process's Side
This refers to the Collecting Process's Side section 9 in
[IPFIX-PROTO].
The Collecting Process SHOULD listen for a new association
request from the Exporting Process. The Exporting Process will
request a number of streams to use for export: the number of
streams SHOULD be equivalent to the number of simultaneous
Template ID used in the association. A Collecting Process MUST
support at least 2 inbound streams per association.
If the Collecting Process receives a malformed IPFIX Message, it
MUST reset the SCTP association, discard the IPFIX Message, and
SHOULD log the error.
Template Sets and Options Template Sets are only sent once. The
Collecting Process MUST store the Template Record information
for the duration of the association so that it can interpret the
corresponding Data Records that are received in subsequent Data
Sets.
If the Collecting Process receives a Template Withdrawal Message
on a different stream than the one on which the Template is
sent, then the Collecting Process MUST shutdown the association.
The only exception is the "All Data Templates Withdrawal
Message" sent reliably on the stream zero.
Template IDs are unique per SCTP association and per Observation
Domain. If the Collecting Process receives a Template which has
already been received but which has not previously been
withdrawn (i.e. a Template Record from the same Exporter
Observation Domain with the same Template ID received on the
SCTP association), then the Collecting Process MUST shutdown the
association.
When an SCTP association is closed, the Collecting Process MUST
discard all Templates received over that association and stop
decoding IPFIX Messages that use those Templates.
The Collecting Process normally receives Template Records from
the Exporting Process before receiving Data Records. The Data
Records are then decoded and stored by the Collector. If the
Template Records have not been received at the time Data Records
are received, the Collecting Process MUST shutdown the SCTP
assocation. A Collecting Process MUST NOT assume that the Data
<Claise, et. Al> Expires October 30, 2007 [Page 13]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
Set and the associated Template Set (or Options Template Set)
are exported in the same IPFIX Message.
The IPFIX protocol has a Sequence Number field in the Export
header which increases with the number of IPFIX Data Records in
the IPFIX Message. A Collector may detect out of sequence,
dropped, or duplicate IPFIX Messages by tracking the Sequence
Number. As this Sequence Number per SCTP stream, the loss per
Template ID can be calculated in case of unreliable or
partially-reliable export.
A collector SHOULD provide a logging mechanism for tracking out
of sequence IPFIX Messages. Such out of sequence IPFIX Messages
may be due to Exporter resource exhaustion where it can not
transmit messages at their creation rate, an Exporting Process
reset, congestion on the network link between the Exporter and
Collector, Collector resource exhaustion where it can not
process the IPFIX Messages at their arrival rate, out of order
packet reception, duplicate packet reception, or an attacker
injecting false messages.
If a Collecting Process receives a Template Withdrawal Message,
the Collecting Process MUST delete the corresponding Template
Records associated with the specific SCTP association and
specific Observation Domain, and stop decoding IPFIX Messages
that use the withdrawn Templates.
5.3. PR-SCTP
This refers to the "SCTP" section 10.2 (and subsections) in
[IPFIX-PROTO]. More specifically the "Stream" section 10.2.4.3
PR-SCTP [RFC3758] MUST be implemented by all compliant
implementations.
An Exporting Process MUST request at least two outbound streams
per association. The Exporting Process SHOULD request as many
SCTP streams as the number of foreseen concurrent Templates.
The first stream (referred to as stream zero in the rest of this
document), is used to send the Template Withdrawal Message to
remove all the Templates. Data Sets MUST NOT be sent on stream
zero. The stream 1 MUST be the last stream used. Even if the
stream 1 already exports Template Set, Options Template Set,
and/or Data Set, the stream 1 MUST be used to export newly
created Template ID and its associated Data Records in case
there is no new unique stream in SCTP to use.
<Claise, et. Al> Expires October 30, 2007 [Page 14]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
Depending on the application requirement, the Exporting Process
selects the mode (unreliable, partially reliable, or fully
reliable) of the SCTP messages, used to send the Data Sets.
Unreliable mode MAY be used where the application does not
require reliable transmission and the use of a retransmission
queue is impractical.
An Exporter uses multiple streams to export Data Sets. In such
a case, the Observation Domain MUST use the same Observation
Domain ID value on all of the streams it uses.
All IPFIX Message MUST be sent in order within a stream.
6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
The same security considerations as for the IPFIX Protocol
[IPFIX-PROTO] apply.
8. References
8.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., Conrad,
P., "Stream Control Transmission Protocol (SCTP),
Partial Reliability Extension", May 2004
[IPFIX-PROTO] B. Claise et Al, IPFIX Protocol Specification,
<draft-ietf-ipfix-protocol-24.txt>, Internet-Draft work
in progress, June 2006
[PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F.
Raspall, "Sampling and Filtering Techniques for IP
Packet Selection" draft-ietf-psamp-sample-tech-07.txt,
Internet-Draft work in progress, Juillet 2005
<Claise, et. Al> Expires October 30, 2007 [Page 15]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
[SCTP-RESET] Stewart, R., Lei, P., Tuexen, M, "Stream Control
Transmission Protocol (SCTP) Stream Reset", draft-
stewart-sctpstrrst-04.txt, Internet-Draft work in
progress, January 2007.
8.2. Informative References
[RFC3917] Quittek, J., Zseby, T., Claise, B. Zander, S,
Requirements for IP Flow Information Export, RFC 3917,
October 2004
[IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek,
J., "Architecture Model for IP Flow Information Export"
draft-ietf-ipfix-architecture-12, Internet-Draft work
in progress, September 2006
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B.,
"IPFIX Applicability", draft-ietf-ipfix-as-11.txt,
Internet-Draft work in progress, May 2005
[IPFIX-INFO] J. Quittek, S. Bryant, B. Claise, J. Meyer,
Information Model for IP Flow Information Export,
<draft-ietf-ipfix-info-15.txt>, Internet-draft work in
progress, June 2006
[PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise,
"Information Model for Packet Sampling Exports", draft-
ietf-psamp-info-05.txt, Internet-Draft work in
progress,
[PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet
Sampling (PSAMP) Protocol Specifications", draft-ietf-
psamp-protocol-07, Internet-Draft work in progress,
October 2006.
[PSAMP-FMWK] D. Chiou, B. Claise, N. Duffield, A. Greenberg, M.
Grossglauser, P. Marimuthu, J. Rexford, G. Sadasivan,
"A Framework for Passive Packet Measurement" draft-
ietf-psamp-framework-10.txt, Internet-Draft work in
progress, January 2005
[IPFIX-RED-RED] Boschi, E., Mark, L., Claise, B. "Reducing
Redundancy in IPFIX and PSAMP Reports", Internet-Draft
work in progress, February, 2007
<Claise, et. Al> Expires October 30, 2007 [Page 16]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
[PSAMP-MIB] Dietz, T., Claise, B. "Definitions of Managed
Objects for Packet Sampling", Internet-Draft work in
progress, June 2006
9. Acknowledgements
The authors would like to thank Gerhard Muenz, Randall Stewart,
and Peter Lei.
10. Author's Addresses
Benoit Claise
Cisco Systems Inc.
De Kleetlaan 6a b1
Diegem 1813
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Andrew Johnson
Cisco Systems (Scotland) Ltd.
96 Commercial Quay
Commercial Street
Edinburgh, EH6 6LX, United Kingdom
Phone: +44 131 561 3641
Email: andrjohn@cisco.com
Paul Aitken
Cisco Systems (Scotland) Ltd.
96 Commercial Quay
Commercial Street
Edinburgh, EH6 6LX, United Kingdom
Phone: +44 131 561 3616
Email: paitken@cisco.com
11. Intellectual Property Statement
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
<Claise, et. Al> Expires October 30, 2007 [Page 17]
Internet-Draft <IPFIX Export per SCTP Stream> April 2007
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.
12. Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
13. Disclaimer
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,
THE IETF TRUST 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.
<Claise, et. Al> Expires October 30, 2007 [Page 18]