idnits 2.17.1 draft-ietf-ipfix-reqs-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 186 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1154 has weird spacing: '...for the purpo...' -- 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 (February 2003) is 7739 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Quittek 2 draft-ietf-ipfix-reqs-09.txt NEC Europe Ltd. 3 Category: Informational T. Zseby 4 Expires: August 2003 Fraunhofer FOKUS 5 B. Claise 6 Cisco Systems 7 S. Zander 8 Fraunhofer FOKUS 10 February 2003 12 Requirements for IP Flow Information Export 14 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all provisions 19 of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This memo defines requirements for the export of measured IP flow 44 information out of routers, traffic measurement probes and 45 middleboxes. 47 Table of Contents 49 1 Introduction ................................................. 3 50 2 Terminology .................................................. 3 51 2.1 IP Traffic Flow ............................................ 3 52 2.2 Observation Point .......................................... 4 53 2.3 Metering Process ........................................... 4 54 2.4 Flow Record ................................................ 5 55 2.5 Exporting Process .......................................... 5 56 2.6 Collecting Process ......................................... 5 57 3 Applications Requiring IP Flow Information Export ............ 5 58 3.1 Usage-based Accounting ..................................... 6 59 3.2 Traffic Profiling .......................................... 6 60 3.3 Traffic Engineering ........................................ 6 61 3.4 Attack/Intrusion Detection ................................. 7 62 3.5 QoS Monitoring ............................................. 7 63 4 Distinguishing Flows ......................................... 8 64 4.1 Interfaces ................................................. 9 65 4.2 IP Header Fields ........................................... 9 66 4.3 Transport Header Fields .................................... 9 67 4.4 MPLS Label ................................................. 9 68 4.5 DiffServ Code Point ........................................ 9 69 4.6 Header Compression and Encryption .......................... 9 70 5 Metering Process ............................................. 10 71 5.1 Reliability ................................................ 10 72 5.2 Sampling ................................................... 10 73 5.3 Overload Behavior .......................................... 11 74 5.4 Timestamps ................................................. 11 75 5.5 Time Synchronization ....................................... 12 76 5.6 Flow Expiration ............................................ 12 77 5.7 Multicast Flows ............................................ 12 78 5.8 Packet Fragmentation ....................................... 12 79 5.9 Ignore Port Copy ........................................... 13 80 6 Data Export .................................................. 13 81 6.1 Information Model .......................................... 13 82 6.2 Data Model ................................................. 15 83 6.3 Data Transfer .............................................. 15 84 6.3.1 Congestion Awareness ..................................... 15 85 6.3.2 Reliability .............................................. 15 86 6.3.3 Security ................................................. 16 87 6.4 Push and Pull Mode Reporting ............................... 17 88 6.5 Regular Reporting Interval ................................. 17 89 6.6 Notification on Specific Events ............................ 17 90 6.7 Anonymization .............................................. 17 91 7 Configuration ................................................ 17 92 7.1 Configuration of the Metering Process ...................... 17 93 7.2 Configuration of the Exporting Process ..................... 18 94 8 General Requirements ......................................... 18 95 8.1 Openness ................................................... 18 96 8.2 Scalability ................................................ 18 97 8.3 Several Collecting Processes ............................... 18 98 9 Special Device Considerations ................................ 19 99 10 Security Considerations ..................................... 21 100 10.1 Disclosure of Flow Information Data ....................... 21 101 10.2 Forgery of Flow Records ................................... 22 102 10.3 Denial of Service (DoS) Attacks ........................... 22 103 11 Acknowledgments ............................................. 22 104 12 Normative References ........................................ 23 105 13 Informative References ...................................... 23 106 14 Authors' Addresses .......................................... 24 107 15 Full Copyright Statement .................................... 25 108 Appendix: Derivation of Requirements from Applications ......... 26 110 1. Introduction 112 There are several applications that require flow-based IP traffic 113 measurements. Such measurements could be performed by a router while 114 forwarding the traffic, by a middlebox [RFC3234], or by a traffic 115 measurement probe attached to a line or a monitored port. This memo 116 defines requirements for exporting traffic flow information out of 117 these boxes for further processing by applications located on other 118 devices. In section 3, a selection of such applications is presented. 119 The following sections list requirements derived from these 120 applications. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. Terminology 128 The following terminology is used within this document: 130 2.1. IP Traffic Flow 132 There are several definitions of the term 'flow' being used by the 133 Internet community. Within this document we use the following one: 135 A flow is defined as a set of IP packets passing an observation point 136 in the network during a certain time interval. All packets belonging 137 to a particular flow have a set of common properties. Each property 138 is defined as the result of applying a function to the values of: 140 1. one or more packet header field (e.g. destination IP address), 141 transport header field (e.g. destination port number), or 142 application header field (e.g. RTP header fields [RFC1889]) 144 2. one or more characteristics of the packet itself (e.g. number 145 of MPLS labels, etc...) 147 3. one or more of fields derived from packet treatment (e.g. next 148 hop IP address, the output interface, etc...) 150 A packet is defined to belong to a flow if it completely satisfies 151 all the defined properties of the flow. 153 This definition covers the range from a flow containing all packets 154 observed at a network interface to a flow consisting of just a single 155 packet between two applications with a specific sequence number. 156 Please note that the flow definition does not necessarily match a 157 general application-level end-to-end stream. However, an application 158 may derive properties of application-level streams by processing 159 measured flow data. Also, please note that although packet properties 160 may depend on application headers, there is no requirement defined in 161 this document related to application headers. 163 2.2. Observation Point 165 The observation point is a location in the network where IP packets 166 can be observed. Examples are a line to which a probe is attached, a 167 shared medium such as an Ethernet-based LAN, a single port of a 168 router, or a set of interfaces (physical or logical) of a router. 170 Note that one observation point may be a superset of several other 171 observation points. For example one observation point can be an 172 entire line card. This would be the superset of the individual 173 observation points at the line card's interfaces. 175 2.3. Metering Process 177 The metering process generates flow records. Input to the process are 178 packet headers observed at an observation point and packet treatment 179 at the observation point, for example the selected output interface. 180 The metering process consists of a set of functions that includes 181 packet header capturing, timestamping, sampling, classifying, and 182 maintaining flow records. 184 The maintenance of flow records may include creating new records, 185 updating existing ones, computing flow statistics, deriving further 186 flow properties, detecting flow expiration, passing flow records to 187 the exporting process, and deleting flow records. 189 The sampling function and the classifying function may be applied 190 more than once with different parameters. Figure 1 shows the sequence 191 in which the functions are applied. Sampling is not illustrated in 192 the figure, it may be applied before any other function. 194 packet header capturing 195 | 196 timestamping 197 | 198 v 199 +----->+ 200 | | 201 | classifying 202 | | 203 +------+ 204 | 205 maintaining flow records 206 | 207 v 209 Figure 1: Functions of the metering process 211 2.4. Flow Record 213 A flow record contains information about a specific flow that was 214 metered at an observation point. A flow record contains measured 215 properties of the flow (e.g. the total number of bytes of all packets 216 of the flow) and usually also characteristic properties of the flow 217 (e.g. source IP address). 219 2.5. Exporting Process 221 The exporting process sends flow records to one or more collecting 222 processes. The flow records are generated by one or more metering 223 processes. 225 2.6. Collecting Process 227 The collecting process receives flow records from one or more 228 exporting processes. The collecting process might store received flow 229 records or further process them, but these actions are out of the 230 scope of this document. 232 3. Applications Requiring IP Flow Information Export 234 This section describes a selection of applications requiring IP flow 235 information export. Because requirements for flow export listed in 236 further sections below are derived from these applications, their 237 selection is crucial. The goal of this requirements document is not 238 to cover all possible applications with all their flow export 239 requirements, but to cover applications which are considered to be of 240 significant importance in today's and/or future IP networks, and for 241 which requirements can be met with reasonable technical effort. 243 Please note, that the described applications can have a large number 244 of differing implementations. Requirement details or the weighting of 245 requirements could differ for specific implementations. Therefore we 246 derive the requirements from the general functionality of the 247 selected applications. 249 The list of applications should lead to a better understanding of the 250 requirements which is particularly important when designing or 251 implementing traffic flow metering functions. A detailed overview of 252 which requirement was derived from which application(s) is given in 253 the appendix. 255 3.1. Usage-based Accounting 257 Several new business models for selling IP services and IP-based 258 services are currently under investigation. Beyond flat rate services 259 which do not need accounting, accounting can be based on time or 260 volume. Accounting data can serve as input for billing systems. 261 Accounting can be performed per user or per user group, it can be 262 performed just for basic IP service or individually per high-level 263 service and/or per content type delivered. For advanced/future 264 services, accounting may also be performed per class of service, per 265 application, per time of day, per used (label switched) path, etc. 267 3.2. Traffic Profiling 269 Traffic profiling is the process of characterizing IP flows by using 270 a model that represents key parameters of the flows such as flow 271 duration, volume, time and burstiness. It is a prerequisite for 272 network planning, network dimensioning, trend analysis, business 273 models development, and other activities. It heavily depends on the 274 particular traffic profiling objective(s) what statistics and 275 accuracy are required from the measurements. Typical information 276 needed for traffic profiling is the distribution of used services and 277 protocols in the network, the amount of packets of a specific type 278 (e.g. percentage of IPv6 packets) and specific flow profiles. 280 Since objectives for traffic profiling can vary, this application 281 requires a high flexibility of the measurement infrastructure, 282 especially regarding the options for measurement configuration and 283 packet classification. 285 3.3. Traffic Engineering 287 Traffic Engineering (TE) comprises methods for measurement, modeling, 288 characterization and control of a network. The goal of TE is the 289 optimization of network resource utilization and traffic performance 290 [RFC2702]. Since control and administrative reaction to measurement 291 results requires access to the involved network nodes, TE mechanisms 292 and the required measurement function usually are performed within 293 one administrative domain. Typical parameters required for TE are 294 link utilization, load between specific network nodes, number, size 295 and entry/exit points of the active flows and routing information. 297 3.4. Attack/Intrusion Detection 299 Capturing of flow information plays an important role for network 300 security, both for detection of security violation, and for 301 subsequent defense. In case of a Denial of Service (DOS) attack, flow 302 monitoring can allow detection of unusual situations or suspicious 303 flows. In a second step, flow analysis can be performed in order to 304 gather information about the attacking flows, and for deriving a 305 defense strategy. 307 Intrusion detection is a potentially more demanding application which 308 would not only look at specific characteristics of flows, but may 309 also use a stateful packet flow analysis for detecting specific, 310 suspicious activities, or unusually frequent activities. Such 311 activities may be characterized by specific communication patterns, 312 detectable by characteristic sequences of certain packet types. 314 3.5. QoS Monitoring 316 QoS monitoring is the passive measurement of quality parameters for 317 IP flows. In contrast to active measurements, passive measurements 318 utilize the existing traffic in the network for QoS analysis. Since 319 no test traffic is sent, passive measurements can only be applied in 320 situations where the traffic of interest is already present in the 321 network. One example application is the validation of QoS parameters 322 negotiated in a service level specification. Note that passive/active 323 measurement is also referred to as non-intrusive/intrusive 324 measurement or as measurement of observed/synthetic traffic. 326 Passive measurements cannot provide the kind of controllable 327 experiments that can be achieved with active measurements. On the 328 other hand passive measurements do not suffer from undesired side 329 effects caused by sending test traffic (e.g. additional load, 330 potential differences in treatment of test traffic and real customer 331 traffic). 333 QoS monitoring often requires the correlation of data from multiple 334 observation points (e.g. for measuring one-way metrics). This 335 requires proper clock synchronization of the involved metering 336 processes. For some measurements, flow records and/or notifications 337 on specific events at the different observation points must be 338 correlated, for example the arrival of a certain packet. For this, 339 the provisioning of post-processing functions (e.g. the generation of 340 packet IDs) at the metering processes would be useful. Since QoS 341 monitoring can lead to a huge amount of measurement result data, it 342 would highly benefit from mechanisms to reduce the measurement data, 343 like aggregation of results and sampling. 345 Please note that not all requirements for QoS monitoring are covered 346 by the IPFIX requirements specified in the following sections. The 347 IPFIX requirements are targeted at per flow information including 348 summaries of per-packet properties for packets within a flow, but not 349 per-packet information itself. For example jitter measurement 350 requires timestamping each packet and reporting of all timestamps of 351 a flow, but the IPFIX requirements only cover timestamps of first and 352 last packet of a flow. 354 4. Distinguishing Flows 356 Packets are mapped to flows by evaluating their properties. Packets 357 with common properties are considered to belong to the same flow. A 358 packet showing at least one difference in the set of properties is 359 considered to belong to a different flow. 361 The following subsections list a set of properties which a metering 362 process MUST, SHOULD, or MAY be able to evaluate for mapping packets 363 to flows. Please note that requiring the ability to evaluate a 364 certain property does not imply that this property must be evaluated 365 for each packet. In other words, meeting the IPFIX requirements 366 means that the metering process in general must be able, via its 367 configuration, to somehow support to distinguish flows via all the 368 MUST fields, even if in certain circumstances/for certain 369 applications, only a subset of the MUST fields is needed and 370 effectively used to distinguish flows. 372 Which combination of properties is used for distinguishing flows and 373 how these properties are evaluated depends on the configuration of 374 the metering process. The configured choice of evaluated properties 375 strongly depends on the environment and purpose of the measurement 376 and on the information required by the collecting process. But 377 anyway, it MUST be ensured that a collecting process is able to 378 clearly identify for each received flow record which set of 379 properties was used for distinguishing this flow from other ones. 381 For specific deployments, only a subset of the REQUIRED properties 382 listed below can be used to distinguish flows, for example in order 383 to aggregate the flow records and reduce the number of flow records 384 exported. On the other hand, some other deployments will require 385 distinguishing flows by some extra parameters, like for example the 386 TTL field of the IP header or the BGP Autonomous System number 387 [RFC1771] of the IP destination address. 389 4.1. Interfaces 391 The metering process MUST be able to separate flows by the incoming 392 interface or by the outgoing interface or by both of them. 394 4.2. IP Header Fields 396 The metering process MUST, SHOULD, or MAY be able to separate flows 397 by the following fields of the IP header as indicated. 399 1. source IP address (MUST) 401 2. destination IP address (MUST) 403 3. protocol type (TCP,UDP,ICMP,...) (MUST) 405 4. IP version number (SHOULD) 406 This requirement only applies if the observation point is 407 located at a device that is supporting more than one version of 408 IP. 410 For source address and destination address, separating by full match 411 MUST be supported as well as separation by prefix match. 413 4.3. Transport Header Fields 415 The metering process MUST be able to separate flows by the port 416 numbers of the transport header in case of TCP or UDP being used as 417 transport protocol. Both, source and destination port number MUST be 418 supported for distinguishing flows, individually as well as in 419 combination. 421 4.4. MPLS Label 423 If the observation point is located at a device supporting 424 Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering 425 process MUST be able to separate flows by the MPLS label. 427 4.5. DiffServ Code Point 429 If the observation point is located at a device supporting 430 Differentiated Services (DiffServ) then the metering process MUST be 431 able to separate flows by the DiffServ Code Point (DSCP, see 432 [RFC2474]). 434 4.6. Header Compression and Encryption 436 If header compression or encryption is used, the metering process 437 might not be able to access all header fields. A metering process 438 MUST meet the requirements stated in this section 4 only for packets 439 that have the relevant header fields not compressed and not 440 encrypted. 442 5. Metering Process 444 The following are requirements for the metering process. All 445 measurements MUST be conducted from the point of view of the 446 observation point. 448 5.1. Reliability 450 The metering process MUST either be reliable or missing reliability 451 MUST be known and indicated. The metering process is reliable if each 452 packet passing the observation point is metered according to the 453 configuration of the metering process. If, e.g. due to some overload, 454 not all passing packets can be included into the metering process, 455 then the metering process MUST be able to detect this failure and to 456 report about it. 458 5.2. Sampling 460 Sampling describes the systematic or random selection of a subset of 461 elements (the sample) out of a set of elements (the parent 462 population). Usually the purpose of applying sampling techniques is 463 to estimate a parameter of the parent population by using only the 464 elements of the subset. Sampling techniques can be applied for 465 instance to select a subset of packets out of all packets of a flow 466 or to select a subset of flows out of all flows on a link. Sampling 467 methods differ in their sampling strategy (e.g. systematic or random) 468 and in the event that triggers the selection of an element. The 469 selection of one packet can for instance be triggered by its arrival 470 time (time-based sampling), by its position in the flow (count-based 471 sampling) or by the packet content (content-based sampling). 473 The metering process MAY support packet sampling. If sampling is 474 supported the sampling configuration MUST be well defined. The 475 sampling configuration includes the sampling method and all its 476 parameters. 478 If the sampling configuration is changed during operation, the new 479 sampling configuration with its parameters MUST be indicated to all 480 collecting processes receiving the affected flow records. Changing 481 the sampling configuration includes: adding a sampling function to 482 the metering process, removing a sampling function from the metering 483 process, change sampling method, and change sampling parameter(s). 485 In case of any change in the sampling configuration, all flow records 486 metered by the previous sampling configuration MUST be terminated and 487 exported according to the export configuration. The metering process 488 MUST NOT merge the flow records generated with the new sampling 489 configuration with the flow records generated with the previous 490 sampling configuration. 492 5.3. Overload Behavior 494 In case of an overload, for example lack of memory or processing 495 power, the metering process MAY change its behavior in order to cope 496 with the lack of resources. Possible reactions include: 498 - Reduce the number of flows to be metered. This can be achieved 499 by more coarse-grained flow measurement or by a restriction of 500 the flow records to a subset of the set of original ones. 502 - Start sampling packets before they are processed by the 503 metering process or - if sampling is already performed - reduce 504 the sampling frequency. 506 - Stop metering. 508 - Reducing the resource usage of competing processes on the same 509 device. Example: reducing the packet forwarding throughput 511 Overload behavior is not restricted to the four options listed above. 512 But in case the overload behavior induces a change of the metering 513 process behavior, the overload behavior MUST be clearly defined. 515 For some flows, the change of behavior might have an impact on the 516 data that would be stored in the associated flow records after the 517 change, for example if the packet classification is changed or the 518 sampling frequency. These flows MUST be considered as terminated and 519 the associated flow records MUST be exported separately from new ones 520 generated after the behavior change. The terminated flow records and 521 new ones generated after the behavior change MUST NOT be merged by 522 the metering process. The collecting process MUST be able to 523 distinguish the affected flow records generated before and after the 524 change of behavior. This requirement does not apply to flows and 525 associated flow records not affected by the change of metering 526 process behavior. 528 5.4. Timestamps 530 The metering process MUST be able to generate timestamps for the 531 first and the last observation of a packet of a flow at the 532 observation point. The timestamp resolution MUST be at least the one 533 of the sysUpTime [RFC1213], which is one centisecond. 535 5.5. Time Synchronization 537 It MUST be possible to synchronize timestamps generated by a metering 538 process with Coordinated Universal Time (UTC). 540 Note that the possibility of synchronizing timestamps of each single 541 metering process with UTC implies the possibility of synchronizing 542 timestamps generated by different metering processes. 544 Note that this does not necessarily imply that timestamps generated 545 by the metering process are UTC timestamps. For example, this 546 requirement can be met by using local system clock values as 547 timestamps and adding an additional timestamp when exporting a report 548 to a collecting process. Then the collecting process can synchronize 549 the timestamps by calculating the offset between UTC and the system 550 clock of the metering process. 552 5.6. Flow Expiration 554 The metering process MUST be able to detect flow expirations. A flow 555 is considered to be expired if no packet of this flow has been 556 observed for a given timeout interval. The metering process MAY 557 support means for detecting the expiration of a flow before a timeout 558 occurs, for example by detecting the FIN or RST bits in a TCP 559 connection. The procedure for detecting a flow expiration MUST be 560 clearly defined. 562 5.7. Multicast Flows 564 For multicast flows containing packets replicated to multiple output 565 interfaces, the metering process SHOULD be able to maintain discrete 566 flow records per different output interface. For example, the 567 metering process SHOULD be able to report an incoming multicast 568 packet that is replicated to four output interfaces in four different 569 flow records that differ by the output interface. 571 5.8. Packet Fragmentation 573 In case of IP packet fragmentation and depending on the 574 classification scheme, only the zero-offset fragment of a single 575 initial packet might contain sufficient information to classify the 576 packet. Note that this fragment should be the first one generated by 577 the router imposing the fragmentation [RFC791], but might not be the 578 first one observed by the IPFIX device, due reordering reasons. The 579 metering process MAY keep state of IP packet fragmentation in order 580 to map fragments that do not contain sufficient header information 581 correctly to flows. 583 5.9. Ignore Port Copy 585 The metering process MAY be able to ignore packets which are 586 generated by a port copy function acting at the device where the 587 observation point of a flow is located. 589 6. Data Export 591 The following are requirements for exporting flow records out of the 592 exporting process. Beside requirements on the data transfer, we 593 separate requirements concerning the information model from 594 requirements concerning the data model. Furthermore, we list 595 requirements on reporting times, notification on specific events, and 596 on anonymization of flow records. 598 6.1. Information Model 600 The information model for the flow information export is the list of 601 attributes of a flow to be contained in the report (including the 602 semantics of the attributes). 604 This section lists attributes an exporting process MUST, SHOULD or 605 MAY be able to report. This does not imply that each exported flow 606 record MUST contain all REQUIRED attributes. But it implies that it 607 MUST be possible to configure the exporting process in a way that the 608 information of all REQUIRED attributes can be transmitted from the 609 exporting process to the receiving collecting process(es) for each 610 exported flow. 612 In other words, meeting the IPFIX requirements means that the 613 exporting process in general must be able, via its configuration, to 614 somehow support to report all the MUST fields, even if in certain 615 circumstance or for certain applications, only a subset of the set of 616 all MUST fields is needed and effectively reported. 618 Beyond that, the exporting process might offer to report further 619 attributes not mentioned here. A particular flow record may contain 620 some of the "REQUIRED" attributes as well as some additional ones, 621 for example covering future technologies. 623 This document does not impose that the following attributes are 624 reported for every single flow record, especially for repetitive 625 attributes. For example, if the observation point is the incoming 626 packet stream at the IP interface with the ifIndex value 3, then this 627 observation point does not have to be exported as part of every 628 single flow record. Exporting it just once might give sufficient 629 information to the collecting process. 631 The exporting process MUST be able to report the following attributes 632 for each metered flow: 634 1. IP version number 635 This requirement only applies if the observation point is 636 located at a device supporting more than one version of IP. 637 2. source IP address 638 3. destination IP address 639 4. IP protocol type (TCP,UDP,ICMP,...) 640 5. if protocol type is TCP or UDP: source TCP/UDP port number 641 6. if protocol type is TCP or UDP: destination TCP/UDP port number 642 7. packet counter 643 If a packet is fragmented, each fragment is counted as an 644 individual packet. 645 8. byte counter 646 Which bytes of a packet are counted MUST be defined exactly. 647 9. type of service octet (in case of IPv4), traffic class 648 octet (in case of IPv6) 649 10. in case of IPv6: Flow Label 650 11. if MPLS is supported at the observation point: the top MPLS 651 label or the corresponding forwarding equivalence class (FEC, 652 [RFC3031]) bound to that label. The FEC is typically defined by 653 an IP prefix. 654 12. timestamp of the first packet of the flow 655 13. timestamp of the last packet of the flow 656 14. if sampling is used: sampling configuration 657 15. unique identifier of the observation point 658 16. unique identifier of the exporting process 660 The exporting process SHOULD be able to report the following 661 attributes for each metered flow: 663 17. if protocol type is ICMP: ICMP type and code 664 18. input interface (ifIndex) 665 This requirement does not apply if the observation point is 666 located at a probe device. 667 19. output interface (ifIndex) 668 This requirement does not apply if the observation point is 669 located at a probe device. 670 20. multicast replication factor 671 the number of outgoing packets originating from a single 672 incoming multicast packet. This is a dynamic property of 673 multicast flows, that may change over time. For unicast flows 674 it has the constant value 1. The computation of the factor MUST 675 be clearly defined. 677 The exporting process MAY be able to report the following attributes 678 for each metered flow: 680 21. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6) 681 22. IP header flags 682 23. TCP header flags 683 24. dropped packet counter at the observation point 684 If a packet is fragmented, each fragment MUST be counted as an 685 individual packet. 686 25. fragmented packet counter 687 counter of all packets for which the fragmented bit is set in 688 the IP header 689 26. next hop IP address 691 In addition, the exporting process MAY be able to report attributes 692 related to inter-autonomous system routing of a flow, for example by 693 reporting BGP Autonomous System numbers [RFC1771]. 695 6.2. Data Model 697 The data model describes how information is represented in flow 698 records. 700 The data model MUST be extensible for future attributes to be added. 701 Even if a set of attributes is fixed in the flow record, the data 702 model MUST provide a way of extending the record by configuration or 703 for certain implementations. 705 The data model used for exporting flow information MUST be flexible 706 concerning the flow attributes contained in flow records. A flexible 707 record format would offer the possibility of defining records in a 708 flexible (customizable) way regarding the number and type of 709 contained attributes. 711 The Data Model SHOULD be independent of the underlying transport 712 protocol, i.e. the data transfer. 714 6.3. Data Transfer 716 Requirements for the data transfer include reliability, congestion 717 awareness, and security requirements. For meeting these requirements 718 the exporting process can utilize existing security features provided 719 by the device hosting the process and/or provided by the transport 720 network. For example it can use existing security technologies for 721 authentication and encryption or it can rely on physical protection 722 of a separated network for transferring flow information. 724 6.3.1. Congestion Awareness 726 For the data transfer, a congestion aware protocol MUST be supported. 728 6.3.2. Reliability 730 Loss of flow records during the data transfer from the exporting 731 process to the collecting process MUST be indicated at the collecting 732 process. This indication MUST allow the collecting process to gauge 733 the number of flow records lost. Possible reasons for flow records 734 loss include but are not limited to: 736 1. Metering process limitations: lack of memory, processing power, 737 etc. These limitations are already covered in section 5.1. 739 2. Exporting process limitations: lack of memory, processing 740 power, etc. 742 3. Data transfer problems: packets that carry flow records sent 743 from the exporting process to the collecting process, are 744 dropped by the network. Examples are connection failures, 745 congestions in combination with an unreliable transport 746 protocol, etc. 748 4. Collecting process limitations: it may be experiencing 749 congestion and not able to buffer new flows records. 751 5. Operation and Maintenance: the collecting process is taken down 752 for maintenance or other administrative purposes. 754 Please note that if an unreliable transport protocol is used, 755 reliability can be provided by higher layers. If reliability is 756 provided by higher layers, only lack of overall reliability MUST be 757 indicated. For example reordering could be dealt with by adding a 758 sequence number to each packet. 760 The data transfer between exporting process and collecting process 761 MUST be open to reliability extensions including at least 762 - retransmission of lost flow records, 763 - detection of disconnection and fail-over, and 764 - acknowledgement of flow records by the collecting process. 765 This extensibility MAY be used to provide additional reliability. 767 6.3.3. Security 769 Confidentiality of flow specific data transferred from an exporting 770 process to a collecting process SHOULD be ensured. 772 Integrity of IPFIX data transferred from an exporting process to a 773 collecting process MUST be ensured. 775 Authenticity of IPFIX data transferred from an exporting process to a 776 collecting process MUST be ensured. 778 The security threats from which these 3 requirements are deducted are 779 explained in the "Security Considerations" (Section 10). 781 6.4. Push and Pull Mode Reporting 783 In general, there are two ways of deciding on reporting times: push 784 mode and pull mode. In push mode, the exporting process decides 785 without an external trigger when to send flow records. In pull mode, 786 sending flow records is triggered by an explicit request from a 787 collecting process. The exporting process MUST support push mode 788 reporting, it MAY support pull mode reporting. 790 6.5. Regular Reporting Interval 792 The exporting process SHOULD be capable of reporting measured traffic 793 data regularly according to a given interval length. 795 6.6. Notification on Specific Events 797 The exporting process MAY be capable of sending notifications to a 798 collecting process, if a specific event occurs. Such an event can be 799 for instance the arrival of the first packet of a new flow, or the 800 termination of a flow after flow timeout. 802 6.7. Anonymization 804 The exporting process MAY be capable of anonymizing source and 805 destination IP addresses in flow data before exporting them. It MAY 806 support anonymization of port numbers and other fields. Please note 807 that anonymization is not originally an application requirement, but 808 derived from general requirements for treatment of measured traffic 809 data within a network. 811 When anonymized flow data is exported, this MUST be clearly indicated 812 to all receiving collecting processes, such that they can distinguish 813 anonymized data from non-anonymized data. 815 7. Configuration 817 7.1. Configuration of the Metering Process 819 The metering process MUST provide a way of configuring traffic 820 measurement. The following parameters of the metering process SHOULD 821 be configurable: 823 1. specification of the observation point 824 e.g. an interface or a list of interfaces to be monitored. 825 2. specifications of flows to be metered 826 3. flow timeouts 828 The following parameters MAY be configurable: 830 4. sampling method and parameters, if feature is supported 831 5. overload behavior, if feature is supported 833 7.2. Configuration of the Exporting Process 835 The exporting process MUST provide a way of configuring the data 836 export. The following parameters of the exporting process SHOULD be 837 configurable: 839 1. reporting data format 840 Specifying the reporting data format MUST include a selection 841 of attributes to be reported for each flow. 842 2. the collecting process(es) to which flows are reported 843 3. the reporting interval 844 This requirement only applies if the exporting process supports 845 reporting in regular intervals. 846 4. notifications to be sent to the collecting process(es) 847 This requirement only applies if the exporting process supports 848 notifications. 849 5. flow anonymization 850 This requirement only applies if the exporting process supports 851 flow anonymization. 853 If configuration is done remotely, security SHOULD be provided for 854 the configuration process covering confidentiality, integrity and 855 authenticity. The means used for remote configuration are out of the 856 scope of this document. 858 8. General Requirements 860 8.1. Openness 862 IPFIX specifications SHOULD be open to future technologies. This 863 includes extensibility of configuration of the metering process and 864 the exporting process. 866 Openness is also required concerning the extensibility of the data 867 model, as stated in section 6.2. 869 8.2. Scalability 871 Data collection from hundreds of different exporting processes MUST 872 be supported. The collecting process MUST be able to distinguish 873 several hundred exporting processes by their identifiers. 875 8.3. Several Collecting Processes 877 The exporting process MAY be able to export flow information to more 878 than one collecting process. If an exporting process is able to 879 export flow records to multiple collecting processes then it MUST be 880 able to ensure that the flow records can be identified so that 881 duplicates can be detected between different collecting processes and 882 double counting problems can be avoided. 884 9. Special Device Considerations 886 This document intends to avoid constraining the architecture of 887 probes, routers, and other devices hosting observation points, 888 metering processes, exporting processes, and/or collecting processes. 889 It can be expected that typically observation point, metering 890 process, and exporting process are co-located at a single device. 891 However, the requirements defined in this document do not exclude 892 devices that derive from this configuration. Figure 2 shows some 893 examples. 895 +---+ +-----+ +---------+ +---------+ 896 | E-+-> | E--+-> | E----+-> <-+--E E--+-> 897 | | | | | | | / \ | | | | | 898 | M | | M | | M M | | M M | 899 | | | | /|\ | | /|\ /|\ | | /|\ /|\ | 900 | O | | OOO | | OOO OOO | | OOO OOO | 901 +---+ +-----+ +---------+ +---------+ 902 Probe Basic Complex Multiple 903 Router Router Exporting 904 Processes 906 +---+ +---+ +---+ 907 | E-+-> | E-+-> | E-+------------->---+ 908 | | | | | | | | | +---+ +-+-----+ 909 +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> 910 | | | | | | | | | | +---+ +-+-----+ 911 +-+-+ +-+-+ | O | | M | | E-+->---+ 912 | | | | +---+ | | | | | | 913 | M | +-+-+ | O | | M | 914 | | | | | | +---+ | | | +-----+ 915 | O | | O | | O | ->-+-C-E-+-> 916 +---+ +---+ +---+ +-----+ 918 Protocol Remote Concentrator Proxy 919 Converter Observation 921 Figure 2: IPFIX-related Devices 923 All examples are composed of one or more of the following elements: 924 observation point (O), metering process (M), exporting process (E), 925 collecting process (C). The observation points shown in the figure 926 are always the most fine-granular ones supported by the respective 927 device. 929 A very simple device is a probe. A typical probe contains a single 930 observation point, a single metering process, and a single exporting 931 process. 933 A basic router extends this structure by multiple observation points. 934 Here, the observation point of a particular flow may be one of the 935 displayed most fine-granular observation points, but also it may be a 936 set of them. 938 A more complex router may host more than one metering process, for 939 example one per line card. Please note that here, the observation 940 point of a single flow cannot exceed the set of most fine-granular 941 observation points linked to a single metering process, because only 942 the metering process can merge packets observed at different fine- 943 granular observation points to a joint flow. An observation point 944 containing all most fine-granular observation points of this router 945 is not possible with this structure. Alternatively, a complex router 946 may host different exporting processes for flow records generated by 947 different metering processes. 949 A protocol converter makes use of a metering process that can be 950 accessed only by another protocol than the one defined for IPFIX, for 951 example the SNMP and the Meter MIB module [RFC2720]. Then the 952 exporting process receives flow record from a remote metering process 953 and exports these records using the IPFIX protocol. Please note, that 954 this document does not make any particular assumption on how metering 955 processes and export processes exchange information, as long as all 956 individual requirements for these processes are met. Also the 957 locations of metering processes are not of any relevance for this 958 document (in contrast to the locations of observation points and the 959 exporting processes). 961 In the example of remote packet observation in Figure 2 the metering 962 process and the observation point are not co-located. Packet header 963 captured at an observation point may be exported as raw data to a 964 device hosting metering process and exporting process. Again, this 965 document does not make any particular assumption on how packet 966 headers are transferred from observation points to metering 967 processes, as long as all requirements for the metering processes are 968 met. 970 An intermediate structure between protocol converter and remote 971 observation (not shown in the Figure) would be a split metering 972 process, for example performing timestamping and sampling at the 973 device hosting the observation point and performing packet 974 classification at another device hosting the exporting process. 976 A concentrator receives flow records via the IPFIX protocol, merges 977 them into more aggregated flow records, and exports them again using 978 the IPFIX protocol. Please note, that for the final flow records the 979 resulting observation point may be a superset of the more fine- 980 granular observation points at the first level devices. The metering 981 process of the final flow records is composed by the (partial) 982 metering processes at the first level devices and the partial 983 metering process at the concentrator. 985 Finally, a very simple IPFIX-related device is a proxy. It just 986 receives flow records using the IPFIX protocol and sends them further 987 using the same protocol. A proxy might be useful for traversing 988 firewalls or other gateways. 990 10. Security Considerations 992 An IPFIX protocol must be capable to transport data over the public 993 Internet. Therefore it cannot be excluded that an attacker captures 994 or modifies packets or inserts additional packets. 996 This section describes security requirements for IPFIX. Like other 997 requirements, the security requirements differ among the considered 998 applications. The incentive to modify collected data for accounting 999 or intrusion detection for instance is usually higher than the 1000 incentive to change data collected for traffic profiling. A detailed 1001 list of the required security features per application can be found 1002 in the appendix. 1004 The suggestion of concrete solutions for achieving the required 1005 security properties should be part of an IPFIX architecture and 1006 protocol. It is out of scope of this document. Also methods for 1007 remote configuration of the metering processes and exporting 1008 processes are out of scope. Therefore, threats that are caused by 1009 data exchange for remote configuration are not considered here. 1011 The following potential security hazards for an IPFIX protocol have 1012 been identified: disclosure of IP flow information, forgery of flow 1013 records, and Denial of Service (DoS) attacks. 1015 10.1. Disclosure of Flow Information Data 1017 The content of data exchanged by an IPFIX protocol (for example IPFIX 1018 flow records) should be kept confidential between the involved 1019 parties (exporting process and collecting process). Observation of 1020 IPFIX flow records gives an attacker information about the active 1021 flows in the network, communication endpoints and traffic patterns. 1022 This information cannot only be used to spy out user behavior but 1023 also to plan and conceal future attacks. Therefore, the requirements 1024 specified in section 6.3.3. include confidentiality of the 1025 transferred data. This can be achieved for instance by encryption. 1027 10.2. Forgery of Flow Records 1029 If flow records are used in accounting and security applications, 1030 there are potentially strong incentives to forge exported IPFIX flow 1031 records (for example to save money or prevent the detection of an 1032 attack). This can be done either by altering flow records on the path 1033 or by injecting forged flow records that pretend to be originated by 1034 the original exporting process. In order to make an IPFIX protocol 1035 resistant against such attacks, authentication and integrity must be 1036 provided, as specified in section 6.3.3. 1038 Special caution is required if security applications rely on flow 1039 measurements. With forged flow records it is possible to trick on 1040 security applications. It is for instance possible to pretend that a 1041 DoS attack happens without even launching a real attack. 1043 10.3. Denial of Service (DoS) Attacks 1045 DoS attacks on routers or other middleboxes that have the IPFIX 1046 protocol implemented would also affect the IPFIX protocol and impair 1047 the sending of IPFIX records. Nevertheless, since such hazards are 1048 not induced specifically by the IPFIX protocol the prevention of such 1049 attacks is out of scope of this document. 1051 However, IPFIX itself also causes potential hazards for DoS attacks. 1052 All processes that expect the reception of traffic can be target of a 1053 DoS attack. With the exporting process this is only the case if it 1054 supports the pull mode (which can be an optional feature of the IPFIX 1055 protocol according to this document). The collecting process always 1056 expects data and therefore can be flooded by flow records. 1058 11. Acknowledgments 1060 Many thanks Georg Carle for contributing to the application analysis, 1061 to K.C. Norseth for several fine-tunings, and to a lot of further 1062 people on the mailing list providing valuable comments and 1063 suggestions including Nevil Brownlee, Carter Bullard, Paul Calato, 1064 Ram Gopal, Tal Givoly, Jeff Meyer, Reinaldo Penno, Sonia Panchen, 1065 Simon Leinen, David Plonka, Ganesh Sadasivan, Kevin Zhang, and many 1066 more. 1068 12. Normative References 1070 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 1071 Switching Architecture", RFC 3031, January 2001. 1073 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 1074 Differentiated Services Field (DS Field) in the IPv4 and 1075 IPv6 Headers", RFC 2474, December 1998. 1077 [RFC791] J. Postel. "Internet Protocol", RFC791, September 1981. 1079 13. Informative References 1081 [RFC3234] B. Carpenter, "Middleboxes: taxonomy and issues", RFC 3234, 1082 February 2002. 1084 [RFC2119] S. Bradner "Key words for use in RFCs to Indicate 1085 Requirement Levels", RFC 2119, March 1997. 1087 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: 1088 A Transport Protocol for Real-Time Applications", RFC 1889, 1089 January 1996. 1091 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 1092 "Requirements for Traffic Engineering Over MPLS", RFC 2702, 1093 September 1999. 1095 [RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1096 RFC 1771, March 1995. 1098 [RFC1213] K. McCloghrie, M. Rose. "Management Information Base for 1099 Network Management of TCP/IP-based internets: MIB-II", RFC 1100 1213, March 1991. 1102 [RFC2720] N. Brownlee. "Traffic Flow Measurement: Meter MIB", RFC 1103 2720, October 1999. 1105 14. Authors' Addresses 1107 Juergen Quittek 1108 NEC Europe Ltd., Network Laboratories 1109 Kurfuersten-Anlage 36 1110 69115 Heidelberg 1111 Germany 1113 Phone: +49 6221 90511 15 1114 EMail: quittek@ccrle.nec.de 1115 Tanja Zseby 1116 Fraunhofer Institute for Open Communication Systems (FOKUS) 1117 Kaiserin-Augusta-Allee 31 1118 10589 Berlin 1119 Germany 1121 Phone: +49 30 3463 7153 1122 Email: zseby@fokus.fhg.de 1124 Benoit Claise 1125 Cisco Systems 1126 De Kleetlaan 6a b1 1127 1831 Diegem 1128 Belgium 1130 Phone: +32 2 704 5622 1131 Email: bclaise@cisco.com 1133 Sebastian Zander 1134 Fraunhofer Institute for Open Communication Systems (FOKUS) 1135 Kaiserin-Augusta-Allee 31 1136 10589 Berlin 1137 Germany 1139 Phone: +49 30 3463 7287 1140 Email: zander@fokus.fhg.de 1142 15. Full Copyright Statement 1144 Copyright (C) The Internet Society (2001). All Rights Reserved. 1146 This document and translations of it may be copied and furnished to 1147 others, and derivative works that comment on or otherwise explain it 1148 or assist in its implementation may be prepared, copied, published 1149 and distributed, in whole or in part, without restriction of any 1150 kind, provided that the above copyright notice and this paragraph are 1151 included on all such copies and derivative works. However, this 1152 document itself may not be modified in any way, such as by removing 1153 the copyright notice or references to the Internet Society or other 1154 Internet organizations, except as needed for the purpose of 1155 developing Internet standards in which case the procedures for 1156 copyrights defined in the Internet Standards process must be 1157 followed, or as required to translate it into languages other than 1158 English. 1160 The limited permissions granted above are perpetual and will not be 1161 revoked by the Internet Society or its successors or assigns. 1163 This document and the information contained herein is provided on an 1164 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1165 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1166 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1167 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1168 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1170 Appendix: Derivation of Requirements from Applications 1172 The following table documents, how the requirements stated in 1173 sections 3-7 are derived from requirements of the applications listed 1174 in section 2. 1176 Used abbreviations: 1177 M = MUST 1178 S = SHOULD 1179 O = MAY (OPTIONAL) 1180 - = DONT CARE 1182 -----------------------------------------------------------------------. 1183 IPFIX | 1184 ----------------------------------------------------------------. | 1185 E: QoS Monitoring | | 1186 ----------------------------------------------------------. | | 1187 D: Attack/Intrusion Detection | | | 1188 ----------------------------------------------------. | | | 1189 C: Traffic Engineering | | | | 1190 ----------------------------------------------. | | | | 1191 B: Traffic Profiling | | | | | 1192 ----------------------------------------. | | | | | 1193 A: Usage-based Accounting | | | | | | 1194 ----------------------------------. | | | | | | 1195 | | | | | | | 1196 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1197 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1198 | 4. | DISTINGUISHING FLOWS | 1199 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1200 | 4. | Combination of | M | M | M | M | M | M | 1201 | | required attributes | | | | | | | 1202 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1203 | 4.1. | in/out IF | S | M | M | S | S | M | 1204 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1205 | 4.2. | src/dst address | M | M | M | M | M | M | 1206 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1207 | 4.2. | Masking of IP adresses | M | M | M | M | M | M | 1208 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1209 | 4.2. | transport protocol | M | M | - | M | M | M | 1210 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1211 | 4.2. | version field | - | S | S | O | O | S | 1212 | | | | | (b) | | | | 1213 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1214 | 4.3. | src/dst port | M | M | - | M | M | M | 1215 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1216 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1217 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1218 | 4.4. | MPLS label (a) | S | S | M | O | S | M | 1219 | | | | | (c) | | | | 1220 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1221 | 4.5. | DSCP (a) | M | S | M | O | M | M | 1222 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1223 | 5. | METERING PROCESS | 1224 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1225 | 5.1. | Reliability | M | S | S | S | S | | 1226 |-------+-------------------------+-----+-----+-----+-----+-----+ M | 1227 | 5.1. | Indication of | - | M | M | M | M | | 1228 | | missing reliability | | | | | | | 1229 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1230 | 5.2. | Sampling (g) | O | O | O | O | O | O | 1231 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1232 | 5.3. | Overload Behavior | O | O | O | O | O | O | 1233 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1234 | 5.4. | Timestamps | M | O | O | S | M | M | 1235 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1236 | 5.5. | Time synchronization | M | S | S | S | M | M | 1237 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1238 | 5.6. | Flow timeout | M | S | - | O | O | M | 1239 | | | (d) | | | | | | 1240 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1241 | 5.7. | Multicast flows | S | O | O | O | S | S | 1242 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1243 | 5.9. | Ignore port copy | O | O | O | O | O | O | 1244 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1245 | 6. | DATA EXPORT | 1246 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1247 | 6.1. | INFORMATION MODEL | 1248 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1249 | 6.1. | IP Version | - | M | M | O | O | M | 1250 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1251 | 6.1. | src/dst address | M | M | M | M | M | M | 1252 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1253 | 6.1. | transport protocol | M | M | - | M | M | M | 1254 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1255 | 6.1. | src/dst port | M | M | - | M | M | M | 1256 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1257 | 6.1. | Packet counter (h) | S | M | M | S | S | M | 1258 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1259 | 6.1. | Byte counter | M | M | M | S | S | M | 1260 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1261 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1262 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1263 | 6.1. | Dropped Packet | O | M | M | S | M | M | 1264 | | Counter (h,i) | | | | | | | 1265 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1266 | 6.1. | ToS Byte | M | S | M | O | M | M | 1267 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1268 | 6.1. | Flow Label | M | S | M | O | M | M | 1269 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1270 | 6.1. | BGP AS# | - | S | M | - | - | M | 1271 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1272 | 6.1. | MPLS label (a) | S | S | M | O | S | M | 1273 | | | | | (c) | | | | 1274 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1275 | 6.1. | DSCP (a) | M | S | M | O | M | M | 1276 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1277 | 6.1. | Timestamps for | M | O | O | S | S | M | 1278 | | first/last packet | | | | | | | 1279 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1280 | 6.1. | Sampling configuration | M | M | M | M | M | M | 1281 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1282 | 6.1. | observation point | M | M | M | M | M | M | 1283 | | identifier | | | | | | | 1284 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1285 | 6.1. | export process | M | M | M | M | M | M | 1286 | | identifier | | | | | | | 1287 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1288 | 6.1. | TTL | O | O | O | O | O | O | 1289 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1290 | 6.1. | IP header flags | - | O | O | O | O | O | 1291 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1292 | 6.1. | TCP header flags | - | O | O | O | - | O | 1293 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1294 | 6.1. | Fragment counter | - | O | O | O | O | O | 1295 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1296 | 6.1. | Multicast | O | S | S | - | S | S | 1297 | | replication factor | | | | | | | 1298 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1299 | 6.2. | DATA MODEL | 1300 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1301 | 6.2. | Flexibility | M | S | M | M | M | M | 1302 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1303 | 6.2. | Extensibility | M | S | M | M | M | M | 1304 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1305 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1306 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1307 | 6.3. | DATA TRANSFER | 1308 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1309 | 6.3.1.| Congestion aware | M | M | M | M | M | M | 1310 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1311 | 6.3.2.| Reliability | M | S | S | S | S | M | 1312 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1313 | 6.3.3.| Confidentiality | S | S | S | S | S | S | 1314 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1315 | 6.3.4.| Integrity | M | M | M | M | M | M | 1316 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1317 | 6.3.5.| Authenticity | M | M | M | M | M | M | 1318 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1319 | 6.4. | REPORTING TIMES | 1320 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1321 | 6.4. | Push mode | M | O | O | M | S | M | 1322 | | | | (e) | (e) | |(e,f)| | 1323 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1324 | 6.4. | Pull mode | O | O | O | O | O | O | 1325 | | | | (e) | (e) | | (e) | | 1326 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1327 | 6.4.1.| Regular Interval | S | S | S | S | S | S | 1328 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1329 | 6.6. | Notifications | O | O | O | O | O | O | 1330 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1331 | 6.7. | Anonymization | O | O | O | O | O | O | 1332 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1333 | 7. | CONFIGURATION | 1334 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1335 | 7. | Config Measurement | M | M | M | M | M | M | 1336 | | & Data Export | | | | | | | 1337 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1338 | 7. | Config Observation Point| S | S | S | S | S | S | 1339 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1340 | 7. | Config Flow | S | S | S | S | S | S | 1341 | | Specifications | | | | | | | 1342 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1343 | 7. | Config Flow Timeouts | S | S | S | S | O | S | 1344 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1345 | 7. | Config Sampling | O | O | O | O | O | O | 1346 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1347 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1348 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1349 | 7. | Config Report | S | S | S | S | S | S | 1350 | | Data Format | | | | | | | 1351 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1352 | 7. | Config | O | O | O | O | O | O | 1353 | | Notifications | | | | | | | 1354 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1355 | 7. | Config Anonymization | O | O | O | O | O | O | 1356 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1357 | 8. | GENERAL REQUIREMENTS | 1358 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1359 | 8.1. | Openness | S | S | S | S | S | S | 1360 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1361 | 8.2. | Scalability: | | | | | | | 1362 | | data collection | M | S | M | O | S | M | 1363 | | from hundreds of | | | | | | | 1364 | | measurement devices | | | | | | | 1365 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1366 | 8.3. | Several Collectors | O | O | O | O | O | O | 1367 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1369 Remarks: 1370 (a) If feature is supported. 1371 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 1372 So we tended to make this a MUST. Nevertheless, a SHOULD seems 1373 to be sufficient to perform most TE tasks and allows us to have 1374 a SHOULD for IPFIX instead of a MUST. 1375 (c) For TE in an MPLS network the label is essential. Therefore a 1376 MUST is given here leading to a MUST in IPFIX. 1377 (d) Precise time-based accounting requires reaction to a flow 1378 timeout. 1379 (e) Either push or pull has to be supported. 1380 (f) Required, in order to immediately report drop indications for 1381 SLA validation. 1382 (g) If sampling is supported the methods and parameters MUST be 1383 well defined. 1384 (h) If a packet is fragmented, each fragment is counted as an 1385 individual packet. 1386 (i) Only if measurement is done on data path i.e. has access to 1387 forwarding decision.