idnits 2.17.1 draft-chen-coloring-based-ipfpm-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 410 -- Looks like a reference, but probably isn't: '2' on line 405 ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) == Outdated reference: A later version (-04) exists of draft-tempia-opsawg-p3m-02 -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Chen 3 Internet-Draft H. Liu 4 Intended status: Informational Y. Yin 5 Expires: August 29, 2013 Huawei Technologies 6 February 25, 2013 8 Coloring based IP Flow Performance Measurement Framework 9 draft-chen-coloring-based-ipfpm-framework-01 11 Abstract 13 By setting one unused bit of the IP header of packets to "color" the 14 packets into different color blocks, it naturally gives a way to 15 measure the real packet loss and delay without inserting any extra 16 OAM packets. This is called "coloring" based IP Flow Performance 17 Measurement (IPFPM). This document specifies a framework and 18 protocol for this "coloring" based IPFPM. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 29, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview and Concept . . . . . . . . . . . . . . . . . . . . . 4 62 3. Reference Model and Functional Components . . . . . . . . . . 5 63 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Functional Components . . . . . . . . . . . . . . . . . . 6 65 3.2.1. Measurement Control Point . . . . . . . . . . . . . . 6 66 3.2.2. Data Collecting Point . . . . . . . . . . . . . . . . 7 67 3.2.3. Target Logical Port . . . . . . . . . . . . . . . . . 7 68 4. Principles of Coloring based IPFPM . . . . . . . . . . . . . . 8 69 4.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 8 70 4.2. Packet Delay Measurement . . . . . . . . . . . . . . . . . 9 71 5. Color Bits Selection . . . . . . . . . . . . . . . . . . . . . 10 72 6. Statistic Information Report . . . . . . . . . . . . . . . . . 10 73 6.1. IPFIX for coloring based IPFPM . . . . . . . . . . . . . . 11 74 6.1.1. Information Element for IPFPM . . . . . . . . . . . . 12 75 6.1.2. DCP Status Template Set . . . . . . . . . . . . . . . 13 76 6.1.3. Packet Loss Template Set . . . . . . . . . . . . . . . 13 77 6.1.4. Packet Delay Template Set . . . . . . . . . . . . . . 15 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 Performance Measurement (PM) is an important tool that can not only 89 provide Service Level Agreement (SLA) verification but facilitate in 90 trouble shooting (e.g., fault localization or fault delimitation) and 91 network visualization. 93 There are two types of performance measurement: one is active 94 performance measurement, and the other is passive performance 95 measurement. 97 In active performance measurement the receiver measures the injected 98 packets to evaluate the performance of a path. The active 99 measurement measures the performance of the extra injected packets, 100 the rate, numbers and interval of the injected packets will largely 101 affect the accuracy of the results. In addition, it also requires 102 that the injected packets have to follow the same path as the real 103 traffic; this normally cannot be guaranteed in the pure IP network. 104 The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way 105 Active Measurement Protocol (TWAMP) [RFC5357] are tools to enable 106 active performance measurement. 108 In passive performance measurement, no artificial traffic is injected 109 into the flow and measurements are taken to record the performance 110 metrics of the real traffic. The Multiprotocol Label Switching 111 (MPLS) PM protocol [RFC6374] for packet loss is an example of passive 112 performance measurement. By periodically inserting auxiliary 113 Operations, Administration, and Maintenance (OAM) packets, the 114 traffic is delimited by the OAM packets into consecutive blocks, and 115 the receivers count the packets and calculate the packets loss each 116 block. 118 But, when the OAM channel is in-band, solutions like [RFC6374] are 119 not pure passive measurement as the OAM packets are inserted into the 120 data stream. Furthermore because solutions like [RFC6374] depend on 121 the fixed positions of the delimiting OAM packets for packets 122 counting, they are vulnerable to out-of-order arrival of packets. 123 This could happen particularly with out-of-band OAM channels, but 124 might also happen with in-band OAM because of the presence of 125 multipath forwarding within the network. Out of order delivery of 126 data and the delimiting OAM can give rise to inaccuracies in the 127 performance measurement figures. The scale of these inaccuracies 128 will depend on data speeds and the variation in delivery, but with 129 out-of-band OAM, this could result in significant differences between 130 real and reported performance. 132 This document describes a mechanism where data packets are marked or 133 "colored" so that they form blocks of data. No additional delimiting 134 OAM is needed and the performance can be measured in-service without 135 the insertion of additional traffic. Furthermore, because coloring 136 based IP performance measurement does not require extra OAM packets 137 for traffic delimitation, it can be used in situations where there is 138 packets re-ordering. This document specifies a framework and 139 protocol for the "coloring" based IP Flow Performance Measurement 140 (IPFPM). 142 2. Overview and Concept 144 The concept of "coloring" IP packets for performance measurement is 145 described in [I-D.tempia-opsawg-p3m]. By "coloring" the packets of a 146 specific IP flow to different colors, it naturally splits the IP flow 147 into deferent consecutive blocks. 149 For packet loss measurement, there are two ways to color packets: 150 fixed packet numbers or fixed time period for each color block. This 151 document only talks about the way of fixed time period. The sender 152 and receiver nodes count the transmitted and received packets/octets 153 based on each color block. By collecting and comparing the 154 transmitted and received packets/octets, it can easily detect whether 155 there is packet loss and how many packets/octets get lost. 157 For packet delay measurement, there are two solutions. One is 158 similar to packet loss, it still colors the IP flow to different 159 color blocks and uses the time when color changing as the reference 160 time for delay calculation. This solution requires that there must 161 not be any out-of-order packets, otherwise, the result will not be 162 accurate. Because it uses the first packet of each color block for 163 delay measurement, if there is packet reordering, the first packet of 164 each block at the sender will be probably different from the first 165 packet of the block at the receiver. The other way is to 166 periodically color a single packet of the IP flow. Within a time 167 period, there is only one packet can be colored. The sender records 168 the timestamp when the colored packet is transmitted, the receiver 169 records the timestamp when detecting the colored packet. With the 170 two timestamps, the packet delay can be computed. 172 To make the above solutions work, two conditions are required. The 173 first one is that there have to be a way to collect the packet counts 174 and timestamps from the senders and receivers to a centralized 175 calculation element. The IP Flow Information eXport (IPFIX) 176 [RFC5101] protocol is used for collecting the performance measurement 177 statistic information (Section 5 of this document). The second is 178 that the centralized calculation element has to know what exactly a 179 pair of packet counts(one from the sender and the other is from the 180 receiver) are based on the same color block and a pair of timestamps 181 (one from the sender and the other is from the receiver) are based on 182 the same colored packet. The "Period Number" based solution (Section 183 4.2 of this document) is introduced to achieve this. 185 3. Reference Model and Functional Components 187 3.1. Reference Model 189 An Multipoint-to-Multipoint (MP2MP) reference model (as shown in 190 Figure 1) is introduced in this document. For a specific IP flow, 191 there may be one or more upstream and downstream Measurement Points 192 (MPs). An IP flow can be identified by the Source IP (SIP) and 193 Destination IP (DIP) addresses, and it may combine the SIP and DIP 194 with any or all of the Protocol number, the Source port, the 195 Destination port, and the Type of Service (TOS) to identify an IP 196 flow. For each flow, there will be a flow identifier that is unique 197 within a certain administrative domain. 199 An MP is a network node. From the measurement point of view, it 200 consists of two parts (as shown in Figure 2): Data Collecting Point 201 (DCP), and Target Logical Port (TLP). For an MP, there is only one 202 DCP and may be one or more TLPs. The Measurement Control Point (MCP) 203 is a centralized calculation element, MPs periodically report their 204 measurement data to the MCP for final performance calculation. The 205 report protocol is defined Section 5 of this document. 207 The reason for choosing MP2MP model is that it can satisfy all the 208 scenarios that include Point-to-Point (P2P), Point-to-Multipoint 209 (P2MP), Multipoint-to-Point (MP2P), and MP2MP. P2P scenario is 210 obvious and can be used anywhere. P2MP and MP2P are very common in 211 mobile backhaul networks. For example, a Cell Site Gateway (CSG) 212 multi-homing to two Radio Network Controller (RNC) Site Gateways 213 (RSGs) is a typical network design. When there is a failure, there 214 is a requirement to monitor the flows between the CSG and the two 215 RSGs hence to determine whether the fault is in the transport network 216 or in the wireless network(this is normally called "fault 217 delimitation"). This is especially useful in the situation where the 218 transport network belongs to one service provider and wireless 219 network belongs to other service providers. 221 +-----+ 222 +------| MCP |------+ 223 | +-----+ | 224 +-----+ | +---/ \---+ | +-----+ 225 | MP1 |---+ | | +---| MP3 | 226 +-----+ | | +-----+ 227 +-----+ | | +-----+ 228 | MP2 |------+ +------| MP4 | 229 +-----+ +-----+ 230 Figure 1: MP2MP based Model 232 +----------------------+ 233 | +--------+ | 234 | | DCP | | Control Plane 235 | +--------+ | 236 ----------|-----/----------\-----|-------------- 237 | +--+--+ +--+--+ | 238 | | TLP1| | TLP2| | Data plane 239 | +-----+ +-----+ | 240 +----------------------+ 241 Figure 2: Measurement Point 243 3.2. Functional Components 245 3.2.1. Measurement Control Point 247 The MCP is responsible for calculating the final performance metrics 248 according to the received measurement data from the MPs (actually 249 from the DCPs). For packet loss, based on each color block, the 250 difference between the total counts received from all upstream MPs 251 and the total counts received from all downstream MPs are the lost 252 packet numbers. The MCP must make sure that the counts from the 253 upstream MPs and downstream MPs are related to the same color block. 254 For packet delay (e.g., one way delay), the difference between the 255 timestamps from the downstream MP and upstream MP is the packet 256 delay. Similarly to packet loss, the MCP must make sure the two 257 timestamps are based on the same colored packet. 259 This document introduces a Period Number (PN) based synchronization 260 mechanism to help the MCP to determine whether any two or more packet 261 counts (from distributed MPs) are related to the same color block or 262 any two timestamps are related to the same colored packet. The PN is 263 generated each time a DCP reads the packet counts and timestamps from 264 the TLP, and is equal to the modulo of the local time (when the 265 counts and timestamps are read) and the interval of the color time 266 period. Each packet count and timestamp has a PN when reported to 267 the MCP, and the same PN means that they are related to the same 268 color block or colored packet. This requires that the upstream and 269 downstream MPs having a certain time synchronization capability 270 (e.g., supporting the Network Time Protocol (NTP) [RFC5905], or the 271 IEEE 1588 Precision Time Protocol (PTP) [IEEE1588].) and assumes that 272 the upstream and downstream MPs have already time synchronized. 273 Since is the intention to measure packet delay, this requirement for 274 time synchronization is already present. 276 3.2.2. Data Collecting Point 278 The DCP is responsible for periodically collecting the measurement 279 data from the TLPs and for reporting the data to the MCP. In 280 addition, when to change the color, when to color a packet (for 281 packet delay measurement), and when to read the packet counts and 282 timestamps are also controlled by DCP. Each DCP will maintain two 283 timers, one (C-timer, used at upstream DCP) is for color changing, 284 the other (R-timer, used at downstream DCP) is for reading the packet 285 counts and timestamps. The two timers have the same time interval 286 but are started at different times. A DCP can be either an upstream 287 or a downstream DCP: the role is specific to an IP flow. For a 288 specific IP flow, the upstream DCP will change the color and read the 289 packet counts and timestamps when the C-timer expires, the downstream 290 DCP just reads the packets counts and timestamps when the R-timer 291 expires. In order to allow for a certain degree of packets re- 292 ordering, the R-timer should be started later than a defined period 293 of time after the C-timer is started (e.g., 1/3 or 2/3 T, where T is 294 the interval of the C-timer). It recommends that: for packet loss 295 measurement, the R-timer should be started at 1/3 T after the C-Timer 296 is started, and for packet delay measurement, the R-timer should be 297 started at 2/3 T after the C-Timer is started. 299 To make the implementation simple, the C-timer should be started at 300 the beginning of each time period. This document recommends the 301 implementation to support at least these time periods (1s, 10s, 1min, 302 10min and 1h). So, if the time period is 10s, the C-timer should be 303 started at the time of any multiples of 10 in seconds (e.g., 0s, 10s, 304 20s, etc.), then the R-timer should be started, for example, at the 305 time of T+1/3 or 2/3 T. With this method, each DCP can independently 306 start its C-timer and R-timer given that the clocks have been 307 synchronized. 309 3.2.3. Target Logical Port 311 The TLP is a logical entity that actually executes the final 312 measurement actions (e.g., colors the packets, counts the packets, 313 records the timestamps, etc.). Normally, a physical interface 314 corresponds to a TLP, and the TLP resides in the data plane. For a 315 measurement instance (corresponding to an IP flow), a TLP will 316 maintain a pairs of packet counters and a timestamp counter for each 317 color block. One packet counter is for counting packets and the 318 other is for counting octets. 320 4. Principles of Coloring based IPFPM 322 The flows discussed in this document are all unidirectional. For a 323 specific flow, there will be upstream and downstream TLPs and 324 upstream and downstream packet counts/timestamp accordingly. 326 4.1. Packet Loss Measurement 328 For packet loss measurement, this document defines the following 329 counters and quantities: 331 U-CountP[n][m]: U-CountP identifies the packets transmitted by a 332 upstream TLP, the "n" identifies the "period number" of the measured 333 color block, the "m" identifies the No. m TLP of the upstream TLPs. 335 D-CountP[n][m]: U-CountP identifies the packets received by a 336 downstream TLP, the "n" identifies the "period number" of the 337 measured color block, the "m" identifies the No. m TLP of the 338 downstream TLPs. 340 U-CountO[n][m]: U-CountO identifies the octets transmitted by a 341 upstream TLP, the "n" identifies the "period number" of the measured 342 color block, the "m" identifies the No. m TLP of the upstream TLPs. 344 D-CountO[n][m]: U-CountO identifies the packets received by a 345 downstream TLP, the "n" identifies the "period number" of the 346 measured color block, the "m" identifies the No. m TLP of the 347 downstream TLPs. 349 LossP: the number of packets transmitted by the upstream TLPs but not 350 received at the downstream TLPs. 352 LossO: the total octets transmitted by the upstream TLPs but not 353 received at the downstream TLPs. 355 The the total packet loss of a flow can be computed as follows: 357 LossP = U-CountP[1][1] + U-CountP[1][2].... + U-CountP[n][m] - 358 D-CountP[1][1]-D-CountP[1][2]-D-CountP[n][m']. 360 LossO = U-CountO[1][1] + U-CountO[1][2].... + U-CountO[n][m] - 361 D-CountO[1][1]-D-CountO[1][2]-D-CountO[n][m']. 363 Where the m is the number of the upstream TLPs, and the m' is the 364 number of the downstream TLPs. 366 4.2. Packet Delay Measurement 368 For packet delay measurement, there will be only one upstream TLP and 369 may be one or more (P2MP) downstream TLPs. Although the coloring 370 based IPFPM supports P2MP model, this document only discusses P2P 371 model, the P2MP model is left for future study. This document 372 defines the following timestamps and quantities: 374 U-Time[n]: U-Time identifies the time when sent a colored packet, the 375 "n" identifies the "period number" of the colored packet. 377 D-Time[n]: D-Time identifies the time when received a colored packet, 378 the "n" identifies the "period number" of the colored packet. This 379 is only for P2P model. 381 D-Time[n][m]: D-Time identifies the time when received a colored 382 packet, the "n" identifies the "period number" of the colored packet, 383 the "m" identifies the No. m TLP of the downstream TLPs. This is for 384 P2MP model and is left for future study. 386 One-way Delay[n]: The one-way delay metric for packet networks is 387 described in [RFC2679]. The "n" identifies the "period number" of 388 the colored packet. 390 One-way Delay[1] = D-Time[1] - U-Time[1]. 392 One-way Delay[2] = D-Time[2] - U-Time[2]. 394 ... 396 One-way Delay[n] = D-Time[n] - U-Time[n]. 398 In the case of two-way delay, the delay is the sum of the two one-way 399 delays of the two flows that have the same TLPs but have opposite 400 directions. 402 Two-way Delay[1] = (D-Time[1] - U-Time[1]) + (D-Time'[1] - 403 U-Time'[1]). 405 Two-way Delay[2] = (D-Time[2] - U-Time[2]) + (D-Time'[2] - 406 U-Time'[2]). 408 ... 410 Two-way Delay[1] = (D-Time[n] - U-Time[n]) + (D-Time'[n] - 411 U-Time'[n]). 413 Where the D-Time and U-Time are for one forward flow, the D-Time' and 414 U-Time' are for reverse flow. 416 5. Color Bits Selection 418 This document does not specify which bits should be used for 419 coloring, it just introduces some options that the operators can 420 select for packet coloring usage. There are not too much bits in the 421 IP header that can be used for IP packet coloring, this document 422 introduces two options: 424 One is to use the reserved bit of the Flag field. There is only one 425 bit that is left, so it cannot be used for packet loss and delay 426 measurement simultaneously. 428 The other option is to use some "unused" bits of the Type Of Service 429 (TOS) field. 431 For both options, the operators should carefully think of the color 432 bits selection to make sure that the setting or changing of the color 433 bits SHOULD NOT affect the normal packet forwarding and process. 435 The implementations should provide some knobs for operators to 436 configure and change the color bits according to their network design 437 and policies. 439 6. Statistic Information Report 441 As described in Section 4 of this document, when the performance 442 measurement started, each DCP will periodically report performance 443 measurement statistic information to the MCP, and the MCP will 444 compute the final performance measurement results according to the 445 received statistic information. 447 For a specific IP flow, whatever for packet delay or loss 448 measurement, there will be at least one upstream and one downstream 449 DCP. As described above section, time synchronization is required 450 and the Period Number is used for MCP to identify and correlate the 451 packet counts and timestamps from the upstream and downstream DCPs to 452 a specific color block or colored packet. 454 For packet loss measurement, the following information is required to 455 report to the MCP: 457 DCP Identifier 459 TLP Identifier 461 Flow Identifier 463 Period Number 465 Packet Number Count 467 Packet Octets Count 469 For packet delay measurement, the following information is required 470 to report to the MCP: 472 DCP Identifier 474 TLP Identifier 476 Flow Identifier 478 Period Number 480 Timestamp 482 In addition, a DCP may report some status and statistic information 483 to the MCP, the following information may be included: 485 DCP Identifier 487 DCP Status 489 Others 491 6.1. IPFIX for coloring based IPFPM 493 The IPFIX protocol [RFC5101] defines how IP Flow information can be 494 exported from routers, measurement probes, or other devices. It 495 defines many Information Elements [RFC5102] that can be used to carry 496 and export the above information from DCP to MCP. Except the Period 497 Number and DCP Status, all the above information can be identified 498 with the existing Information Elements. 500 DCP Identifier: exporterIPv4Address/exporterIPv6Address (130/131) 502 TLP Identifier: meteringProcessId (143) 503 Flow Identifier: flowId (148) 505 Packet Number Count: packetTotalCount (86) 507 Packet Octets Count: octetTotalCount (85) 509 Timestamp: flowStartMilliseconds (152) 511 6.1.1. Information Element for IPFPM 513 6.1.1.1. periodNumber 515 Description: The periodNumber is used to identify a packet count or 516 timestamp that belongs to a specific color block or colored packet. 517 The MCP uses it to determine whether any two or more packet counts 518 (from distributed DCPs) are related to the same color block or any 519 two timestamps are related to the same colored packet. The PN is 520 generated each time a DCP reads the packet counts and timestamp from 521 the TLP, and is equal to the modulo of the local time (when the 522 counts and timestamps are read) and the interval of the color time 523 period. 525 Abstract Data Type: unsigned32 527 ElementId: TBD 529 Status: current 531 6.1.1.2. dcpStatus 533 Description: The dcpStatus is used to carry some status of the DCP, 534 for example, whether the DCP has already time synchronized. 536 Abstract Data Type: unsigned8 538 ElementId: TBD 540 Status: current 542 The dcpStaus is defined as follows: 544 +-+-+-+-+-+-+-+-+ 545 | Reserved |T| 546 +-+-+-+-+-+-+-+-+ 548 One bit (Time synchronized bit) is defined in this document, it is 549 used to indicate whether a DCP is time synchronized. When T bit set, 550 the DCP is time synchronized, otherwise, the DCP is not time 551 synchronized. The MCP MUST calculate the results when all related 552 DCPs of a flow are time synchronized, otherwise, the results will not 553 correct. 555 6.1.2. DCP Status Template Set 557 The DCP Status Template is an Option Template Set, it is used to 558 report the status and statistic information of the DCP to MCP. 559 0 1 2 3 560 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Set ID = 3 | Length = 24 | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Template ID 256 | Field Count = 3 | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Scope Field Count = 1 |0| dcpStatus = TBD | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Scope 1 Field Length = 1 |0|exportedMessageTotalCount=41 | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Scope 2 Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Field Length = 2 | Padding | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 The dcpStatus is as defined in Section 6.1.1.2of this document. 577 The exportedMessageTotalCount field is used to report how many IPFIX 578 messages that the DCP has sent to the MCP. 580 The exportedFlowRecordTotalCount is used to report how many IPFIX 581 flow records that the DCP has sent to the MCP. 583 6.1.3. Packet Loss Template Set 585 The Packet Loss Template Set is a Data Set, it is used to report the 586 packet loss measurement statistic of a flow to the MCP. 588 The Data Set will be as follows: 590 0 1 2 3 591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Set ID = 2 | Length = 32 octets | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Template ID 257 | Field Count = 6 | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 |0| exporterIPv4Address = 130 | Field Length = 4 | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |0| meteringProcessId = 143 | Field Length = 4 | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |0| flowId = 148 | Field Length = 4 | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |0| periodNumber = TBD | Field Length = 4 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |0| packetTotalCount = 86 | Field Length = 8 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 |0| octetTotalCount = 85 | Field Length = 8 | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 The exporterIPv4Address is used to carry the DCP ID. 612 The meteringProcessId is used to carry the TLP ID. 614 The flowId is a identifier that is unique within a specific 615 administrative domain (e.g., an Autonomous System). The TLP, DCP and 616 MCP have to agree a flow identifier related to a specific flow. For 617 example, the flow identifier can be generated and maintained by a 618 centralized element. How to generate and maintain the flowId is out 619 the scope of this document. 621 The flowId has the following structure, it consists of two parts: one 622 the Reserved field that is left for future extensions, the other is 623 the Identifier field is 24-bit in length. 624 0 1 2 3 625 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Reserved | Identifier | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 The periodNumber is as defined in Section 6.1.1.1 of this document. 632 The packetTotalCount is used to carry the total transmitted/received 633 packets of a flow since the measurement start. 635 The octetTotalCount is used to carry the total transmitted/received 636 octets of a flow since the measurement start. 638 6.1.4. Packet Delay Template Set 640 The Packet Delay Template Set is a Data Set, it is used to report the 641 packet delay measurement statistic of a flow to the MCP. 643 The Data Set will be as follows: 645 0 1 2 3 646 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Set ID = 2 | Length = 24 octets | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Template ID 258 | Field Count = 5 | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 |0| exporterIPv4Address = 130 | Field Length = 4 | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 |0| meteringProcessId = 143 | Field Length = 4 | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |0| flowId = 148 | Field Length = 4 | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 |0| PeriodNumber = TBD | Field Length = 4 | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 |0| flowStartMilliseconds = 152 | Field Length = 8 | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 The exporterIPv4Address is used to carry the DCP ID. 665 The meteringProcessId is used to carry the TLP ID. 667 The flowId is used to carry the flow identifier of a flow, the 668 structure is defined in Section 6.1.3 of this document. 670 The periodNumber is as defined in Section 6.1.1.1 of this document. 672 The flowStartMilliseconds is used to carry the timestamp of a colored 673 packet of a specific flow. 675 7. IANA Considerations 677 TBD. 679 8. Security Considerations 681 TBD. 683 9. Acknowledgements 685 The authors would like to thank Adrian Farrel for his review, 686 suggestion and comments to this document. 688 10. References 690 10.1. Normative References 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, March 1997. 695 [RFC5101] Claise, B., "Specification of the IP Flow Information 696 Export (IPFIX) Protocol for the Exchange of IP Traffic 697 Flow Information", RFC 5101, January 2008. 699 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 700 Meyer, "Information Model for IP Flow Information Export", 701 RFC 5102, January 2008. 703 10.2. Informative References 705 [I-D.tempia-opsawg-p3m] 706 Bonda, A., Capello, A., Cociglio, M., and L. Castaldelli, 707 "A packet based method for passive performance 708 monitoring", draft-tempia-opsawg-p3m-02 (work in 709 progress), July 2012. 711 [IEEE1588] 712 IEEE, "1588-2008 IEEE Standard for a Precision Clock 713 Synchronization Protocol for Networked Measurement and 714 Control Systems", March 2008. 716 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 717 Delay Metric for IPPM", RFC 2679, September 1999. 719 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 720 Zekauskas, "A One-way Active Measurement Protocol 721 (OWAMP)", RFC 4656, September 2006. 723 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 724 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 725 RFC 5357, October 2008. 727 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 728 Time Protocol Version 4: Protocol and Algorithms 729 Specification", RFC 5905, June 2010. 731 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 732 Measurement for MPLS Networks", RFC 6374, September 2011. 734 Authors' Addresses 736 Mach(Guoyi) Chen 737 Huawei Technologies 739 Email: mach.chen@huawei.com 741 Hongming Liu 742 Huawei Technologies 744 Email: liuhongming@huawei.com 746 Yuanbin Yin 747 Huawei Technologies 749 Email: yinyuanbin@huawei.com