Skip to main content

IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream
draft-ietf-ipfix-export-per-sctp-stream-08

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6526.
Authors Benoît Claise , Paul Aitken, Andrew Johnson , Gerhard Muenz
Last updated 2021-10-22 (Latest revision 2010-06-01)
Replaces draft-claise-ipfix-export-per-sctp-stream
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 6526 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Dan Romascanu
IESG note
Send notices to (None)
draft-ietf-ipfix-export-per-sctp-stream-08
IPFIX Working Group                                    B. Claise 
     Internet-Draft                                         P. Aitken 
     Intended Status: Standards Track                      A. Johnson 
     Expires: November 31, 2010                   Cisco Systems, Inc.   
                                                             G. Muenz 
                                                          TU Muenchen 
                                                         May 31, 2010 
      
                       IPFIX Export per SCTP Stream 
                draft-ietf-ipfix-export-per-sctp-stream-08 

     Abstract 

        This document specifies an extension to the specifications 
        in RFC5101, IP Flow Information Export (IPFIX), when using 
        the Partial Reliability extension of SCTP (PR-SCTP, Partial 
        Reliability Stream Control Transmission Protocol). 
        When implemented at both the Exporting and Collecting Processes, 
        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, reduced likelihood of Data Record loss, 
        and reduced demands on the Collecting Process.  When implemented 
        in only the Collecting or Exporting Process then normal IPFIX 
        behavior will be seen without these additional benefits. 
         
     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 May, 2010. 
         
         
     Copyright Notice 

         
     <Claise, et. Al>         Expires Nov 31 2010             [Page 1] 

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        Copyright (c) 2010 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.  Code Components extracted from this 
        document must include Simplified BSD License text as described 
        in Section 4.e of the Trust Legal Provisions and are provided 
        without warranty as described in the Simplified BSD License. 
         
         
     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. Introduction............................................... 3 
           1.1. Relationship with IPFIX and PSAMP..................... 4 
           1.2. Applicability......................................... 4 
           1.3. Limitations........................................... 5 
        2. Terminology................................................ 5 
           2.1. IPFIX Documents Overview.............................. 6 
           2.2. PSAMP Documents Overview.............................. 6 
        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 an SCTP 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............. 9 
              3.3.1. IPFIX Protocol Specifications Limitation......... 9 
              3.3.2. IPFIX Export per SCTP Stream Advantages......... 10 
        4. Specifications............................................ 10 
           4.1. New Information Element.............................. 10 
           4.2. Template Management.................................. 11 
           4.3. SCTP................................................. 13 
      
      
     <Claise, et. Al>         Expires Nov 31, 2010             [Page 2] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

           4.4. Template Withdrawal Message.......................... 13 
           4.5. The Collecting Process's Side........................ 14 
        5. Performance Impact........................................ 16 
        6. Guidelines for IPFIX per-SCTP-stream Extension Testing.... 16 
        7. Examples.................................................. 17 
        8. IANA Considerations....................................... 21 
        9. Security Considerations................................... 21 
        10. References............................................... 21 
           10.1. Normative References................................ 21 
           10.2. Informative References.............................. 22 
        11. Acknowledgements......................................... 22 
        12. Author's Addresses....................................... 23 
         
      
         

     1. Introduction 

        The IPFIX protocol [RFC5101] has the goal of exporting IP 
        Flow information.  This protocol is designed to export 
        information about IP traffic Flows and related measurement 
        data, where a Flow is defined by a set of key attributes 
        (e.g., source and destination IP address, source and 
        destination port, etc.).  However, thanks to its Template 
        mechanism, the IPFIX protocol can export any type of 
        information, as long as the relevant Information Element is 
        specified in the IPFIX Information Model [RFC5102], 
        registered with IANA, or specified as an enterprise-specific 
        Information Element. 
         
        The IPFIX protocol [RFC5101] specifies that IP traffic 
        measurements for Flows are exported using a TLV (type, 
        length, value) format.  The information is exported using a 
        Template Record which 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 multiple SCTP streams per association; it allows the 
        transmission of Data Sets, Template Sets, and/or Options 
        Template Sets on any SCTP stream; it offers full and partially 
        reliable export of Data Sets; it proposes ordered or out-of-
        order delivery of Data Sets.  However, due to bandwidth 
        restrictions and packet losses in the network as well as 
        resource constraints on the Exporter and Collector (e.g., 

      
      
     <Claise, et. Al>         Expires Nov 31, 2010             [Page 3] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        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 SCTP 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. 
      
         
     1.1. Relationship with IPFIX and PSAMP 

        The specification in this document applies to the IPFIX 
        protocol specifications [RFC5101].  However, it only applies 
        to the SCTP transport protocol [RFC4960] option of the IPFIX 
        protocol specifications, specifically in the case of the 
        partial reliability extension [RFC3758].  All specifications 
        from [RFC5101] apply unless specified otherwise in this 
        document. 
      
        As the Packet Sampling (PSAMP) protocol specifications 
        [RFC5476] are based on the IPFIX protocol specifications, the 
        specifications in this document are also valid for the PSAMP 
        protocol. 
           
      
     1.2. Applicability 

        The specifications contained in this document are applicable to 
        cases where application requirements include knowing 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 Nov 31, 2010             [Page 4] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        To be more precise, the specification applicability is the case 
        where multiple Templates are simultaneously active within a 
        single SCTP Transport Session and the calculation of the Data 
        Record loss for a particular Template is required.  Indeed, with 
        the current IPFIX specifications [RFC5101], if an IPFIX Message 
        is lost (UDP or SCTP partially reliable), it is not possible to 
        determine to which Template the lost Data Records belong to. 
         
        Exporting Processes following this specification will 
        interoperate with existing Collecting Processes that comply with 
        [RFC5101]; no changes are required at the Collecting Process to 
        receive data from an Exporting Process compliant with this 
        method.  However, Collecting Processes may implement additional 
        support for per-stream export specified in this document in 
        order to realize all the benefits of the approach specified 
        herein. 
         
      
     1.3. Limitations 

        When multiple Templates are required, this method requires 
        multiple SCTP streams in the association between the Exporting 
        and Collecting Process, ideally one per Template.  To properly 
        handle the transmission of additional Templates during the 
        Transport Session, additional SCTP streams are sometimes 
        required.  These SCTP streams can only be added within the 
        existing SCTP association if the specifications in [SCTP-RESET] 
        are supported. 
      
      
     2. 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.   
         
        Note that, in this document, "(Options) Template" is used to 
        refer to Templates and Options Templates.  Unless otherwise 
        specified, "Template" alone refers to Templates exclusive of 
        Options Templates. 
         
        Template Reuse Delay  
         
           The time the Exporting Process needs to wait after sending 
           the last Data Set described by a given Template before 

      
      
     <Claise, et. Al>         Expires Nov 31, 2010             [Page 5] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

           sending a Template Withdrawal Message for the Template.  
           [RFC5101] specifies a default value of 5 seconds. 
         

     2.1. IPFIX Documents Overview 

        The IPFIX Protocol [RFC5101] provides network administrators 
        with access to IP Flow information. 
         
        The architecture for the export of measured IP Flow 
        information out of an IPFIX Exporting Process to a Collecting 
        Process is defined in the IPFIX Architecture [RFC5470], per 
        the requirements defined in [RFC3917]. 
         
        The IPFIX Architecture [RFC5470] specifies how IPFIX Data 
        Records and Templates are carried via a congestion-aware 
        transport protocol from IPFIX Exporting Processes to IPFIX 
        Collecting Processes. 
         
        IPFIX has a formal description of IPFIX Information Elements, 
        their names, types and additional semantic information, as 
        specified in the IPFIX Information Model [RFC5102].   
         
        Finally the IPFIX Applicability Statement [RFC5472] describes 
        what type of applications can use the IPFIX protocol and how 
        they can use the information provided.  It furthermore shows 
        how the IPFIX framework relates to other architectures and 
        frameworks.  
         
     2.2. PSAMP Documents Overview 

        The document "A Framework for Packet Selection and Reporting" 
        [RFC5474], describes the Packet Sampling (PSAMP) framework 
        for network elements to select subsets of packets by 
        statistical and other methods, and to export a stream of 
        reports on the selected packets to a collector. 
         
        The set of packet selection techniques (sampling, filtering, 
        and hashing) supported by PSAMP are described in "Sampling 
        and Filtering Techniques for IP Packet Selection" [RFC5475]. 
         
        The PSAMP protocol [RFC5476] specifies the export of packet 
        information from a PSAMP Exporting Process to a PSAMP 
        Collecting Process.  Like IPFIX, PSAMP has a formal 
        description of its Information Elements, their names, types 
        and additional semantic information.  The PSAMP information 
        model is defined in [RFC5477]. 
      
      
     <Claise, et. Al>         Expires Nov 31, 2010             [Page 6] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

         
        Finally [PSAMP-MIB] describes the PSAMP Management 
        Information Base. 
         
     3. IPFIX Protocol Specifications Limitations and Improvements  

        For three specific topics ("Data Record Loss per Template", 
        "Transmission Order within an SCTP stream", "No Transmission 
        Order across SCTP Streams"), this section explains the IPFIX 
        protocol specifications limitations on the 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." 
         
        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), and IPFIX does not conventionally 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 IPFIX Message 
        header increases with the number of IPFIX Data Records within 
        the SCTP stream, so loss will be detected per 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 Template defined within the 
        whole SCTP association, then there is no way of knowing which 
        Template any lost Data Record is 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. 
      
        Note that a workaround allowed by the IPFIX specifications 
        [RFC5101] is to use only one Template Record per SCTP Transport 

      
      
     <Claise, et. Al>         Expires Nov 31, 2010             [Page 7] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        Session, at the cost of multiplying the number of SCTP Transport 
        Sessions when multiple Template Records are required. 
      
         
     3.1.2. IPFIX Export per SCTP Stream Advantage 

        Using the specification in this document, it is guaranteed that 
        any lost Data Records will be associated only with the Templates 
        that are defined on that SCTP  stream. By defining only one 
        Template per SCTP stream, it is ensured that any loss is 
        associated with that single Template.  So, by exporting each 
        Template and the corresponding Data Records within a different 
        SCTP 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 an SCTP 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.  [RFC5101] specifies: 
         
           "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 
        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."  
      
         

      
      
     <Claise, et. Al>         Expires Nov 31, 2010             [Page 8] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

     3.2.2. IPFIX Export per SCTP Stream Advantages 

        By exporting each Template Record and the corresponding Data 
        Records within a single SCTP 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 an SCTP 
        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 
        SCTP stream. 
         
        Another advantage of the new specifications in this document 
        is a reduced load on the Collecting Process.  Indeed, the 
        Collecting Process doesn't have to store the Data Records 
        while waiting for the Template Record, 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 SCTP stream(s) on which the Template 
        Set, Options Template Set, and corresponding Data Sets are 
        exported, implies that the (Options) Template Record might be 
        exported on a different SCTP stream than the corresponding 
        Data Records.  This might cause Data Record loss in the 
        Collecting Process as ordered transmission across SCTP 
        streams is not guaranteed.  
      
        For example, a Template Record may be blocked pending 
        reliable transmission on one SCTP stream while the 
        corresponding Data Records may be transmitted immediately in 
        another SCTP stream.  Also, due to different SCTP stream 
        congestion, it is possible that even if the Template Record 
        and corresponding Data Records are sent reliably, Data 

      
      
     <Claise, et. Al>         Expires Nov 31, 2010             [Page 9] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        Records sent on a different SCTP 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 all corresponding Data 
        Records within a single SCTP stream, and imposing in-order 
        transmission, the issue of ordered transmission across 
        multiple SCTP streams is avoided. 
         
        By exporting all corresponding Data Records within the same 
        ordered SCTP stream as the Template Record, each SCTP stream is 
        independent and self-contained and the interaction between SCTP 
        streams is limited to that of Options Template and associated 
        Data Records sent in different streams.  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 the buffering of Data Sets which correspond 
        with Templates that are missing). 
         
         
     4. Specifications 

        This section specifies Exporting Process and Collecting Process 
        behavior different from that in [RFC5101] in order to realize 
        the benefits of per-stream export. Note that Exporting Processes 
        following these specifications will interoperate with [RFC5101]-
        compliant Collecting Processes, but that Collecting Processes 
        will have to follow additional non-interoperable specifications 
        to realize the full benefits of the technique.  These new 
        specifications, which add to those in [RFC5101], are described 
        with the key words described in [RFC2119]. 
         
         
     4.1. New Information Element 

        dataRecordsReliability 
         
           Description: 
                The export reliability of Data Records, within this SCTP 
                stream, for the element(s) in the Options Template 
                scope.  A typical example of element for which the 
                export reliability must be reported is the templateID, 
                as a specified in the Data Record Reliability  Options 
      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 10] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

                Template.  A value of 'true' means that the Exporting 
                Process MUST send any Data Records associated with the 
                element(s) reliably within this SCTP stream.  A value of 
                'false' means that the Exporting Process MAY send any 
                Data Records associated with the element(s) unreliably 
                within this SCTP stream. 
                 
           Abstract Data Type: boolean 
           Data Type Semantics: identifier 
           ElementId: XXX 
           Status: current 
         
        IANA NOTE: IANA should replace XXX with the assigned value 
         

     4.2. Template Management 

     To take advantage of per-stream export, Exporting Processes MUST 
     follow the specification in this section in addition to Section 8, 
     Template Management, of [RFC5101]. 
        As specified in [RFC5101], Template Sets and Options Template 
        Sets MUST be sent reliably.   
         
        Any Data Sets associated with a Template Record MUST be sent on 
        the same SCTP stream on which the Template Record was sent. 
         
        The Data Record Reliability Options Template is used to 
        explicitly inform the Collecting Process which Templates will be 
        used in each SCTP stream and whether each set of associated Data 
        Records will be sent reliably or unreliably.  Before sending any 
        Data Records on an SCTP stream, the Exporting Process MUST 
        notify the Collecting Process of its intention to send those 
        Data Records reliably or unreliably within that SCTP stream.  It 
        does this by sending a Data Record defined by the Data Record 
        Reliability Options Template for the Template associated with 
        Data Records to be sent.  The one exception to this rule is that 
        the Data Records associated with the Data Record Reliability 
        Options Template don't require an explicit notification as these 
        MUST always be sent reliably. 
         
        The Data Record Reliability Options Template MUST contain the 
        following Information Elements: 
      
         Scope:     Template ID  
         Non-scope: dataRecordsReliability 
         
      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 11] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        A value of 'true' for the dataRecordsReliability Element means 
        that the Exporting Process MUST send any Data Records associated 
        with the Template ID reliably within this SCTP stream.  A value 
        of 'false' for the dataRecordsReliability Element means that the 
        Exporting Process MAY send any Data Records associated with the 
        Template ID unreliably within this SCTP stream. 
         
        If the Exporter wants to change the export reliability value 
        (from reliable to unreliable, or vice-versa) for Data Records on 
        an SCTP stream, the Template MUST be withdrawn, and a new 
        Template MUST be used. 
         
        The Data Record Reliability Options Template MAY contain other 
        non-scope Information Elements associated with the (Options) 
        Template. 
         
        When an Options Template, including the Data Record Reliability 
        Options Template, and associated Data Records are sent in the 
        same SCTP stream, the first associated Data Record can follow 
        the Options Template immediately.  When the Options Template and 
        associated Data Records are sent in different SCTP streams, the 
        Exporting Process SHOULD transmit the Options Template in 
        advance of any Data Sets that use it, to help ensure that the 
        Collector has received the Options Template Record before 
        receiving the first associated Data Record. 
         
        It is RECOMMENDED that the Exporter only sends a single Template 
        and corresponding Data Sets within a single SCTP stream in order 
        to enable calculation of the potential Data Record loss for this 
        Template.  The Exporter MAY group related (Options) Templates 
        and their associated Data Records within a single SCTP stream so 
        that loss statistics are calculated for the group of Templates 
        that are being sent unreliably within the SCTP stream.  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 SCTP streams to export each 
        Template in its own SCTP stream. 
      
        If an SCTP stream contains a mixture of Data Records defined by 
        Template Records and Options Template Records, the Data Records 
        defined by the Options Template Records SHOULD be sent reliably 
        so that the Collector does not consider any loss to be 
        associated with the options Data Records. 
      
         

      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 12] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

     4.3. SCTP 

        To take advantage of per-stream export, Exporting Processes MUST 
        manage SCTP streams according to the specification in this 
        section, in addition to Section 10.2.4.3, Stream, of [RFC5101]. 
         
        PR-SCTP [RFC3758] MUST be implemented by all compliant 
        implementations. 
         
     All IPFIX Messages in an SCTP stream MUST be sent in order. 
        As specified in [RFC5101], depending on the requirements of the 
        application, the Exporting Process may send Data Sets with full 
        or partial reliability.   
         
        If the Exporting Process is required to export a new Template 
        Record but there are no more free SCTP streams available, it 
        SHOULD attempt to increase the number of outbound SCTP 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 SCTP stream at the cost of diluting the granularity 
        of Data Records loss.   An alternative, which may result in the 
        loss of Flow Records (for example, due to lack of buffering on 
        the Exporter), is to restart the SCTP association with an 
        increased number of SCTP streams.   
         
         
     4.4. Template Withdrawal Message 

        To take advantage of per-stream export, Exporting Processes MUST 
        send Template Withdrawal Messages according to the specification 
        in this section, in addition to Section 8, Template Management, 
        of [RFC5101]. 
         
        As specified in [RFC5101], Templates which 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 SCTP 
        stream as the associated 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 an SCTP stream (per the specifications 
        in this document), the IPFIX Message containing the Template 
        Withdrawal Message will not arrive at the Collecting Process 
      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 13] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        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 SCTP 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 reusing the Template ID, the Exporting Process MUST send a 
        Data Record associated with the Data Record Reliability Options 
        Template to specify the reliability level of the Data Records 
        associated with the new Template.  
      
        If the Template ID is to be reused on a different SCTP stream, 
        the new Template Record 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 under the condition that all the Template IDs 
        in the Template Withdrawal Message are used on the same SCTP 
        stream as the Template Withdrawal Message. 
      
         
     4.5. The Collecting Process's Side 

        Collecting Processes must operate slightly contrary to [RFC5101] 
        in order to realize the full benefits of per-stream export. 
        However, the specification in this section contains a mechanism 
        which allows per-stream-capable Collecting Processes to 
        selectively enable per-stream export, in order to ensure 
        interoperability of per-stream-capable Collecting Processes with 
        Exporting Processes which do not implement per-stream export. 
         
        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 SCTP streams to use 
        for export. 
         
        A Collecting Process SHOULD support the procedure for the 
        addition of an SCTP stream [SCTP-RESET]. 
         

      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 14] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        In IPFIX, there is no explicit notification of the Exporting 
        Process's capabilities.  There is also no return channel for the 
        Collecting Process to communicate its capabilities.  
         
        In the case where the Exporting Process uses the per-SCTP-stream  
        extension, the first Data Record received by the Collecting 
        Process MUST be associated with the Data Records Reliability 
        Options Template. If the first Data Record is associated with 
        any other (Options) Template, the Collecting Process MUST 
        disable the extension for the specific Exporter on the 
        Collecting side. 
      
        The Collecting Process MUST accept other non-scope Information 
        Elements in the Data Record Reliability Options Template. 
         
        As specified in [RFC5101], the IPFIX protocol has a Sequence 
        Number field in the IPFIX Message header that increases with the 
        number of IPFIX Data Records in the IPFIX Message.  A Collector 
        may detect out-of-sequence, dropped, or duplicate IPFIX Messages 
        by tracking the Sequence Number.  
         
        When one or more sequential IPFIX Messages are considered lost, 
        the number of lost Data Records is equal to the Sequence Number 
        of the first IPFIX Message Header following the lost packets 
        (S2) minus the Sequence Number of the first lost IPFIX Message 
        (S1).  The Sequence Number of the first lost IPFIX Message can 
        be calculated as the Sequence Number of the last IPFIX Message 
        before the sequence of lost IPFIX Messages (S0) plus the number 
        of Data Records in that IPFIX Message (N0).  
         
               S1 = S0 + N0 
               loss = (S2 - S1) (mod 2^32) 
                    = (S2 - (S0 + N0)) (mod 2^32) 
         
        Note that molulo 2^32 arithmetic is required since the Sequence 
        Number may wrap once or multiple times in the series of lost 
        IPFIX Messages.  If less than 2^32 Data Records are lost in a 
        sequence (which can be assumed in practice), the above equation 
        returns the exact number of lost Data Records. 
         
        Note that using a unsigned32 type for the loss would 
        automatically take care of the mod(2^32) operation. 
         
        As this Sequence Number is incremented per SCTP stream, the loss 
        of Data Records sent in that SCTP stream can be calculated in 
        case of partially-reliable export.  This loss can be attributed 

      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 15] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        to the Data Records sent for the (Options) Template(s) whose 
        records are being sent unreliably within that SCTP stream. 
         
        Once the Collecting Process receives a Data Record Reliability 
        Options Data Record for a particular Template, if the Collecting 
        Process receives a Data Record or a Template Withdrawal Message 
        for the same Template on a different SCTP stream, then the 
        Collecting Process SHOULD log an error message and 'disable' 
        this extension for the SCTP association. 
         
         
     5. Performance Impact 

        Although adding the new SCTP streams requires a message 
        exchange, it is more lightweight to set up additional SCTP 
        streams than to set up a new SCTP association since the only 
        overhead of adding SCTP stream(s) to an existing SCTP 
        association is the addition of 16-24 more bytes (allocated in 
        the SCTP association, a single time), whereas setting up a new 
        SCTP association implies more overhead.  
         
        In terms of throughput impact, the fact that these 
        specifications discourage multiplexing Templates and Data 
        Records of different Template IDs may lead to a slightly larger 
        IPFIX Message overhead.  If the Data Record rate is low for a 
        specific Template (hence a specific SCTP stream), the Exporting 
        Process might not be able to fill the IPFIX Messages with Data 
        Records associated with other Templates.  In such a situation, 
        there is a potential overhead due to additional IPFIX Message 
        headers and SCTP chunk headers. 
         
        Finally, with respect to the processing overhead on the 
        Exporter, a lot of state information must be stored when a large 
        number of SCTP streams are used within an SCTP association.  
        However, no comparison of the performance impact of multiple 
        streams within an SCTP association versus opening the same 
        number of independent SCTP associations is available. 
      
         
     6. Guidelines for IPFIX per-SCTP-stream Extension Testing 

        This section specifies guidelines for a series of tests that can 
        be run on the Collecting Process in order to probe the 
        conformity and robustness of the IPFIX per-SCTP-stream extension 
        protocol implementations. 
         

      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 16] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        For example, nothing prevents an implementation that does not 
        meet the specification of the per-SCTP-stream extension from 
        sending a Template that looks like a dataRecordsReliability 
        Options Template.  Therefore, a Collecting Process MUST detect 
        if the Exporter fails to meet the specification fully.  If any 
        of the conditions below is met, the Exporting Process does not 
        properly use the per-SCTP-stream extension, and the Collecting 
        Process MUST report an error message: 
              
            1. A Data Record is received before the appropriate Data 
            Record associated with the Data Records Reliability Options 
            Template has been received on the same SCTP stream (see 
            section 4.1). 
             
            2. A Data Record associated with a Data Record 
            ReliabilityOptions Template is received on an SCTP stream 
            for a (non-Options) Template that was defined on a 
            different SCTP stream. 
                  
            3. Loss of Data Records is detected within a stream where 
            there has not been received a Data Record associated with 
            the Data Record Reliability Options Template indicating 
            unreliable transmission for any template. 
                  
            4. A message is received with the SCTP U(nordered) flag set 
            to 1, (i.e., the message was sent unordered) even if it 
            isprocessed in order. 
      
         
     7. Examples 

        Figure 1 shows an example where SCTP 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 Options Template with Template ID 257 is transmitted 
        with full reliability (FR).  Its corresponding Data Set contains 
        one Data Record. 
        Record 1: 
          
             o Scope:     Template ID = 256 
             o Non-scope: dataRecordsReliability = False 
         
         
                      +--------+       +---------+   +--------+   
                      |        |       |         |   |        |      
        stream 10 ----| Data   | . . . |  Data   |---| Data   |---... 
      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 17] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

                      |   256  |       |    256  |   |   257  | 
                      |      PR|       |       PR|   |      FR|       
                      +--------+       +---------+   +--------+  
         
         
         
         
         
                             +----------+       +------------+ 
                             |          |       | Options    | 
                             |          |       | Reliability|  
                       ...---| Template |-------| Template   |------> 
                             |     256  |       |        257 | 
                             |        FR|       |          FR| 
                             +----------+       +------------+ 
         
                                  Figure 1    
         
        Note that Template 256 will always be processed before the Data 
        Records by the Collecting Process because all IPFIX Messages are 
        sent in order within an SCTP stream.  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 Options 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 or 
        associated with the Data Record), the Options Template Record 
        should be sent in the same SCTP stream, as displayed in figure 
        2. 
         
         
                         +--------+   +--------+     +--------+ 
                         |        |   |        |     |        | 
           stream 20 ----| Data   |...| Data   |-----| Data   |--- ... 
                         |   260  |   |   260  |     |   259  | 
                         |      PR|   |      PR|     |      FR| 
                         +--------+   +--------+     +--------+ 
         
                                +--------+       +----------+ 
                                |        |       |          | 
                          ...---| Data   |-------| Template |---... 
                                |   258  |       |     260  | 
                                |      FR|       |        FR| 
                                +--------+       +----------+ 
         
      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 18] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

         
                             +----------+       +-------------+ 
                             | Options  |       | Options     | 
                             | Template |       | Reliability | 
                       ...---|          |-------| Template    |------> 
                             |     259  |       |        258  | 
                             |        FR|       |           FR| 
                             +----------+       +-------------+ 
         
         
         
                                     Figure 2               
         
        Figure 2 shows an example where SCTP stream 20 carries:  
        -  a Data Record Reliability Options Template with Template ID 
           258, transmitted with full reliability (FR) 
        -  an Options Template Record with Template ID 259 transmitted 
           with full reliability.  This Options Template Record contains 
           additional information related to the subsequent Data Records 
           based on Template ID 260.  Typical examples are the Common 
           Properties information [RFC5473] or a Selector Report 
           Interpretation [RFC5476]. 
        -  a Template Record with Template ID 260, transmitted with full 
           reliability.    
        -  a Data Set specified by the Reliability Options Template with 
           Template ID 258 transmitted with full reliability.   
           The Data Set contains three Data Records. 
           Record 1: 
             o Scope:     Template ID = 258 
             o Non-scope: dataRecordsReliability = True 
           Record 2:  
             o Scope:     Template ID = 259 
             o Non-scope: dataRecordsReliability = True 
           Record 3:  
             o Scope:     Template ID = 260 
             o Non-scope: dataRecordsReliability = False 
           These Data Records inform 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. 
        -  a Data Record specified by Template ID 259, transmitted with 
           full reliability  
        -  a Data Record specified by Template ID 260, transmitted with 
           partial reliability  
         
        If the Collector observes some Data Record loss using the 
        Sequence Number, the loss can only stem from the Data Records 
        associated with Template ID 260, as these are the only Data 
      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 19] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        Records not exported reliably.  Therefore, the calculation of 
        loss per Template ID 260 is possible.  
         
        Note that the Options Templates 258, 259, and 260 will always 
        arrive before their associated Data Records, respectively, 
        because all IPFIX Messages must be sent in order within an SCTP 
        stream. 
      
        Figure 3 shows an example where SCTP stream 30 carries a 
        Template Record with Template ID 262 transmitted with full 
        reliability (FR), an associated Data Record transmitted with 
        full reliability (FR), a Template Withdrawal Message, followed 
        by a redefinition of the Template ID 262, and finally the Data 
        Record associated with the new Template transmitted with partial 
        reliability.  The Template Withdrawal Message and the new 
        definition of the Template ID 262 are sent immediately, without 
        waiting for the Template Reuse Delay. 
         
         
         
                         +--------+   +----------+     +----------+     
                         |        |   |Data      |     |          |     
        stream 30 ... ---| Data   |...|  261     |-----| Template |--- 
                         |   262  |   |tmpID: 262|     |    262   |    
                         |      PR|   |dRR: false|     |        FR|    
                         +--------+   +----------+     +----------+   
         
                   +----------+     +--------+       +----------+ 
                   | Template |     |        |       | Data     | 
                ...| Withdraw |-----| Data   |-------|   261    |---... 
                   |    262   |     |   262  |       |tmpID: 262| 
                   |        FR|     |      FR|       |dRR:  true| 
                   +----------+     +--------+       +----------+ 
         
         
                             +----------+       +-------------+ 
                             |          |       | Options     | 
                             | Template |       | Reliability | 
                       ...---|          |-------| Template    |------> 
                             |     262  |       |        261  | 
                             |        FR|       |           FR| 
                             +----------+       +-------------+ 
               
                                     Figure 3    
         
        The second Data Record associated with the Data Record 
        Reliability Options Template shows that the Data Records 
      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 20] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

        associated with the newly specified Template ID 262, will be 
        sent unreliably. 
                  
         
     8. IANA Considerations 

        According to the process defined in [RFC5102], IANA will 
        allocate the dataRecordsReliability Information Element defined 
        in Section 4.1.  in the IANA IPFIX Information Elements 
        registry. 
         
         
     9. Security Considerations 

        The same security considerations as for the IPFIX Protocol 
        [RFC5101] apply. 
         
         
     10. References 

     10.1. Normative References 

        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 
                Requirement Levels, BCP 14, RFC 2119, March 1997 
         
        [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., and P. 
                Conrad, "Stream Control Transmission Protocol (SCTP), 
                Partial Reliability Extension", May 2004 
         
        [RFC4960] Stewart, R., Ed., "Stream Control Transmission 
                Protocol", RFC 4960, September 2007. 
      
        [RFC5101] Claise, B., Ed., "Specification of the IP Flow 
                Information Export (IPFIX) Protocol for the Exchange of 
                IP Traffic Flow Information", RFC 5101, January 2008. 
      
        [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and 
                J. Meyer, "Information Model for IP Flow Information 
                Export", RFC 5102, January 2008. 
      
        [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini S., and 
                F. Raspall, "Sampling and Filtering Techniques for IP 
                Packet Selection", RFC5475, March 2009 
         
        [SCTP-RESET] Stewart, R., Lei, P., Tuexen, M, "Stream Control 
                Transmission Protocol (SCTP) Stream Reconfiguration", 

      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 21] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

                draft-ietf-tsvwg-sctp-strrst-04, Internet-Draft work in 
                progress, February 2010 
      
         
     10.2. Informative References 

         
        [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 
                Requirements for IP Flow Information Export, RFC 3917, 
                October 2004 
         
        [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 
                Quittek, "Architecture Model for IP Flow Information 
                Export", RFC5470, March 2009 
         
        [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 
                "IP Flow Information Export (IPFIX) Applicability", RFC 
                5472, March 2009 
         
        [RFC5477] T. Dietz, F. Dressler, G. Carle, and B. Claise, 
                "Information Model for Packet Sampling Exports", RFC 
                5477, March 2009 
         
        [RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet 
                Sampling (PSAMP) Protocol Specifications", RFC 5476, 
                March 2009. 
         
        [RFC5474] Chiou, D., Claise, B., Duffield, N., Greenberg, A.,  
                Grossglauser, M., Marimuthu, P., Rexford, J., and G. 
                Sadasivan,  RFC 5474, March 2009 
         
        [RFC5473] Boschi, E., Mark, L., and B. Claise, " Reducing 
                Redundancy in IP Flow Information Export (IPFIX) and 
                Packet Sampling (PSAMP) Reports", RFC 5473, March 2009 
         
        [PSAMP-MIB] Dietz, T., and B. Claise, "Definitions of Managed 
                Objects for Packet Sampling", Internet-Draft work in 
                progress, June 2006 
         

     11. Acknowledgements 

        The authors would like to thank Brian Trammell for his expert 
        feedback and continuous effort to improve the specifications, 
        Elisa Boschi for her thorough reading, and Randall Stewart, 
        Peter Lei, Michael Tuexen for their SCTP-related feedback and 
        expertise, and Tobias Limmer. 
      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 22] 
         

     Internet-Draft      <IPFIX Export per SCTP Stream>        May 2010 
         

         
         
     12. Author's Addresses 

        Benoit Claise 
        Cisco Systems Inc. 
        De Kleetlaan 6a b1 
        Diegem 1813 
        Belgium 
            
        Phone: +32 2 704 5622 
        Email: bclaise@cisco.com 
      
      
        Paul Aitken 
        Cisco Systems (Scotland) Ltd. 
        96 Commercial Quay 
        Commercial Street 
        Edinburgh, EH6 6LX, United Kingdom 
            
        Phone: +44 131 561 3616 
        Email: paitken@cisco.com 
         
         
        Andrew Johnson 
        Cisco Systems (Scotland) Ltd. 
        96 Commercial Quay 
        Commercial Street 
        Edinburgh, EH6 6LX, United Kingdom 
            
        Phone: +44 131 561 3641 
        Email: andrjohn@cisco.com 
         
         
        Gerhard Muenz 
        Technische Universitaet Muenchen 
        Departement of Informatics - I8 
        Boltzmannstr. 3 
        Garching D-85748 
        DE 
         
        Phone: +49 89 289-18008 
        Email: muenz@net.in.tum.de 
        URI: http://www.net.in.tum.de/~muenz 
      

      
      
     <Claise, et. Al>         Expires Nov 31, 2010            [Page 23]