[ipfix-data] Data Doc

[[e-mail]]

KC, here are a bunch of edits. If you want,
send me the source and I'll take editor
responsibilties for it.

Paul

[e-mail] wrote:
> 
> IPFIX working group
> Internet Draft
> draft-ietf-ipfix-data-00.txt
> Expires: August 2002
> 
> Benoit Claise
> Cisco Systems
> P. Calato
> Riverstone Networks Inc
> Ram Gopal
> Man Li
> Nokia
> K.C. Norseth
> Enterasys Networks
> Reinaldo Penno
> NortelNetworks
> J. Quittek
> NEC Europe Ltd.
> Ganesh Sadasivan
> Cisco Systems, Inc.Kevin Zhang
> XACCT Technologies
> Tanja Zseby
> FhI FOKUS
> 
> February 2002
> 
> IPFIX Architecture
> Architecture Model for IP Flow Information Export
> draft-ietf-ipfix-data-00.txt
> 
> Status of this Memo
> 
> This document is an Internet-Draft and is in full conformance with all
> provisions of Section 10 of RFC2026 [1].
> 
> 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.
> 
> Abstract
> 
> This document defines architecture for scalable monitoring, measuring
> and exporting IP flow information to collectors.
> 
> 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 [1].
> 
> 1. Introduction 5
> 2. Scope        5
> 3. Terminology  5
> 4. Information Model    5
> 4.1. Attributes related to IP Packet Header     6
> 4.2. Attributes Related to Measurement  6
> 4.3. Attributes Related to Flow Definition      6
> 4.4. Attributes related to Upper Layers 6
> 4.5. IPFIX Template     7
> 4.5.1. Template Negotiation     7
> 5. Information Elements 7
> 5.1. Packet Management  7
> 5.1.1. Version Number   7
> 5.1.2. FLOWS    7
> 5.1.3. FLOW_LABEL       7
> 5.2. IP Address 7
> 5.2.1. Source Address IE        7
> 5.2.2. Destination Address IE   8
> 5.2.3. NEXT_HOP_IP IE   8
> 5.3. Time Stamps        8
> 5.3.1. Time IE  8
> 5.3.2. UTC Time IE      8
> 5.3.3. Delta Time IE    8
> 5.4. Service Types      8
> 5.4.1. Class of Service IE      8
> 5.4.2. TCP Control Bits IE      9
> 5.4.3. Protocol Identifier IE   9
> 5.4.4. Source Exporter [ is that the right term?? PAC] Address IE
> 9
> 5.5. Flow State IE      9
> 5.6. Statistical Elements       9
> 5.6.1. Byte Count IE    10
> 5.6.2. Packet Count IE  10
> 5.6.3. Dropped Byte Count IE    10
> 5.6.4. Dropped Packet Count IE  10
> 5.7. Port Information   11
> 5.7.1. Source Port IE   11
> 5.7.2. Destination Port IE      11
> 5.8. Autonomous System (AS)     11
> 5.8.1. Source AS IE     11
> 5.8.2. Destination AS IE        11
> 5.8.3. Next Hop AS IE   11
> 5.9. IfIndexes and Interfaces   11
> 5.9.1. Ingress Port IE  11
> 5.9.2. Egress Port IE   11
> 5.9.3. Egress ATM Subinterface  12
> 5.9.4. EGRESS_FRAME_RELAY_SUBINTERFACE IE       12
> 5.10. NetMasks  12
> 5.10.1. Source Address Netmask IE       12
> 5.10.2. Destination Address Netmask IE  12
> 5.11. BGP & Vlan IE's   12
> 5.11.1. Destination BGP Community IE    12
> 5.11.2. Source BGP Community IE 12
> 5.11.3. BGP_NEXT_HOP    12
> 5.11.4. Source VLAN ID IE       12
> 5.11.5. Destination VLAN ID IE  13
> 5.11.6. Source Virtual Address IE       13
> 5.11.7. Source Virtual Port IE  13
> 5.11.8. Destination Virtual Address IE  14
> 5.11.9. Destination Virtual Port IE     14
> 5.12. NAT       14
> 5.12.1. INSIDE_L4_SRC   14
> 5.12.2. INSIDE_IPV4_SRC_ADDR    14
> 5.12.3. INSIDE_L4_DST_PORT      14
> 5.12.4. INSIDE_IPV4_DST_ADDR    14
> 5.12.5. INSIDE_IPV6_SRC_ADDR    14
> 5.12.6. INSIDE_IPV6_DST_ADDR    14
> 5.12.7. OUTSIDE_L4_SRC_PORT     14
> 5.12.8. OUTSIDE_IPV4_SRC_ADDR   15
> 5.12.9. OUTSIDE_L4_DST_PORT     15
> 5.12.10. OUTSIDE_IPV4_DST_ADDR  15
> 5.12.11. OUTSIDE_IPV6_SRC_ADDR  15
> 5.12.12. OUTSIDE_IPV6_DST_ADDR  15
> 5.13. Vendor Specific IE        15
> 5.14. Misc. Information Elements        15
> 5.14.1. Flow Label IE   15
> 5.14.2. Flow Direction  15
> 5.14.3. Fragment ID IE  16
> 5.14.4. Internal queue priority 16
> 5.14.5. Global VPN Identifier IE        16
> 5.14.6. IPM_DPKTS       16
> 5.14.7. IPM_DOCTETS     16
> 5.14.8. LAST_SWITCHED   16
> 5.14.9. FIRST_SWITCHED  16
> 5.14.10. MAC_ADDR       16
> 5.14.11. VLAN_ID        16
> 5.14.12. ICMP_TYPE      16
> 5.14.13. IGMP_TYPE      16
> 5.15. Sampling  17
> 5.15.1. SAMPLING_INTERVAL       17
> 5.15.2. SAMPLING_ALGO   17
> 5.15.3. FLOW_ACTIVE_TIMEOUT     17
> 5.15.4. FLOW_INACTIVE_TIMEOUT   17
> 6. References   17
> 7. Acknowledgements     19
> 8. Author's Addresses   20
> 9. Full Copyright Statement     21
> 10. Stuff to Add        21
> 11. End of stuff to add 21
> 
> 1. Introduction
> 
> Many applications e.g., Intrusion detection, traffic engineering,
> require the monitoring, measuring of IP traffic flows. It is hence
> important to have a standard way of exporting information related to IP
> flows. This document defines architecture for IP traffic flow
> monitoring, measuring and exporting. It provides a high-level
> description of the key components and their functions.
> 
> 2. Scope
> 
> This document defines information data model for IPFIX[3]. Specifically,
> this document
> 
> 3. Terminology
> MOVED to the Requirements draft
> 
> 4. Information Model
> 

Delete Start
============

> I think we need to begin with a couple of guidlines (which
> we should augment as we go). They are just guidelines.
> 
> 1. Data element values should be defined in terms of other
> specifications. Since we are only reporting things in other protocols,
> there should be little reason for us to define anything from scatch.
> 
> 2. Each element should be able to be interpreted on it own. In other
> words, don't make me look though the rest of the message to figure out
> what this value means. The drawback is this can lead to data element
> explosion. We'll have to balance the tradeoffs.
> 
> 3. Others?

Delete End
===========

	Those were just my comments. I don't think they belong
	in the document.

> 
> The IPFIX information model is listed in the IPFIX requirement
> document.  The information model consists of the minimum set of
> attributes that an IPFIX exporting device should be able to export. In
> conjunction with IP flow definitions, they provide locally accurate
> information about a flow.

	I do not think it is the minimum set. It is the full
	set to this point in time. We need to define the full
	set in order to get interoperabiltity. Vendors defining
	their own fields should be the exception rather than the
	rule.

> 
> To meet application's requirement may require the collection device to
> obtain additional information about the flow, e.g. address translation,
> user identification, etc. Additional flow information may also be
> required; in this case, equipment vendors may define extensions to the
> IPFIX information model.  Any extension to the IPFIX information model
> should be conveyed between end points.
> 
> This section presents a rigorous definition and sufficient statistics
> for these attributes.
> 
> 4.1.  Attributes related to IP Packet Header
> 
> The following attributes are obtained directly from IP packet header
> belonging to a flow:
> o IP Version Number
> o Source Address
> o Destination Address
> o Protocol Type
> o TOS (for version 4)
> o Flow Label (for version 6)
> o DSCP (if DiffServ is supported)
> 
> 4.2.  Attributes Related to Measurement
> 
> The following attributes relates to measurements and measuring
> methodology:
> o Packet Counter
> o Dropped Packet Counter
> o Payload Byte Counter
	
	What is this??

> o Timestamp of the First Packet Observed
> o Timestamp of the Last Packet Observed
> o Timeout Indication
> o Sampling Method
> o Sampling Parameters
> 
> 4.3.  Attributes Related to Flow Definition
> 
> The following attributes relates to IP flow definitions.
> 
> o Incoming Interface
> o Outgoing Interface
> o Packet Treatment
> o Unique ID of the Observation Point
> o Unique ID of the Measuring Device
> 
> 4.4.  Attributes related to Upper Layers
> 
> The following attributes provides information of upper layer protocols.
> o Source Port Address
> o MPLS Label (if MPLS is supported)

	Just a nit but MPLS is actaually a lower layer.


	Where are derived things like AS number?

> 
> 4.5. IPFIX Template
> 
> The IPFIX system MUST support efficient exporting of IP flow
> information.  This can be achieved by negotiating a set of IPFIX
> Templates for an IPFIX session before actual IP flow information is
> exported. A template defines the structure of an IPFIX user message
> payload by describing the data type, meaning, and location of the fields
> in the payload. By agreeing on IPFIX templates, IPFIX end-points
> understand how to process IPFIX user messages. As a result, an exporting
> device only needs to export actual flow information without attaching
> any descriptors of the attributes; this reduces the amount of bytes sent
> over communication links.
> 
> A template is an ordered list of keys. A key specifies an attribute that
> a meter entity MAY export. The specification MUST consist of the
> description and the data type of the attribute. (e.g. 'Number of Sent
> Bytes'  can be a key that is an 32 bit unsigned integer) An exporting
> device typically defines keys. Based on the IPFIX information model, a
> set of IPFIX standard keys can be defined.
> 
> 4.5.1.  Template Negotiation
> 
> During the initial setup of an IPFIX session, template negotiation
> procedures should be carried out.  It would allow all the IPFIX
> end-points to synchronize on a set of templates that will be used during
> IP flow information export.


	I assume a lot more discussion needs to happen here. 

> 
> 5. Information Elements
> 5.1. Packet Management
> 
> This information contains the fields needed to manage the data packets
> transmitted
> 
> 5.1.1. Version Number
> 
> [Need to expand more]

	If this is IPFIX protocol version, it does not
	belong here.

> 
> 5.1.2. FLOWS
>                         V#3      S#4
> Number of main cache flows

	What is this???

> 
> 5.1.3.    FLOW_LABEL
>                    V#31      S#2
> IPV6 Flow Label
> [Need to expand more]
> 

	Delete, already covered below in more detail.

> 5.2.  IP Address
> 
> 5.2.1.  Source Address IE
> 
> Source address associated with a flow. Addresses can be of any type as
> described in RFC 1700 [note - we need a new reference here, 1700 has
> been obsoleted]
> 
> 5.2.2.  Destination Address IE
> 
> Destination address associated with a flow. same as above.
> 
> 5.2.3.  NEXT_HOP_IP IE
> 
> Address of the next hop. address is defined the same as for Source
> Address IE.
> 
> 5.3. Time Stamps
> 
> 5.3.1.  Time IE
> 
> The time (as a SNMPv2 TimeStamp [1443]) associated with the
> status/statistics observed or other events.
> 
> 5.3.2.  UTC Time IE
> 
> The time in seconds since 00:00:00 UTC, January 1, 1970 associated with
> the status/statistics observed or other events. If both Time and
> UTC_TIME are present, UTC Time takes precedence.
> 
> 5.3.3.  Delta Time IE
> 
> The number in 100ths of seconds over which the statistics were observed.
> TYPE is 71 and format is:
> 
> 5.4. Service Types
> 
> 5.4.1.  Class of Service IE
> 
> The class of service associated with a flow.
> 
> Class of Service Received
> Class of Service Transmitted
> 
> 1. IPv4, CoS value is defined by ToS in RFC 791
> 2. IPv6, CoS value is defined by Traffic Class in RFC 2460
> 3. MPLS, CoS value is defined by Exp in RFC 3032
> 4. VLAN, CoS value is defined by user_priority in IEEE802.1q[802.1q] and
> IEEE 802.1p[802.1p]
> 
>    [Can more than one Class of Service can be present??? PAC]
> 
> 
> 5.4.2. TCP Control Bits IE
> 
> The TCP control bits seen for this flow. Note a 0 value for each bit
> only indicates that the flag was not detected (i.e. it may have occurred
> but was not detected by the reporting CCE). TCP Control Bits are defined
> by RFC 793.
> 
> 5.4.3. Protocol Identifier IE
> 
>  e.g. TCP/UDP [ need an RFC reference here. PAC]
> 
> 5.4.4.  Source Exporter [ is that the right term?? PAC] Address IE
> 
> Source Exporter address is the address of the Exporter reporting the
> flow, Address is same as is as shown for Source Address. This
> information is used by applications to later correlate the
> ingress/egress port with a specific Exporter. It is also used to
> maintain the source Exporter information when there is an intermediate
> proxy. For example, given the picture below:
> 
>             SW1 --------    P1 ------ FAS1
>                             ^
>                             |
>             SW2----------   |
> 
> Flows coming from SW1 and SW2 through proxy P1 would look to the
> Collector [ is this the rigth term??? PAC]  like the same Exporter
> connection. With the Source Exporter in the message the original
> Exporter  address is maintained.
> 
> 5.5.  Flow State IE
> 
> Flow State is the intended End State for the Flow.
> 
> Flow state has one of the following meanings:
> 
>          Flow is inactive
>          Flow is active
> 
> 5.6. Statistical Elements
> 
> To be added
> 
> 5.6.1.  Byte Count IE
> 
> Contains the count of octets sent and received associated with the
> identified flow.
> 
> The byte count can be for bytes received (towards source) or  bytes sent
> (towards destination) or both (bi-directional flow).
> 
> The byte count can be a running counter and is the count from the
> beginning of the flow establishment.
> 
> The byte count can be a delta counter and is the count since the last
> report for this flow.
> 
> 5.6.2.  Packet Count IE
> 
> Contains the count of packets sent and received associated with the
> identified flow.
> 
> The packet count can be for packets received (towards source) or packets
> sent (towards destination) or both (bi-directional flow).
> 
> The packet count can be a running counter and is the count from the
> beginning of the flow establishment.
> 
> The packet count can be a delta counter and is the count since the last
> report for this flow.
> 
> 5.6.3.  Dropped Byte Count IE
> 
> Contains the count of octets dropped at the observation point associated
> with the identified flow.
> 
> The dropped byte count can be a running counter and is the count from
> the beginning of the flow establishment.
> 
> The byte count can be a delta counter and is the count since the last
> report for this flow.
> 
> 5.6.4.  Dropped Packet Count IE
> 
> Contains the count of packets dropped at the observation point
> associated with the identified flow.
> 
> The dropped packet count can be a running counter and is the count from
> the beginning of the flow establishment.
> 
> The dropped packet count can be a delta counter and is the count since
> the last report for this flow.
> 
> 5.7. Port Information
> 
> To be added
> 
> 5.7.1.  Source Port IE
> 
> This IE is used to report  UDP source port [see RFC 768] or TCP source
> port [see RFC 793].
> 
> 5.7.2.  Destination Port IE
> 
> This IE is used to report  UDP destination port [see RFC 768] or TCP
> destination port [see RFC 793].
> 
> 5.8. Autonomous System (AS)
> 
> To be added
> 
> 5.8.1.  Source AS IE
> 
> The Autonomous System (AS) numbers for the source address associated
> with a flow. Autonomous System (AS) number is defined by RFC 1930 and
> RFC 1771 (BGP-4):
> 
> 5.8.2.  Destination AS IE
> 
> The Autonomous System (AS) numbers for the destination address
> associated wit a flow. Autonomous System (AS) number is defined by RFC
> 1930 and RFC 1771 (BGP-4).
> 
> 5.8.3. Next Hop AS IE
> 
> The Autonomous System (AS) numbers for the next hop IP. Autonomous
> System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4).
> 
> 5.9. IfIndexes and Interfaces
> 
> To be added
> 
> 5.9.1.  Ingress Port IE
> 
> The ingress ifIndex for the flow is provided in this IE. ifIndex is
> defined by RFC 2233.
> 
> 5.9.2.  Egress Port IE
> 
> The egress ifIndex for the flow is provided in this IE. ifIndex is
> defined by RFC 2233.
> 
> 5.9.3.  Egress ATM Subinterface
> 
> The egress vpi/vci for the flow is provided in this IE. vpi/vci id
> defined by the ATM Forum UNI 3.1 specification:
> 
> 5.9.4.  EGRESS_FRAME_RELAY_SUBINTERFACE IE
> 
> The egress DLCI for the flow is provided in this IE. ITU Q.922 defines
> the DLCI range. The frDlcmiState is defined in RFC 2115 and defines the
> specific values of the DLCI.
> 
> 5.10. NetMasks
> 5.10.1.  Source Address Netmask IE
> 
> The number of bits in the CIDR netmask, as defined in RFC 1519, for the
> source address.
> 
> 5.10.2.  Destination Address Netmask IE
> 
> The CIDR netmask, as defined in RFC 1519, for the destination address.
> 
> 5.11. BGP & Vlan IE's
> 
> 5.11.1.  Destination BGP Community IE
> 
> The BGP community number for the destination address. BGP community
> number is defined by RFC 1997:
> 
> 5.11.2.  Source BGP Community IE
> 
> The BGP community number for the source address.
> 
> 5.11.3.    BGP_NEXT_HOP
>                  V#18      S#4
> Next-hop router in the BGP
>                                               domain
> 
> 5.11.4.  Source VLAN ID IE
> 
> The Source VLAN ID associated with the flow. VLAN ID is defined by IEEE
> standard 802.1q - 1998[802.1q].
> 
> [ Is this ultimate source VLAN or the source vlan of the port where the
> packet came in? Or do we need a way to represent both? PAC]
> 
> 5.11.5.  Destination VLAN ID IE
> 
> The destination VLAN ID associated with the flow. VLAN ID is defined by
> IEEE standard 802.1q - 1998[802.1q].
> 
> [ Is this ultimate destination VLAN or the destination vlan of the port
> where the packet went out? Or do we need a way to represent both? PAC]
> 
> 1.1. Virtual Information
> 
> 5.11.6.  Source Virtual Address IE
> 
> An Exporter may be involved in redirecting flows. This IE captures
> information needed for proper accounting of redirected flows. The Source
> Virtual IE contains the source address of the flow as transmitted by the
> Exporter. It is generally different than the source address IE, which
> contains the address of the actual source of the message.
> 
> A type field would contain the type of translation performed on the
> source address. The following types are currently available:
> 1. - NAT
> 2. - LSNAT
> 3. - Web Cache
> 
> The address is defined the same as for Source Address.
> 
> 5.11.7.  Source Virtual Port IE
> 
> A CCE may be involved in redirecting flows. This IE captures information
> needed for proper accounting of redirected flows. The Source Virtual
> port IE contains the source port of the flow as transmitted by the CCE.
> It may be different than the source port IE, which contains the port of
> the actual source of the flow.  An IP Protocol field is present and is
> defined by the IP protocol spec [RFC 791] (e.g. TCP/UDP). The fields
> indicates how to interpret the port value field.
> 
> A type field contains the type of translation performed on the source
> port. The following types are currently available:
> 
> 1. - NAT
> 2. - LSNAT
> 3. - Web Cache
> 
> 5.11.8.  Destination Virtual Address IE
> 
> The Destination Virtual IE contains the destination address of the flow
> as received by the Exporter. It is generally different than the
> destination port number, which contains the actual destination address
> of the flow.
> 
> 5.11.9.  Destination Virtual Port IE
> 
> The Destination Virtual port IE contains the destination port of the
> flow as received by the Exporter. It may be different than the
> destination port recorded in the destination port, which contains the
> actual destination port of the flow.
> 


Start delete
============

> 5.12. NAT
> 5.12.1.    INSIDE_L4_SRC
>                 V#42      S#2
> 
> NAT port number (.e.g, FTP, Telnet, etc...) only applicable with NAT
> 
> 5.12.2.    INSIDE_IPV4_SRC_ADDR
>          V#43      S#4
> Source IPv4 Address only applicable with NAT TCP/UDP destination port
> 
> 5.12.3.    INSIDE_L4_DST_PORT
>            V#44      S#2
> The number (.e.g, FTP, telnet etc...) only applicable with NAT
> 
> 5.12.4.    INSIDE_IPV4_DST_ADDR
>          V#45      S#4
> Destination IPv4 Address only applicable with NAT
> 
> 5.12.5.    INSIDE_IPV6_SRC_ADDR
>          V#46      S#16
> IPv6 Source Address only applicable with NAT
> 
> 5.12.6.    INSIDE_IPV6_DST_ADDR
>          V#47      #16
> IPv6 Destination Address only applicable with NAT
> 
> 5.12.7.    OUTSIDE_L4_SRC_PORT
>           V#48       S#2
> TCP/UDP destination port number (.e.g, FTP, Telnet, etc...) only
> applicable with NAT
> 
> 5.12.8.    OUTSIDE_IPV4_SRC_ADDR
>         V#49       S#4
> Source IPv4 Address only applicable with NAT TCP/UDP destination port
> 
> 5.12.9.    OUTSIDE_L4_DST_PORT
>           V#50       S#2
> number (.e.g, FTP, Telnet, etc...) only applicable with NAT
> 
> 5.12.10.    OUTSIDE_IPV4_DST_ADDR
>         V#51       S#4
> Destination IPv4 Address only applicable with NAT
> 
> 5.12.11.    OUTSIDE_IPV6_SRC_ADDR
>         V#52       S#16
> IPv6 Source Address only applicable with NAT
> 
> 5.12.12.    OUTSIDE_IPV6_DST_ADDR
>         V#53       S#16
> IPv6 Destination Address only applicable with NAT
> 


Delete ENd
==========

	Already covered above in more detail above.
	Even if we disagree on the exact text, this 
	stuyff is duplicate.



> 5.13.  Vendor Specific IE
> 
> Vendors may add their own information to the protocol. Information
> contained in this IE is vendor specific. OID and OID Value is defined by
> ITU X.680.X683 (1997) and is encoded as defined by ITU X.690.691(1997).
> This IE MUST not contain any information which cannot be safely ignored
> by the Exporter or Collector. If multiple Vendor Specific IE's with the
> same OID occur, then the vendor defines semantics of ordering.
> 
> 5.14. Misc. Information Elements
> 
> To be added
> 
> 5.14.1. Flow Label IE
> 
> The Flow Label IE contains the IPV6 Flow Label information as defined by
> RFC 2460.
> 5.14.2.    Flow Direction
>                V#54       S#1
> The direction of the flow observed at the observation point. If the
> observation point is a set of interface(s) the direction is w.r.t the
> wire.
> 
> 5.14.3.  Fragment ID IE
> 
> The fragment ID associated with the flow. RFC 791 and RFC 2460 define
> fragment ID.
> 
> 5.14.4.  Internal queue priority
> 
> A switch may map several of its internal priority queues into a Premium,
> High, Medium or Low category.
> 
> [ this sections needs more work]
> 
> 5.14.5. Global VPN Identifier IE
> 
> The VPN identifier associated with the flow as defined in RFC 2685.
> 
> 5.14.6.    IPM_DPKTS
>                     V#19      S#4
> Packet count for IP Multicast
> 
> 5.14.7.    IPM_DOCTETS
>                   V#20      S#4
>      Octet (byte) count for IP Multicast

	IPM_DPKTS and IPM_DOCTETS should be moved to where
	the other counts are.
	

> 
> 5.14.8.    LAST_SWITCHED
>                 V#21      S#4
> SysUptime at which the last packet of this flow was switched
> 
> 5.14.9.    FIRST_SWITCHED
>                V#22      S#4
> SysUptime at which the first packet of this flow was switched
> [Need to expand more]
> 

	Move these with the other timestamp info, 
	I'll work on combining.

> 5.14.10.    MAC_ADDR
>                      V#25      S#6
> Layer 2 Media Access Control address associated with a flow
> 

	Delete. Already covered under the address stuff.


> 5.14.11.    VLAN_ID
>                       V#26      S#2
> Virtual LAN identifier associated with a flow

	Delete. already covered in more detail.

> 
> 5.14.12.    ICMP_TYPE
>                     V#32      S#1
> ICMP Packet Type. This is reported as (ICMP Type * 256) + ICMP code


	We need a spec reference.

> 
> 5.14.13.    IGMP_TYPE
>                     V#33      S#1
> IGMP Packet Type


	we need a spec reference.
> 
> 5.15. Sampling
> 
> 5.15.1.    SAMPLING_INTERVAL
>             V#34      S#1
> When using Sampling, the rate at which packets are sampled. For
> example, a value of 100 indicates that one of every hundred packets is
> sampled.
> 
> 5.15.2.    SAMPLING_ALGO
>                 V#35      S#1
> The type of algorithm used for sampling
> data.                                              Currently, the only
> sampling algorithm defined  is:
> 0x02 packet-sampling
> 
> 5.15.3.    FLOW_ACTIVE_TIMEOUT
>           V#36      S#2
> Timeout value for active flow entries in the cache.
> 
> 5.15.4.    FLOW_INACTIVE_TIMEOUT
>         V#37      S#2
> Timeout value for inactive flow entries in the cache.
> 
> 6. References
> 
> 3. J. Quittek ,et al.," Requirements for IP Flow Information Export ",
> (work in progress) ,Internet Draft, Internet Engineering Task Force,
> <draft-ietf-ipfix-reqs-00.txt>, November 2001
> 
> 4. M. Wood ,et al.," Intrusion Detection Message Exchange
> Requirements",(work in progress), Internet Draft, Internet Engineering
> Task Force, draft-ietf-idwg-requirements-06,February 2002.
> 
> 5. Daniel O. Awduche, et. al.," Overview and Principles of Internet
> Traffic Engineering", (work in progress), Internet Draft, Internet
> Engineering Task Force, draft-ietf-tewg-principles-02.txt, May 2002
> 
> [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions,
> http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-adelaide/pp-dist/
> 
> [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric for
> IPPM,
> <draft-ietf-ippm-ipdv-08.txt>, November   2001
> 
> [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss
> Metric for
> IPPM, September 1999
> 
> [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application
> of Sampling
> Methodologies to Network Traffic Characterization, Proceedings of ACM
> SIGCOMM'93,
> San Francisco, CA, USA,  September 13 - 17, 1993
> 
> [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS,
> John G. CLEARY:
> Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay
> Variation on
> the Internet, INET'98, Geneva, Switzerland,  21-24 July, 1998
> 
> [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for
> Direct Traffic
> Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August
> 28 -
> September 1, 2000.
> 
> [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric
> for IPPM,
> Request for Comments: 2679, September 1999
> 
> [ZsZC01]        Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation
> of Building Blocks
> for Passive One-way-delay Measurements, Proceedings of Passive and
> Active Measurement
> Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 (PAM
> 2001)
> 
> [MCFW] Srisuresh, S. et al.  "Middlebox Communication Architecture and
> framework," work in progress.  October 2001.
> 
> [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
> (NAT) Terminology and Considerations", RFC 2663, August 1999.
> 
> [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
> Address Translator (Traditional NAT)", RFC 3022, January  2001.
> 
> [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider
> Provisioned Virtual Private Networks ", work in progress,
> <draft-ietf-ppvpn-framework-03.txt>, January 2002.
> 
> [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft
> <draft-ietf-ppvpn-l2vpn-00.txt>, July 2001.
> 
> [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W.
> Weiss, "An Architecture for Differentiated Services", RFC 2475, December
> 1998.
> 
> [1] Requirements for IP Flow Export, <draft-ietf-ipfx-req-00.txt>
> <http://www.ietf.org/html.charters/ipfix-charter.html>
> 
> [2] K.Zhang, et al., "Common Reliable Accounting for Network Element
> (CRANE)", <draft-kzhang-crane-protocol-02.txt>, February 2002
> 
> [3] G. Sadasivan, et al., "Flow Export Architecture",
> <draft-cisco-ipfix-arch-00.txt>, January 2002
> 
> [4] Carlson, James, "PPP Design, Implementation and Debugging", Second
> Edition .
> 
> 7. Acknowledgements
> We like to thank all the people contributing to the requirements
> discussion on the mailing list, and the design teams for a lot of
> valuable comments.
> 
> George Carle
> Tanja Zseby
> Paul Calato
> Dave Plonka
> Kevin Zhang
> KC Norseth
> Phill Richards
> Will Eatherton
> Benoit Claise
> Ganesh Sadasivan
> Vamsi Valluri
> Ram Gopal
> Jc Martin
> Carter Bullard
> Juergen Quittek
> Reinaldo Penno
> Nevil Brownlee
> Simon Leinen
> 
> 8. Author's Addresses
> 
> Benoit Claise
> Cisco Systems
> De Kleetlaan 6a b1
> 1831 Diegem
> Belgium
> Phone: [phone]
> Email: [e-mail]
> 
> Paul Calato
> Riverstone Networks, Inc.
> 5200 Great America Parkway
> Santa Clara, CA 95054  USA
> Phone:  [phone]
> Email:  [e-mail]
> 
> Ganesh Sadasivan
> Cisco Systems, Inc.
> 170 W. Tasman Dr.
> San Jose, CA 95134
> USA
> Phone:  [phone]
> Email:  [e-mail]
> 
> Ram Gopal
> Nokia
> 5 Wayside Road,
> Burlington, MA 01803
> Phone:[phone]
> Email: [e-mail]
> 
> Man Li
> Nokia
> 5 Wayside Road,
> Burlington, MA 01803
> Phone: [phone]
> Email: [e-mail]
> 
> K.C. Norseth
> Enterasys Networks
> 2691 S. Decker Lake Lane
> Salt Lake City, Utah 84119
> Phone: [phone]
> Email: [e-mail]
> 
> Reinaldo Penno
> Nortel Networks, Inc.
> 2305 Mission College Boulevard
> Building SC9-B1240
> Santa Clara, CA 95134
> Email: [e-mail]
> 
> Juergen Quittek
> NEC Europe Ltd.
> Adenauerplatz 6
> 69115 Heidelberg
> Germany
> Phone: [phone]
> EMail: [e-mail]
> 
> Kevin Zhang
> XACCT Technologies, Inc.
> 2900 Lakeside Drive
> Santa Clara, CA 95054
> Phone [phone]
> Email: [e-mail]
> 
> Tanja Zseby
> GMD FOKUS
> Kaiserin-Augusta-Allee 31
> 10589 Berlin, Germany
> Phone: [phone]
> Email: [e-mail]
> 
> 9. Full Copyright Statement
> 
> "Copyright (C) The Internet Society (date). All Rights Reserved. This
> document and translations of it may be copied and furnished to others,
> and derivative works that comment on or otherwise explain it or assist
> in its implementation may be prepared, copied, published and
> distributed, in whole or in part, without restriction of any kind,
> provided that the above copyright notice and this paragraph are included
> on all such copies and derivative works. However, this document itself
> may not be modified in any way, such as by removing the copyright notice
> or references to the Internet Society or other Internet organizations,
> except as needed for the purpose of developing Internet standards in
> which case the procedures for copyrights defined in the Internet
> Standards process must be followed, or as required to translate it into.
> 
> 10. Stuff to Add
> 11. End of stuff to add
> 
> 
>         IPFIX Information Data Model    February, 2002
> 
> 
> IPFIX WG         Expires August, 2002    [Page 4]
> 
> Gopal, Li,Zhang,Tanja   Expires July 2002       [Page 1]

--
Help        mailto:[e-mail] and say "help" in message body
Unsubscribe mailto:[e-mail] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/