IPFIX Working Group B. Claise
Internet-Draft A. Johnson
Intended Status: to be discussed P. Aitken
Expires: December 29th, 2007 Cisco Systems, Inc.
June 29th 2007
IPFIX Export per SCTP Stream
draft-claise-ipfix-export-per-sctp-stream-01
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 December 2, 2007 [Page 1]
Internet-Draft <IPFIX Export per SCTP Stream> June 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 7
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 8
4.3. Advantage 3: Easier Job for the Collecting Process 9
5. Specifications 9
5.1. Template Management 9
5.2. PR-SCTP 12
5.3. The Collecting Process's Side 13
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 January 2, 2007 [Page 2]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
1. Open Issues and Action Items for the next draft version
- 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 sent reliably. The Data Records are sent on a different
SCTP stream, for which the reliably level can be chosen.
<Claise, et. Al> Expires January 2, 2007 [Page 3]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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.
The architecture for the export of measured IP flow information
out of an IPFIX exporting process to a collecting process is
<Claise, et. Al> Expires January 2, 2007 [Page 4]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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].
Template
<Claise, et. Al> Expires January 2, 2007 [Page 5]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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.
There are three different types of Sets: Template Set,
Options Template Set, and Data Set.
<Claise, et. Al> Expires January 2, 2007 [Page 6]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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.
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
<Claise, et. Al> Expires January 2, 2007 [Page 7]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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.
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
<Claise, et. Al> Expires January 2, 2007 [Page 8]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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
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.
<Claise, et. Al> Expires January 2, 2007 [Page 9]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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, 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
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
<Claise, et. Al> Expires January 2, 2007 [Page 10]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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 stream 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 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.
<Claise, et. Al> Expires January 2, 2007 [Page 11]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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.
5.2. 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.
<Claise, et. Al> Expires January 2, 2007 [Page 12]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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.
If the Exporting Process requires a new Template to be exported
but there are no more free SCTP streams available, it MAY
increase the number of outbound streams it is able to send to
[SCTP-RESET]. Alternatevily (or if the Collector doesn't
support the procedure for the addition of new SCTP streams),
the stream 1 MUST be used to export newly created Template IDs
and its associated Data Records. In other words, the stream 1
is the only stream that could export multiple Template Sets
and/or Options Template Sets, and associated Data Set. In any
way, the stream 1 MUST be the last stream used.
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.
5.3. 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. A
Collecting process SHOULD support the procedure for the
addition of a SCTP stream [SCTP-RESET].
<Claise, et. Al> Expires January 2, 2007 [Page 13]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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 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 is per SCTP stream, the loss
per Template ID can be calculated in case of unreliable or
partially-reliable export.
<Claise, et. Al> Expires January 2, 2007 [Page 14]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
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.
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-10.txt,
Internet-Draft work in progress, June 2007
<Claise, et. Al> Expires January 2, 2007 [Page 15]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
[SCTP-RESET] Stewart, R., Lei, P., Tuexen, M, "Stream Control
Transmission Protocol (SCTP) Stream Reset", draft-
stewart-sctpstrrst-05.txt, Internet-Draft work in
progress, June 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, February 2007
[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-06.txt, Internet-Draft work in
progress, June 2007
[PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet
Sampling (PSAMP) Protocol Specifications", draft-ietf-
psamp-protocol-08, Internet-Draft work in progress,
June 2007.
[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-12.txt, Internet-Draft work in
progress, June 2007
[IPFIX-RED-RED] Boschi, E., Mark, L., Claise, B. "Reducing
Redundancy in IPFIX and PSAMP Reports", Internet-Draft
work in progress, draft-ietf-ipfix-reducing-
redundancy-04.txt, May 2007
<Claise, et. Al> Expires January 2, 2007 [Page 16]
Internet-Draft <IPFIX Export per SCTP Stream> June 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
<Claise, et. Al> Expires January 2, 2007 [Page 17]
Internet-Draft <IPFIX Export per SCTP Stream> June 2007
technology described in this document or the extent to which
any 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 January 2, 2007 [Page 18]