[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 1, 2009                     Cisco Systems, Inc.
                                                             G. Muenz
                                              University of Tuebingen
                                                         July 1, 2008
     
                       IPFIX Export per SCTP Stream
                draft-ietf-ipfix-export-per-sctp-stream-00
     
     
     Status of this Memo
     
        By submitting this Internet-Draft, each author represents
        that any applicable patent or other IPR claims of which he
        or she is aware have been or will be disclosed, and any of
        which he or she becomes aware will be disclosed, in
        accordance with Section 6 of BCP 79.
     
        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups.  Note that other groups may also distribute
        working documents as Internet-Drafts.
     
        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time.  It is inappropriate to use
        Internet-Drafts as reference material or to cite them
        other than as "work in progress."
     
        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt.
     
        The list of Internet-Draft Shadow Directories can be
        accessed at
        http://www.ietf.org/shadow.html.
     
        This Internet-Draft will expire on June, 2008.
     
     Copyright Notice
     
        Copyright (C) The IETF Trust (2008).
     
     
     
     
     
     
     
     
     
     
     

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

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     
     Abstract
     
        This document specifies an improvement to the use of SCTP
        as specified in the IPFIX specifications in order to be
        able to deduce the Data Record loss per Template Record in
        case of partially-reliable SCTP export.  This specification
        offers several extra advantages: immediate export of the
        Template Withdrawal Message, immediate reuse of Template ID
        within a stream, and the Collecting Process's job is
        easier.
     
     Conventions used in this document
     
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
        and "OPTIONAL" in this document are to be interpreted as
        described in RFC 2119 [RFC2119].
     
     
     Table of Contents
     
     
        1. Terminology.................................................4
           1.1. IPFIX Documents Overview...............................4
           1.2. PSAMP Documents Overview...............................4
        2. Introduction................................................5
           2.1. Relationship with IPFIX and PSAMP......................6
           2.2. Applicability..........................................6
           2.3. Limitations............................................7
        3. IPFIX Protocol Specifications Limitations and
        Improvements...................................................7
           3.1. Data Record Loss per Template..........................7
              3.1.1. IPFIX Protocol Specifications Limitation..........7
              3.1.2. IPFIX Export per SCTP Stream Advantage............8
           3.2. Transmission Order within a Stream.....................8
              3.2.1. IPFIX Protocol Specifications Limitation..........8
              3.2.2. IPFIX Export per SCTP Stream Advantages...........9
           3.3. No Transmission Order across SCTP Streams.............10
              3.3.1. IPFIX Protocol Specifications Limitation.........10
              3.3.2. IPFIX Export per SCTP Stream Advantages..........10
        4. Specifications.............................................10
           4.1. Template Management...................................10
           4.2. New Information Element...............................12
           4.3. SCTP..................................................12
           4.4. Template Withdrawal Message...........................13
           4.5. The Collecting Process's Side.........................13
     
     
     <Claise, et. Al>       Expires January 1, 2009           [Page 2]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
        5. Examples...................................................14
        6. IANA Considerations........................................16
        7. Security Considerations....................................16
        8. References.................................................17
           8.1. Normative References..................................17
           8.2. Informative References................................17
        9. Acknowledgements...........................................18
        10. Author's Addresses........................................19
        11. Intellectual Property Statement...........................20
        12. Copyright Statement.......................................20
        13. Disclaimer................................................20
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009           [Page 3]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     
     1. Terminology
     
        IPFIX-specific terminology used in this document is defined
        in section 2 of [RFC5101].  As in [RFC5101], these IPFIX-
        specific terms have the first letter of a word capitalized
        when used in this document.
     
        Template Reuse Delay
     
           The configurable timeout to allow the Collecting Process
           to receive and process the last Data Record using this
           Template information before which the Template Withdrawal
           Message MUST NOT be sent.  [RFC5101] specifies a default
           value of 5 seconds.
     
     
     1.1. IPFIX Documents Overview
     
        The IPFIX Protocol [RFC5101] provides network administrators
        with access to IP Flow information.
     
        The architecture for the export of measured IP Flow
        information out of an IPFIX Exporting Process to a Collecting
        Process is defined in the IPFIX Architecture [IPFIX-ARCH],
        per the requirements defined in RFC 3917 [RFC3917].
     
        The IPFIX Architecture [IPFIX-ARCH] specifies how IPFIX Data
        Records and Templates are carried via a congestion-aware
        transport protocol from IPFIX Exporting Processes to IPFIX
        Collecting Processes.
     
        IPFIX has a formal description of IPFIX Information Elements,
        their name, type and additional semantic information, as
        specified in the IPFIX Information Model [RFC5102].
     
        Finally the IPFIX Applicability Statement [IPFIX-AS]
        describes what type of applications can use the IPFIX
        protocol and how they can use the information provided.  It
        furthermore shows how the IPFIX framework relates to other
        architectures and frameworks.
     
     1.2. PSAMP Documents Overview
     
        The document "A Framework for Packet Selection and Reporting"
        [PSAMP-FMWK], describes the PSAMP framework for network
        elements to select subsets of packets by statistical and
     
     
     <Claise, et. Al>       Expires January 1, 2009           [Page 4]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
        other methods, and to export a stream of reports on the
        selected packets to a collector.
     
        The set of packet selection techniques (sampling, filtering,
        and hashing) supported by PSAMP are described in "Sampling
        and Filtering Techniques for IP Packet Selection" [PSAMP-
        TECH].
     
        The PSAMP protocol [PSAMP-PROTO] specifies the export of
        packet information from a PSAMP Exporting Process to a PSAMP
        Collecting Process.  Like IPFIX, PSAMP has a formal
        description of its information elements, their name, type and
        additional semantic information.  The PSAMP information model
        is defined in [PSAMP-INFO].
     
        Finally [PSAMP-MIB] describes the PSAMP Management
        Information Base.
     
     
     2. Introduction
     
        The IPFIX working group has specified a protocol to export IP
        Flow information [RFC5101].  This protocol is designed to
        export information about IP traffic Flows and related
        measurement data, where a Flow is defined by a set of key
        attributes (e.g. source and destination IP address, source
        and destination port, etc.).  However, thanks to its template
        mechanism, the IPFIX protocol can export any type of
        information, as long as the relevant Information Element is
        specified in the IPFIX Information Model [RFC5102],
        registered with IANA, or specified as an enterprise-specific
        Information Element.
     
        The IPFIX protocol [RFC5101] specifies that IP traffic
        measurements for Flows are exported using a TLV (type,
        length, value) format.  The information is exported using a
        Template Record that is sent once to export the {type,
        length} pairs that define the data format for the Information
        Elements in a Flow.  The Data Records specify values for each
        Flow.
     
        The IPFIX protocol [RFC5101] is flexible: it foresees the usage
        of the multiple SCTP streams per association; it allows the
        transmission of Data Sets, Template Sets, and/or Options
        Template Sets on any stream; it offers the full or partial
        reliability export of Data Sets; it proposes the ordered or out-
        of-order delivery of Data Sets.  However, due to bandwidth
     
     
     <Claise, et. Al>       Expires January 1, 2009           [Page 5]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
        restrictions and packet losses in the network as well as
        resource constraints on the Exporter and Collector (e.g.,
        limited buffer sizes), it is not always possible to export all
        Data Sets in a reliable way.
     
     
        Without delving into the details of the specifications described
        later on in this document, the basic idea is to export the
        Template Record and its associated Data Sets into a single
        unique SCTP stream, ideally to limit the Template ID to a single
        stream, while imposing in-order transmission.
     
        The specification in this document offers several advantages
        such as: calculation of Data Record losses in case of partially-
        reliable SCTP export, immediate export of the Template
        Withdrawal Message, immediate reuse of template ID within a
        stream, reduced likelihood of losing Data Record, and the
        Collecting Process's job is easier.
     
     
     2.1. Relationship with IPFIX and PSAMP
     
        The specification in this document applies to the IPFIX
        protocol specifications [RFC5101].  However, it only applies
        to the SCTP transport protocol [RFC4960] option of the IPFIX
        protocol specifications, specifically in the case of the
        partial reliability extension [RFC3758].  All specifications
        from [RFC5101] apply unless specified otherwise in this
        document.
     
        As the Packet Sampling (PSAMP) protocol specifications
        [PSAMP-PROTO] are based on the IPFIX protocol specifications,
        the specifications in this document are also valid for the
        PSAMP protocol.  Therefore, the advantages specified by this
        document also apply to PSAMP.
     
     
     2.2. Applicability
     
        The specifications are required in cases where we must know how
        many Data Records of a certain type (i.e. from a certain
        Template ID) were lost.  Furthermore, they apply in cases where
        the Exporter can not afford to export all the Flow Records
        reliably, due to the limited resources to buffer the huge amount
        of flow records.  Such situations may occur if Data Sets are
        generated at a higher rate at the Exporter than can be
        transferred to the Collector because of bandwidth limitations in
     
     
     <Claise, et. Al>       Expires January 1, 2009           [Page 6]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
        the network or slow reception at the Collector.  A typically
        example is a router exporting billing records.
     
        To be more precise, the specification applicability is the case
        where multiple Template IDs are sent within a SCTP Transport
        Session and the calculation of the Data Record loss for a
        particular one Template ID is required.  Indeed, with the
        current IPFIX specifications [RFC5101], if an IPFIX Message is
        lost (UDP or SCTP partially reliable), it is not possible to
        determine to which Template ID of the Transport Session the lost
        Data Records belong to.
     
        In terms of Collector, there is backwards compatibility: the
        Collecting Process does not require any changes to support an
        Exporter that complies to the specifications in this document.
     
     
     2.3. Limitations
     
        To be compliant with the specifications in this document, the
        Transport Session must support multiple SCTP streams.
        Furthermore, if the SCTP Transport Session does not support
        enough streams for the increasing number of Template ID in the
        Transport Session, the addition of streams must be supported
        according to [SCTP-RESET].  Alternatively, the new Template ID
        and associated Data Records may be added to an existing stream
        at the cost of diluting the granularity of Data Records loss.
        The other alternatives, which is not practical in operational
        networks, is to restart the SCTP association with an increase
        number of streams.
     
     
     3. IPFIX Protocol Specifications Limitations and Improvements
     
     3.1. Data Record Loss per Template
     
     3.1.1. IPFIX Protocol Specifications Limitation
     
        Section 6.3.2 of the Requirements for IP Flow Information
        Export [RFC3917] discusses the data transfer reliability
        issues.  "Loss of flow records during the data transfer from
        the exporting process to the Collecting Process must be
        indicated at the collecting process." is clearly mentioned.
        However, in some cases, it may be important to know how many
        Data Records of a certain type were lost (e.g., in the case
        of billing), but conventionally IPFIX does not provide this
        information.
     
     
     <Claise, et. Al>       Expires January 1, 2009           [Page 7]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     
        A Collector can detect out-of-sequence, dropped, or duplicate
        IPFIX Messages by tracking the Sequence Number [RFC5101].
        Note that the Sequence Number field in the Export header
        increases with the number of IPFIX Data Records within the
        PR-SCTP stream.
     
        The IPFIX protocol specification [RFC5101] specifies that Data
        Records associated with any Template ID may be sent on any SCTP
        stream.  As such, if there is more than one Template IDs defined
        within the whole SCTP association then there is no way of
        knowing which Template ID any lost Data Records are associated
        with.  This is true, no matter what convention the Exporting
        Process uses to send Data Records on different SCTP streams, as
        the protocol makes no guarantees.
     
        Using the specification in this document, it is guaranteed that
        any lost Data Records will be associated only with the Templates
        that are defined on that stream and by defining only one
        Template on a stream it is ensured that any loss is associated
        with that single Template.
     
     
     3.1.2. IPFIX Export per SCTP Stream Advantage
     
        By exporting each Template ID and the corresponding Data Records
        within a different stream, the loss pertaining to each specific
        Template ID can be deduced from the Sequence Number field in the
        IPFIX Message headers.
     
     
     3.2. Transmission Order within a Stream
     
     3.2.1. IPFIX Protocol Specifications Limitation
     
        A Collecting Process must have received the Template Record
        associated with the Data Records to be able to decode the
        information in the Data Records.  The IPFIX protocol
        specification foresees:
     
           "The Exporting Process SHOULD transmit the Template Set
           and Options Template Set in advance of any Data Sets that
           use that (Options) Template ID, to help ensure that the
           Collector has the Template Record before receiving the
           first Data Record.",
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009           [Page 8]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
        The fact that the Collecting Process cannot decode the Data
        Records without the Template Record may result in the Data
        Records being discarded by the Collector, as specified in
        [RFC5101]:
     
           "The Collecting Process normally receives Template Records
           from the Exporting Process before receiving Data Records.
           The Data Records are then decoded and stored by the
           Collector.  If the Template Records have not been received
           at the time Data Records are received, the Collecting
           Process MAY store the Data Records for a short period of
           time and decode them after the Template Records are
           received."
     
        In practice, Data Records without associated (Options)
        Template Records will probably be discarded by the Collecting
        Process.
     
     
     3.2.2. IPFIX Export per SCTP Stream Advantages
     
        By exporting each Template Record and the corresponding Data
        Records within a single stream and imposing in-order
        transmission, the Template will always arrive before the
        associated Data Records.  Therefore, there is no risk that
        the Collecting Process discards Data Records while waiting
        for the Template to arrive.
     
        Furthermore, when reusing a Template ID within a stream, the
        Template Withdrawal Message will be guaranteed to arrive
        before the new definition of the Template and therefore the
        Template Record may be sent directly after the Template
        Withdrawal Message.  In other words, the Template Reuse Delay
        restriction (by default, 5 seconds, as specified in [RFC5101]
        is removed for Template ID reuse within the same stream.
     
        Another advantage with the new specifications in this
        document is that the Collecting Process's job is now easier.
        Indeed, the Collecting Process doesn't have to store the Data
        Records while waiting for the Template Records, as the
        transmission order is always guaranteed.  This way, extra
        reliability of the Data Records is achieved without extra
        burden on the Collecting Process.
     
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009           [Page 9]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     3.3. No Transmission Order across SCTP Streams
     
     3.3.1. IPFIX Protocol Specifications Limitation
     
        The fact that the protocol specifications [RFC5101] are
        flexible in terms of stream(s) on which the Template Set,
        Options Template Set, and corresponding Data Sets are
        exported, implies that the (Options) Template Set might be
        exported on a different stream than the corresponding Data
        Sets.  This might cause Data Record loss in the Collecting
        Process as the ordered transmission across SCTP streams is
        not guaranteed.
     
        For example, a Template may be blocked pending reliable
        transmission on one stream while the associated Data Records
        may be transmitted immediately in another stream.  Also, due
        to different stream congestion, it is possible that even if
        the Template and Data Records are both sent reliably, Data
        Records sent on a different stream than the associated
        Template might still arrive before the associated Template.
     
     
     3.3.2. IPFIX Export per SCTP Stream Advantages
     
        By exporting each Template Record and the corresponding Data
        Records within a single stream, imposing in-order
        transmission, and limiting the Template ID to a single
        stream, the issue of ordered transmission across multiple
        streams is avoided.
     
        By exporting all corresponding Data Records within the same
        ordered stream as the Template Definition, each stream is
        independent and self-contained and the interaction between
        streams is limited to that of Options Data interactions.  This
        has several advantageous consequences, including the order
        preservation that does not result in the blocking of unrelated
        data and the Collector's job simplification (as the Template
        Records are guaranteed to be delivered before the associated
        Data Records).
     
     
     4. Specifications
     
     4.1. Template Management
     
        This section introduces modifications compared to the Template
        Management section 8 in [RFC5101].
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 10]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     
        As specified in [RFC5101], Template Sets and Options Template
        Sets MUST be sent reliably.  In other words, any IPFIX Message
        containing an (Options) Template Set MUST be sent reliably.
     
        Any Data Sets associated with a Template Record MUST be sent on
        the same stream on which the Template Record was sent.
     
        The Exporter SHOULD send a single Template and associated Data
        Sets within a single stream in order to calculate the potential
        Data Record loss for this Template ID.  However, the Exporter
        MAY group related Templates and their associated Data Sets
        within a single stream so loss statistics are calculated for the
        group.  This may be suitable in cases where there is
        insufficient SCTP streams to send each Template on its own
        stream and/or the case where there are slight variations on a
        single Template to show that some fields were unavailable at the
        time of monitoring.
     
        If a SCTP stream contains a mixture of Data Records defined by a
        Template Record and Options Template Record(s), the Data Records
        defined by the Options Template Record(s) SHOULD be sent
        reliably within the same stream so that the Collector does not
        consider any loss to be associated with the Options Data.
        Indeed, if the Collector does not have the guarantee that the
        Data Records defined by the Options Template Record are sent
        reliably, the Collector can not determine whether the loss in
        that stream belongs to the Data Records defined by the Template
        Record, defined by the Option Template Record, or by both of
        them.  By sending the Options Data reliably (which is usually
        required to interpret the Data Records correctly), any loss will
        be limited to the non-option Data Record and loss can still be
        calculated on a per Template basis.
     
        For each (Options) Template Record, the Exporting Process MUST
        send the Data Record Reliability Option Template using an Option
        Template with the following Information Elements:
     
         SCOPE:     Template ID
         NOT-SCOPE: dataRecordsReliability
     
        The Data Record Reliability Option Template MUST be sent
        reliably.
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 11]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
        The Option Data Record SHOULD be sent before the Data Record
        that needs it so that it arrives first and is available for the
        Collector to use.
     
     
     4.2. New Information Element
     
        dataRecordsReliability
     
           Description:
                The Data Records reliability associated with this
                Template ID.  The integer value 1 means that the Data
                Records are sent reliably, while the integer value 2
                means that the Data Records are not sent reliably.
           Abstract Data Type: boolean
           Data Type Semantics: identifier
           ElementId: xxx
           Status: current
     
     
     4.3. SCTP
     
        This section introduces modifications compared to the "SCTP"
        section 10.2 (and subsections) in [RFC5101].  More specifically
        the "Stream" section 10.2.4.3
     
        PR-SCTP [RFC3758] MUST be implemented by all compliant
        implementations.
     
        All IPFIX Messages MUST be sent in order within a stream.
     
        Depending on the application requirement, the Exporting Process
        MAY send Data Sets with full or partial reliability.  Unreliable
        data transfer MAY be used where the application does not require
        reliable transmission or the use of a retransmission queue is
        impractical due to resource restrictions at the Exporter.
     
     
        If the Exporting Process requires to export a new Template but
        there are no more free SCTP streams available, it SHOULD attempt
        to increase the number of outbound streams it is able to send
        to, per [SCTP-RESET].  Alternatively, the Exporting Process MAY
        add the Template Set and Data Records to an existing stream at
        the cost of diluting the granularity of Data Records loss.
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 12]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     4.4. Template Withdrawal Message
     
        This section introduces Template Withdrawal Message-related
        modifications compared to the Template Management section 8 in
        [RFC5101].
     
        Templates that are not used anymore SHOULD be deleted.  Before
        reusing a Template ID, the Template MUST be deleted.  In order
        to delete an allocated Template, the Template is withdrawn
        through the use of a Template Withdrawal Message.  The Template
        Withdrawal Message MUST be sent on the same stream as the
        Template Record.
     
        As the Template Withdrawal Message MUST be sent reliably, using
        SCTP-ordered delivery per [RFC5101], and as all IPFIX Messages
        are sent in order within a stream (per the specifications in
        this document), the IPFIX Message containing the Template
        Withdrawal Message will not arrive at the Collecting Process
        before any associated and previously sent Data Record.  As a
        consequence, no Data Records will be lost due to delayed arrival
        at the Collector.
     
        The Template ID from a withdrawn Template MAY be reused on the
        same stream immediately after the Template Withdrawal Message is
        sent.  This case is equivalent to the use of a Template Reuse
        Delay value of 0.
     
        If the new definition of the Template ID is to be reused on a
        different stream, the Template Withdrawal Message MUST NOT be
        sent before the Template Reuse Delay.
     
        A Template Withdrawal Message to withdraw all Templates for the
        Observation Domain ID specified in the IPFIX Message header MUST
        NOT be used.
     
        Multiple Template IDs MAY be withdrawn with a single Template
        Withdrawal Message at the condition that all the Template IDs in
        the Template Withdrawal Message are used on the same SCTP
        stream.
     
     
     4.5. The Collecting Process's Side
     
        This section introduces modifications to the Collection Process
        as compared to section 9 in [RFC5101].
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 13]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
        The Collecting Process SHOULD listen for a new association
        request from the Exporting Process.  The Exporting Process will
        request a number of streams to use for export: the number of
        streams SHOULD be equivalent to the number of simultaneous
        Template Records used in the association. Note that the Template
        Records don't include the Options Template Records.
     
        A Collecting Process SHOULD support the procedure for the
        addition of an SCTP stream [SCTP-RESET].
     
        The IPFIX protocol has a Sequence Number field in the IPFIX
        Message header that increases with the number of IPFIX Data
        Records in the IPFIX Message.  A Collector may detect out-of-
        sequence, dropped, or duplicate IPFIX Messages by tracking the
        Sequence Number.  As this Sequence Number is per SCTP stream,
        the loss for the Data Records sent in that stream can be
        calculated in case of partially-reliable export.
     
        If the Collecting Process receives a Template Withdrawal Message
        on a different stream than the one on which the Template ID is
        used, then the Collecting Process MUST reset the association and
        SHOULD log an error message.
     
        The following sentences from [RFC5101] are not applicable in
        this specification:
     
           "The Collecting Process normally receives Template Records
           from the Exporting Process before receiving Data Records.
           The Data Records are then decoded and stored by the
           Collector.  If the Template Records have not been received at
           the time Data Records are received, the Collecting Process
           MAY store the Data Records for a short period of time and
           decode them after the Template Records are received."
     
     
     5. Examples
     
        Figure 1 shows an example where the stream 10 carries a Template
        with the Template ID 256 transmitted with full reliability (FR),
        together with associated Data Records transmitted with partial
        reliability (PR).  Note that, because all IPFIX Messages are
        sent in order within a stream, the Template 256 will always be
        processed before the Data Records by the Collecting Process.
        Therefore, the Collecting Process job is simplified.
        Furthermore, the Data Record loss for the Template 256 can
        easily be calculated on the Collecting Process.
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 14]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     
                      +--------+       +---------+   +----------+
                      |        |       |         |   |          |
        stream 10 ----| Data   | . . . |  Data   |---| Template |--->
                      |   256  |       |    256  |   |     256  |
                      |      PR|       |       PR|   |        FR|
                      +--------+       +---------+   +----------+
                                     Figure 1
     
        If an Option Template is necessary to understand the content of
        a Data Record (i.e. the scope in the Options Template Record is
        an Information Element contained in the Data Record), the
        Options Template Record may be sent in the same stream, as
        displayed in figure 2.
     
                         +--------+   +--------+     +----------+
                         |        |   |        |     |          |
        stream 20 ... ---| Data   |...| Data   |-----| Template |---
                         |   258  |   |   258  |     |     258  |
                         |      PR|   |      PR|     |        FR|
                         +--------+   +--------+     +----------+
     
                                +--------+       +----------+
                                |        |       | Options  |
                          ...---| Data   |-------| Template |------>
                                |   257  |       |     257  |
                                |      FR|       |        FR|
                                +--------+       +----------+
                                     Figure 2
     
        Figure 2 shows an example where stream 20 carries an Options
        Template with Template ID 257 transmitted with full reliability
        (FR), an associated Data Record transmitted with full
        reliability (FR), a Template with Template ID 258 transmitted
        with full reliability (FR), and associated Data Records
        transmitted with partial reliability (PR).  In this example the
        Option Template Record contains information required to decode
        the latter Data Records, such as Common Properties information
        [IPFIX-RED-RED].  So it makes sense to export the Data Sets 257
        reliably.  If some Data Record loss is observed from the
        Sequence Number , the loss can only stem from the Data Sets with
        the Template ID 258, as these are the only Sets not exported
        reliably.  Therefore, the calculation of loss per Template ID
        258 is possible.
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 15]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     
        Note that, because all IPFIX Messages must be sent in order
        within a stream, the Options Template 257 will always arrive
        before its associated Data Records, and that the Template 259
        will always arrive before the its associated Data Records.
     
        Figure 3 shows an example where stream 30 carries a Template
        with Template ID 259 transmitted with full reliability (FR), an
        associated Data Record transmitted with partial reliability
        (PR), a Template Withdrawal Message, followed by a redefinition
        of the Template ID 259, and finally the new definition of Data
        Record transmitted with partial reliability.  The Template
        Withdrawal Message and the new definition of the Template ID 259
        are sent immediately, without waiting for the Template Reuse
        Delay.
     
     
                         +--------+   +----------+     +----------+
                         |        |   |          |     | Template |
        stream 30 ... ---| Data   |...| Template |-----| Withdraw.|---
                         |   259  |   |   259    |     |    259   |
                         |      PR|   |        FR|     |        FR|
                         +--------+   +----------+     +----------+
     
                                +--------+       +----------+
                                |        |       |          |
                          ...---| Data   |-------| Template |------>
                                |   259  |       |     259  |
                                |      PR|       |        FR|
                                +--------+       +----------+
     
                                     Figure 3
     
     6. IANA Considerations
     
        The dataRecordsReliability Information Element must be requested
        from IANA, following the process in [RFC5102].
     
     
     7. Security Considerations
     
        The same security considerations as for the IPFIX Protocol
        [RFC5101] apply.
     
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 16]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     8. References
     
     8.1. Normative References
     
        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
                Requirement Levels, BCP 14, RFC 2119, March 1997
     
        [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., Conrad,
                P., "Stream Control Transmission Protocol (SCTP),
                Partial Reliability Extension", May 2004
     
        [RFC4960] Stewart, R., Ed., "Stream Control Transmission
                Protocol", RFC 4960, September 2007.
     
        [RFC5101] Claise, B., Ed., "Specification of the IP Flow
                Information Export (IPFIX) Protocol for the Exchange of
                IP Traffic Flow Information", RFC 5101, January 2008.
     
        [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and
                J. Meyer, "Information Model for IP Flow Information
                Export", RFC 5102, January 2008.
     
        [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F.
                Raspall, "Sampling and Filtering Techniques for IP
                Packet Selection" draft-ietf-psamp-sample-tech-10.txt,
                Internet-Draft work in progress, June 2007
     
        [SCTP-RESET] Stewart, R., Lei, P., Tuexen, M, "Stream Control
                Transmission Protocol (SCTP) Stream Reset",
                 draft-stewart-tsvwg-sctpstrrst-00.txt, Internet-Draft
                work in progress, June 2008
     
     
     8.2. Informative References
     
     
        [RFC3917] Quittek, J., Zseby, T., Claise, B. Zander, S,
                Requirements for IP Flow Information Export, RFC 3917,
                October 2004
     
        [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek,
                J., "Architecture Model for IP Flow Information Export"
                draft-ietf-ipfix-architecture-12, Internet-Draft work
                in progress, September 2006
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 17]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
        [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B.,
                "IPFIX Applicability", draft-ietf-ipfix-as-12.txt,
                Internet-Draft work in progress, February 2007
     
        [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise,
                "Information Model for Packet Sampling Exports", draft-
                ietf-psamp-info-08.txt, Internet-Draft work in
                progress, February 2008
     
        [PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet
                Sampling (PSAMP) Protocol Specifications", draft-ietf-
                psamp-protocol-09, Internet-Draft work in progress,
                December 2007.
     
        [PSAMP-FMWK] D. Chiou, B. Claise, N. Duffield, A. Greenberg, M.
                Grossglauser, P. Marimuthu, J. Rexford, G. Sadasivan,
                "A Framework for Passive Packet Measurement" draft-
                ietf-psamp-framework-12.txt, Internet-Draft work in
                progress, June 2007
     
        [IPFIX-RED-RED] Boschi, E., Mark, L., Claise, B. "Reducing
                Redundancy in IPFIX and PSAMP Reports", Internet-Draft
                work in progress, draft-ietf-ipfix-reducing-redundancy-
                04.txt, May 2007
     
        [PSAMP-MIB] Dietz, T., Claise, B. "Definitions of Managed
                Objects for Packet Sampling", Internet-Draft work in
                progress, June 2006
     
     
     9. Acknowledgements
     
        The authors would like to thank Brian Trammell for his expert
        feedback, Randall Stewart and Peter Lei for their SCTP-related
        feedback, and Elisa Boschi for her thorough reading.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 18]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     10. Author's Addresses
     
        Benoit Claise
        Cisco Systems Inc.
        De Kleetlaan 6a b1
        Diegem 1813
        Belgium
     
        Phone: +32 2 704 5622
        Email: bclaise@cisco.com
     
     
        Paul Aitken
        Cisco Systems (Scotland) Ltd.
        96 Commercial Quay
        Commercial Street
        Edinburgh, EH6 6LX, United Kingdom
     
        Phone: +44 131 561 3616
        Email: paitken@cisco.com
     
     
        Andrew Johnson
        Cisco Systems (Scotland) Ltd.
        96 Commercial Quay
        Commercial Street
        Edinburgh, EH6 6LX, United Kingdom
     
        Phone: +44 131 561 3641
        Email: andrjohn@cisco.com
     
     
        Gerhard Muenz
        University of Tuebingen
        Computer Networks and Internet
        Sand 13
        Tuebingen  D-72076
        DE
     
        Phone: +49 7071 29-70534
        Email: muenz@informatik.uni-tuebingen.de
        URI:   http://net.informatik.uni-tuebingen.de/~muenz
     
     
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 19]
     

     Internet-Draft      <IPFIX Export per SCTP Stream>       July 2008
     
     
     11. Intellectual Property Statement
     
        The IETF takes no position regarding the validity or scope of
        any Intellectual Property Rights or other rights that might be
        claimed to pertain to the implementation or use of the
        technology described in this document or the extent to which any
        license under such rights might or might not be available; nor
        does it represent that it has made any independent effort to
        identify any such rights.  Information on the procedures with
        respect to rights in RFC documents can be found in BCP 78 and
        BCP 79.
        Copies of IPR disclosures made to the IETF Secretariat and any
        assurances of licenses to be made available, or the result of an
        attempt made to obtain a general license or permission for the
        use of such proprietary rights by implementers or users of this
        specification can be obtained from the IETF on-line IPR
        repository at http://www.ietf.org/ipr.
     
        The IETF invites any interested party to bring to its attention
        any copyrights, patents or patent applications, or other
        proprietary rights that may cover technology that may be
        required to implement this standard.  Please address the
        information to the IETF at ietf-ipr@ietf.org.
     
     
     12. Copyright Statement
     
        Copyright (C) The IETF Trust (2008).
     
        This document is subject to the rights, licenses and
        restrictions contained in BCP 78, and except as set forth
        therein, the authors retain all their rights.
     
     
     13. Disclaimer
     
        This document and the information contained herein are provided
        on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
        REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
        THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
        ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
        ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
        INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
        OR FITNESS FOR A PARTICULAR PURPOSE.
     
     
     
     
     
     <Claise, et. Al>       Expires January 1, 2009          [Page 20]
     

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/