idnits 2.17.1 draft-quittek-ipfx-req-01.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 is more than 15 pages and seems to lack a Table of Contents. == 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 116 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2001) is 8313 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 2274' is mentioned on line 557, but not defined ** Obsolete undefined reference: RFC 2274 (Obsoleted by RFC 2574) == Unused Reference: 'RFC2274' is defined on line 582, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-carpenter-midtax-01 ** Downref: Normative reference to an Informational draft: draft-carpenter-midtax (ref. 'MIDBOXTAX') ** Downref: Normative reference to an Informational RFC: RFC 2702 ** Obsolete normative reference: RFC 2274 (Obsoleted by RFC 2574) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Quittek 3 NEC 4 Expires: January 2002 5 T. Zseby 6 G. Carle 7 S. Zander 8 GMD FOKUS 10 July 2001 12 Requirements for IP Flow Export 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This memo defines requirements for the export of IP flow information 38 out of routers, traffic measurement probes and middleboxes. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119. 46 Table of Content 48 1. Introduction 49 1.1. IP Flows 50 2. Applications Requiring IP Flow Export 51 2.1 Usage Accounting 52 2.2 Traffic Profiling 53 2.3 Traffic Engineering 54 2.4 Attack/Intrusion Detection 55 2.5 Network Surveillance 56 2.6 QoS Monitoring 57 3. Distinguishing Flows 58 3.1. Interfaces 59 3.2. Packet Treatment 60 3.3. IP Header Fields 61 3.4. Transport Header Fields 62 3.5. MPLS Label 63 3.6. DiffServ Code Point 64 4. Metering Process 65 4.1. Reliability 66 4.2. Sampling 67 4.3. Timestamps 68 4.4. Timeout 69 4.5. Header Compression 70 4.6. Ignore Port Copy 71 5. Data Export 72 5.1. Information Model 73 5.2. Data Model 74 5.3. Data Transfer 75 5.3.1. Reliability 76 5.3.2. Confidentiality 77 5.3.3 Integrity 78 5.3.3 Authenticity 79 5.4. Reporting Times 80 5.4.1. Regular Interval 81 5.4.2. Notification on Account Opening 82 5.4.3. Notification on Account Closing 83 5.5. Anonymization 84 6. Configuration 85 7. General Requirements 86 8. Open Issues 87 9. Security Considerations 88 10. References 89 11. Authors' Addresses 91 1. Introduction 93 There are several applications that require flow-based IP traffic 94 measurements. Such measurements could be performed by a router while 95 forwarding the traffic, by a middlebox [MIDBOXTAX], or by a traffic 96 measurement probe attached to a line or monitor port. This memo 97 defines requirements for exporting traffic flow information out of 98 these boxes for further processing by applications located on other 99 devices. In section 2 a selection of such applications is presented. 100 The following sections list requirements derived from these 101 applications. 103 1.1 IP Flows 105 There are several definitions of the term 'flow' being used by the 106 Internet community. Within this document we use the following one: 108 A flow is a set of packets passing an observed point in the 109 network during a certain time interval. All packets belonging to a 110 particular flow have a set of common properties derived from the 111 data contained in the packet or from packet reception or packet 112 treatment at the observing device. 114 The observed point may be a network interface of a device or an 115 entire router or middlebox with several interfaces. Properties 116 derived from packet reception include the interface at which the 117 packet arrived and potentially some more fine grained sub-IP 118 information. Properties derived from packet treatment include 119 information about the kind of treatment (observation only, reception, 120 forwarding, discarding) and, in case of forwarding, the selected 121 forwarding parameters. 123 Which flow properties are considered for distinguishing flows is part 124 of the requirements definition and will be addressed below. This 125 definitions cover the range from a flow containing all packets 126 observed at a network interface to a flow consisting of just a single 127 packet between two applications with a specific sequence number. 128 Please note that the definition does not match a general application- 129 level end-to-end stream. However, an applicaton may derive properties 130 of application-level streams by processing measured flow data. 132 2. Applications Requiring IP Flow Export 134 The following list contains a selection of applications requiring IP 135 flow export. Because requirements for flow export listed in further 136 sections below are derived from these applications, their selection 137 is crucial. The goal of this requirements document is not to cover 138 all possible applications with all their flow export requirements, 139 but to cover applications which are considered to be of significant 140 importance in today's or future IP networks, and for which 141 requirements can be met with reasonable technical effort. 143 Please note, that the described applications can have a large number 144 of differing implementations. Requirement details or the weighting of 145 requirements could differ for specific implementations. Therefore we 146 derive the requirements from the general functionality of the 147 selected applications. Furthermore, the list of applications should 148 lead to a better understanding of the requirements which is 149 particularly important when designing or implementing a traffic flow 150 measuring device. 152 2.1 Usage Accounting 154 Several new business models for selling IP service and IP-based 155 services are currently under investigation. Beyond flat rate services 156 which do not need accounting, accounting for these models can be 157 based on time or volume. Accounting can be performed per user or per 158 user group, it can be performed just for basic IP service or 159 individually per high-level service and/or per content type 160 delivered. For advanced/future services, accounting may also be 161 performed per class of service (assuming different quality of service 162 for different classes) and per used (label switched) path. 164 2.2 Traffic Profiling 166 Traffic profiling is a process of characterizing IP flows and flow 167 aggregates by using a model that represents key parameters of the 168 flow such as flow duration, volume and burstiness. It is a 169 prerequisite for network planning, network dimensioning, trend 170 analysis, developing business models, and other activities. It 171 heavily depends on the particular traffic profiling objective(s) what 172 statistics and accuracy are required from the measurements. Typical 173 information needed for traffic profiling are the distribution of used 174 services and protocols in the network, the amount of packets of a 175 specific type (e.g. percentage of IPv6 packets) and specific flow 176 profiles. 178 Since objectives for traffic profiling can vary, this application 179 requires a high flexibility of the measurement infrastructure, 180 especially regarding the options for measurement configuration and 181 packet classification. 183 2.3 Traffic Engineering 185 Traffic Engineering (TE) comprises methods for measurement, modeling, 186 characterization and control of a network. The goal of TE is the 187 optimization of network resource utilization and traffic performance 188 [RFC2702]. Since control and administrative reaction to measurement 189 results requires access to the involved network nodes, TE mechanisms 190 and the required measurement function usually are performed within 191 one administrative domain. Typical parameters required for TE are 192 link utilization, load between specific network nodes, number, size 193 and entry/exit points of the active flows and routing information. 195 2.4 Attack/Intrusion Detection 197 Capturing of flow information plays an important role for network 198 security, both for detection of security violation, and for 199 subsequent defense. In case of a Denial of Service (DOS) attack, flow 200 monitoring can allow detection of unusual load situations or 201 suspicious flows. In a second step, flow analysis can be performed in 202 order to gather information about the attacking flows, and for 203 deriving a defense strategy. Intrusion detection is a potentially 204 more demanding application which would not only look at specific 205 characteristics of flows, but that may also use a stateful packet 206 flow analysis for detecting specific, suspicious activities, or 207 unusally frequent activities. Such activities may be characterized by 208 specific communication patterns, detectable by characteristic 209 sequences of certain packet types. 211 2.5 Network Surveillance 213 This application class requires collection and storage of information 214 that characterizes flows, and possibly also the collection and 215 storage of selected packets. One obvious use for network surveillance 216 is the collection of evidence of illegal activities for the purpose 217 of law enforcement. As the data collected for the purpose of network 218 surveillance contains sensitive information, adequate security 219 mechanisms are required in order to avoid misuse of the sensitive 220 information. 222 2.6 QoS Monitoring 224 QoS monitoring is the non-intrusive (passive) measurement of quality 225 parameters for single flows or traffic aggregates. In contrast to 226 intrusive (active) measurements, non-intrusive measurements utilize 227 the existing traffic in the network for QoS analysis. Since no test 228 traffic is sent, non-intrusive measurements can only be applied in 229 situations where the traffic of interest is already present in the 230 network. One example application is the validation of QoS parameters 231 negotiated in a service level specification (SLS). 233 Non-intrusive measurements cannot provide the kind of controllable 234 experiments that can be achieved with active measurements. On the 235 other hand non-intrusive measurements do not suffer from undesired 236 side effects caused by sending test traffic (e.g. additional load, 237 "Heisenberg" effects, potential differences in treatment of test 238 traffic and real customer traffic) 240 QoS monitoring often requires the correlation of data from multiple 241 measurement instances (e.g. for measuring one-way metrics). This 242 requires proper clock synchronization of the involved measurement 243 instances. For some measurements packet events at the different 244 measurement points must be correlated. For this, the provisioning of 245 post-processing functions (e.g. the generation of packet IDs) at the 246 measurement instances would be useful. Furthermore QoS monitoring 247 can lead to a huge amount of measurement result data. Therefore it 248 would highly benefit from mechanisms to reduce the measurement data, 249 like aggregation of results and sampling. 251 3. Distinguishing Flows 253 The following are requirements for distinguishing flows. They specify 254 the required availability of properties of observed packets for 255 mapping packets to flows. A traffic measuring device MUST support the 256 separation of packets by single properties as well as by combinations 257 of properties listed below. 259 3.1. Interfaces 261 The measuring device MUST be able to separate flows by the network 262 interface at which the packet was observed. If the packet enters the 263 device at one interface and leaves it at a different interface, flow 264 separation by the incoming interface MUST be supported as well as 265 separation by the outgoing interface(s). 267 3.2. Packet Treatment 269 The measuring device SHOULD be able to separate flows by the 270 treatment it applies to the packet, such as pure observation, 271 reception, forwarding, discarding. 273 3.3. IP Header Fields 275 The measuring device MUST, SHOULD, or MAY be able to separate flows 276 by the following fields of the IP header as indicated. It MUST 277 support separation by a single field as well as separation by 278 arbitrary combinations of all REQUIRED fields: 279 1. source address (MUST) 280 2. destination address (MUST) 281 3. transport protocol type (MUST) 282 4. version number (SHOULD) 283 5. time to live (MAY) 284 For source address and destination address separating by full match 285 MUST be supported as well as separation by a partial match. 287 3.4. Transport Header Fields 289 The measuring device MUST be able to separate flows by the port 290 numbers of the transport header in case of TCP or UDP being used as 291 transport protocol. Both, source and destination port number MUST be 292 supported for distinguishing flows, individually as well as in 293 combination. 295 3.5. MPLS Label 297 If the measuring device supports Multiprotocol Label Switching (MPLS, 298 see [RFC3031]) and if this support is activated, then the measuring 299 device MUST be able to separate flows by the MPLS label. 301 3.6. DiffServ Code Point 303 If the measuring device supports Differentiated Services (DiffServ) 304 and if this support is activated, then the measuring device MUST be 305 able to separate flows by the DiffServ Code Point (DSCP, see 306 [RFC2474]). 308 4. Metering Process 310 The following are requirements for the metering process. They 311 describe the requirements for the process at the measurement 312 instance. 314 4.1. Reliability 316 The measurement process MUST either be reliable or missing 317 reliability MUST be known and indicated. The measurement process is 318 reliable, if each packet passing the point of observation is measured 319 according to the configuration of the measuring device. If, e.g. due 320 to some overload, not all passing packets can be included into the 321 measurement process, then it SHOULD be stored at the measuring 322 device, that flows might be measured inaccurately. 324 4.2. Sampling 326 The measuring device MAY support measuringe traffic by packet 327 sampling. If sampling is supported the sampling method and its 328 parameters MUST be well defined. The device MAY offer a mechanism for 329 automatically switching to sampling (or to a more coarse flow 330 definition) in case of certain events, such as device overloaded. If 331 automatic switch to sampling or automated switch of the sampling rate 332 is supported, the events triggering a switch and the chosen sampling 333 method and parameters after a switch MUST be well defined. 335 4.3. Timestamps 337 The measuring device MUST be able to generate timestamps for observed 338 packets. For each accounted flow it MUST be possible to measure at 339 least the timestamps of the first and the last packet observed. 341 4.4. Timeout 343 The measuring device MUST be able to detect flow timeout. A flow is 344 considered to be timed out if no packet of this flow has been 345 observed for a given timeout interval. 347 4.5. Header Compression 349 If the measuring device is able to interpret or forward compressed IP 350 headers, then it MUST account all passing packets with compressed 351 headers as if they were not compressed. 353 4.6. Ignore Port Copy 355 The measuring device MAY be able to igore packets which are generated 356 by a port copy function acting at the same device. 358 5. Data Export 360 The following are requirements for exporting measured flow data out 361 of the measuring device. We separate requirements concerning the data 362 model and the information model from requirements concerning the data 363 transport, and from requirements concerning the reporting interval. 365 5.1. Information Model 367 The information model describes what information is exported. The 368 measuring device MUST be able to report the following attributes for 369 each measured flow: 370 1. flow specification Index 371 It is assumed that configuring flow measurement includes 372 stating a set of flow specifications, each of them specifying a 373 single flow or a set of flows. Reports on measured flows MUST 374 for each reported contain an index or other identifier 375 indicating the flow specification (or in case of overlapping 376 specifications: one of the flow specifications) which caused 377 the measuring device to measure the particular flow. 378 2. IP version number 379 3. source address 380 4. destination address 381 5. transport type 382 6. source port number 383 7. incoming interface 384 8. outgoing interfaces 385 9. packet treatment (observed only, received, forwarded, dropped) 386 10. packet counter 387 11. dropped packet counter 388 12. payload byte counter 389 13. in case of IPv4: Type of Service 390 14. in case of IPv6: Flow Label 391 15. if MPLS is supported and activated: MPLS label 392 16. if DiffServ is supported and activated: DSCP 393 17. timestamp of the first packet observed 394 18. timestamp of the last packet observed 395 19. timeout indication 396 20. sampling method 397 21. sampling parameters 398 22. unique identifier of the observation point 399 23. unique identifier of the measuring device 401 The measuring device SHOULD be able to report the following 402 attributes for each measured flow: 403 24. Time To Live 404 25. IP header flags 405 26. TCP header flags 407 5.2 Data Model 409 The data model describes how information is represented in flow 410 records. The data model used for exporting flow data MAY be flexible 411 concerning the flow attributes contained in reports. A flexible 412 record format would offer the possibility of defining records in a 413 flexibility way regarding the number and type of report attributes. 415 The data model MUST be extensible for future attributes to be added. 416 Even if a set of attributes is fixed in the flow record, the data 417 model MUST provide a way of extending the record by configuration or 418 for certain implementations. 420 5.3. Data Transfer 422 Requirements for the data transfer include reliability and security 423 requirements. These requirements do not apply to the measuring device 424 alone, but also to the transport network. Consequently, the 425 measurement device does not necessarily have to guarantee that all 426 requirements are met. Particularly the security requirements might be 427 guaranteed already by the network used for data transfer. Then these 428 requirements do not have to be considered anymore by the measuring 429 device. Therefore, these requirements are OPTIONAL for the measuring 430 device, although they may be REQUIRED for the data transfer as 431 specified in the appendix. 433 5.3.1. Reliability 435 The data transfer mechanism MUST either be reliabe, or it MUST 436 indicate loss of packets and packet reordering during transport. 438 5.3.2. Confidentiality 440 The measuring device MAY provide means for ensuring confidentiality 441 of the reported data, e.g. by encryption. 443 5.3.3 Integrity 445 The measuring device MAY provide means for ensuring integrity of the 446 reported data. 448 5.3.3 Authenticity 450 The measuring device MAY provide means for ensuring authenticity of 451 the reported data. 453 5.4. Reporting Times 455 In general, there are two ways of deciding on reporting times: push 456 mode and pull mode. In push mode, the measuring device decides 457 without an external trigger on when to send a report on measured 458 flows. In pull mode, sending a report is triggered by an explicit 459 request from a data collector or some other receiver of flow records. 460 The measuring device MUST support push mode reporting, it MAY support 461 pull mode reporting. 463 5.4.1. Regular Interval 465 The measuring device MUST be capable of reporting measured traffic 466 data regularly according to a given interval length. 468 5.4.2. Notification on Flow Account Opening 470 The measuring device MUST be capable of sending notifications to a 471 consumer of measure data, that indicate the arrival of the first 472 packet of a new flow account. 474 5.4.3. Notification on Flow Account Closing 476 The measuring device MUST be capable of sending notifications to a 477 consumer of measure data, that indicate the closing of an account. An 478 account for a specific flow might for example be closed after a 479 certain timeout expires. 481 5.5. Anonymization 483 The measuring device SHOULD be capable of anonymizing source and 484 destination IP addresses in flow data before exporting them. It 485 SHOULD support anonymization of port numbers and MAY support the 486 anonymizing of other fields. Please note that anonymization is not 487 originally an application requirement, but derived from general 488 requirements for treatment of traffic within a network. 490 6. Configuration 492 The measuring device MUST provide a way of configuring traffic 493 measurement and traffic data export remotely. The following 494 parameters MUST be configurable: 495 1. specification of the observation point, e.g. a list of 496 interfaces 497 2. specifications of flows to be measured 498 3. reporting data format 499 Specifying the reporting data format SHOULD include a selection 500 of attributes to be reported for each flow. 501 4. reporting interval 502 5. notifications 503 6. flow timeouts 504 7. sampling method and parameters, if feature is supported 505 8. flow anonymization, if feature is supported 507 The measuring device SHOULD support security of remote configuration 508 including confidentiality, integrity and authenticity. 510 7. General Requirements 512 7.1. Openness 514 IPFX specifications SHOULD be open to future technologies. This 515 includes extensibility of configuration of measurement and reporting 516 as well as extensibility of the reporting data model used for 517 reporting. 519 7.2. Scalability concerning measuring devices 521 Data collection from at least hundreds of different measuring devices 522 MUST be supported. This includes a unique identification of the 523 measuring device. 525 8. Open Issues 527 The following issues need to be discussed and included into the 528 document: 529 1. requirements for measuring multicast traffic 530 Shall the number of outgoing packets originating from a single 531 incoming packet be reported? Shall all outgoing ports used by a 532 multicast session be reported? 533 2. Scalability concerning number of flows 534 3. Adding AS# to section 5.1. 535 4. IP Fragmentation 536 How shall fragmented packets be counted? Is fragmentation to be 537 reported? 538 5. Security 539 A lot of security issues need to be discussed including 540 - secure configuration 541 - exporting payload? 542 - TCP header fields and IPSec 543 - option for encryption of reported flow records? 545 9. Security Considerations 547 The configuration of a meter and the export of IP Flow information 548 has a number of possible security threats such as unauthorized 549 access, modification or disclosure of the exported flow information. 550 Depending on whether information about the originator of the flow is 551 allowed to be revealed privacy protection may be an issue. 553 The transport of IP flow and configuration information can be secured 554 through the use of end-to-end encryption, as e.g. provided by IPSec. 555 The meter must be protected against unauthorized access at the 556 configuration interface. For inter-domain scenarios the access 557 control provided by SNMPv3 [RFC 2274] appears adequate. For other 558 scenarios such as third party measurement or inter-domain 559 authorization control, a AAA protocol and AAA servers may be 560 necessary. This access control can be controlled by policies which 561 can be very fine grained such that a certain user is allowed to get 562 only specific flow information. If privacy of the flow originator is 563 of concern all flow information which contains sensitive data must be 564 at least partially anonymized. 566 10. References 568 [MIDBOXTAX] B. Carpenter, "Middleboxes: taxonomy and issues", 569 draft-carpenter-midtax-01.txt, work in progress. 571 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 572 Switching Architecture", RFC 3031, January 2001. 574 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition 575 of the Differentiated Services Field (DS Field) in the IPv4 576 and IPv6 Headers", RFC 2474, December 1998. 578 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 579 "Requirements for Traffic Engineering Over MPLS", 580 RFC 2702, September 1999. 582 [RFC2274] U. Blumenthal, B. Wijnen "User-based Security Model (USM) 583 for version 3 of the Simple Network Management Protocol 584 (SNMPv3), RFC 2274, January 1998. 586 11. Authors' Addresses 588 Juergen Quittek 589 NEC Europe Ltd. 590 Adenauerplatz 6 591 69115 Heidelberg 592 Germany 594 Phone: +49 6221 90511-15 595 EMail: quittek@ccrle.nec.de 596 Tanja Zseby 597 GMD FOKUS 598 Kaiserin-Augusta-Allee 31 599 10589 Berlin 600 Germany 602 Phone: +49 30 3463 7153 603 Email: zseby@fokus.gmd.de 605 Georg Carle 606 GMD FOKUS 607 Kaiserin-Augusta-Allee 31 608 10589 Berlin 609 Germany 611 Phone: +49 30 3463 7149 612 Email: carle@fokus.gmd.de 614 Sebastian Zander 615 GMD FOKUS 616 Kaiserin-Augusta-Allee 31 617 10589 Berlin 618 Germany 620 Phone: +49 30 3463 7287 621 Email: zander@fokus.gmd.de 623 Appendix: Derivation of Requirements form Target Applications 625 The following table documents, how the requirements stated in 626 sections 3-7 are derived from requirements of the applications listed 627 in section 2. 629 Used abbreviations: 630 M = MUST 631 S = SHOULD 632 O = MAY (OPTIONAL) 633 - = DONT CARE 635 -----------------------------------------------------------------------. 636 IPFX | 637 ----------------------------------------------------------------. | 638 F: QoS Monitoring | | 639 ----------------------------------------------------------. | | 640 E: Network Surveillance | | | 641 ----------------------------------------------------. | | | 642 D: Attack/Intrusion Detection | | | | 643 ----------------------------------------------. | | | | 644 C: Traffic Engineering | | | | | 645 ----------------------------------------. | | | | | 646 B: Traffic Profiling | | | | | | 647 ----------------------------------. | | | | | | 648 A: Usage Accounting | | | | | | | 649 ----------------------------. | | | | | | | 650 | | | | | | | | 651 | Sect. | Requirement | A | B | C | D | E | F | IPFX | 652 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 653 | | GENERAL REQ | 654 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 655 | | | | | | | | | | 656 | 7.2. |Scalability: | | | | | | | | 657 | |data collection | M | S | M | O | M | S | M | 658 | |from hundreds of | | | | | | | | 659 | |measurement devices| | | | | | | | 660 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 661 | | FLOW DISTINGUISH | 662 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 663 | 3. |Combination of | M | M | M | M | M | M | M | 664 | |required attributes| | | | | | | | 665 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 666 | 3.1. |in/out IF | S | M | M | S | S | S | M | 667 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 668 | 3.2. |Packet treatment | O | O | S | O | O | S | S | 669 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 670 | 3.3. |src/dst address | M | M | M | M | M | M | M | 671 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 672 | 3.3. |Masking of IP | M | M | M | M | M | M | M | 673 | |adresses | | | | | | | | 674 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 675 | 3.3. |transport protocol | M | M | - | M | M | M | M | 676 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 677 | 3.3. |version field | - | S | S | O | O | O | S | 678 | | | | | (b) | | | | | 679 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 680 | 3.3. |TTL | - | O | - | O | - | - | O | 681 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 682 | 3.4. |src/dst port | M | M | - | M | M | M | M | 683 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 684 | 3.5. |MPLS label (a) | S | S | M | O | - | S | M | 685 | | | | | (c) | | | | | 686 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 687 | 3.6. |DSCP (a) | M | S | M | O | - | M | M | 688 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 689 | |METERING PROCESS | 690 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 691 | 4.1. |Reliability | M | S | S | S | M | S | | 692 |-------+-------------------+-----+-----+-----+-----+-----+-----+ M | 693 | 4.1. |Indication of | - | M | M | M | - | M | | 694 | |missing reliability| | | | | | | | 695 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 696 | 4.2. |Sampling | O | O | O | O | - | O | O | 697 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 698 | 4.2. |Dynamic sampling | O | O | O | O | - | O | O | 699 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 700 | 4.3. |Timestamping at | M | O | O | S | S | M | M | 701 | |measurement device | | | | | | | | 702 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 703 | 4.4. |Flow timeout | M | s | - | O | O | O | M | 704 | | | (d) | | | | | | | 705 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 706 | 4.5. |Process compressed | M | M | M | M | M | M | M | 707 | |headers (a) | | | | | | | | 708 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 709 | 4.6. |Ignore port copy | O | O | O | O | O | O | O | 710 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 711 | |REPORT ATTRIBUTES | 712 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 713 | | => TODO | | | | | | | | 714 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 715 | |DATA MODEL | 716 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 717 | 5.2. |Flexibility | O | O | O | O | O | O | O | 718 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 719 | 5.2. |Extensibility | M | M | M | M | M | M | M | 720 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 721 | |DATA TRANSFER | 722 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 723 | 5.3.1 |Reliability | M | S | S | S | M | S | M | 724 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 725 | 5.3.2 |Confidentiality | S | S | S | S | S | S | S | 726 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 727 | 5.3.3 |Integrity | M | M | M | M | M | M | M | 728 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 729 | 5.3.4 |Authenticity | M | M | M | M | M | M | M | 730 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 731 | |REPORTING TIMES | 732 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 733 | 5.4. |Push mode | M | O | O | M | O | S | M | 734 | | | | (e) | (e) | | (e) |(e,f)| | 735 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 736 | 5.4. |Pull mode | O | O | O | O | O | O | O | 737 | | | | (e) | (e) | | (e) | (e) | | 738 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 739 | 5.4.1 |Regular Interval | S | S | S | S | S | S | S | 740 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 741 | 5.4.2 |Flow Acct. Opening | S | O | O | M | O | S | M | 742 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 743 | 5.4.3 |Flow Acct. Closing | M | O | O | M | O | S | M | 744 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 745 | |CONFIGURATION | 746 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 747 | |=> TODO | | | | | | | | 748 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 749 | | | | | | | | | | 750 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 752 Remarks: 753 (a) if feature is supported 754 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 755 So we tended to make this a MUST. Nevertheless, a SHOULD seems 756 to be sufficient to perform most TE tasks and allows us to have 757 a SHOULD for IPFX instead of a MUST. 758 (c) For TE in an MPLS network the label is essential. Therefore a 759 MUST is given here leading to a MUST in IPFX 760 (d) Precise time-based accounting requires reaction to a flow 761 timeout. 762 (e) Either push or pull has to be supported. 763 (f) Required, in order to immediately report drop indications for 764 SLA validation