[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

   IPFIX working group                                 Editor P. Aitken
   Internet Draft                                      Editor B. Claise
   draft-aitken-ipfix-new-infos-03                  Cisco Systems, Inc.
   Intended Status: Proposed Standard                    March 17, 2008
   Expires: September 17, 2008




         New Information Elements from the IPFIX Information Model


 Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed
   at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 3rd, 2008.

 Copyright Notice

   Copyright (C) The IETF Trust (2008).

 Abstract

   This document specifies the IPFIX protocol that serves for
   transmitting IP traffic flow information over the network.  In order



  Aitken, Claise            Standard Track                    [Page 1]


New Information Elements for the IPFIX Information Model    March 2008

   to transmit IP traffic flow information from an exporting process to
   an information collecting process, a common representation of flow
   data and a standard means of communicating them is required. This
   document describes how the IPFIX data and templates records are
   carried over a number of transport protocols from an IPFIX exporting
   process to an IPFIX collecting process.

 Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

 Table of Contents

     1. Introduction.................................................3
     2. Terminology..................................................3
      2.1 IPFIX Documents Overview...................................4
      2.2 PSAMP Documents Overview...................................4
     3. Information Element Identifiers..............................4
     4. New Information Elements in the range 1-127..................6
      4.1 interfaceName..............................................6
      4.2 interfaceDescription.......................................7
      4.3 forwardingStatus...........................................7
      4.4 mplsTopLabelPrefixLength...................................9
      4.5 postIpDiffServCodePoint...................................10
      4.6 multicastReplicationFactor................................10
     5. New Information Elements in the range 128-32767.............10
      5.1 postNATSourceIPv4Address..................................10
      5.2 postNATDestinationIPv4Address.............................11
      5.3 postNAPTSourceTransportPort...............................11
      5.4 postNAPTDestinationTransportPort..........................12
      5.5 natOriginatingAddressRealm................................12
      5.6 natEvent..................................................12
      5.7 initiatorOctets...........................................13
      5.8 responderOctets...........................................13
      5.9 firewallEvent.............................................13
      5.10 ingressVRFID.............................................14
      5.11 egressVRFID..............................................14
      5.12 VRFname..................................................14
      5.13 ethernetHeaderLength.....................................14
      5.14 ethernetPayloadLength....................................15
      5.15 ethernetTotalLength......................................15
      5.16 dot1qVlanId..............................................15
      5.17 dot1qPriority............................................16
      5.18 dot1qCustomerVlanId......................................16


  Aitken, Claise            Standard Track                    [Page 2]


New Information Elements for the IPFIX Information Model    March 2008

      5.19 dot1qCustomerPriority....................................16
      5.20 metroEvcId...............................................17
      5.21 metroEvcType.............................................17
      5.22 pseudoWireId.............................................17
      5.23 pseudoWireType...........................................18
      5.24 pseudoWireControlWord....................................18
      5.25 ingressPhysicalInterface.................................18
      5.26 egressPhysicalInterface..................................18
      5.27 postDot1qVlanId..........................................19
      5.28 postDot1qCustomerVlanId..................................19
      5.29 ethernetType.............................................19
      5.30 selectorName.............................................20
     6. Relationship between dot1qVlanId and vlanId.................20
     7. Relationship between interface related Information Elements.21
     8. IANA Considerations.........................................21
     9. References..................................................22
      9.1 Normative References......................................22
      9.2 Informative References....................................23
     10. Security Considerations....................................25
     11. Contributors...............................................25
     12. Acknowledgements...........................................25
     13. Authors' Addresses.........................................25
     14. Intellectual Property Statement............................26
     15. Copyright Statement........................................26
     16. Disclaimer.................................................27


1.    Introduction

   The IPFIX Information Model [RFC5102] defines an extensible list of
   Information Elements which may be transmitted by the IPFIX protocol
   [RFC5101].

   This document lists a series of new Information Elements to update
   the IPFIX Information Model, and acts as the persistent publication
   medium requested in the IANA considerations section of the IPFIX
   Information Model [RFC5102] ("The specification of new IPFIX
   Information Elements MUST use the template specified in section 2.1
   and MUST be published using a well established and persistent
   publication medium").


2.    Terminology

   IPFIX-specific terminology used in this document is defined in
   section 2 of the IPFIX Protocol [RFC5101].  As in the IPFIX Protocol
   [RFC5101], these IPFIX-specific terms have the first letter of a word
   capitalized when used in this document.


  Aitken, Claise            Standard Track                    [Page 3]


New Information Elements for the IPFIX Information Model    March 2008



2.1     IPFIX Documents Overview

   The IPFIX Protocol [RFC5101] provides network administrators with
   access to IP flow information.

   The architecture for the export of measured IP flow information out
   of an IPFIX exporting process to a collecting process is defined in
   the IPFIX Architecture [IPFIX-ARCH], per the requirements defined in
   RFC 3917 [RFC3917].

   The IPFIX Architecture [IPFIX-ARCH] specifies how IPFIX Data Records
   and Templates are carried via a congestion-aware transport protocol
   from IPFIX Exporting Processes to IPFIX Collecting Processes.

   IPFIX has a formal description of IPFIX Information Elements, their
   name, type and additional semantic information, as specified in the
   IPFIX Information Model [RFC5102].

   Finally the IPFIX Applicability Statement [IPFIX-AS] describes what
   type of applications can use the IPFIX protocol and how they can use
   the information provided.  It furthermore shows how the IPFIX
   framework relates to other architectures and frameworks.


2.2     PSAMP Documents Overview

   The document "A Framework for Packet Selection and Reporting" [PSAMP-
   FMWK], describes the PSAMP framework for network elements to select
   subsets of packets by statistical and other methods, and to export a
   stream of reports on the selected packets to a collector.

   The set of packet selection techniques (sampling, filtering, and
   hashing) supported by PSAMP are described in "Sampling and Filtering
   Techniques for IP Packet Selection" [PSAMP-TECH].

   The PSAMP protocol [PSAMP-PROTO] specifies the export of packet
   information from a PSAMP Exporting Process to a PSAMP Collecting
   Process.  Like IPFIX, PSAMP has a formal description of its
   information elements, their name, type and additional semantic
   information.  The PSAMP information model is defined in [PSAMP-INFO].

   Finally [PSAMP-MIB] describes the PSAMP Management Information Base.


3.    Information Element Identifiers




  Aitken, Claise            Standard Track                    [Page 4]


New Information Elements for the IPFIX Information Model    March 2008

   The value of the Information Element identifiers are in the range of
   1 - 32767.  Within this range, Information Element identifier values
   in the sub-range of 1-127 are compatible with field types used by
   NetFlow version 9 [RFC3954].

   The following list gives an overview of the new Information Element
   identifiers that are in the range 1-127.  These Information Elements
   were previously RESERVED according to the IPFIX Information Model
   [RFC5102] and IANA.

      +-------+----------------------------+
      |    ID | Name                       |
      +-------+----------------------------+
      |    82 | interfaceName              |
      |    83 | interfaceDescription       |
      ~       ~                            ~
      |    89 | forwardingStatus           |
      ~       ~                            ~
      |    91 | mplsTopLabelPrefixLength   |
      ~       ~                            ~
      |    98 | postIpDiffServCodePoint    |
      |    99 | multicastReplicationFactor |
      +-------+----------------------------+

   The following list gives an overview of new Information Elements, not
   part of the RESERVED range.  It also displays the ideal Information
   Element identifiers that we would like IANA to assign. Note that the
   following web site http://ipfix.netlab.nec.de/infoElements.php,
   maintained by the IPFIX Chair (Juergen Quittek) is a placeholder for
   the allocation of the Information Element Id, while waiting for the
   IANA assignments.





















  Aitken, Claise            Standard Track                    [Page 5]


New Information Elements for the IPFIX Information Model    March 2008

      +-------+----------------------------------+
      |    ID | Name                             |
      +-------+----------------------------------+
      |   225 | postNATSourceIPv4Address         |
      |   226 | postNATDestinationIPv4Address    |
      |   227 | postNAPTSourceTransportPort      |
      |   228 | postNAPTDestinationTransportPort |
      |   229 | natOriginatingAddressRealm       |
      |   230 | natEvent                         |
      |   231 | InitiatorOctets                  |
      |   232 | ResponderOctets                  |
      |   233 | firewallEvent                    |
      |   234 | ingressVRFID                     |
      |   235 | egressVRFID                      |
      |   236 | VRFname                          |
      ~       ~                                  ~
      |   240 | ethernetHeaderLength             |
      |   241 | ethernetPayloadLength            |
      |   242 | ethernetTotalLength              |
      |   243 | dot1qVlanId                      |
      |   244 | dot1qPriority                    |
      |   245 | dot1qCustomerVlanId              |
      |   246 | dot1qCustomerPriority            |
      |   247 | metroEvcId                       |
      |   248 | metroEvcType                     |
      |   249 | pseudoWireId                     |
      |   250 | pseudoWireType                   |
      |   251 | pseudoWireControlWord            |
      |   252 | ingressPhysicalInterface         |
      |   253 | egressPhysicalInterface          |
      |   254 | postDot1qVlanId                  |
      |   255 | postDot1qCustomerVlanId          |
      |   256 | ethernetType                     |
      ~       ~                                  ~
      |   335 | selectorName                     |
      +-------+----------------------------------+


4.    New Information Elements in the range 1-127


4.1     interfaceName

   Description:
      A short name uniquely describing an interface, eg "Eth1/0".
   Abstract Data Type: string
   ElementId: 82
   Status: current
   Reference:
      See RFC 2863 [RFC2863] for the definition of the ifName object.


  Aitken, Claise            Standard Track                    [Page 6]


New Information Elements for the IPFIX Information Model    March 2008



4.2     interfaceDescription

   Description:
      The description of an interface, eg "FastEthernet 1/0" or "ISP
      connection".
   Abstract Data Type: string
   ElementId: 83
   Status: current
   Reference:
      See RFC 2863 [RFC2863] for the definition of the ifDescr object.


4.3     forwardingStatus

   Description:
      Describes the forwarding status of the flow and any attached
      reasons.

      Forwarding Status is a variable length field with length of 1, 2
      or 4 octets.


      *** IANA ACTION ***

      The values of this element are to be allocated from IANA
      registries which can be found at
      http://www.iana.org/assignments/...
      A. When length = 1 octet:

               0 1 2 3 4 5 6 7
              +-+-+-+-+-+-+-+-+
              | S |           |
              | t |  Reason   |
              | a |  codes    |
              | t |  or       |
              | u |  flags    |
              | s |           |
              +-+-+-+-+-+-+-+-+

          Status:

          00b = Unknown
          01b = Forwarded
          10b = Dropped
          11b = Consumed

          Reason codes:


  Aitken, Claise            Standard Track                    [Page 7]


New Information Elements for the IPFIX Information Model    March 2008


          Reason codes are defined per status code.

          Reason Code (status = 01b, Forwarded):

          000000b = Unknown
          000001b = Fragmented
          000010b = Not Fragmented


          Reason Code (status = 10b, Dropped):

          000000b = Unknown
          000001b = ACL Deny
          000010b = ACL drop
          000011b = Unroutable
          000100b = Adjacency
          000101b = Fragmentation & DF set
          000110b = Bad header checksum
          000111b = Bad total Length
          001000b = Bad Header Length
          001001b = bad TTL
          001010b = Policer
          001011b = WRED
          001100b = RPF
          001101b = For us
          001110b = Bad output interface
          001111b = Hardware


          Reason Code (status = 11b, Consumed):

          000000b = Unknown
          000001b = Punt Adjacency
          000010b = Incomplete Adjacency
          000011b = For us


            Example 1:

          hex dump: 01 000000
          decode:   01         -> Forward
                       000000  -> No further information

            Example 2:

          hex dump: 10 001001
          decode  : 10          -> Drop
                       001001   -> Fragmentation & DF set



  Aitken, Claise            Standard Track                    [Page 8]


New Information Elements for the IPFIX Information Model    March 2008


       B. When length = 2 octets:

          A length of 2 indicates an extended reason:

          bit 0 0 0 0 0 0 0 0  0 0 1 1 1 1 1 1
              0 1 2 3 4 5 6 7  8 9 0 1 2 3 4 5
            +----------------+----------------+
            |Status & Reason | Extended Reason|
            +----------------+----------------+

          The status and reason are as defined in (A) above.  The
          extended reasons are yet to be defined.

       C. When length = 4 octets:

          If there are further extensions to the reason, the field
          length is 4:

     0 0 0 0 0 0 0 0  0 0 1 1 1 1 1 1  1 1 1 1 2 2 2 2  2 2 2 2 2 2 3 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
   +----------------+----------------+----------------+----------------+
   |Status & Reason | Extended Reason|        Further Extensions       |
   +----------------+----------------+----------------+----------------+

          The status, reason and extended reason are as defined in (B)
          above.  Further extended reasons are yet to be defined.

   Abstract Data Type: octetArray
   Data Type Semantics: flags
   ElementId: 89
   Status: current


4.4     mplsTopLabelPrefixLength

   Description:
      The prefix length of the subnet of the mplsTopLabelIPv4Address
      that the MPLS top label will cause the Flow to be forwarded to.
   Abstract Data Type: unsigned 8
   Data Type Semantics: identifier
   ElementId: 91
   Status: current
   Units: bits
   Range: The valid range is 0-32
   Reference:
      See RFC 3031 for the association between MPLS labels and prefix
      lengths.



  Aitken, Claise            Standard Track                    [Page 9]


New Information Elements for the IPFIX Information Model    March 2008


4.5     postIpDiffServCodePoint

   Description:
       The definition of this Information Element is identical to the
       definition of Information Element 'ipDiffServCodePoint', except
       that it reports a potentially modified value caused by a
       middlebox function after the packet passed the Observation
       Point.
       Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 98
   Status: current
   Range: The valid range is 0-63.
   Reference:
      See RFC 3260 [RFC3260] for the definition of the Differentiated
      Services Field.  See section 5.3.2 of RFC 1812 [RFC1812] and RFC
      791 [RFC791] for the definition of the IPv4 TOS field.  See RFC
      2460 [RFC2460] for the definition of the IPv6 Traffic Class
      field.  See the IPFIX Informaiton Model [RFC5102] for the
      'ipDiffServCodePoint' specification.


4.6     multicastReplicationFactor

   Description:
       The amount of multicast replication that's applied to a traffic
       stream.
   Abstract Data Type:
   Data Type Semantics:
   ElementId: 99
   Status: current
   Reference:
       See RFC 1112 [RFC1112] for the specification of reserved IPv4
       multicast addresses.  See RFC 4291 [RFC4291] for the
       specification of reserved IPv6 multicast addresses.


5.   New Information Elements in the range 128-32767

5.1     postNATSourceIPv4Address

   Description:
       The definition of this Information Element is identical to the
       definition of Information Element 'sourceIPv4Address', except
       that it reports a modified value caused by a NAT middlebox
       function after the packet passed the Observation Point.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 225


  Aitken, Claise            Standard Track                   [Page 10]


New Information Elements for the IPFIX Information Model    March 2008

   Status: current
   Reference:
       See RFC 791 [RFC791] for the definition of the IPv4 source
       address field.  See RFC 3022 [RFC3022] for the definition of
       NAT.  See RFC 3234 [RFC3234] for the definition of middleboxes.


5.2     postNATDestinationIPv4Address

   Description:
       The definition of this Information Element is identical to the
       definition of Information Element 'destinationIPv4Address',
       except that it reports a modified value caused by a NAT
       middlebox function after the packet passed the Observation
       Point.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 226
   Status: current
   Reference:
       See RFC 791 [RFC791] for the definition of the IPv4 destination
       address field.  See RFC 3022 [RFC3022] for the definition of
       NAT.  See RFC 3234 [RFC3234] for the definition of middleboxes.


5.3     postNAPTSourceTransportPort

   Description:
       The definition of this Information Element is identical to the
       definition of Information Element 'sourceTransportPort', except
       that it reports a modified value caused by a Network Address
       Port Translation (NAPT) middlebox function after the packet
       passed the Observation Point.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 227
   Status: current
   Reference:
       See RFC 768 [RFC768] for the definition of the UDP source port
       field.  See RFC 793 [RFC793] for the definition of the TCP
       source port field.  See RFC 4960 [RFC4960] for the definition of
       SCTP.
       See RFC 3022 [RFC3022] for the definition of NAPT.  See RFC 3234
       [RFC3234] for the definition of middleboxes.
       Additional information on defined UDP and TCP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.






  Aitken, Claise            Standard Track                   [Page 11]


New Information Elements for the IPFIX Information Model    March 2008

5.4     postNAPTDestinationTransportPort

   Description:
       The definition of this Information Element is identical to the
       definition of Information Element 'destinationTransportPort',
       except that it reports a modified value caused by a Network
       Address Port Translation (NAPT) middlebox function after the
       packet passed the Observation Point.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 228
   Status: current
   Reference:
       See RFC 768 [RFC768] for the definition of the UDP source port
       field.  See RFC 793 [RFC793] for the definition of the TCP
       source port field.  See RFC 4960 [RFC4960] for the definition of
       SCTP.    See RFC 3022 [RFC3022] for the definition of NAPT.  See
       RFC 3234 [RFC3234] for the definition of middleboxes.
       Additional information on defined UDP and TCP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.


5.5     natOriginatingAddressRealm

   Description:
       Indicates whether the session was created because traffic
       originated in the private or public address realm.
       postNATSourceIPv4Address, postNATDestinationIPv4Address,
       postNAPTSourceTransportPort, and
       postNAPTDestinationTransportPort are qualified with the address
       realm in perspective.
       The allowed values are:
        Private: 1
        Public:  2
   Abstract Data Type: unsigned8
   Data Type Semantics: flags
   ElementId: 229
   Status: current
   Reference:
      See RFC 3022 [RFC3022] for the definition of NAT.


5.6     natEvent

   Description:
       Indicates a NAT event. The allowed values are:
          1 - Create event.
          2 - Delete event.




  Aitken, Claise            Standard Track                   [Page 12]


New Information Elements for the IPFIX Information Model    March 2008

       A Create event is generated when a NAT translation is created,
       whether dynamically or statically.  A Delete event is generated
       when a NAT translation is deleted.
   Abstract Data Type: unsigned8
   Data Type Semantics:
   ElementId: 230
   Status: current
   Reference:
   See RFC 3022 [RFC3022] for the definition of NAT.


5.7     initiatorOctets

    Description:
      The total number of layer 4 payload bytes in a flow from the
      initiator.  The initiator is the device which triggered the
      session creation, and remains the same for the life of the
      session.
   Abstract Data Type: unsigned64
   Data Type Semantics:
   ElementId: 231
   Status: current


5.8     responderOctets

    Description:
      The total number of layer 4 payload bytes in a flow from the
      responder.  The responder is the device which replies to the
      initiator, and remains the same for the life of the session.
   Abstract Data Type: unsigned64
   Data Type Semantics:
   ElementId: 232
   Status: current


5.9     firewallEvent

    Description:
      Indicates a firewall event.  The allowed values are:

      0 - Ignore (invalid)
      1 - Flow Created
      2 - Flow Deleted
      3 - Flow Denied
      4 - Flow Alert

   Abstract Data Type: unsigned8
   Data Type Semantics:
   ElementId: 233


  Aitken, Claise            Standard Track                   [Page 13]


New Information Elements for the IPFIX Information Model    March 2008

   Status: current


5.10      ingressVRFID

    Description:
      An unique identifier of the VRFname where the packets of this
      flow are being received.  This identifier is unique per Metering
      Process
   Abstract Data Type: unsigned32
   Data Type Semantics:
   ElementId: 234
   Status: current


5.11      egressVRFID

    Description:
      An unique identifier of the VRFname where the packets of this
      flow are being sent.  This identifier is unique per Metering
      Process
   Abstract Data Type: unsigned32
   Data Type Semantics:
   ElementId: 235
   Status: current


5.12      VRFname

    Description:
      The name of a VPN Routing and Forwarding table (VRF).
   Abstract Data Type: string
   ElementId: 236
   Status: current
   Reference:
      See RFC 4364 [RFC4364] for the definition of VRF.


5.13      ethernetHeaderLength

    Description:
      The difference between the length of an Ethernet frame (minus the
      FCS) and the length of its MAC Client Data section (including any
      padding) as defined in section 3.1 of [IEEE.802-3.2005].  It does
      not include the Preamble, SFD and Extension field lengths.
   Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 240
   Status: current
   Units: octets


  Aitken, Claise            Standard Track                   [Page 14]


New Information Elements for the IPFIX Information Model    March 2008

   Reference:
      (1) [IEEE.802-3.2005]


5.14      ethernetPayloadLength

    Description:
      The length of the MAC Client Data section (including any padding)
      of a frame as defined in section 3.1 of [IEEE.802-3.2005].
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 241
   Status: current
   Units: octets
   Reference:
      (1) [IEEE.802-3.2005]


5.15      ethernetTotalLength

    Description:
      The total length of the Ethernet frame (excluding the Preamble,
      SFD, Extension and FCS fields) as described in section 3.1 of
      [IEEE.802-3.2005].
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 242
   Status: current
   Units: octets
   Reference:
      (1) [IEEE.802-3.2005]


5.16      dot1qVlanId

    Description:
      The value of the 12-bit VLAN Identifier portion of the Tag
      Control Information field of an Ethernet frame as described in
      section 3.5.5 of [IEEE.802-3.2005].  The structure and semantics
      within the Tag Control Information field are defined in IEEE
      P802.1Q.  In case of a QinQ frame, it represents the outer tag's
      VLAN identifier and in case of an IEEE 802.1ad frame it
      represents the Service VLAN identifier in the S-TAG Tag Control
      Information (TCI) field as described in [IEEE.802-1ad.2005].
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 243
   Status: current
   Reference:
      (1) [IEEE.802-3.2005]


  Aitken, Claise            Standard Track                   [Page 15]


New Information Elements for the IPFIX Information Model    March 2008

      (2) [IEEE.802-1ad.2005]


5.17      dot1qPriority

    Description:
      The value of the 3-bit User Priority portion of the Tag Control
      Information field of an Ethernet frame as described in section
      3.5.5 of [IEEE.802-3.2005].  The structure and semantics within
      the Tag Control Information field are defined in IEEE P802.1Q.
      In case of a QinQ frame, it represents the outer tag's 3-bit
      Class of Service (CoS) identifier and in case of an IEEE 802.1ad
      frame it represents the 3-bit Priority Code Point (PCP) portion
      of the S-TAG Tag Control Information (TCI) field as described in
      [IEEE.802-1ad.2005].
   Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 244
   Status: current
   Reference:
      (1) [IEEE.802-3.2005]
      (2) [IEEE.802-1ad.2005]


5.18      dot1qCustomerVlanId

    Description:
      In case of a QinQ frame, it represents the inner tag's (*) VLAN
      identifier and in case of an IEEE 802.1ad frame it represents the
      Customer VLAN identifier in the C-TAG Tag Control Information
      (TCI) field as described in [IEEE.802-1ad.2005].
      (*) Note: the 801.2Q tag directly following the outer one.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 245
   Status: current
   Reference:
      (1) [IEEE.802-1ad.2005]
      (2) [IEEE.802-1Q.2003]


5.19      dot1qCustomerPriority

    Description:
      In case of a QinQ frame, it represents the inner tag's (*) Class
      of Service (CoS) identifier and in case of an IEEE 802.1ad frame
      it represents the 3-bit Priority Code Point (PCP) portion of the
      C-TAG Tag Control Information (TCI) field as described in
      [IEEE.802-1ad.2005].
      (*) Note: the 801.2Q tag directly following the outer one.


  Aitken, Claise            Standard Track                   [Page 16]


New Information Elements for the IPFIX Information Model    March 2008

   Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 246
   Status: current
   Reference:
      (1) [IEEE.802-1ad.2005]
      (2) [IEEE.802-1Q.2003]


5.20      metroEvcId

    Description:
      The EVC Service Attribute which uniquely identifies the Ethernet
      Virtual Connection (EVC) within a Metro Ethernet Network, as
      defined in section 6.2 of MEF 10.1.  The MetroEVCID is encoded in
      a string of up to 100 characters.
   Abstract Data Type: string
   ElementId: 247
   Status: current
   Reference:
      (1) MEF 10.1 (Ethernet Services Attributes Phase 2)
      (2) MEF16 (Ethernet Local Management Interface)


5.21      metroEvcType

    Description:
      The 3-bit EVC Service Attribute which identifies the type of
      service provided by an EVC.
   Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 248
   Status: current
   Reference:
      (1) MEF 10.1 (Ethernet Services Attributes Phase 2)
      (2) MEF16 (Ethernet Local Management Interface)


5.22      pseudoWireId

    Description:
      A 32-bit non-zero connection identifier, which together with the
      pseudoWireType, identifies the Pseudo Wire (PW) as defined in RFC
      4447 [RFC4447].
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 249
   Status: current
   Reference:
      See RFC 4447 [RFC4447] for pseudowire definitions.


  Aitken, Claise            Standard Track                   [Page 17]


New Information Elements for the IPFIX Information Model    March 2008



5.23      pseudoWireType

    Description:
      The value of this information element identifies the type of MPLS
      Pseudo Wire (PW) as defined in RFC 4446.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 250
   Status: current
   Reference:
      See RFC 4446 [RFC4446] for the pseudowire type definition, and
      http://www.iana.org/assignments/pwe3-parameters for the IANA
      Pseudowire Types Registry.


5.24      pseudoWireControlWord

    Description:
      The 32-bit Preferred Pseudo Wire (PW) MPLS Control Word as
      defined in Section 3 of RFC 4385 [RFC4385].
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 251
   Status: current
   Reference:
      See RFC 4385 [RFC4385] for the Pseudo Wire Control Word
      definition.


5.25      ingressPhysicalInterface

    Description:
      The index of a networking device's physical interface (example, a
      switch port) where packets of this flow are being received.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 252
   Status: current
   Reference:
      See RFC 2863 [RFC2863] for the definition of the ifIndex object.


5.26      egressPhysicalInterface

    Description:
      The index of a networking device's physical interface (example, a
      switch port) where packets of this flow are being sent.


  Aitken, Claise            Standard Track                   [Page 18]


New Information Elements for the IPFIX Information Model    March 2008

   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 253
   Status: current
   Reference:
      See RFC 2863 [RFC2863] for the definition of the ifIndex object.


5.27      postDot1qVlanId

    Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'dot1qVlanId', except that it
      reports a potentially modified value caused by a middlebox
      function after the packet passed the Observation Point.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 254
   Status: current
   Reference:
      (1) [IEEE.802-3.2005]
      (2) [IEEE.802-1ad.2005]


5.28      postDot1qCustomerVlanId

    Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'dot1qCustomerVlanId', except
      that it reports a potentially modified value caused by a
      middlebox function after the packet passed the Observation Point.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 255
   Status: current
   Reference:
      (1) [IEEE.802-1ad.2005]
      (2) [IEEE.802-1Q.2003]


5.29      ethernetType

    Description:
      The Ethernet type field of an Ethernet frame that identifies the
      MAC client protocol carried in the payload as defined in
      paragraph 1.4.349 of [IEEE.802-3.2005].
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 256
   Status: current


  Aitken, Claise            Standard Track                   [Page 19]


New Information Elements for the IPFIX Information Model    March 2008

   Reference:
      (1) [IEEE.802-3.2005]
      (2) Ethertype registry available at
          http://standards.ieee.org/regauth/ethertype/eth.txt


5.30      selectorName

   Description:
      The name of a selector identified by a selectorID.  Globally
      unique per Metering Process.
   Abstract Data Type: string
   ElementId: 335
   Status: current


6.    Relationship between dot1qVlanId and vlanId

   The IPFIX Information Model [RFC5102] specifies the vlanId
   Information Element, while this document specifies the dot1qVlanId.

   The vlanId Information Element references [IEEE.802-1Q.2003], while
   the dot1qVlanId references [IEEE.802-3.2005] and [IEEE.802-1ad.2005].
   Since the [IEEE.802-1ad.2005] supersedes the [IEEE.802-1Q.2003] (it
   mentions: "Amendment to IEEE Std 802.1Q-2005".), then the dot1qVlanId
   supersedes vlanId.


   ***IANA ACTION ***

   As a consequence the vlanId specified in the IPFIX Information Model
   [RFC5102] is now deprecated:

   vlanId
      Description:
         The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
         Control Information field that was attached to the IP packet.
      Abstract Data Type: unsigned16
      Data Type Semantics: identifier
      ElementId: 58
      Status: deprecated
      Reference:
         See [IEEE.802-1Q.2003].


   ***IANA ACTION ***

   This document also specifies postDot1qVlanId, in connection with the
   dot1qCustomerVlanId.  As a consequence, the postVlanId specified in
   the IPFIX Information Model [RFC5102] is now deprecated:


  Aitken, Claise            Standard Track                   [Page 20]


New Information Elements for the IPFIX Information Model    March 2008


   postVlanId
      Description:
         The definition of this Information Element is identical to the
         definition of Information Element 'vlanId', except that it
         reports a potentially modified value caused by a middlebox
         function after the packet passed the Observation Point.
      Abstract Data Type: unsigned16
      Data Type Semantics: identifier
      ElementId: 59
      Status: deprecated
      Reference:
         See [IEEE.802-1Q.2003].

7.    Relationship between interface related Information Elements

   The IPFIX Information Model [RFC5102] specifies the ingressInterface
   (#10) and egressInterface (#14) information elements, while this
   document specifies the ingressPhysicalInterface and
   egressPhysicalInterface.

   The IPFIX definitions for ingressInterface and egressInterface are
   somewhat vague, essentially in case of the virtual interfaces.  Let
   us consider traffic transiting a tunnel, where the virtual and
   physical interfaces are different.  If one implementation uses the
   ingressInterface and egressInterface to report the physical
   interfaces while another implementation uses the same information
   elements to report the virtual interfaces, without somehow making
   this clear to the Collector, then any reports and analysis are going
   to be skewed.

   The specifications of ingressPhysicalInterface and
   egressPhysicalInterface clarifies the situation.

   The relationship between the multiple sub-layers of network
   interfaces is specified in the ifStackTable MIB table in the
   interface MIB [RFC2863].


8.    IANA Considerations

   This document specifies new IPFIX Information Elements in two ranges.

   Information Elements in the range 1 to 127 are compatible with field
   types used by NetFlow version 9 [RFC3954].  These Information
   Elements were previously RESERVED according to the IPFIX Information
   Model [RFC5102] and IANA.  These should be allocated immediately with
   the specified IDs to retain backwards compatibility with NetFlow
   version 9 [RFC3954].



  Aitken, Claise            Standard Track                   [Page 21]


New Information Elements for the IPFIX Information Model    March 2008

   The remainder of the Information Elements (in the range 128 and up)
   are new, and are therefore subject to expert review as specified in
   the IPFIX Information Model [RFC5102].  They are listed here with the
   ideal Information Element identifiers that we would like IANA to
   assign.

   In addition, some IANA actions have been highlighted in section 7.

   Finally, the forwardingStatus Information Element requires the
   creation of new IANA registries.

9.    References

9.1     Normative References

 [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
             August 1980.

 [RFC791]   J. Postel, "Internet Protocol. DARPA Internet Program.
             Protocol Specification," RFC 791, September 1981.

 [RFC793]   J. Postel, "Transmission Control Protocol", September
             1981.

 [RFC1112]  B. Braden, "Requirements for Internet hosts -
             communication layers", Octobre 1989.

 [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
             RFC 1812, June 1995.

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997

 [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

 [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
             MIB", RFC 2863, June 2000.

 [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
             Architecture", RFC 4291, February 2006.

 [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
             Networks (VPNs)", RFC 4364, February 2006.

 [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
             "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
             Use over an MPLS PSN", RFC 4385, February 2006.




  Aitken, Claise            Standard Track                   [Page 22]


New Information Elements for the IPFIX Information Model    March 2008

 [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
             Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

 [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
             G. Heron, "Pseudowire Setup and Maintenance Using the
             Label Distribution Protocol (LDP)", RFC 4447, April 2006.

 [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
             RFC 4960, September 2007.

 [RFC5101]  Claise, B., Ed., "Specification of the IP Flow Information
             Export (IPFIX) Protocol for the Exchange of IP Traffic
             Flow Information", RFC 5101, January 2008.

 [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
             Meyer, "Information Model for IP Flow Information Export",
             RFC 5102, January 2008.

 [IEEE.802-1ad.2005]
             "IEEE Standard for Local and Metropolitan Area Networks---
             Virtual Bridged Local Area Networks---Amendment 4:
             Provider Bridges", IEEE 802.1ad-2005, May 26, 2006.

 [IEEE.802-1Q.2003]
             "IEEE Standards for Local and Metropolitan Area Networks:
             Virtual Bridged Local Area Networks", IEEE 802.1Q,2003
             Edition-2003.

 [IEEE Std 802.1Q-2005]
             "IEEE Standard for Local and Metropolitan Area Networks---
             Virtual Bridged Local Area Networks", IEEE 802.1Q-2005,
             May 19, 2006.

 [IEEE.802-3.2005]
             "IEEE Standard for Information Technology -
             Telecommunications and Information Exchange Between
             Systems - Local and Metropolitan Area Networks - Specific
             Requirements Part 3: Carrier Sense Multiple Access with
             Collision Detection (CSMA/CD) Access Method and Physical
             Layer Specifications", IEEE 802.3-2005, Dec 09, 2005.

 [ISO_IEC.7498-1_1994]
             International Organization for Standardization,
             "Information technology -- Open Systems Interconnection --
             Basic Reference Model: The Basic Mode", ISO Standard 7498-
             1:1994, June 1996.

9.2     Informative References




  Aitken, Claise            Standard Track                   [Page 23]


New Information Elements for the IPFIX Information Model    March 2008

 [RFC3022]    Srisuresh, P. and K. Egevang, "Traditional IP Network
               Address Translator (Traditional NAT)", RFC 3022, January
               2001.

 [RFC3234]    Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
               Issues", RFC 3234, February 2002.

 [RFC3260]    Grossman, D., "New Terminology and Clarifications for
               Diffserv", RFC 3260, April 2002.

 [RFC3917]    Quittek, J., Zseby, T., Claise, B., Zander, S.,
               "Requirements for IP Flow Information Export" RFC 3917,
               October 2004

 [RFC3954]    Claise, B., et al "Cisco Systems NetFlow Services Export
               Version 9", RFC 3954, October 2004

 [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek, J.,
               "Architecture Model for IP Flow Information Export"
               draft-ietf-ipfix-architecture-12, September 2006

 [IPFIX-AS]   Zseby, T., Boschi, E., Brownlee, N., Claise, B., "IPFIX
               Applicability", draft-ietf-ipfix-as-12.txt, June 2007



 [PSAMP-FMWK] D. Chiou, B. Claise, N. Duffield, A. Greenberg, M.
               Grossglauser, P. Marimuthu, J. Rexford, G. Sadasivan,
               "A Framework for Passive Packet Measurement" draft-ietf-
               psamp-framework-12.txt

 [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F.
               Raspall, "Sampling and Filtering Techniques for IP
               Packet Selection" draft-ietf-psamp-sample-tech-10.txt

 [PSAMP-PROTO] B. Claise (Ed.), "Packet Sampling (PSAMP) Protocol
               Specifications", RFC XXXX. [Currently Internet Draft
               draft-ietf-psamp-protocol-09.txt, work in progress,
               December 2007].

 [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, "Information
               Model for Packet Sampling Exports", draft-ietf-psamp-
               info-08.txt

 [PSAMP-MIB]  Dietz, T., Claise, B. "Definitions of Managed Objects
               for Packet Sampling", Internet-Draft work in progress,
               June 2006





  Aitken, Claise            Standard Track                   [Page 24]


New Information Elements for the IPFIX Information Model    March 2008

10.     Security Considerations

   The IPFIX information model itself does not directly introduce
   security issues.  Rather, it defines a set of attributes that may for
   privacy or business issues be considered sensitive information.


11.     Contributors

      Ganesh Murthy
      Cisco Systems, Inc.
      3850 Zanker Road
      San Jose , CALIFORNIA 95134
      United States

      Phone: +1 408 853 7869
      EMail: gmurthy@cisco.com


      Marco Foschiano
      Cisco Systems, Inc.
      Torri Bianche-Faggio Bldg Lot H1
      Via Torri Bianche 7
      Vimercate 20059
      Italy

      Phone: +39 039 629 5244
      EMail: foschia@cisco.com



12.     Acknowledgements

   The editors would like to thank the following persons for their
   reviews of the information elements specifications: Andrew Johnson,
   Gennady Dosovitsky, George Serpa, Mike Tracy, Nagaraj Varadharajan,
   Senthil Sivakumar, Stan Yates, Stewart Bryant and Roland Dobbins. The
   contributors wish to thank the following individuals for discussions
   and feedback: Bob Klessig, Neil McGill, Samer Salam, Yibin Yang, Ravi
   Samprathi and Prasanna Rajah.


13.     Authors' Addresses

      Paul Aitken
      Cisco Systems, Inc.
      96 Commercial Quay
      Edinburgh EH6 6LX



  Aitken, Claise            Standard Track                   [Page 25]


New Information Elements for the IPFIX Information Model    March 2008

      Scotland

      Phone: +44 131 561 3616
      EMail: paitken@cisco.com


      Benoit Claise
      Cisco Systems, Inc.
      De Kleetlaan 6a b1
      Diegem 1831
      Belgium

      Phone: +32 2 704 5622
      EMail: bclaise@cisco.com



14.     Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the
   technology described in this document or the extent to which any
   license under such rights might or might not be available; nor
   does it represent that it has made any independent effort to
   identify any such rights.  Information on the procedures with
   respect to rights in RFC documents can be found in BCP 78 and
   BCP 79.
   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the
   use of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be
   required to implement this standard.  Please address the
   information to the IETF at ietf-ipr@ietf.org.


15.     Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and
   restrictions contained in BCP 78, and except as set forth
   therein, the authors retain all their rights.


  Aitken, Claise            Standard Track                   [Page 26]


New Information Elements for the IPFIX Information Model    March 2008



16.     Disclaimer

   This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
   THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
   ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
   ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.








































  Aitken, Claise            Standard Track                   [Page 27]


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