idnits 2.17.1 draft-ietf-ipfix-reqs-04.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 Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 184 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 1059 has weird spacing: '...for the purpo...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Overload behavior is not restricted to the four options listed above. But in case the overload behavior has an impact on the metering process or the exporting process, the overload behavior MUST be clearly defined and the collector MUST be able to distinguish the flow records exported before and after the metering process behavior change: In case of any change of the meter's behavior, all flow records metered by the previous behavior MUST be terminated and exported according to the configuration of the exporting process. The metering process MUST not merge the flow records generated with the new behavior with the flow records generated with the previous behavior. -- 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 (July 2002) is 7953 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) == Missing Reference: 'RFC 2026' is mentioned on line 26, but not defined == Unused Reference: 'RFC2026' is defined on line 966, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3234 ** Downref: Normative reference to an Informational RFC: RFC 2702 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft J. Quittek 2 Document: draft-ietf-ipfix-reqs-04.txt NEC Europe Ltd. 3 Expires: January 2003 T. Zseby 4 FhI FOKUS 5 B. Claise 6 Cisco Systems 7 S. Zander 8 G. Carle 9 FhI FOKUS 10 K.C. Norseth 11 Consultant 13 July 2002 15 Requirements for IP Flow Information Export 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 23 working documents of the Internet Engineering Task Force (IETF), its 24 areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Distribution of this document is unlimited. 40 Copyright Notice 42 Copyright (C) The Internet Society (2001). All Rights Reserved. 44 Abstract 46 This memo defines requirements for the export of measured IP flow 47 information out of routers, traffic measurement probes and 48 middleboxes. 50 Table of Contents 52 1 Introduction ................................................. 2 53 2 Terminology .................................................. 2 54 2.1 IP Traffic Flow ............................................ 2 55 2.2 Observation Point .......................................... 3 56 2.3 Metering Process ........................................... 3 57 2.4 Flow Record ................................................ 4 58 2.5 Exporting Process .......................................... 4 59 2.6 Collecting Process ......................................... 4 60 3 Applications Requiring IP Flow Information Export ............ 4 61 3.1 Usage-based Accounting ..................................... 5 62 3.2 Traffic Profiling .......................................... 5 63 3.3 Attack/Intrusion Detection ................................. 6 64 3.4 QoS Monitoring ............................................. 6 65 4 Distinguishing Flows ......................................... 7 66 4.1 Interfaces ................................................. 7 67 4.2 IP Header Fields ........................................... 8 68 4.3 Transport Header Fields .................................... 8 69 4.4 MPLS Label ................................................. 8 70 4.5 DiffServ Code Point ........................................ 8 71 4.6 Header Compression and Encryption .......................... 8 72 5 Metering Process ............................................. 9 73 5.1 Reliability ................................................ 9 74 5.2 Sampling ................................................... 9 75 5.3 Overload Behavior .......................................... 10 76 5.4 Timestamps ................................................. 10 77 5.5 Time Synchronization ....................................... 10 78 5.6 Timeout .................................................... 10 79 5.7 Ignore Port Copy ........................................... 11 80 6 Data Export .................................................. 11 81 6.1 Information Model .......................................... 11 82 6.2 Data Model ................................................. 13 83 6.3 Data Transfer .............................................. 13 84 6.3.1 Congestion Awareness ..................................... 14 85 6.3.2 Reliability .............................................. 14 86 6.3.3 Security ................................................. 14 87 6.4 Regular Reporting Interval ................................. 14 88 6.5 Notification on Specific Events ............................ 14 89 6.6 Anonymization .............................................. 15 90 7 Configuration ................................................ 15 91 7.1 Configuration of the Metering Process ...................... 15 92 7.2 Configuration of the Exporting Process ..................... 15 93 8 General Requirements ......................................... 16 94 8.1 Openness ................................................... 16 95 ........................................................... 16 96 8.3 Several Collectors ......................................... 16 97 9 Special Device Considerations ................................ 16 98 10 Security Considerations ..................................... 19 99 10.1 Disclosure of Flow Information Data ....................... 19 100 10.2 Forgery of Flow Records ................................... 19 101 10.3 Denial of Service (DoS) Attacks ........................... 20 102 11 Acknowledgments ............................................. 20 103 12 References .................................................. 20 104 13 Authors' Addresses .......................................... 21 105 14 Full Copyright Statement .................................... 22 106 Appendix: Derivation of Requirements from Applications ........ 23 108 1. Introduction 110 There are several applications that require flow-based IP traffic 111 measurements. Such measurements could be performed by a router while 112 forwarding the traffic, by a middlebox [RFC3234], or by a traffic 113 measurement probe attached to a line or a monitored port. This memo 114 defines requirements for exporting traffic flow information out of 115 these boxes for further processing by applications located on other 116 devices. In section 3, a selection of such applications is presented. 117 The following sections list requirements derived from these 118 applications. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Terminology 126 The following terminology is used within this document: 128 2.1. IP Traffic Flow 130 There are several definitions of the term 'flow' being used by the 131 Internet community. Within this document we use the following one: 133 A flow is defined as a set of IP packets passing an observation point 134 in the network during a certain time interval. All packets belonging 135 to a particular flow have a set of common properties. Each property 136 is defined as the result of applying a function to the values of: 138 1. one or more packet header field (e.g. destination IP address) 140 2. one or more properties of the packet itself (e.g. packet 141 length) 143 3. one or more of fields derived from packet treatment (e.g. AS 144 number) 146 A packet is defined to belong to a flow if it completely satisfies 147 all the defined properties of the flow. 149 This definition covers the range from a flow containing all packets 150 observed at a network interface to a flow consisting of just a single 151 packet between two applications with a specific sequence number. 152 Please note that the flow definition does not necessarily match a 153 general application-level end-to-end stream. However, an application 154 may derive properties of application-level streams by processing 155 measured flow data. 157 2.2. Observation Point 159 The observation point is a location in the network where IP packets 160 can be observed. Examples are a line to which a probe is attached, a 161 shared medium, such as an Ethernet-based LAN, a single port of a 162 router, or a set of interfaces (physical or logical) of a router. 164 Please note that a coarse-grained observation point of one flow, for 165 example a line card with several ports, may be the superset of 166 several more fine-grained observation points of some other flows, for 167 example the individual ports of the line card. 169 2.3. Metering Process 171 The metering process generates flow records. Input to the process are 172 IP packet headers observed at an observation point. The metering 173 process consists of a set of functions that includes packet header 174 capturing, timestamping, sampling, classifying, and maintaining flow 175 records. 177 The maintenance of flow records may include creating new records, 178 updating existing ones, computing flow statistics, deriving further 179 flow properties, detecting flow expiration, passing flows record to 180 the exporting process, and deleting flow records. 182 The sampling function and the classifying function may be applied 183 more than once with different parameters. Figure 1 shows the sequence 184 in which the functions are applied. Sampling is not illustrated in 185 the figure, it may be applied before any other function. 187 packet header capturing 188 | 189 timestamping 190 | 191 v 192 +----->+ 193 | | 194 | classifying 195 | | 196 +------+ 197 | 198 maintaining flow records 199 | 200 v 202 Figure 1: Functions of the metering process 204 2.4. Flow Record 206 A flow record contains information about a specific flow that was 207 metered at an observation point. A flow record contains measured 208 properties of the flow (e.g. the total number of bytes of all packets 209 of the flow) and usually also characteristic properties of the flow 210 (e.g. source IP address). 212 2.5. Exporting Process 214 The exporting process sends flow records to one or more collectors. 215 The flow records are generated by one or more metering processes. 217 2.6. Collecting Process 219 The collecting process receives flow records from one or more 220 exporting processes. The collecting process might store received flow 221 records or further process them, but these actions are out of the 222 scope of this document. 224 3. Applications Requiring IP Flow Information Export 226 This section describes a selection of applications requiring IP flow 227 information export. Because requirements for flow export listed in 228 further sections below are derived from these applications, their 229 selection is crucial. The goal of this requirements document is not 230 to cover all possible applications with all their flow export 231 requirements, but to cover applications which are considered to be of 232 significant importance in today's or future IP networks, and for 233 which requirements can be met with reasonable technical effort. 235 Please note, that the described applications can have a large number 236 of differing implementations. Requirement details or the weighting of 237 requirements could differ for specific implementations. Therefore we 238 derive the requirements from the general functionality of the 239 selected applications. 241 The list of applications should lead to a better understanding of the 242 requirements which is particularly important when designing or 243 implementing traffic flow measuring functions. A detailed overview of 244 which requirement was derived from which application(s) is given in 245 the appendix. 247 3.1. Usage-based Accounting 249 Several new business models for selling IP service and IP-based 250 services are currently under investigation. Beyond flat rate services 251 which do not need accounting, accounting for these models can be 252 based on time or volume. Accounting data can serve as input for 253 billing systems. Accounting can be performed per user or per user 254 group, it can be performed just for basic IP service or individually 255 per high-level service and/or per content type delivered. For 256 advanced/future services, accounting may also be performed per class 257 of service, per application, per time of day, per used (label 258 switched) path, etc. 260 3.2. Traffic Profiling 262 Traffic profiling is the process of characterizing IP flows and flow 263 aggregates by using a model that represents key parameters of the 264 flows such as flow duration, volume, time and burstiness. It is a 265 prerequisite for network planning, network dimensioning, trend 266 analysis, developing business models, and other activities. It 267 heavily depends on the particular traffic profiling objective(s) what 268 statistics and accuracy are required from the measurements. Typical 269 information needed for traffic profiling is the distribution of used 270 services and protocols in the network, the amount of packets of a 271 specific type (e.g. percentage of IPv6 packets) and specific flow 272 profiles. 274 Since objectives for traffic profiling can vary, this application 275 requires a high flexibility of the measurement infrastructure, 276 especially regarding the options for measurement configuration and 277 packet classification. 279 Traffic Engineering (TE) comprises methods for measurement, modeling, 280 characterization and control of a network. The goal of TE is the 281 optimization of network resource utilization and traffic performance 282 [RFC2702]. Since control and administrative reaction to measurement 283 results requires access to the involved network nodes, TE mechanisms 284 and the required measurement function usually are performed within 285 one administrative domain. Typical parameters required for TE are 286 link utilization, load between specific network nodes, number, size 287 and entry/exit points of the active flows and routing information. 289 3.3. Attack/Intrusion Detection 291 Capturing of flow information plays an important role for network 292 security, both for detection of security violation, and for 293 subsequent defense. In case of a Denial of Service (DOS) attack, flow 294 monitoring can allow detection of unusual load situations or 295 suspicious flows. In a second step, flow analysis can be performed in 296 order to gather information about the attacking flows, and for 297 deriving a defense strategy. 299 Intrusion detection is a potentially more demanding application which 300 would not only look at specific characteristics of flows, but that 301 may also use a stateful packet flow analysis for detecting specific, 302 suspicious activities, or unusually frequent activities. Such 303 activities may be characterized by specific communication patterns, 304 detectable by characteristic sequences of certain packet types. 306 3.4. QoS Monitoring 308 QoS monitoring is the non-intrusive (passive) measurement of quality 309 parameters for single flows or traffic aggregates. In contrast to 310 intrusive (active) measurements, non-intrusive measurements utilize 311 the existing traffic in the network for QoS analysis. Since no test 312 traffic is sent, non-intrusive measurements can only be applied in 313 situations where the traffic of interest is already present in the 314 network. One example application is the validation of QoS parameters 315 negotiated in a service level specification (SLS). 317 Non-intrusive measurements cannot provide the kind of controllable 318 experiments that can be achieved with active measurements. On the 319 other hand non-intrusive measurements do not suffer from undesired 320 side effects caused by sending test traffic (e.g. additional load, 321 potential differences in treatment of test traffic and real customer 322 traffic). 324 QoS monitoring often requires the correlation of data from multiple 325 measurement instances (e.g. for measuring one-way metrics). This 326 requires proper clock synchronization of the involved measurement 327 instances. For some measurements packet events at the different 328 measurement points must be correlated. For this, the provisioning of 329 post-processing functions (e.g. the generation of packet IDs) at the 330 measurement instances would be useful. Furthermore, QoS monitoring 331 can lead to a huge amount of measurement result data. Therefore it 332 would highly benefit from mechanisms to reduce the measurement data, 333 like aggregation of results and sampling. 335 Please note that not all requirements for QoS monitoring are covered 336 by the IPFIX requirements specified in the following sections. The 337 IPFIX requirements are targeted at per flow information including 338 summaries of per-packet properties for packets within a flow, but not 339 per-packet information itself. For example jitter measurement 340 requires timestamping each packet and reporting of all timestamps of 341 a flow, but the IPFIX requirements only cover timestamps of first and 342 last packet of a flow. 344 4. Distinguishing Flows 346 Packets are mapped to flows by evaluating their properties. Packets 347 with common properties are considered to belong to the same flow. A 348 packet showing at least one difference in the set of properties is 349 considered to belong to a different flow. 351 The following subsections list a set of properties which a metering 352 process MUST, SHOULD, or MAY be able to evaluate for mapping packets 353 to flows. Please note that requiring the ability to evaluate a 354 certain property does not imply that this property must be evaluated 355 for each packet. 357 In other words, meeting the IPFIX requirements means that the 358 metering process in general must be able, via its configuration, to 359 somehow support to distinguish flows via all the MUST fields, even if 360 in certain circumstance/for certain applications, only a subset of 361 the MUST fields is needed and only a subset of the MUST fields is 362 effectively used to distinguish flows. 364 Which combination of properties is used for distinguishing a flow in 365 a particular measurement and how these properties are evaluated 366 depends on the configuration of the metering process. The configured 367 choice of evaluated properties strongly depends on the environment 368 and purpose of the measurement and on the information required by the 369 collector. 371 For specific deployments, only a subset of the REQUIRED properties 372 listed below can be used to distinguish flows, for example in order 373 to aggregate the flow records and reduce the number of flow records 374 exported. On the other hand, some other deployments will require 375 distinguishing flows by some extra parameters, like for example the 376 TTL field of the IP header or the BGP Autonomous Systems. 378 4.1. Interfaces 380 The metering process MUST be able to separate flows by the incoming 381 interface or by the outgoing interface or by both of them. 383 4.2. IP Header Fields 385 The metering process MUST, SHOULD, or MAY be able to separate flows 386 by the following fields of the IP header as indicated. 388 1. source IP address (MUST) 390 2. destination IP address (MUST) 392 3. protocol type (TCP,UDP,ICMP,...) (MUST) 394 4. IP version number (SHOULD) 395 This requirement only applies if the the observation point is 396 located at a device that is supporting more than one version of 397 IP. 399 For source address and destination address, separating by full match 400 MUST be supported as well as separation by a partial match (for 401 example subnet masking). 403 4.3. Transport Header Fields 405 The metering process MUST be able to separate flows by the port 406 numbers of the transport header in case of TCP or UDP being used as 407 transport protocol. Both, source and destination port number MUST be 408 supported for distinguishing flows, individually as well as in 409 combination. 411 4.4. MPLS Label 413 If the observation point is located at a device supporting 414 Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering 415 process MUST be able to separate flows by the MPLS label. 417 4.5. DiffServ Code Point 419 If the observation point is located at a device supporting 420 Differentiated Services (DiffServ) then the metering process MUST be 421 able to separate flows by the DiffServ Code Point (DSCP, see 422 [RFC2474]). 424 4.6. Header Compression and Encryption 426 If header compression or encryption is used, the metering process 427 might not be able to access all header fields. For packets with 428 compressed or encrypted headers, the requirements stated in this 429 section 4 MUST be met for observation points at end points of header 430 compression or of packet encryption, but they do not need to be met 431 for observation points between the end points. 433 5. Metering Process 435 The following are requirements for the metering process. All 436 measurements MUST be conducted from the point of view of the 437 observation point. 439 5.1. Reliability 441 The metering process MUST either be reliable or missing reliability 442 MUST be known and indicated. The metering process is reliable if each 443 packet passing the observation point is measured according to the 444 configuration of the metering process. If, e.g. due to some overload, 445 not all passing packets can be included into the metering process, 446 then the metering process MUST be able to detect this failure and to 447 report about it. 449 5.2. Sampling 451 Sampling describes the systematic or random selection of a subset of 452 elements (the sample) out of a set of elements (the parent 453 population). Usually the purpose of applying sampling techniques is 454 to estimate a parameter of the parent population by using only the 455 elements of the subset. Sampling techniques can be applied for 456 instance to select a subset of packets out of all packets of a flow 457 or to select a subset of flows out of all flows on a link. Sampling 458 methods differ in their sampling strategy (e.g. systematic or random) 459 and in the event that triggers the selection of an element. The 460 selection of one packet can for instance be triggered by its arrival 461 time (time-based sampling), by its position in the flow (count-based 462 sampling) or by the packet content (content-based sampling). 464 The metering process MAY support measuring traffic by packet 465 sampling. If sampling is supported the sampling configuration MUST be 466 well defined. The sampling configuration includes the sampling method 467 and all its parameters. 469 If the sampling configuration is changed during operation, the new 470 sampling configuration with its parameters MUST be indicated to all 471 collectors receiving the affected flow records. Changing the sampling 472 configuration includes: start sampling, stop sampling, change 473 sampling method, and change sampling parameter. 475 In case of any change in the sampling configuration, all flow records 476 metered by the previous sampling configuration MUST be terminated and 477 exported according to the export configuration. The metering process 478 MUST NOT merge the flow records generated with the new sampling 479 configuration with the flow records generated with the previous 480 sampling configuration. 482 5.3. Overload Behavior 484 In case of an overload, for example lack of memory or processing 485 power, the metering process MAY change its behavior in order to cope 486 with the lack of resources. Possible reactions include: 488 - Reduce the number of flows to be measured. This can be achieved 489 by more coarse grained flow measurement or by a restriction of 490 the flow accounts to a subset of the set of original ones. 492 - Switch to sampling packets before they are processed by the 493 metering process or - if sampling is already performed - reduce 494 the sampling rate. 496 - Stop metering. 498 - Reducing the resource usage of competing processes on the same 499 device. Example: reducing the packet forwarding throughput 501 Overload behavior is not restricted to the four options listed above. 502 But in case the overload behavior has an impact on the metering 503 process or the exporting process, the overload behavior MUST be 504 clearly defined and the collector MUST be able to distinguish the 505 flow records exported before and after the metering process behavior 506 change: In case of any change of the meter's behavior, all flow 507 records metered by the previous behavior MUST be terminated and 508 exported according to the configuration of the exporting process. The 509 metering process MUST not merge the flow records generated with the 510 new behavior with the flow records generated with the previous 511 behavior. 513 5.4. Timestamps 515 The metering process MUST be able to generate timestamps for the 516 first and the last observed packet of a flow. The timestamp 517 resolution MUST be at least the one of the sysUpTime [RFC1213], which 518 is one centisecond. 520 5.5. Time Synchronization 522 Metering processes and collectors SHOULD be time-synchronized with 523 each other. Using NTP or GPS are possible ways of achieving this. 524 However selecting a method for time synchronization is not in the 525 scope of this document. 527 5.6. Timeout 529 The metering process MUST be able to detect flow timeouts. A flow is 530 considered to be timed out if no packet of this flow has been 531 observed for a given timeout interval. The metering process MAY 532 support means for detecting the end of a flow before a timeout 533 occurs, for example by detecting the FIN or RST bits in a TCP 534 connection. The procedure for detecting a flow timeout MUST be 535 clearly defined. 537 5.7. Ignore Port Copy 539 The metering process MAY be able to ignore packets which are 540 generated by a port copy function acting at the device where the 541 observation point of a flow is located. 543 6. Data Export 545 The following are requirements for exporting measured flow data out 546 of the exporter. Beside requirements on the data transfer, we 547 separate requirements concerning the information model from 548 requirements concerning the data model. Furthermore, we list 549 requirements on reporting times and events and on anonymization of 550 records. 552 6.1. Information Model 554 The information model for the flow information export is the list of 555 attributes of a flow to be contained in the report (including the 556 semantics of the attributes). 558 This section lists attributes an exporting process MUST or MAY be 559 able to report. This does not imply that each exported flow records 560 MUST contain all REQUIRED attributes. But it implies that it MUST be 561 possible to configure the exporting process in a way that the 562 information contained in all of the REQUIRED attributes of each 563 exported flow is transmitted from the exporting process to the 564 receiving collecting process(es). 566 In other words, meeting the IPFIX requirements means that the 567 exporting process in general must be able, via its configuration, to 568 somehow support to report all the MUST fields, even if in certain 569 circumstance or for certain applications, only a subset of the MUST 570 fields is needed and only a subset of the MUST fields is effectively 571 reported. 573 Beyond that, the exporting process might offer to report further 574 attributes not mentioned here. A particular flow record may contain 575 some of the "REQUIRED" attributes as well as some additional ones, 576 for example covering future technologies. 578 This document does not impose that the following attributes are 579 reported for every single flow record, especially for repetitive 580 attributes. For example, if the observation point is the incoming 581 packet stream at the IP interface with the ifIndex value 3, then this 582 observation point does not have to be exported as part of every 583 single flow record. Exporting it just once might give sufficient 584 information to the collecting process. 586 The exporting process MUST be able to report the following attributes 587 for each measured flow: 589 1. IP version number 590 This requirement only applies if the observation point is 591 located at a device supporting more than one version of IP. 592 2. source IP address 593 3. destination IP address 594 4. IP protocol type (TCP,UDP,ICMP,...) 595 5. source TCP/UDP port number 596 6. destination TCP/UDP port number 597 7. input interface (ifIndex) 598 This requirement does not apply if the observation point is 599 located at a probe device. 600 8. output interface (ifIndex) 601 This requirement does not apply if the observation point is 602 located at a probe device. This requirement does not apply in 603 case of multicast flow records. 604 9. packet counter 605 If a packet is fragmented, each fragment is counted as an 606 individual packet. 607 10. byte counter 608 Which bytes of a packet are counted MUST be defined exactly. 609 11. in case of IPv4: Type of Service 610 10. in case of IPv6: Flow Label 611 11. if BGP is supported at the observation point: BGP AS number 612 12. if MPLS is supported at the observation point: MPLS label 613 13. if DiffServ is supported at the observation point: DSCP 614 14. timestamp of the first packet of the flow 615 15. timestamp of the last packet of the flow 616 16. if sampling is used: sampling configuration 617 17. unique identifier of the observation point 618 18. unique identifier of the exporting process 620 The exporting process MAY be able to report the following attributes 621 for each measured flow: 623 20. Time To Live 624 21. IP header flags 625 22. TCP header flags 626 23. dropped packet counter at the observation point 627 If a packet is fragmented, each fragment MUST be counted as an 628 individual packet. 629 individual packet. 630 24. fragmented packet counter 631 counter of all packets for which the fragmented bit is set in 632 the IP header 633 25. multicast replication factor 634 the number of outgoing packets originating from a single 635 incoming multicast packet 636 26. list of output interfaces for a multicast flow 638 6.2. Data Model 640 The data model describes how information is represented in flow 641 records. 643 The data model MUST be extensible for future attributes to be added. 644 Even if a set of attributes is fixed in the flow record, the data 645 model MUST provide a way of extending the record by configuration or 646 for certain implementations. 648 The data model used for exporting flow information MAY be flexible 649 concerning the flow attributes contained in flow records. A flexible 650 record format would offer the possibility of defining records in a 651 flexible (customizable) way regarding the number and type of 652 contained attributes. 654 The Data Model SHOULD be independent of the underlying transport 655 protocol, i.e. the data transfer. 657 6.3. Data Transfer 659 Requirements for the data transfer include reliability and security 660 requirements. For meeting these requirements the exporting process 661 can utilize existing security features provided by the device hosting 662 the process and or provided by the transport network. For example it 663 can use existing security technologies for authentication and 664 encryption or it can rely on physical protection of a separated 665 network for transferring flow information. 667 6.3.1. Congestion Awareness 669 For the data transfer, a congestion aware protocol MUST be supported. 671 6.3.2. Reliability 673 Absence of reliability of the data transfer, for example caused by 674 loss or reordering of packets containing flow information, MUST be 675 indicated. 677 Please note that if an unreliable transport protocol is used, 678 reliability can be provided by higher layers. In such a case only 679 lack of overall reliability MUST be indicated. For example reordering 680 could be dealt with by adding a sequence number to each packet. 682 6.3.3. Security 684 Confidentiality of flow specific data transferred from an exporting 685 process to a collecting process SHOULD be ensured. 687 Integrity of flow specific data transferred from an exporting process 688 to a collecting process MUST be ensured. 690 Authenticity of flow specific data transferred from an exporting 691 process to a collecting process MUST be ensured. 693 The security threats from which these 3 requirements are deducted are 694 explained in the "Security Considerations" (Section 10). sh 2 "Push 695 and Pull Mode Reporting" 697 In general, there are two ways of deciding on reporting times: push 698 mode and pull mode. In push mode, the exporting process decides 699 without an external trigger when to send a report on measured flows. 700 In pull mode, sending a report is triggered by an explicit request 701 from a collector. The exporting process MUST support push mode 702 reporting, it MAY support pull mode reporting. 704 6.4. Regular Reporting Interval 706 The exporting process SHOULD be capable of reporting measured traffic 707 data regularly according to a given interval length. 709 6.5. Notification on Specific Events 711 The exporting process MAY be capable of sending notifications to a 712 collecting process, if a specific event occurs. Such an event can be 713 for instance the arrival of the first packet of a new flow, or the 714 termination of a flow after flow timeout. 716 6.6. Anonymization 718 The exporting process MAY be capable of anonymizing source and 719 destination IP addresses in flow data before exporting them. It MAY 720 support anonymization of port numbers and other fields. Please note 721 that anonymization is not originally an application requirement, but 722 derived from general requirements for treatment of traffic within a 723 network. 725 7. Configuration 727 7.1. Configuration of the Metering Process 729 The metering process MUST provide a way of configuring traffic 730 measurement. The following parameters of the metering process SHOULD 731 be configurable: 733 1. specification of the observation point 734 e.g. an interface or a list of interfaces to be monitored. 735 2. specifications of flows to be metered 736 3. flow timeouts 738 The following parameters MAY be configurable: 740 4. sampling method and parameters, if feature is supported 741 5. overload behavior 743 7.2. Configuration of the Exporting Process 745 The exporting process MUST provide a way of configuring the data 746 export. The following parameters of the exporting process SHOULD be 747 configurable: 749 1. reporting data format 750 Specifying the reporting data format SHOULD include a selection 751 of attributes to be reported for each flow. 752 2. the collecting process(es) to which flows are reported 753 3. notifications to be sent to the collecting process(es) 754 4. flow anonymization 755 Only applicable if the exporting process supports flow 756 anonymization. 758 If configuration is done remotely, security SHOULD be provided for 759 the configuration process covering confidentiality, integrity and 760 authenticity. The means used for remote configuration are out of the 761 scope of this document. 763 8. General Requirements 765 8.1. Openness 767 IPFIX specifications SHOULD be open to future technologies. This 768 includes extensibility of configuration of measurement and reporting. 770 Openness is also required concerning the extensibility of the data 771 model, as stated in section 6.2. 773 8.2. Scalability Concerning the Number of Exporting Processes 775 Data collection from hundreds of different exporting processes MUST 776 be supported. The collecting process MUST be able to distinguish 777 several hundred exporting processes by their identifiers. 779 8.3. Several Collectors 781 The exporting process MAY be able to export flow information to more 782 than one collecting process. 784 9. Special Device Considerations 786 This document intends to avoid constraining the architecture of 787 probes, routers, and other devices hosting observation points, 788 metering processes, exporting processes, and/or collecting processes. 789 It can be expected that typically observation point, metering 790 process, and exporting process are co-located at a single device. 791 However, the requirements defined in this document do not exclude 792 devices that derive from this configuration. Figure 2 shows some 793 examples. 795 +---+ +-----+ +---------+ +---------+ 796 | E-+-> | E--+-> | E----+-> <-+--E E--+-> 797 | | | | | | | / \ | | | | | 798 | M | | M | | M M | | M M | 799 | | | | /|\ | | /|\ /|\ | | /|\ /|\ | 800 | O | | OOO | | OOO OOO | | OOO OOO | 801 +---+ +-----+ +---------+ +---------+ 802 Probe Basic Complex Multiple 803 Router Router Exporters 805 +---+ +---+ +---+ 806 | E-+-> | E-+-> | E-+------------->---+ 807 | | | | | | | | | +---+ +-+-----+ 808 +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> 809 | | | | | | | | | | +---+ +-+-----+ 810 +-+-+ +-+-+ | O | | M | | E-+->---+ 811 | | | | +---+ | | | | | | 812 | M | +-+-+ | O | | M | 813 | | | | | | +---+ | | | +-----+ 814 | O | | O | | O | ->-+-C-E-+-> 815 +---+ +---+ +---+ +-----+ 817 Protocol Remote Concentrator Proxy 818 Converter Observation 820 Figure 2: IPFIX-related Devices 822 All examples are composed of one or more of the following elements: 823 observation point (O), full or partial metering process (M), 824 exporting process (E), collecting process (C). The observation points 825 shown in the figure are always the most fine-granular ones supported 826 by the respective device. 828 A very simple device is a probe. A typical probe contains a single 829 observation point, a single metering process, and a single exporting 830 process. 832 A basic router extends this structure by multiple observation points. 833 Here, the observation point of a flow may be one of the displayed 834 most fine-granular observation points, but also it may be a set of 835 them. 837 A more complex router may host more than one metering process, for 838 example one per line card. Please note that here, the observation 839 point of a single flow cannot exceed the set of most fine-granular 840 observation points linked to a single metering process, because only 841 the metering process can merge packets observed at different fine- 842 granular observation points to a joint flow. An observation point 843 containing all most fine-granular observation points of this router 844 is not possible with this structure. 846 Alternatively, a complex router may host different exporting 847 processes for flow records generated by different metering processes. 849 A protocol converter makes use of a metering process that can be 850 accessed only by another protocol than the one defined for IPFIX, for 851 example the SNMP and the Meter MIB module [RFC2720]. Then the 852 exporter receives flow record from a remote metering process and 853 exports these records using the IPFIX protocol. 855 Please note that this document does not make any particular 856 assumption on how metering processes and a export processes exchange 857 information, as long as all individual requirements for these 858 processes are met. Also the locations of metering processes are not 859 of any relevance for this document (in contrast to the locations of 860 observation points and the exporting processes). 862 In the example of remote packet observation in Figure 2 the metering 863 process and the observation point are not co-located. Packet header 864 captured at an observation point may be exported as raw data to a 865 device hosting metering process and exporting process. Again, this 866 document does not make any particular assumption on how packet 867 headers are transfered from observation points to metering processes, 868 as long as all requirements for the metering processes are met. 870 An intermediate structure between protocol converter and remote 871 observation (not shown in the Figure) would be a split metering 872 process, for example performing timestamping and sampling at the 873 device hosting the observation point and performing packet 874 classification at another device hosting the exporting process. 876 A concentrator receives flow records via the IPFIX protocol, merges 877 them into higher aggregated flows and exports the resulting flows 878 again using the IPFIX protocol. Please note that for the final flow 879 records the observation point potentially includes all most fine- 880 granular observation points of all first level devices. The metering 881 process of the final flow records is composed by the (partial) 882 metering processes at the first level devices and the partial 883 metering process at the concentrator. 885 Finally, a very simple IPFIX-related device is a proxy. It just 886 receives flow records using the IPFIX protocol and sends them further 887 using the same protocol. A proxy might be useful for traversing 888 firewalls or other gateways. 890 10. Security Considerations 892 An IPFIX protocol must be capable to transport data over the public 893 Internet. Therefore it cannot be excluded that an attacker captures 894 or modifies packets or inserts additional packets. 896 This section describes security requirements for IPFIX. Like other 897 requirements, the security requirements differ among the considered 898 applications. The incentive to modify collected data for accounting 899 or intrusion detection for instance is usually higher than the 900 incentive to change data collected for traffic profiling. A detailed 901 list of the required security features per application can be found 902 in the appendix. 904 The suggestion of concrete solutions for achieving the required 905 security properties should be part of an IPFIX architecture and 906 protocol is out of scope of this document. Also methods for remote 907 configuration of the metering processes and exporting processes are 908 out of scope. Therefore, threats that are caused by data exchange for 909 remote configuration are not considered here. 911 The following potential security hazards for an IPFIX protocol can be 912 identified: disclosure of IP flow information, forgery of flow 913 records, and Denial of Service (DoS) attacks. 915 10.1. Disclosure of Flow Information Data 917 The content of data exchanged by an IPFIX protocol (for example IPFIX 918 flow records) should be kept confidential between the involved 919 parties (exporting process and collecting process). Observation of 920 IPFIX flow records gives an attacker information about the active 921 flows in the network, communication endpoints and traffic patterns. 922 This information cannot only be used to spy out user behavior but 923 also to plan and conceal future attacks. Therefore, the requirements 924 specified in section 6.3.3. include confidentiality of the 925 transferred data. This can be achieved for instance by encryption. 927 10.2. Forgery of Flow Records 929 If flow records are used in accounting and security applications, 930 there are potentially strong incentives to forge exported IPFIX flow 931 records (for example to save money or prevent the detection of an 932 attack). This can be done either by altering flow records on the path 933 or by injecting forged flow records that pretend to be originated by 934 the original exporting process. In order to make an IPFIX protocol 935 resistant against such attacks, authentication and integrity must be 936 provided, as specified in section 6.3.3. 938 Special caution is required if security applications rely on flow 939 measurements. With forged flow records it is possible to trick on 940 security applications. It is for instance possible to pretend that a 941 DoS attack happens without even launching a real attack. 943 10.3. Denial of Service (DoS) Attacks 945 DoS attacks on routers or other middleboxes that have the IPFIX 946 protocol implemented would also affect the IPFIX protocol and impair 947 the sending of IPFIX records. Nevertheless, since such hazards are 948 not induced specifically by the IPFIX protocol the prevention of such 949 attacks is out of scope of this document. 951 Nevertheless IPFIX itself also causes potential hazards for DoS 952 attacks. All processes that expect the reception of traffic can be 953 target of a DoS attack. With the exporting process this is only the 954 case if it supports the pull mode (which can be an optional feature 955 of the future IPFIX protocol according to this document). The 956 collecting process always expects data and therefore can be flooded 957 by forged flow records. 959 11. Acknowledgments 961 We like to thank all the people contributing to the requirements 962 discussion on the mailing list for a lot of valuable comments. 964 12. References 966 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 967 RFC 2026, October 1996. 969 [RFC3234] B. Carpenter, "Middleboxes: taxonomy and issues", RFC 3234, 970 February 2002. 972 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 973 Requirement Levels", RFC 2119, March 1997. 975 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 976 "Requirements for Traffic Engineering Over MPLS", RFC 2702, 977 September 1999. 979 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 980 Switching Architecture", RFC 3031, January 2001. 982 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 983 Differentiated Services Field (DS Field) in the IPv4 and 984 IPv6 Headers", RFC 2474, December 1998. 986 [RFC1213] K. McCloghrie, M. Rose. "Management Information Base for 987 Network Management of TCP/IP-based internets: MIB-II", RFC 988 1213, March 1991. 990 [RFC2720] N. Brownlee. "Traffic Flow Measurement: Meter MIB", RFC 991 2720, October 1999. 993 13. Authors' Addresses 995 Juergen Quittek 996 NEC Europe Ltd., Network Laboratories 997 Adenauerplatz 6 998 69115 Heidelberg 999 Germany 1001 Phone: +49 6221 90511-15 1002 EMail: quittek@ccrle.nec.de 1004 Tanja Zseby 1005 Fraunhofer Institute for Open Communication Systems (FOKUS) 1006 Kaiserin-Augusta-Allee 31 1007 10589 Berlin 1008 Germany 1010 Phone: +49 30 3463 7153 1011 Email: zseby@fokus.fhg.de 1013 Benoit Claise 1014 Cisco Systems 1015 De Kleetlaan 6a b1 1016 1831 Diegem 1017 Belgium 1019 Phone: +32 2 704 5622 1020 Email: bclaise@cisco.com 1022 Sebastian Zander 1023 Fraunhofer Institute for Open Communication Systems (FOKUS) 1024 Kaiserin-Augusta-Allee 31 1025 10589 Berlin 1026 Germany 1028 Phone: +49 30 3463 7287 1029 Email: zander@fokus.fhg.de 1030 Georg Carle 1031 Fraunhofer Institute for Open Communication Systems (FOKUS) 1032 Kaiserin-Augusta-Allee 31 1033 10589 Berlin 1034 Germany 1036 Phone: +49 30 3463 7149 1037 Email: carle@fokus.fhg.de 1039 K.C. Norseth 1040 Consultant 1041 934 S. Palos Verdes Dr. 1042 Kaysville, Utah 84037 USA 1044 Phone: 801.546.3316 1045 Email: kcn@norseth.com 1047 14. Full Copyright Statement 1049 Copyright (C) The Internet Society (2001). All Rights Reserved. 1051 This document and translations of it may be copied and furnished to 1052 others, and derivative works that comment on or otherwise explain it 1053 or assist in its implementation may be prepared, copied, published 1054 and distributed, in whole or in part, without restriction of any 1055 kind, provided that the above copyright notice and this paragraph are 1056 included on all such copies and derivative works. However, this 1057 document itself may not be modified in any way, such as by removing 1058 the copyright notice or references to the Internet Society or other 1059 Internet organizations, except as needed for the purpose of 1060 developing Internet standards in which case the procedures for 1061 copyrights defined in the Internet Standards process must be 1062 followed, or as required to translate it into languages other than 1063 English. 1065 The limited permissions granted above are perpetual and will not be 1066 revoked by the Internet Society or its successors or assigns. 1068 This document and the information contained herein is provided on an 1069 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1070 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1071 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1072 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1073 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1075 Appendix: Derivation of Requirements from Applications 1077 The following table documents, how the requirements stated in 1078 sections 3-7 are derived from requirements of the applications listed 1079 in section 2. 1081 Used abbreviations: 1082 M = MUST 1083 S = SHOULD 1084 O = MAY (OPTIONAL) 1085 - = DONT CARE 1087 -----------------------------------------------------------------------. 1088 IPFIX | 1089 ----------------------------------------------------------------. | 1090 E: QoS Monitoring | | 1091 ----------------------------------------------------------. | | 1092 D: Attack/Intrusion Detection | | | 1093 ----------------------------------------------------. | | | 1094 C: Traffic Engineering | | | | 1095 ----------------------------------------------. | | | | 1096 B: Traffic Profiling | | | | | 1097 ----------------------------------------. | | | | | 1098 A: Usage-based Accounting | | | | | | 1099 ----------------------------------. | | | | | | 1100 | | | | | | | 1101 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1102 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1103 | 4. | DISTINGUISHING FLOWS | 1104 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1105 | 4. | Combination of | M | M | M | M | M | M | 1106 | | required attributes | | | | | | | 1107 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1108 | 4.1. | in/out IF | S | M | M | S | S | M | 1109 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1110 | 4.2. | src/dst address | M | M | M | M | M | M | 1111 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1112 | 4.2. | Masking of IP adresses | M | M | M | M | M | M | 1113 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1114 | 4.2. | transport protocol | M | M | - | M | M | M | 1115 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1116 | 4.2. | version field | - | S | S | O | O | S | 1117 | | | | | (b) | | | | 1118 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1119 | 4.3. | src/dst port | M | M | - | M | M | M | 1120 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1121 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1122 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1123 | 4.4. | MPLS label (a) | S | S | M | O | S | M | 1124 | | | | | (c) | | | | 1125 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1126 | 4.5. | DSCP (a) | M | S | M | O | M | M | 1127 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1128 | 5. | METERING PROCESS | 1129 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1130 | 5.1. | Reliability | M | S | S | S | S | | 1131 |-------+-------------------------+-----+-----+-----+-----+-----+ M | 1132 | 5.1. | Indication of | - | M | M | M | M | | 1133 | | missing reliability | | | | | | | 1134 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1135 | 5.2. | Sampling (g) | O | O | O | O | O | O | 1136 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1137 | 5.3. | Overload Behavior | O | O | O | O | O | O | 1138 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1139 | 5.4. | Timestamps | M | O | O | S | M | M | 1140 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1141 | 5.5. | Time synchronization | S | S | S | S | S | S | 1142 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1143 | 5.6. | Flow timeout | M | S | - | O | O | M | 1144 | | | (d) | | | | | | 1145 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1146 | 5.7. | Ignore port copy | O | O | O | O | O | O | 1147 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1148 | 6. | DATA EXPORT | 1149 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1150 | 6.1. | INFORMATION MODEL | 1151 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1152 | 6.1. | IP Version | - | M | M | O | O | M | 1153 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1154 | 6.1. | src/dst address | M | M | M | M | M | M | 1155 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1156 | 6.1. | transport protocol | M | M | - | M | M | M | 1157 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1158 | 6.1. | src/dst port | M | M | - | M | M | M | 1159 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1160 | 6.1. | Packet counter (h) | S | M | M | S | S | M | 1161 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1162 | 6.1. | Byte counter | M | M | M | S | S | M | 1163 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1164 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1165 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1166 | 6.1. | Dropped Packet | O | M | M | S | M | M | 1167 | | Counter (h,i) | | | | | | | 1168 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1169 | 6.1. | ToS Byte | M | S | M | O | M | M | 1170 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1171 | 6.1. | Flow Label | M | S | M | O | M | M | 1172 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1173 | 6.1. | BGP AS# | - | S | M | - | - | M | 1174 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1175 | 6.1. | MPLS label (a) | S | S | M | O | S | M | 1176 | | | | | (c) | | | | 1177 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1178 | 6.1. | DSCP (a) | M | S | M | O | M | M | 1179 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1180 | 6.1. | Timestamps for | M | O | O | S | S | M | 1181 | | first/last packet | | | | | | | 1182 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1183 | 6.1. | Sampling configuration | M | M | M | M | M | M | 1184 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1185 | 6.1. | observation point | M | M | M | M | M | M | 1186 | | identifier | | | | | | | 1187 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1188 | 6.1. | export process | M | M | M | M | M | M | 1189 | | identifier | | | | | | | 1190 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1191 | 6.1. | TTL | O | O | O | O | O | O | 1192 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1193 | 6.1. | IP header flags | - | O | O | O | O | O | 1194 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1195 | 6.1. | TCP header flags | - | O | O | O | - | O | 1196 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1197 | 6.1. | Fragment counter | - | O | O | O | O | O | 1198 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1199 | 6.1. | Multicast | O | O | O | - | - | O | 1200 | | replication factor | | | | | | | 1201 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1202 | 6.2. | DATA MODEL | 1203 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1204 | 6.2. | Flexibility | O | O | O | O | O | O | 1205 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1206 | 6.2. | Extensibility | M | M | M | M | M | M | 1207 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1208 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1209 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1210 | 6.3. | DATA TRANSFER | 1211 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1212 | 6.3.1.| Congestion aware | M | M | M | M | M | M | 1213 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1214 | 6.3.2.| Reliability | M | S | S | S | S | M | 1215 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1216 | 6.3.3.| Confidentiality | S | S | S | S | S | S | 1217 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1218 | 6.3.4.| Integrity | M | M | M | M | M | M | 1219 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1220 | 6.3.5.| Authenticity | M | M | M | M | M | M | 1221 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1222 | 6.4. | REPORTING TIMES | 1223 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1224 | 6.4. | Push mode | M | O | O | M | S | M | 1225 | | | | (e) | (e) | |(e,f)| | 1226 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1227 | 6.4. | Pull mode | O | O | O | O | O | O | 1228 | | | | (e) | (e) | | (e) | | 1229 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1230 | 6.4.1.| Regular Interval | S | S | S | S | S | S | 1231 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1232 | 6.6. | Notifications | O | O | O | O | O | O | 1233 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1234 | 6.7. | Anonymization | O | O | O | O | O | O | 1235 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1236 | 7. | CONFIGURATION | 1237 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1238 | 7. | Config Measurement | M | M | M | M | M | M | 1239 | | & Data Export | | | | | | | 1240 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1241 | 7. | Config Observation Point| S | S | S | S | S | S | 1242 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1243 | 7. | Config Flow | S | S | S | S | S | S | 1244 | | Specifications | | | | | | | 1245 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1246 | 7. | Config Flow Timeouts | S | S | S | S | O | S | 1247 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1248 | 7. | Config Sampling | O | O | O | O | O | O | 1249 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1250 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1251 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1252 | 7. | Config Report | S | S | S | S | S | S | 1253 | | Data Format | | | | | | | 1254 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1255 | 7. | Config | O | O | O | O | O | O | 1256 | | Notifications | | | | | | | 1257 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1258 | 7. | Config Anonymization | O | O | O | O | O | O | 1259 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1260 | 8. | GENERAL REQUIREMENTS | 1261 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1262 | 8.1. | Openness | S | S | S | S | S | S | 1263 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1264 | 8.2. | Scalability: | | | | | | | 1265 | | data collection | M | S | M | O | S | M | 1266 | | from hundreds of | | | | | | | 1267 | | measurement devices | | | | | | | 1268 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1269 | 8.3. | Several Collectors | O | O | O | O | O | O | 1270 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1272 Remarks: 1273 (a) If feature is supported. 1274 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 1275 So we tended to make this a MUST. Nevertheless, a SHOULD seems 1276 to be sufficient to perform most TE tasks and allows us to have 1277 a SHOULD for IPFIX instead of a MUST. 1278 (c) For TE in an MPLS network the label is essential. Therefore a 1279 MUST is given here leading to a MUST in IPFIX. 1280 (d) Precise time-based accounting requires reaction to a flow 1281 timeout. 1282 (e) Either push or pull has to be supported. 1283 (f) Required, in order to immediately report drop indications for 1284 SLA validation. 1285 (g) If sampling is supported the methods and parameters MUST be 1286 well defined. 1287 (h) If a packet is fragmented, each fragment is counted as an 1288 individual packet. 1289 (i) Only if measurement is done on data path i.e. has access to 1290 forwarding decision.