[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-claise-ipfix-export-per-sctp-stream) 00 01 02 03 04 05 06 07 08 RFC 6526

     IPFIX Working Group                                   B. Claise
     Internet-Draft                                        P. Aitken
     Intended Status: Informational                       A. Johnson
     Expires: January 10, 2010                    Cisco Systems, Inc.
                                                            G. Muenz
                                                         TU Muenchen
                                                       July 10, 2009
    
                      IPFIX Export per SCTP Stream
               draft-ietf-ipfix-export-per-sctp-stream-03
    
    
    Abstract
    
       This document specifies an improvement to the Partial
       Reliability extension of SCTP (PR-SCTP, Partial Reliability
       Stream Control Transmission Protocol) export specified in
       the IP Flow Information Export (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.
    
    
    Status of this Memo
    
       This Internet-Draft is submitted to IETF in full conformance
       with the provisions of BCP 78 and BCP 79.
    
       Internet-Drafts are working documents of the Internet
       Engineering Task Force (IETF), its areas, and its working
       groups.  Note that other groups may also distribute working
       documents as Internet-Drafts.
    
       Internet-Drafts are draft documents valid for a maximum of six
       months and may be updated, replaced, or obsoleted by other
       documents at any time.  It is inappropriate to use Internet-
       Drafts as reference material or to cite them other than as "work
       in progress."
    
       The list of current Internet-Drafts can be accessed at
       http://www.ietf.org/ietf/1id-abstracts.txt
    
       The list of Internet-Draft Shadow Directories can be accessed at
       http://www.ietf.org/shadow.html
    
       This Internet-Draft will expire on January 10th, 2010.
    
    
    Copyright Notice
    
    
    <Claise, et. Al>      Expires January 10, 2010          [Page 1]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       Copyright (c) 2009 IETF Trust and the persons identified as the
       document authors.  All rights reserved.
    
       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents in effect on the date of
       publication of this document (http://trustee.ietf.org/license-
       info).  Please review these documents carefully, as they
       describe your rights and restrictions with respect to this
       document.
    
    
    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.................................................8
          3.1. Data Record Loss per Template...........................8
             3.1.1. IPFIX Protocol Specifications Limitation...........8
             3.1.2. IPFIX Export per SCTP Stream Advantage.............9
          3.2. Transmission Order within a Stream......................9
             3.2.1. IPFIX Protocol Specifications Limitation...........9
             3.2.2. IPFIX Export per SCTP Stream Advantages...........10
          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...........11
       4. Specifications...........................................11
          4.1. Template Management....................................11
          4.2. New Information Element................................13
          4.3. SCTP..................................................13
          4.4. Template Withdrawal Message............................14
          4.5. The Collecting Process's Side..........................15
       5. Performance Impact.......................................16
    
    
    <Claise, et. Al>      Expires January 10, 2010          [Page 2]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       6. Examples.................................................17
       7. IANA Considerations......................................20
       8. Security Considerations...................................20
       9. References...............................................20
          9.1. Normative References...................................20
          9.2. Informative References.................................21
       10. Acknowledgements........................................22
       11. Author's Addresses......................................23
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    <Claise, et. Al>      Expires January 10, 2010          [Page 3]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
    
    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 needs to 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 [RFC5470], per
       the requirements defined in RFC 3917 [RFC3917].
    
       The IPFIX Architecture [RFC5470] specifies how IPFIX Data
       Records and Templates are carried via a congestion-aware
       transport protocol from IPFIX Exporting Processes to IPFIX
       Collecting Processes.
    
       IPFIX has a formal description of IPFIX Information Elements,
       their name, type and additional semantic information, as
       specified in the IPFIX Information Model [RFC5102].
    
       Finally the IPFIX Applicability Statement [RFC5472] describes
       what type of applications can use the IPFIX protocol and how
       they can use the information provided.  It furthermore shows
       how the IPFIX framework relates to other architectures and
       frameworks.
    
    1.2. PSAMP Documents Overview
    
       The document "A Framework for Packet Selection and Reporting"
       [RFC5474], describes the Packet Sampling (PSAMP) framework
       for network elements to select subsets of packets by
    
    
    
    <Claise, et. Al>      Expires January 10, 2010          [Page 4]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       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" [RFC5475].
    
       The PSAMP protocol [RFC5476] 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 [RFC5477].
    
       Finally [PSAMP-MIB] describes the PSAMP Management
       Information Base.
    
    
    2. Introduction
    
       The IPFIX protocol [RFC5101] has the goal of exporting IP
       Flow information.  This protocol is designed to export
       information about IP traffic Flows and related measurement
       data, where a Flow is defined by a set of key attributes
       (e.g. source and destination IP address, source and
       destination port, etc.).  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
       restrictions and packet losses in the network as well as
    
    
    <Claise, et. Al>      Expires January 10, 2010          [Page 5]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       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
       [RFC5476] are based on the IPFIX protocol specifications, the
       specifications in this document are also valid for the PSAMP
       protocol.  Therefore, the method specified by this document
       also applies to PSAMP.
    
    
    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 January 10, 2010          [Page 6]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       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 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
       receive data from an Exporting Process compliant with this
       method. However, in order to benefit, the Collecting Process
       specified in [RFC5101] must implement some additional
       specifications that this document introduces.
    
    
    2.3. Limitations
    
       This method requires multiple SCTP streams in the association
       between the Exporting and Collecting Process, ideally one per
       Template.
    
       In the future, the SCTP association may support the addition of
       streams according to [SCTP-RESET] in order to handle the
       transmission of additional Templates during the Transport
       Session.
    
       The SCTP Stream Reset functionality [SCTP-RESET] provides
       applications the ability to dynamically reset the sequence
       numbering of any existing stream(s) in an association, as well
       as the ability to add new streams to an existing association.  A
       new SCTP chunk type, Stream Reset, along with new SCTP
       parameters to be used in the chunk are defined.  The Stream
       Reset chunk contains one request type parameter, one response
       type parameter, or one of each.  Each parameter contains a
       request and/or response sequence number.  The sequence number is
       used in case of retransmissions.  In the case of the add streams
       functionality as specified in [SCTP-RESET], the Add Streams
       parameter is used for requesting the addition of new streams
       to the association.  When a sender wishes to increase the number
       of outbound streams on the association, it will send a Stream
       Reset chunk with the desired number of streams to be added.  The
       receiver of the chunk will add the requested number of inbound
       streams, if it can satisfy the request, and respond with a
       Stream Reset chunk containing a Stream Reset Response parameter
       indicating a success.  The newly added streams will be appended
    
    
    <Claise, et. Al>      Expires January 10, 2010          [Page 7]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       to the existing inbound stream numbers and initialized as
       starting at stream sequence number zero.  The sender will
       then add the desired number of outbound streams and can begin to
       use the new streams.  If the receiver cannot add the requested
       number of streams, it will respond with a Stream Reset chunk
       with a Stream Reset Response parameter indicating a failure.  In
       this case, no new streams will be added.
    
       The case where no more free SCTP streams are available is
       discussed in further details in the section 4.4.
    
    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
       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
    
    
    
    <Claise, et. Al>      Expires January 10, 2010          [Page 8]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       send Data Records on different SCTP streams, as the protocol
       makes no guarantees.
    
       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
    
       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.  So, 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:
    
          "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
    
    
    <Claise, et. Al>      Expires January 10, 2010          [Page 9]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
          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
       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.
    
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 10]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       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).
    
    
    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.
    
    
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 11]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       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 an 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.
    
       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
    
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 12]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       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
    
    
    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, the
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 13]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       Exporting Process MUST 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 increased number of streams.
       In the future, the Exporting Process may attempt to increase the
       number of outbound streams it is able to send to, per [SCTP-
       RESET].
    
    
    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
       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.
    
    
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 14]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       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.
    
       In the future, a Collecting Process should support the procedure
       for the addition of an SCTP stream [SCTP-RESET].
    
       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)
    
    
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 15]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       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. Performance Impact
    
       What is the performance impact regarding the implementation of
       these specifications compared to the IPFIX protocol [RFC5101]?
    
       Although adding the new SCTP streams requires a message
       exchange, it is more lightweight to set up additional SCTP
       streams than to set up a new SCTP association since the only
       overhead of adding stream(s) to an existing SCTP association is
       the addition of 16-24 more bytes (allocated in the SCTP
       association, a single time), whereas setting up a new SCTP
       association implies more overhead.
    
       In terms of throughput impact, the fact that these
       specifications discourage multiplexing Templates and Data
       Records of different Template IDs may lead to a slightly larger
       IPFIX Message overhead.  If the Data Record rate is low for a
       specific Template (hence a specific SCTP stream), the Exporting
       Process might not be able to fill the IPFIX Messages as fully as
       possible.  In such a situation, there is a potential overhead
       due to additional IPFIX Message headers and SCTP chunk headers.
    
       Finally, with respect to the processing overhead on the
       Exporter, a lot of state information must be stored when a large
       number of SCTP streams are used with an SCTP association.
       However, no comparison of the performance impact of multiple
       streams within an SCTP association versus opening the same
       number of independent SCTP associations are available.
    
    
    
    
    
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 16]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
    6. 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
            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
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 17]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       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|
                        +--------+   +--------+     +--------+
    
                               +--------+       +----------+
                               |        |       |          |
                         ...---| 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 [RFC5473] or a selector report
          interpretation [RFC5476].
       - 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.
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 18]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
          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.
       - 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.
    
    
    
    
    
    
    
    
    
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 19]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
    
    
                        +--------+   +----------+     +----------+
                        |        |   |          |     | 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.
    
    
    7. IANA Considerations
    
       According to the process defined in [RFC5102], IANA will
       allocate the dataRecordsReliability Information element defined
       in Section 4.2. in the IANA IPFIX Information Elements registry.
    
    
    8. Security Considerations
    
       The same security considerations as for the IPFIX Protocol
       [RFC5101] apply.
    
    
    9. References
    
    9.1. Normative References
    
       [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
                Requirement Levels, BCP 14, RFC 2119, March 1997
    
       [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., and P.
                Conrad, "Stream Control Transmission Protocol (SCTP),
                Partial Reliability Extension", May 2004
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 20]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
    
       [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.
    
       [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini S., and
                F. Raspall, "Sampling and Filtering Techniques for IP
                Packet Selection", RFC5475, March 2009
    
    
    
    9.2. Informative References
    
    
       [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
                Requirements for IP Flow Information Export, RFC 3917,
                October 2004
    
       [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J.
                Quittek, "Architecture Model for IP Flow Information
                Export", RFC5470, March 2009
    
       [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
                "IP Flow Information Export (IPFIX) Applicability", RFC
                5472, March 2009
    
       [RFC5477] T. Dietz, F. Dressler, G. Carle, and B. Claise,
                "Information Model for Packet Sampling Exports", RFC
                5477, March 2009
    
       [RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet
                Sampling (PSAMP) Protocol Specifications", RFC 5476,
                March 2009.
    
       [RFC5474] Chiou, D., Claise, B., Duffield, N., Greenberg, A.,
                Grossglauser, M., Marimuthu, P., Rexford, J., and G.
                Sadasivan,  RFC 5474, March 2009
    
    
    
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 21]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
       [RFC5473] Boschi, E., Mark, L., and B. Claise, " Reducing
                Redundancy in IP Flow Information Export (IPFIX) and
                Packet Sampling (PSAMP) Reports", RFC 5473, March 2009
    
       [PSAMP-MIB] Dietz, T., and B. Claise, "Definitions of Managed
                Objects for Packet Sampling", Internet-Draft work in
                progress, June 2006
    
       [SCTP-RESET] Stewart, R., Lei, P., Tuexen, M, "Stream Control
                Transmission Protocol (SCTP) Stream Reset",
                draft-stewart-tsvwg-sctpstrrst-01.txt, Internet-Draft
                work in progress, February 2009
    
    
    10. Acknowledgements
    
       The authors would like to thank Brian Trammell for his expert
       feedback, Elisa Boschi for her thorough reading, and Randall
       Stewart, Peter Lei, and Michael Tuexen for their SCTP-related
       feedback and expertise.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    <Claise, et. Al>      Expires January 10, 2010         [Page 22]
    

     Internet-Draft     <IPFIX Export per SCTP Stream>       July 2009
    
    
    11. 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 January 10, 2010         [Page 23]
    

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/