[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: July 21, 2009                       Cisco Systems, Inc.
                                                             G. Muenz
                                                          TU Muenchen
                                                     January 21, 2009
     
                       IPFIX Export per SCTP Stream
                draft-ietf-ipfix-export-per-sctp-stream-02
     
     
     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 July, 2009.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

     <Claise, et. Al>         Expires July 21 2009             [Page 1]
     

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

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
        5. Examples...................................................16
        6. IANA Considerations........................................19
        7. Security Considerations....................................20
        8. References.................................................20
           8.1. Normative References..................................20
           8.2. Informative References................................20
        9. Acknowledgements...........................................21
        10. Author's Addresses........................................22
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>        Expires July 21, 2009            [Page 3]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 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 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 July 21, 2009            [Page 4]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
        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 July 21, 2009            [Page 5]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
        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 July 21, 2009            [Page 6]
     

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

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
        indicating a success.  The newly added streams will be appended
        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.3
     
     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 July 21, 2009            [Page 8]
     

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

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

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

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

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

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

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

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
            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
             o NOT-SCOPE: dataRecordsReliability = False
     
     
                      +--------+       +---------+   +--------+
                      |        |       |         |   |        |
        stream 10 ----| Data   | . . . |  Data   |---| Data   |---...
                      |   256  |       |    256  |   |   257  |
                      |      PR|       |       PR|   |      FR|
                      +--------+       +---------+   +--------+
     
     
     
     
     
                                +----------+       +----------+
                                |          |       | Options  |
     
     
     <Claise, et. Al>        Expires July 21, 2009           [Page 16]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
                                |          |       | 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|
                         +--------+   +--------+     +--------+
     
                                +--------+       +----------+
                                |        |       |          |
                          ...---| Data   |-------| Template |---...
                                |   258  |       |     260  |
                                |      FR|       |        FR|
                                +--------+       +----------+
     
     
                                +----------+       +----------+
                                | Options  |       | Options  |
                                | Template |       | Reliabil.|
                          ...---|          |-------| Template |------>
                                |     259  |       |     258  |
                                |        FR|       |        FR|
                                +----------+       +----------+
     
     
     
     
     <Claise, et. Al>        Expires July 21, 2009           [Page 17]
     

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

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
     
        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.
     
     
     6. IANA Considerations
     
        The dataRecordsReliability Information Element must be requested
        from IANA, following the process in [RFC5102].
     
     
     
     
     
     
     <Claise, et. Al>        Expires July 21, 2009           [Page 19]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
     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
     
     
     
     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 July 21, 2009           [Page 20]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
        [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
     
        [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
     
     
     
     9. 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 July 21, 2009           [Page 21]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
     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
     
     
     
        Full Copyright Statement
     
     
     
     <Claise, et. Al>        Expires July 21, 2009           [Page 22]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 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
        (http://trustee.ietf.org/license-info) in effect on the date of
        publication of this document. Please review these documents
        carefully, as they describe your rights and restrictions with
        respect to this document.
     
        All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
        WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
        PURPOSE.
     
     
     
        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.
     
        Copies of Intellectual Property 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 any standard or specification contained in
        an IETF Document.  Please address the information to the IETF at
        ietf-ipr@ietf.org.
     
     
     
     
     <Claise, et. Al>        Expires July 21, 2009           [Page 23]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>    January 2009
     
     
        The definitive version of an IETF Document is that published by,
        or under the auspices of, the IETF. Versions of IETF Documents
        that are published by third parties, including those that are
        translated into other languages, should not be considered to be
        definitive versions of IETF Documents. The definitive version of
        these Legal Provisions is that published by, or under the
        auspices of, the IETF. Versions of these Legal Provisions that
        are published by third parties, including those that are
        translated into other languages, should not be considered to be
        definitive versions of these Legal Provisions.
     
     
        For the avoidance of doubt, each Contributor to the IETF
        Standards Process licenses each Contribution that he or she
        makes as part of the IETF Standards Process to the IETF Trust
        pursuant to the provisions of RFC 5378. No language to the
        contrary, or terms, conditions or rights that differ from or are
        inconsistent with the rights and licenses granted under RFC
        5378, shall have any effect and shall be null and void, whether
        published or posted by such Contributor, or included with or in
        such Contribution.
     
        Acknowledgment
     
        Funding for the RFC Editor function is currently provided by the
        Internet Society.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>        Expires July 21, 2009           [Page 24]
     

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