idnits 2.17.1 draft-aitken-ipfix-new-infos-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1180. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1180. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1186. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 17, 2008) is 5877 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1ad.2005' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1Q.2003' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-3.2005' == Outdated reference: A later version (-13) exists of draft-ietf-psamp-framework-12 == Outdated reference: A later version (-11) exists of draft-ietf-psamp-sample-tech-10 == Outdated reference: A later version (-11) exists of draft-ietf-psamp-info-08 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX working group Editor P. Aitken 3 Internet Draft Editor B. Claise 4 draft-aitken-ipfix-new-infos-03 Cisco Systems, Inc. 5 Intended Status: Proposed Standard March 17, 2008 6 Expires: September 17, 2008 8 New Information Elements from the IPFIX Information Model 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed 32 at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 3rd, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document specifies the IPFIX protocol that serves for 44 transmitting IP traffic flow information over the network. In order 45 to transmit IP traffic flow information from an exporting process to 46 an information collecting process, a common representation of flow 47 data and a standard means of communicating them is required. This 48 document describes how the IPFIX data and templates records are 49 carried over a number of transport protocols from an IPFIX exporting 50 process to an IPFIX collecting process. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Introduction.................................................3 61 2. Terminology..................................................3 62 2.1 IPFIX Documents Overview...................................4 63 2.2 PSAMP Documents Overview...................................4 64 3. Information Element Identifiers..............................4 65 4. New Information Elements in the range 1-127..................6 66 4.1 interfaceName..............................................6 67 4.2 interfaceDescription.......................................7 68 4.3 forwardingStatus...........................................7 69 4.4 mplsTopLabelPrefixLength...................................9 70 4.5 postIpDiffServCodePoint...................................10 71 4.6 multicastReplicationFactor................................10 72 5. New Information Elements in the range 128-32767.............10 73 5.1 postNATSourceIPv4Address..................................10 74 5.2 postNATDestinationIPv4Address.............................11 75 5.3 postNAPTSourceTransportPort...............................11 76 5.4 postNAPTDestinationTransportPort..........................12 77 5.5 natOriginatingAddressRealm................................12 78 5.6 natEvent..................................................12 79 5.7 initiatorOctets...........................................13 80 5.8 responderOctets...........................................13 81 5.9 firewallEvent.............................................13 82 5.10 ingressVRFID.............................................14 83 5.11 egressVRFID..............................................14 84 5.12 VRFname..................................................14 85 5.13 ethernetHeaderLength.....................................14 86 5.14 ethernetPayloadLength....................................15 87 5.15 ethernetTotalLength......................................15 88 5.16 dot1qVlanId..............................................15 89 5.17 dot1qPriority............................................16 90 5.18 dot1qCustomerVlanId......................................16 91 5.19 dot1qCustomerPriority....................................16 92 5.20 metroEvcId...............................................17 93 5.21 metroEvcType.............................................17 94 5.22 pseudoWireId.............................................17 95 5.23 pseudoWireType...........................................18 96 5.24 pseudoWireControlWord....................................18 97 5.25 ingressPhysicalInterface.................................18 98 5.26 egressPhysicalInterface..................................18 99 5.27 postDot1qVlanId..........................................19 100 5.28 postDot1qCustomerVlanId..................................19 101 5.29 ethernetType.............................................19 102 5.30 selectorName.............................................20 103 6. Relationship between dot1qVlanId and vlanId.................20 104 7. Relationship between interface related Information Elements.21 105 8. IANA Considerations.........................................21 106 9. References..................................................22 107 9.1 Normative References......................................22 108 9.2 Informative References....................................23 109 10. Security Considerations....................................25 110 11. Contributors...............................................25 111 12. Acknowledgements...........................................25 112 13. Authors' Addresses.........................................25 113 14. Intellectual Property Statement............................26 114 15. Copyright Statement........................................26 115 16. Disclaimer.................................................27 117 1. Introduction 119 The IPFIX Information Model [RFC5102] defines an extensible list of 120 Information Elements which may be transmitted by the IPFIX protocol 121 [RFC5101]. 123 This document lists a series of new Information Elements to update 124 the IPFIX Information Model, and acts as the persistent publication 125 medium requested in the IANA considerations section of the IPFIX 126 Information Model [RFC5102] ("The specification of new IPFIX 127 Information Elements MUST use the template specified in section 2.1 128 and MUST be published using a well established and persistent 129 publication medium"). 131 2. Terminology 133 IPFIX-specific terminology used in this document is defined in 134 section 2 of the IPFIX Protocol [RFC5101]. As in the IPFIX Protocol 135 [RFC5101], these IPFIX-specific terms have the first letter of a word 136 capitalized when used in this document. 138 2.1 IPFIX Documents Overview 140 The IPFIX Protocol [RFC5101] provides network administrators with 141 access to IP flow information. 143 The architecture for the export of measured IP flow information out 144 of an IPFIX exporting process to a collecting process is defined in 145 the IPFIX Architecture [IPFIX-ARCH], per the requirements defined in 146 RFC 3917 [RFC3917]. 148 The IPFIX Architecture [IPFIX-ARCH] specifies how IPFIX Data Records 149 and Templates are carried via a congestion-aware transport protocol 150 from IPFIX Exporting Processes to IPFIX Collecting Processes. 152 IPFIX has a formal description of IPFIX Information Elements, their 153 name, type and additional semantic information, as specified in the 154 IPFIX Information Model [RFC5102]. 156 Finally the IPFIX Applicability Statement [IPFIX-AS] describes what 157 type of applications can use the IPFIX protocol and how they can use 158 the information provided. It furthermore shows how the IPFIX 159 framework relates to other architectures and frameworks. 161 2.2 PSAMP Documents Overview 163 The document "A Framework for Packet Selection and Reporting" [PSAMP- 164 FMWK], describes the PSAMP framework for network elements to select 165 subsets of packets by statistical and other methods, and to export a 166 stream of reports on the selected packets to a collector. 168 The set of packet selection techniques (sampling, filtering, and 169 hashing) supported by PSAMP are described in "Sampling and Filtering 170 Techniques for IP Packet Selection" [PSAMP-TECH]. 172 The PSAMP protocol [PSAMP-PROTO] specifies the export of packet 173 information from a PSAMP Exporting Process to a PSAMP Collecting 174 Process. Like IPFIX, PSAMP has a formal description of its 175 information elements, their name, type and additional semantic 176 information. The PSAMP information model is defined in [PSAMP-INFO]. 178 Finally [PSAMP-MIB] describes the PSAMP Management Information Base. 180 3. Information Element Identifiers 181 The value of the Information Element identifiers are in the range of 182 1 - 32767. Within this range, Information Element identifier values 183 in the sub-range of 1-127 are compatible with field types used by 184 NetFlow version 9 [RFC3954]. 186 The following list gives an overview of the new Information Element 187 identifiers that are in the range 1-127. These Information Elements 188 were previously RESERVED according to the IPFIX Information Model 189 [RFC5102] and IANA. 191 +-------+----------------------------+ 192 | ID | Name | 193 +-------+----------------------------+ 194 | 82 | interfaceName | 195 | 83 | interfaceDescription | 196 ~ ~ ~ 197 | 89 | forwardingStatus | 198 ~ ~ ~ 199 | 91 | mplsTopLabelPrefixLength | 200 ~ ~ ~ 201 | 98 | postIpDiffServCodePoint | 202 | 99 | multicastReplicationFactor | 203 +-------+----------------------------+ 205 The following list gives an overview of new Information Elements, not 206 part of the RESERVED range. It also displays the ideal Information 207 Element identifiers that we would like IANA to assign. Note that the 208 following web site http://ipfix.netlab.nec.de/infoElements.php, 209 maintained by the IPFIX Chair (Juergen Quittek) is a placeholder for 210 the allocation of the Information Element Id, while waiting for the 211 IANA assignments. 213 +-------+----------------------------------+ 214 | ID | Name | 215 +-------+----------------------------------+ 216 | 225 | postNATSourceIPv4Address | 217 | 226 | postNATDestinationIPv4Address | 218 | 227 | postNAPTSourceTransportPort | 219 | 228 | postNAPTDestinationTransportPort | 220 | 229 | natOriginatingAddressRealm | 221 | 230 | natEvent | 222 | 231 | InitiatorOctets | 223 | 232 | ResponderOctets | 224 | 233 | firewallEvent | 225 | 234 | ingressVRFID | 226 | 235 | egressVRFID | 227 | 236 | VRFname | 228 ~ ~ ~ 229 | 240 | ethernetHeaderLength | 230 | 241 | ethernetPayloadLength | 231 | 242 | ethernetTotalLength | 232 | 243 | dot1qVlanId | 233 | 244 | dot1qPriority | 234 | 245 | dot1qCustomerVlanId | 235 | 246 | dot1qCustomerPriority | 236 | 247 | metroEvcId | 237 | 248 | metroEvcType | 238 | 249 | pseudoWireId | 239 | 250 | pseudoWireType | 240 | 251 | pseudoWireControlWord | 241 | 252 | ingressPhysicalInterface | 242 | 253 | egressPhysicalInterface | 243 | 254 | postDot1qVlanId | 244 | 255 | postDot1qCustomerVlanId | 245 | 256 | ethernetType | 246 ~ ~ ~ 247 | 335 | selectorName | 248 +-------+----------------------------------+ 250 4. New Information Elements in the range 1-127 252 4.1 interfaceName 254 Description: 255 A short name uniquely describing an interface, eg "Eth1/0". 256 Abstract Data Type: string 257 ElementId: 82 258 Status: current 259 Reference: 260 See RFC 2863 [RFC2863] for the definition of the ifName object. 262 4.2 interfaceDescription 264 Description: 265 The description of an interface, eg "FastEthernet 1/0" or "ISP 266 connection". 267 Abstract Data Type: string 268 ElementId: 83 269 Status: current 270 Reference: 271 See RFC 2863 [RFC2863] for the definition of the ifDescr object. 273 4.3 forwardingStatus 275 Description: 276 Describes the forwarding status of the flow and any attached 277 reasons. 279 Forwarding Status is a variable length field with length of 1, 2 280 or 4 octets. 282 *** IANA ACTION *** 284 The values of this element are to be allocated from IANA 285 registries which can be found at 286 http://www.iana.org/assignments/... 287 A. When length = 1 octet: 289 0 1 2 3 4 5 6 7 290 +-+-+-+-+-+-+-+-+ 291 | S | | 292 | t | Reason | 293 | a | codes | 294 | t | or | 295 | u | flags | 296 | s | | 297 +-+-+-+-+-+-+-+-+ 299 Status: 301 00b = Unknown 302 01b = Forwarded 303 10b = Dropped 304 11b = Consumed 306 Reason codes: 308 Reason codes are defined per status code. 310 Reason Code (status = 01b, Forwarded): 312 000000b = Unknown 313 000001b = Fragmented 314 000010b = Not Fragmented 316 Reason Code (status = 10b, Dropped): 318 000000b = Unknown 319 000001b = ACL Deny 320 000010b = ACL drop 321 000011b = Unroutable 322 000100b = Adjacency 323 000101b = Fragmentation & DF set 324 000110b = Bad header checksum 325 000111b = Bad total Length 326 001000b = Bad Header Length 327 001001b = bad TTL 328 001010b = Policer 329 001011b = WRED 330 001100b = RPF 331 001101b = For us 332 001110b = Bad output interface 333 001111b = Hardware 335 Reason Code (status = 11b, Consumed): 337 000000b = Unknown 338 000001b = Punt Adjacency 339 000010b = Incomplete Adjacency 340 000011b = For us 342 Example 1: 344 hex dump: 01 000000 345 decode: 01 -> Forward 346 000000 -> No further information 348 Example 2: 350 hex dump: 10 001001 351 decode : 10 -> Drop 352 001001 -> Fragmentation & DF set 354 B. When length = 2 octets: 356 A length of 2 indicates an extended reason: 358 bit 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 360 +----------------+----------------+ 361 |Status & Reason | Extended Reason| 362 +----------------+----------------+ 364 The status and reason are as defined in (A) above. The 365 extended reasons are yet to be defined. 367 C. When length = 4 octets: 369 If there are further extensions to the reason, the field 370 length is 4: 372 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 373 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 374 +----------------+----------------+----------------+----------------+ 375 |Status & Reason | Extended Reason| Further Extensions | 376 +----------------+----------------+----------------+----------------+ 378 The status, reason and extended reason are as defined in (B) 379 above. Further extended reasons are yet to be defined. 381 Abstract Data Type: octetArray 382 Data Type Semantics: flags 383 ElementId: 89 384 Status: current 386 4.4 mplsTopLabelPrefixLength 388 Description: 389 The prefix length of the subnet of the mplsTopLabelIPv4Address 390 that the MPLS top label will cause the Flow to be forwarded to. 391 Abstract Data Type: unsigned 8 392 Data Type Semantics: identifier 393 ElementId: 91 394 Status: current 395 Units: bits 396 Range: The valid range is 0-32 397 Reference: 398 See RFC 3031 for the association between MPLS labels and prefix 399 lengths. 401 4.5 postIpDiffServCodePoint 403 Description: 404 The definition of this Information Element is identical to the 405 definition of Information Element 'ipDiffServCodePoint', except 406 that it reports a potentially modified value caused by a 407 middlebox function after the packet passed the Observation 408 Point. 409 Abstract Data Type: unsigned8 410 Data Type Semantics: identifier 411 ElementId: 98 412 Status: current 413 Range: The valid range is 0-63. 414 Reference: 415 See RFC 3260 [RFC3260] for the definition of the Differentiated 416 Services Field. See section 5.3.2 of RFC 1812 [RFC1812] and RFC 417 791 [RFC791] for the definition of the IPv4 TOS field. See RFC 418 2460 [RFC2460] for the definition of the IPv6 Traffic Class 419 field. See the IPFIX Informaiton Model [RFC5102] for the 420 'ipDiffServCodePoint' specification. 422 4.6 multicastReplicationFactor 424 Description: 425 The amount of multicast replication that's applied to a traffic 426 stream. 427 Abstract Data Type: 428 Data Type Semantics: 429 ElementId: 99 430 Status: current 431 Reference: 432 See RFC 1112 [RFC1112] for the specification of reserved IPv4 433 multicast addresses. See RFC 4291 [RFC4291] for the 434 specification of reserved IPv6 multicast addresses. 436 5. New Information Elements in the range 128-32767 438 5.1 postNATSourceIPv4Address 440 Description: 441 The definition of this Information Element is identical to the 442 definition of Information Element 'sourceIPv4Address', except 443 that it reports a modified value caused by a NAT middlebox 444 function after the packet passed the Observation Point. 445 Abstract Data Type: ipv4Address 446 Data Type Semantics: identifier 447 ElementId: 225 448 Status: current 449 Reference: 450 See RFC 791 [RFC791] for the definition of the IPv4 source 451 address field. See RFC 3022 [RFC3022] for the definition of 452 NAT. See RFC 3234 [RFC3234] for the definition of middleboxes. 454 5.2 postNATDestinationIPv4Address 456 Description: 457 The definition of this Information Element is identical to the 458 definition of Information Element 'destinationIPv4Address', 459 except that it reports a modified value caused by a NAT 460 middlebox function after the packet passed the Observation 461 Point. 462 Abstract Data Type: ipv4Address 463 Data Type Semantics: identifier 464 ElementId: 226 465 Status: current 466 Reference: 467 See RFC 791 [RFC791] for the definition of the IPv4 destination 468 address field. See RFC 3022 [RFC3022] for the definition of 469 NAT. See RFC 3234 [RFC3234] for the definition of middleboxes. 471 5.3 postNAPTSourceTransportPort 473 Description: 474 The definition of this Information Element is identical to the 475 definition of Information Element 'sourceTransportPort', except 476 that it reports a modified value caused by a Network Address 477 Port Translation (NAPT) middlebox function after the packet 478 passed the Observation Point. 479 Abstract Data Type: unsigned16 480 Data Type Semantics: identifier 481 ElementId: 227 482 Status: current 483 Reference: 484 See RFC 768 [RFC768] for the definition of the UDP source port 485 field. See RFC 793 [RFC793] for the definition of the TCP 486 source port field. See RFC 4960 [RFC4960] for the definition of 487 SCTP. 488 See RFC 3022 [RFC3022] for the definition of NAPT. See RFC 3234 489 [RFC3234] for the definition of middleboxes. 490 Additional information on defined UDP and TCP port numbers can 491 be found at http://www.iana.org/assignments/port-numbers. 493 5.4 postNAPTDestinationTransportPort 495 Description: 496 The definition of this Information Element is identical to the 497 definition of Information Element 'destinationTransportPort', 498 except that it reports a modified value caused by a Network 499 Address Port Translation (NAPT) middlebox function after the 500 packet passed the Observation Point. 501 Abstract Data Type: unsigned16 502 Data Type Semantics: identifier 503 ElementId: 228 504 Status: current 505 Reference: 506 See RFC 768 [RFC768] for the definition of the UDP source port 507 field. See RFC 793 [RFC793] for the definition of the TCP 508 source port field. See RFC 4960 [RFC4960] for the definition of 509 SCTP. See RFC 3022 [RFC3022] for the definition of NAPT. See 510 RFC 3234 [RFC3234] for the definition of middleboxes. 511 Additional information on defined UDP and TCP port numbers can 512 be found at http://www.iana.org/assignments/port-numbers. 514 5.5 natOriginatingAddressRealm 516 Description: 517 Indicates whether the session was created because traffic 518 originated in the private or public address realm. 519 postNATSourceIPv4Address, postNATDestinationIPv4Address, 520 postNAPTSourceTransportPort, and 521 postNAPTDestinationTransportPort are qualified with the address 522 realm in perspective. 523 The allowed values are: 524 Private: 1 525 Public: 2 526 Abstract Data Type: unsigned8 527 Data Type Semantics: flags 528 ElementId: 229 529 Status: current 530 Reference: 531 See RFC 3022 [RFC3022] for the definition of NAT. 533 5.6 natEvent 535 Description: 536 Indicates a NAT event. The allowed values are: 537 1 - Create event. 538 2 - Delete event. 540 A Create event is generated when a NAT translation is created, 541 whether dynamically or statically. A Delete event is generated 542 when a NAT translation is deleted. 543 Abstract Data Type: unsigned8 544 Data Type Semantics: 545 ElementId: 230 546 Status: current 547 Reference: 548 See RFC 3022 [RFC3022] for the definition of NAT. 550 5.7 initiatorOctets 552 Description: 553 The total number of layer 4 payload bytes in a flow from the 554 initiator. The initiator is the device which triggered the 555 session creation, and remains the same for the life of the 556 session. 557 Abstract Data Type: unsigned64 558 Data Type Semantics: 559 ElementId: 231 560 Status: current 562 5.8 responderOctets 564 Description: 565 The total number of layer 4 payload bytes in a flow from the 566 responder. The responder is the device which replies to the 567 initiator, and remains the same for the life of the session. 568 Abstract Data Type: unsigned64 569 Data Type Semantics: 570 ElementId: 232 571 Status: current 573 5.9 firewallEvent 575 Description: 576 Indicates a firewall event. The allowed values are: 578 0 - Ignore (invalid) 579 1 - Flow Created 580 2 - Flow Deleted 581 3 - Flow Denied 582 4 - Flow Alert 584 Abstract Data Type: unsigned8 585 Data Type Semantics: 586 ElementId: 233 587 Status: current 589 5.10 ingressVRFID 591 Description: 592 An unique identifier of the VRFname where the packets of this 593 flow are being received. This identifier is unique per Metering 594 Process 595 Abstract Data Type: unsigned32 596 Data Type Semantics: 597 ElementId: 234 598 Status: current 600 5.11 egressVRFID 602 Description: 603 An unique identifier of the VRFname where the packets of this 604 flow are being sent. This identifier is unique per Metering 605 Process 606 Abstract Data Type: unsigned32 607 Data Type Semantics: 608 ElementId: 235 609 Status: current 611 5.12 VRFname 613 Description: 614 The name of a VPN Routing and Forwarding table (VRF). 615 Abstract Data Type: string 616 ElementId: 236 617 Status: current 618 Reference: 619 See RFC 4364 [RFC4364] for the definition of VRF. 621 5.13 ethernetHeaderLength 623 Description: 624 The difference between the length of an Ethernet frame (minus the 625 FCS) and the length of its MAC Client Data section (including any 626 padding) as defined in section 3.1 of [IEEE.802-3.2005]. It does 627 not include the Preamble, SFD and Extension field lengths. 628 Abstract Data Type: unsigned8 629 Data Type Semantics: identifier 630 ElementId: 240 631 Status: current 632 Units: octets 633 Reference: 634 (1) [IEEE.802-3.2005] 636 5.14 ethernetPayloadLength 638 Description: 639 The length of the MAC Client Data section (including any padding) 640 of a frame as defined in section 3.1 of [IEEE.802-3.2005]. 641 Abstract Data Type: unsigned16 642 Data Type Semantics: identifier 643 ElementId: 241 644 Status: current 645 Units: octets 646 Reference: 647 (1) [IEEE.802-3.2005] 649 5.15 ethernetTotalLength 651 Description: 652 The total length of the Ethernet frame (excluding the Preamble, 653 SFD, Extension and FCS fields) as described in section 3.1 of 654 [IEEE.802-3.2005]. 655 Abstract Data Type: unsigned16 656 Data Type Semantics: identifier 657 ElementId: 242 658 Status: current 659 Units: octets 660 Reference: 661 (1) [IEEE.802-3.2005] 663 5.16 dot1qVlanId 665 Description: 666 The value of the 12-bit VLAN Identifier portion of the Tag 667 Control Information field of an Ethernet frame as described in 668 section 3.5.5 of [IEEE.802-3.2005]. The structure and semantics 669 within the Tag Control Information field are defined in IEEE 670 P802.1Q. In case of a QinQ frame, it represents the outer tag's 671 VLAN identifier and in case of an IEEE 802.1ad frame it 672 represents the Service VLAN identifier in the S-TAG Tag Control 673 Information (TCI) field as described in [IEEE.802-1ad.2005]. 674 Abstract Data Type: unsigned16 675 Data Type Semantics: identifier 676 ElementId: 243 677 Status: current 678 Reference: 679 (1) [IEEE.802-3.2005] 680 (2) [IEEE.802-1ad.2005] 682 5.17 dot1qPriority 684 Description: 685 The value of the 3-bit User Priority portion of the Tag Control 686 Information field of an Ethernet frame as described in section 687 3.5.5 of [IEEE.802-3.2005]. The structure and semantics within 688 the Tag Control Information field are defined in IEEE P802.1Q. 689 In case of a QinQ frame, it represents the outer tag's 3-bit 690 Class of Service (CoS) identifier and in case of an IEEE 802.1ad 691 frame it represents the 3-bit Priority Code Point (PCP) portion 692 of the S-TAG Tag Control Information (TCI) field as described in 693 [IEEE.802-1ad.2005]. 694 Abstract Data Type: unsigned8 695 Data Type Semantics: identifier 696 ElementId: 244 697 Status: current 698 Reference: 699 (1) [IEEE.802-3.2005] 700 (2) [IEEE.802-1ad.2005] 702 5.18 dot1qCustomerVlanId 704 Description: 705 In case of a QinQ frame, it represents the inner tag's (*) VLAN 706 identifier and in case of an IEEE 802.1ad frame it represents the 707 Customer VLAN identifier in the C-TAG Tag Control Information 708 (TCI) field as described in [IEEE.802-1ad.2005]. 709 (*) Note: the 801.2Q tag directly following the outer one. 710 Abstract Data Type: unsigned16 711 Data Type Semantics: identifier 712 ElementId: 245 713 Status: current 714 Reference: 715 (1) [IEEE.802-1ad.2005] 716 (2) [IEEE.802-1Q.2003] 718 5.19 dot1qCustomerPriority 720 Description: 721 In case of a QinQ frame, it represents the inner tag's (*) Class 722 of Service (CoS) identifier and in case of an IEEE 802.1ad frame 723 it represents the 3-bit Priority Code Point (PCP) portion of the 724 C-TAG Tag Control Information (TCI) field as described in 725 [IEEE.802-1ad.2005]. 726 (*) Note: the 801.2Q tag directly following the outer one. 728 Abstract Data Type: unsigned8 729 Data Type Semantics: identifier 730 ElementId: 246 731 Status: current 732 Reference: 733 (1) [IEEE.802-1ad.2005] 734 (2) [IEEE.802-1Q.2003] 736 5.20 metroEvcId 738 Description: 739 The EVC Service Attribute which uniquely identifies the Ethernet 740 Virtual Connection (EVC) within a Metro Ethernet Network, as 741 defined in section 6.2 of MEF 10.1. The MetroEVCID is encoded in 742 a string of up to 100 characters. 743 Abstract Data Type: string 744 ElementId: 247 745 Status: current 746 Reference: 747 (1) MEF 10.1 (Ethernet Services Attributes Phase 2) 748 (2) MEF16 (Ethernet Local Management Interface) 750 5.21 metroEvcType 752 Description: 753 The 3-bit EVC Service Attribute which identifies the type of 754 service provided by an EVC. 755 Abstract Data Type: unsigned8 756 Data Type Semantics: identifier 757 ElementId: 248 758 Status: current 759 Reference: 760 (1) MEF 10.1 (Ethernet Services Attributes Phase 2) 761 (2) MEF16 (Ethernet Local Management Interface) 763 5.22 pseudoWireId 765 Description: 766 A 32-bit non-zero connection identifier, which together with the 767 pseudoWireType, identifies the Pseudo Wire (PW) as defined in RFC 768 4447 [RFC4447]. 769 Abstract Data Type: unsigned32 770 Data Type Semantics: identifier 771 ElementId: 249 772 Status: current 773 Reference: 774 See RFC 4447 [RFC4447] for pseudowire definitions. 776 5.23 pseudoWireType 778 Description: 779 The value of this information element identifies the type of MPLS 780 Pseudo Wire (PW) as defined in RFC 4446. 781 Abstract Data Type: unsigned16 782 Data Type Semantics: identifier 783 ElementId: 250 784 Status: current 785 Reference: 786 See RFC 4446 [RFC4446] for the pseudowire type definition, and 787 http://www.iana.org/assignments/pwe3-parameters for the IANA 788 Pseudowire Types Registry. 790 5.24 pseudoWireControlWord 792 Description: 793 The 32-bit Preferred Pseudo Wire (PW) MPLS Control Word as 794 defined in Section 3 of RFC 4385 [RFC4385]. 795 Abstract Data Type: unsigned32 796 Data Type Semantics: identifier 797 ElementId: 251 798 Status: current 799 Reference: 800 See RFC 4385 [RFC4385] for the Pseudo Wire Control Word 801 definition. 803 5.25 ingressPhysicalInterface 805 Description: 806 The index of a networking device's physical interface (example, a 807 switch port) where packets of this flow are being received. 808 Abstract Data Type: unsigned32 809 Data Type Semantics: identifier 810 ElementId: 252 811 Status: current 812 Reference: 813 See RFC 2863 [RFC2863] for the definition of the ifIndex object. 815 5.26 egressPhysicalInterface 817 Description: 818 The index of a networking device's physical interface (example, a 819 switch port) where packets of this flow are being sent. 821 Abstract Data Type: unsigned32 822 Data Type Semantics: identifier 823 ElementId: 253 824 Status: current 825 Reference: 826 See RFC 2863 [RFC2863] for the definition of the ifIndex object. 828 5.27 postDot1qVlanId 830 Description: 831 The definition of this Information Element is identical to the 832 definition of Information Element 'dot1qVlanId', except that it 833 reports a potentially modified value caused by a middlebox 834 function after the packet passed the Observation Point. 835 Abstract Data Type: unsigned16 836 Data Type Semantics: identifier 837 ElementId: 254 838 Status: current 839 Reference: 840 (1) [IEEE.802-3.2005] 841 (2) [IEEE.802-1ad.2005] 843 5.28 postDot1qCustomerVlanId 845 Description: 846 The definition of this Information Element is identical to the 847 definition of Information Element 'dot1qCustomerVlanId', except 848 that it reports a potentially modified value caused by a 849 middlebox function after the packet passed the Observation Point. 850 Abstract Data Type: unsigned16 851 Data Type Semantics: identifier 852 ElementId: 255 853 Status: current 854 Reference: 855 (1) [IEEE.802-1ad.2005] 856 (2) [IEEE.802-1Q.2003] 858 5.29 ethernetType 860 Description: 861 The Ethernet type field of an Ethernet frame that identifies the 862 MAC client protocol carried in the payload as defined in 863 paragraph 1.4.349 of [IEEE.802-3.2005]. 864 Abstract Data Type: unsigned16 865 Data Type Semantics: identifier 866 ElementId: 256 867 Status: current 868 Reference: 869 (1) [IEEE.802-3.2005] 870 (2) Ethertype registry available at 871 http://standards.ieee.org/regauth/ethertype/eth.txt 873 5.30 selectorName 875 Description: 876 The name of a selector identified by a selectorID. Globally 877 unique per Metering Process. 878 Abstract Data Type: string 879 ElementId: 335 880 Status: current 882 6. Relationship between dot1qVlanId and vlanId 884 The IPFIX Information Model [RFC5102] specifies the vlanId 885 Information Element, while this document specifies the dot1qVlanId. 887 The vlanId Information Element references [IEEE.802-1Q.2003], while 888 the dot1qVlanId references [IEEE.802-3.2005] and [IEEE.802-1ad.2005]. 889 Since the [IEEE.802-1ad.2005] supersedes the [IEEE.802-1Q.2003] (it 890 mentions: "Amendment to IEEE Std 802.1Q-2005".), then the dot1qVlanId 891 supersedes vlanId. 893 ***IANA ACTION *** 895 As a consequence the vlanId specified in the IPFIX Information Model 896 [RFC5102] is now deprecated: 898 vlanId 899 Description: 900 The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag 901 Control Information field that was attached to the IP packet. 902 Abstract Data Type: unsigned16 903 Data Type Semantics: identifier 904 ElementId: 58 905 Status: deprecated 906 Reference: 907 See [IEEE.802-1Q.2003]. 909 ***IANA ACTION *** 911 This document also specifies postDot1qVlanId, in connection with the 912 dot1qCustomerVlanId. As a consequence, the postVlanId specified in 913 the IPFIX Information Model [RFC5102] is now deprecated: 915 postVlanId 916 Description: 917 The definition of this Information Element is identical to the 918 definition of Information Element 'vlanId', except that it 919 reports a potentially modified value caused by a middlebox 920 function after the packet passed the Observation Point. 921 Abstract Data Type: unsigned16 922 Data Type Semantics: identifier 923 ElementId: 59 924 Status: deprecated 925 Reference: 926 See [IEEE.802-1Q.2003]. 928 7. Relationship between interface related Information Elements 930 The IPFIX Information Model [RFC5102] specifies the ingressInterface 931 (#10) and egressInterface (#14) information elements, while this 932 document specifies the ingressPhysicalInterface and 933 egressPhysicalInterface. 935 The IPFIX definitions for ingressInterface and egressInterface are 936 somewhat vague, essentially in case of the virtual interfaces. Let 937 us consider traffic transiting a tunnel, where the virtual and 938 physical interfaces are different. If one implementation uses the 939 ingressInterface and egressInterface to report the physical 940 interfaces while another implementation uses the same information 941 elements to report the virtual interfaces, without somehow making 942 this clear to the Collector, then any reports and analysis are going 943 to be skewed. 945 The specifications of ingressPhysicalInterface and 946 egressPhysicalInterface clarifies the situation. 948 The relationship between the multiple sub-layers of network 949 interfaces is specified in the ifStackTable MIB table in the 950 interface MIB [RFC2863]. 952 8. IANA Considerations 954 This document specifies new IPFIX Information Elements in two ranges. 956 Information Elements in the range 1 to 127 are compatible with field 957 types used by NetFlow version 9 [RFC3954]. These Information 958 Elements were previously RESERVED according to the IPFIX Information 959 Model [RFC5102] and IANA. These should be allocated immediately with 960 the specified IDs to retain backwards compatibility with NetFlow 961 version 9 [RFC3954]. 963 The remainder of the Information Elements (in the range 128 and up) 964 are new, and are therefore subject to expert review as specified in 965 the IPFIX Information Model [RFC5102]. They are listed here with the 966 ideal Information Element identifiers that we would like IANA to 967 assign. 969 In addition, some IANA actions have been highlighted in section 7. 971 Finally, the forwardingStatus Information Element requires the 972 creation of new IANA registries. 974 9. References 976 9.1 Normative References 978 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 979 August 1980. 981 [RFC791] J. Postel, "Internet Protocol. DARPA Internet Program. 982 Protocol Specification," RFC 791, September 1981. 984 [RFC793] J. Postel, "Transmission Control Protocol", September 985 1981. 987 [RFC1112] B. Braden, "Requirements for Internet hosts - 988 communication layers", Octobre 1989. 990 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 991 RFC 1812, June 1995. 993 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 994 Requirement Levels", BCP 14, RFC 2119, March 1997 996 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 997 (IPv6) Specification", RFC 2460, December 1998. 999 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1000 MIB", RFC 2863, June 2000. 1002 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1003 Architecture", RFC 4291, February 2006. 1005 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1006 Networks (VPNs)", RFC 4364, February 2006. 1008 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1009 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1010 Use over an MPLS PSN", RFC 4385, February 2006. 1012 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1013 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1015 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 1016 G. Heron, "Pseudowire Setup and Maintenance Using the 1017 Label Distribution Protocol (LDP)", RFC 4447, April 2006. 1019 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1020 RFC 4960, September 2007. 1022 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 1023 Export (IPFIX) Protocol for the Exchange of IP Traffic 1024 Flow Information", RFC 5101, January 2008. 1026 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1027 Meyer, "Information Model for IP Flow Information Export", 1028 RFC 5102, January 2008. 1030 [IEEE.802-1ad.2005] 1031 "IEEE Standard for Local and Metropolitan Area Networks--- 1032 Virtual Bridged Local Area Networks---Amendment 4: 1033 Provider Bridges", IEEE 802.1ad-2005, May 26, 2006. 1035 [IEEE.802-1Q.2003] 1036 "IEEE Standards for Local and Metropolitan Area Networks: 1037 Virtual Bridged Local Area Networks", IEEE 802.1Q,2003 1038 Edition-2003. 1040 [IEEE Std 802.1Q-2005] 1041 "IEEE Standard for Local and Metropolitan Area Networks--- 1042 Virtual Bridged Local Area Networks", IEEE 802.1Q-2005, 1043 May 19, 2006. 1045 [IEEE.802-3.2005] 1046 "IEEE Standard for Information Technology - 1047 Telecommunications and Information Exchange Between 1048 Systems - Local and Metropolitan Area Networks - Specific 1049 Requirements Part 3: Carrier Sense Multiple Access with 1050 Collision Detection (CSMA/CD) Access Method and Physical 1051 Layer Specifications", IEEE 802.3-2005, Dec 09, 2005. 1053 [ISO_IEC.7498-1_1994] 1054 International Organization for Standardization, 1055 "Information technology -- Open Systems Interconnection -- 1056 Basic Reference Model: The Basic Mode", ISO Standard 7498- 1057 1:1994, June 1996. 1059 9.2 Informative References 1061 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1062 Address Translator (Traditional NAT)", RFC 3022, January 1063 2001. 1065 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1066 Issues", RFC 3234, February 2002. 1068 [RFC3260] Grossman, D., "New Terminology and Clarifications for 1069 Diffserv", RFC 3260, April 2002. 1071 [RFC3917] Quittek, J., Zseby, T., Claise, B., Zander, S., 1072 "Requirements for IP Flow Information Export" RFC 3917, 1073 October 2004 1075 [RFC3954] Claise, B., et al "Cisco Systems NetFlow Services Export 1076 Version 9", RFC 3954, October 2004 1078 [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek, J., 1079 "Architecture Model for IP Flow Information Export" 1080 draft-ietf-ipfix-architecture-12, September 2006 1082 [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B., "IPFIX 1083 Applicability", draft-ietf-ipfix-as-12.txt, June 2007 1085 [PSAMP-FMWK] D. Chiou, B. Claise, N. Duffield, A. Greenberg, M. 1086 Grossglauser, P. Marimuthu, J. Rexford, G. Sadasivan, 1087 "A Framework for Passive Packet Measurement" draft-ietf- 1088 psamp-framework-12.txt 1090 [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. 1091 Raspall, "Sampling and Filtering Techniques for IP 1092 Packet Selection" draft-ietf-psamp-sample-tech-10.txt 1094 [PSAMP-PROTO] B. Claise (Ed.), "Packet Sampling (PSAMP) Protocol 1095 Specifications", RFC XXXX. [Currently Internet Draft 1096 draft-ietf-psamp-protocol-09.txt, work in progress, 1097 December 2007]. 1099 [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, "Information 1100 Model for Packet Sampling Exports", draft-ietf-psamp- 1101 info-08.txt 1103 [PSAMP-MIB] Dietz, T., Claise, B. "Definitions of Managed Objects 1104 for Packet Sampling", Internet-Draft work in progress, 1105 June 2006 1107 10. Security Considerations 1109 The IPFIX information model itself does not directly introduce 1110 security issues. Rather, it defines a set of attributes that may for 1111 privacy or business issues be considered sensitive information. 1113 11. Contributors 1115 Ganesh Murthy 1116 Cisco Systems, Inc. 1117 3850 Zanker Road 1118 San Jose , CALIFORNIA 95134 1119 United States 1121 Phone: +1 408 853 7869 1122 EMail: gmurthy@cisco.com 1124 Marco Foschiano 1125 Cisco Systems, Inc. 1126 Torri Bianche-Faggio Bldg Lot H1 1127 Via Torri Bianche 7 1128 Vimercate 20059 1129 Italy 1131 Phone: +39 039 629 5244 1132 EMail: foschia@cisco.com 1134 12. Acknowledgements 1136 The editors would like to thank the following persons for their 1137 reviews of the information elements specifications: Andrew Johnson, 1138 Gennady Dosovitsky, George Serpa, Mike Tracy, Nagaraj Varadharajan, 1139 Senthil Sivakumar, Stan Yates, Stewart Bryant and Roland Dobbins. The 1140 contributors wish to thank the following individuals for discussions 1141 and feedback: Bob Klessig, Neil McGill, Samer Salam, Yibin Yang, Ravi 1142 Samprathi and Prasanna Rajah. 1144 13. Authors' Addresses 1146 Paul Aitken 1147 Cisco Systems, Inc. 1148 96 Commercial Quay 1149 Edinburgh EH6 6LX 1150 Scotland 1152 Phone: +44 131 561 3616 1153 EMail: paitken@cisco.com 1155 Benoit Claise 1156 Cisco Systems, Inc. 1157 De Kleetlaan 6a b1 1158 Diegem 1831 1159 Belgium 1161 Phone: +32 2 704 5622 1162 EMail: bclaise@cisco.com 1164 14. Intellectual Property Statement 1166 The IETF takes no position regarding the validity or scope of 1167 any Intellectual Property Rights or other rights that might be 1168 claimed to pertain to the implementation or use of the 1169 technology described in this document or the extent to which any 1170 license under such rights might or might not be available; nor 1171 does it represent that it has made any independent effort to 1172 identify any such rights. Information on the procedures with 1173 respect to rights in RFC documents can be found in BCP 78 and 1174 BCP 79. 1175 Copies of IPR disclosures made to the IETF Secretariat and any 1176 assurances of licenses to be made available, or the result of an 1177 attempt made to obtain a general license or permission for the 1178 use of such proprietary rights by implementers or users of this 1179 specification can be obtained from the IETF on-line IPR 1180 repository at http://www.ietf.org/ipr. 1182 The IETF invites any interested party to bring to its attention 1183 any copyrights, patents or patent applications, or other 1184 proprietary rights that may cover technology that may be 1185 required to implement this standard. Please address the 1186 information to the IETF at ietf-ipr@ietf.org. 1188 15. Copyright Statement 1190 Copyright (C) The IETF Trust (2008). 1192 This document is subject to the rights, licenses and 1193 restrictions contained in BCP 78, and except as set forth 1194 therein, the authors retain all their rights. 1196 16. Disclaimer 1198 This document and the information contained herein are provided 1199 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1200 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1201 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 1202 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1203 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1204 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1205 OR FITNESS FOR A PARTICULAR PURPOSE.