idnits 2.17.1 draft-claise-ipfix-export-per-sctp-stream-03.txt: 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 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 731. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 25, 2008) is 5904 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) == Outdated reference: A later version (-11) exists of draft-ietf-psamp-sample-tech-10 -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) == Outdated reference: A later version (-11) exists of draft-ietf-psamp-info-07 == Outdated reference: A later version (-13) exists of draft-ietf-psamp-framework-12 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Claise 3 Internet-Draft P. Aitken 4 Intended Status: Informational A. Johnson 5 Expires: August 25, 2008 Cisco Systems, Inc. 6 G. Muenz 7 University of Tuebingen 8 February 25, 2008 10 IPFIX Export per SCTP Stream 11 draft-claise-ipfix-export-per-sctp-stream-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents 16 that any applicable patent or other IPR claims of which he 17 or she is aware have been or will be disclosed, and any of 18 which he or she becomes aware will be disclosed, in 19 accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working 23 groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by 28 other documents at any time. It is inappropriate to use 29 Internet-Drafts as reference material or to cite them 30 other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be 36 accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on June, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 This document specifies an improvement to the use of SCTP 48 as specified in the IPFIX specifications in order to be 49 able to deduce the data record loss per template record in 50 case of partially-reliable SCTP export. This specification 51 offers several extra advantages: immediate export of the 52 template withdrawal message, immediate reuse of template ID 53 within a stream, and the collecting process's job is 54 easier. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 59 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 60 and "OPTIONAL" in this document are to be interpreted as 61 described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Terminology...............................................4 66 1.1. IPFIX Documents Overview.............................4 67 1.2. PSAMP Documents Overview.............................4 68 2. Introduction..............................................5 69 2.1. Applicability........................................6 70 3. IPFIX Protocol Specifications Limitations and Improvements6 71 3.1. Data Record Loss per Template........................6 72 3.1.1. IPFIX Protocol Specifications Limitation........6 73 3.1.2. IPFIX Export per SCTP Stream Advantage..........7 74 3.2. Transmission Order within a Stream...................7 75 3.2.1. IPFIX Protocol Specifications Limitation........7 76 3.2.2. IPFIX Export per SCTP Stream Advantages.........8 77 3.3. No Transmission Order across SCTP Streams............8 78 3.3.1. IPFIX Protocol Specifications Limitation........8 79 3.3.2. IPFIX Export per SCTP Stream Advantages.........9 80 4. Specifications............................................9 81 4.1. Template Management..................................9 82 4.2. Template Withdrawal Message.........................10 83 4.3. SCTP................................................11 84 4.4. The Collecting Process's Side.......................12 85 5. Examples.................................................12 86 6. IANA Considerations......................................15 87 7. Security Considerations..................................15 88 8. References...............................................15 89 8.1. Normative References................................15 90 8.2. Informative References..............................16 91 9. Acknowledgements.........................................17 92 10. Author's Addresses......................................18 93 11. Intellectual Property Statement.........................19 94 12. Copyright Statement.....................................19 95 13. Disclaimer..............................................19 97 1. Terminology 99 IPFIX-specific terminology used in this document is defined 100 in section 2 of [RFC5101]. As in [RFC5101], these IPFIX- 101 specific terms have the first letter of a word capitalized 102 when used in this document. 104 Template Reuse Delay 106 The configurable timeout to allow the Collecting Process 107 to receive and process the last Data Record using this 108 Template information before which the Template Withdrawal 109 Message MUST NOT be sent. [RFC5101] specifies a default 110 value of 5 seconds. 112 1.1. IPFIX Documents Overview 114 The IPFIX Protocol [RFC5101] provides network administrators 115 with access to IP flow information. 117 The architecture for the export of measured IP flow 118 information out of an IPFIX exporting process to a collecting 119 process is defined in the IPFIX Architecture [IPFIX-ARCH], 120 per the requirements defined in RFC 3917 [RFC3917]. 122 The IPFIX Architecture [IPFIX-ARCH] specifies how IPFIX Data 123 Records and Templates are carried via a congestion-aware 124 transport protocol from IPFIX Exporting Processes to IPFIX 125 Collecting Processes. 127 IPFIX has a formal description of IPFIX Information Elements, 128 their name, type and additional semantic information, as 129 specified in the IPFIX Information Model [RFC5102]. 131 Finally the IPFIX Applicability Statement [IPFIX-AS] 132 describes what type of applications can use the IPFIX 133 protocol and how they can use the information provided. It 134 furthermore shows how the IPFIX framework relates to other 135 architectures and frameworks. 137 1.2. PSAMP Documents Overview 139 The document "A Framework for Packet Selection and Reporting" 140 [PSAMP-FMWK], describes the PSAMP framework for network 141 elements to select subsets of packets by statistical and 142 other methods, and to export a stream of reports on the 143 selected packets to a collector. 145 The set of packet selection techniques (sampling, filtering, 146 and hashing) supported by PSAMP are described in "Sampling 147 and Filtering Techniques for IP Packet Selection" [PSAMP- 148 TECH]. 150 The PSAMP protocol [PSAMP-PROTO] specifies the export of 151 packet information from a PSAMP Exporting Process to a PSAMP 152 Collecting Process. Like IPFIX, PSAMP has a formal 153 description of its information elements, their name, type and 154 additional semantic information. The PSAMP information model 155 is defined in [PSAMP-INFO]. 157 Finally [PSAMP-MIB] describes the PSAMP Management 158 Information Base. 160 2. Introduction 162 The IPFIX working group has specified a protocol to export IP 163 Flow information [RFC5101]. This protocol is designed to 164 export information about IP traffic flows and related 165 measurement data, where a flow is defined by a set of key 166 attributes (e.g. source and destination IP address, source 167 and destination port, etc.). However, thanks to its template 168 mechanism, the IPFIX protocol can export any type of 169 information, as long as the relevant Information Element is 170 specified in the IPFIX Information Model [RFC5102], 171 registered with IANA, or specified as an enterprise-specific 172 Information Element. 174 The IPFIX protocol [RFC5101] specifies that IP traffic 175 measurements for flows are exported using a TLV (type, 176 length, value) format. The information is exported using a 177 Template Record that is sent once to export the {type, 178 length} pairs that define the data format for one or more 179 Data Records that are sent for a flow. The Data Records 180 specify values for each flow. 182 The IPFIX protocol [RFC5101] is flexible: it foresees the usage 183 of the multiple SCTP streams per association; allows the 184 transmission of Data Sets, Template Sets, and/or Options 185 Template Sets on any stream; it offers the full or partial 186 reliability export of Data Sets; it proposes the ordered or out- 187 of-order delivery of Data Sets. However, due the resource 188 constraints on the Exporter, it is not always possible to export 189 all Data Sets in a reliable way. 191 The specification in this document offers several advantages 192 such as: the data records loss per template record in case of 193 partially-reliable SCTP export, immediate export of the Template 194 Withdrawal Message, immediate reuse of template ID within a 195 stream, reduce the likelihood of losing data record, and the 196 collecting process's job is easier. 198 2.1. Applicability 200 The specification in this document applies to the IPFIX 201 protocol specifications [RFC5101]. However, it only applies 202 to the SCTP transport [RFC4960] and [RFC3758] protocol option 203 of the IPFIX protocol specifications. All specifications 204 from [RFC5101] apply unless specified otherwise in this 205 document. 207 As the Packet Sampling (PSAMP) protocol specifications 208 [PSAMP-PROTO] are based on the IPFIX protocol specifications, 209 the specifications in this document are also valid for the 210 PSAMP protocol. Therefore, the advantages specified by this 211 document also apply to PSAMP. 213 3. IPFIX Protocol Specifications Limitations and Improvements 215 3.1. Data Record Loss per Template 217 3.1.1. IPFIX Protocol Specifications Limitation 219 Section 6.3.2 of the Requirements for IP Flow Information 220 Export [RFC3917] discusses the data transfer reliability 221 issues. "Loss of flow records during the data transfer from 222 the exporting process to the collecting process must be 223 indicated at the collecting process." is clearly mentioned. 224 However, in some cases, it may be important to know how many 225 Data Records of a certain type were lost (e.g., in the case 226 of billing), but conventionally IPFIX does not provide this 227 information. 229 A Collector can detect out-of-sequence, dropped, or duplicate 230 IPFIX Messages by tracking the Sequence Number [RFC5101]. 231 However, the Sequence Number field in the Export header 232 increases with the number of IPFIX Data Records with the PR- 233 SCTP stream. 235 The IPFIX protocol specification [RFC5101] specifies that Data 236 Records associated with any Template ID may be sent on any SCTP 237 stream. As such, if there is more than one Template IDs defined 238 within the whole SCTP association then there is no way of 239 knowing the which Template ID any lost Data Records are 240 associated with. This is true, now matter what convention 241 the Exporting Process uses to send Data Records on different 242 SCTP streams, as the protocol makes no guarantees. 244 Using the specification in this document, it is guaranteed that 245 any lost Data Records will be associated only with the Templates 246 that are defined on that stream and by defining only one 247 Template on a stream it is ensured that any loss is associated 248 with that single Template. 250 3.1.2. IPFIX Export per SCTP Stream Advantage 252 By exporting each Template ID and the corresponding Data Records 253 within a different stream, the loss pertaining to each specific 254 Template ID can be deduced from Sequence Number field in the 255 Export headers. 257 3.2. Transmission Order within a Stream 259 3.2.1. IPFIX Protocol Specifications Limitation 261 A Collecting Process must have received the Template Record 262 associated with the Data Records to be able to decode the 263 information in the Data Records. The IPFIX protocol 264 specification foresees: 266 "The Exporting Process SHOULD transmit the Template Set 267 and Options Template Set in advance of any Data Sets that 268 use that (Options) Template ID, to help ensure that the 269 Collector has the Template Record before receiving the 270 first Data Record.", 272 The fact that the Collecting Process cannot decode the Data 273 Records without the Template Record may result in the Data 274 Records being discarded by the Collector, as specified in 275 [RFC5101]: 277 "The Collecting Process normally receives Template Records 278 from the Exporting Process before receiving Data Records. 279 The Data Records are then decoded and stored by the 280 Collector. If the Template Records have not been received 281 at the time Data Records are received, the Collecting 282 Process MAY store the Data Records for a short period of 283 time and decode them after the Template Records are 284 received." 286 In practice, Data Records without associated (Options) 287 Template Records will probably be discarded by the Collecting 288 Process. 290 3.2.2. IPFIX Export per SCTP Stream Advantages 292 By exporting each Template Record and the corresponding Data 293 Records within a single stream and imposing in-order 294 transmission, the Template will always arrive before the 295 associated Data Records. Therefore, there is no risk that 296 the Collecting Process discards Data Records while waiting 297 for the Template to arrive. 299 Furthermore, when reusing a Template ID within a stream, the 300 Template Withdrawal Message will be guaranteed to arrive 301 before the new definition of the Template and therefore the 302 Template Record may be sent directly after the Template 303 Withdrawal Message. Therefore the Template Reuse Delay 304 restriction can be removed for Template ID reuse with a 305 stream. 307 Another advantage with the new specifications in this 308 document is that the Collecting Process's job is now easier. 309 Indeed, the Collecting Process doesn't have to store the Data 310 Records while waiting for the Template Records, as the 311 transmission order is always guaranteed. This way, extra 312 reliability of the Data Records is achieved without extra 313 burden on the Collecting Process. 315 3.3. No Transmission Order across SCTP Streams 317 3.3.1. IPFIX Protocol Specifications Limitation 319 The fact that the protocol specifications [RFC5101] are 320 flexible in terms of stream(s) on which the Template Set, 321 Options Template Set, and corresponding Data Sets are 322 exported, implies that the (Options) Template Set might be 323 exported on a different stream than the corresponding Data 324 Sets. This might cause Data Record loss in the Collecting 325 Process as the ordered transmission across SCTP streams is 326 not guaranteed. 328 For example, a Template may be blocked pending reliable 329 transmission on one stream while the associated Data Records 330 may be transmitted immediately in another stream. Also, due 331 to different stream congestion, it is possible that even if 332 the Template and Data Records are both sent reliably, Data 333 Records sent on a different stream than the associated 334 Template might still arrive before the associated Template. 336 3.3.2. IPFIX Export per SCTP Stream Advantages 338 By exporting each Template Record and the corresponding Data 339 Records within a single stream, imposing in-order 340 transmission, and limiting the Template ID to a single 341 stream, the issue of ordered transmission across multiple 342 streams is avoided. 344 By exporting all corresponding Data Records within the same 345 ordered stream as the Template Definition then each stream is 346 independent and self-contained and the interaction between 347 streams is limited to that of Options Data interactions. This 348 has several advantageous consequences, including order 349 preservation does not result in the blocking of unrelated data 350 and that the Collector's job is simplified as the Template 351 Records are guaranteed to be delivered before the associated 352 Data Records. 354 4. Specifications 356 4.1. Template Management 358 This section introduces modifications compared to the Template 359 Management section 8 in [RFC5101]. 361 As specified in [RFC5101], Template Sets and Options Template 362 Sets MUST be sent reliably. In other words, any IPFIX Message 363 containing an (Options) Template Set MUST be sent reliably. 365 Any Data Sets associated with a Template Record MUST be sent on 366 the same stream on which the Template Record was sent. 368 By sending only a single Template ID and associated Data Sets 369 within a single stream, any Data Record loss can be calculated 370 on a per Template basis. 372 If there is some Options Data Records required to interpret the 373 Data Records, the Options Data Records MUST be sent reliably 374 within the same stream. If not sent reliably, the Collector 375 could consider that any loss might be associated with the 376 Options Template Record, even if the Exporter is always sending 377 them reliably. 379 The Option Data Record SHOULD be sent before the Data Record 380 that needs it so that it arrives first and is available for the 381 Collector to use. By sending the Options Data reliably, any 382 loss will be limited to the non-option Data Record and loss can 383 still be calculated on a per 384 Template basis. 386 Furthermore, the Exporter MAY group related Template IDs and 387 their associated Data Sets within a single stream so loss 388 statistics are calculated for the group. This may be suitable 389 in cases where there is insufficient SCTP streams to send each 390 Template on its own stream and/or the case where there are 391 slight variations on a single Template to show that some fields 392 were unavailable at the time of monitoring. 394 4.2. Template Withdrawal Message 396 This section introduces Template Withdrawal Message-related 397 modifications compared to the Template Management section 8 in 398 [RFC5101]. 400 Templates that are not used anymore SHOULD be deleted. Before 401 reusing a Template ID, the Template MUST be deleted. In order 402 to delete an allocated Template, the Template is withdrawn 403 through the use of a Template Withdrawal Message. The Template 404 Withdrawal Message MUST be sent on the same stream as the 405 Template ID to be removed. 407 As all IPFIX Messages are sent in order within a stream and 408 reliably per [RFC5101], the IPFIX Message containing the 409 Template Withdrawal Message will not arrive at the Collecting 410 Process before any associated and previously sent Data Record. 412 As a consequence, no Data Records will be lost due to delayed 413 arrival at the Collector. 415 The Template ID from a withdrawn Template MAY be reused on the 416 same stream immediately after the Template Withdrawal Message is 417 sent. This case is equivalent to the use of a Template Reuse 418 Delay value of 0. 420 If the new definition of the Template ID is to be reused on a 421 different stream, the Template Withdrawal Message MUST NOT be 422 sent before the Template Reuse Delay. 424 A Template Withdrawal Message to withdraw all Templates for the 425 Observation Domain ID specified in the IPFIX Message header MUST 426 NOT be used. 428 Multiple Template IDs MAY be withdrawn with a single Template 429 Withdrawal Message at the condition that all the Template IDs in 430 the Template Withdrawal Message are used on the same SCTP 431 stream. 433 4.3. SCTP 435 This section introduces modifications compared to the "SCTP" 436 section 10.2 (and subsections) in [RFC5101]. More specifically 437 the "Stream" section 10.2.4.3 439 PR-SCTP [RFC3758] MUST be implemented by all compliant 440 implementations. 442 All IPFIX Messages MUST be sent in order within a stream. 444 Depending on the application requirement, the Exporting Process 445 MAY send Data Sets with full or partial reliability. Unreliable 446 data transfer MAY be used where the application does not require 447 reliable transmission and the use of a retransmission queue is 448 impractical. 450 If the Exporting Process requires to export a new Template but 451 there are no more free SCTP streams available, it SHOULD attempt 452 to increase the number of outbound streams it is able to send 453 to, per [SCTP-RESET]. Alternatively, the Exporting Process MAY 454 add the Template Set and Data Records to an existing stream at 455 the cost of diluting the granularity of Data Records loss. 457 4.4. The Collecting Process's Side 459 This refers to the Collecting Process's Side section 9 in 460 [RFC5101]. 462 The Collecting Process SHOULD listen for a new association 463 request from the Exporting Process. The Exporting Process will 464 request a number of streams to use for export: the number of 465 streams SHOULD be equivalent to the number of simultaneous 466 Template IDs used in the association. 468 A Collecting process SHOULD support the procedure for the 469 addition of a SCTP stream [SCTP-RESET]. 471 The IPFIX protocol has a Sequence Number field in the Message 472 header that increases with the number of IPFIX Data Records in 473 the IPFIX Message. A Collector may detect out-of-sequence, 474 dropped, or duplicate IPFIX Messages by tracking the Sequence 475 Number. As this Sequence Number is per SCTP stream, the loss 476 for the Data Records sent in that stream can be calculated in 477 case of partially-reliable export. If the SCTP stream only 478 contains Data Records from a single Template ID, the Data 479 Records for that Template ID can be calculated. 481 If the Collecting Process receives a Template Withdrawal Message 482 on a different stream than the one on which the Template ID is 483 used, then the Collecting Process MUST reset the association and 484 SHOULD log an error message. 486 The following sentence from [RFC5101] is not applicable in this 487 specification: 489 "The Collecting Process normally receives Template Records 490 from the Exporting Process before receiving Data Records. 491 The Data Records are then decoded and stored by the 492 Collector. If the Template Records have not been received at 493 the time Data Records are received, the Collecting Process 494 MAY store the Data Records for a short period of time and 495 decode them after the Template Records are received." 497 5. Examples 499 Figure 1 shows an example where the stream 10 carries a Template 500 with the Template ID 256 transmitted with full reliability (FR), 501 together with associated Data Records transmitted with partial 502 reliability (PR). Note that, because all IPFIX Messages are 503 sent in order within a stream, the Template 256 will always be 504 processed before the Data Records by the Collecting Process. 505 Therefore, the Collecting Process job is simplified. 506 Furthermore, the Data Record loss for the Template 256 can 507 easily be calculated on the Collecting Process. 509 +--------+ +---------+ +----------+ 510 | | | | | | 511 stream 10 ----| Data | . . . | Data |---| Template |---> 512 | 256 | | 256 | | 256 | 513 | PR| | PR| | FR| 514 +--------+ +---------+ +----------+ 515 Figure 1 517 If an Options Template is necessary to understand the content of 518 a Data Record (i.e. the scope in the Options Template Record is 519 an Information Element contained in the Data Record), the 520 Options Template Record may be sent in the same stream, as 521 displayed in figure 2. 523 +--------+ +--------+ +----------+ 524 | | | | | | 525 stream 20 ... ---| Data |...| Data |-----| Template |--- 526 | 258 | | 258 | | 258 | 527 | PR| | PR| | FR| 528 +--------+ +--------+ +----------+ 530 +--------+ +----------+ 531 | | | Options | 532 ...---| Data |-------| Template |------> 533 | 257 | | 257 | 534 | FR| | FR| 535 +--------+ +----------+ 536 Figure 2 538 Figure 2 shows an example where stream 20 carries an Options 539 Template with Template ID 257 transmitted with full reliability 540 (FR), an associated Data Record transmitted with full 541 reliability (FR), a Template with Template ID 258 transmitted 542 with full reliability (FR), and associated Data Records 543 transmitted with partial reliability (PR). In this example the 544 Option Template Record contains information required to decode 545 the latter Data Records, such as Common Properties information 546 [IPFIX-RED-RED]. So it makes sense to export the Data Sets 257 547 reliably. If some Data Record loss is observed from the 548 Sequence Number , the loss can only stem from the Data Sets with 549 the Template ID 258, as these are the only Sets not exported 550 reliably. Therefore, the calculation of loss per Template ID 551 258 is possible. 553 Note that, because all IPFIX Message must be sent in order 554 within a stream, the Options Template 257 will always arrive 555 before its associated Data Records, and that the Template 259 556 will always arrive before the its associated Data Records. 558 Figure 3 show an example where stream 30 carries an Template 559 with Template ID 259 transmitted with full reliability (FR), an 560 associated Data Record transmitted with partial reliability 561 (PR), a Template Withdrawal Message, followed by a redefinition 562 of the Template ID 259, and finally the new definition of Data 563 Record transmitted with partial reliability. The Template 564 Withdrawal Message and the new definition of the Template ID 259 565 are sent immediately, without waiting for the Template Reuse 566 Delay. 568 +--------+ +----------+ +----------+ 569 | | | | | Template | 570 stream 30 ... ---| Data |...| Template |-----| Withdraw.|--- 571 | 259 | | 259 | | 259 | 572 | PR| | FR| | FR| 573 +--------+ +----------+ +----------+ 575 +--------+ +----------+ 576 | | | | 577 ...---| Data |-------| Template |------> 578 | 259 | | 259 | 579 | PR| | FR| 580 +--------+ +----------+ 582 Figure 3 584 6. IANA Considerations 586 This document has no actions for IANA. 588 7. Security Considerations 590 The same security considerations as for the IPFIX Protocol 591 [RFC5101] apply. 593 8. References 595 8.1. Normative References 597 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 598 Requirement Levels, BCP 14, RFC 2119, March 1997 600 [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., Conrad, 601 P., "Stream Control Transmission Protocol (SCTP), 602 Partial Reliability Extension", May 2004 604 [RFC4960] Stewart, R., Ed., "Stream Control Transmission 605 Protocol", RFC 4960, September 2007. 607 [RFC5101] Claise, B., Ed., "Specification of the IP Flow 608 Information Export (IPFIX) Protocol for the Exchange of 609 IP Traffic Flow Information", RFC 5101, January 2008. 611 [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. 612 Raspall, "Sampling and Filtering Techniques for IP 613 Packet Selection" draft-ietf-psamp-sample-tech-10.txt, 615 [SCTP-RESET] Stewart, R., Lei, P., Tuexen, M, "Stream Control 616 Transmission Protocol (SCTP) Stream Reset", draft- 617 stewart-sctpstrrst-05.txt, Internet-Draft work in 618 progress, June 2007 620 8.2. Informative References 622 [RFC3917] Quittek, J., Zseby, T., Claise, B. Zander, S, 623 Requirements for IP Flow Information Export, RFC 3917, 624 October 2004 626 [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek, 627 J., "Architecture Model for IP Flow Information Export" 628 draft-ietf-ipfix-architecture-12, Internet-Draft work 629 in progress, September 2006 631 [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B., 632 "IPFIX Applicability", draft-ietf-ipfix-as-12.txt, 634 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and 635 J. Meyer, "Information Model for IP Flow Information 636 Export", RFC 5102, January 2008. 638 [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, 639 "Information Model for Packet Sampling Exports", draft- 640 ietf-psamp-info-07.txt, Internet-Draft work in 641 progress, October 2007 643 [PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet 644 Sampling (PSAMP) Protocol Specifications", draft-ietf- 645 psamp-protocol-09, Internet-Draft work in progress, 646 December 2007. 648 [PSAMP-FMWK] D. Chiou, B. Claise, N. Duffield, A. Greenberg, M. 649 Grossglauser, P. Marimuthu, J. Rexford, G. Sadasivan, 650 "A Framework for Passive Packet Measurement" draft- 651 ietf-psamp-framework-12.txt, Internet-Draft work in 652 progress, June 2007 654 [IPFIX-RED-RED] Boschi, E., Mark, L., Claise, B. "Reducing 655 Redundancy in IPFIX and PSAMP Reports", Internet-Draft 656 work in progress, draft-ietf-ipfix-reducing-redundancy- 657 04.txt, May 2007 659 [PSAMP-MIB] Dietz, T., Claise, B. "Definitions of Managed 660 Objects for Packet Sampling", Internet-Draft work in 661 progress, June 2006 663 9. Acknowledgements 665 The authors would like to thank Brian Trammell for expert 666 feedback, Randall Stewart and Peter Lei for their SCTP-related 667 feedback. 669 10. Author's Addresses 671 Benoit Claise 672 Cisco Systems Inc. 673 De Kleetlaan 6a b1 674 Diegem 1813 675 Belgium 677 Phone: +32 2 704 5622 678 Email: bclaise@cisco.com 680 Paul Aitken 681 Cisco Systems (Scotland) Ltd. 682 96 Commercial Quay 683 Commercial Street 684 Edinburgh, EH6 6LX, United Kingdom 686 Phone: +44 131 561 3616 687 Email: paitken@cisco.com 689 Andrew Johnson 690 Cisco Systems (Scotland) Ltd. 691 96 Commercial Quay 692 Commercial Street 693 Edinburgh, EH6 6LX, United Kingdom 695 Phone: +44 131 561 3641 696 Email: andrjohn@cisco.com 698 Gerhard Muenz 699 University of Tuebingen 700 Computer Networks and Internet 701 Sand 13 702 Tuebingen D-72076 703 DE 705 Phone: +49 7071 29-70534 706 Email: muenz@informatik.uni-tuebingen.de 707 URI: http://net.informatik.uni-tuebingen.de/~muenz 709 11. Intellectual Property Statement 711 The IETF takes no position regarding the validity or scope of 712 any Intellectual Property Rights or other rights that might be 713 claimed to pertain to the implementation or use of the 714 technology described in this document or the extent to which any 715 license under such rights might or might not be available; nor 716 does it represent that it has made any independent effort to 717 identify any such rights. Information on the procedures with 718 respect to rights in RFC documents can be found in BCP 78 and 719 BCP 79. 720 Copies of IPR disclosures made to the IETF Secretariat and any 721 assurances of licenses to be made available, or the result of an 722 attempt made to obtain a general license or permission for the 723 use of such proprietary rights by implementers or users of this 724 specification can be obtained from the IETF on-line IPR 725 repository at http://www.ietf.org/ipr. 727 The IETF invites any interested party to bring to its attention 728 any copyrights, patents or patent applications, or other 729 proprietary rights that may cover technology that may be 730 required to implement this standard. Please address the 731 information to the IETF at ietf-ipr@ietf.org. 733 12. Copyright Statement 735 Copyright (C) The IETF Trust (2008). 737 This document is subject to the rights, licenses and 738 restrictions contained in BCP 78, and except as set forth 739 therein, the authors retain all their rights. 741 13. Disclaimer 743 This document and the information contained herein are provided 744 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 745 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 746 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 747 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 748 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 749 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 750 OR FITNESS FOR A PARTICULAR PURPOSE.