IPFIX working group EDITORS: K.C. Norseth Internet Draft Enterasys Networks draft-ietf-ipfix-data-00.txt Paul Calato Expires: August 2002 Riverstone Networks Inc IPFIX Data Model Data 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 an information and daqta model 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. Introduction 3 2. Scope 3 3. Terminology 3 4. Flow Type and Flow Definition 3 4.1. Observation Point 5 4.2. Unidirectional and Bidirectional Flows 5 5. Metering Process Function 6 5.1. Flow Classification 6 IPFIX Working Group Expires August 2002 [Page 1] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 5.2. Selection Criteria Of Packets 6 5.2.1. Function on properties that determines a flow type (Fi) 7 5.2.2. Sampling packets on a flow type (Si) 7 5.3. Selection Criteria of flows for export 7 5.4. Flow Expiration 7 6. Information Model 8 6.1. Attributes related to IP Packet Header 8 6.2. Attributes Related to Measurement 9 6.3. Attributes Related to Flow Definition 9 6.4. Attributes related to Upper Layers 9 7. Information Elements 9 7.1. IP Address 9 7.1.1. Source Address 9 7.1.2. Destination Address 10 7.1.3. NEXT_HOP_IP 10 7.2. Time Stamps 10 7.2.1. Flow Creation Time 10 7.2.2. Flow End Time 10 7.2.3. Flow Start UTC Time 11 7.2.4. Flow End UTC Time 11 7.2.5. Flow Update Start Time 11 7.2.6. Flow Update End Time 11 7.2.7. Flow Update Delta Time 11 7.3. Service Types 11 7.3.1. Class of Service 11 7.3.2. TCP Control Bits 12 7.3.3. Protocol Identifier 12 7.3.4. Source Exporter Address 12 7.4. Flow End State 13 7.5. Statistical Elements 13 7.5.1. Byte Count 13 7.5.2. Packet Count 13 7.5.3. Dropped Byte Count 14 7.5.4. Dropped Packet Count 14 7.5.5. IPM_DPKTS 14 7.5.6. IPM_DOCTETS 14 7.6. Port Information 14 7.6.1. Source Port 14 7.6.2. Destination Port 14 7.7. Autonomous System (AS) 15 7.7.1. Source AS 15 7.7.2. Destination AS 15 7.7.3. Next Hop AS 15 7.8. IfIndexes and Interfaces 15 7.8.1. Ingress Port 15 7.8.2. Egress Port 15 7.8.3. Egress ATM Subinterface 16 7.8.4. EGRESS_FRAME_RELAY_SUBINTERFACE 16 7.9. NetMasks 16 7.9.1. Source Address Netmask 16 7.9.2. Destination Address Netmask 16 7.10. BGP & Vlan 's 16 7.10.1. Destination BGP Community 16 7.10.2. Source BGP Community 17 IPFIX Working Group Expires August 2002 [Page 2] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 7.10.3. BGP_NEXT_HOP 17 7.10.4. Source VLAN ID 17 7.10.5. Destination VLAN ID 17 7.11. Virtual Information 17 7.11.1. Source Virtual Address 17 7.11.2. Source Virtual Port 18 7.11.3. Destination Virtual Address 18 7.11.4. Destination Virtual Port 18 7.12. Vendor Specific 19 7.13. Misc. Information Elements 19 7.13.1. Flow Label 19 7.13.2. Flow Direction 19 7.13.3. Fragment ID 19 7.13.4. Internal queue priority 19 7.13.5. Global VPN Identifier 20 7.13.6. ICMP_TYPE 20 7.13.7. IGMP_TYPE 20 7.14. Sampling 20 7.14.1. SAMPLING_INTERVAL 20 7.14.2. SAMPLING_ALGO 20 8. IANA Consideration 20 9. Security Section 20 10. References 21 11. Acknowledgements 22 12. Author's Addresses 23 13. Full Copyright Statement 24 14. To Add 24 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 the data, which may be used by the exporter for IP traffic flow monitoring an measuring. 2. Scope This document defines information data model for IPFIX[3]. Specifically, this document describes a general purpose flow definition along with the data elements which may be exported. 3. Terminology To be filled out 4. Flow Type and Flow Definition As defined in the requirement draft [1], "A flow is a set of packets passing an observation point in IPFIX Working Group Expires August 2002 [Page 3] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 the network during a certain time interval. All packets belonging to a particular flow have a set of common properties derived from the data contained in the packet and from the packet treatment at the observation point." In this draft we define the flow more specifically. A flow is defined as a set of packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: A. one or more of packet header fields (e.g. destination IP address) B. one or more properties of the packet itself (e.g. packet length) C. one or more of fields derived from packet treatment (e.g. AS number) A packet is defined to belong to a flow if it matches all the defined properties of the flow. Flows can be defined in multiple ways. Some examples are: Example 1: To create flows, we define the different fields to distinguish flows. The different combination of the field values creates unique flows. If the keys are defined as {source IP address, destination IP address, TOS}, then all of these are different flows. 1. {192.1.40.1, 171.6.23.5, 4} 2. {192.1.40.23, 171.6.23.67, 4} 3. {192.1.40.23, 171.6.23.67, 2} 4. {198.20.9.200, 171.6.23.67, 4} Example 2: To create flows, we can apply a match function to all the packets that pass through an observation point, in order to aggregate some values. This could be done by defining the keys as {source IP address, destination IP address, TOS} like in the example 1, and applying the function which masks the least significant 8 bits of the source IP address and destination IP address (i.e. the resultant is a /24 address). The 4 flows from example 1 would now be aggregated into 3 flows, by merging the flows 1. and 2. into a single flow. 1. {192.1.40.0/24, 171.6.23.0/24, 4} 2. {192.1.40.0/24, 171.6.23.0/24, 2} 3. {198.20.9.0/24, 171.6.23.0/24, 4} Example 3: IPFIX Working Group Expires August 2002 [Page 4] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 To create flows, we can filter some field values on all packets that pass the observation point, in order to select only certain flows. The filter is defined by choosing fixed values for specific fields from the packet. All the packets that go from a customer network 192.1.40.0/24 to another customer network 171.6.23.0/24 with TOS value of 4 define a flow. All other combinations don't define a flow and are not taken into account. The 3 flows from example 2 would now be reduced to 1 flow, by filtering away the second and the third flow. {192.1.40.0/24, 171.6.23.0/24, 4}. The above example can be thought of as a function F takes as input {source IP address, destination IP address, TOS}. The function selects only the packets which satisfy all the 3 conditions which are: * mask the least significant 8 bits of source IP address, compare against 192.1.40.0. * mask the least significant 8 bits of destination IP address, compare against 171.6.23.0. * tos value equal to 4. Depending on the values of {source IP address, destination IP address, TOS} of the different observed packets, the metering process function F would choose/filter/aggregate different sets of packets, which would create different flows. In other words, based on various combination of values of {source IP address, destination IP address, TOS}, F(source IP address, destination IP address, TOS) would result in the definition of one or more flows. The function F is referred to as Flow Type. 4.1. Observation Point For definition refer to section 1.2. A flow is uniquely defined by the way it gets measured at an observation point. Example: The flow defined in the example 1 of section 2., can be used at 2 different observation points 'a' and 'b' in 2 different ways. Observation point 'a' measures the packets that match the flow {192.1.40.0/8, 171.6.23.0/8, 4} at a sampling rate of 1 in 10 and 'b' measures packets that match the same flow with a sampling rate of 1 in 100. 4.2. Unidirectional and Bidirectional Flows A flow defined by the above terms is unidirectional. In case the exporter has got the knowledge of the bi-directional flows and in case the bi-directional information make sense, the exporter MAY choose to export in the same Template/Flow Record, along with IPFIX Working Group Expires August 2002 [Page 5] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 bidirectional accounting information. This would save some bandwidth as the exporter won't have to send two unidirectional flow records. Let {KF1,KF2.., KFn} define the set of fields consisting of at least one of : a. one or more of packet header fields b. one or more properties of the packet itself c. one or more of fields derived from packet treatment The corresponding flow is F(KF1,KF2.., KFn). If the flow has any characteristics which pertain to a direction w.r.t to the wire, then it is a uni-directional flow. Say forms a pair which defines the characteristic in a direction w.r.t wire. If defines the in the other direction w.r.t the wire, then Bi- directional flow can be defined as F(KF1,.. , ...KFn). Where "|" means "OR" and <> just delimits the internal set. 5. Metering Process Functions 5.1. Flow Classification The collector MUST be able to map the flow to the corresponding property types defined by the flow type. This can be done only if the collector has a mapping from flow type identifier (carried in each flow record) to its actual structure. More details of how this can be achieved are described in section 5.??? In addition the collector, when it receives the flow records, MAY need the following interpreting the flow records further: A. Observation Point. B. Selection Criteria of Packets As mentioned in section 2.1, a flow record can be better analyzed if the Observation Point from which it is measured is known. As such it is recommended that the flow record carry the Observation Point information along with the flow records when exported. In cases where there is a single observation point or where the observation point information is not relevant, the exporter MAY choose not to add this to the flow records. 5.2. Selection Criteria Of Packets The measurement device MAY define rules so that only certain packets within a flow can be chosen for measurement at an IPFIX Working Group Expires August 2002 [Page 6] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 observation point. This MAY be done by one of the two types of methods defined below or a combination of them. A combination of each of these ways can be adopted to select the packets .i.e. one can define a set of methods {F1, S1, F2, S2, S3} executed in certain sequence at an observation point to collect flows of a particular type. 5.2.1. Function on properties that determines a flow type (Fi) Packets that satisfy a function on the fields defined by the packet header fields or fields obtained while doing the packet processing or the properties of the packet itself. Example: Mask/Match of the fields that define a filter. The filter may be defined as {Protocol == TCP, Destination Port between 80 and 120}. Multiple such filters could be used in any sequence to select packets. 5.2.2. Sampling packets on a flow type (Si) Packets that satisfy the sampling criteria for this flow type. Example: Sample every 100th packet that was received at an observation point and collect the flow information for a particular flow type. choosing all the packets is a special case where sampling rate is 1:1. 5.3. Selection Criteria of flows for export The measurement device MAY define additional rules so that only certain flows records are picked up for export. This MAY be done by either one of the two types of methods defined in 2.3.1 and 2.3.2 or a combination of them. Example: The flow records which meet the following selection criteria are only exported. 1 All flow records whose destination IP address matches {20.3.1.5}. 2 Every other (.i.e. sampling rate 1 in 2) flow record whose destination IP address matches {160.0.1.30}. IPFIX Working Group Expires August 2002 [Page 7] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 5.4. Flow Expiration A flow is considered to be inactive if no packets of this flow has been observed at the observation point for a given timeout interval. The flow can be exported under the following conditions: 1. If the exporter can deduce the end of a flow, the exporter SHOULD export the flow records when the end of the flow is detected. For example: flow generated by TCP type of traffic where the FIN or RST bits indicate the end of the flow 2. If the flow has been inactive for a certain period of time. This inactivity timeout SHOULD be configurable. For example: flow generated by UDP type of traffic. 3. For long aging flows, the exporter SHOULD export the flow records on regular basis, in order to: a. report the flow records periodic accounting information to the collector b. avoid counter wrapping This activity timeout SHOULD be configurable 4. If the exporter experiences resources constraints, a flow MAY be prematurely expired (example: memory) 6. Information Model The IPFIX information model is listed in the IPFIX requirement document. The information model consists of the 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. This section presents a rigorous definition and sufficient statistics for these attributes. 6.1. Attributes related to IP Packet Header The following attributes are obtained directly from IP packet header belonging to a flow: * IP Version Number * Source Address * Destination Address * Source Port (e.g. TCP port number) * Destination Port (e.g. TCP port number) * Protocol Type * TOS (for version 4) * Flow Label (for version 6) * DSCP (if DiffServ is supported) IPFIX Working Group Expires August 2002 [Page 8] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 6.2. Attributes Related to Measurement The following attributes relates to measurements and measuring methodology: * Packet Counter * Dropped Packet Counter * Byte Counter * Dropped Byte Counter * Timestamp of the First Packet Observed * Timestamp of the Last Packet Observed * Timeout Indication * Sampling Method * Sampling Parameters 6.3. Attributes Related to Flow Definition The following attributes relates to IP flow definitions. * Incoming Interface * Outgoing Interface * Packet Treatment * Unique ID of the Observation Point * Unique ID of the Measuring Device 6.4. Attributes related to Upper Layers The following attributes provides information of lower layer protocols. * MPLS Label (if MPLS is supported) 7. Information Elements All element descriptions contain the following information: Field Type: This is the type of element the field is. All values are defined in the TEXTUAL CONVENTIONS in the IETF rfcs. For example, a source address is defined as field defined IpAddress from SNMPv2- SMI (RFC 1443). [This needs to be filled in on all the fields] Size: The size of the Data FlowSet including FlowSet ID and the Length . 7.1.IP Address 7.1.1. Source Address IPFIX Working Group Expires August 2002 [Page 9] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 Source address taken from the packet header. Addresses can be of any type as described in RFC 1700 [note - we need a new reference here, 1700 has been obsoleted] [ Do we want to be even more specific and say "taken from the IP packet header" Is there a reason to report L2 addresses? ] Field Type: ### Size: ### 7.1.2. Destination Address Destination address taken from the packet header. Address is defined the same as for Source Address. Field Type: ### Size: ### 7.1.3. NEXT_HOP_IP Address of the next hop. address is defined the same as for Source Address . Field Type: ### Size: ### 7.2.Time Stamps [ Note - there are several concepts in the time section. We certainly can and will argue about whether there is unnecessary duplication or not. For now I just wanted to get the ideas down ] 7.2.1. Flow Creation Time The time at which the flow was created. The time is a SNMPv2 TimeStamp [1443]. Field Type: ### Size: ### 7.2.2. Flow End Time The time at which the flow was deleted. The time is a SNMPv2 TimeStamp [1443]. [ Do we need a reason code? e.g. inactivity, detected TCP FIN. ] IPFIX Working Group Expires August 2002 [Page 10] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 Field Type: ### Size: ### 7.2.3. Flow Start UTC Time 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. Field Type: ### Size: ### 7.2.4. Flow End UTC Time The time in seconds since 00:00:00 UTC, January 1, 1970 associated with the status/statistics observed or other events. [ Need to define what happens if more If both Time IE is present ] Field Type: ### Size: ### 7.2.5. Flow Update Start Time Defines the time at the start of the flow Update. The time is a SNMPv2 TimeStamp [1443]. Field Type: ### Size: ### 7.2.6. Flow Update End Time Defines the time at the end of the flow Update. The time is a SNMPv2 TimeStamp [1443]. Field Type: ### Size: ### 7.2.7. Flow Update Delta Time The time covered by the update (e.g. update end - update_start).The time is in 100ths of seconds. Field Type: ### Size: ### 7.3.Service Types 7.3.1. Class of Service The class of service associated with a flow. Class of Service Received Class of Service Transmitted IPFIX Working Group Expires August 2002 [Page 11] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 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???] Field Type: ### Size: ### 7.3.2.TCP Control Bits 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. [ Do we need another field with a more definitive meaning for 0?? ] Field Type: ### Size: ### 7.3.3.Protocol Identifier e.g. TCP/UDP [ need an RFC reference here. PAC] Field Type: ### Size: ### 7.3.4. Source Exporter [ is that the right term?? PAC] Address 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 ------ Collector ^ | SW2---------- | Flows coming from SW1 and SW2 through proxy P1 would look to the Collector [ is this the right term??? PAC] like the same Exporter connection. With the Source Exporter in the message the original Exporter address is maintained. [ Does this belong here or in the Arch doc? I think in the arch doc. ] IPFIX Working Group Expires August 2002 [Page 12] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 Field Type: ### Size: ### 7.4. Flow End State The reason the flow has ended. 1. Inactivity timeout 2. End of flow detected (e.g. TCP FIN) 3. Forced end ???? 4. Cache full Field Type: ### Size: ### 7.5.Statistical Elements To be expanded 7.5.1. Byte Count 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. Field Type: ### Size: ### 7.5.2. Packet Count 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. Field Type: ### Size: ### IPFIX Working Group Expires August 2002 [Page 13] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 7.5.3. Dropped Byte Count 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. Field Type: ### Size: ### 7.5.4. Dropped Packet Count 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. Field Type: ### Size: ### 7.5.5. IPM_DPKTS Packet count for IP Multicast Field Type: ### Size: ### 7.5.6. IPM_DOCTETS Octet (byte) count for IP Multicast Field Type: ### Size: ### 7.6.Port Information To be added 7.6.1. Source Port This information element is used to report UDP source port [see RFC 768] or TCP source port [see RFC 793] as taken from the IP header. Field Type: ### Size: ### IPFIX Working Group Expires August 2002 [Page 14] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 7.6.2. Destination Port This information element is used to report UDP destination port [see RFC 768] or TCP destination port [see RFC 793] as taken from the IP header. Field Type: ### Size: ### 7.7.Autonomous System (AS) To be added Field Type: ### Size: ### 7.7.1. Source AS 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): Field Type: ### Size: ### 7.7.2. Destination AS 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). Field Type: ### Size: ### 7.7.3.Next Hop AS The Autonomous System (AS) numbers for the next hop IP. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). Field Type: ### Size: ### 7.8.IfIndexes and Interfaces To be added 7.8.1. Ingress Port The ifIndex where the packets for the flow are being received. ifIndex is defined by RFC 2233. Field Type: ### Size: ### IPFIX Working Group Expires August 2002 [Page 15] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 7.8.2. Egress Port The ifIndex where the packets for the flow are exiting. ifIndex is defined by RFC 2233. [ Do multi-cast flow cause us to possible have more than one of these?? PAC ] Field Type: ### Size: ### 7.8.3. Egress ATM Subinterface The egress vpi/vci for the flow is provided in this Information element. vpi/vci id defined by the ATM Forum UNI 3.1 specification: Field Type: ### Size: ### 7.8.4. EGRESS_FRAME_RELAY_SUBINTERFACE The egress DLCI for the flow is provided in this Information element. ITU Q.922 defines the DLCI range. The frDlcmiState is defined in RFC 2115 and defines the specific values of the DLCI. Field Type: ### Size: ### 7.9.NetMasks 7.9.1. Source Address Netmask The number of bits in the CIDR netmask, as defined in RFC 1519, for the source address. Field Type: ### Size: ### 7.9.2. Destination Address Netmask The CIDR netmask, as defined in RFC 1519, for the destination address. Field Type: ### Size: ### 7.10.BGP & Vlan 's 7.10.1. Destination BGP Community The BGP community number for the destination address. BGP IPFIX Working Group Expires August 2002 [Page 16] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 community number is defined by RFC 1997: Field Type: ### Size: ### 7.10.2. Source BGP Community The BGP community number for the source address. Field Type: ### Size: ### 7.10.3. BGP_NEXT_HOP Next-hop router in the BGP domain Field Type: ### Size: ### 7.10.4. Source VLAN ID 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? ] Field Type: ### Size: ### 7.10.5. Destination VLAN ID 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?] Field Type: ### Size: ### 7.11.Virtual Information 7.11.1. Source Virtual Address An Exporter may be involved in redirecting flows. This information element captures information needed for proper accounting of redirected flows. The Source Virtual information element contains the source address of the flow as transmitted by the Exporter. It is generally different than the source address information element, which contains the address of the actual source of the message. IPFIX Working Group Expires August 2002 [Page 17] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 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. Field Type: ### Size: ### 7.11.2. Source Virtual Port A CCE may be involved in redirecting flows. This information element captures information needed for proper accounting of redirected flows. The Source Virtual port information element contains the source port of the flow as transmitted by the CCE. It may be different than the source port information element, 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 indicate 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 Field Type: ### Size: ### 7.11.3. Destination Virtual Address The Destination Virtual information element 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. Field Type: ### Size: ### 7.11.4. Destination Virtual Port The Destination Virtual port information element 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. Field Type: ### Size: ### IPFIX Working Group Expires August 2002 [Page 18] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 7.12. Vendor Specific Vendors may add their own information to the protocol. Information contained in this information element is vendor specific. OID and OID Value are defined by ITU X.680.X683 (1997) and are encoded as defined by ITU X.690.691(1997). This information element MUST not contain any information which cannot be safely ignored by the Exporter or Collector. If multiple Vendor Specific information element's with the same OID occur, then the vendor defines semantics of ordering. Field Type: ### Size: ### 7.13.Misc. Information Elements 7.13.1.Flow Label The Flow Label information element contains the IPV6 Flow Label information as defined by RFC 2460. Field Type: ### Size: ### 7.13.2. Flow Direction 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. Field Type: ### Size: ### 7.13.3. Fragment ID The fragment ID associated with the flow. RFC 791 and RFC 2460 define fragment ID. Field Type: ### Size: ### 7.13.4. Internal queue priority A switch may map several of its internal priority queues into a Premium, High, Medium or Low category. [ This section needs more] Field Type: ### Size: ### 7.13.5.Global VPN Identifier IPFIX Working Group Expires August 2002 [Page 19] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 The VPN identifier associated with the flow as defined in RFC 2685. Field Type: ### Size: ### 7.13.6. ICMP_TYPE ICMP Packet Type. This is reported as (ICMP Type * 256) + ICMP code [We need a spec reference.] Field Type: ### Size: ### 7.13.7. IGMP_TYPE IGMP Packet Type [We need a spec reference.] Field Type: ### Size: ### 7.14.Sampling 7.14.1. SAMPLING_INTERVAL When using Sampling, the rate at which packets is sampled. For example, a value of 100 indicates that one of every hundred packets is sampled. Field Type: ### Size: ### 7.14.2. SAMPLING_ALGO The type of algorithm used for sampling data. Currently, the only sampling algorithm defined is: 0x02 packet-sampling Field Type: ### Size: ### 8. IANA Consideration To be filled out. 9. Security Section To be filled out. IPFIX Working Group Expires August 2002 [Page 20] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 10. References 3. J. Quittek ,et al.," Requirements for IP Flow Information Export ", (work in progress) ,Internet Draft, Internet Engineering Task Force, , 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, , 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: IPFIX Working Group Expires August 2002 [Page 21] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 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, , January 2002. [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft , 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, [2] K.Zhang, et al., "Common Reliable Accounting for Network Element (CRANE)", , February 2002 [3] G. Sadasivan, et al., "Flow Export Architecture", , January 2002 [4] Carlson, James, "PPP Design, Implementation and Debugging", Second Edition . 11. 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 Benoit Claise IPFIX Working Group Expires August 2002 [Page 22] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 Ganesh Sadasivan Vamsi Valluri Ram Gopal Jc Martin Carter Bullard Juergen Quittek Reinaldo Penno Nevil Brownlee Simon Leinen 12. Author's Addresses Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Paul Calato Riverstone Networks, Inc. 5200 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 (603) 557-6913 Email: calato@riverstonenet.com Ganesh Sadasivan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1 (408) 527-0251 Email: gsadasiv@cisco.com Ram Gopal Nokia 5 Wayside Road, Burlington, MA 01803 Phone:+1 781 993 3685 Email: ram.gopal@nokia.com Man Li Nokia 5 Wayside Road, Burlington, MA 01803 Phone: +1 781 993 3923 Email: man.m.li@nokia.com K.C. Norseth Enterasys Networks 2691 S. Decker Lake Lane Salt Lake City, Utah 84119 IPFIX Working Group Expires August 2002 [Page 23] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 Phone: +1 801 887 9823 Email: knorseth@enterasys.com Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9-B1240 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com Juergen Quittek NEC Europe Ltd. Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Kevin Zhang XACCT Technologies, Inc. 2900 Lakeside Drive Santa Clara, CA 95054 Phone +1 301 992 4697 Email: kevin.zhang@xacct.com Tanja Zseby GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 Email: zseby@fokus.gmd.de 13. 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. 14. To Add We should have as example of how the flow packet works. A good IPFIX Working Group Expires August 2002 [Page 24] INTERNET-DRAFT draft-ietf-ipfix-data-00.txt Feb. 22, 2002 example is what a NetFlow v5 packet looks like with this data model. IPFIX Working Group Expires August 2002 [Page 25]