IPFIX Working Group                                    B. Claise 
     Internet-Draft                                     G. Dhandapani 
     Intended Status: Standard Track                         S. Yates 
     Expires: January 30, 2010                              P. Aitken  
                                                  Cisco Systems, Inc. 
                                                        July 30, 2009 
      
                       Export of Structured Data in IPFIX 
                    draft-claise-structured-data-in-ipfix-02 


     Status of this Memo 

        This Internet-Draft is submitted to IETF in full conformance 
        with the provisions of BCP 78 and BCP 79.  
         
        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups.  Note that other groups may also distribute working 
        documents as Internet-Drafts.  
         
        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other 
        documents at any time.  It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as "work 
        in progress."  
         
        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
         
        The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html  
         
        This Internet-Draft will expire on January, 2010.



















     <Claise, et. Al>       Expires January 30 2010           [Page 1] 
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

         
     Copyright Notice 
         
        Copyright (c) 2009 IETF Trust and the persons identified as the 
        document authors.  All rights reserved. 
         
        This document is subject to BCP 78 and the IETF Trust's Legal 
        Provisions Relating to IETF Documents in effect on the date of 
        publication of this document (http://trustee.ietf.org/license-
        info).  Please review these documents carefully, as they 
        describe your rights and restrictions with respect to this 
        document.                      
      

     Abstract 

        This document specifies an extension to IP Flow Information 
        eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 
        information model specified in [RFC5102] to support hierarchical 
        structured data and lists (sequences) of Information Elements in 
        data records.  This extension allows definition of complex data 
        structures such as variable-length lists and specification of 
        hierarchical containment relationships between Templates. 
         
         
     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]. 
      















      
      
     <Claise, et. Al>      Expires December 30, 2009          [Page 2] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

     Table of Contents 

         
        1. Overview....................................................6 
           1.1. IPFIX Documents Overview...............................6 
           1.2. Relationship between IPFIX and PSAMP...................6 
        2. Terminology.................................................7 
           2.1. New Terminology........................................7 
        3. Introduction................................................7 
           3.1. The IPFIX Track........................................8 
           3.2. The IPFIX Limitations..................................9 
           3.3. The Proposal..........................................11 
        4. Linkage with the Information Model.........................12 
           4.1. New Abstract Data Types...............................12 
              4.1.1. basicList........................................12 
              4.1.2. subTemplateList..................................12 
              4.1.3. subTemplateMultiList.............................13 
           4.2. New Data Type Semantic................................13 
              4.2.1. List.............................................13 
           4.3. New Information Elements..............................13 
              4.3.1. basicList........................................13 
              4.3.2. subTemplateList..................................13 
              4.3.3. subTemplateMultiList.............................14 
           4.4. Encoding of IPFIX Data Types..........................14 
              4.4.1. basicList........................................14 
              4.4.2. subTemplateList..................................16 
              4.4.3. subTemplateMultiList.............................18 
        5. Structured Data Format.....................................20 
           5.1. Length Encoding Considerations........................20 
           5.2. Recursive Structured Data.............................21 
           5.3. Structured Data Information Elements Applicability in 
           Options Template Sets......................................21 
           5.4. Usage Guidelines for Equivalent Data Representations..22 
           5.5. Padding...............................................23 
        6. Template Management........................................23 
        7. The Collecting Process's Side..............................24 
        8. Structured Data Encoding Examples..........................24 
           8.1. Encoding BasicList....................................24 
           8.2. Encoding subTemplateList..............................25 
           8.3. Encoding subTemplateMultiList.........................28 
           8.4. Encoding As Scope.....................................32 
        9. Relationship with the Other IFPIX Documents................35 
           9.1. Relationship with Reducing Redundancy.................35 
              9.1.1. Encoding Common Properties elements With Structured 
              Data Element............................................35 
              9.1.2. Encoding Structured Data Element using Common 
              Properties..............................................35 
      
      
     <Claise, et. Al>      Expires December 30, 2009          [Page 3] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

           9.2. Relationship with Guidelines for IPFIX Testing........36 
           9.3. Relationship with Bidirectional Flow Export...........37 
           9.4. Relationship with IPFIX Mediation Function............37 
        10. IANA Considerations.......................................37 
           10.1. New Abstract Data Types..............................37 
              10.1.1. basicList.......................................38 
              10.1.2. subTemplateList.................................38 
              10.1.3. subTemplateMultiList............................38 
           10.2. New Data Type Semantics..............................38 
              10.2.1. list............................................38 
           10.3. New Information Elements.............................39 
              10.3.1. basicList.......................................39 
              10.3.2. subTemplateList.................................39 
              10.3.3. subTemplateMultiList............................39 
        11. Security Considerations...................................40 
        12. References................................................40 
           12.1. Normative References.................................40 
           12.2. Informative References...............................40 
        13. Acknowledgement...........................................41 
        14. Authors' Addresses........................................41 
        Appendix A.  XML Specification of IPFIX Information Elements 
        and Abstract Data Types.......................................42 
         
      























      
      
     <Claise, et. Al>      Expires December 30, 2009          [Page 4] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

     Table of Figures 

     Figure A: basicList Information Element Encoding.................15 
     Figure B: basicList Encoding with Enterprise Number..............15 
     Figure C: Variable-Length basicList Information Element Encoding 
        (Length < 255 octets)........................................16 
     Figure D: Variable-Length basicList Information Element Encoding 
        (Length 0 to 65535 octets)...................................16 
     Figure E: subTemplateList Encoding...............................17 
     Figure F: Variable-Length subTemplateList Information Element 
        Encoding (Length < 255 octets)...............................18 
     Figure G: Variable-Length subTemplateList Information Element 
        Encoding (Length 0 to 65535 octets)..........................18 
     Figure H: subTemplateMultiList Encoding..........................19 
     Figure I: Variable-Length subTemplateMultiList Information Element 
        Encoding (Length < 255 octets)...............................20 
     Figure J: Variable-Length subTemplateMultiList Information Element 
        Encoding (Length 0 to 65535 octets)..........................20 
     Figure K: Encoding basicList, Template Record....................25 
     Figure L: Encoding basicList, Data Record........................25 
     Figure M: Encoding subTemplateList, Template for One-Way Delay 
        Metrics......................................................26 
     Figure N: Encoding subTemplateList, Template Record..............27 
     The list of (observationTimeMicroseconds, digestHashValue) is 
        exported as a subTemplateList. The Length of the subTemplatelist 
        is chosen to be encoded in three bytes even though it may be 
        less than 255 octets.........................................27 
     The Data Record is represented as follows:.......................27 
     Figure O: Encoding subTemplateList, Data Set.....................28 
     Figure P: Encoding subTemplateMultiList, Template for Target.....30 
     Figure Q: Encoding subTemplateMultiList, Template for Attacker...30 
     Figure R: Encoding subTemplateMultiList, Template for Participant30 
     Figure S: Encoding subTemplateMultiList, Template for IPS Alert..31 
     Figure T: Encoding subTemplateMultiList, Data Set................32 
     Figure U: PSAMP SSRI to be encoded...............................33 
     Figure V: Options Template record for PSAMP SSRI.................33 
     Figure W: PSAMP SSRI, Template record for interface list.........34 
     Figure X: PSAMP SSRI, Template record for linecard list..........34 
     Figure Y: PSAMP SSRI, Template record for interface and linecard 
        list.........................................................34 
     Figure Z: Example of a Selection Sequence Report Interpretation 
        Data Record, Encoded using a subTemplateMultiList............35 
      




      
      
     <Claise, et. Al>      Expires December 30, 2009          [Page 5] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      
     1. Overview 

     1.1. IPFIX Documents Overview 

      The IPFIX Protocol [RFC5101] provides network administrators with 
      access to IP Flow information. 
       
      The architecture for the export of measured IP Flow information 
      out of an IPFIX Exporting Process to a Collecting Process is 
      defined in the IPFIX Architecture [RFC5470], per the requirements 
      defined in RFC 3917 [RFC3917]. 
       
      The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records 
      and Templates are carried via a congestion-aware transport 
      protocol from IPFIX Exporting Processes to IPFIX Collecting 
      Processes. 
       
      IPFIX has a formal description of IPFIX Information Elements, 
      their name, type and additional semantic information, as specified 
      in the IPFIX information model [RFC5102]. 
       
      In order to gain a level of confidence in the IPFIX 
      implementation, probe the conformity and robustness, and allow 
      interoperability, the Guidelines for IPFIX Testing [RFC5471] 
      presents a list of tests for implementers of compliant Exporting 
      Processes and Collecting Processes. 
      
      The Bidirectional Flow Export [RFC5103] specifies a method for 
      exporting bidirectional flow (biflow) information using the IP 
      Flow Information Export (IPFIX) protocol, representing each Biflow 
      using a single Flow Record. 
       
      The "Reducing Redundancy in IP Flow Information Export (IPFIX) and 
      Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth 
      saving method for exporting Flow or packet information, by 
      separating information common to several Flow Records from 
      information specific to an individual Flow Record: common Flow 
      information is exported only once. 
      
      
     1.2. Relationship between IPFIX and PSAMP 

      The specification in this document applies to the IPFIX protocol 
      specifications [RFC5101].  All specifications from [RFC5101] apply 
      unless specified otherwise in this document. 
       
      
      
     <Claise, et. Al>      Expires December 30, 2009          [Page 6] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      The Packet Sampling (PSAMP) protocol [RFC5476] specifies the 
      export of packet information from a PSAMP Exporting Process to a 
      PSAMP Collecting Process.  Like IPFIX, PSAMP has a formal 
      description of its information elements, their name, type and 
      additional semantic information.  The PSAMP information model is 
      defined in [RFC5477]. 
      
      As the PSAMP protocol specifications [RFC5476] are based on the 
      IPFIX protocol specifications, the specifications in this document 
      are also valid for the PSAMP protocol.  
        
      Indeed, the major difference between IPFIX and PSAMP is that the 
      IPFIX protocol exports Flow Records while the PSAMP protocol 
      exports Packet Reports.  From a pure export point of view, IPFIX 
      will not distinguish a Flow Record composed of several packets 
      aggregated together, from a Flow Record composed of a single 
      packet.  So the PSAMP export can be seen as a special IPFIX Flow 
      Record containing information about a single packet. 
      
      
     2. Terminology 

      IPFIX-specific terminology used in this document is defined in 
      section 2 of the IPFIX protocol specification [RFC5101] and 
      section 3 of PSAMP protocol specification [RFC5476].  As in 
      [RFC5101], these IPFIX-specific terms have the first letter of a 
      word capitalized when used in this document. 
       
       
     2.1. New Terminology 

      Structured Data Information Element 
       
          One of the Information Elements supporting structured data, 
          i.e., the basicList, subTemplateList, or subTemplateMultiList 
          Information Elements as defined in section 4.3.  
      
      
     3. Introduction 

      While collecting the interface counters every five minutes has 
      proven to be useful in the past, more and more granular 
      information is required from network elements for a series of 
      applications: performance assurance, capacity planning, security, 
      billing, or simply monitoring.  However, the amount of information 
      has become so important that, when dealing with highly granular 
      information such as Flow information, a push mechanism (as opposed 
      
      
     <Claise, et. Al>      Expires December 30, 2009          [Page 7] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      to a pull mechanism, such as SNMP) is the only solution for 
      routers... whose primary function is to route packet.  Indeed, 
      polling short-live Flows via SNMP is not an option: high end 
      routers can support hundreds of thousands of Flows simultaneously.  
      Furthermore, in order to reduce the export bandwidth requirements, 
      the network elements have to integrate mediation functions, to 
      aggregate the collected information, both in space and time. 
       
      Typically, it would be beneficial if access routers could export 
      Flow Records, composed of the counters before and after the WAN 
      optimization mechanism, instead of exporting two Flow Records with 
      identical tuple information. 
       
      In terms of aggregation in time, let us imagine that, for 
      performance assurance, the network management application must 
      receive the performance metrics associated with a specific flow, 
      every millisecond.  Since the performance metrics will be 
      constantly changing, there is a new dimension to the Flow 
      definition: we are not dealing anymore with a single Flow lasting 
      a few seconds or a few minutes, but with a multitude of one 
      millisecond sub flows for which the performance metrics are 
      reported. 
                        
      Which current protocol is suitable for these requirements: push 
      mechanism, highly granular information, and huge number of similar 
      records? IPFIX, as specified in RFC5101 would give part of the 
      solution. 
       
      
     3.1. The IPFIX Track 

      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.).   
       
      The IPFIX protocol specification [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.   
       
      Based on the Requirements for IP Flow Information Export (IPFIX) 
      [RFC3917], the IPFIX protocol has been optimized to export Flow 
      related information.  However, thanks to its Template mechanism, 
      
      
     <Claise, et. Al>      Expires December 30, 2009          [Page 8] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      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.  For each Information 
      Element, the IPFIX information model [RFC5102] defines a numeric 
      identifier, an abstract data type, an encoding mechanism for the 
      data type, and any semantic constraints.  Only basic, single-
      valued data types, e.g., numbers, strings, and network addresses 
      are currently supported. 

      
     3.2. The IPFIX Limitations 

      The IPFIX protocol specification [RFC5101] does not support the 
      encoding of hierarchical structured data and arbitrary-length 
      lists (sequences) of Information Elements as fields within a 
      Template Record.  As it is currently specified, a Data Record is a 
      "flat" list of single-valued attributes.  However, it is a common 
      data modeling requirement to compose complex hierarchies of data 
      types, with multiple occurrences, e.g., 0..* cardinality allowed 
      for instances of each Information Element in the hierarchy.  

      A typical example is the MPLS label stack entries model.  An early 
      NetFlow implementation used two Information Elements to represent 
      the MPLS label stack entry: a "label stack entry position" 
      followed by a "label stack value".  However, several drawbacks 
      were discovered.  Firstly, the Information Elements in the 
      Template Record had to be imposed so that the position would 
      always precede the value.  However, some encoding optimizations 
      are based on the permutation of Information Element order.  
      Secondly, a new semantic intelligence, not described in the 
      information model, had to be hardcoded in the Collecting Process: 
      the label value at the position "X" in the stack is contained in 
      the "label stack value" Information Element following by a "label 
      stack entry position" Information Element containing the value 
      "X".  Therefore, this model was abandoned. 
       
      The selected solution in the IPFIX information model [RFC5102] is 
      a long series of Information Elements: mplsTopLabelStackSection, 
      mplsLabelStackSection2, mplsLabelStackSection3, 
      mplsLabelStackSection4, mplsLabelStackSection5, 
      mplsLabelStackSection6, mplsLabelStackSection7, 
      mplsLabelStackSection8, mplsLabelStackSection9, 
      mplsLabelStackSection10.  While this model removes any ambiguity, 
      it overloads the IPFIX information model with repetitive 
      information.  Furthermore, if mplsLabelStackSection11 is required, 
      IANA will not be able to assign the new Information Element next 
      
      
     <Claise, et. Al>      Expires December 30, 2009          [Page 9] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      to the other ones in the registry, which might cause some 
      confusion. 
       
      Clearly a real structured data type composed of ("label stack 
      entry position", "label stack value") pairs, potentially repeated 
      multiple times in Flow Records would be more efficient from an 
      information model point of view. 
       
      Some more examples enter the same category: how to encode the list 
      of output interfaces in a multicast Flow, how to encode the list 
      of BGP Autonomous Systems (AS) in a BGP Flow, how to encode the 
      BGP communities in a BGP Flow, etc?  
       
      The one-way delay passive measurement, which is described in the 
      IPFIX Applicability [RFC5472], is yet another example that would 
      benefit from a structured data encoding.  Assuming synchronized 
      clocks, the Collector can deduce the one-way delay from the 
      following two Information Elements, collected from two different 
      Observation Points: 
          - Packet arrival time: observationTimeMicroseconds [RFC5477] 
          - Packet ID: digestHashValue [RFC5477] 
      Ideally, the measurement at the second Observation Point should 
      start a little bit later than at the first Observation Point, 
      allowing the packets to arrive at the destination.  In practice, 
      this implies that many pairs of (observationTimeMicroseconds, 
      digestHashValue) must be exported for each Observation Point, even 
      if some optimization based on Hash-Based Filtering [RFC5475] is 
      used.  Instead of exporting repetitive information as part of 
      every single Flow Record (for example, the 5 tuple), an optimized 
      flow record composed of a structured data type such as the 
      following would save a lot of bandwidth: 
          5 tuple 
                    observationTimeMicroseconds 1, digestHashValue 1 
                    observationTimeMicroseconds 2, digestHashValue 2 
                    observationTimeMicroseconds 3, digestHashValue 3 
                    ...  , ... 
         
      As a last example, here is a more complex example of hierarchical 
      structured data encoding.  Consider the example scenario of an IPS 
      (Intrusion Prevention System) alert data structure containing 
      multiple participants, where each participant contains multiple 
      attackers and multiple targets, with each target potentially 
      composed of multiple applications, as depicted below: 
       
          alert 
              signatureId 

      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 10] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

              protocolIdentifier 
              riskRating 
              participant 1 
                  attacker 1 
                      sourceIPv4Address 
                      applicationId 
                  ... 
                  attacker N 
                      sourceIPv4Address 
                      applicationId 
                  target 1 
                      destinationIPv4Address 
                      applicationId 1 
                      ... 
                      applicationId n 
                  ... 
                  target N 
                      destinationIPv4Address 
                      applicationId 1 
                      ... 
                      applicationId n 
              participant 2 
                  ... 
       
      To export this information in IPFIX, the data would need to be 
      flattened (thus losing the hierarchical relationships) and a new 
      IPFIX Template created for each alert, according to the number of 
      applicationID elements in each target, the number of targets and 
      attackers in each participant and the number of participants in 
      each alert.  Clearly each Template will be unique to each alert, 
      and a large amount of CPU, memory and export bandwidth will be 
      wasted creating, exporting, maintaining, and withdrawing the 
      Templates.  See the Structured Data encoding examples in section 
      8. for specific examples related to this case study. 
      
      
     3.3. The Proposal 

      This document specifies an IPFIX extension to support hierarchical 
      structured data and variable-length lists by defining three new 
      Information Elements and three corresponding new abstract data 
      types called basicList, subTemplateList, and subTemplateMultiList. 
      These are defined in section 4.1. New Abstract Data Types. 

      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 11] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

       
      It is important to note that whereas the Information Elements and 
      abstract data types defined in the IPFIX information model 
      [RFC5102] represent single values, these new abstract data types 
      are structural in nature and primarily contain references to other 
      Information Elements and to Templates.  By referencing other 
      Information Elements and Templates from an Information Element's 
      data content, it is possible to define complex data structures 
      such as variable-length lists and to specify hierarchical 
      containment relationships between Templates.  Therefore, this 
      document prefers the more generic "Data Record" term to the "Flow 
      Record" term. 
      
      
     4. Linkage with the Information Model 

      As in the IPFIX Protocol specification [RFC5101], the new 
      Information Elements specified in section 4.3. below MUST be sent 
      in canonical format in network-byte order (also known as the big-
      endian byte ordering). 
       
       
     4.1. New Abstract Data Types 

      This document specifies three new abstract data types, as 
      described below. 
       
       
     4.1.1. basicList 

      The type "basicList" represents a list of zero or more instances 
      of any single Information Element, primarily used for single-
      valued data types. For example, a list of port numbers, list of 
      interface indexes, list of AS in a BGP AS-PATH, etc. 
       
       
     4.1.2. subTemplateList 

      The type "subTemplateList" represents a list of zero or more 
      instances of a structured data type, where the data type of each 
      list element is the same and corresponds with a single Template 
      Record. For example, a structured data type composed of multiple 
      pairs of ("MPLS label stack entry position", "MPLS label stack 
      value"), a structured data type composed of performance metrics, a 
      structured data type composed of multiple pairs of IP address, 
      etc. 
       
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 12] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

       
     4.1.3. subTemplateMultiList 

      The type "subTemplateMultiList" represents a list of zero or more 
      instances of a structured data type, where the data type of each 
      list element can be different and corresponds with different 
      template definitions. For example, a structured data type composed 
      of multiple access-list entries, where entries can be composed of 
      different criteria types. 
       
       
     4.2. New Data Type Semantic 

      This document specifies a new data type semantic, as described 
      below.  
       
       
     4.2.1. List 

      A list represents an arbitrary-length sequence of structured data 
      elements, either composed of regular Information Elements or 
      composed of data conforming to a Template Record. 
       
       
     4.3. New Information Elements 

      This document specifies three new Information Elements, as 
      described below. 
       
       
     4.3.1. basicList 

      A basicList specifies a generic Information Element with a 
      basicList abstract data type as defined in section 4.1.1. and list 
      semantics as defined in section 4.2.1.  For example, a list of 
      port numbers, list of interface indexes, etc.   
       
      EDITOR'S NOTE: while waiting for IANA to assign this new 
      Information Element identifier, the value XXX is used in all the 
      examples. 
       
       
     4.3.2. subTemplateList 

      A subTemplateList specifies a generic Information Element with a 
      subTemplateList abstract data type as defined in section 4.1.2. 
      and list semantics as defined in section 4.2.1.  
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 13] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

       
      EDITOR'S NOTE: while waiting for IANA to assign this new 
      Information Element identifier, the value YYY is used in all the 
      examples.   
       
       
     4.3.3. subTemplateMultiList 

      A subTemplateMultiList specifies a generic Information Element 
      with a subTemplateMultiList abstract data type as defined in 
      section 4.1.3. and list semantics as defined in section 4.2.1.  
       
      EDITOR'S NOTE: while waiting for IANA to assign this new 
      Information Element identifier, the value ZZZ is used in all the 
      examples. 
       
       
     4.4. Encoding of IPFIX Data Types 

      The following sections define the encoding of the data types 
      defined in section 4.1. above. 
       
      When the encoding of a Structured Data Information Element has a 
      fixed length (because, for example, it contains the same number of 
      fixed-length elements, or if the permutations of elements in the 
      list always produces the same total length), the element length 
      can be encoded in the corresponding Template Record.  However, 
      when representing variable-length data, hierarchical data, and 
      repeated data with variable element counts, we RECOMMEND these are 
      encoded as a Variable-Length Information Element as described in 
      section 7 of [RFC5101], with the length carried in one or three 
      octets before the Structured Data Information Element encoding. 
       
       
     4.4.1. basicList 

      The basicList Information Element defined in section 4.3.1.  
      represents a list of zero or more instances of an Information 
      Element and is encoded as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|          Field ID           |        Element  Length        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      BasicList Content ...                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 14] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                    
                Figure A: basicList Information Element Encoding  
       
       
      Field ID 
       
          The Field ID is the Information Element identifier of the 
          Information Element(s) contained in the list. 
           
      Element Length 
       
          The Element Length indicates the length of each element or 
          contains the value 0xFFFF if the length is encoded as for a 
          variable-length Information Element. 
       
      BasicList Content 
       
          A Collection Process decodes list elements from the BasicList 
          Content until no further data remains.  A field count is not 
          included but can be derived when the Information Element is 
          decoded. 
           
      Note that in the diagram above, the Field ID is shown with the 
      Enterprise bit (most significant bit) set to 0.  If instead the 
      Enterprise bit is set to 1, a four-byte Enterprise Number MUST be 
      encoded immediately after the Element Length as shown below.  See 
      the "Field Specifier Format" section in the IPFIX Protocol 
      [RFC5101] for additional information. 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |1|          Field ID           |          Element Length       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      Enterprise Number                        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                    BasicList Content ...                      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
              Figure B: basicList Encoding with Enterprise Number 
       


      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 15] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      Also note that, if a basicList has zero elements, the encoded data 
      contains the Field ID, the Element Length and the four-byte 
      Enterprise Number (if present); the BasicList Content is empty. 

      The Element Length field is effectively part of a header, so even 
      in the case of a zero-element list with no Enterprise Number, it 
      MUST NOT be omitted. 

      If the basicList is encoded as a Variable-Length Information 
      Element in less than 255 octets, it is encoded with the Length per 
      section 7 of [RFC5101] as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Length (< 255)|         basicList Information Element         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      ... continuing as needed                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
        Figure C: Variable-Length basicList Information Element Encoding 
                             (Length < 255 octets) 
       
       
      If the basicList is encoded as a Variable-Length Information 
      Element in 255 or more octets, it is encoded with the Length per 
      section 7 of [RFC5101] as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |      Length (0 to 65535)      |      ...      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 basicList Information Element                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        Figure D: Variable-Length basicList Information Element Encoding 
                           (Length 0 to 65535 octets) 
         
         
     4.4.2. subTemplateList 

      The subTemplateList Information Element represents a list of zero 
      or more instances of Template data.  Because the Template Record 
      referenced by a subTemplateList Information Element can itself 
      contain other subTemplateList Information Elements, and because 
      these Template Record references are part of the Information 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 16] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      Elements content in the Data Record, it is possible to represent 
      complex hierarchical data structures.  The following diagram shows 
      how a subTemplateList Information Element is encoded within a Data 
      Record: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Template ID           |    SubTemplateList Content    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                       Figure E: subTemplateList Encoding 
       
       
      Template ID 
       
          The Template ID is the ID of the template used to encode and 
          decode the SubTemplateList Content. 
       
      SubTemplateList Content 
       
          The SubTemplateList Content consists of zero or more instances 
          of Data Records corresponding to the Template ID.  A 
          Collecting Process decodes the Data Records until no further 
          data remains.  A record count is not included but can be 
          derived when the subTemplateList is decoded.  Encoding and 
          decoding are performed recursively if the specified Template 
          itself contains Structured Data Information Elements as 
          described here. 
       
      Note that, if a subTemplateList has zero elements, the encoded 
      data contains just the Template ID; the SubTemplateList Content is 
      empty. 
       
      If the subTemplateList is encoded as a Variable-Length Information 
      Element in less than 255 octets, it is encoded with the Length per 
      section 7 of [RFC5101] as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Length (< 255)|     subTemplateList Information Element       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                    ... continuing as needed                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 17] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

                                        
         Figure F: Variable-Length subTemplateList Information Element 
                         Encoding (Length < 255 octets) 
       
       
      If the subTemplateList is encoded as a Variable-Length Information 
      Element in 255 or more octets, it is encoded with the Length per 
      section 7 of [RFC5101] as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |      Length (0 to 65535)      |      ...      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           ...  SubTemplateList continuing as needed           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

         Figure G: Variable-Length subTemplateList Information Element 
                      Encoding (Length 0 to 65535 octets) 
      

     4.4.3. subTemplateMultiList 

      Whereas each top-level element in a subTemplateList Information 
      Element corresponds with a single Template ID and therefore has 
      the same data type, sometimes it is useful for a list to contain 
      elements of more than one data type.  To support this case, each 
      top-level element in a subTemplateMultiList Information Element 
      carries a Template ID and Length.  The following diagram shows how 
      a subTemplateMultiList Information Element is encoded within a 
      Data Record. Note that the subTemplateMultiList encoding is 
      consistent with Set Header specified in [RFC5101].  
       
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Element 1 Template Id   |     Element 1 Length          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     Element 1 Content ...                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Element 2 Template Id   |     Element 2 Length          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     Element 2 content ...                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 18] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      Element N Template Id    |     Element N Length          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     Element N content ...                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                   Figure H: subTemplateMultiList Encoding 
      
      Element Length 
        
          The total length of the Element encoding, including the 2 
          bytes for the Template Id and the 2 bytes for the Element 
          Length field itself. 
          
      Element Template ID 
       
          Unlike the subTemplateList Information Element, each list 
          element contains an Element Length and Element Template ID 
          which specifies the encoding of the following Element Content. 
       
      Element Content 
       
          The Element Content consists of zero or more instances of Data 
          Records corresponding to the Element Template ID.  A 
          Collecting Process decodes the Data Records until no further 
          data remains.  A record count is not included but can be 
          derived when the Element Content is decoded.  Encoding and 
          decoding are performed recursively if the specified Template 
          itself contains Structured Data Information Elements as 
          described here. 
       
       
      In the exceptional case of zero instances in the 
      subTemplateMultiList, no data is encoded and the Length is set to 
      zero. 
       
      If the subTemplateMultiList is encoded as a Variable-Length 
      Information Element in less than 255 octets, it is encoded with 
      the Length per section 7 of [RFC5101] as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Length (< 255)|   subTemplateMultiList Information Element    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      ... continuing as needed                 | 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 19] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
      Figure I: Variable-Length subTemplateMultiList Information Element 
                        Encoding (Length < 255 octets) 
       
       
      If the subTemplateMultiList is encoded as a Variable-Length 
      Information Element in 255 or more octets, it is encoded with the 
      Length per section 7 of [RFC5101] as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |      Length (0 to 65535)      |       IE      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      ... continuing as needed                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

           Figure J: Variable-Length subTemplateMultiList Information 
                  Element Encoding (Length 0 to 65535 octets) 
       
       
     5. Structured Data Format 

       
     5.1. Length Encoding Considerations 

      The new Structured Data Information Elements represent a list that 
      potentially carries complex hierarchical and repeated data.  In 
      the normal case where the number and length of elements can vary 
      from record to record, these Information Elements are encoded as 
      variable-length Information Elements as described in section 7 of 
      [RFC5101]. 
       
      Because of the complex and repeated nature of the data, it is 
      potentially difficult for the Exporting Process to efficiently 
      know in advance the exact encoding size; as a result, data may be 
      recursively encoded starting at a fixed offset, with the final 
      length only known and filled in afterwards. 
       
      Therefore, the three-byte length encoding is RECOMMENDED for 
      variable-length information elements in all Template Records 
      containing a Structured Data Information Element, even if the 
      encoded length can be less than 255 bytes, because the starting 
      offset of the data is known in advance. 
       

      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 20] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      An Exporting Process MUST take care when encoding such data to not 
      exceed the maximum allowed length of an IPFIX Message, 65535 
      bytes, respecting the IPFIX specifications [RFC5101] that imposes: 
      "The IPFIX Message Header 16-bit Length field limits the length of 
      an IPFIX Message to 65535 octets, including the header".  
       
     5.2. Recursive Structured Data 

      It is possible to define recursive relationships between IPFIX 
      structured data instances, for example when representing a tree 
      structure.  The simplest case of this might be a basicList where 
      each element is itself a basicList, or a subTemplateList where one 
      of the fields of the referenced template is itself a 
      subTemplateList referencing the same Template.  When encoding 
      recursively-defined structured data, each leaf element of the 
      encoded structure MUST be terminated with a zero-length element.  
      This implies that variable-length encoding as described in section 
      7 of [RFC5101] MUST be used when such a recursive relationship 
      exists. Also, the Exporting Process MUST take care that, when 
      encoding recursively-defined structured data, to not exceed the 
      maximum allowed length of an IPFIX Message (as noted in Length 
      Encoding Considerations). 
       
     5.3. Structured Data Information Elements Applicability in Options 
        Template Sets 

      All the examples in this document use the Structured Data 
      Information Elements, abstract data types, and data type semantic 
      in Template Sets.  However, they could also be used in Options 
      Template Sets. 
       
      Regarding the scope in the Options Template Record, the IPFIX 
      specification [RFC5101] mentions that "The IPFIX protocol doesn't 
      prevent the use of any Information Elements for scope".  
      Therefore, a Structured Data Information Element could be used as 
      scope in an Options Template Set.   
       
      Consider a mediation function that aggregate Data Records from 
      multiple different Observation Points:  
       
         Router 1, (interface 1, 2, 3)  
         Router 2, (line card A)  
         Router 3, (line card B, C)  
         Router 4, (line card D, interface 4)  
       
      The mediation function wishes to express this as a single 
      Observation Point, in order to encode the PSAMP Selection Sequence 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 21] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      Report Interpretation.  Recall from [RFC5476] that the PSAMP 
      Selection Sequence Report Interpretation consists of the following 
      fields:  
       
         Scope:     selectionSequenceId  
         Non-Scope: one Information Element mapping the Observation  
                    Point  
                    selectorId (one or more)  
       
      Without structured data, there is clearly no way to express the 
      complex mediation device observation point as "one Information 
      Element mapping the Observation Point".  However, the desired 
      result may be easily achieved using the structured data types.  
       
       
     5.4. Usage Guidelines for Equivalent Data Representations 

      Because basicList, subTemplateList, and subTemplateMultiList are 
      all lists, in several cases there is more than one way to 
      represent what is effectively the same data structure.  However, 
      in some cases, one approach has an advantage over the other e.g. 
      more compact, uses fewer resources, etc., and is therefore 
      preferred over an alternate representation. 

      A subTemplateList can represent the same simple list of single-
      value Information Elements as a basicList, if the Template 
      referenced by the subTemplateList contains only one single-valued 
      Information Element.  Although the encoding is more compact than a 
      basicList by two bytes, using a subTemplateList in this case 
      requires a new Template per list element.  The basicList requires 
      no additional Template and is therefore RECOMMENDED in this case.  

      As the {Length, Template ID, Content} tuple effectively forms a 
      subTemplateList, so the subTemplateMultiList can be viewed as a 
      list of subTemplateLists.  So, although a subTemplateMultiList can 
      represent the content of a subTemplateList, the 
      subTemplateMultiList carries two additional bytes (Total Length).  
      It is also potentially useful to a Collecting Process to know in 
      advance that a subTemplateList directly indicates that list 
      element types are consistent.  The subTemplateList Information 
      Element is therefore RECOMMENDED in this case. 
       
      Similarly, although a basicList of single-element subTemplateList 
      Information Elements can represent the same mixed-type content as 
      a subTemplateMultiList, a basicList instance carries four 
      additional bytes (Element Length and Field ID), so the 

      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 22] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      subTemplateMultiList is more compact and is therefore RECOMMENDED 
      in this case. 

      Note that the referenced Information Element(s) in the Structured 
      Data Information Elements can be taken from the IPFIX information 
      model [RFC5102], the PSAMP information model [RFC5477], or any of 
      the Information Elements defined in the IANA IPFIX registry. 
       
       
     5.5. Padding 

      The Exporting Process MAY insert some padding octets in structured 
      data field values in a Data Record by including the 
      'paddingOctets' Information Element as described in [RFC5101] 
      section 3.3.1, "Set Format".  The paddingOctets Information 
      Element can be included in a Template Record referenced by 
      Structured Data Information Element for this purpose. 
                            
       
     6. Template Management  

      This section introduces some more specific Template Management and 
      Template Withdrawal Message-related specifications compared to the 
      IPFIX protocol specification [RFC5101]. 
       
      First of all, the Template ID uniqueness is unchanged compared to 
      [RFC5101]; the uniqueness is local to the Transport Session and 
      Observation Domain that generated the Template ID.  In other 
      words, the Set ID used to export the Template Record does not 
      influence the Template ID uniqueness. 
      
      While [RFC5101] mentions that: "If an Information Element is 
      required more than once in a Template, the different occurrences 
      of this Information Element SHOULD follow the logical order of 
      their treatments by the Metering Process.", this rule MAY not be 
      followed for the Structured Data Information Elements.   
      
      As specified in [RFC5101], Templates that are not used anymore 
      SHOULD be deleted.  Before reusing a Template ID, the Template 
      MUST be deleted.  In order to delete an allocated Template, the 
      Template is withdrawn through the use of a Template Withdrawal 
      Message.  
       
      Multiple Template IDs MAY be withdrawn with a single Template 
      Withdrawal Message, in that case, padding MAY be used. 
      
      
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 23] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

     7. The Collecting Process's Side  

      This section introduces some more specific specifications to the 
      Collection Process compared to section 9 in the IPFIX Protocol 
      [RFC5101].   
      
      As described in [RFC5101], a Collecting Process MUST note the 
      Information Element identifier of any Information Element that it 
      does not understand and MAY discard that Information Element from 
      the Flow Record.  Therefore a Collection Process that does not 
      support the extension specified in this document can ignore the 
      Structured Data Information Elements in a Data Record, or it can 
      ignore Data Records containing these new Structured Data 
      Information Elements while continuing to process other Data 
      Records. 
      
      
     8. Structured Data Encoding Examples 

      The following examples are created solely for the purpose of 
      illustrating how the extensions proposed in this document are 
      encoded. 

     8.1. Encoding BasicList 

      Consider encoding a multicast flow containing the following data: 

      -------------------------------------------------------- 
       Source IP   | Destination IP  |  Outgoing Interfaces 
      -------------------------------------------------------- 
       192.0.2.201   233.252.0.1        1, 4, 8 
      -------------------------------------------------------- 
       

      Template Record for the multicast Flows, with the Template ID 258: 

       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 20 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 258       |       Field Count = 3         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   sourceIPv4Address = 8     |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| DestinationIPv4Address = 12 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 24] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      |0|       basicList = XXX       |     Field Length = 0xFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                         
                 Figure K: Encoding basicList, Template Record 
       

      The list of outgoing interfaces is represented as a basicList, the 
      Length of the list is chosen to be encoded in three bytes even 
      though it may be less than 255 octets. 

      The Data Set is represented as follows: 

       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 258         |          Length  = 31         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               sourceIPv4Address = 192.0.2.201                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |             DestinationIPv4Address = 233.252.0.1              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |        List Length = 16       |egressInterface| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  ... = 14     |egressInterf. Field Length = 4 |egressInterface| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... value 1: octets 2-4 of = 1                |egressInterface|  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... value 2: octets 2-4 of = 4                |egressInterface| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... value 2: octets 2-4 of = 8                |                 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                   Figure L: Encoding basicList, Data Record 
                                         
     8.2. Encoding subTemplateList 

      As explained in section 3.2. , multiple pairs of 
      (observationTimeMicroseconds, digestHashValue) must be collected 
      from two different Observation Points to compute passively the 
      one-way delay across the network.  This data can be exported with 
      an optimized Flow Record that consists of the following 
      attributes:  
       
          5 tuple 
                    observationTimeMicroseconds 1, digestHashValue 1 
                    observationTimeMicroseconds 2, digestHashValue 2 
                    observationTimeMicroseconds 3, digestHashValue 3 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 25] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

                    ...  , ... 
      

      A subTemplateList is best suited for exporting the list of   
      (observationTimeMicroseconds, digestHashValue).  For illustration 
      purposes, the number of elements in the list is 5, in practice, it 
      could be more. 
      
      ------------------------------------------------------------------ 
      srcIP     | dstIP      | src   | dst  |proto| one-way delay 
                |            | Port  | Port |     |   metrics 
      ------------------------------------------------------------------ 
      192.0.2.1  192.0.2.105   1025     80     6    Time1, 0x0x91230613   
                                                    Time2, 0x0x91230650   
                                                    Time3, 0x0x91230725   
                                                    Time4, 0x0x91230844   
                                                    Time5, 0x0x91230978 
      ------------------------------------------------------------------ 
      
      The following Template is defined for exporting the one-way delay 
      metrics: 
      
      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |        Set ID = 2             |      Length = 16 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 258       |       Field Count = 2         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| observationTimeMicroSec=324 |       Field Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   digestHashValue = 326     |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
         Figure M: Encoding subTemplateList, Template for One-Way Delay 
                                    Metrics 
      
       
      The Template Record for the Optimized Flow Record is as follows: 
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 32 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 259       |       Field Count = 6         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   sourceIPv4Address = 8     |       Field Length = 4        | 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 26] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationIPv4Address = 12 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|  sourceTransportPort = 7    |       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationTransportPort= 11|       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| protocolIdentifier = 4      |       Field Length = 1        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|  subTemplateList = YYY      |     Field Length = 0xFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
              Figure N: Encoding subTemplateList, Template Record 
                                         
     The list of (observationTimeMicroseconds, digestHashValue) is 
     exported as a subTemplateList. The Length of the subTemplatelist is 
     chosen to be encoded in three bytes even though it may be less than 
     255 octets. 
         
        The Data Record is represented as follows: 
         
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 259          |      Length =  82 octets      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                sourceIPv4Address = 192.0.2.1                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              destinationIPV4Address = 192.0.2.105             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | sourceTransportPort = 1025    | destinationTransportPort = 80 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Protocol = 6  |      255      | one-way metrics list len = 62 |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Template ID=258           |   octets 1-2 of TimeValue1    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 ... octets 3-6 of TimeValue1                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... octets 7-8 of TimeValue1  |      digestHashValue 1 =      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    ... 0x0x91230613           |   octets 1-2 of TimeValue2    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                  ... octets 3-6 of TimeValue2                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... octets 7-8 of TimeValue2  |      digestHashValue 2 =      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    ... 0x0x91230650           |   octets 1-2 of TimeValue3    |  
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 27] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 ... octets 3-6 of TimeValue3                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... octets 7-8 of TimeValue3  |      digestHashValue 3 =      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |   ... 0x0x91230725            |   octets 1-2 of TimeValue4    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 ... octets 3-6 of TimeValue4                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... octets 7-8 of TimeValue4  |      digestHashValue 4 =      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |   ... 0x0x91230844            |   octets 1-2 of TimeValue5    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 ... octets 3-6 of TimeValue5                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... octets 7-8 of TimeValue5  |      digestHashValue 5 =      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |   ... 0x0x91230978            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                          
      
                   Figure O: Encoding subTemplateList, Data Set 
                                           
         
     8.3. Encoding subTemplateMultiList  

      An IPS alert consists of the following mandatory attributes:  
      signatureId, protocolIdentifier and riskRating.  It can also 
      contain zero or more participants, each participant can contain 
      zero or more attackers and zero or more targets.  An attacker 
      contains the attributes sourceIPv4Address and applicationId and 
      a target contains the attribute destinationIPv4Address and zero or 
      more occurrences of the attribute applicationId. 
       
      Note that the signatureId and riskRating Information Element 
      fields are created for these examples only; the Field IDs are 
      shown as N/A.  The signatureId helps to uniquely identify the IPS 
      signature that triggered the alert.  The riskRating identifies the 
      potential risk, on a scale of 0-100 (100 being most serious), of 
      the traffic that triggered the alert. 
       
      Consider the following contrived example of an IPS alert to 
      illustrate the encoding of a subTemplateMultiList.  The 
      participant can contain attackers and targets in any order and the 
      sequence conveys some information to the Collector and needs to be 
      preserved.  In the example below, we have attacker1 A1, target T1 
      and attacker A2 and this is encoded as a subTemplateMultiList.   
       
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 28] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      ------------------------------------------------------------------ 
            |        |        |             participant  
      sigId |protocol| risk   |      attacker   |      target            
            |   Id   | Rating |    IP   | appId |    IP      | appId(s) 
      ------------------------------------------------------------------ 
      1003     17      10      192.0.2.3  103    192.0.2.103  3001, 3002  
                               192.0.2.4  104    
      ------------------------------------------------------------------ 
       
      Where attacker A1 is: (IP, appID)=(192.0.2.3, 103) 
      Where attacker A2 is: (IP, appID)=(192.0.2.4, 104) 
      Where target T1 is: (IP, appID)= (192.0.2.103, (3001, 3002)) 
       
      To represent an alert, the following Templates are defined: 
      Template for target (258) 
      Template for attacker (259) 
      Template for participant (260) 
      Template for alert (261) 
       
           alert (261) 
           |  (signatureId) 
           |  (protocolIdentifier) 
           |  (riskRating) 
           | 
           +------- participant (260) 
                    | 
                    +------- attacker (259) 
                    |           (sourceIPv4Address) 
                    |           (applicationId) 
                    | 
                    +------- target (258) 
                             |  (destinationIPv4Address) 
                             |  (list of applicationId) 
                              
      Note that the attackers are always composed of a single 
      applicationId, while the targets typically have multiple 
      applicationId. 
       
      Template Record for target, with the Template ID 258: 
       
       
      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |        Set ID = 2             |      Length = 16 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 258       |       Field Count = 2         | 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 29] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationIPv4Address = 12 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|       basicList = XXX       |     Field Length = 0xFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
          Figure P: Encoding subTemplateMultiList, Template for Target 
      
       
      The list of applicationId in the target Template Record is 
      represented as a basicList. 
       
      Template Record for attacker, with the Template ID 259: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 16 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 259       |       Field Count = 2         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|    sourceIPv4Address = 8    |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|     applicationId = 95      |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
         Figure Q: Encoding subTemplateMultiList, Template for Attacker 
       
       
      Template Record for participant, with the Template ID 260: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 12 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 260       |       Field Count = 1         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| subTemplateMultiList = ZZZ  |     Field Length = 0xFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                        
             Figure R: Encoding subTemplateMultiList, Template for 
                                  Participant 
       
       


      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 30] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      The Template Record for the participant has one 
      subTemplateMultiList Information Element, which is a list that can 
      include attackers and targets repeated in any order. 
          
      Template Record for IPS alert, with the Template ID 261: 
       
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 24 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 261       |       Field Count = 4         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|    signatureId = N/A        |       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   protocolIdentifier = 4    |       Field Length = 1        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|     riskRating = N/A        |       Field Length = 1        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|     subTemplateList = YYY   |     Field Length = 0xFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
        Figure S: Encoding subTemplateMultiList, Template for IPS Alert 
       
      The subTemplateList in the alert Template Record contains a list 
      of participants.   
       
      The Length of basicList, subTemplateList and subTemplateMultiList 
      are encoded in three bytes even though it may be less than 255 
      octets. 
       
       
      The Data Set is represented as follows: 
        
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 261         |         Length = 63           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      signatureId = 1003       | protocolId=17 | riskRating=10 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |  participant Length  = 52     |participant ...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |Template ID=260|      255      |subTemplateMultiList Length=47 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  attacker1 Template ID = 259  |   attacker1 Length = 12       | 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 31] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |        attacker1 sourceIPv4Address = 192.0.2.3                | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               attacker1 applicationId = 103                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |   target1 Template ID = 258   |      Target1 Length = 23      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |        target1 destinationIPv4Address = 192.0.2.103           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     255       | target1 appId List Length=12  |target1 appId..| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Field ID = 95 | target1 appId Field ID Len = 4|target1 appId =| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...                    3001                   |target1 appId =| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...                    3002                   | attacker2  ...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |Template ID=259|     attacker2 Length = 12     | attacker2  ...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...   sourceIPv4Address = 192.0.2.4           | attacker2  ...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...      applicationId = 104                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
               Figure T: Encoding subTemplateMultiList, Data Set 
         
                                          
     8.4. Encoding As Scope  

      As described in section 5.3. , consider a mediation function that 
      aggregate Data Records from multiple different Observation Points:  
       
         Router 1, (interface 1, 2, 3)  
         Router 2, (line card A)  
         Router 3, (line card B, C)  
         Router 4, (line card D, interface 4)  
       
      The mediation function wishes to express this as a single 
      Observation Point, in order to encode the PSAMP Selection Sequence 
      Report Interpretation (SSRI).  Recall from [RFC5476] that the 
      PSAMP Selection Sequence Report Interpretation consists of the 
      following fields:  
       
         Scope:     selectionSequenceId  
         Non-Scope: one Information Element mapping the Observation  
                    Point  
                    selectorId (one or more)  
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 32] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

       
      For example, the Observation Point detailed above may be encoded 
      in a PSAMP Selection Sequence Report Interpretation as shown 
      below:  
       
       Selection Sequence 7 (Filter->Sampling):  
         observation point: subTemplateMultiList.  
                              Router 1, (interface 1, 2, 3)  
                              Router 2, (line card A)  
                              Router 3, (line card B, C)  
                              Router 4, (line card D, interface 4)  
         selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1)  
         selectorId: 10 (Sampler, Random 1 out-of ten) 
                                        
                      Figure U: PSAMP SSRI to be encoded 
       
        0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 3           |          Length = 26          |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Template ID = 270      |         Field Count = 4       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |     Scope Field Count =  1    |0|  selectionSequenceId = 301  |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |       Scope 1 Length = 4      |0| subTemplateMultiList =  ZZZ |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |     Field Length = 0xFFFF     |0|      selectorId = 302       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Field Length = 4       |0|      selectorId = 302       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Field Length = 4       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
               Figure V: Options Template record for PSAMP SSRI  
                                        
                                        
         0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 2           |          Length = 12          |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Template ID = 271      |         Field Count = 1       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |      Field 1 Length = 4       |0|    ingressInterface = 10    |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 33] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

           Figure W: PSAMP SSRI, Template record for interface list  
                                        
                                        
         0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 2           |          Length = 12          |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Template ID = 272      |         Field Count = 1       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |      Field 1 Length = 4       |0|      lineCardId = 141       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
           Figure X: PSAMP SSRI, Template record for linecard list  
                                        
                                        
         0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 3           |          Length = 16          |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Template ID = 273      |         Field Count = 2       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |      Field 1 Length = 4       |0|    ingressInterface = 10    |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |      Field 2 Length = 4       |0|      lineCardId = 141       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
      Figure Y: PSAMP SSRI, Template record for interface and linecard 
      list 
       
       
        0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 270         |           Length =   51       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |                    selectionSequenceId = 7                    |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |      255      | Observation Point List Len=43 | el1_length ...|  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |... el1_length |       Template ID = 271       | ingress...    |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |...Interface=1 |     ingressInterface = 2      | ingress...    |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |...Interface=3 |          el2_length           | Template ID = |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 34] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

       |    ... 272    |        lineCardId = A         | el3_length ...|  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |... el3_length |       Template ID = 272       |lineCardId=B...|  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |      ...      |        lineCardId = C         | el4_length ...|  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |... el4_length |       Template ID = 273       |lineCardId=D...|  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |      ...      |     ingressInterface = 5      |      ...      |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |                selectorId = 5                 |      ...      |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |                selectorId = 10                |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
       Figure Z: Example of a Selection Sequence Report Interpretation 
              Data Record, Encoded using a subTemplateMultiList 
    
      
     9. Relationship with the Other IFPIX Documents 

     9.1. Relationship with Reducing Redundancy  

        [RFC5473] describes a bandwidth saving method for exporting Flow 
        or packet information using the IP Flow Information eXport 
        (IPFIX) protocol. 

        It defines the commonPropertiesID Information Element for 
        exporting Common Properties. 

         

     9.1.1. Encoding Common Properties elements With Structured Data 
        Element. 

        The new structured data types listed in section 4.1. may be used 
        to define a list of commonPropertiesID. 

        EDITOR'S NOTE: to be completed 

         

     9.1.2. Encoding Structured Data Element using Common Properties. 

        When structured data elements contain repeated elements, these 
        elements may be replaced with a commonPropertiesID Information 
        Element as described in [RFC5473].  The replaced elements may 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 35] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

        include the basicList, subTemplateList and subTemplateMultiList 
        Information Elements. 

         

     9.2. Relationship with Guidelines for IPFIX Testing 

        [RFC5471] presents a list of tests for implementers of IP Flow 
        Information eXport (IPFIX) compliant Exporting Processes and 
        Collecting Processes.  

        Although [RFC5471] doesn't define any structured data element 
        specific tests, the Structured Data Information Elements can be 
        used in many of the [RFC5471] tests. 

        The [RFC5471] series of test could be useful because the 
        document specifies that every Information Element type should be 
        tested.  However, not all cases from this document are tested in 
        [RFC5471]. 

        The following sections are especially noteworthy: 

          . 3.2.1.  Transmission of Template with fixed size 
             Information Elements 

               - each data type should be used in at least one test. The 
                  new data types specified in section 4.1. should be 
                  included in this test. 

          .  3.2.2. Transmission of Template with variable length 
             Information Elements 

               - this test should be expanded to include Data Records 
                  containing variable length basicList, subTemplateList, 
                  and subTemplateMultiList Information Elements. 

          . 3.3.1. Enterprise-specific Information Elements 

               - this test should include the export of basicList, 
                  subTemplateList, and subTemplateMultiList Information 
                  Elements containing Enterprise-specific Information 
                  Elements. e.g., see the example in figure B. 

          . 3.3.3. Multiple instances of the same Information Element 
             in one Template 


      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 36] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

               - this test should verify that multiple instances of the 
                  basicList, subTemplateList and subTemplateMultiList 
                  Information Elements are accepted. 

          . 3.5 Stress/Load tests 

               - since the structured data types defined here allow 
                  modeling of complex data structures, they may be 
                  useful for stress testing both Exporting Processes and 
                  Collecting Processes. 

     9.3. Relationship with Bidirectional Flow Export  

        [RFC5103] describes a method for exporting bidirectional flow 
        information, and defines the biflowDirection Information Element 
        for this purpose. 
         
        [RFC5103] biflows may be encoded in a basicList, subTemplateList 
        or subTemplateMultiList. 
         
        EDITOR'S NOTE: to be completed. See if there is a more 
        efficient/cleaner way to encode the bidirectional Flows with the 
        Structured Data Information Element(s). 
         
     9.4. Relationship with IPFIX Mediation Function 

     The Structured Data Information Elements would be beneficial for 
     the export of aggregated Data Records in mediation function, as it 
     was demonstrated with the example of the aggregated Observation 
     Point in section 5.3.  
         

     10. IANA Considerations 

      This document specifies several new IPFIX abstract data types, a 
      new IPFIX Data Type Semantic, and several new Information 
      Elements. 
       
      These require the creation of two new IPFIX registries and 
      updating the existing IPFIX Information Element registry as 
      detailed below. 
       
       
     10.1. New Abstract Data Types 

      Section 4.1. of this document specifies several new IPFIX abstract 
      data types. Per section 6 of the IPFIX information model 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 37] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      [RFC5102], new abstract data types can be added to the IPFIX 
      information model.  This requires creation of a new IPFIX 
      "abstract data types" registry at 
      http://www.iana.org/assignments/ipfix. This registry should 
      include all the abstract data types from section 3.1 of [RFC5102].  
       
      Abstract data types to be added to the IPFIX "abstract data types" 
      registry are listed below.  
       
       
     10.1.1. basicList 

      The type "basicList" represents a list of any Information Element 
      used for single-valued data types.  
       
     10.1.2. subTemplateList 

      The type "subTemplateList" represents a list of a structured data 
      type, where the data type of each list element is the same and 
      corresponds with a single Template Record.  
       
     10.1.3. subTemplateMultiList 

      The type "subTemplateMultiList" represents a list of structured 
      data types, where the data types of the list elements can be 
      different and correspond with different template definitions. 
      
     10.2. New Data Type Semantics 

      Section 4.2. of this document specifies a new IPFIX Data Type 
      Semantic. Per section 3.2 of the IPFIX information model 
      [RFC5102], new data type semantics can be added to the IPFIX 
      information model. This requires creation of a new IPFIX "data 
      types semantics" registry at 
      http://www.iana.org/assignments/ipfix. This registry should 
      include all the data type semantics from section 3.2 of [RFC5102]. 
       
      Data type semantics to be added to the IPFIX "data types 
      semantics" registry are listed below. 
          
     10.2.1. list 

      A list is a structured data type, being composed of a sequence of 
      elements e.g. Information Element, Template Record, etc.  
       
       

      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 38] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

     10.3. New Information Elements 

      Section 4.3. of this document specifies several new Information 
      Elements which are to be created in the IPFIX Information Element 
      registry located at http://www.iana.org/assignments/ipfix.  
       
      New Information Elements to be added to the IPFIX Information 
      Element registry are listed below. 
      
     10.3.1. basicList  

      Name: basicList  
      Description:  
      Specifies a generic Information Element with a basicList abstract 
      data type.  For example, list of port numbers, list of interface 
      indexes, etc.  
      Abstract Data Type: basicList  
      Data Type Semantics: list  
      ElementId: XXX (to be specified)  
      Status: current  
      
     10.3.2. subTemplateList 

      Name: subTemplateList  
      Description:  
      Specifies a generic Information Element with a subTemplateList 
      abstract data type.  
      Abstract Data Type: subTemplateList  
      Data Type Semantics: list  
      ElementId: YYY (to be specified)  
      Status: current 
      
     10.3.3. subTemplateMultiList 

      Name: subTemplateMultiList  
      Description:  
      Specifies a generic Information Element with a 
      subTemplateMultiList abstract data type.  
      Abstract Data Type: subTemplateMultiList  
      Data Type Semantics: list  
      ElementId: ZZZ (to be specified)  
      Status: current 

      



      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 39] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

     11. Security Considerations 

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

     12.1. Normative References 

        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 
                Requirement Levels, BCP 14, RFC 2119, March 1997. 
      
        [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. 
      
         
     12.2. Informative References 

         
        [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 
                Requirements for IP Flow Information Export, RFC 3917, 
                October 2004. 
         
        [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 
                Export Using IP Flow Information Export (IPFIX)", RFC 
                5103, January 2008. 
      
        [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 
                Quittek, "Architecture for IP Flow Information Export", 
                RFC 5470, March 2009. 
         
        [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 
                for IP Flow Information Export (IPFIX) Testing", RFC 
                5471, March 2009. 
         
        [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 
                "IP Flow Information Export (IPFIX) Applicability", RFC 
                5472, March 2009. 
         


      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 40] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

        [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 
                Redundancy in IP Flow Information Export (IPFIX) and 
                Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. 
      
        [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., 
                and F. Raspall, "Sampling and Filtering Techniques for 
                IP Packet Selection", RFC 5475, March 2009. 
      
        [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol 
                Specifications", RFC 5476, March 2009. 
         
        [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and 
                G. Carle, "Information Model for Packet Sampling 
                Exports", RFC 5477, March 2009. 
         

     13. Acknowledgement 

      The authors would like to thank Zhipu Jin, Nagaraj Varadharajan, 
      Brian Trammel, and Atsushi Kobayashi for their feedback. 
       
       
     14. Authors' Addresses 

       
      Benoit Claise 
      Cisco Systems Inc. 
      De Kleetlaan 6a b1 
      Diegem 1813 
      Belgium 
          
      Phone: +32 2 704 5622 
      EMail: bclaise@cisco.com 
       
       
      Gowri Dhandapani 
      Cisco Systems Inc. 
      13615 Dulles Technology Drive 
      Herndon, Virigina 20171 
      United States 
          
      Phone: +1 408 853 0480 
      EMail: gowri@cisco.com 
       
       
      Stan Yates 
      Cisco Systems Inc. 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 41] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

      7100-8 Kit Creek Road 
      PO Box 14987 
      Research Triangle Park 
      North Carolina, 27709-4987 
      United States 
          
      Phone: +1 919 392 8044 
      EMail: syates@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 
            

      Appendix A.  XML Specification of IPFIX Information Elements and 
      Abstract Data Types 

      <fieldDefinitions xmlns="urn:ietf:params:xml:ns:ipfix-info" 
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                   xsi:schemaLocation="urn:ietf:params:xml:ns:ipfix-info 
                   ipfix-info.xsd"> 
       
       <field name="basicList"  
               dataType="basicList" 
               group="structured-data" 
               dataTypeSemantics="List" 
               elementId="XXX" applicability="all" status="current"> 
          <description> 
            <paragraph> 
               Represents a list of zero or more instances of 
               any single Information Element, primarily used for 
               single-valued data types. For example, a list of port  
               numbers, list of interface indexes, list of AS in a BGP  
               AS-PATH, etc. 
            </paragraph> 
          </description> 
        </field>  
           
        <field name="subTemplateList"  
               dataType="subTemplateList" 
               group="structured-data" 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 42] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

               dataTypeSemantics="List" 
               elementId="XXX" applicability="all" status="current"> 
          <description> 
            <paragraph> 
               Represents a list of zero or more instances of a 
               structured data type, where the data type of each list 
               element is the same and corresponds with a single  
               Template Record. For example, a structured data type  
               composed of multiple pairs of ("MPLS label stack entry  
               position", "MPLS label stack value"), a structured data  
               type composed of performance metrics, a structured data  
               type composed of multiple pairs of IP address, etc. 
            </paragraph> 
          </description> 
        </field> 
       
        <field name="subTemplateMultiList"                
               dataType="subTemplateMultiList" 
               group="structured-data" 
               dataTypeSemantics="List" 
               elementId="XXX" applicability="all" status="current"> 
          <description> 
            <paragraph> 
              Represents a list of zero or more instances of 
              structured data types, where the data type of each list  
              element can be different and corresponds with 
              different template definitions. For example, a structured  
              data type composed of multiple access-list entries, where  
              entries can be composed of different criteria types. 
            </paragraph> 
          </description> 
        </field> 
       
      </fieldDefinitions> 
        <schema targetNamespace="urn:ietf:params:xml:ns:ipfix-info" 
              xmlns:ipfix="urn:ietf:params:xml:ns:ipfix-info" 
              xmlns="http://www.w3.org/2001/XMLSchema" 
              elementFormDefault="qualified"> 
       
        <simpleType name="dataType"> 
          <restriction base="string"> 
            <enumeration value="basicList"> 
              <annotation> 
                <documentation> 
                  Represents a list of zero or more instances of 
                  any single Information Element, primarily used for 
                  single-valued data types. For example, a list of port  
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 43] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

                  numbers, list of interface indexes, list of AS in a  
                  BGP AS-PATH, etc. 
                </documentation> 
              </annotation> 
            </enumeration> 
            <enumeration value="subTemplateList"> 
              <annotation> 
                <documentation> 
                  Represents a list of zero or more instances of a 
                  structured data type, where the data type of each list 
                  element is the same and corresponds with a single  
                  Template Record. For example, a structured data type  
                  composed of multiple pairs of ("MPLS label stack entry  
                  position", "MPLS label stack value"), a structured  
                  data type composed of performance metrics, a  
                  structured data type composed of multiple pairs of IP  
                  address, etc. 
                </documentation> 
              </annotation> 
            </enumeration> 
            <enumeration value="subTemplateMultiList"> 
              <annotation> 
                <documentation> 
                  Represents a list of zero or more instances of 
                  structured data types, where the data type of each  
                  list element can be different and corresponds with 
                  different template definitions. For example, a  
                  structured data type composed of multiple access-list  
                  entries, where entries 
                  can be composed of different criteria types. 
                </documentation> 
              </annotation> 
            </enumeration> 
          </restriction> 
        </simpleType> 
          
        <simpleType name="dataTypeSemantics"> 
          <restriction base="string"> 
            <enumeration value="List"> 
              <annotation> 
                <documentation> 
                  Represents an arbitrary-length sequence of structured  
                  data elements, either composed of regular Information  
                  Elements or composed of data conforming to a Template  
                  Record.                
                </documentation> 
              </annotation> 
      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 44] 
         
     Internet-Draft  <Export of Structured Data in IPFIX>  July 2009 
         

            </enumeration> 
          </restriction> 
        </simpleType> 
          
      </schema> 










































      
      
     <Claise, et. Al>      Expires December 30, 2009         [Page 45]