TSVWG Lishun. Sun Internet-Draft Wendong. Wang Intended status: Informational BUPT Expires: December 31, 2012 Fang. Yu Huawei Technologies June 29, 2012 Flow-based Performance Measurement draft-sun-tsvwg-flowbased-pm-00 Abstract The performance measurements of service flow are becoming significant important for administrators monitoring the fitness of the network. This memo defines an end-to-end application-based performance measurement method, which is achieved by generating synthetic measurement packets, injecting them to the network and analyzing the statistics carried in the measurement packets. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 31, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Sun, et al. Expires December 31, 2012 [Page 1] Internet-Draft Flow-based Performance Measurement June 2012 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2.1. Conventions Used in This Document . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4 3.3. Logical Model . . . . . . . . . . . . . . . . . . . . . . 5 4. Measurement Process . . . . . . . . . . . . . . . . . . . . . 6 4.1. Connection Activation . . . . . . . . . . . . . . . . . . 6 4.2. Measurement Process . . . . . . . . . . . . . . . . . . . 8 4.3. Connection Deactivation . . . . . . . . . . . . . . . . . 10 5. Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Delay Calculation . . . . . . . . . . . . . . . . . . . . 11 5.2. Jitter Calculation . . . . . . . . . . . . . . . . . . . . 12 5.3. Loss Calculation . . . . . . . . . . . . . . . . . . . . . 12 6. Exception Handling . . . . . . . . . . . . . . . . . . . . . . 13 6.1. FM/BR Packet Loss . . . . . . . . . . . . . . . . . . . . 13 6.2. Packet Mis-ordering . . . . . . . . . . . . . . . . . . . 13 7. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Sun, et al. Expires December 31, 2012 [Page 2] Internet-Draft Flow-based Performance Measurement June 2012 1. Introduction The IETF IP Performance Metrics (IPPM) working group has defined a series of standard metrics that can be applied to the quality, performance and reliability of Internet data delivery services. In some cases, it needs to monitor the various time-varying performance indexes of the IP network, the performance measurement should be based on real service stream and reflect the real performance of the network. The average performance indexes measured by the active measurement method may not be suitable in these cases. This memo proposes an IP performance measurement method which can support on-the-spot measurement, that is, measurement is performed online when service is running. This method is an end-to-end flow- based method which can obtain measurement data simply and accurately. It injects the OAM packets to the network which are used to carry some parameters related to service flow and some statistic information. The OAM packets are processed using the same method as its corresponding service flow, so the measurements can reflect the network status suffered by the service flow more accurately. This IP performance measurement method can monitor the real time change of service and reflect the running situation of actual IP service. It can play an important role in the fault diagnosis and statistics of the service in IP transmission network. 2. Conventions and Terminology 2.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Terminology PM:performance monitoring FM:Forward Monitoring BR:Backward Reporting 3. Overview Sun, et al. Expires December 31, 2012 [Page 3] Internet-Draft Flow-based Performance Measurement June 2012 3.1. Motivation It is required to provide a reasonable estimation measurement of delay, jitter and packet loss in IP network (such as backhaul network). The above parameters are functions of time, and are stochastic in nature. Therefore, the mechanism is required to provide statistical condition estimations of the IP link status. Moreover, since measurement injects some OAM packets to the network, it is necessary that the frequency of packet generation is kept at a minimum. Moreover, these packets should not lead to an excessive computational overload on the measure device. In other words, the process of generation of these measurement packets should be simple and must not overload the transport interface. The packets must be small and infrequent so as not to cause unnecessary overload on the network bandwidth or influence the service running on the network. 3.2. Protocol overview Firstly we make some statement for this method. We define a measurement method that can be used in some scene. The method proposed here involves three steps#: connection activation#, measurement process and connection deactivation. Two types of logical entities are defined, the PM Initiator and the PM Responder. Firstly the PM Initiator sends a request to the PM Responder to set up the PM connection activation. The PM Responder responds with an ACK packet including some parameters based on the request. When the PM Initiator receives the ACK, it will prepare for starting the measurement process. During the measurement process, the PM Initiator periodically generates Forward Monitor (FM) packets with the source and destination IP addresses, and other classification information (for example DSCP class) of the service packets , which are sent to the PM Responder. The generation and transmission of FM packets can be periodical with a specific time interval, or a certain number of traffic packets should be sent between two contiguous FM packets. The PM Responder receives the FM packets and sends Backward Reporting(BR)packets which is constructed according to the FM packets. The path performance such as the delay, jitter and loss rate etc. are calculates by the PM Initiator according to the information in the BR packets. Sun, et al. Expires December 31, 2012 [Page 4] Internet-Draft Flow-based Performance Measurement June 2012 The FM packets have the same source and destination IP addresses, even the same DSCP class in some cases with the data packets. So they are carried through the transport network just most like the data packets, and delay, jitter and packet loss encountered by them resembles the performance as seen by the packets of the actual traffic flows. The FM and BR packets used in this method are small enough to produce influence to actual service flow as little as possible. 3.3. Logical Model The role and definition of the logical entities and measurement packets in this method are defined as follows. This method is an end-to-end measurement, so two logical entities are defined. o PM Initiator: PM Initiator serves as the sending endpoint, and charges for generating and sending the request to initiate a PM connection. It could also send FM packets to collect measurement data and generate statistical report. o PM Responder: PM Responder serves as the receiving endpoint, and charges for responding the request of initiating a link. It could also send back a BR packet to the sending endpoint once it receives the FM package from the PM Initiator. One possible scenario of relationships between these roles is shown below. +---------------+ +----------------+ | |-------------------->| | | PM Initiator |<--------------------| PM Responder | +---------------+ +----------------+ Figure 1: One possible relationship between PM Initiator and PM Responder There are six types of packets in total, which include four types of control packets and two types of measurement packets. Note that a new port number is introduced to be assigned by the IANA. The assigned port number is used as the destination port number of the control packets and measurement packets#, and the source port number can be random. Control packet: Sun, et al. Expires December 31, 2012 [Page 5] Internet-Draft Flow-based Performance Measurement June 2012 o ACT: It is sent from the PM Initiator to a specific UDP port on PM Responder, carries parameters used in negotiation process when initiating a PM connection. o ACT-ACK: It is a response for ACT sent by the PM Responder to the PM Initiator. o DEA: It is sent by the PM Initiator to the PM Responder for disconnecting the PM connection. o DEA-ACK: It is a response for DEA sent by the PM Responder to the PM Initiator. Measurement packet: o FM (Forward Monitoring): It is sent by the PM Initiator. The format of FM packet payload as defined by this document will be shown blow. FM packet header is constructed in accordance with the data packet except the destination port. o BR (Backward Reporting): It is sent by the PM Responder. The format of BR packet payload as defined by this document will be shown blow. It is a response for FM. 4. Measurement Process 4.1. Connection Activation In the PM connection activation process, both the PM Initiator and the PM Responder are assigned a Flow ID for a defined flow (the Flow ID is unique in a connection between the PM Initiator and the PM Responder). It should specify how to define the Flow corresponding to the measurement instance. Flow can be defined by different combinations of source IP address (SIP), destination IP address (DIP), protocol type (PT), DSCP, source port number (sPort) and destination port number (dPort). Three types of combinations are suggested: (SIP, DIP, PT), or (SIP, DIP, PT, DSCP) or (SIP, DIP, PT, sPort, dPort). The more the combinational dimensions are, the more fine-grained can be the monitoring of data flow. Before starting the measurement, a connection should be established. When the PM Initiator wants to start the measurement process, it enables the measurement capabilities to the PM Responder by sending ACT packet to the specific UDP port on the PM Responder. When the PM Responder receives the ACT, it enables its measurement function and responses to the Sender with ACT-ACK packet. The connection activation process is finished after the PM Initiator receiving the Sun, et al. Expires December 31, 2012 [Page 6] Internet-Draft Flow-based Performance Measurement June 2012 ACT-ACK packet from the PM Responder, then the PM Initiator can send FM packet after one cycle. The definition of flow, FlowID, and the sending period of FM packets must be consulted by two ends during the connection activation process. The format of ACT packet is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | Periods | FlowType | PT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DIP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sPort | dPort | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sFlowId | DSCP | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver and Type existed in all packets in this memo indicate the version and type of packet. Type in this packets MUST be 0X1 indicates that this is an ACT packet. Periods defined by PM Initiator indicates the sending period of FM packets. FlowType indicates how a flow is defined.0x0 in this filed is for (SIP, DIP, PT, sPort, dPort), while 0x1 is for (SIP, DIP, PT, DSCP) and 0x2 is for (SIP, DIP, PT). The other values are not defined. PT is the protocol type value of the service flow needed to be measured. It may be UDP, TCP, SCTP or other types. SIP is the source IP address of the service flow, and DIP is the destination IP address of the service flow. SPort and DPort which are valid only when the flow is defined by (SIP, DIP, PT, sPort, dPort) indicate source/destination port number of the ACT packets. If the FlowType is not defined by (SIP, DIP, PT, sPort, dPort), this filed is 0xFF. sFlowId is the flow id defined by the PM Initiator. DSCP is valid only when the flow is defined by (SIP, DIP, PT, DSCP). It indicates the value of the DSCP filed in IP header of service flow. Sun, et al. Expires December 31, 2012 [Page 7] Internet-Draft Flow-based Performance Measurement June 2012 Reserved is reserved for extensions in future and MUST be set to 0x0 currently. The format of ACT-ACK packet is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | Periods | dFlowId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sFlowId | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type of 0X2 indicates ACT-ACK. dFlowId is copied from the sFlowId field of the ACT packets. sFlowId is the flow id defined by the PM Responder. 4.2. Measurement Process When the connection is established successfully, the PM Initiator sends FM packets according to the given time-interval, and the PM Responder responses by sending BR packets after receiving FM packets from the PM Initiator. The destination port number in the FM packet header must be set as the specific number. The format of FM packet is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | SN | dFlowId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxPkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type of 0X3 indicates FM. SN is the sequence number of the flow, which distinguishes the Sun, et al. Expires December 31, 2012 [Page 8] Internet-Draft Flow-based Performance Measurement June 2012 different FM packets and indicates the correspondence between FM packets and BR packets. Each PM flow should maintain a set of sequence numbers (SN). dFlowId is the flow id of the PM Responder, which is copied from sFlowId in ACT-ACK. FwdTxPkt is the accumulation of the number of the packets sent by the PM Initiator. FwdTxByte is the accumulation of the number of bytes sent by the PM Initiator.In order to determine the value of the fields of FwdTxPkt and FwdTxByte, the PM Initiator maintains two counters, SPN and SBN, for each PM flow that is incremented every time a traffic packet is sent.When the FM packets are to be sent, the FwdTxPkt and FwdTxByte are set to the then value of the counters respectively. T1 is the timestamp when the PM Initiator sends FM packets. There is no requirement for synchronization between the PM Initiator and the PM Responder. The format of BR packet is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | SN | dFlowId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxPkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdRxPkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdRxByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type of 0X4 indicates BR. SN is copied from the SN field of the corresponding FM packet. Sun, et al. Expires December 31, 2012 [Page 9] Internet-Draft Flow-based Performance Measurement June 2012 dFlowId is the flow id of the PM Initiator, which is copied from sFlowId in ACT. The FwdTxPkt and FwdTxByte are copied from the corresponding FM packet. FwdRxPkt is the accumulation of the number of the packets received by the PM Responder. FwdRxByte is the accumulation of the number of bytes received by the PM Responder. In order to determine the value of the fields of FwdRxPkt and FwdRxByte, the PM Responder maintains two counters, RPN and RBN, for each PM flow that is incremented every time a traffic packet is received. When the BR packets are to be sent, the FwdRxPkt and FwdRxByte are set to the then value of the counters respectively. T1 is copied from the T1 field of the FM packets, T2 is the timestamp when the PM Responder receives the FM packets, and T3 is the timestamp when the PM Responder sends the BR packets. When the PM Responder receives a FM packet, it copies the value of FwdTxPkt, FwdTxByte and T1 in FM packet into the corresponding fields of the BR packet, and sets the fields of T3, FwdRxPkt and FwdRxByte and sends the BR packet. Note that the PM Initiator could start multiple measurement engines; each engine is corresponding to an active logical path (with a different Flow). These measurement engines operate in parallel, and send FM packets with the flow id of the logical path, collect the corresponding BR packets, and maintain the collected statistical values. 4.3. Connection Deactivation When the PM Initiator wants to stop the measurement, it sends Connection Deactivation request packet called DEA to the PM Responder. The PM Responder sends DEA-ACK packets back to the PM Initiator after it receives the DEA packets. The format of DEA packet is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | Reserved | dFlowId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type of 0X5 indicates DEA. dFlowId is the flow id defined by the PM Responder, which is copied Sun, et al. Expires December 31, 2012 [Page 10] Internet-Draft Flow-based Performance Measurement June 2012 from sFlowId in ACT-ACK. The format of DEA-ACK packet is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | Reserved | dFlowId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type of 0X6 indicates DEA-ACK. dFlowId is the flow id defined by the PM Initiator, which is copied from sFlowId in ACT. . 5. Statistics 5.1. Delay Calculation In order to determine the delay sample for a given FM and BR packets, we assume that the paths are symmetric; that is the delay would be same for FM and BR packets. Therefore, the traffic delay is calculated as: (T4-T1)-(T3-T2) Td = --------------- 2 Where td is the one-way delay for the dth BR received, t4 is the time that the PM Initiator received the dth BR packet, t3 is the time that the PM Initiator sent the dth FM packet. t2 is the time that the PM Responder received dth FM packet, and t1 is the time that PM Responder sent the dth BR packet(dth is a SN of a flow). Let's assume that during the current reporting interval D, N BR packets were received at the PM Initiator, the delay reported to the network management entity is determined as 1 M+N-1 TD = --- * sum td N d=M Where TD is the delay metric reported corresponding to the interval D to the network management entity. Sun, et al. Expires December 31, 2012 [Page 11] Internet-Draft Flow-based Performance Measurement June 2012 5.2. Jitter Calculation Jitter is defined as the Packet Delay Variation, and is not calculated for each arriving BR packet. Instead, td values are considered over several seconds, and the associated jitter value is calculated. Let's consider that N consecutive delay values were used to determine the dth jitter value, jp as: ________________________ | 1 M+N-1 2 jp = |--- * sum ( TD - Td ) /\| N d=M jp is the variance of delay Note that hence calculated jitter value needs to be aggregated over the reporting interval. Let's assume that during the current reporting interval D, N such jitter calculations were made at the PM Initiator, therefore the jitter reported to the network management entity is determined as: 1 N jD = --- * sum jp N p=1 5.3. Loss Calculation When the dth BR packet is received at the PM Initiator, the loss rate plr based on the dth BR packet and (d-1)th BR packet is calculated as: (SPN(d)-SPN(d-1))-(RPN(d)-RPN(d-1)) plrd = ------------------------------------- SPN(d)-SPN(d-1) (SPN(d)-SPN(d-1))indicates the number of service packets sent by the PM Initiator during dth measurement, and (RPN(d)-RPN(d-1)) indicates the actual number of service packets received by the PM Responder during dth measurement. The loss rate needs to be aggregated over the reporting interval. Let's assume that N BR packets were received during the dth reporting interval. Therefore, the packet loss rate for that interval can be calculated as: Sun, et al. Expires December 31, 2012 [Page 12] Internet-Draft Flow-based Performance Measurement June 2012 1 N PLRd = --- * sum plrd N d=1 6. Exception Handling 6.1. FM/BR Packet Loss In some cases the FM or BR packet may be lost in transit, then no statistics can be obtained from this round of measurement. So the loss rate of the mth measurement can be calculated as: (SPN(m)-SPN(n))-(RPN(m)-RPN(d-n)) plrm = ------------------------------------- SPN(m)-SPN(n) where m is the SN of the BR packet currently received and n is the SN of the latest BR received. 6.2. Packet Mis-ordering In the receive side if the received packets are out of order, the FM packet may arrive earlier than the last service packet sent before it, or later than the first service packet sent after it. Then statistical error of packet loss will be result in. Note that the packet loss calculation is based on sample statistic, so the occasional packet mis-ordering may make less impact on the packet loss statistic. And the mis-ordering can be solved by some private method which is out-of-scope of this document. 7. Use Case This section describes a typical scene using the measurement method. The wireless mobile backhaul networks based on IP, share the available capacity between the connected eNodeBs. Compared to the traditional SDH/ATM transport network, in IP-RAN, the data transfer speed is unstable and data transfer is lacks of QoS guarantee and there is no perfect testing method on packet loss, delay and jitter. So it is necessary for the nodes in the RAN side to detect the network quality of the connection between RNC and NodeB or eNodeB and SAE. Take the eNodeB and SAE for example; in order to make sure that the amount of generated traffic is aligned with the available capacity, Sun, et al. Expires December 31, 2012 [Page 13] Internet-Draft Flow-based Performance Measurement June 2012 it is important that the eNodeB probes the backhaul network to determine the actual delay, jitter and packet loss encountered by typical packets. The proposed method in this document can be used to detect the IP Performance of the connections between the eNB and S-GW. At the eNodeB, FM OAM packets are generated periodically with the source and destination IP addresses, and DSCP class. At the S-GW, after receiving the FM packets, BR packets are constructed. They are then forwarded back to the eNodeB. Upon receiving the BR packets at the logical port exactly knows the current congestion extent in transport network. The bandwidth of the logical port is reduced if congestion is detected according to the measurement result; otherwise, the bandwidth is increased slowly. 8. Security Considerations To be defined. 9. IANA Considerations The destination port number of the newly defined packets for measurement needs to be assigned by the IANA. 10. Acknowledgments The authors gratefully acknowledge reviews and contributions from Peter McCann and Anthony Chan. 11. References 11.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. Sun, et al. Expires December 31, 2012 [Page 14] Internet-Draft Flow-based Performance Measurement June 2012 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", September 2006. Authors' Addresses Lishun Sun Beijing University of Posts and Telecommunications Xitucheng road 10 Haidian District, Beijing 100876 P. R. China Email: lishunsun@Gmail.com Wendong Wang Beijing University of Posts and Telecommunications Xitucheng road 10 Haidian District, Beijing 100876 P. R. China Email: wdwang@bupt.edu.cn Fang Yu Huawei Technologies Huawei Building, Q20 No.156 Beiqing Rd.Z-park Haidian District, Beijing 100095 P. R. China Email: grace.yufang@huawei.com Sun, et al. Expires December 31, 2012 [Page 15]