IPFIX Working Group B. Claise
Internet-Draft P. Aitken
Intended Status: Informational A. Johnson
Expires: January 1, 2009 Cisco Systems, Inc.
G. Muenz
University of Tuebingen
July 1, 2008
IPFIX Export per SCTP Stream
draft-ietf-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, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
<Claise, et. Al> Expires January 1, 2009 [Page 1]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
Abstract
This document specifies an improvement to the use of SCTP
as specified in the IPFIX specifications in order to be
able to deduce the Data Record loss per Template Record in
case of partially-reliable SCTP export. This specification
offers several extra advantages: immediate export of the
Template Withdrawal Message, immediate reuse of Template ID
within a stream, 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. Terminology.................................................4
1.1. IPFIX Documents Overview...............................4
1.2. PSAMP Documents Overview...............................4
2. Introduction................................................5
2.1. Relationship with IPFIX and PSAMP......................6
2.2. Applicability..........................................6
2.3. Limitations............................................7
3. IPFIX Protocol Specifications Limitations and
Improvements...................................................7
3.1. Data Record Loss per Template..........................7
3.1.1. IPFIX Protocol Specifications Limitation..........7
3.1.2. IPFIX Export per SCTP Stream Advantage............8
3.2. Transmission Order within a Stream.....................8
3.2.1. IPFIX Protocol Specifications Limitation..........8
3.2.2. IPFIX Export per SCTP Stream Advantages...........9
3.3. No Transmission Order across SCTP Streams.............10
3.3.1. IPFIX Protocol Specifications Limitation.........10
3.3.2. IPFIX Export per SCTP Stream Advantages..........10
4. Specifications.............................................10
4.1. Template Management...................................10
4.2. New Information Element...............................12
4.3. SCTP..................................................12
4.4. Template Withdrawal Message...........................13
4.5. The Collecting Process's Side.........................13
<Claise, et. Al> Expires January 1, 2009 [Page 2]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
5. Examples...................................................14
6. IANA Considerations........................................16
7. Security Considerations....................................16
8. References.................................................17
8.1. Normative References..................................17
8.2. Informative References................................17
9. Acknowledgements...........................................18
10. Author's Addresses........................................19
11. Intellectual Property Statement...........................20
12. Copyright Statement.......................................20
13. Disclaimer................................................20
<Claise, et. Al> Expires January 1, 2009 [Page 3]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
1. Terminology
IPFIX-specific terminology used in this document is defined
in section 2 of [RFC5101]. As in [RFC5101], these IPFIX-
specific terms have the first letter of a word capitalized
when used in this document.
Template Reuse Delay
The configurable timeout to allow the Collecting Process
to receive and process the last Data Record using this
Template information before which the Template Withdrawal
Message MUST NOT be sent. [RFC5101] specifies a default
value of 5 seconds.
1.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 [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 [RFC5102].
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.
1.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
<Claise, et. Al> Expires January 1, 2009 [Page 4]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
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.
2. Introduction
The IPFIX working group has specified a protocol to export IP
Flow information [RFC5101]. 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 relevant Information Element is
specified in the IPFIX Information Model [RFC5102],
registered with IANA, or specified as an enterprise-specific
Information Element.
The IPFIX protocol [RFC5101] 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 the data format for the Information
Elements in a Flow. The Data Records specify values for each
Flow.
The IPFIX protocol [RFC5101] is flexible: it foresees the usage
of the multiple SCTP streams per association; it allows the
transmission of Data Sets, Template Sets, and/or Options
Template Sets on any stream; it offers the full or partial
reliability export of Data Sets; it proposes the ordered or out-
of-order delivery of Data Sets. However, due to bandwidth
<Claise, et. Al> Expires January 1, 2009 [Page 5]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
restrictions and packet losses in the network as well as
resource constraints on the Exporter and Collector (e.g.,
limited buffer sizes), it is not always possible to export all
Data Sets in a reliable way.
Without delving into the details of the specifications described
later on in this document, the basic idea is to export the
Template Record and its associated Data Sets into a single
unique SCTP stream, ideally to limit the Template ID to a single
stream, while imposing in-order transmission.
The specification in this document offers several advantages
such as: calculation of Data Record losses in case of partially-
reliable SCTP export, immediate export of the Template
Withdrawal Message, immediate reuse of template ID within a
stream, reduced likelihood of losing Data Record, and the
Collecting Process's job is easier.
2.1. Relationship with IPFIX and PSAMP
The specification in this document applies to the IPFIX
protocol specifications [RFC5101]. However, it only applies
to the SCTP transport protocol [RFC4960] option of the IPFIX
protocol specifications, specifically in the case of the
partial reliability extension [RFC3758]. All specifications
from [RFC5101] apply unless specified otherwise in this
document.
As the Packet Sampling (PSAMP) protocol specifications
[PSAMP-PROTO] are based on the IPFIX protocol specifications,
the specifications in this document are also valid for the
PSAMP protocol. Therefore, the advantages specified by this
document also apply to PSAMP.
2.2. Applicability
The specifications are required in cases where we must know how
many Data Records of a certain type (i.e. from a certain
Template ID) were lost. Furthermore, they apply in cases where
the Exporter can not afford to export all the Flow Records
reliably, due to the limited resources to buffer the huge amount
of flow records. Such situations may occur if Data Sets are
generated at a higher rate at the Exporter than can be
transferred to the Collector because of bandwidth limitations in
<Claise, et. Al> Expires January 1, 2009 [Page 6]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
the network or slow reception at the Collector. A typically
example is a router exporting billing records.
To be more precise, the specification applicability is the case
where multiple Template IDs are sent within a SCTP Transport
Session and the calculation of the Data Record loss for a
particular one Template ID is required. Indeed, with the
current IPFIX specifications [RFC5101], if an IPFIX Message is
lost (UDP or SCTP partially reliable), it is not possible to
determine to which Template ID of the Transport Session the lost
Data Records belong to.
In terms of Collector, there is backwards compatibility: the
Collecting Process does not require any changes to support an
Exporter that complies to the specifications in this document.
2.3. Limitations
To be compliant with the specifications in this document, the
Transport Session must support multiple SCTP streams.
Furthermore, if the SCTP Transport Session does not support
enough streams for the increasing number of Template ID in the
Transport Session, the addition of streams must be supported
according to [SCTP-RESET]. Alternatively, the new Template ID
and associated Data Records may be added to an existing stream
at the cost of diluting the granularity of Data Records loss.
The other alternatives, which is not practical in operational
networks, is to restart the SCTP association with an increase
number of streams.
3. IPFIX Protocol Specifications Limitations and Improvements
3.1. Data Record Loss per Template
3.1.1. IPFIX Protocol Specifications Limitation
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.
However, in some cases, it may be important to know how many
Data Records of a certain type were lost (e.g., in the case
of billing), but conventionally IPFIX does not provide this
information.
<Claise, et. Al> Expires January 1, 2009 [Page 7]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
A Collector can detect out-of-sequence, dropped, or duplicate
IPFIX Messages by tracking the Sequence Number [RFC5101].
Note that the Sequence Number field in the Export header
increases with the number of IPFIX Data Records within the
PR-SCTP stream.
The IPFIX protocol specification [RFC5101] specifies that Data
Records associated with any Template ID may be sent on any SCTP
stream. As such, if there is more than one Template IDs defined
within the whole SCTP association then there is no way of
knowing which Template ID any lost Data Records are associated
with. This is true, no matter what convention the Exporting
Process uses to send Data Records on different SCTP streams, as
the protocol makes no guarantees.
Using the specification in this document, it is guaranteed that
any lost Data Records will be associated only with the Templates
that are defined on that stream and by defining only one
Template on a stream it is ensured that any loss is associated
with that single Template.
3.1.2. IPFIX Export per SCTP Stream Advantage
By exporting each Template ID and the corresponding Data Records
within a different stream, the loss pertaining to each specific
Template ID can be deduced from the Sequence Number field in the
IPFIX Message headers.
3.2. Transmission Order within a Stream
3.2.1. IPFIX Protocol Specifications Limitation
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. The IPFIX protocol
specification foresees:
"The Exporting Process SHOULD 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.",
<Claise, et. Al> Expires January 1, 2009 [Page 8]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
The fact that the Collecting Process cannot decode the Data
Records without the Template Record may result in the Data
Records being discarded by the Collector, as specified in
[RFC5101]:
"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 MAY store the Data Records for a short period of
time and decode them after the Template Records are
received."
In practice, Data Records without associated (Options)
Template Records will probably be discarded by the Collecting
Process.
3.2.2. IPFIX Export per SCTP Stream Advantages
By exporting each Template Record and the corresponding Data
Records within a single stream and imposing in-order
transmission, the Template will always arrive before the
associated Data Records. Therefore, there is no risk that
the Collecting Process discards Data Records while waiting
for the Template to arrive.
Furthermore, when reusing a Template ID within a stream, the
Template Withdrawal Message will be guaranteed to arrive
before the new definition of the Template and therefore the
Template Record may be sent directly after the Template
Withdrawal Message. In other words, the Template Reuse Delay
restriction (by default, 5 seconds, as specified in [RFC5101]
is removed for Template ID reuse within the same stream.
Another advantage with the new specifications in this
document is that the Collecting Process's job is now easier.
Indeed, the Collecting Process doesn't have to store the Data
Records while waiting for the Template Records, as the
transmission order is always guaranteed. This way, extra
reliability of the Data Records is achieved without extra
burden on the Collecting Process.
<Claise, et. Al> Expires January 1, 2009 [Page 9]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
3.3. No Transmission Order across SCTP Streams
3.3.1. IPFIX Protocol Specifications Limitation
The fact that the protocol specifications [RFC5101] are
flexible in terms of stream(s) on which the Template Set,
Options Template Set, and corresponding Data Sets are
exported, implies that the (Options) Template Set might be
exported on a different stream than the corresponding Data
Sets. This might cause Data Record loss in the Collecting
Process as the ordered transmission across SCTP streams is
not guaranteed.
For example, a Template may be blocked pending reliable
transmission on one stream while the associated Data Records
may be transmitted immediately in another stream. Also, due
to different stream congestion, it is possible that even if
the Template and Data Records are both sent reliably, Data
Records sent on a different stream than the associated
Template might still arrive before the associated Template.
3.3.2. IPFIX Export per SCTP Stream Advantages
By exporting each Template Record and the corresponding Data
Records within a single stream, imposing in-order
transmission, and limiting the Template ID to a single
stream, the issue of ordered transmission across multiple
streams is avoided.
By exporting all corresponding Data Records within the same
ordered stream as the Template Definition, each stream is
independent and self-contained and the interaction between
streams is limited to that of Options Data interactions. This
has several advantageous consequences, including the order
preservation that does not result in the blocking of unrelated
data and the Collector's job simplification (as the Template
Records are guaranteed to be delivered before the associated
Data Records).
4. Specifications
4.1. Template Management
This section introduces modifications compared to the Template
Management section 8 in [RFC5101].
<Claise, et. Al> Expires January 1, 2009 [Page 10]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
As specified in [RFC5101], Template Sets and Options Template
Sets MUST be sent reliably. In other words, any IPFIX Message
containing an (Options) Template Set MUST be sent reliably.
Any Data Sets associated with a Template Record MUST be sent on
the same stream on which the Template Record was sent.
The Exporter SHOULD send a single Template and associated Data
Sets within a single stream in order to calculate the potential
Data Record loss for this Template ID. However, the Exporter
MAY group related Templates and their associated Data Sets
within a single stream so loss statistics are calculated for the
group. This may be suitable in cases where there is
insufficient SCTP streams to send each Template on its own
stream and/or the case where there are slight variations on a
single Template to show that some fields were unavailable at the
time of monitoring.
If a SCTP stream contains a mixture of Data Records defined by a
Template Record and Options Template Record(s), the Data Records
defined by the Options Template Record(s) SHOULD be sent
reliably within the same stream so that the Collector does not
consider any loss to be associated with the Options Data.
Indeed, if the Collector does not have the guarantee that the
Data Records defined by the Options Template Record are sent
reliably, the Collector can not determine whether the loss in
that stream belongs to the Data Records defined by the Template
Record, defined by the Option Template Record, or by both of
them. By sending the Options Data reliably (which is usually
required to interpret the Data Records correctly), any loss will
be limited to the non-option Data Record and loss can still be
calculated on a per Template basis.
For each (Options) Template Record, the Exporting Process MUST
send the Data Record Reliability Option Template using an Option
Template with the following Information Elements:
SCOPE: Template ID
NOT-SCOPE: dataRecordsReliability
The Data Record Reliability Option Template MUST be sent
reliably.
<Claise, et. Al> Expires January 1, 2009 [Page 11]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
The Option Data Record SHOULD be sent before the Data Record
that needs it so that it arrives first and is available for the
Collector to use.
4.2. New Information Element
dataRecordsReliability
Description:
The Data Records reliability associated with this
Template ID. The integer value 1 means that the Data
Records are sent reliably, while the integer value 2
means that the Data Records are not sent reliably.
Abstract Data Type: boolean
Data Type Semantics: identifier
ElementId: xxx
Status: current
4.3. SCTP
This section introduces modifications compared to the "SCTP"
section 10.2 (and subsections) in [RFC5101]. More specifically
the "Stream" section 10.2.4.3
PR-SCTP [RFC3758] MUST be implemented by all compliant
implementations.
All IPFIX Messages MUST be sent in order within a stream.
Depending on the application requirement, the Exporting Process
MAY send Data Sets with full or partial reliability. Unreliable
data transfer MAY be used where the application does not require
reliable transmission or the use of a retransmission queue is
impractical due to resource restrictions at the Exporter.
If the Exporting Process requires to export a new Template but
there are no more free SCTP streams available, it SHOULD attempt
to increase the number of outbound streams it is able to send
to, per [SCTP-RESET]. Alternatively, the Exporting Process MAY
add the Template Set and Data Records to an existing stream at
the cost of diluting the granularity of Data Records loss.
<Claise, et. Al> Expires January 1, 2009 [Page 12]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
4.4. Template Withdrawal Message
This section introduces Template Withdrawal Message-related
modifications compared to the Template Management section 8 in
[RFC5101].
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 on the same stream as the
Template Record.
As the Template Withdrawal Message MUST be sent reliably, using
SCTP-ordered delivery per [RFC5101], and as all IPFIX Messages
are sent in order within a stream (per the specifications in
this document), the IPFIX Message containing the Template
Withdrawal Message will not arrive at the Collecting Process
before any associated and previously sent Data Record. As a
consequence, no Data Records will be lost due to delayed arrival
at the Collector.
The Template ID from a withdrawn Template MAY be reused on the
same stream immediately after the Template Withdrawal Message is
sent. This case is equivalent to the use of a Template Reuse
Delay value of 0.
If the new definition of the Template ID is to be reused on a
different stream, the Template Withdrawal Message MUST NOT be
sent before the Template Reuse Delay.
A Template Withdrawal Message to withdraw all Templates for the
Observation Domain ID specified in the IPFIX Message header MUST
NOT be used.
Multiple Template IDs MAY be withdrawn with a single Template
Withdrawal Message at the condition that all the Template IDs in
the Template Withdrawal Message are used on the same SCTP
stream.
4.5. The Collecting Process's Side
This section introduces modifications to the Collection Process
as compared to section 9 in [RFC5101].
<Claise, et. Al> Expires January 1, 2009 [Page 13]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
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 Records used in the association. Note that the Template
Records don't include the Options Template Records.
A Collecting Process SHOULD support the procedure for the
addition of an SCTP stream [SCTP-RESET].
The IPFIX protocol has a Sequence Number field in the IPFIX
Message header that 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 for the Data Records sent in that stream can be
calculated in case of partially-reliable export.
If the Collecting Process receives a Template Withdrawal Message
on a different stream than the one on which the Template ID is
used, then the Collecting Process MUST reset the association and
SHOULD log an error message.
The following sentences from [RFC5101] are not applicable in
this specification:
"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
MAY store the Data Records for a short period of time and
decode them after the Template Records are received."
5. Examples
Figure 1 shows 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
reliability (PR). Note that, because all IPFIX Messages are
sent in order within a stream, the Template 256 will always be
processed before the Data Records by the Collecting Process.
Therefore, the Collecting Process job is simplified.
Furthermore, the Data Record loss for the Template 256 can
easily be calculated on the Collecting Process.
<Claise, et. Al> Expires January 1, 2009 [Page 14]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
+--------+ +---------+ +----------+
| | | | | |
stream 10 ----| Data | . . . | Data |---| Template |--->
| 256 | | 256 | | 256 |
| PR| | PR| | FR|
+--------+ +---------+ +----------+
Figure 1
If an Option 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), the
Options Template Record may be sent in the same stream, as
displayed in figure 2.
+--------+ +--------+ +----------+
| | | | | |
stream 20 ... ---| Data |...| Data |-----| Template |---
| 258 | | 258 | | 258 |
| PR| | PR| | FR|
+--------+ +--------+ +----------+
+--------+ +----------+
| | | Options |
...---| Data |-------| Template |------>
| 257 | | 257 |
| FR| | FR|
+--------+ +----------+
Figure 2
Figure 2 shows an example where stream 20 carries an Options
Template with Template ID 257 transmitted with full reliability
(FR), an associated Data Record transmitted with full
reliability (FR), a Template with Template ID 258 transmitted
with full reliability (FR), and associated Data Records
transmitted with partial reliability (PR). In this example the
Option Template Record contains information required to decode
the latter Data Records, such as Common Properties information
[IPFIX-RED-RED]. So it makes sense to export the Data Sets 257
reliably. If some Data Record loss is observed from the
Sequence Number , the loss can only stem from the Data Sets with
the Template ID 258, as these are the only Sets not exported
reliably. Therefore, the calculation of loss per Template ID
258 is possible.
<Claise, et. Al> Expires January 1, 2009 [Page 15]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
Note that, because all IPFIX Messages must be sent in order
within a stream, the Options Template 257 will always arrive
before its associated Data Records, and that the Template 259
will always arrive before the its associated Data Records.
Figure 3 shows an example where stream 30 carries a Template
with Template ID 259 transmitted with full reliability (FR), an
associated Data Record transmitted with partial reliability
(PR), a Template Withdrawal Message, followed by a redefinition
of the Template ID 259, and finally the new definition of Data
Record transmitted with partial reliability. The Template
Withdrawal Message and the new definition of the Template ID 259
are sent immediately, without waiting for the Template Reuse
Delay.
+--------+ +----------+ +----------+
| | | | | Template |
stream 30 ... ---| Data |...| Template |-----| Withdraw.|---
| 259 | | 259 | | 259 |
| PR| | FR| | FR|
+--------+ +----------+ +----------+
+--------+ +----------+
| | | |
...---| Data |-------| Template |------>
| 259 | | 259 |
| PR| | FR|
+--------+ +----------+
Figure 3
6. IANA Considerations
The dataRecordsReliability Information Element must be requested
from IANA, following the process in [RFC5102].
7. Security Considerations
The same security considerations as for the IPFIX Protocol
[RFC5101] apply.
<Claise, et. Al> Expires January 1, 2009 [Page 16]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
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
[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.
[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
[SCTP-RESET] Stewart, R., Lei, P., Tuexen, M, "Stream Control
Transmission Protocol (SCTP) Stream Reset",
draft-stewart-tsvwg-sctpstrrst-00.txt, Internet-Draft
work in progress, June 2008
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
<Claise, et. Al> Expires January 1, 2009 [Page 17]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B.,
"IPFIX Applicability", draft-ietf-ipfix-as-12.txt,
Internet-Draft work in progress, February 2007
[PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise,
"Information Model for Packet Sampling Exports", draft-
ietf-psamp-info-08.txt, Internet-Draft work in
progress, February 2008
[PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet
Sampling (PSAMP) Protocol Specifications", draft-ietf-
psamp-protocol-09, Internet-Draft work in progress,
December 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
[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 Brian Trammell for his expert
feedback, Randall Stewart and Peter Lei for their SCTP-related
feedback, and Elisa Boschi for her thorough reading.
<Claise, et. Al> Expires January 1, 2009 [Page 18]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
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
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
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
Gerhard Muenz
University of Tuebingen
Computer Networks and Internet
Sand 13
Tuebingen D-72076
DE
Phone: +49 7071 29-70534
Email: muenz@informatik.uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~muenz
<Claise, et. Al> Expires January 1, 2009 [Page 19]
Internet-Draft <IPFIX Export per SCTP Stream> July 2008
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
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 (2008).
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 1, 2009 [Page 20]
