Internet DRAFT - draft-aitken-ipfix-new-infos
draft-aitken-ipfix-new-infos
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]
