idnits 2.17.1 draft-ietf-psamp-framework-08.txt: -(158): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(171): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(178): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(181): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(444): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 1551. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1571), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 113. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 18 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations are addressed in:' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 2 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 39 has weird spacing: '...porting proce...' == Line 448 has weird spacing: '...etering proce...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2004) is 7156 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC-2330' on line 1447 looks like a reference -- Missing reference section? 'PSAMP-TECH' on line 1377 looks like a reference -- Missing reference section? 'PSAMP-MIB' on line 1383 looks like a reference -- Missing reference section? 'PSAMP-PROTO' on line 1388 looks like a reference -- Missing reference section? 'PSAMP-INFO' on line 1393 looks like a reference -- Missing reference section? 'IPFIX-REQUIRE' on line 1456 looks like a reference -- Missing reference section? 'IPv4' on line 475 looks like a reference -- Missing reference section? 'RFC-2460' on line 1417 looks like a reference -- Missing reference section? 'RFC-3031' on line 1464 looks like a reference -- Missing reference section? 'RFC-2804' on line 1436 looks like a reference -- Missing reference section? 'RFC-2914' on line 1433 looks like a reference -- Missing reference section? 'RFC-3176' on line 1443 looks like a reference -- Missing reference section? 'IPFIX-INFO' on line 1403 looks like a reference -- Missing reference section? 'SCTP' on line 964 looks like a reference -- Missing reference section? 'RFC-3758' on line 1476 looks like a reference -- Missing reference section? 'UDP' on line 1453 looks like a reference -- Missing reference section? 'IPFIX-PROTO' on line 1412 looks like a reference -- Missing reference section? 'DuGeGr02' on line 1424 looks like a reference -- Missing reference section? 'DuGr01' on line 1420 looks like a reference -- Missing reference section? 'DuGr04' on line 1429 looks like a reference -- Missing reference section? 'Zs02' on line 1480 looks like a reference -- Missing reference section? 'RFC-1213' on line 1439 looks like a reference -- Missing reference section? 'B88' on line 1400 looks like a reference -- Missing reference section? 'ClPB93' on line 1407 looks like a reference -- Missing reference section? 'RFC-791' on line 1450 looks like a reference -- Missing reference section? 'RFC1771' on line 1461 looks like a reference -- Missing reference section? 'SPSJTKS01' on line 1468 looks like a reference -- Missing reference section? 'RFC-2960' on line 1473 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 31 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Nick Duffield (Editor) 3 Category: Informational AT&T Labs � Research 4 Document: September 2004 5 Expires: March 2005 7 A Framework for Packet Selection and Reporting 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum 18 of six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document specifies a framework for the PSAMP (Packet 32 SAMPling) protocol. The functions of this protocol are to select 33 packets from a stream according to a set of standardized 34 selectors, to form a stream of reports on the selected packets, 35 and to export the reports to a collector. This framework details 36 the components of this architecture, then describes some generic 37 requirements, motivated the dual aims of ubiquitous deployment 38 and utility of the reports for applications. Detailed 39 requirements for selection, reporting and exporting processes 40 are described, along with configuration requirements of the PSAMP 41 functions. 43 Comments on this document should be addressed to the PSAMP 44 Working Group mailing list: psamp@ops.ietf.org 46 To subscribe: psamp-request@ops.ietf.org, in body: subscribe 47 Archive: https://ops.ietf.org/lists/psamp/ 49 Table of Contents 51 1. Introduction...............................................3 52 2. PSAMP Documents Overview...................................4 53 3. Elements, Terminology and High-level Architecture..........4 54 3.1 High-level description of the PSAMP Architecture ..........4 55 3.2 Observation Points, Packet Streams and Packet Content......5 56 3.3 Selection Process .........................................6 57 3.4 Reporting Process .........................................7 58 3.5 Measurement Process........................................8 59 3.6 Exporting Process .........................................8 60 3.7 PSAMP Device...............................................8 61 3.8 Collector..................................................8 62 3.9 Possible Configurations....................................9 63 3.10 PSAMP and IPFIX Interaction................................9 64 4. Generic Requirements for PSAMP.............................9 65 4.1 Generic Selection Process Requirements....................10 66 4.2 Generic Reporting Process Requirements....................10 67 4.3 Generic Exporting process Requirements....................11 68 4.4 Generic Configuration Requirements........................11 69 5. Packet Selection Operations...............................12 70 5.1 Two Types of Selection Operation..........................12 71 5.2 PSAMP Packet Selection Operations ........................12 72 5.3 Selection Rate Terminology................................14 73 5.4 Input Sequence Numbers for Primitive Selection Processes..15 74 5.5 Composite Selectors.......................................15 75 5.6 Constraints on the Sampling Frequency.....................16 76 6. Reporting Process ........................................16 77 6.1 Mandatory Contents of Packet Reports......................16 78 6.2 Extended Packet Reports...................................17 79 6.3 Extended Packet Reports in the Presence of IPFIX .........17 80 6.4 Report Interpretation.....................................17 81 6.5 Export Packet Compression ................................18 82 7. Parallel Measurement Processes............................18 83 8. Exporting Process ........................................19 84 8.1 Use of IPFIX..............................................19 85 8.2 Congestion-aware Unreliable Transport.....................19 86 8.3 Limiting Delay for Export Packets ........................19 87 8.4 Configurable Export Rate Limit............................21 88 8.5 Collector Destination.....................................21 89 8.6 Local Export..............................................21 90 9. Configuration and Management..............................21 91 10. Feasibility and Complexity................................22 92 10.1 Feasibility...............................................22 93 10.1.1 Filtering...............................................22 94 10.1.2 Sampling ...............................................22 95 10.1.3 Hashing.................................................23 96 10.1.4 Reporting...............................................23 97 10.1.5 Export..................................................23 98 10.2 Potential Hardware Complexity.............................23 99 11. Applications..............................................24 100 11.1 Baseline Measurement and Drill Down.......................25 101 11.2 Trajectory Sampling.......................................25 102 11.3 Passive Performance Measurement...........................25 103 11.4 Troubleshooting...........................................26 104 12. Security Considerations...................................27 105 13. Normative References......................................27 106 14. Informative References....................................28 107 15. Authors' Addresses........................................29 108 16. Intellectual Property Statements..........................31 109 17. Full Copyright Statement..................................31 111 Copyright (C) The Internet Society (2004). All Rights Reserved. 112 This document is an Internet-Draft and is in full conformance 113 with all provisions of Section 10 of RFC 2026. 115 Internet-Drafts are working documents of the Internet Engineering 116 Task Force (IETF), its areas, and its working groups. Note that 117 other groups may also distribute working documents as Internet- 118 Drafts. 120 Internet-Drafts are draft documents valid for a maximum of six 121 months and may be updated, replaced, or obsoleted by other 122 documents at any time. It is inappropriate to use Internet- 123 Drafts as reference material or to cite them other than as "work 124 in progress." 126 The list of current Internet-Drafts can be accessed at 127 http://www.ietf.org/ietf/1id-abstracts.txt 129 The list of Internet-Draft Shadow Directories can be accessed at 130 http://www.ietf.org/shadow.html. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 133 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 RFC 2119. 137 1. Introduction 139 This document describes the PSAMP framework for network elements 140 to select subsets of packets by statistical and other methods, 141 and to export a stream of reports on the selected packets to a 142 collector. 144 The motivation for the PSAMP standard comes from the need for 145 measurement-based support for network management and control 146 across multivendor domains. This requires domain wide consistency 147 in the types of selection schemes available, the manner in which 148 the resulting measurements are presented, and consequently, 149 consistency of the interpretation that can be put on them. 151 The motivation for specific packet selection operations comes 152 from the applications that they enable. Development of the PSAMP 153 standard is open to influence by the requirements of standards in 154 related IETF Working Groups, for example, IP Performance Metrics 155 (IPPM) [RFC-2330] and Internet Traffic Engineering (TEWG). 157 The name PSAMP is a contraction of the phrase Packet Sampling. 158 The word �sampling� captures the idea that only a subset of all 159 packets passing a network element will be selected for reporting. 160 But PSAMP selection operations include random selection, 161 deterministic selection (filtering), and deterministic 162 approximations to random selection (hash-based selection). 164 2. PSAMP Documents Overview 166 PSAMP-FRAMEWORK: �A Framework for Packet Selection and 167 Reporting�: this document. This document describes the PSAMP 168 framework for network elements to select subsets of packets by 169 statistical and other methods, and to export a stream of reports 170 on the selected packets to a collector. Definitions of 171 terminology and the use of the terms �must�, �should� and �may� 172 in this document are informational only. 174 [PSAMP-TECH]: �Sampling and Filtering Techniques for IP Packet 175 Selection�, describes the set of packet selection techniques 176 supported by PSAMP. 178 [PSAMP-MIB]: �Definitions of Managed Objects for Packet Sampling� 179 describes the PSAMP Management Information Base 181 [PSAMP-PROTO]: �Packet Sampling (PSAMP) Protocol Specifications� 182 specifies the export of packet information from a PSAMP Exporting 183 Process to a PSAMP Colleting Process 185 [PSAMP-INFO]: �Information Model for Packet Sampling Exports� 186 defines an information and data model for PSAMP. 188 3. Elements, Terminology and High-level Architecture 190 3.1 High-level description of the PSAMP Architecture 192 Here is an informal high level description of the PSAMP protocol 193 operating in a PSAMP device (all terms will be defined 194 presently). A stream of packets is observed at an observation 195 point. A selection process inspects each packet to determine 196 whether it should be selected. A reporting process constructs a 197 report on each selected packet, using the packet content, and 198 possibly other information such as the packet treatment or the 199 arrival timestamp. An exporting process sends the reports to a 200 collector, together with any subsidiary information needed for 201 their interpretation. 203 The following figure indicates the sequence of the three 204 processes (selection, reporting, and exporting) within the PSAMP 205 device. The composition of the selection process followed by the 206 reporting process is known as the measurement process. 208 +---------+ +---------+ +---------+ 209 Observed |Selection| |Reporting| |Exporting| 210 Packet--->|Process |--->|Process |--->|Process |--->Collector 211 Stream +---------+ +---------+ +---------+ 212 \----Measurement Process-----/ 214 The following sections give the detailed definitions of each of 215 all the objects just named. 217 3.2 Observation Points, Packet Streams and Packet Content 219 This section contains the definition of terms relevant to 220 obtaining the packet input to the selection process. 222 * Observation Point 224 An observation point is a location in the network where packets 225 can be observed. Examples include: 227 (i) a line to which a probe is attached; 228 (ii) a shared medium, such as an Ethernet-based LAN; 229 (iii) a single port of a router, or set of interfaces 230 (physical or logical) of a router; 231 (iv) an embedded measurement subsystem within an 232 interface. 234 Note that one observation point may be a superset of several 235 other observation points. For example one observation point 236 can be an entire line card. This would be the superset of the 237 individual observation points at the line card's interfaces. 239 * Observed Packet Stream 241 The observed packet stream is the set of all packets observed 242 at the observation point. 244 * Packet Stream 246 A packet stream denotes a subset of the observed packet stream. 248 * Packet Content 250 The packet content denotes the union of the packet header 251 (which includes link layer, network layer and other 252 encapsulation headers) and the packet payload. 254 Note that packets selected from a stream, e.g. by sampling, do 255 not necessarily possess a property by which they can be 256 distinguished from packets that have not been selected. For this 257 reason the term �stream� is favored over �flow�, which is defined 258 as set of packets with common properties [IPFIX-REQUIRE]. 260 3.3 Selection Process 262 This section defines the selection process and related objects. 264 * Selection Process 266 A selection process takes a packet stream as its input and 267 selects a subset of that stream as its output. 269 * Selection State: 271 A selection process may maintain state information for use 272 by the selection process and/or the reporting process. At a 273 given time, the selection state may depend on packets 274 observed at and before that time, and other variables. 275 Examples include: 277 (i) sequence numbers of packets at the input of 278 selectors; 280 (ii) a timestamp of observation of the packet at the 281 observation point; 283 (iii) iterators for pseudorandom number generators; 285 (iv) hash values calculated during selection; 287 (v) indicators of whether the packet was selected by 288 a given selector; 290 Selection processes may change portions of the selection 291 state as a result of processing a packet. Selection state 292 for a packet is to reflect the state after processing the 293 packet. 295 * Selector: 297 A selector defines the action of a selection process on a 298 single packet of its input. A selected packet becomes an 299 element of the output packet stream of the selection 300 process. 302 The selector can make use of the following information in 303 determining whether a packet is selected: 305 (i) the packet�s content; 307 (ii) information derived from the packet's treatment at the 308 observation point; 310 (iii) any selection state that may be maintained by the 311 selection process. 313 * Composite Selection Process: 315 A composite selection process is an ordered composition of 316 selection processes, in which the output stream issuing from 317 one component forms the input stream for the succeeding 318 component. 320 * Composite Selector: 322 A selector is composite if it defines a composite selection 323 process. 325 * Primitive Selection Process: 327 A selection process is primitive if it is not a composite a 328 selection process. 330 * Primitive Selector: 332 A selector is primitive if it defines a primitive selection 333 process. 335 3.4 Reporting Process 337 * Reporting Process: 339 A reporting process creates a report stream on packets 340 selected by a selection process, in preparation for export. 341 The input to the reporting process comprises that 342 information available to the selection process per selected 343 packet, specifically: 345 (i) the selected packet�s content; 347 (ii) information derived from the selected packet's 348 treatment at the observation point; 350 (iii) any selection state maintained by the inputting 351 selection process, reflecting any modifications to the 352 selection state made during selection of the packet. 354 * Packet Reports: 356 Packet reports comprise a configurable subset of a packet�s 357 input to the reporting process, including the packet�s 358 content, information relating to its treatment 359 (for example, the output interface), and its associated 360 selection state (for example, a hash of the packet�s 361 content) 363 * Report Interpretation: 365 Report interpretation comprises subsidiary information, 366 relating to one or more packets, that is used for 367 interpretation of their packet reports. Examples include 368 configuration parameters of the selection process and of the 369 reporting process. 371 * Report Stream: 373 The report stream is the output of a reporting process, 374 comprising two distinguished types of information: packet 375 reports, and report interpretation. 377 3.5 Measurement Process 379 * A Measurement Process is the composition of a selection process 380 that takes the observed packet stream as its input, followed by 381 a reporting process. 383 3.6 Exporting Process 385 * Exporting Process: 387 An exporting process sends, in the form of export packet, the 388 output of one or more measurement processes to one or more 389 collectors. 391 * Export Packets: 393 a combination of report interpretation and/or one or more 394 packet reports are bundled by the exporting process into a 395 export packet for exporting to a collector. 397 3.7 PSAMP Device 399 A PSAMP Device is a device hosting at least an observation point, 400 a measurement process and an exporting process. Typically, 401 corresponding observation point(s), measurement process(es) and 402 exporting process(es) are co-located at this device, for example 403 at a router. 405 3.8 Collector 406 A collector receives a report stream exported by one or more 407 exporting processes. In some cases, the host of the measurement 408 and/or exporting processes may also serve as the collector. 410 3.9 Possible Configurations 412 Various possibilities for the high level architecture of these 413 elements are as follows. 415 MP = Measurement Process, EP = Exporting process 417 PSAMP Device 418 +---------------------+ +------------------+ 419 |Observation Point(s) | | Collector(1) | 420 |MP(s)--->EP----------+---------------->| | 421 |MP(s)--->EP----------+-------+-------->| | 422 +---------------------+ | +------------------+ 423 | 424 PSAMP Device | 425 +---------------------+ | +------------------+ 426 |Observation Point(s) | +-------->| Collector(2) | 427 |MP(s)--->EP----------+---------------->| | 428 +---------------------+ +------------------+ 430 PSAMP Device 431 +---------------------+ 432 |Observation Point(s) | 433 |MP(s)--->EP---+ | 434 | | | 435 |Collector(3)<-+ | 436 +---------------------+ 438 3.10 PSAMP and IPFIX Interaction 440 The PSAMP measurement process can be viewed as analogous to the 441 IPFIX metering process. The PSAMP measurement process takes an 442 observed packet stream as its input, and produces packet reports 443 as its output. The IPFIX metering process produces flow records 444 as its output. The distinct name �measurement process� has been 445 retained in order to avoid potential confusion in settings where 446 IPFIX and PSAMP coexist, and in order to avoid the implicit 447 requirement that the PSAMP version satisfy the requirements of an 448 IPFIX metering process (at least while these are under 449 development). The relationship between PSAMP and IPFIX is 450 described more in [PSAMP-INFO]. 452 4. Generic Requirements for PSAMP 454 This section describes the generic requirements for the PSAMP 455 protocol. A number of these are realized as specific requirements 456 in later sections. 458 4.1 Generic Selection Process Requirements. 460 * Ubiquity: The selectors must be simple enough to be implemented 461 ubiquitously at maximal line rate. 463 * Applicability: the set of selectors must be rich enough to 464 support a range of existing and emerging measurement based 465 applications and protocols. This requires a workable trade-off 466 between the range of traffic engineering applications and 467 operational tasks it enables, and the complexity of the set of 468 capabilities. 470 * Extensibility: the protocol must be able to accommodate 471 additional packet selectors not currently defined. 473 * Flexibility: the protocol must support selection of packets 474 using various network protocols or encapsulation layers, 475 including Internet Protocol Version 4 (IPv4) [IPv4], Internet 476 Protocol Version 6 (IPv6) [RFC-2460], and Multiprotocol Label 477 Switching (MPLS) [RFC-3031]. 479 * Robust Selection: packet selection must be robust against 480 attempts to craft an observed packet stream from which packets 481 are selected disproportionately (e.g. to evade selection, or 482 overload measurement systems). 484 * Parallel Measurement Processes: the protocol must support 485 simultaneous operation of multiple independent measurement 486 processes at the same host. 488 * Non-Contingency: the selection decision for each packet must 489 not depend on future packets. 491 * Encrypted Packets: selection operations based on interpretation 492 of packet fields must be configurable to ignore (i.e. not 493 select) encrypted packets, when they are detected. 495 Selectors are outlined in Section 5, and described in more detail 496 in the companion document [PSAMP-TECH]. 498 4.2 Generic Reporting Process Requirements 500 * Self-defining: the report stream must be complete in the sense 501 that no additional information need be retrieved from the 502 observation point in order to interpret and analyze the 503 reports. 505 * Indication of Information Loss: the reports stream must include 506 sufficient information to indicate or allow the detection of 507 loss occurring within the selection, reporting or exporting 508 processes, or in transport. This may be achieved by the use of 509 sequence numbers. 511 * Accuracy: the report stream must include information that 512 enables the accuracy of measurements to be determined. 514 * Faithfulness: all reported quantities that relate to the packet 515 treatment must reflect the router state and configuration 516 encountered by the packet at the time it is received by the 517 measurement process. 519 * Privacy: selection of the content of packet reports will be 520 cognizant of privacy and anonymity issues while being 521 responsive to the needs of measurement applications, and in 522 accordance with [RFC-2804]. Full packet capture of arbitrary 523 packet streams is explicitly out of scope. 525 A specific reporting process meeting these requirements, and the 526 requirement for ubiquity, is described in Section 6. 528 4.3 Generic Exporting process Requirements 530 * Timeliness: configuration must allow for limiting of buffering 531 delays for the formation and transmission for export reports. 532 See Section Error! Reference source not found. for further 533 details. 535 * Congestion Avoidance: export of a report stream across a 536 network must be congestion avoiding in compliance with [RFC- 537 2914]. 539 * Secure Export: 541 (i) confidentiality: the option to encrypt exported data must 542 be provided. 544 (ii) integrity: alterations in transit to exported data must be 545 detectable at the collector 547 (iii) authenticity: authenticity of exported data must be 548 verifiable by the collector in order to detect forged data. 550 The motivation here is the same as for security in IPFIX export; 551 see Sections 6.3 and 10 of [IPFIX-REQUIRE]. 553 4.4 Generic Configuration Requirements 555 * Ease of Configuration: of sampling and export parameters, e.g. 556 for automated remote reconfiguration in response to collected 557 reports. 559 * Secure Configuration: the option to configure via protocols 560 that prevent unauthorized reconfiguration or eavesdropping on 561 configuration communications must be available. Eavesdropping 562 on configuration might allow an attacker to gain knowledge that 563 would be helpful in crafting a packet stream to evade 564 subversion, or overload the measurement infrastructure. 566 Configuration is discussed in Section 9. Feasibility and 567 complexity of PSAMP operations is discussed in Section 10. 569 5. Packet Selection Operations 571 5.1 Two Types of Selection Operation 573 PSAMP categorizes selection operations into two types: 575 * Filtering: a filter is a selection operation that selects a 576 packet deterministically based on the packet content, its 577 treatment, and functions of these occurring in the selection 578 state. Two examples are: 580 (i) Mask/match filtering. 582 (ii) Hash-based selection: a hash function is applied to the 583 packet content, and the packet is selected if the result 584 falls in a specified range. 586 * Sampling: a selection operation that is not a filter is called 587 a sampling operation. This reflects the intuitive notion that 588 if the selection of a packet cannot be determined from its 589 content alone, there must be some type of sampling taking 590 place. 592 Sampling operations can be divided into two subtypes: 594 (i) Content-independent Sampling, which does not use packet 595 content in reaching sampling decisions. Examples include 596 periodic sampling, and uniform pseudorandom sampling 597 driven by a pseudorandom number whose generation is 598 independent of packet content. Note that in content- 599 independent sampling it is not necessary to access the 600 packet content in order to make the selection decision. 602 (ii) Content-dependent Sampling, in which the packet content is 603 used in reaching selection decisions. Examples include 604 pseudorandom selection according to a probability that 605 depends on the contents of a packet field; note that this 606 is not a filter. 608 5.2 PSAMP Packet Selection Operations 610 A spectrum of packet selection operations is described in detail 611 in [PSAMP-TECH]. Here we only briefly summarize the meanings for 612 completeness. 614 A PSAMP selection process must support at least one of the 615 following selectors. 617 * Systematic Time Based Sampling: packet selection is triggered 618 at periodic instants separated by a time called the spacing. 619 All packets that arrive within a certain time of the trigger 620 (called the interval length) are selected. 622 * Systematic Count Based Sampling: similar to systematic time 623 based expect that selection is reckoned with respect to packet 624 count rather than time. Packet selection is triggered 625 periodically by packet count, a number of successive packets 626 being selected subsequent to each trigger. 628 * Uniform Probabilistic Sampling: packets are selected 629 independently with fixed sampling probability p. 631 * Non-uniform Probabilistic Sampling: packets are selected 632 independently with probability p that depends on packet 633 content. 635 * Probabilistic n-out-of-N Sampling: form each count-based 636 successive block of N packets, n are selected at random. 638 * Mask/match Filtering: this entails taking the masking portions 639 of the packet (i.e. taking the logical �and� with a binary 640 mask) and selecting the packet if the result falls in a range 641 specified in the selection parameters of the filter. This 642 specification does not preclude the future definition of a high 643 level syntax for defining filtering in a concise way (e.g. TCP 644 port taking a particular value) providing that syntax can be 645 compiled into the bitwise expression. 647 Mask/match operations should be available for different 648 protocol portions of the packet header: 650 (i) the IP header (excluding options in IPv4, stacked 651 headers in IPv6) 653 (ii) transport header 655 (iii) encapsulation headers (e.g. the MPLS label stack) if 656 present) 658 When the PSAMP device offers mask/match filtering, and, in its 659 usual capacity other than in performing PSAMP functions, 660 identifies or processes information from one or more of the 661 above protocols, then the information should be made available 662 for filtering. For example, when a PSAMP device routes based on 663 destination IP address, that field should be made available for 664 filtering. Conversely, a PSAMP device that does not route is 665 not expected to be able to locate an IP address within a 666 packet, or make it available for filtering, although it may do 667 so. 669 Since packet encryption alters the meaning of encrypted fields, 670 Mask/Match filtering must be configurable to ignore encrypted 671 packets, when detected. 673 Hash-based Selection: Hash-based selection will employ one or 674 more hash functions to be standardized. A hash function is 675 applied to a subset of packet content, and the packet is 676 selected of the resulting hash falls in a specified range. With 677 a suitable hash function, hash based selection approximates 678 uniform random sampling. Applications of hash-based sampling 679 are described in Section 11. 681 * Router State Filtering: the selection process may support 682 filtering based on the following conditions, which may be 683 combined with the logical "and", "or" or "not" operators: 685 (i) Ingress interface at which packet arrives equals a 686 specified value 687 (ii) Egress interface to which packet is routed to equals a 688 specified value 689 (iii) Packet violated Access Control List (ACL) on the 690 router 691 (iv) Failed Reverse Path Forwarding (RPF) 692 (v) Failed Resource Reservation (RSVP) 693 (vi) No route found for the packet 694 (vii) Origin Border Gateway Protocol (BGP) Autonomous System 695 (AS) equals a specified value or lies within a given range 696 (viii) Destination BGP AS equals a specified value or lies 697 within a given range 699 Router architectural considerations may preclude some 700 information concerning the packet treatment, e.g. routing state, 701 being available at line rate for selection of packets. However, 702 if selection not based on routing state has reduced down from 703 line rate, subselection based on routing state may be feasible. 705 This section detailed specific requirements for the selection 706 process, motivated by the generic requirement of Section 3.3. 708 5.3 Selection Rate Terminology 710 The proportion of packets that are selected by a selection 711 operation is figured in two ways: 713 * Attained Selection Frequency: the actual frequency with which 714 packets are selected by a selection process. When packets are 715 selected from a set of packets in a stream, the attained 716 sampling frequency is calculated as ratio of the number of 717 packets selected to the number of packets in the set. 719 * Target Selection Frequency: the average frequency with which 720 packets are expected to be selected, based on selector 721 parameter settings. 723 For sampling operations, due to the inherent statistical 724 variability of sampling decisions, the target and attained 725 selection frequencies will not in general be equal, although 726 they may be close in some circumstances, e.g., when the 727 population size is large. 729 5.4 Input Sequence Numbers for Primitive Selection Processes 731 Each instance of a primitive selection process must maintain a 732 count of packets presented at its input. The counter value is to 733 be included as a sequence number for selected packets. The 734 sequence numbers are considered as part of the packet's selection 735 state. 737 Use of input sequence numbers enables applications to determine 738 the attained selection frequency, and hence correctly normalize 739 network usage estimates regardless of loss of information, 740 regardless of whether this loss occurs because of discard of 741 packet reports in the measurement or reporting process (e.g. due 742 to resource contention in the host of these processes), or loss 743 of export packets in transmission or collection. See [RFC-3176] 744 for further details. 746 As an example, consider a set of n consecutive packet reports r1, 747 r2,... , rn, selected by a sampling operation and received at a 748 collector. Let s1, s2,..., sn be the input sequence numbers 749 reported by the packets. The attained selection frequency, taking 750 into account both packet sampling at the observation point and 751 selection arising from loss in transmission, is R = (n-1)/(sn- 752 s1). (Note R would be 1 if all packets were selected and there 753 were no transmission loss). 755 The attained selection frequency can be used to estimate the 756 number bytes present in a portion of the observed packet stream. 757 Let b1, b2,..., bn be the bytes reported in each of the packets 758 that reached the collector, and set B = b1+b2+...+bn. Then the 759 total bytes present in packets in the observed packet stream 760 whose input sequence numbers lie between s1 and sn is estimated 761 by B/R, i.e, scaling up the measured bytes through division by 762 the attained selection frequency. 764 With composite selectors, and input sequence number must be 765 reported for each selector in the composition. 767 5.5 Composite Selectors 768 The ability to compose selectors in a selection process should be 769 provided. The following combinations appear to be most useful for 770 applications: 772 * filtering followed by sampling 774 * sampling followed by filtering 776 Composite selectors are useful for drill down applications. The 777 first component of a composite selector can be used to reduce the 778 load on the second component. In this setting, the advantage to 779 be gained from a given ordering can depend on the composition of 780 the packet stream. 782 5.6 Constraints on the Sampling Frequency 784 Sampling at full line rate, i.e. with probability 1, is not 785 excluded in principle, although resource constraints may not 786 support it in practice. 788 6. Reporting Process 790 This section detailed specific requirements for the reporting 791 process, motivated by the generic requirement of Section 3.4 793 6.1 Mandatory Contents of Packet Reports 795 The reporting process must include the following in each packet 796 report: 798 (i) the input sequence number(s) of any sampling operation 799 that acted on the packet in the instance of a measurement 800 process of which the reporting process is a component. 802 The reporting process must support inclusion of the following in 803 each packet report, as a configurable option: 805 (ii) a basic report on the packet, i.e., some number of 806 contiguous bytes from the start of the packet, including the 807 packet header (which includes link layer, network layer and 808 other encapsulation headers) and some subsequent bytes of 809 the packet payload. 811 Some devices hosting reporting processes may not have the 812 resource capacity or functionality to provide more detailed 813 packet reports that those in (i) and (ii) above. Using this 814 minimum required reporting functionality, the reporting process 815 places the burden of interpretation on the collector, or on 816 applications that it supplies. Some devices may have the 817 capability to provide extended packet reports, described in the 818 next section. 820 6.2 Extended Packet Reports 822 The reporting process may support inclusion in packet reports of 823 the following information, inclusion any or all being 824 configurable as an option. 826 (iii) fields relating to the following protocols used in the 827 packet: IPv4, IPV6, transport protocols, MPLS. 829 (iv) packet treatment, including: 831 - identifiers for any input and output interfaces of the 832 observation point that were traversed by the packet 834 - source and destination BGP AS 836 (v) selection state associated with the packet, including: 838 - the timestamp of observation of the packet at the 839 observation point. The timestamp should be reported to 840 microsecond resolution. 842 - hashes, where calculated. 844 It is envisaged that selection of fields for extended packet 845 reporting may be used to reduce reporting bandwidth, in which 846 case the option to report information in (ii) may not be 847 exercised. 849 6.3 Extended Packet Reports in the Presence of IPFIX 851 If an IPFIX metering process is supported at the observation 852 point, then in order to be PSAMP compliant, extended packet 853 reports must be able to include all fields required in the IPFIX 854 information model [IPFIX-INFO], with modifications appropriate to 855 reporting on single packets rather than flows. 857 6.4 Report Interpretation 859 Information for use in report interpretation must include 861 (i) configuration parameters of the selectors of the packets 862 reported on. 864 (ii) format of the packet report; 866 (iii) indication of the inherent accuracy of the reported 867 quantities, e.g., of the packet timestamp. 869 (iv) identifiers for observation point, measurement process, 870 and exporting process. 872 The accuracy measure in (iii) is of fundamental importance for 873 estimating the likely error attached to estimates formed from the 874 packet reports by applications. 876 Identifiers in (iv) are necessary, e.g., in order to match packet 877 reports to the selection process that selected them. For example, 878 when packet reports due to a sampling operation suffer loss 879 (either during export, or in transit) it may be desirable to 880 reconfigure downwards the sampling rate on the selection process 881 that selected them. 883 The requirements for robustness and transparency are motivations 884 for including report interpretation in the report stream. 885 Inclusion makes the report stream self-defining. The PSAMP 886 framework excludes reliance on an alternative model in which 887 interpretation is recovered out of band. This latter approach is 888 not robust with respect to undocumented changes in selector 889 configuration, and may give rise to future architectural problems 890 for network management systems to coherently manage both 891 configuration and data collection. 893 It is not envisaged that all report interpretation be included in 894 every packet report. Many of the quantities listed above are 895 expected to be relatively static; they could be communicated 896 periodically, and upon change. 898 6.5 Export Packet Compression 900 To conserve network bandwidth and resources at the collector, the 901 export packets may be compressed before export. Compression is 902 expected to be quite effective since the sampled packets may 903 share many fields in common, e.g. if a filter focuses on packets 904 with certain values in particular header fields. Using 905 compression, however, could impact the timeliness of packet 906 reports. Any consequent delay must not violate the timeliness 907 requirement for availability of packet reports at the collector. 909 7. Parallel Measurement Processes 911 Because of the increasing number of distinct measurement 912 applications, with varying requirements, it is desirable to set 913 up parallel measurement processes on given observed packet 914 stream. A device capable of hosting a measurement process should 915 be able to support more than one independently configurable 916 measurement process simultaneously. Each such measurement process 917 should have the option of being equipped with its own exporting 918 process; otherwise the parallel measurement processes may share 919 the same exporting process. 921 Each of the parallel measurement processes should be independent. 922 However, resource constraints may prevent complete reporting on a 923 packet selected by multiple selection processes. In this case, 924 reporting for the packet must be complete for at least one 925 measurement process; other measurement processes need only record 926 that they selected the packet, e.g., by incrementing a counter. 927 The priority amongst measurement processes under resource 928 contention should be configurable. 930 It is not proposed to standardize the number of parallel 931 measurement processes. 933 8. Exporting Process 935 This section detailed specific requirements for the exporting 936 process, motivated by the generic requirements of Section 3.6 938 8.1 Use of IPFIX 940 PSAMP will use the IP Flow Information eXport (IPFIX) protocol 941 for export of the report stream. The IPFIX protocol is well 942 suited for this purpose, because the IPFIX architecture matches 943 the PSAMP architecture very well and the means provided by the 944 IPFIX protocol are sufficient. 946 8.2 Congestion-aware Unreliable Transport 948 The export of the report stream does not require reliable export. 949 Section 5.4 shows that the use of input sequence number in packet 950 selectors means that the ability to estimate traffic rates is not 951 impaired by export loss. Export packet loss becomes another form 952 of sampling, albeit a less desirable, and less controlled, form 953 of sampling. 955 On the contrary, retransmission of lost export packets consumes 956 additional network resources. The requirement to store 957 unacknowledged data is an impediment to having ubiquitous support 958 for PSAMP. 960 In order to jointly satisfy the timeliness and congestion 961 avoidance requirements of Section 4.3, a congestion aware 962 unreliable transport protocol must be used. IPFIX is compatible 963 with this requirement, since it mandates support of the Stream 964 Control Transmission Protocol (SCTP) [SCTP] and the SCTP Partial 965 Reliability Extension [RFC-3758]. IPFIX also allows the use of 966 User Datagram Protocol (UDP) [UDP] although it is not a 967 congestion aware protocol. However, in this case, the Export 968 Packets must remain wholly within the administrative domains of 969 the operators [IPFIX-PROTO]. 971 8.3 Limiting Delay for Export Packets 973 Low measurement latency allows the traffic monitoring system to 974 be more responsive to real-time network events, for example, in 975 quickly identifying sources of congestion. Timeliness is 976 generally a good thing for devices performing the sampling since 977 it minimizes the amount of memory needed to buffer samples. 979 Keeping the packet dispatching delay small has other benefits 980 besides limiting buffer requirements. For many applications a 981 resolution of 1 second is sufficient. Applications in this 982 category would include: identifying sources associated with 983 congestion; tracing denial of service attacks through the network 984 and constructing traffic matrices. Furthermore, keeping dispatch 985 delay within the resolution required by applications eliminates 986 the need for timestamping by synchronized clocks at observation 987 points, or for the observation points and collector to maintain 988 bi-directional communication in order to track clock offsets. The 989 collector can simply process packet reports in the order that 990 they are received, using its own clock as a "global" time base. 991 This avoids the complexity of buffering and reordering samples. 992 See [DuGeGr02] for an example. 994 The delay between observation of a packet and transmission of a 995 export packet containing a report on that packet has several 996 components. It is difficult to standardize a given numerical 997 delay requirement, since in practice the delay may be sensitive 998 to processor load at the observation point. Therefore, PSAMP aims 999 to control that portion of the delay within the observation point 1000 that is due to buffering in the formation and transmission of 1001 export packets. 1003 In order to limit delay in the formation of export packets, the 1004 exporting process must provide the ability to close out and 1005 enqueue for transmission any export packet in formation as soon 1006 as it includes one packet report. This could be achieved, for 1007 example, by the following means: 1009 - the number of packet reports per export packet is not 1010 to exceed a maximum value, which can be configured to 1011 take the value 1. 1013 - the ability to exclude report interpretation from any 1014 export packet that contains a packet report; 1016 In order to limit the delay in the transmission of export 1017 packets, a configurable upper bound to the delay of an export 1018 packet prior to transmission must be provided. If the bound is 1019 exceeded the export packet is dropped. This functionality can be 1020 provided by the timed reliability service of the SCTP Partial 1021 Reliability Extension [RFC-3758]. 1023 The exporting process may queue the report stream in order to 1024 export multiple packet reports in a single export packet. Any 1025 consequent delay must still allow for timely availability of 1026 packet reports as just described. The timed reliability service 1027 of the SCTP Partial Reliability Extension [RFC-3758] allows from 1028 the dropping of packets from the export buffer once their age in 1029 the buffer exceeds a configurable bound. 1031 8.4 Configurable Export Rate Limit 1033 The exporting process must have an export rate limit, 1034 configurable per exporting process. This is useful for two 1035 reasons: 1037 (i) Even without network congestion, the rate of packet 1038 selection may exceed the capacity of the collector to 1039 process reports, particularly when many exporting processes 1040 feed a common collector. Use of an export rate limit allows 1041 control of the global input rate to the collector. 1043 (ii) IPFIX provides export using UDP as the transport 1044 protocol in some circumstances. An export rate limit allows 1045 the capping of the export rate to match both path link 1046 speeds and the capacity of the collector. 1048 8.5 Collector Destination 1050 When exporting to a remote collector, the collector is identified 1051 by IP address, transport protocol, and transport port number. 1053 8.6 Local Export 1055 The report stream may be directly exported to on-board 1056 measurement based applications, for example those that form 1057 composite statistics from more than one packet. Local export may 1058 be presented through an interface direct to the higher level 1059 applications, i.e., through an API, rather than employing the 1060 transport used for off-board export. Specification of such an API 1061 is outside the scope of the PSAMP framework. 1063 A possible example of local export could be that packets selected 1064 by the PSAMP measurement process serve as the input for the IPFIX 1065 protocol, which then forms flow records out of the stream of 1066 selected packets. 1068 9. Configuration and Management 1070 A key requirement for PSAMP is the easy reconfiguration of the 1071 parameters of the measurement process: those for selection, 1072 packet reports and export. Examples are 1074 (i) support of measurement-based applications that want to 1075 drill-down on traffic detail in real-time; 1077 (ii) collector-based rate reconfiguration. 1079 To facilitate reconfiguration and retrieval of parameters, they 1080 are to reside in a Management Information Base (MIB). Mandatory 1081 configuration, capabilities and monitoring objects will cover all 1082 mandatory PSAMP functionality. 1084 Secondary objects will cover the recommended and optional PSAMP 1085 functionality, and must be provided when such functionality is 1086 offered by a PSAMP device. Such PSAMP functionality includes 1087 configuration of offered selectors, composite selectors, multiple 1088 measurement processes, and report format including the choice of 1089 fields to be reported. For further details concerning the PSAMP 1090 MIB, see [PSAMP-MIB]. 1092 PSAMP requires a uniform mechanism with which to access and 1093 configure the MIB. SNMP access must be provided by the host of 1094 the MIB. 1096 10. Feasibility and Complexity 1098 In order for PSAMP to be supported across the entire spectrum of 1099 networking equipment, it must be simple and inexpensive to 1100 implement. One can envision easy-to-implement instances of the 1101 mechanisms described within this draft. Thus, for that subset of 1102 instances, it should be straightforward for virtually all system 1103 vendors to include them within their products. Indeed, sampling 1104 and filtering operations are already realized in available 1105 equipment. 1107 Here we give some specific arguments to demonstrate feasibility 1108 and comment on the complexity of hardware implementations. We 1109 stress here that the point of these arguments is not to favor or 1110 recommend any particular implementation, or to suggest a path for 1111 standardization, but rather to demonstrate that the set of 1112 possible implementations is not empty. 1114 10.1 Feasibility 1116 10.1.1 Filtering 1118 Filtering consists of a small number of mask (bit-wise logical), 1119 comparison and range (greater than) operations. Implementation 1120 of at least a small number of such operations is straightforward. 1121 For example, filters for security access control lists (ACLs) are 1122 widely implemented. This could be as simple as an exact match on 1123 certain fields, or involve more complex comparisons and ranges. 1125 10.1.2 Sampling 1127 Sampling based on either counters (counter set, decrement, test 1128 for equal to zero) or range matching on the hash of a packet 1129 (greater than) is possible given a small number of selectors, 1130 although there may be some differences in ease of implementation 1131 for hardware vs. software platforms. 1133 10.1.3 Hashing 1135 Hashing functions vary greatly in complexity. Execution of a 1136 small number of sufficient simple hash functions is implementable 1137 at line rate. Concerning the input to the hash function, hop- 1138 invariant IP header fields (IP address, IP identification) and 1139 TCP/UDP header fields (port numbers, TCP sequence number) drawn 1140 from the first 40 bytes of the packet have been found to possess 1141 a considerable variability; see [DuGr01]. 1143 10.1.4 Reporting 1145 The simplest packet report would duplicate the first n bytes of 1146 the packet. However, such an uncompressed format may tax the 1147 bandwidth available to the reporting process for high sampling 1148 rates; reporting selected fields would save on this bandwidth. 1149 Thus there is a trade-off between simplicity and bandwidth 1150 limitations. 1152 10.1.5 Export 1154 Ease of exporting export packets depends on the system 1155 architecture. Most systems should be able to support export by 1156 insertion of export packets, even through the software path. 1158 10.2 Potential Hardware Complexity 1160 We now comment on the complexity of possible hardware 1161 implementations. Achieving low constants for performance while 1162 minimizing hardware resources is, of course, a challenge, 1163 especially at very high clock frequencies. Most of these 1164 operations, however, are very basic and their implementations 1165 very well understood; in fact, the average ASIC designer simply 1166 uses canned library instances of these operations rather than 1167 design them from scratch. In addition, networking equipment 1168 generally does not need to run at the fastest clock rates, 1169 further reducing the effort required to get reasonably efficient 1170 implementations. 1172 Simple bit-wise logical operations are easy to implement in 1173 hardware. Such operations (NAND/NOR/XNOR/NOT) directly translate 1174 to four-transistor gates. Each bit of a multiple-bit logical 1175 operation is completely independent and thus can be performed in 1176 parallel incurring no additional performance cost above a single 1177 bit operation. 1179 Comparisons (EQ/NEQ) take O(lg(M)) stages of logic, where M is 1180 the number of bits involved in the comparison. The lg(M) is 1181 required to accumulate the result into a single bit. 1183 Greater than operations, as used to determine whether a hash 1184 falls in a selection range, are a determination of the most 1185 significant not-equivalent bit in the two operands. The operand 1186 with that most-significant-not-equal bit set to be one is greater 1187 than the other. Thus, a greater than operation is also an 1188 O(lg(M)) stages of logic operation. Optimized implementations of 1189 arithmetic operations are also O(lg(M)) due to propagation of the 1190 carry bit. 1192 Setting a counter is simply loading a register with a state. Such 1193 an operation is simple and fast O(1). Incrementing or 1194 decrementing a counter is a read, followed by an arithmetic 1195 operation followed by a store. Making the register dual-ported 1196 does take additional space, but it is a well-understood 1197 technique. Thus, the increment/decrement is also an O(lg(M)) 1198 operation. 1200 Hashing functions come in a variety of forms. The computation 1201 involved in a standard Cyclic Redundancy Code (CRC) for example 1202 are essentially a set of XOR operations, where the intermediate 1203 result is stored and XORed with the next chunk of data. There 1204 are only O(1) operations and no log complexity operations. Thus, 1205 a simple hash function, such as CRC or generalizations thereof, 1206 can be implemented in hardware very efficiently. 1208 At the other end of the range of complexity, the MD5 function 1209 uses a large number of bit-wise conditional operations and 1210 arithmetic operations. The former are O(1) operations and the 1211 latter are O(lg(M)). MD5 specifies 256 32b ADD operations per 16B 1212 of input processed. Consider processing 10Gb/sec at 100MHz (this 1213 processing rate appears to be currently available). This requires 1214 processing 12.5B/cycle, and hence at least 200 adders, a sizeable 1215 number. Because of data dependencies within the MD5 algorithm, 1216 the adders cannot be simply run in parallel, thus requiring 1217 either faster clock rates and/or more advanced architectures. 1218 Thus, selection hashing functions as complex as MD5 may be 1219 precluded for ubiquitous use at full line rate. This motivates 1220 exploring the use of selection hash functions with complexity 1221 somewhere between that of MD5 and CRC. However, identification 1222 hashing with MD5 on only selected packets is feasible at a 1223 sufficiently low sampling frequency. 1225 11. Applications 1227 We first describe several representative operational applications 1228 that require traffic measurements at various levels of temporal 1229 and spatial granularity. Some of the goals here appear similar to 1230 those of IPFIX, at least in the broad classes of applications 1231 supported. The major benefit of PSAMP is the support of new 1232 network management applications, specifically, those enabled by 1233 the packet selectors that it supports. 1235 11.1 Baseline Measurement and Drill Down 1237 Packet sampling is ideally suited to determine the composition of 1238 the traffic across a network. The approach is to enable 1239 measurement on a cut-set of the network links such that each 1240 packet entering the network is seen at least once, for example, 1241 on all ingress links. Unfiltered sampling with a relatively low 1242 frequency establishes baseline measurements of the network 1243 traffic. Packet reports include packet attributes of common 1244 interest: source and destination address and port numbers, 1245 prefix, protocol number, type of service, etc. Traffic matrices 1246 are indicated by reporting source and destination AS matrices. 1247 Absolute traffic volumes are estimated by renormalizing the 1248 sampled traffic volumes through division by either the target 1249 sampling frequency, or by the attained sampling frequency (as 1250 derived by interface packet counters included in the report 1251 stream) 1253 Suppose an operator or a measurement-based application detects an 1254 interesting subset of a packet stream, as identified by a 1255 particular packet attribute. Real-time drill-down to that subset 1256 is achieved by instantiating a new measurement process on the 1257 same packet stream from which the subset was reported. The 1258 selection process of the new measurement process filters 1259 according to the attribute of interest, and composes with 1260 sampling if necessary to manage the frequency of packet 1261 selection. 1263 11.2 Trajectory Sampling 1265 Trajectory sampling is the selection of a subset of packets at 1266 either all of a set of observation points or none of them. 1267 Trajectory sampling is realized by hash-based sampling if all 1268 observation points in the set apply a common hash function to a 1269 portion of the packet content that is invariant along the packet 1270 path. (Thus, fields such at TTL and CRC are excluded). 1272 The trajectory followed by a packet is reconstructed from PSAMP 1273 reports on it that reach the collector. Reports on a given packet 1274 are associated either by matching a label comprising the 1275 invariant reported packet content, or possibly some digest of it. 1276 The reconstruction of trajectories, and methods for dealing with 1277 possible ambiguities due to label collisions (identical labels 1278 reported by different packets) and potential loss of reports in 1279 transmission are dealt with in [DuGr01], [DuGeGr02] and [DuGr04]. 1281 11.3 Passive Performance Measurement 1283 Trajectory sampling enables the tracking of the performance 1284 experience by customer traffic, customers identified by a list of 1285 source or destination prefixes, or by ingress or egress 1286 interfaces. Operational uses include the verification of Service 1287 Level Agreements (SLAs), and troubleshooting following a customer 1288 complaint. 1290 In this application, trajectory sampling is enabled at all 1291 network ingress and egress interfaces. Rates of loss in transit 1292 between ingress and egress are estimated from the proportion of 1293 trajectories for which no egress report is received. Note that 1294 loss of customer packets is distinguishable from loss of packet 1295 reports through use of report sequence numbers. Assuming 1296 synchronization of clocks between different entities, delay of 1297 customer traffic across the network may also be measured; see 1298 [Zs02]. 1300 Extending hash-selection to all interfaces in the network would 1301 enable attribution of poor performance to individual network 1302 links. 1304 11.4 Troubleshooting 1306 PSAMP reports can also be used to diagnose problems whose 1307 occurrence is evident from aggregate statistics, per interface 1308 utilization and packet loss statistics. These statistics are 1309 typically moving averages over relatively long time windows, 1310 e.g., 5 minutes, and serve as a coarse-grain indication of 1311 operational health of the network. The most common method of 1312 obtaining such measurements are through the appropriate SNMP MIBs 1313 (MIB-II [RFC-1213] and vendor-specific MIBs.) 1315 Suppose an operator detects a link that is persistently 1316 overloaded and experiences significant packet drop rates. There 1317 is a wide range of potential causes: routing parameters (e.g., 1318 OSPF link weights) that are poorly adapted to the traffic matrix, 1319 e.g., because of a shift in that matrix; a denial of service 1320 attack or a flash crowd; a routing problem (link flapping). In 1321 most cases, aggregate link statistics are not sufficient to 1322 distinguish between such causes, and to decide on an appropriate 1323 corrective action. For example, if routing over two links is 1324 unstable, and the links flap between being overloaded and 1325 inactive, this might be averaged out in a 5 minute window, 1326 indicating moderate loads on both links. 1328 Baseline PSAMP measurement of the congested link, as described in 1329 Section 11.1, enables measurements that are fine grained in both 1330 space and time. The operator has to be able to determine how many 1331 bytes/packets are generated for each source/destination address, 1332 port number, and prefix, or other attributes, such as protocol 1333 number, MPLS forwarding equivalence class (FEC), type of service, 1334 etc. This allows the precise determination of the nature of the 1335 offending traffic. For example, in the case of a Distributed 1336 Denial of Service(DDoS) attack, the operator would see a 1337 significant fraction of traffic with an identical destination 1338 address. 1340 In certain circumstances, precise information about the spatial 1341 flow of traffic through the network domain is required to detect 1342 and diagnose problems and verify correct network behavior. In the 1343 case of the overloaded link, it would be very helpful to know the 1344 precise set of paths that packets traversing this link follow. 1345 This would readily reveal a routing problem such as a loop, or a 1346 link with a misconfigured weight. More generally, complex 1347 diagnosis scenarios can benefit from measurement of traffic 1348 intensities (and other attributes) over a set of paths that is 1349 constrained in some way. For example, if a multihomed customer 1350 complains about performance problems on one of the access links 1351 from a particular source address prefix, the operator should be 1352 able to examine in detail the traffic from that source prefix 1353 which also traverses the specified access link towards the 1354 customer. 1356 While it is in principle possible to obtain the spatial flow of 1357 traffic through auxiliary network state information, e.g., by 1358 downloading routing and forwarding tables from routers, this 1359 information is often unreliable, outdated, voluminous, and 1360 contingent on a network model. For operational purposes, a direct 1361 observation of traffic flow provided by trajectory sampling is 1362 more reliable, as it does not depend on any such auxiliary 1363 information. For example, if there was a bug in a router's 1364 software, direct observation would allow the diagnosis the effect 1365 of this bug, while an indirect method would not. 1367 12. Security Considerations 1369 Security considerations are addressed in: 1371 - Section 4.1: item Robust Selection 1372 - Section 4.3: item Secure Export 1373 - Section 4.4: item Secure Configuration 1375 13. Normative References 1377 [PSAMP-TECH] T. Zseby, M. Molina, F. Raspall, N. G. Duffield, 1378 Sampling and Filtering Techniques for IP Packet 1379 Selection, RFC XXXX. [Currently Internet Draft, draft- 1380 ietf-psamp-sample-tech-04.txt, work in progress, February 1381 2004. 1383 [PSAMP-MIB] T. Dietz, B. Claise, Definitions of Managed 1384 Objects for Packet Sampling, RFC XXXX. [Currently 1385 Internet Draft, draft-ietf-psamp-mib-03.txt, work in 1386 progress, July 2004.] 1388 [PSAMP-PROTO] B. Claise (Ed.) Packet Sampling (PSAMP) 1389 Protocol Specifications, RFC XXXX. [Currently Internet 1390 Draft draft-ietf-psamp-protocol-01.txt, work in progress, 1391 February 2004.] 1393 [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, 1394 Information Model for Packet Sampling Exports, RFC XXXX. 1395 [Currently Internet Draft, draft-ietf-psamp-info-02, July 1396 2004 1398 14. Informative References 1400 [B88] R.T. Braden, A pseudo-machine for packet monitoring 1401 and statistics, in Proc ACM SIGCOMM 1988 1403 [IPFIX-INFO] Calato, P, Meyer, J, Quittek, J, "Information 1404 Model for IP Flow Information Export" draft-ietf-ipfix- 1405 info-04, November 2003 1407 [ClPB93] K.C. Claffy, G.C. Polyzos, H.-W. Braun, Application 1408 of Sampling Methodologies to Network Traffic 1409 Characterization, Proceedings of ACM SIGCOMM'93, San 1410 Francisco, CA, USA, September 13-17, 1993 1412 [IPFIX-PROTO] B. Claise, B. Stewart, G. Sadasivan, M. 1413 Fullmer,P. Calato , R. Penno, IPFIX Protocol 1414 Specifications , Internet Draft, draft-ietf-ipfix- 1415 protocol-05.txt, August 2004. 1417 [RFC-2460] S. Deering, R. Hinden, Internet Protocol, Version 1418 6 (IPv6) Specification, RFC 2460, December 1998. 1420 [DuGr01] N. G. Duffield and M. Grossglauser, Trajectory 1421 Sampling for Direct Traffic Observation, IEEE/ACM Trans. 1422 on Networking, 9(3), 280-292, June 2001. 1424 [DuGeGr02] N.G. Duffield, A. Gerber, M. Grossglauser, 1425 Trajectory Engine: A Backend for Trajectory Sampling, 1426 IEEE Network Operations and Management Symposium 2002, 1427 Florence, Italy, April 15-19, 2002. 1429 [DuGr04] N. G. Duffield and M. Grossglauser, Trajectory 1430 Sampling with Unreliable Reporting, Proc IEEE Infocom 1431 2004, Hong Kong, March 2004, 1433 [RFC-2914] S. Floyd, Congestion Control Principles, RFC 1434 2914, September 2000. 1436 [RFC-2804] IAB and IESG, Network Working Group, IETF Policy 1437 on Wiretapping, RFC 2804, May 2000 1439 [RFC-1213] - K. McCloghrie, M. Rose, Management Information 1440 Base for Network Management of TCP/IP-based 1441 internets:MIB-II, RFC 1213, March 1991. 1443 [RFC-3176] P. Phaal, S. Panchen, N. McKee, InMon 1444 Corporation's sFlow: A Method for Monitoring Traffic in 1445 Switched and Routed Networks, RFC 3176, September 2001 1447 [RFC-2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, 1448 Framework for IP Performance Metrics, RFC 2330, May 1998 1450 [RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, 1451 September 1981. 1453 [UDP] Postel, J., "User Datagram Protocol" RFC 768, August 1454 1980 1456 [IPFIX-REQUIRE] J. Quittek, T. Zseby, B. Claise, S. Zander, 1457 Requirements for IP Flow Information Export, Internet 1458 Draft draft-ietf-ipfix-reqs-16.txt, work in progress, 1459 June 2004. 1461 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway 1462 Protocol 4 (BGP-4)", RFC 1771, March 1995. 1464 [RFC-3031] Rosen, E., Viswanathan, A. and R. Callon, 1465 "Multiprotocol Label Switching Architecture", RFC 3031, 1466 January 2001. 1468 [SPSJTKS01] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. 1469 E. Jones, F. Tchakountio, S. T. Kent, W. T. Strayer, 1470 Hash-Based IP Traceback, Proc. ACM SIGCOMM 2001, San 1471 Diego, CA, September 2001. 1473 [RFC-2960] R. Stewart, (ed.) "Stream Control Transmission 1474 Protocol", RFC 2960, October 2000. 1476 [RFC-3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. 1477 Conrad, "SCTP Partial Reliability Extension", RFC 3758, 1478 May 2004. 1480 [Zs02] T. Zseby, ``Deployment of Sampling Methods for SLA 1481 Validation with Non-Intrusive Measurements'', Proceedings 1482 of Passive and Active Measurement Workshop (PAM 2002), 1483 Fort Collins, CO, USA, March 25-26, 2002 1485 15. Authors' Addresses 1486 Derek Chiou 1487 Avici Systems 1488 101 Billerica Ave 1489 North Billerica, MA 01862 1490 Phone: +1 978-964-2017 1491 Email: dchiou@avici.com 1493 Benoit Claise 1494 Cisco Systems 1495 De Kleetlaan 6a b1 1496 1831 Diegem 1497 Belgium 1498 Phone: +32 2 704 5622 1499 Email: bclaise@cisco.com 1501 Nick Duffield 1502 AT&T Labs - Research 1503 Room B-139 1504 180 Park Ave 1505 Florham Park NJ 07932, USA 1506 Phone: +1 973-360-8726 1507 Email: duffield@research.att.com 1509 Albert Greenberg 1510 AT&T Labs - Research 1511 Room A-161 1512 180 Park Ave 1513 Florham Park NJ 07932, USA 1514 Phone: +1 973-360-8730 1515 Email: albert@research.att.com 1517 Matthias Grossglauser 1518 School of Computer and Communication Sciences 1519 EPFL 1520 1015 Lausanne 1521 Switzerland 1522 Email: matthias.grossglauser@epfl.ch 1524 Peram Marimuthu 1525 Cisco Systems 1526 170, W. Tasman Drive 1527 San Jose, CA 95134 1528 Phone: (408) 527-6314 1529 Email: peram@cisco.com 1531 Jennifer Rexford 1532 AT&T Labs - Research 1533 Room A-169 1534 180 Park Ave 1535 Florham Park NJ 07932, USA 1536 Phone: +1 973-360-8728 1537 Email: jrex@research.att.com 1538 Ganesh Sadasivan 1539 Cisco Systems 1540 170 W. Tasman Drive 1541 San Jose, CA 95134 1542 Phone: (408) 527-0251 1543 Email: gsadasiv@cisco.com 1545 16. Intellectual Property Statements 1547 By submitting this Internet-Draft, each author represents that 1548 any applicable patent or other IPR claims of which he or she is 1549 aware have been or will be disclosed, and any of which he or she 1550 becomes aware will be disclosed, in accordance with Section 6 of 1551 RFC 3668. 1553 The IETF has been notified by AT&T Corp. of intellectual property 1554 rights claimed in regard to some or all of the specification 1555 contained in this document. For more information, see 1556 http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp- 1557 framework.txt 1559 The IETF has been notified by Cisco Corp. of intellectual 1560 property rights claimed in regard to some or all of the 1561 specification contained in this document. For more information, 1562 see 1563 http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp- 1564 protocol.txt 1566 17. Full Copyright Statement 1568 Copyright (C) The Internet Society (2004). This document is 1569 subject to the rights, licenses and restrictions contained in BCP 1570 78 and except as set forth therein, the authors retain all their 1571 rights. 1573 This document and translations of it may be copied and furnished 1574 to others, and derivative works that comment on or otherwise 1575 explain it or assist in its implementation may be prepared, 1576 copied, published and distributed, in whole or in part, without 1577 restriction of any kind, provided that the above copyright notice 1578 and this paragraph are included on all such copies and derivative 1579 works. However, this document itself may not be modified in any 1580 way, such as by removing the copyright notice or references to 1581 the Internet Society or other Internet organizations, except as 1582 needed for the purpose of developing Internet standards in which 1583 case the procedures for copyrights defined in the Internet 1584 Standards process must be followed, or as required to translate 1585 it into languages other than English. 1587 The limited permissions granted above are perpetual and will not 1588 be revoked by the Internet Society or its successors or assigns. 1590 This document and the information contained herein is provided on 1591 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1592 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1593 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1594 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1595 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1596 PURPOSE.