[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 6313

     IPFIX Working Group                                    B. Claise
     Internet-Draft                                     G. Dhandapani
     Intended Status: Standards Track                        S. Yates
     Expires: April 15, 2010                                P. Aitken
                                                  Cisco Systems, Inc.
                                                     October 15, 2009
 
                       Export of Structured Data in IPFIX
                     draft-ietf-ipfix-structured-data-00.txt
 
 
     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 April, 2010.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     <Claise, et. Al>        Expires April 10 2010            [Page 1]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 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 April 15, 2010            [Page 2]
 

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

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
           9.2. Relationship with Guidelines for IPFIX Testing .....41
           9.3. Relationship with Bidirectional Flow Export.........42
           9.4. Relationship with IPFIX Mediation Function..........43
        10. IANA Considerations.....................................43
           10.1. New Abstract Data Types............................43
              10.1.1. basicList.....................................43
              10.1.2. subTemplateList...............................44
              10.1.3. subTemplateMultiList..........................44
           10.2. New Data Type Semantics............................44
              10.2.1. list..........................................44
           10.3. New Information Elements ..........................44
              10.3.1. basicList.....................................44
              10.3.2. subTemplateList...............................45
              10.3.3. subTemplateMultiList..........................45
        11. Security Considerations.................................45
        12. References..............................................45
           12.1. Normative References...............................45
           12.2. Informative References.............................46
        13. Acknowledgement ........................................47
        14. Authors' Addresses......................................47
        Appendix A.  XML Specification of IPFIX Information Elements
        and Abstract Data Types.....................................48
        Appendix B.  Example of Biflow Encoding using Structured
        Data Information Elements...................................50
        Appendix C.  Encoding IPS Alert using Structured Data
        Information Elements........................................53
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010            [Page 4]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
     Table of Figures
 
     Figure A: basicList Information Element Encoding...............16
     Figure B: basicList Encoding with Enterprise Number............17
     Figure C: Variable-Length basicList Information Element Encoding
        (Length < 255 octets) ......................................17
     Figure D: Variable-Length basicList Information Element Encoding
        (Length 0 to 65535 octets)..................................18
     Figure E: subTemplateList Encoding.............................18
     Figure F: Variable-Length subTemplateList Information Element
        Encoding (Length < 255 octets)..............................19
     Figure G: Variable-Length subTemplateList Information Element
        Encoding (Length 0 to 65535 octets) ........................19
     Figure H: subTemplateMultiList Encoding........................20
     Figure I: Variable-Length subTemplateMultiList Information Element
        Encoding (Length < 255 octets)..............................21
     Figure J: Variable-Length subTemplateMultiList Information Element
        Encoding (Length 0 to 65535 octets) ........................21
     Figure K: Encoding basicList, Template Record..................26
     Figure L: Encoding basicList, Data Record......................27
     Figure M: Encoding subTemplateList, Template for One-Way Delay
        Metrics ....................................................28
     Figure N: Encoding subTemplateList, Template Record............28
     Figure O: Encoding subTemplateList, Data Set...................30
     Figure P: Encoding subTemplateMultiList, Template for
        Classification Attributes...................................32
     Figure Q: Encoding subTemplateMultiList, Template for Sampling
        Attributes..................................................33
     Figure R: Encoding subTemplateMultiList, Template for Flow Record34
     Figure S: Encoding subTemplateMultiList, Data Set..............34
     Figure T: PSAMP SSRI to be encoded.............................36
     Figure U: Options Template Record for PSAMP SSRI using
        subTemplateMultiList........................................37
     Figure V: PSAMP SSRI, Template Record for interface............37
     Figure W: PSAMP SSRI, Template Record for linecard ............37
     Figure X: PSAMP SSRI, Template Record for linecard and interface38
     Figure Y: Example of a PSAMP SSRI Data Record, Encoded using a
        subTemplateMultiList........................................38
     Figure Z: Common and Specific Properties Exported Together
        [RFC5473]...................................................40
     Figure ZA: Common and Specific Properties Exported Separately
        according to [RFC5473]......................................40
     Figure ZB: Common and Specific Properties Exported with Structured
        Data Information Element....................................40
     Figure B0: Using a subTemplateList to represent a Biflow.......51
     Figure B1: Template for the Biflow Fields......................52
     Figure B2: Template for the Key Fields.........................52
 
 
     <Claise, et. Al>        Expires April 15, 2010            [Page 5]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
     Figure B3: Biflow Data Set Encoded using Structured Data.......53
     Figure C0: Encoding IPS Alert, Template for Target ............55
     Figure C1: Encoding IPS Alert, Template for Attacker...........55
     Figure C2: Encoding IPS Alert, Template for Participant........56
     Figure C3: Encoding IPS Alert, Template for IPS Alert..........56
     Figure C4: Encoding IPS Alert, Data Set........................57
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010            [Page 6]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
      TO DO
      - Incorporate the WG consensus regarding the Selector ID Length
      - Does the WG want to include logical OR in this draft?
      - The template IDs used in appendix B could be modified to make
      them continue from the earlier examples. However, reviewing the
      template IDs already used, I saw:
        8.1 = 258
        8.2 = 259, 260
        8.3 = 261, 262, 263, 264
        8.4 = 270, 271, 272, 273
          #B = 300, 301.
        So there's clearly a gap where 265 through 269 weren't used or
        were removed. Also Template could start at 256.
 
 
     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.
 
 
     <Claise, et. Al>        Expires April 15, 2010            [Page 7]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
      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.
 
      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
 
 
     <Claise, et. Al>        Expires April 15, 2010            [Page 8]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
          One of the Information Elements supporting structured data,
          i.e., the basicList, subTemplateList, or subTemplateMultiList
          Information Elements.
 
 
     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
      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.
 
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010            [Page 9]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
     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,
      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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 10]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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
      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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 11]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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 case 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
              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
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 12]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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 Appendix C8. for a specific example 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.
 
      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.
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 13]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
     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, a list of
      interface indexes, a 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.
 
 
     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.
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 14]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
 
     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.
 
      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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 15]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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 ...                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 16]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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
 
 
      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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 17]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
       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
      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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 18]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
          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                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
         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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 19]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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 ...                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 20]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
          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                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
      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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 21]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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.
 
      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
 
      Structured Data Information Elements MAY be used in Options
      Template Sets.
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 22]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
      As an example, consider a mediation function that must aggregate
      Data Records from multiple Observation Point types:
 
         Router 1, (interface 1)
         Router 2, (line card A)
         Router 3, (line card B)
         Router 4, (line card C, interface 2)
 
      In order to encode the PSAMP Selection Sequence Report
      Interpretation [RFC5476], the mediation function must express this
      combination of Observation Points as a single new Observation
      Point.  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 aggregated Observation Point as "one Information Element
      mapping the Observation Point".  However, the desired result may
      be easily achieved using the structured data types.  Refer to
      Section 8.4. "Encoding an Options Template Set using Structured
      Data" for an encoding example related to this case study.
 
      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 MAY be used as
      scope in an Options Template Set.
 
      Extending the previous example, the mediation function could
      export a given name for this complex aggregated Observation Point:
 
         Scope: Aggregated Observation Point (Structured Data)
         Non-Scope: a new Information Element containing the name
 
 
     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.
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 23]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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.
 
      Although a subTemplateMultiList with one Element can represent the
      contents of a subTemplateList, the subTemplateMultiList carries
      two additional bytes (Element  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
      subTemplateMultiList is more compact and is therefore RECOMMENDED
      in this case.  The basicList is best suited for exporting
      recurrence of a single Information Element.
 
      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.
 
 
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 24]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
     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.
 
 
     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.
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 25]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
 
     8.1. Encoding BasicList
 
      Consider encoding a multicast flow containing the following data:
 
      ---------------------------------------------------------------
       Ingress If | Source IP   | Destination IP  | Egress Interfaces
      ---------------------------------------------------------------
            9       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 = 24 octets       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Template ID = 258       |       Field Count = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|    ingressInterface = 10    |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   sourceIPv4Address = 8     |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| DestinationIPv4Address = 12 |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |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  = 35         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     ingressInterface = 9                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 26]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      |               sourceIPv4Address = 192.0.2.201                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             DestinationIPv4Address = 233.252.0.1              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      255      |        List Length = 16       |egressInterface|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |... Field Id=14| egressInterf. Field Length = 4|egressInterface|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                ... value 1 = 1                |egressInterface|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                ... value 2 = 4                |egressInterface|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                ... value 3 = 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
                    ...  , ...
 
 
      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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 27]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
                                                    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 = 259       |       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 = 260       |       Field Count = 6         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   sourceIPv4Address = 8     |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |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
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 28]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
     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 = 260          |      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=259           |   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    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 ... 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                  |
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 29]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | ... octets 7-8 of TimeValue5  |      digestHashValue 5 =      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   ... 0x0x91230978            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                   Figure O: Encoding subTemplateList, Data Set
 
 
     8.3. Encoding subTemplateMultiList
 
     As explained in section 4.4.3. , a subTemplateMultiList is used to
     export a list of mixed-type content where each top level element
     corresponds to a different Template Record.
 
     To illustrate this, consider the Flow Record with the following
     attributes:
 
 
          5 tuple (Flow Keys), octetCount, packetCount
                    attributes for classification
                         selectorId,
                         selectorAlgorithm
                    attributes for sampling
                         selectorId,
                         selectorAlgorithm,
                         samplingPacketInterval,
                         samplingPacketSpace
 
     This example demonstrates that the Selector Report Interpretation
     [RFC5476] can be encoded with the subTemplateMultiList. More
     specifically, the example describes Property Match Filtering
     Selector Report Interpretation [RFC5476] used for classification
     purposes, and the Systemic Count-Based Sampling as described in
     Section 6.5.2.1 of [RFC5476]. Some traffic will be filtered
     according to match properties configured, some will be sampled,
     some will be filtered and sampled, and some will not be filtered or
     be sampled.
 
     A subTemplateMultiList is best suited for exporting this variable
     data.  A Template is defined for classification attributes and
     another Template is defined for sampling attributes.  A Flow Record
     can contain data corresponding to either of the Templates, both or
     none.
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 30]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
     Consider the example below where the following Flow Record contains
     both classification and sampling attributes.
 
     Key attributes of the Flow Record:
 
      ------------------------------------------------------------------
      srcIP     | dstIP      | src   | dst  |proto|octetCount|packet
                |            | Port  | Port |     |          |Count
      ------------------------------------------------------------------
      192.0.2.1  192.0.2.105   1025     80     6     108000     120
      ------------------------------------------------------------------
 
 
     Classification attributes:
 
      -------------------------------------------
      selectorId  | selectorAlgorithm
      -------------------------------------------
         100         5 (Property Match Filtering)
      -------------------------------------------
 
 
     Sampling attributes:
 
     For Systemic Count-Based Sampling as defined in Section 6.5.2.1 of
     [RFC5476] the required algorithm-specific Information Elements are:
 
           samplingPacketInterval: number of packets selected in a row
           samplingPacketSpace:    number of packets between selections
 
        Example of a simple 1 out-of 100 systematic count-based Selector
        definition, where the samplingPacketInterval is 1 and the
        samplingPacketSpace is 99.
 
      --------------------------------------------------------------
      selectorId | selectorAlgorithm        | sampling | sampling
                 |                          | Packet   | Packet
                 |                          | Interval | Space
      --------------------------------------------------------------
         15        1 (Count-Based Sampling)      1         99
      --------------------------------------------------------------
 
 
     To represent the Flow Record, the following Template Records are
     defined:
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 31]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
         Template for classification attributes: 261
          Template for sampling attributes: 262
          Template for Flow Record: 263
 
          Flow record (263)
              |  (sourceIPv4Address)
              |  (destinationIPv4Address)
              |  (sourceTransportPort)
              |  (destinationTransportPort)
              |  (protocolIdentifier)
              |  (octetTotalCount)
              |  (packetTotalCount)
              |
              +------ classification attributes (261)
              |          (selectorId)
              |          (selectorAlgorithm)
              |
              +------ sampling attributes (262)
              |          (selectorId)
              |          (selectorAlgorithm)
              |          (samplingPacketInterval)
              |          (samplingPacketSpace)
 
 
      The following Template Record is defined for classification
      attributes:
 
       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          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Template ID = 261        |        Field Count = 2        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|    selectorId = 302         |        Field Length = 4       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| selectorAlgorithm = 304     |        Field Length = 1       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
            Figure P: Encoding subTemplateMultiList, Template for
                          Classification Attributes
 
 
      The Template for sampling attributes is defined 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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 32]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Set ID = 2           |          Length = 24          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Template ID = 262        |        Field Count = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|    selectorId = 302         |        Field Length = 4       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|  selectorAlgorithm = 304    |        Field Length = 1       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| samplingPacketInteval = 305 |        Field Length = 1       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| samplingPacketSpace = 306   |        Field Length = 1       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
        Figure Q: Encoding subTemplateMultiList, Template for Sampling
                                  Attributes
 
 
        Note that while samplingPacketInterval and samplingPacketSpace
        are defined as unsigned32, they are compressed down to 1 octet
        here as allowed by Reduced Size Encoding in section 6.2 of the
        IPFIX protocol specifications [RFC5101].
 
 
      Template for the Flow Record is defined as shown below:
 
       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 = 40          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Template ID = 263        |        Field Count = 8        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   sourceIPv4Address = 8     |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |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|   octetTotalCount = 85      |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   packetTotalCount = 86     |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 33]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      |0| subTemplateMultiList = ZZZ  |     Field Length = 0XFFFF     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
      Figure R: Encoding subTemplateMultiList, Template for Flow Record
 
     A subTemplateMultiList is used to export the classification and
     sampling attributes.  The Length of the subTemplateMultilist is
     chosen to be encoded in three bytes even though it may be less than
     255 octets.
 
     The Data Record 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Set ID = 263            |          Length = 48          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 sourceIPv4Address = 192.0.2.1                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              destinationIPv4Address = 192.0.2.105             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  sourceTransportPort = 1025   | destinationTransportPort = 80 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | protocol = 6  |        octetTotalCount = 108000               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     ...       |        packetTotalCount = 120                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     ...       |      255      | Attributes List Length = 20   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Classify Template ID = 261    | Classif. Attributes Length = 9|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      selectorId = 100                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |selectorAlg = 5| Sampling Template ID = 262     |Sampling Attr.|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Length = 11   |                selectorId = 15                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     ...       |selectorAlg = 1| Interval = 1   | Space = 99   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
              Figure S: Encoding subTemplateMultiList, Data Set
 
 
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 34]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
     8.4. Encoding an Options Template Set using Structured Data
 
      As described in section 5.3. , consider a mediation function that
      must aggregate Data Records from multiple different Observation
      Points.
 
      Say Observation Point 1 consists of one or more interfaces,
      Observation Points 2 and 3 consist of one or more line cards, and
      Observation Point 4 consists of one or more interfaces and one or
      more line cards.  Without the support for structured data, a
      template would have to be defined for every possible combination
      to interpret the data corresponding to each of the Observation
      Points.  However, with the support for structured data, a
      basicList can be used to encode the list of interfaces and another
      basicList can be used to encode the list of line cards.
 
      For the sake of simplicity, each Observation Point shown below has
      an <interface> or <linecard> or <line card and interface>. This
      can very well be extended to include a list of interfaces and a
      list of linecards using basicLists as explained above.
 
         Observation Point 1: Router 1, (interface 1)
         Observation Point 2: Router 2, (line card A)
         Observation Point 3: Router 3, (line card B)
         Observation Point 4: Router 4, (line card C, interface 2)
 
 
      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)
 
      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)
                              Router 2, (line card A)
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 35]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
                              Router 3, (line card B)
                              Router 4, (line card C, interface 2)
         selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1)
         selectorId: 10 (Sampler, Random 1 out-of ten)
 
      The following Templates are defined to represent the PSAMP SSRI:
      Template for representing PSAMP SSRI: 264
      Template for representing interface: 265
      Template for representing linecard: 266
      Template for representing linecard and interface: 267
 
 
           PSAMP SSRI (264)
              | (SelectionSequenceId)
              |
              +--- Observation Point 1 (265)
              |      (Interface Id)
              |
              +--- Observation Point 2 and 3 (266)
              |      (line card)
              |
              +--- Observation Point 4 (267)
              |      (line card)
              |      (Interface Id)
              |
              | (selectorId 1)
              | (selectorId 2)
 
 
                      Figure T: 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 = 264      |         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       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 36]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
       |        Field Length = 4       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
             Figure U: Options Template Record for PSAMP SSRI using
                              subTemplateMultiList
 
      The subTemplateMultiList is used to encode the list of Observation
      Points.
 
        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 = 265      |         Field Count = 1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|   ingressInterface = 10     |        Field Length = 4       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
             Figure V: PSAMP SSRI, Template Record for interface
 
 
        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 = 266      |         Field Count = 1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|      lineCardId = 141       |        Field Length = 4       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
              Figure W: PSAMP SSRI, Template Record for linecard
 
 
        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          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Template ID = 267      |         Field Count = 2       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|      lineCardId = 141       |        Field Length = 4       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|    ingressInterface = 10    |        Field Length = 4       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 37]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
       Figure X: PSAMP SSRI, Template Record for linecard and interface
 
 
         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 = 264         |           Length = 51         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    selectionSequenceId = 7                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      255      | Observation Point List Len=32 | OP1_Template  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |... ID = 265   |       OP1 Length = 8          | ingress ...   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                ... Interface = 1              | OP2,3 Template|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |... ID = 266   |       OP2,3 Length = 12       |lineCardId=A...|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                ...lineCardId = A              |lineCardId=B...|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                ...lineCardId = B              |OP4 Template...|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |... ID = 267   |       OP4 Length = 12         |lineCardId=C...|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                ...lineCardId = C              | ingress ...   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                ...Interface = 2               |selectorID ... |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                selectorId = 5                 |selectorID ... |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                selectorId = 10                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
        Figure Y: Example of a PSAMP SSRI Data Record, Encoded using a
                             subTemplateMultiList
 
      Note that the Data Record above contains multiple instances of
      Template 266 to represent Observation Point 2 (line card A) and
      Observation Point 3 (line card B).  Instead, if a single
      Observation Point had both line card A and line card B, a
      basicList would be used to represent the list of line cards.
 
 
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 38]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
     9. Relationship with the Other IFPIX Documents
 
     9.1. Relationship with Reducing Redundancy
 
        "Reducing Redundancy in IP Flow Information Export (IPFIX) and
        Packet Sampling (PSAMP) Reports" [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 Structured Data Element using Common Properties.
 
        When Structured Data Information Elements contain repeated
        elements, these elements may be replaced with a
        commonPropertiesID Information Element as specified in
        [RFC5473].  The replaced elements may include the basicList,
        subTemplateList and subTemplateMultiList Information Elements.
 
        This technique might help reducing the bandwidth requirements
        for the export.  However, a detailed analysis of the gain has
        not been done; refer to Section 8.3 "Efficiency Gain" [RFC5473]
        for further considerations.
 
 
 
     9.1.2. Encoding Common Properties elements With Structured Data
        Element.
 
        Structured Data Information Element MAY be used to define a list
        of commonPropertiesID, as a replacement for the specifications
        in [RFC5473].
 
        Indeed, the example in figures 1 and 2 of [RFC5473] can be
        encoded with the specifications in this document.
 
 
           +----------------+-------------+---------------------------+
           | sourceAddressA | sourcePortA |     <Flow1 information>   |
           +----------------+-------------+---------------------------+
           | sourceAddressA | sourcePortA |     <Flow2 information>   |
           +----------------+-------------+---------------------------+
           | sourceAddressA | sourcePortA |     <Flow3 information>   |
           +----------------+-------------+---------------------------+
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 39]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
           | sourceAddressA | sourcePortA |     <Flow4 information>   |
           +----------------+-------------+---------------------------+
           |      ...       |     ...     |            ...            |
           +----------------+-------------+---------------------------+
 
           Figure Z: Common and Specific Properties Exported Together
                                   [RFC5473]
 
 
           +------------------------+-----------------+-------------+
           | index for properties A | sourceAddressA  | sourcePortA |
           +------------------------+-----------------+-------------+
           |          ...           |      ...        |     ...     |
           +------------------------+-----------------+-------------+
 
 
           +------------------------+---------------------------+
           | index for properties A |     <Flow1 information>   |
           +------------------------+---------------------------+
           | index for properties A |     <Flow2 information>   |
           +------------------------+---------------------------+
           | index for properties A |     <Flow3 information>   |
           +------------------------+---------------------------+
           | index for properties A |     <Flow4 information>   |
           +------------------------+---------------------------+
 
         Figure ZA: Common and Specific Properties Exported Separately
                             according to [RFC5473]
 
           +----------------+-------------+---------------------------+
           | sourceAddressA | sourcePortA |     <Flow1 information>   |
           +----------------+-------------+---------------------------+
                                          |     <Flow2 information>   |
                                          +---------------------------+
                                          |     <Flow3 information>   |
                                          +---------------------------+
                                          |     <Flow4 information>   |
                                          +---------------------------+
                                          |            ...            |
                                          +---------------------------+
 
            Figure ZB: Common and Specific Properties Exported with
                      Structured Data Information Element
 
 
        The example in figure ZB could be encoded with a basicList if
        the <Flow information> represents a single Information Element,
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 40]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
        with a subTemplateList if the <Flow information> represents a
        Template Record, or with a subTemplateMultiList if the <Flow
        information> is composed of different Template Records.
 
        Using Structured Data Information Elements as a replacement for
        the techniques specified in "Reducing Redundancy in IP Flow
        Information Export (IPFIX) and Packet Sampling (PSAMP) Reports"
        [RFC5473] offers the advantage that a single Template Record is
        defined.  Hence the Collectors job in term of Template
        management and combining Template/Options Template Records is
        simplified.
 
        However, it must be noted that using Structured Data Information
        Elements as a replacement for the techniques specified in
        "Reducing Redundancy in IP Flow Information Export (IPFIX) and
        Packet Sampling (PSAMP) Reports" only applies to simplified
        cases. For example, the "Multiple Data Reduction" (section 7.1
        [RFC5473]) might be too complex to encode with Structured Data
        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.
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 41]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
          .  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
 
               - 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 subTemplateList or
        subTemplateMultiList. The basicList requires recurrence of a
        single element, so is not suitable for Biflows.
 
        Encoding Biflows with subTemplateList or subTemplateMultiList
        provides a more logical division of the information in both
        directions, although this encoding incurs a small additional
        bandwidth penalty.
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 42]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
        An example of Biflow encoding using Structure Data Information
        Elements and comparison with the [RFC5103] Biflow encoding is
        shown in Appendix B.
 
 
     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
      [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.
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 43]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
     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.
 
 
     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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 44]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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
 
 
     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.
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 45]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
        [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.
 
        [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.
 
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 46]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 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.
      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
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 47]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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"
               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>
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 48]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
        <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
                  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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 49]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
                  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>
            </enumeration>
          </restriction>
        </simpleType>
 
      </schema>
 
 
      Appendix B.  Example of Biflow Encoding using Structured Data
      Information Elements
 
        Referring to [RFC5103] figure 1, a Biflow consists of two parts:
        some "key" fields such as src/dst information (IP addresses,
        ports), followed by a set of forward/reverse pairs.
 
        Then looking at [RFC5103] figure 7, we see that the Reverse PEN
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 50]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
        is repeated many times to indicate fields which were observed in
        the reverse direction. Clearly that repetition is wasteful.
 
        Looking back at [RFC5103] figure 1, it's clear that the encoding
        can use a Template Record consisting of the Flow Keys followed
        by a subTemplateList consisting of two elements: one for the
        forward direction, the other for the reverse direction.
 
        The subTemplateList uses a single Template Record to describe
        the fields in both lists since they are a set of forward/reverse
        pairs.
 
 
               Uniflow                             Uniflow
 +-------+-------+-----------------+ +-------+-------+-----------------+
 | src A | dst B | counters/values | | src B | dst A | counters/values |
 +-------+-------+-----------------+ +-------+-------+-----------------+
     |       |            |                             |
     V       V            V                             V
 +-------+-------+---------------------+---------------------+
 | src A | dst B | fwd counters/values | rev counters/values |
 +-------+-------+---------------------+---------------------+
          |                  |                     |
          V                  V                     V
     key fields         fwd element          rev element
 
           Figure B0: Using a subTemplateList to represent a Biflow.
 
      The following example shows the example from Appendix A of
      [RFC5103] encoded using a subTemplateList:
 
 
       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          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Template ID = 268        |        Field Count = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| flowDirection            61 |       Field Length = 1        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| flowStartSeconds        150 |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| octetTotalCount          85 |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| packetTotalCount         86 |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 51]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
                   Figure B1: Template for the Biflow Fields
 
 
       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          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Template ID = 269        |        Field Count = 6        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| sourceIPv4Address         8 |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |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 = 28       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                     Figure B2: Template for the Key Fields
 
      The Template Record includes a subTemplateList for encoding the
      BiFlow fields for the forward and reverse direction.  Note that
      the subTemplateList is encoded using Fixed Length, as shown in the
      above template definition.
 
      Also, note that the overall template size is 24 + 32 = 56 octets,
      compared with 64 octets in the [RFC5103] example - so a small
      saving is achieved.
 
 
       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 = 269            |          Length = 45          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 sourceIPv4Address = 192.0.2.2                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              destinationIPv4Address = 192.0.2.3               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  sourceTransportPort = 32770  | destinationTransportPort = 80 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 52]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      | protocol = 6  |     Template ID = 268         | dir = forward |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            flowStartSeconds = 2006-02-01 17:00:00             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    octetTotalCount = 18000                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     packetTotalCount = 65                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | dir = reverse |    flowStartSeconds = 2006-02-01 17:00:01     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      ...      |           octetTotalCount = 128000            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      ...      |            packetTotalCount = 110             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      ...      |
      +-+-+-+-+-+-+-+-+
 
            Figure B3: Biflow Data Set Encoded using Structured Data
 
 
      Note that the Data Set length is 45, compared with 41 in RFC5103.
      The four additional octets are due to the inclusion of the 16-bit
      Template ID and two, 8-bit direction indicators.
 
      Clearly structured data offers an alternative way to encode
      Biflows.  Although this may not be best suited if the number of
      elements is small as in this example, it does offer a more robust
      and scalable solution if multiple elements need to be encoded.
 
 
      Appendix C.  Encoding IPS Alert using Structured Data Information
      Elements
 
      In this section, a contrived example of an IPS alert is used to
      demonstrate how complex data and multiple levels of hierarchy can
      be encoded using Structured Data Information Elements.
 
      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
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 53]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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.  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.
 
      ------------------------------------------------------------------
            |        |        |             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 (270)
      Template for attacker (271)
      Template for participant (272)
      Template for alert (273)
 
           alert (273)
           |  (signatureId)
           |  (protocolIdentifier)
           |  (riskRating)
           |
           +------- participant (272)
                    |
                    +------- attacker (271)
                    |           (sourceIPv4Address)
                    |           (applicationId)
                    |
                    +------- target (270)
                             |  (destinationIPv4Address)
                             |  (list of applicationId)
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 54]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      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 270:
 
      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 = 270       |       Field Count = 2         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| destinationIPv4Address = 12 |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|       basicList = XXX       |     Field Length = 0xFFFF     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
               Figure C0: Encoding IPS Alert, 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 271:
 
       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 = 271       |       Field Count = 2         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|    sourceIPv4Address = 8    |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|     applicationId = 95      |       Field Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
              Figure C1: Encoding IPS Alert, Template for Attacker
 
 
      Template Record for participant, with the Template ID 272:
 
       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       |
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 55]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Template ID = 272       |       Field Count = 1         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| subTemplateMultiList = ZZZ  |     Field Length = 0xFFFF     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
            Figure C2: Encoding IPS Alert, Template for Participant
 
 
      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 273:
 
 
       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 = 273       |       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 C3: Encoding IPS Alert, Template for IPS Alert
 
      The subTemplateList in the alert Template Record contains a list
      of participants.  For the sake of simplicity, only one participant
      is shown in the Data Set.
 
      Note that a subTemplateList is used to encode the list of
      participants. Each participant contains the list of attackers and
      targets encoded using a subTemplateMultiList and a target contains
      a basicList for encoding the list of applications.
 
      The Length of basicList, subTemplateList and subTemplateMultiList
      are encoded in three bytes even though it may be less than 255
      octets.
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 56]
 

     Internet-Draft <Export of Structured Data in IPFIX> October 2009
 
 
 
      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 = 273         |         Length = 63           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      signatureId = 1003       | protocolId=17 | riskRating=10 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      255      |participant List Length  = 52  |participant ...|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Template ID=272|      255      |subTemplateMultiList Length=47 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  attacker1 Template ID = 271  |   attacker1 Length = 12       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        attacker1 sourceIPv4Address = 192.0.2.3                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               attacker1 applicationId = 103                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   target1 Template ID = 270   |      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=271|     attacker2 Length = 12     | attacker2  ...|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | ...   sourceIPv4Address = 192.0.2.4           | attacker2  ...|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | ...      applicationId = 104                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                    Figure C4: Encoding IPS Alert, Data Set
 
 
 
 
 
 
 
 
 
     <Claise, et. Al>        Expires April 15, 2010           [Page 57]
 

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