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