idnits 2.17.1 draft-sun-tsvwg-flowbased-pm-00.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 == Line 510 has weird spacing: '... * sum td...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2012) is 4317 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2330' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC4656' is defined on line 653, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG Lishun. Sun 3 Internet-Draft Wendong. Wang 4 Intended status: Informational BUPT 5 Expires: December 31, 2012 Fang. Yu 6 Huawei Technologies 7 June 29, 2012 9 Flow-based Performance Measurement 10 draft-sun-tsvwg-flowbased-pm-00 12 Abstract 14 The performance measurements of service flow are becoming significant 15 important for administrators monitoring the fitness of the network. 16 This memo defines an end-to-end application-based performance 17 measurement method, which is achieved by generating synthetic 18 measurement packets, injecting them to the network and analyzing the 19 statistics carried in the measurement packets. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 31, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 69 2.1. Conventions Used in This Document . . . . . . . . . . . . 3 70 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4 74 3.3. Logical Model . . . . . . . . . . . . . . . . . . . . . . 5 75 4. Measurement Process . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Connection Activation . . . . . . . . . . . . . . . . . . 6 77 4.2. Measurement Process . . . . . . . . . . . . . . . . . . . 8 78 4.3. Connection Deactivation . . . . . . . . . . . . . . . . . 10 79 5. Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. Delay Calculation . . . . . . . . . . . . . . . . . . . . 11 81 5.2. Jitter Calculation . . . . . . . . . . . . . . . . . . . . 12 82 5.3. Loss Calculation . . . . . . . . . . . . . . . . . . . . . 12 83 6. Exception Handling . . . . . . . . . . . . . . . . . . . . . . 13 84 6.1. FM/BR Packet Loss . . . . . . . . . . . . . . . . . . . . 13 85 6.2. Packet Mis-ordering . . . . . . . . . . . . . . . . . . . 13 86 7. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 The IETF IP Performance Metrics (IPPM) working group has defined a 98 series of standard metrics that can be applied to the quality, 99 performance and reliability of Internet data delivery services. 101 In some cases, it needs to monitor the various time-varying 102 performance indexes of the IP network, the performance measurement 103 should be based on real service stream and reflect the real 104 performance of the network. The average performance indexes measured 105 by the active measurement method may not be suitable in these cases. 107 This memo proposes an IP performance measurement method which can 108 support on-the-spot measurement, that is, measurement is performed 109 online when service is running. This method is an end-to-end flow- 110 based method which can obtain measurement data simply and accurately. 111 It injects the OAM packets to the network which are used to carry 112 some parameters related to service flow and some statistic 113 information. The OAM packets are processed using the same method as 114 its corresponding service flow, so the measurements can reflect the 115 network status suffered by the service flow more accurately. 117 This IP performance measurement method can monitor the real time 118 change of service and reflect the running situation of actual IP 119 service. It can play an important role in the fault diagnosis and 120 statistics of the service in IP transmission network. 122 2. Conventions and Terminology 124 2.1. Conventions Used in This Document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 2.2. Terminology 132 PM:performance monitoring 134 FM:Forward Monitoring 136 BR:Backward Reporting 138 3. Overview 139 3.1. Motivation 141 It is required to provide a reasonable estimation measurement of 142 delay, jitter and packet loss in IP network (such as backhaul 143 network). The above parameters are functions of time, and are 144 stochastic in nature. Therefore, the mechanism is required to 145 provide statistical condition estimations of the IP link status. 146 Moreover, since measurement injects some OAM packets to the network, 147 it is necessary that the frequency of packet generation is kept at a 148 minimum. Moreover, these packets should not lead to an excessive 149 computational overload on the measure device. In other words, the 150 process of generation of these measurement packets should be simple 151 and must not overload the transport interface. The packets must be 152 small and infrequent so as not to cause unnecessary overload on the 153 network bandwidth or influence the service running on the network. 155 3.2. Protocol overview 157 Firstly we make some statement for this method. We define a 158 measurement method that can be used in some scene. The method 159 proposed here involves three steps#: connection activation#, 160 measurement process and connection deactivation. 162 Two types of logical entities are defined, the PM Initiator and the 163 PM Responder. 165 Firstly the PM Initiator sends a request to the PM Responder to set 166 up the PM connection activation. The PM Responder responds with an 167 ACK packet including some parameters based on the request. When the 168 PM Initiator receives the ACK, it will prepare for starting the 169 measurement process. 171 During the measurement process, the PM Initiator periodically 172 generates Forward Monitor (FM) packets with the source and 173 destination IP addresses, and other classification information (for 174 example DSCP class) of the service packets , which are sent to the PM 175 Responder. The generation and transmission of FM packets can be 176 periodical with a specific time interval, or a certain number of 177 traffic packets should be sent between two contiguous FM packets. 179 The PM Responder receives the FM packets and sends Backward 180 Reporting(BR)packets which is constructed according to the FM 181 packets. 183 The path performance such as the delay, jitter and loss rate etc. are 184 calculates by the PM Initiator according to the information in the BR 185 packets. 187 The FM packets have the same source and destination IP addresses, 188 even the same DSCP class in some cases with the data packets. So 189 they are carried through the transport network just most like the 190 data packets, and delay, jitter and packet loss encountered by them 191 resembles the performance as seen by the packets of the actual 192 traffic flows. The FM and BR packets used in this method are small 193 enough to produce influence to actual service flow as little as 194 possible. 196 3.3. Logical Model 198 The role and definition of the logical entities and measurement 199 packets in this method are defined as follows. 201 This method is an end-to-end measurement, so two logical entities are 202 defined. 204 o PM Initiator: PM Initiator serves as the sending endpoint, and 205 charges for generating and sending the request to initiate a PM 206 connection. It could also send FM packets to collect measurement 207 data and generate statistical report. 209 o PM Responder: PM Responder serves as the receiving endpoint, and 210 charges for responding the request of initiating a link. It could 211 also send back a BR packet to the sending endpoint once it 212 receives the FM package from the PM Initiator. 214 One possible scenario of relationships between these roles is shown 215 below. 217 +---------------+ +----------------+ 218 | |-------------------->| | 219 | PM Initiator |<--------------------| PM Responder | 220 +---------------+ +----------------+ 222 Figure 1: One possible relationship between PM Initiator and PM 223 Responder 225 There are six types of packets in total, which include four types of 226 control packets and two types of measurement packets. 228 Note that a new port number is introduced to be assigned by the IANA. 229 The assigned port number is used as the destination port number of 230 the control packets and measurement packets#, and the source port 231 number can be random. 233 Control packet: 235 o ACT: It is sent from the PM Initiator to a specific UDP port on PM 236 Responder, carries parameters used in negotiation process when 237 initiating a PM connection. 239 o ACT-ACK: It is a response for ACT sent by the PM Responder to the 240 PM Initiator. 242 o DEA: It is sent by the PM Initiator to the PM Responder for 243 disconnecting the PM connection. 245 o DEA-ACK: It is a response for DEA sent by the PM Responder to the 246 PM Initiator. 248 Measurement packet: 250 o FM (Forward Monitoring): It is sent by the PM Initiator. The 251 format of FM packet payload as defined by this document will be 252 shown blow. FM packet header is constructed in accordance with 253 the data packet except the destination port. 255 o BR (Backward Reporting): It is sent by the PM Responder. The 256 format of BR packet payload as defined by this document will be 257 shown blow. It is a response for FM. 259 4. Measurement Process 261 4.1. Connection Activation 263 In the PM connection activation process, both the PM Initiator and 264 the PM Responder are assigned a Flow ID for a defined flow (the Flow 265 ID is unique in a connection between the PM Initiator and the PM 266 Responder). It should specify how to define the Flow corresponding 267 to the measurement instance. Flow can be defined by different 268 combinations of source IP address (SIP), destination IP address 269 (DIP), protocol type (PT), DSCP, source port number (sPort) and 270 destination port number (dPort). Three types of combinations are 271 suggested: (SIP, DIP, PT), or (SIP, DIP, PT, DSCP) or (SIP, DIP, PT, 272 sPort, dPort). The more the combinational dimensions are, the more 273 fine-grained can be the monitoring of data flow. 275 Before starting the measurement, a connection should be established. 276 When the PM Initiator wants to start the measurement process, it 277 enables the measurement capabilities to the PM Responder by sending 278 ACT packet to the specific UDP port on the PM Responder. When the PM 279 Responder receives the ACT, it enables its measurement function and 280 responses to the Sender with ACT-ACK packet. The connection 281 activation process is finished after the PM Initiator receiving the 282 ACT-ACK packet from the PM Responder, then the PM Initiator can send 283 FM packet after one cycle. The definition of flow, FlowID, and the 284 sending period of FM packets must be consulted by two ends during the 285 connection activation process. 287 The format of ACT packet is defined as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Ver | Type | Periods | FlowType | PT | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | SIP | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | DIP | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | sPort | dPort | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | sFlowId | DSCP | Reserved | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Ver and Type existed in all packets in this memo indicate the version 304 and type of packet. Type in this packets MUST be 0X1 indicates that 305 this is an ACT packet. 307 Periods defined by PM Initiator indicates the sending period of FM 308 packets. 310 FlowType indicates how a flow is defined.0x0 in this filed is for 311 (SIP, DIP, PT, sPort, dPort), while 0x1 is for (SIP, DIP, PT, DSCP) 312 and 0x2 is for (SIP, DIP, PT). The other values are not defined. 314 PT is the protocol type value of the service flow needed to be 315 measured. It may be UDP, TCP, SCTP or other types. 317 SIP is the source IP address of the service flow, and DIP is the 318 destination IP address of the service flow. SPort and DPort which 319 are valid only when the flow is defined by (SIP, DIP, PT, sPort, 320 dPort) indicate source/destination port number of the ACT packets. 321 If the FlowType is not defined by (SIP, DIP, PT, sPort, dPort), this 322 filed is 0xFF. 324 sFlowId is the flow id defined by the PM Initiator. 326 DSCP is valid only when the flow is defined by (SIP, DIP, PT, DSCP). 327 It indicates the value of the DSCP filed in IP header of service 328 flow. 330 Reserved is reserved for extensions in future and MUST be set to 0x0 331 currently. 333 The format of ACT-ACK packet is defined as follows: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Ver | Type | Periods | dFlowId | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | sFlowId | Reserved | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Type of 0X2 indicates ACT-ACK. 345 dFlowId is copied from the sFlowId field of the ACT packets. 347 sFlowId is the flow id defined by the PM Responder. 349 4.2. Measurement Process 351 When the connection is established successfully, the PM Initiator 352 sends FM packets according to the given time-interval, and the PM 353 Responder responses by sending BR packets after receiving FM packets 354 from the PM Initiator. The destination port number in the FM packet 355 header must be set as the specific number. 357 The format of FM packet is defined as follows: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Ver | Type | SN | dFlowId | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | FwdTxPkt | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | FwdTxByte | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | T1 | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Reserved | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Type of 0X3 indicates FM. 375 SN is the sequence number of the flow, which distinguishes the 376 different FM packets and indicates the correspondence between FM 377 packets and BR packets. Each PM flow should maintain a set of 378 sequence numbers (SN). 380 dFlowId is the flow id of the PM Responder, which is copied from 381 sFlowId in ACT-ACK. 383 FwdTxPkt is the accumulation of the number of the packets sent by the 384 PM Initiator. FwdTxByte is the accumulation of the number of bytes 385 sent by the PM Initiator.In order to determine the value of the 386 fields of FwdTxPkt and FwdTxByte, the PM Initiator maintains two 387 counters, SPN and SBN, for each PM flow that is incremented every 388 time a traffic packet is sent.When the FM packets are to be sent, the 389 FwdTxPkt and FwdTxByte are set to the then value of the counters 390 respectively. 392 T1 is the timestamp when the PM Initiator sends FM packets. There is 393 no requirement for synchronization between the PM Initiator and the 394 PM Responder. 396 The format of BR packet is defined as follows: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Ver | Type | SN | dFlowId | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | FwdTxPkt | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | FwdTxByte | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | T1 | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | T2 | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | FwdRxPkt | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | FwdRxByte | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | T3 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Reserved | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Type of 0X4 indicates BR. 422 SN is copied from the SN field of the corresponding FM packet. 424 dFlowId is the flow id of the PM Initiator, which is copied from 425 sFlowId in ACT. 427 The FwdTxPkt and FwdTxByte are copied from the corresponding FM 428 packet. FwdRxPkt is the accumulation of the number of the packets 429 received by the PM Responder. FwdRxByte is the accumulation of the 430 number of bytes received by the PM Responder. In order to determine 431 the value of the fields of FwdRxPkt and FwdRxByte, the PM Responder 432 maintains two counters, RPN and RBN, for each PM flow that is 433 incremented every time a traffic packet is received. When the BR 434 packets are to be sent, the FwdRxPkt and FwdRxByte are set to the 435 then value of the counters respectively. 437 T1 is copied from the T1 field of the FM packets, T2 is the timestamp 438 when the PM Responder receives the FM packets, and T3 is the 439 timestamp when the PM Responder sends the BR packets. 441 When the PM Responder receives a FM packet, it copies the value of 442 FwdTxPkt, FwdTxByte and T1 in FM packet into the corresponding fields 443 of the BR packet, and sets the fields of T3, FwdRxPkt and FwdRxByte 444 and sends the BR packet. 446 Note that the PM Initiator could start multiple measurement engines; 447 each engine is corresponding to an active logical path (with a 448 different Flow). These measurement engines operate in parallel, and 449 send FM packets with the flow id of the logical path, collect the 450 corresponding BR packets, and maintain the collected statistical 451 values. 453 4.3. Connection Deactivation 455 When the PM Initiator wants to stop the measurement, it sends 456 Connection Deactivation request packet called DEA to the PM 457 Responder. The PM Responder sends DEA-ACK packets back to the PM 458 Initiator after it receives the DEA packets. 460 The format of DEA packet is defined as follows: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Ver | Type | Reserved | dFlowId | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Type of 0X5 indicates DEA. 470 dFlowId is the flow id defined by the PM Responder, which is copied 471 from sFlowId in ACT-ACK. 473 The format of DEA-ACK packet is defined as follows: 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Ver | Type | Reserved | dFlowId | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Type of 0X6 indicates DEA-ACK. 483 dFlowId is the flow id defined by the PM Initiator, which is copied 484 from sFlowId in ACT. . 486 5. Statistics 488 5.1. Delay Calculation 490 In order to determine the delay sample for a given FM and BR packets, 491 we assume that the paths are symmetric; that is the delay would be 492 same for FM and BR packets. Therefore, the traffic delay is 493 calculated as: 495 (T4-T1)-(T3-T2) 496 Td = --------------- 497 2 499 Where td is the one-way delay for the dth BR received, t4 is the time 500 that the PM Initiator received the dth BR packet, t3 is the time that 501 the PM Initiator sent the dth FM packet. t2 is the time that the PM 502 Responder received dth FM packet, and t1 is the time that PM 503 Responder sent the dth BR packet(dth is a SN of a flow). 505 Let's assume that during the current reporting interval D, N BR 506 packets were received at the PM Initiator, the delay reported to the 507 network management entity is determined as 509 1 M+N-1 510 TD = --- * sum td 511 N d=M 513 Where TD is the delay metric reported corresponding to the interval D 514 to the network management entity. 516 5.2. Jitter Calculation 518 Jitter is defined as the Packet Delay Variation, and is not 519 calculated for each arriving BR packet. Instead, td values are 520 considered over several seconds, and the associated jitter value is 521 calculated. Let's consider that N consecutive delay values were used 522 to determine the dth jitter value, jp as: 524 ________________________ 525 | 1 M+N-1 2 526 jp = |--- * sum ( TD - Td ) 527 /\| N d=M 529 jp is the variance of delay 531 Note that hence calculated jitter value needs to be aggregated over 532 the reporting interval. Let's assume that during the current 533 reporting interval D, N such jitter calculations were made at the PM 534 Initiator, therefore the jitter reported to the network management 535 entity is determined as: 537 1 N 538 jD = --- * sum jp 539 N p=1 541 5.3. Loss Calculation 543 When the dth BR packet is received at the PM Initiator, the loss rate 544 plr based on the dth BR packet and (d-1)th BR packet is calculated 545 as: 547 (SPN(d)-SPN(d-1))-(RPN(d)-RPN(d-1)) 548 plrd = ------------------------------------- 549 SPN(d)-SPN(d-1) 551 (SPN(d)-SPN(d-1))indicates the number of service packets sent by the 552 PM Initiator during dth measurement, and (RPN(d)-RPN(d-1)) indicates 553 the actual number of service packets received by the PM Responder 554 during dth measurement. 556 The loss rate needs to be aggregated over the reporting interval. 557 Let's assume that N BR packets were received during the dth reporting 558 interval. Therefore, the packet loss rate for that interval can be 559 calculated as: 561 1 N 562 PLRd = --- * sum plrd 563 N d=1 565 6. Exception Handling 567 6.1. FM/BR Packet Loss 569 In some cases the FM or BR packet may be lost in transit, then no 570 statistics can be obtained from this round of measurement. So the 571 loss rate of the mth measurement can be calculated as: 573 (SPN(m)-SPN(n))-(RPN(m)-RPN(d-n)) 574 plrm = ------------------------------------- 575 SPN(m)-SPN(n) 577 where m is the SN of the BR packet currently received and n is the SN 578 of the latest BR received. 580 6.2. Packet Mis-ordering 582 In the receive side if the received packets are out of order, the FM 583 packet may arrive earlier than the last service packet sent before 584 it, or later than the first service packet sent after it. Then 585 statistical error of packet loss will be result in. Note that the 586 packet loss calculation is based on sample statistic, so the 587 occasional packet mis-ordering may make less impact on the packet 588 loss statistic. And the mis-ordering can be solved by some private 589 method which is out-of-scope of this document. 591 7. Use Case 593 This section describes a typical scene using the measurement method. 594 The wireless mobile backhaul networks based on IP, share the 595 available capacity between the connected eNodeBs. Compared to the 596 traditional SDH/ATM transport network, in IP-RAN, the data transfer 597 speed is unstable and data transfer is lacks of QoS guarantee and 598 there is no perfect testing method on packet loss, delay and jitter. 599 So it is necessary for the nodes in the RAN side to detect the 600 network quality of the connection between RNC and NodeB or eNodeB and 601 SAE. 603 Take the eNodeB and SAE for example; in order to make sure that the 604 amount of generated traffic is aligned with the available capacity, 605 it is important that the eNodeB probes the backhaul network to 606 determine the actual delay, jitter and packet loss encountered by 607 typical packets. The proposed method in this document can be used to 608 detect the IP Performance of the connections between the eNB and 609 S-GW. 611 At the eNodeB, FM OAM packets are generated periodically with the 612 source and destination IP addresses, and DSCP class. At the S-GW, 613 after receiving the FM packets, BR packets are constructed. They are 614 then forwarded back to the eNodeB. Upon receiving the BR packets at 615 the logical port exactly knows the current congestion extent in 616 transport network. The bandwidth of the logical port is reduced if 617 congestion is detected according to the measurement result; 618 otherwise, the bandwidth is increased slowly. 620 8. Security Considerations 622 To be defined. 624 9. IANA Considerations 626 The destination port number of the newly defined packets for 627 measurement needs to be assigned by the IANA. 629 10. Acknowledgments 631 The authors gratefully acknowledge reviews and contributions from 632 Peter McCann and Anthony Chan. 634 11. References 636 11.1. Normative Reference 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, March 1997. 641 11.2. Informative References 643 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 644 "Framework for IP Performance Metrics", RFC 2330, 645 May 1998. 647 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 648 Delay Metric for IPPM", RFC 2679, September 1999. 650 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 651 Packet Loss Metric for IPPM", RFC 2680, September 1999. 653 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 654 Zekauskas, "A One-way Active Measurement Protocol 655 (OWAMP)", September 2006. 657 Authors' Addresses 659 Lishun Sun 660 Beijing University of Posts and Telecommunications 661 Xitucheng road 10 662 Haidian District, Beijing 100876 663 P. R. China 665 Email: lishunsun@Gmail.com 667 Wendong Wang 668 Beijing University of Posts and Telecommunications 669 Xitucheng road 10 670 Haidian District, Beijing 100876 671 P. R. China 673 Email: wdwang@bupt.edu.cn 675 Fang Yu 676 Huawei Technologies 677 Huawei Building, Q20 No.156 Beiqing Rd.Z-park 678 Haidian District, Beijing 100095 679 P. R. China 681 Email: grace.yufang@huawei.com