IPFIX Working Group B. Claise
Internet-Draft P. Aitken
Intended Status: Informational A. Johnson
Expires: May 3, 2009 Cisco Systems, Inc.
G. Muenz
TU Muenchen
November 3, 2008
IPFIX Export per SCTP Stream
draft-ietf-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, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
<Claise, et. Al> Expires May 3 2009 [Page 1]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
Abstract
This document specifies an improvement to the PR-SCTP
export specified in the IPFIX specifications in RFC5101.
This method offers several advantages such as the ability to
calculate Data Record losses for PR-SCTP, immediate export of
Template Withdrawal Messages, immediate reuse of Template IDs
within an SCTP stream, and reduced demands on the Collecting
Process.
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.............................................11
4.1. Template Management...................................11
4.2. New Information Element...............................12
4.3. SCTP..................................................13
4.4. Template Withdrawal Message...........................13
4.5. The Collecting Process's Side.........................14
<Claise, et. Al> Expires May 2, 2009 [Page 2]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
5. Examples...................................................15
6. IANA Considerations........................................19
7. Security Considerations....................................19
8. References.................................................19
8.1. Normative References..................................19
8.2. Informative References................................20
9. Acknowledgements...........................................20
10. Author's Addresses........................................21
11. Intellectual Property Statement...........................22
12. Copyright Statement.......................................22
13. Disclaimer................................................22
<Claise, et. Al> Expires May 2, 2009 [Page 3]
Internet-Draft <IPFIX Export per SCTP Stream> November 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 time the Exporting Process MUST wait after sending the
last Data Set described by a given Template before sending a
Template Withdrawal Message for the Template. [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 May 2, 2009 [Page 4]
Internet-Draft <IPFIX Export per SCTP Stream> November 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 May 2, 2009 [Page 5]
Internet-Draft <IPFIX Export per SCTP Stream> November 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.
This document specifies a method for exporting a Template Record
and its associated Data Sets in a single SCTP stream, limiting
each Template ID to a single stream if possible, and imposing
in-order transmission.
This method offers several advantages over IPFIX export as
specified in [RFC5101] such as the ability to calculate Data
Record losses for PR-SCTP, immediate export of Template
Withdrawal Messages, immediate reuse of Template IDs within an
SCTP stream, reduced likelihood of Data Record loss, and reduced
demands on the Collecting Process.
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 method specified by this
document also applies 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) were lost. A typical example is a router exporting
billing records. 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 the network or
slow reception at the Collector.
<Claise, et. Al> Expires May 2, 2009 [Page 6]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
To be more precise, the specification applicability is the case
where multiple Templates are simultaneously active within a
single SCTP Transport Session and the calculation of the Data
Record loss for a particular Template 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 of the Transport Session the lost
Data Records belong to.
Exporting Processes following this specification will
interoperate with existing Collecting Processes that comply with
[RFC5101]; no changes are required at the Collecting Process to
support this method. This document introduces some additional
specifications for the Collection Process specified in
[RFC5101].
2.3. Limitations
This method requires multiple SCTP streams in the association
between the Exporting and Collecting Process, ideally one per
Template. The SCTP association should support the addition of
streams according to [SCTP-RESET] in order to handle the
transmission of additional Templates during the Transport
Session.
3. IPFIX Protocol Specifications Limitations and Improvements
For three specific topics (Data Record Loss per Template,
Transmission Order within a Stream, No Transmission Order across
SCTP Streams), this section explains the IPFIX protocol
specifications limitations on one hand, and the advantages of
the method specified in this document on the other hand.
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
<Claise, et. Al> Expires May 2, 2009 [Page 7]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
Data Records of a certain type were lost (e.g., in the case
of billing), but conventionally IPFIX does not provide this
information.
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 defined by any Template may be sent on any SCTP stream.
As such, if there is more than one Templates defined within the
whole SCTP association then there is no way of knowing which
Template 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.
Note that a workaround allowed by the IPFIX specifications
[RFC5101] is to use only one Template Record per SCTP Transport
Session, at the cost of multiplying the number of SCTP Transport
Sessions when multiple Template Records are required.
3.1.2. IPFIX Export per SCTP Stream Advantage
By exporting each Template and the corresponding Data Records
within a different stream, the loss pertaining to each specific
Template 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:
<Claise, et. Al> Expires May 2, 2009 [Page 8]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
"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.",
The fact that the Collecting Process cannot decode the Data
Records without the corresponding 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 Record 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 Record 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 reduces the load on the Collecting Process. Indeed,
the Collecting Process doesn't have to store the Data Records
while waiting for the Template Records, as the transmission
<Claise, et. Al> Expires May 2, 2009 [Page 9]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
order is always guaranteed. This way, extra reliability of
the Data Records is achieved without extra burden on the
Collecting Process.
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 Record may be blocked pending
reliable transmission on one stream while the corresponding
Data Records may be transmitted immediately in another
stream. Also, due to different stream congestion, it is
possible that even if the Template Record and corresponding
Data Records are sent reliably, Data Records sent on a
different stream than the Template Record might still arrive
before the Template Record.
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 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 Record, each stream is
independent and self-contained and the interaction between
streams is limited to that of options Data Record interactions.
This has several advantageous consequences, including the order
preservation that does not result in the blocking of unrelated
data and load reduction on the Collecting Process (as the
Template Records are guaranteed to be delivered before the
associated Data Records, there is no need for buffering of Data
Sets with missing Templates).
<Claise, et. Al> Expires May 2, 2009 [Page 10]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
4. Specifications
This section introduces improvements compared to the IPFIX
specifications in [RFC5101]. These new specifications, which
are more specific compared to [RFC5101], are descried with the
key words described in [RFC2119].
4.1. Template Management
This section introduces some more additional specifications
compared to the Template Management section 8 in [RFC5101].
As specified in [RFC5101], Template Sets and Options Template
Sets 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 corresponding
Data Sets within a single stream in order to enable calculation
of the potential Data Record loss for this Template. However,
the Exporter MAY group related (Options) Templates and their
corresponding Data Sets within a single stream so that loss
statistics are calculated for the group. This is suitable in
cases where there are only slight variations among the Templates
in a group, e.g. the omission of unavailable fields for export
efficiency, and may be necessary if the SCTP association does
not support enough streams to export each Template in its own
stream.
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
Records. Indeed, if the Collector does not have the guarantee
that the options Data 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 (option Data Records), or by both of
them. By sending the options Data Record 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.
<Claise, et. Al> Expires May 2, 2009 [Page 11]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
The Data Record Reliability Option Template is used to guarantee
to the Collector that the Data Records are sent reliably. In
every SCTP stream, the Exporting Process MUST send a Data Record
defined by the Data Record Reliability Option Template for every
Template and every Option Template used on this stream (i.e.,
for which Data Records are exported on this stream). The Data
Record Reliability Option Template contains the following
Information Elements:
SCOPE: Template ID
NOT-SCOPE: dataRecordsReliability
The Data Record defined by the Data Record Reliability Option
Template MUST be sent reliably. When the Data Record
Reliability Option Template and associated Data Records are sent
in the same SCTP stream, the first associated Data Record can
follow the Data Record Reliability Option Template immediately.
When the Data Record Reliability Option Template and associated
Data Records are sent in different SCTP streams, the Exporting
Process SHOULD transmit the Data Record Reliability Option
Template in advance of any Data Sets that use this Option
Template, to help ensure that the Collector has the Option
Template Record before receiving the first Data Record.
4.2. New Information Element
dataRecordsReliability
Description:
The Data Records reliability associated with this
Template ID. The true value means that the Data Records
are sent reliably, while the false value means that the
Data Records are not sent reliably.
Abstract Data Type: boolean
Data Type Semantics: identifier
ElementId: xxx
Status: current
<Claise, et. Al> Expires May 2, 2009 [Page 12]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
4.3. SCTP
This section introduces some more specific specifications
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.
As specified in [RFC5101], depending on the requirements of the
application, 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
Record 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. The other alternative, which is not practical in
operational networks, is to restart the SCTP association with an
increase number of streams.
4.4. Template Withdrawal Message
This section introduces some more specific Template Withdrawal
Message-related specifications compared to [RFC5101].
As specified 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
<Claise, et. Al> Expires May 2, 2009 [Page 13]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
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.
After the new definition of the Template ID, the Exporting
Process MUST send the Data Record Reliability Option Template to
specify the reliability level of its corresponding Data Records.
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 some more specific specifications to the
Collection Process compared to section 9 in [RFC5101]. However,
the new specifications are backwards compatible with RFC5101-
compliant Collecting Processes.
As specified in [RFC5101], 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 requested streams SHOULD be equivalent to the
number of simultaneous Template Records used in the association.
A Collecting Process SHOULD support the procedure for the
addition of an SCTP stream [SCTP-RESET].
<Claise, et. Al> Expires May 2, 2009 [Page 14]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
As specified in [RFC5101], 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.
When one or more sequential IPFIX Messages are considered lost,
the number of lost Data Records is equal to the Sequence Number
of the first IPFIX Message Header following the lost packets
(S2) minus the Sequence Number of the first lost IPFIX Message
(S1). The Sequence Number of the first lost IPFIX Message can
be calculated as the Sequence Number of the last IPFIX Message
before the sequence of lost IPFIX Messages (S0) plus the number
of Data Records in that IPFIX Message (N0).
S1 = S0 + N0
loss = S2 - S1 = S2 - (S0 + N0)
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 is
used, then the Collecting Process SHOULD log an error message.
The Collector can assume that the Exporter Transport Session
supports the specifications in this document if it receives in
every stream Data Records defined by the Data Record Reliability
Option Template for all Templates used in this stream.
5. Examples
Figure 1 shows an example where the stream 10 carries a Template
Record with the Template ID 256 transmitted with full
reliability (FR), together with associated Data Records
transmitted with partial reliability (PR). The Data Record
Reliability Option Template with Template ID 257 is transmitted
with full reliability (FR). Its corresponding Data Set contains
two Data Records.
Record 1:
o SCOPE: Template ID = 257
o NOT-SCOPE: dataRecordsReliability = True
Record 2:
o SCOPE: Template ID = 256
<Claise, et. Al> Expires May 2, 2009 [Page 15]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
o NOT-SCOPE: dataRecordsReliability = False
+--------+ +---------+ +--------+
| | | | | |
stream 10 ----| Data | . . . | Data |---| Data |---...
| 256 | | 256 | | 257 |
| PR| | PR| | FR|
+--------+ +---------+ +--------+
+----------+ +----------+
| | | Options |
| | | Reliabil.|
...---| Template |-------| Template |------>
| 256 | | 257 |
| FR| | FR|
+----------+ +----------+
Figure 1
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.
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 should be sent in the same stream, as
displayed in figure 2.
+--------+ +--------+ +--------+
| | | | | |
stream 20 ----| Data |...| Data |-----| Data |--- ...
| 260 | | 260 | | 259 |
| PR| | PR| | FR|
+--------+ +--------+ +--------+
+--------+ +----------+
<Claise, et. Al> Expires May 2, 2009 [Page 16]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
| | | |
...---| Data |-------| Template |---...
| 258 | | 260 |
| FR| | FR|
+--------+ +----------+
+----------+ +----------+
| Options | | Options |
| Template | | Reliabil.|
...---| |-------| Template |------>
| 259 | | 258 |
| FR| | FR|
+----------+ +----------+
Figure 2
Figure 2 shows an example where stream 20 carries:
- the Data Record Reliability Option Template with Template ID
258, transmitted with full reliability (FR)
- an Options Template Record with Template ID 259 transmitted
with full reliability. This Options Template Record contains
additional information related to the subsequent Data Records
based on Template ID 260. Typical examples are the Common
Properties information [IPFIX-RED-RED] or a selector report
interpretation [PSAMP-PROTO].
- the Template Record with Template ID 260, transmitted with
full reliability, along with the associated Data Records
transmitted with partial reliability (PR).
- the Data Set specified by the Reliability Option Template
with Template ID 258 transmitted with full reliability.
The Data Set contains three Data Records.
Record 1:
o SCOPE: Template ID = 258
o NOT-SCOPE: dataRecordsReliability = True
Record 2:
o SCOPE: Template ID = 259
o NOT-SCOPE: dataRecordsReliability = True
Record 3:
o SCOPE: Template ID = 260
o NOT-SCOPE: dataRecordsReliability = False
These Data Records indicate to the Collector that the Data
Records for Template ID 258 and 259 are sent reliably, while
the Data Records for Template ID 260 are not.
<Claise, et. Al> Expires May 2, 2009 [Page 17]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
- the Data Record specified by Template ID 259, transmitted
with full reliability
- the Data Record specified by Template ID 260, transmitted
with partial reliability
If the Collector observes some Data Record loss from the
Sequence Number, the loss can only stem from the Data Sets with
the Template ID 260, as these are the only Sets not exported
reliably. Therefore, the calculation of loss per Template ID
260 is possible.
Note that, because all IPFIX Messages must be sent in order
within a stream, the Options Template 258, 259, and 260 will
always arrive before their associated Data Records,
respectively.
Figure 3 shows an example where stream 30 carries a Template
Record with Template ID 261 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 261, and finally the new
definition of Data Record transmitted with partial reliability.
The Template Withdrawal Message and the new definition of the
Template ID 261 are sent immediately, without waiting for the
Template Reuse Delay.
+--------+ +----------+ +----------+
| | | | | Template |
stream 30 ... ---| Data |...| Template |-----| Withdraw.|---
| 261 | | 261 | | 261 |
| PR| | FR| | FR|
+--------+ +----------+ +----------+
+--------+ +----------+
| | | |
...---| Data |-------| Template |------>
| 261 | | 261 |
| PR| | FR|
+--------+ +----------+
Figure 3
The Data Record Reliability Option Template is not displayed in
the example in figure 3, but it should be present to indicate
the reliability of the Data Records specified by the newly
specified Template ID 261.
<Claise, et. Al> Expires May 2, 2009 [Page 18]
Internet-Draft <IPFIX Export per SCTP Stream> November 2008
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.
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-11.txt,
Internet-Draft work in progress, July 2008
[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
<Claise, et. Al> Expires May 2, 2009 [Page 19]
Internet-Draft <IPFIX Export per SCTP Stream> November 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
[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-11.txt, Internet-Draft work in
progress, October 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-13.txt, Internet-Draft work in
progress, June 2008
[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, Elisa Boschi for her thorough reading, and Randall
Stewart and Peter Lei for their SCTP-related feedback
<Claise, et. Al> Expires May 2, 2009 [Page 20]
Internet-Draft <IPFIX Export per SCTP Stream> November 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
Technische Universitaet Muenchen
Departement of Informatics - I8
Boltzmannstr. 3
Garching D-85748
DE
Phone: +49 89 289-18008
Email: muenz@net.in.tum.de
URI: http://www.net.in.tum.de/~muenz
<Claise, et. Al> Expires May 2, 2009 [Page 21]
Internet-Draft <IPFIX Export per SCTP Stream> November 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 May 2, 2009 [Page 22]