idnits 2.17.1 draft-ietf-ipfix-reqs-08.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 1148 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 (January 2003) is 7772 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-08.txt NEC Europe Ltd. 3 Category: Informational T. Zseby 4 Expires: July 2003 Fraunhofer FOKUS 5 B. Claise 6 Cisco Systems 7 S. Zander 8 Fraunhofer FOKUS 10 January 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 ................................................. 2 50 2 Terminology .................................................. 2 51 2.1 IP Traffic Flow ............................................ 2 52 2.2 Observation Point .......................................... 3 53 2.3 Metering Process ........................................... 3 54 2.4 Flow Record ................................................ 4 55 2.5 Exporting Process .......................................... 4 56 2.6 Collecting Process ......................................... 4 57 3 Applications Requiring IP Flow Information Export ............ 4 58 3.1 Usage-based Accounting ..................................... 5 59 3.2 Traffic Profiling .......................................... 5 60 3.3 Traffic Engineering ........................................ 5 61 3.4 Attack/Intrusion Detection ................................. 6 62 3.5 QoS Monitoring ............................................. 6 63 4 Distinguishing Flows ......................................... 7 64 4.1 Interfaces ................................................. 7 65 4.2 IP Header Fields ........................................... 8 66 4.3 Transport Header Fields .................................... 8 67 4.4 MPLS Label ................................................. 8 68 4.5 DiffServ Code Point ........................................ 8 69 4.6 Header Compression and Encryption .......................... 8 70 5 Metering Process ............................................. 9 71 5.1 Reliability ................................................ 9 72 5.2 Sampling ................................................... 9 73 5.3 Overload Behavior .......................................... 10 74 5.4 Timestamps ................................................. 10 75 5.5 Time Synchronization ....................................... 10 76 5.6 Flow Expiration ............................................ 11 77 5.7 Multicast Flows ............................................ 11 78 5.8 Packet Fragmentation ....................................... 11 79 5.9 Ignore Port Copy ........................................... 11 80 6 Data Export .................................................. 12 81 6.1 Information Model .......................................... 12 82 6.2 Data Model ................................................. 14 83 6.3 Data Transfer .............................................. 14 84 6.3.1 Congestion Awareness ..................................... 14 85 6.3.2 Reliability .............................................. 14 86 6.3.3 Security ................................................. 15 87 6.4 Push and Pull Mode Reporting ............................... 15 88 6.5 Regular Reporting Interval ................................. 16 89 6.6 Notification on Specific Events ............................ 16 90 6.7 Anonymization .............................................. 16 91 7 Configuration ................................................ 16 92 7.1 Configuration of the Metering Process ...................... 16 93 7.2 Configuration of the Exporting Process ..................... 16 94 8 General Requirements ......................................... 17 95 8.1 Openness ................................................... 17 96 8.2 Scalability ................................................ 17 97 8.3 Several Collecting Processes ............................... 17 98 9 Special Device Considerations ................................ 17 99 10 Security Considerations ..................................... 20 100 10.1 Disclosure of Flow Information Data ....................... 20 101 10.2 Forgery of Flow Records ................................... 20 102 10.3 Denial of Service (DoS) Attacks ........................... 21 103 11 Acknowledgments ............................................. 21 104 12 Normative References ........................................ 21 105 13 Informative References ...................................... 21 106 14 Authors' Addresses .......................................... 22 107 15 Full Copyright Statement .................................... 23 108 Appendix: Derivation of Requirements from Applications ......... 24 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 applicaton 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 (SLS). Note that 323 passive/active measurement is also referred to as non- 324 intrusive/intrusive measurement or as measurement of 325 observed/synthetic traffic. 327 Passive measurements cannot provide the kind of controllable 328 experiments that can be achieved with active measurements. On the 329 other hand passive measurements do not suffer from undesired side 330 effects caused by sending test traffic (e.g. additional load, 331 potential differences in treatment of test traffic and real customer 332 traffic). 334 QoS monitoring often requires the correlation of data from multiple 335 observation points (e.g. for measuring one-way metrics). This 336 requires proper clock synchronization of the involved metering 337 processes. For some measurements, flow records and/or notifications 338 on specific events at the different observation points must be 339 correlated, for example the arrival of a certain packet. For this, 340 the provisioning of post-processing functions (e.g. the generation of 341 packet IDs) at the metering processes would be useful. Since QoS 342 monitoring can lead to a huge amount of measurement result data, it 343 would highly benefit from mechanisms to reduce the measurement data, 344 like aggregation of results and sampling. 346 Please note that not all requirements for QoS monitoring are covered 347 by the IPFIX requirements specified in the following sections. The 348 IPFIX requirements are targeted at per flow information including 349 summaries of per-packet properties for packets within a flow, but not 350 per-packet information itself. For example jitter measurement 351 requires timestamping each packet and reporting of all timestamps of 352 a flow, but the IPFIX requirements only cover timestamps of first and 353 last packet of a flow. 355 4. Distinguishing Flows 357 Packets are mapped to flows by evaluating their properties. Packets 358 with common properties are considered to belong to the same flow. A 359 packet showing at least one difference in the set of properties is 360 considered to belong to a different flow. 362 The following subsections list a set of properties which a metering 363 process MUST, SHOULD, or MAY be able to evaluate for mapping packets 364 to flows. Please note that requiring the ability to evaluate a 365 certain property does not imply that this property must be evaluated 366 for each packet. 368 In other words, meeting the IPFIX requirements means that the 369 metering process in general must be able, via its configuration, to 370 somehow support to distinguish flows via all the MUST fields, even if 371 in certain circumstances/for certain applications, only a subset of 372 the MUST fields is needed and effectively used to distinguish flows. 374 Which combination of properties is used for distinguishing flows and 375 how these properties are evaluated depends on the configuration of 376 the metering process. The configured choice of evaluated properties 377 strongly depends on the environment and purpose of the measurement 378 and on the information required by the collecting process. 380 For specific deployments, only a subset of the REQUIRED properties 381 listed below can be used to distinguish flows, for example in order 382 to aggregate the flow records and reduce the number of flow records 383 exported. On the other hand, some other deployments will require 384 distinguishing flows by some extra parameters, like for example the 385 TTL field of the IP header or the BGP Autonomous System number 386 [RFC1771] of the IP destination address. 388 4.1. Interfaces 390 The metering process MUST be able to separate flows by the incoming 391 interface or by the outgoing interface or by both of them. 393 4.2. IP Header Fields 395 The metering process MUST, SHOULD, or MAY be able to separate flows 396 by the following fields of the IP header as indicated. 398 1. source IP address (MUST) 400 2. destination IP address (MUST) 402 3. protocol type (TCP,UDP,ICMP,...) (MUST) 404 4. IP version number (SHOULD) 405 This requirement only applies if the observation point is 406 located at a device that is supporting more than one version of 407 IP. 409 For source address and destination address, separating by full match 410 MUST be supported as well as separation by prefix match. 412 4.3. Transport Header Fields 414 The metering process MUST be able to separate flows by the port 415 numbers of the transport header in case of TCP or UDP being used as 416 transport protocol. Both, source and destination port number MUST be 417 supported for distinguishing flows, individually as well as in 418 combination. 420 4.4. MPLS Label 422 If the observation point is located at a device supporting 423 Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering 424 process MUST be able to separate flows by the MPLS label. 426 4.5. DiffServ Code Point 428 If the observation point is located at a device supporting 429 Differentiated Services (DiffServ) then the metering process MUST be 430 able to separate flows by the DiffServ Code Point (DSCP, see 431 [RFC2474]). 433 4.6. Header Compression and Encryption 435 If header compression or encryption is used, the metering process 436 might not be able to access all header fields. A metering process 437 MUST meet the requirements stated in this section 4 only for packets 438 that have the relevant header fields not compressed and not 439 encrypted. 441 5. Metering Process 443 The following are requirements for the metering process. All 444 measurements MUST be conducted from the point of view of the 445 observation point. 447 5.1. Reliability 449 The metering process MUST either be reliable or missing reliability 450 MUST be known and indicated. The metering process is reliable if each 451 packet passing the observation point is metered according to the 452 configuration of the metering process. If, e.g. due to some overload, 453 not all passing packets can be included into the metering process, 454 then the metering process MUST be able to detect this failure and to 455 report about it. 457 5.2. Sampling 459 Sampling describes the systematic or random selection of a subset of 460 elements (the sample) out of a set of elements (the parent 461 population). Usually the purpose of applying sampling techniques is 462 to estimate a parameter of the parent population by using only the 463 elements of the subset. Sampling techniques can be applied for 464 instance to select a subset of packets out of all packets of a flow 465 or to select a subset of flows out of all flows on a link. Sampling 466 methods differ in their sampling strategy (e.g. systematic or random) 467 and in the event that triggers the selection of an element. The 468 selection of one packet can for instance be triggered by its arrival 469 time (time-based sampling), by its position in the flow (count-based 470 sampling) or by the packet content (content-based sampling). 472 The metering process MAY support packet sampling. If sampling is 473 supported the sampling configuration MUST be well defined. The 474 sampling configuration includes the sampling method and all its 475 parameters. 477 If the sampling configuration is changed during operation, the new 478 sampling configuration with its parameters MUST be indicated to all 479 collecting processes receiving the affected flow records. Changing 480 the sampling configuration includes: start sampling, stop sampling, 481 change sampling method, and change sampling parameter. 483 In case of any change in the sampling configuration, all flow records 484 metered by the previous sampling configuration MUST be terminated and 485 exported according to the export configuration. The metering process 486 MUST NOT merge the flow records generated with the new sampling 487 configuration with the flow records generated with the previous 488 sampling configuration. 490 5.3. Overload Behavior 492 In case of an overload, for example lack of memory or processing 493 power, the metering process MAY change its behavior in order to cope 494 with the lack of resources. Possible reactions include: 496 - Reduce the number of flows to be metered. This can be achieved 497 by more coarse-grained flow measurement or by a restriction of 498 the flow records to a subset of the set of original ones. 500 - Start sampling packets before they are processed by the 501 metering process or - if sampling is already performed - reduce 502 the sampling frequency. 504 - Stop metering. 506 - Reducing the resource usage of competing processes on the same 507 device. Example: reducing the packet forwarding throughput 509 Overload behavior is not restricted to the four options listed above. 510 But in case the overload behavior induces a change of the metering 511 process behavior, the overload behavior MUST be clearly defined. 513 For some flows, the change of behavior might have an impact on the 514 data that would be stored in the associated flow records after the 515 change, for example if the packet classification is changed or the 516 sampling frequency. These flows MUST be considered as terminated and 517 the associated flow records MUST be exported separately from new ones 518 generated after the behavior change. The terminated flow records and 519 new ones generated after the behavior change MUST NOT be merged by 520 the metering process. The collecting process MUST be able to 521 distinguish the affected flow records generated before and after the 522 change of behavior. This requirement does not apply to flows and 523 associated flow records not affected by the change of metering 524 process behavior. 526 5.4. Timestamps 528 The metering process MUST be able to generate timestamps for the 529 first and the last observation of a packet of a flow at the 530 observation point. The timestamp resolution MUST be at least the one 531 of the sysUpTime [RFC1213], which is one centisecond. 533 5.5. Time Synchronization 535 It MUST be possible to synchronize timestamps generated by a metering 536 process with Coordinated Universal Time (UTC). 538 Note that the possibility of synchronizing timestamps of each single 539 metering process with UTC implies the possibility of synchronizing 540 timestamps generated by different metering processes. 542 Note that this does not necessarily imply that timestamps generated 543 by the metering process are UTC timestamps. For example, this 544 requirement can be met by using local system clock values as 545 timestamps and adding an additional timestamp when exporting a report 546 to a collecting process. Then the collecting process can synchronize 547 the timestamps by calculating the offset between UTC and the system 548 clock of the metering process. 550 5.6. Flow Expiration 552 The metering process MUST be able to detect flow expirations. A flow 553 is considered to be expired if no packet of this flow has been 554 observed for a given timeout interval. The metering process MAY 555 support means for detecting the expiration of a flow before a timeout 556 occurs, for example by detecting the FIN or RST bits in a TCP 557 connection. The procedure for detecting a flow expiration MUST be 558 clearly defined. 560 5.7. Multicast Flows 562 For multicast flows containing packets replicated to multiple output 563 interfaces, the metering process SHOULD be able to maintain discrete 564 flow records per different output interface. For example, the 565 metering process SHOULD be able to report an incoming multicast 566 packet that is replicated to four output interfaces in four different 567 flow records that differ by the output interface. 569 5.8. Packet Fragmentation 571 In case of IP packet fragmentation and depending on the 572 classification scheme, only the zero-offset fragment of a single 573 initial packet might contain sufficient information to classify the 574 packet. Note that this fragment should be the first one generated by 575 the router imposing the fragmentation [RFC791], but might not be the 576 first one observed by the IPFIX device, due reordering reasons. The 577 metering process MAY keep state of IP packet fragmentation in order 578 to map fragments that do not contain sufficient header information 579 correctly to flows. 581 5.9. Ignore Port Copy 583 The metering process MAY be able to ignore packets which are 584 generated by a port copy function acting at the device where the 585 observation point of a flow is located. 587 6. Data Export 589 The following are requirements for exporting flow records out of the 590 exporting process. Beside requirements on the data transfer, we 591 separate requirements concerning the information model from 592 requirements concerning the data model. Furthermore, we list 593 requirements on reporting times, notification on specific events, and 594 on anonymization of flow records. 596 6.1. Information Model 598 The information model for the flow information export is the list of 599 attributes of a flow to be contained in the report (including the 600 semantics of the attributes). 602 This section lists attributes an exporting process MUST, SHOULD or 603 MAY be able to report. This does not imply that each exported flow 604 record MUST contain all REQUIRED attributes. But it implies that it 605 MUST be possible to configure the exporting process in a way that the 606 information of all REQUIRED attributes can be transmitted from the 607 exporting process to the receiving collecting process(es) for each 608 exported flow. 610 In other words, meeting the IPFIX requirements means that the 611 exporting process in general must be able, via its configuration, to 612 somehow support to report all the MUST fields, even if in certain 613 circumstance or for certain applications, only a subset of the set of 614 all MUST fields is needed and effectively reported. 616 Beyond that, the exporting process might offer to report further 617 attributes not mentioned here. A particular flow record may contain 618 some of the "REQUIRED" attributes as well as some additional ones, 619 for example covering future technologies. 621 This document does not impose that the following attributes are 622 reported for every single flow record, especially for repetitive 623 attributes. For example, if the observation point is the incoming 624 packet stream at the IP interface with the ifIndex value 3, then this 625 observation point does not have to be exported as part of every 626 single flow record. Exporting it just once might give sufficient 627 information to the collecting process. 629 The exporting process MUST be able to report the following attributes 630 for each metered flow: 632 1. IP version number 633 This requirement only applies if the observation point is 634 located at a device supporting more than one version of IP. 635 2. source IP address 636 3. destination IP address 637 4. IP protocol type (TCP,UDP,ICMP,...) 638 5. if protocol type is TCP or UDP: source TCP/UDP port number 639 6. if protocol type is TCP or UDP: destination TCP/UDP port number 640 7. packet counter 641 If a packet is fragmented, each fragment is counted as an 642 individual packet. 643 8. byte counter 644 Which bytes of a packet are counted MUST be defined exactly. 645 9. type of service octet (in case of IPv4), traffic class 646 octet (in case of IPv6) 647 10. in case of IPv6: Flow Label 648 11. if MPLS is supported at the observation point: the top MPLS 649 label or the corresponding forwarding equivalence class (FEC, 650 [RFC3031]) bound to that label. The FEC is typically defined by 651 an IP prefix. 652 12. timestamp of the first packet of the flow 653 13. timestamp of the last packet of the flow 654 14. if sampling is used: sampling configuration 655 15. unique identifier of the observation point 656 16. unique identifier of the exporting process 658 The exporting process SHOULD be able to report the following 659 attributes for each metered flow: 661 17. if protocol type is ICMP: ICMP type and code 662 18. input interface (ifIndex) 663 This requirement does not apply if the observation point is 664 located at a probe device. 665 19. output interface (ifIndex) 666 This requirement does not apply if the observation point is 667 located at a probe device. 668 20. multicast replication factor 669 the number of outgoing packets originating from a single 670 incoming multicast packet. This is a dynamic property of 671 multicast flows, that may change over time. For unicast flows 672 it has the constant value 1. The computation of the factor MUST 673 be clearly defined. 675 The exporting process MAY be able to report the following attributes 676 for each metered flow: 678 21. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6) 679 22. IP header flags 680 23. TCP header flags 681 24. dropped packet counter at the observation point 682 If a packet is fragmented, each fragment MUST be counted as an 683 individual packet. 684 25. fragmented packet counter 685 counter of all packets for which the fragmented bit is set in 686 the IP header 688 26. next hop IP address 690 In addition, the exporting process MAY be able to report attributes 691 related to inter-autonomous system routing of a flow, for example by 692 reporting BGP Autonomous System numbers [RFC1771]. 694 6.2. Data Model 696 The data model describes how information is represented in flow 697 records. 699 The data model MUST be extensible for future attributes to be added. 700 Even if a set of attributes is fixed in the flow record, the data 701 model MUST provide a way of extending the record by configuration or 702 for certain implementations. 704 The data model used for exporting flow information MUST be flexible 705 concerning the flow attributes contained in flow records. A flexible 706 record format would offer the possibility of defining records in a 707 flexible (customizable) way regarding the number and type of 708 contained attributes. 710 The Data Model SHOULD be independent of the underlying transport 711 protocol, i.e. the data transfer. 713 6.3. Data Transfer 715 Requirements for the data transfer include reliability, congestion 716 awareness, and security requirements. For meeting these requirements 717 the exporting process can utilize existing security features provided 718 by the device hosting the process and/or provided by the transport 719 network. For example it can use existing security technologies for 720 authentication and encryption or it can rely on physical protection 721 of a separated network for transferring flow information. 723 6.3.1. Congestion Awareness 725 For the data transfer, a congestion aware protocol MUST be supported. 727 6.3.2. Reliability 729 Loss of flow records during the data transfer from the exporting 730 process to the collecting process MUST be indicated at the collecting 731 process. This indication MUST allow the collecting process to gauge 732 the number of flow records lost. Possible reasons for flow records 733 loss include but are not limited to: 735 1. Metering process limitations: lack of memory, processing power, 736 etc. These limitations are already covered in section 5.1. 738 2. Exporting process limitations: lack of memory, processing 739 power, etc. 741 3. Data transfer problems: packets that carry flow records sent 742 from the exporting process to the collecting process, are 743 dropped by the network. Examples are connection failures, 744 congestions in combination with an unreliable transport 745 protocol, etc. 747 4. Collecting process limitations: it may be experiencing 748 congestion and not able to buffer new flows records." 750 5. Operation and Maintenance: the collecting process is taken down 751 for maintenance or other administrative purposes. 753 Please note that if an unreliable transport protocol is used, 754 reliability can be provided by higher layers. In such a case only 755 lack of overall reliability MUST be indicated. For example reordering 756 could be dealt with by adding a sequence number to each packet. 758 The data transfer between exporting process and collecting process 759 MUST be open to reliability extensions including at least 760 - retransmission of lost flow records, 761 - detection of disconnection and fail-over, and 762 - acknowledgement of flow records by the collecting process. 763 This extensibility MAY be used to provide additional reliability. 765 6.3.3. Security 767 Confidentiality of flow specific data transferred from an exporting 768 process to a collecting process SHOULD be ensured. 770 Integrity of IPFIX data transferred from an exporting process to a 771 collecting process MUST be ensured. 773 Authenticity of IPFIX data transferred from an exporting process to a 774 collecting process MUST be ensured. 776 The security threats from which these 3 requirements are deducted are 777 explained in the "Security Considerations" (Section 10). 779 6.4. Push and Pull Mode Reporting 781 In general, there are two ways of deciding on reporting times: push 782 mode and pull mode. In push mode, the exporting process decides 783 without an external trigger when to send flow records. In pull mode, 784 sending flow records is triggered by an explicit request from a 785 collecting process. The exporting process MUST support push mode 786 reporting, it MAY support pull mode reporting. 788 6.5. Regular Reporting Interval 790 The exporting process SHOULD be capable of reporting measured traffic 791 data regularly according to a given interval length. 793 6.6. Notification on Specific Events 795 The exporting process MAY be capable of sending notifications to a 796 collecting process, if a specific event occurs. Such an event can be 797 for instance the arrival of the first packet of a new flow, or the 798 termination of a flow after flow timeout. 800 6.7. Anonymization 802 The exporting process MAY be capable of anonymizing source and 803 destination IP addresses in flow data before exporting them. It MAY 804 support anonymization of port numbers and other fields. Please note 805 that anonymization is not originally an application requirement, but 806 derived from general requirements for treatment of measured traffic 807 data within a network. 809 7. Configuration 811 7.1. Configuration of the Metering Process 813 The metering process MUST provide a way of configuring traffic 814 measurement. The following parameters of the metering process SHOULD 815 be configurable: 817 1. specification of the observation point 818 e.g. an interface or a list of interfaces to be monitored. 819 2. specifications of flows to be metered 820 3. flow timeouts 822 The following parameters MAY be configurable: 824 4. sampling method and parameters, if feature is supported 825 5. overload behavior, if feature is supported 827 7.2. Configuration of the Exporting Process 829 The exporting process MUST provide a way of configuring the data 830 export. The following parameters of the exporting process SHOULD be 831 configurable: 833 1. reporting data format 834 Specifying the reporting data format MUST include a selection 835 of attributes to be reported for each flow. 836 2. the collecting process(es) to which flows are reported 837 3. the reporting interval 838 This requirement only applies if the exporting process supports 839 reporting in regular intervals. 840 4. notifications to be sent to the collecting process(es) 841 This requirement only applies if the exporting process supports 842 notifications. 843 5. flow anonymization 844 This requirement only applies if the exporting process supports 845 flow anonymization. 847 If configuration is done remotely, security SHOULD be provided for 848 the configuration process covering confidentiality, integrity and 849 authenticity. The means used for remote configuration are out of the 850 scope of this document. 852 8. General Requirements 854 8.1. Openness 856 IPFIX specifications SHOULD be open to future technologies. This 857 includes extensibility of configuration of the metering process and 858 the exporting process. 860 Openness is also required concerning the extensibility of the data 861 model, as stated in section 6.2. 863 8.2. Scalability 865 Data collection from hundreds of different exporting processes MUST 866 be supported. The collecting process MUST be able to distinguish 867 several hundred exporting processes by their identifiers. 869 8.3. Several Collecting Processes 871 The exporting process MAY be able to export flow information to more 872 than one collecting process. If an exporting process is able to 873 export flow records to multiple collecting processes then it MUST be 874 able to ensure that the flow records can be identified so that 875 duplicates can be detected between different collecting processes and 876 double counting problems can be avoided. 878 9. Special Device Considerations 880 This document intends to avoid constraining the architecture of 881 probes, routers, and other devices hosting observation points, 882 metering processes, exporting processes, and/or collecting processes. 883 It can be expected that typically observation point, metering 884 process, and exporting process are co-located at a single device. 886 However, the requirements defined in this document do not exclude 887 devices that derive from this configuration. Figure 2 shows some 888 examples. 890 +---+ +-----+ +---------+ +---------+ 891 | E-+-> | E--+-> | E----+-> <-+--E E--+-> 892 | | | | | | | / \ | | | | | 893 | M | | M | | M M | | M M | 894 | | | | /|\ | | /|\ /|\ | | /|\ /|\ | 895 | O | | OOO | | OOO OOO | | OOO OOO | 896 +---+ +-----+ +---------+ +---------+ 897 Probe Basic Complex Multiple 898 Router Router Exporting 899 Processes 901 +---+ +---+ +---+ 902 | E-+-> | E-+-> | E-+------------->---+ 903 | | | | | | | | | +---+ +-+-----+ 904 +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> 905 | | | | | | | | | | +---+ +-+-----+ 906 +-+-+ +-+-+ | O | | M | | E-+->---+ 907 | | | | +---+ | | | | | | 908 | M | +-+-+ | O | | M | 909 | | | | | | +---+ | | | +-----+ 910 | O | | O | | O | ->-+-C-E-+-> 911 +---+ +---+ +---+ +-----+ 913 Protocol Remote Concentrator Proxy 914 Converter Observation 916 Figure 2: IPFIX-related Devices 918 All examples are composed of one or more of the following elements: 919 observation point (O), metering process (M), exporting process (E), 920 collecting process (C). The observation points shown in the figure 921 are always the most fine-granular ones supported by the respective 922 device. 924 A very simple device is a probe. A typical probe contains a single 925 observation point, a single metering process, and a single exporting 926 process. 928 A basic router extends this structure by multiple observation points. 929 Here, the observation point of a particular flow may be one of the 930 displayed most fine-granular observation points, but also it may be a 931 set of them. 933 A more complex router may host more than one metering process, for 934 example one per line card. Please note that here, the observation 935 point of a single flow cannot exceed the set of most fine-granular 936 observation points linked to a single metering process, because only 937 the metering process can merge packets observed at different fine- 938 granular observation points to a joint flow. An observation point 939 containing all most fine-granular observation points of this router 940 is not possible with this structure. Alternatively, a complex router 941 may host different exporting processes for flow records generated by 942 different metering processes. 944 A protocol converter makes use of a metering process that can be 945 accessed only by another protocol than the one defined for IPFIX, for 946 example the SNMP and the Meter MIB module [RFC2720]. Then the 947 exporting process receives flow record from a remote metering process 948 and exports these records using the IPFIX protocol. Please note, that 949 this document does not make any particular assumption on how metering 950 processes and export processes exchange information, as long as all 951 individual requirements for these processes are met. Also the 952 locations of metering processes are not of any relevance for this 953 document (in contrast to the locations of observation points and the 954 exporting processes). 956 In the example of remote packet observation in Figure 2 the metering 957 process and the observation point are not co-located. Packet header 958 captured at an observation point may be exported as raw data to a 959 device hosting metering process and exporting process. Again, this 960 document does not make any particular assumption on how packet 961 headers are transfered from observation points to metering processes, 962 as long as all requirements for the metering processes are met. 964 An intermediate structure between protocol converter and remote 965 observation (not shown in the Figure) would be a split metering 966 process, for example performing timestamping and sampling at the 967 device hosting the observation point and performing packet 968 classification at another device hosting the exporting process. 970 A concentrator receives flow records via the IPFIX protocol, merges 971 them into more aggregated flow records, and exports them again using 972 the IPFIX protocol. Please note, that for the final flow records the 973 resulting observation point may be a superset of the more fine- 974 granular observation points at the first level devices. The metering 975 process of the final flow records is composed by the (partial) 976 metering processes at the first level devices and the partial 977 metering process at the concentrator. 979 Finally, a very simple IPFIX-related device is a proxy. It just 980 receives flow records using the IPFIX protocol and sends them further 981 using the same protocol. A proxy might be useful for traversing 982 firewalls or other gateways. 984 10. Security Considerations 986 An IPFIX protocol must be capable to transport data over the public 987 Internet. Therefore it cannot be excluded that an attacker captures 988 or modifies packets or inserts additional packets. 990 This section describes security requirements for IPFIX. Like other 991 requirements, the security requirements differ among the considered 992 applications. The incentive to modify collected data for accounting 993 or intrusion detection for instance is usually higher than the 994 incentive to change data collected for traffic profiling. A detailed 995 list of the required security features per application can be found 996 in the appendix. 998 The suggestion of concrete solutions for achieving the required 999 security properties should be part of an IPFIX architecture and 1000 protocol. It is out of scope of this document. Also methods for 1001 remote configuration of the metering processes and exporting 1002 processes are out of scope. Therefore, threats that are caused by 1003 data exchange for remote configuration are not considered here. 1005 The following potential security hazards for an IPFIX protocol have 1006 been identified: disclosure of IP flow information, forgery of flow 1007 records, and Denial of Service (DoS) attacks. 1009 10.1. Disclosure of Flow Information Data 1011 The content of data exchanged by an IPFIX protocol (for example IPFIX 1012 flow records) should be kept confidential between the involved 1013 parties (exporting process and collecting process). Observation of 1014 IPFIX flow records gives an attacker information about the active 1015 flows in the network, communication endpoints and traffic patterns. 1016 This information cannot only be used to spy out user behavior but 1017 also to plan and conceal future attacks. Therefore, the requirements 1018 specified in section 6.3.3. include confidentiality of the 1019 transferred data. This can be achieved for instance by encryption. 1021 10.2. Forgery of Flow Records 1023 If flow records are used in accounting and security applications, 1024 there are potentially strong incentives to forge exported IPFIX flow 1025 records (for example to save money or prevent the detection of an 1026 attack). This can be done either by altering flow records on the path 1027 or by injecting forged flow records that pretend to be originated by 1028 the original exporting process. In order to make an IPFIX protocol 1029 resistant against such attacks, authentication and integrity must be 1030 provided, as specified in section 6.3.3. 1032 Special caution is required if security applications rely on flow 1033 measurements. With forged flow records it is possible to trick on 1034 security applications. It is for instance possible to pretend that a 1035 DoS attack happens without even launching a real attack. 1037 10.3. Denial of Service (DoS) Attacks 1039 DoS attacks on routers or other middleboxes that have the IPFIX 1040 protocol implemented would also affect the IPFIX protocol and impair 1041 the sending of IPFIX records. Nevertheless, since such hazards are 1042 not induced specifically by the IPFIX protocol the prevention of such 1043 attacks is out of scope of this document. 1045 However, IPFIX itself also causes potential hazards for DoS attacks. 1046 All processes that expect the reception of traffic can be target of a 1047 DoS attack. With the exporting process this is only the case if it 1048 supports the pull mode (which can be an optional feature of the IPFIX 1049 protocol according to this document). The collecting process always 1050 expects data and therefore can be flooded by flow records. 1052 11. Acknowledgments 1054 Many thanks Georg Carle for contributing to the application analysis, 1055 to K.C. Norseth for several fine-tunings, and to a lot of further 1056 people on the mailing list providing valuable comments and 1057 suggestions including Nevil Brownlee, Carter Bullard, Paul Calato, 1058 Ram Gopal, Tal Givoly, Jeff Meyer, Reinaldo Penno, Sonia Panchen, 1059 Simon Leinen, David Plonka, Ganesh Sadasivan, Kevin Zhang, and may 1060 more. 1062 12. Normative References 1064 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 1065 Switching Architecture", RFC 3031, January 2001. 1067 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 1068 Differentiated Services Field (DS Field) in the IPv4 and 1069 IPv6 Headers", RFC 2474, December 1998. 1071 [RFC791] J. Postel. "Internet Protocol", RFC791, September 1981. 1073 13. Informative References 1075 [RFC3234] B. Carpenter, "Middleboxes: taxonomy and issues", RFC 3234, 1076 February 2002. 1078 [RFC2119] S. Bradner "Key words for use in RFCs to Indicate 1079 Requirement Levels", RFC 2119, March 1997. 1081 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: 1082 A Transport Protocol for Real-Time Applications", RFC 1889, 1083 January 1996. 1085 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 1086 "Requirements for Traffic Engineering Over MPLS", RFC 2702, 1087 September 1999. 1089 [RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1090 RFC 1771, March 1995. 1092 [RFC1213] K. McCloghrie, M. Rose. "Management Information Base for 1093 Network Management of TCP/IP-based internets: MIB-II", RFC 1094 1213, March 1991. 1096 [RFC2720] N. Brownlee. "Traffic Flow Measurement: Meter MIB", RFC 1097 2720, October 1999. 1099 14. Authors' Addresses 1101 Juergen Quittek 1102 NEC Europe Ltd., Network Laboratories 1103 Kurfuersten-Anlage 36 1104 69115 Heidelberg 1105 Germany 1107 Phone: +49 6221 90511 15 1108 EMail: quittek@ccrle.nec.de 1110 Tanja Zseby 1111 Fraunhofer Institute for Open Communication Systems (FOKUS) 1112 Kaiserin-Augusta-Allee 31 1113 10589 Berlin 1114 Germany 1116 Phone: +49 30 3463 7153 1117 Email: zseby@fokus.fhg.de 1119 Benoit Claise 1120 Cisco Systems 1121 De Kleetlaan 6a b1 1122 1831 Diegem 1123 Belgium 1125 Phone: +32 2 704 5622 1126 Email: bclaise@cisco.com 1127 Sebastian Zander 1128 Fraunhofer Institute for Open Communication Systems (FOKUS) 1129 Kaiserin-Augusta-Allee 31 1130 10589 Berlin 1131 Germany 1133 Phone: +49 30 3463 7287 1134 Email: zander@fokus.fhg.de 1136 15. Full Copyright Statement 1138 Copyright (C) The Internet Society (2001). All Rights Reserved. 1140 This document and translations of it may be copied and furnished to 1141 others, and derivative works that comment on or otherwise explain it 1142 or assist in its implementation may be prepared, copied, published 1143 and distributed, in whole or in part, without restriction of any 1144 kind, provided that the above copyright notice and this paragraph are 1145 included on all such copies and derivative works. However, this 1146 document itself may not be modified in any way, such as by removing 1147 the copyright notice or references to the Internet Society or other 1148 Internet organizations, except as needed for the purpose of 1149 developing Internet standards in which case the procedures for 1150 copyrights defined in the Internet Standards process must be 1151 followed, or as required to translate it into languages other than 1152 English. 1154 The limited permissions granted above are perpetual and will not be 1155 revoked by the Internet Society or its successors or assigns. 1157 This document and the information contained herein is provided on an 1158 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1159 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1160 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1161 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1162 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1164 Appendix: Derivation of Requirements from Applications 1166 The following table documents, how the requirements stated in 1167 sections 3-7 are derived from requirements of the applications listed 1168 in section 2. 1170 Used abbreviations: 1171 M = MUST 1172 S = SHOULD 1173 O = MAY (OPTIONAL) 1174 - = DONT CARE 1176 -----------------------------------------------------------------------. 1177 IPFIX | 1178 ----------------------------------------------------------------. | 1179 E: QoS Monitoring | | 1180 ----------------------------------------------------------. | | 1181 D: Attack/Intrusion Detection | | | 1182 ----------------------------------------------------. | | | 1183 C: Traffic Engineering | | | | 1184 ----------------------------------------------. | | | | 1185 B: Traffic Profiling | | | | | 1186 ----------------------------------------. | | | | | 1187 A: Usage-based Accounting | | | | | | 1188 ----------------------------------. | | | | | | 1189 | | | | | | | 1190 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1191 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1192 | 4. | DISTINGUISHING FLOWS | 1193 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1194 | 4. | Combination of | M | M | M | M | M | M | 1195 | | required attributes | | | | | | | 1196 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1197 | 4.1. | in/out IF | S | M | M | S | S | M | 1198 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1199 | 4.2. | src/dst address | M | M | M | M | M | M | 1200 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1201 | 4.2. | Masking of IP adresses | M | M | M | M | M | M | 1202 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1203 | 4.2. | transport protocol | M | M | - | M | M | M | 1204 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1205 | 4.2. | version field | - | S | S | O | O | S | 1206 | | | | | (b) | | | | 1207 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1208 | 4.3. | src/dst port | M | M | - | M | M | M | 1209 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1210 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1211 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1212 | 4.4. | MPLS label (a) | S | S | M | O | S | M | 1213 | | | | | (c) | | | | 1214 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1215 | 4.5. | DSCP (a) | M | S | M | O | M | M | 1216 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1217 | 5. | METERING PROCESS | 1218 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1219 | 5.1. | Reliability | M | S | S | S | S | | 1220 |-------+-------------------------+-----+-----+-----+-----+-----+ M | 1221 | 5.1. | Indication of | - | M | M | M | M | | 1222 | | missing reliability | | | | | | | 1223 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1224 | 5.2. | Sampling (g) | O | O | O | O | O | O | 1225 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1226 | 5.3. | Overload Behavior | O | O | O | O | O | O | 1227 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1228 | 5.4. | Timestamps | M | O | O | S | M | M | 1229 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1230 | 5.5. | Time synchronization | M | S | S | S | M | M | 1231 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1232 | 5.6. | Flow timeout | M | S | - | O | O | M | 1233 | | | (d) | | | | | | 1234 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1235 | 5.7. | Multicast flows | S | O | O | O | S | S | 1236 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1237 | 5.9. | Ignore port copy | O | O | O | O | O | O | 1238 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1239 | 6. | DATA EXPORT | 1240 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1241 | 6.1. | INFORMATION MODEL | 1242 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1243 | 6.1. | IP Version | - | M | M | O | O | M | 1244 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1245 | 6.1. | src/dst address | M | M | M | M | M | M | 1246 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1247 | 6.1. | transport protocol | M | M | - | M | M | M | 1248 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1249 | 6.1. | src/dst port | M | M | - | M | M | M | 1250 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1251 | 6.1. | Packet counter (h) | S | M | M | S | S | M | 1252 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1253 | 6.1. | Byte counter | M | M | M | S | S | M | 1254 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1255 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1256 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1257 | 6.1. | Dropped Packet | O | M | M | S | M | M | 1258 | | Counter (h,i) | | | | | | | 1259 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1260 | 6.1. | ToS Byte | M | S | M | O | M | M | 1261 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1262 | 6.1. | Flow Label | M | S | M | O | M | M | 1263 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1264 | 6.1. | BGP AS# | - | S | M | - | - | M | 1265 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1266 | 6.1. | MPLS label (a) | S | S | M | O | S | M | 1267 | | | | | (c) | | | | 1268 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1269 | 6.1. | DSCP (a) | M | S | M | O | M | M | 1270 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1271 | 6.1. | Timestamps for | M | O | O | S | S | M | 1272 | | first/last packet | | | | | | | 1273 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1274 | 6.1. | Sampling configuration | M | M | M | M | M | M | 1275 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1276 | 6.1. | observation point | M | M | M | M | M | M | 1277 | | identifier | | | | | | | 1278 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1279 | 6.1. | export process | M | M | M | M | M | M | 1280 | | identifier | | | | | | | 1281 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1282 | 6.1. | TTL | O | O | O | O | O | O | 1283 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1284 | 6.1. | IP header flags | - | O | O | O | O | O | 1285 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1286 | 6.1. | TCP header flags | - | O | O | O | - | O | 1287 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1288 | 6.1. | Fragment counter | - | O | O | O | O | O | 1289 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1290 | 6.1. | Multicast | O | S | S | - | S | S | 1291 | | replication factor | | | | | | | 1292 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1293 | 6.2. | DATA MODEL | 1294 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1295 | 6.2. | Flexibility | M | S | M | M | M | M | 1296 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1297 | 6.2. | Extensibility | M | S | M | M | M | M | 1298 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1299 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1300 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1301 | 6.3. | DATA TRANSFER | 1302 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1303 | 6.3.1.| Congestion aware | M | M | M | M | M | M | 1304 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1305 | 6.3.2.| Reliability | M | S | S | S | S | M | 1306 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1307 | 6.3.3.| Confidentiality | S | S | S | S | S | S | 1308 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1309 | 6.3.4.| Integrity | M | M | M | M | M | M | 1310 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1311 | 6.3.5.| Authenticity | M | M | M | M | M | M | 1312 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1313 | 6.4. | REPORTING TIMES | 1314 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1315 | 6.4. | Push mode | M | O | O | M | S | M | 1316 | | | | (e) | (e) | |(e,f)| | 1317 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1318 | 6.4. | Pull mode | O | O | O | O | O | O | 1319 | | | | (e) | (e) | | (e) | | 1320 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1321 | 6.4.1.| Regular Interval | S | S | S | S | S | S | 1322 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1323 | 6.6. | Notifications | O | O | O | O | O | O | 1324 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1325 | 6.7. | Anonymization | O | O | O | O | O | O | 1326 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1327 | 7. | CONFIGURATION | 1328 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1329 | 7. | Config Measurement | M | M | M | M | M | M | 1330 | | & Data Export | | | | | | | 1331 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1332 | 7. | Config Observation Point| S | S | S | S | S | S | 1333 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1334 | 7. | Config Flow | S | S | S | S | S | S | 1335 | | Specifications | | | | | | | 1336 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1337 | 7. | Config Flow Timeouts | S | S | S | S | O | S | 1338 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1339 | 7. | Config Sampling | O | O | O | O | O | O | 1340 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1341 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1342 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1343 | 7. | Config Report | S | S | S | S | S | S | 1344 | | Data Format | | | | | | | 1345 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1346 | 7. | Config | O | O | O | O | O | O | 1347 | | Notifications | | | | | | | 1348 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1349 | 7. | Config Anonymization | O | O | O | O | O | O | 1350 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1351 | 8. | GENERAL REQUIREMENTS | 1352 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1353 | 8.1. | Openness | S | S | S | S | S | S | 1354 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1355 | 8.2. | Scalability: | | | | | | | 1356 | | data collection | M | S | M | O | S | M | 1357 | | from hundreds of | | | | | | | 1358 | | measurement devices | | | | | | | 1359 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1360 | 8.3. | Several Collectors | O | O | O | O | O | O | 1361 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1363 Remarks: 1364 (a) If feature is supported. 1365 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 1366 So we tended to make this a MUST. Nevertheless, a SHOULD seems 1367 to be sufficient to perform most TE tasks and allows us to have 1368 a SHOULD for IPFIX instead of a MUST. 1369 (c) For TE in an MPLS network the label is essential. Therefore a 1370 MUST is given here leading to a MUST in IPFIX. 1371 (d) Precise time-based accounting requires reaction to a flow 1372 timeout. 1373 (e) Either push or pull has to be supported. 1374 (f) Required, in order to immediately report drop indications for 1375 SLA validation. 1376 (g) If sampling is supported the methods and parameters MUST be 1377 well defined. 1378 (h) If a packet is fragmented, each fragment is counted as an 1379 individual packet. 1380 (i) Only if measurement is done on data path i.e. has access to 1381 forwarding decision.