IPPM L. Sun Internet-Draft BUPT Intended status: Informational F. Yu Expires: August 12, 2013 Huawei Technologies X. Gong BUPT February 8, 2013 TWAMP Flow-based Performance Measurement draft-sun-ippm-twamp-flowbased-00 Abstract This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP). Through carrying the information of business flow, it can measure the online performance without bringing effect to application significantly. 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 August 12, 2013. Copyright Notice Copyright (c) 2013 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 include Simplified BSD License text as described in Section 4.e of Sun, et al. Expires August 12, 2013 [Page 1] Internet-Draft TWAMP Flow-based performance measurement February 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 5 3. Flow-based Performance Measurement principles . . . . . . . . 6 4. TWAMP-Control Extension . . . . . . . . . . . . . . . . . . . 6 4.1. Connection Setup with New Feature . . . . . . . . . . . . 6 4.2. Test Session Creation: Request-TW-Session Packet Format . 7 5. Extended TWAMP-Test . . . . . . . . . . . . . . . . . . . . . 9 5.1. sender behavior . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Packet timing . . . . . . . . . . . . . . . . . . . . 10 5.1.2. Session-sender Packet Format . . . . . . . . . . . . . 10 5.2. reflector behavior . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Session-Reflector Packet Format . . . . . . . . . . . 12 6. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Exception Handling . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Packet Reordering . . . . . . . . . . . . . . . . . . . . 15 8. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Sun, et al. Expires August 12, 2013 [Page 2] Internet-Draft TWAMP Flow-based performance measurement February 2013 1. Introduction According to the existing extension of [RFC5357], the extension context of TWAMP includes embedding a number of meaningful fields in the padding octets of the TWAMP test packet transmitted between a Session-Sender and a Session-Reflector [RFC5357] [RFC6038], and redefining existing fields like in [I-D.morton-ippm-twamp-rate] or adding new fields like in [RFC6038] in the Request-TW-Session Packet transmitted between a Control-Client and a server. This memo describes the implementation of Flow-based Performance Measurement (FPM) under the architecture of TWAMP, or as an optional extension of TWAMP. The FPM has been described individually in [I-D.sun-ippm-flowbased-pm]. It is an end-to-end flow-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. This measurement method can support the online and real-time performance measurement of a particular or one kind of applications with negligible effect on the application. Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set to zero by senders and MUST be ignored by receivers. Also, the HMAC (Hashed Message Authentication Code) MUST be calculated as defined in Section 3.2 of [RFC4656]. 1.1. Problem statement The TWAMP protocol proposed by IPPM WG provides a simple and useful network performance measurement method. It aims at using a safe and effective way to measure the performance of the IP network. TWAMP uses TWAMP-Control protocol to initiate, start, and stop test sessions, making the measurement process with more flexibility and security. It uses TWAMP-Test protocol for the actual network test by injecting test packets into network, so that various properties of the network can be measured offline effectively. However, while TWAMP is able to achieve most network measurement situations, it does not work well in some cases on the performance testing for real time business. 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. For measuring the performance of the real service stream, TWAMP has the following defects due to the limit of measurement parameters and its framework. Sun, et al. Expires August 12, 2013 [Page 3] Internet-Draft TWAMP Flow-based performance measurement February 2013 o TWAMP is mainly used to measure the performance of the network. It cannot be well applied to the real-time performance measurement of a particular or one kind of applications. o In the case of real time measurement of network performance, if the test packets are sent too frequently, the network load will be increased and application flows will be affected. Otherwise, if the number of test packets is small, the performance of the network cannot be reflected accurately by the measurement. For example, for real time streaming media services such as IPTV and video conference, packets carry QoS parameters to ensure service quality for different application flows. Network needs to real time monitor the performance of these application flows, in order to adjust the allocation of resources in network according to the monitoring results in real time, thereby ensuring the QoS requirements of different applications. For the performance measurement of such business discussed above, TWAMP cannot meet all the requirements well as a result of the above defects. For the problems discussed above, it is required to define a new measurement framework, which is able to meet the demand for real time measurement of application flows, and does not have much impact on the data flow itself. At the same time, this new measurement method will be able to meet the following goals of the IPPM measurement: guarantee the Service Level Agreement (SLA) provided to the customers, detect/locate the network performance defects, react in response to performance degradation or the failures promptly, and optimize the network resources utilization. In the following section, we discuss the requirements of IP performance measurement in IP mobile backhaul network. In mobile operator's backhaul network, there must be a performance monitoring mechanism to check the traffic status in the network. With the status information, some strategies can be implemented on entities. For example, eNodeB can implement online congestion control and bandwidth adjustment strategy based on the performance monitoring result. Hence, IPPM mechanism is required to provide a reasonable estimate of the amount of delay, ipdv (IP Packet Delay Variation) and packet loss in the backhaul network connecting it to the GW. In order to avoid adding superfluous traffic to the backhaul and leading to the increase of the load level in the network, it is necessary that the frequency of measurement packets generation is kept at a minimum. Moreover, these packets should not lead to an excessive computational overload on the eNodeB and the GW. In other Sun, et al. Expires August 12, 2013 [Page 4] Internet-Draft TWAMP Flow-based performance measurement February 2013 words, the process of generation of these probe packets should be simple and must not overload the transport interface. The packets must be small and infrequent so as to not cause un-necessary overload on the backhaul bandwidth. Applications or traffic in mobile backhaul network are divided into multiple bearers with proper mobile QoS parameters (e.g. QCI). If the mobile network would manage bearers as QoS and applications, then the performance of backhaul is more like to be based on applications or QoS. The currently active measurement method (e.g. TWAMP) may be able to do flow-based measurement by specifying DSCP for the TWAMP- test packets. But it can not well support the online measurement and the length of test packet is changeless and not varying as the real service packets. The average performance indexes measured by the active measurement method may not be suitable in these cases. A new measurement method can be applied into backhaul network, by deploying an end-to-end performance monitor on eNodeB to assist eNodeB to execute the congestion control and flow scheduling. Played as sender entity, eNodeB sends out the test packets periodically to trigger the other end (e.g. another eNodeB or an SGW) replying acknowledgement packets, then to estimate the delay, ipdv (IP Packet Delay Variation) and packet loss of each application flow by collecting and calculating status information. 1.2. Requirements Language 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. Purpose and Scope The purpose of this memo is to define an extended feature for TWAMP, which is called Flow-based Performance Measurement (FPM). The scope of the memo is limited to specifications of the following extensions: o The addition and redefinition some fields in the Request-TW- Session command [RFC5357]. o The definition of new Session-Sender and Session-Reflector behaviors. o The definition of a structure for embedding a sequence of flow- related fields at the beginning of the Packet Padding [RFC5357]. Sun, et al. Expires August 12, 2013 [Page 5] Internet-Draft TWAMP Flow-based performance measurement February 2013 This feature can support the online and real-time performance measurement of a particular or one kind of applications. Because the test packets inserted are small and infrequent, the effect on the application flows due to this measurement is negligible. 3. Flow-based Performance Measurement principles In FPM, the business 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. Each test session established in TWAMP can measure a flow defined in the way above. After the session is established, test packets can be exchanged between the two endpoints of the flow, and the information relative to the business flow based on which the measurement and statistics can be done is carried in the test packets. 4. TWAMP-Control Extension TWAMP connection establishment follows the procedure defined in Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357]. The Modes field is employed to identify and select specific communication capabilities in the TWAMP Control protocol [RFC5357]. In a similar way with another extension of TWAMP, such as [RFC2680], the FPM feature requires one new bit position (and value). Such bit position (and value) is not defined in this memo. 4.1. Connection Setup with New Feature The Server sets the new bit position in the Modes field of the Server Greeting message to indicate its capabilities and willingness to operate in the FPM mode if desired. If the Control-Client intends to operate all test sessions invoked with this control connection using the new mode, it MUST set the Mode field bit corresponding the function in the Setup Response message. With this extension, the Control- Client MAY set the Mode field bit in the Setup Response message. Sun, et al. Expires August 12, 2013 [Page 6] Internet-Draft TWAMP Flow-based performance measurement February 2013 4.2. Test Session Creation: Request-TW-Session Packet Format Comparing with the procedure of test session creation defined in Section 3.5 of TWAMP [RFC5357], the message format of the Request-TW- Session command has the exceptions with the message format as described in Section 3.5 of TWAMP as follows: Sun, et al. Expires August 12, 2013 [Page 7] Internet-Draft TWAMP Flow-based performance measurement February 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 |FT |MBZ| IPVN | Conf-Sender | Conf-Receiver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Schedule Slots | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Port | Receiver Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender Address (cont.) or MBZ (12 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Receiver Address (cont.) or MBZ (12 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SID (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Time | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timeout, (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type-P Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sun, et al. Expires August 12, 2013 [Page 8] Internet-Draft TWAMP Flow-based performance measurement February 2013 o FT: this field occupies two bits. It indicates how a flow is defined. 0x0 in this field is for (SIP, DIP, PT, sPort, dPort), while 0x1 is for (SIP, DIP, PT, DSCP) and 0x2 is for (SIP, DIP, PT). The 0X3 is not defined. In this mode, the test packets MUST have the same sender and receiver address as the business packets. So the SIP/DIP are the same as the value in the Sender address/ Receiver address field if the Sender Address and Receiver Address fields are not set to 0. If they are set to 0, SIP/DIP are the same as the IP addresses used for the Control-Client to Server TWAMP-Control message exchange. By this same logic, if the value of FT is 0x1, the value of the DSCP is the same as the value in the Type-P Descriptor. o Protocol Type: these octets composed the field of number of packets in OWAMP [RFC4656], whereasGBP[not]in TWAMP [RFC5357]GBP[not]it is unused and set to 0. In FPM mode, this filed is reinterpreted as the protocol type value of the service flow needed to be measured. It may be UDP, TCP, SCTP or other types. The value of this field SHOULD follow the IANA types defined in [RFC1700]. o SID: in the FPM mode, there MAY be lots of test sessions related to different business flow between the same pair of hosts and ports. So, it is necessary to set this field to identify the session. However, in this mode, only last two octets are employed, the first 14 octets MUST be zero. o Padding length: in this mode, the test packets needn!_t include padding field as described in section 5.1.2. so the padding length MUST be set to 0. o sPort and dPort: these two fields both occupy two octets. They, which indicate source and destination port number of the business packets respectively, are valid only when the flow is defined by (SIP, DIP, PT, sPort, dPort). 5. Extended TWAMP-Test 5.1. sender behavior This section describes the extensions to the behavior of the TWAMP Session-Sender. Sun, et al. Expires August 12, 2013 [Page 9] Internet-Draft TWAMP Flow-based performance measurement February 2013 5.1.1. Packet timing The send schedule is the same as in OWAMP. 5.1.2. Session-sender Packet Format The Session-Sender packet format follows the same procedure and guidelines as defined in TWAMP [RFC5357]GBP[not]but with some embedding fields . This feature allows the Session-Sender to set a few octets instead of the TWAMP-Test Packet Padding under the unauthenticated modes or in the MBZ fields under the authenticated and encrypted modes with flow information, which includes the number of the packets and bytes sent by the sender. Therefore, the placement of bits from the FPM octets depends on the mode(s) being selected. In this modeGBP[not]there SHOULD be no Packet Padding fields in the test packets in order to save the network resource and avoid creating adverse effects on the business flow. So symmetrical size of TWAMP-Test packets in the forward and reverse directions of transmission is not need in FPM mode. The Session-Sender SHOULD use the following TWAMP-Test packet format when the FPM feature is selected in conjunction with the Unauthenticated mode: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxPkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Session-Sender SHOULD use the following TWAMP-Test packet format when the FPM feature is selected in conjunction with the authenticated and encrypted mode: Sun, et al. Expires August 12, 2013 [Page 10] Internet-Draft TWAMP Flow-based performance measurement February 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxPkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | MBZ (6 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of SID is equal to the last two octets of SID in Request- TW-Session command. The value of FwdTxPkt/FwdTxByte field is the accumulation of the number of the packets/bytes sent by the session-sender. In order to determine the value of the fields of FwdTxPkt and FwdTxByte, the session-sender maintains two counters, SPN and SBN, for each FPM flow that is incremented every time a business packet is sent. When the test packets are to be sent, the FwdTxPkt and FwdTxByte are set to the then value of the counters respectively. 5.2. reflector behavior The TWAMP Session-Reflector follows the procedures and guidelines in Section 4.2 of [RFC5357], with some changes and additional functions. When the FPM mode is selected, the behavior of the Session-Reflector SHOULD be as follows: The session-reflector is required to transmit a packet to the session-sender in response to each test packet it receives. When the session-reflector receives a test packet, it copies the Sun, et al. Expires August 12, 2013 [Page 11] Internet-Draft TWAMP Flow-based performance measurement February 2013 value of FwdTxPkt, FwdTxByte and SID in test packet from the session- sender into the corresponding fields of the reflected test packet, and sets the fields of Sender Timestamp, Receive Timestamp and other fields as it does in TWAMP [RFC5357]. And then the reflected test packet is reflected to the session-sender. Note that there SHOULD be no Packet Padding field in the reflected test packets in order to save the network resource and avoid creating adverse effects on the business flow. 5.2.1. Session-Reflector Packet Format When the FPM mode is selected, the Session-Reflector SHOULD use the following TWAMP-Test Packet Format in Unauthenticated mode: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdRxPkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdRxByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxPkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the FPM mode is selected, the Session-Reflector SHOULD use the Sun, et al. Expires August 12, 2013 [Page 12] Internet-Draft TWAMP Flow-based performance measurement February 2013 following TWAMP-Test Packet Format in authenticated and encrypted mode: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdRxPkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdRxByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (6 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxPkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FwdTxByte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (12 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (6 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | | +-+-+-+-+-+-+-+-+ + | | | | | MBZ (15 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC (16 octets) | Sun, et al. Expires August 12, 2013 [Page 13] Internet-Draft TWAMP Flow-based performance measurement February 2013 | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The FwdTxPkt and FwdTxByte are copied from the corresponding test packet from Session-Sender. FwdRxPkt is the accumulation of the number of the packets received by the Session-Reflector. FwdRxByte is the accumulation of the number of bytes received by the Session-Reflector. In order to determine the value of the fields of FwdRxPkt and FwdRxByte, the Session-Reflector maintains two counters, RPN and RBN, for each FPM flow that is incremented every time a business packet is received. When the Session-Reflector test packets are to be sent, the FwdRxPkt and FwdRxByte are set to the then value of the counters respectively. Note that the Control client 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 test packets with the flow id (which is indicated by the SID filed) of the logical path, collect the corresponding reflected test packets, and maintain the collected statistical values. 6. Metrics In FPM mode, most of the Metrics defined by IPPM WG can be measured, such as the one-way delay metric for IPPM defined in [RFC2679], the round-trip delay metric for IPPM defined in [RFC2681], the one-way loss metric [RFC2680], the IP packet delay variation metric for IPPM defined in [RFC3393], etc.. This section takes the one-way loss metric [RFC2680] as an example, it can be calculated as follows. In FPM mode, session-sender uses a counter to count the actual number of bussiness packets sent by it. Session-reflector records whether business packet has arrived or not, if the packet reaches the session-reflector, business packet loss value is 0; if the packet is lost during transmission, the business packet loss value is 1. Session-reflector cumulates the loss value, and calculates the number of packets actually received. The above parameters, carried by Sun, et al. Expires August 12, 2013 [Page 14] Internet-Draft TWAMP Flow-based performance measurement February 2013 measurement packets, are exchanged between both sides, used to calculate packet loss and loss rate in session-sender ultimately. In some cases the Session-sender Packet Loss or Session-reflector test packet may be lost in transit, and then no statistics can be obtained from this round of measurement. So the loss rate of the packet loss rate (plr) of the mth measurement can be calculated as: (SPN(d)-SPN(d-1))-(RPN(d)-RPN(d-1)) plrd = ------------------------------------- SPN(d)-SPN(d-1) Where m is the sequence number of the test packet currently received by Session-reflector, n is the sequence number of the latest test packet received by Session-reflector, and SPN(x) and RPN(x) are the value of FwdTxPkt and FwRxPkt in the xth test packet. As described above, measurement packet only needs to carry statistics information of both sides in the FPM. The measurement packet size and the transmission frequency are relatively small, so FPM will not cause too much impact on the original business. 7. Exception Handling 7.1. Packet Reordering In the Session-Reflector side if the received packets are out of order, the Session-sender test 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. There are several reasons for packet reordering. When a network node receives a fragmented IP packet, it has to reassemble the datagram and the extra time spent on the IP fragment reassembly may cause packet reordering; some load sharing schemes for network (e.g. ECMP, ML-PPP) may create multipath for packets, which can also cause packet reordering; Multi-core CPU processing and multi-threading of packets in the sender and receiver may also lead to packet reordering. In the simplest case that data transmits along a single path, DSCP can be used to classify the flow in order to avoid the packet reordering. Note that the packet loss calculation is based on sample statistic, and by increasing the monitoring period, the error caused by the Sun, et al. Expires August 12, 2013 [Page 15] Internet-Draft TWAMP Flow-based performance measurement February 2013 occasional packet reordering can be smoothed. 8. Use case This section describes a typical scene using the FMP mode. 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 ipdv (IP Packet Delay Variation). 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, 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. As shown in the figure 1, the Control-Client/Session-Sender is deployed in eNodeB, and the Server/Session-Reflector is deployed in S-GW. ________________ _________________ | | control protocol | | | | <----------------------> | | |Control-Client/ | Session-Sender packet | Server/ | |Session-Sender | -----------------------> |Session-Reflector| | | Session-Reflector packet | | |----------------| <----------------------- |-----------------| : eNodeB : : S-GW : :................: :.................: Figure 1: Example of FPM mode in backhaul network At the eNodeB, test packets followed the format as Section 5.1.2 are generated periodically with the source and destination IP addresses, and DSCP class. At the S-GW, after receiving the test packets from the eNodeB, test packets with the format described in Section 5.2.1are constructed. They are then forwarded back to the eNodeB. We sent a similar packet of OAM, packet size and the transmission frequency is relatively small, so TWAMP in FPM mode will not cause Sun, et al. Expires August 12, 2013 [Page 16] Internet-Draft TWAMP Flow-based performance measurement February 2013 too much impact on the original business between eNodeB and S-GW. Since test packet is constructed according to the business packet, the network path of test packet and business packet is the same (Tunneling is used for the data transmission between eNodeB and S-GW, the parameter statistics of FPM mode should be carried before the tunnel. Test packet and business packet are encapsulated into a same tunnel and they are passed in the same path). The data obtained through FPM can represent the performance of the business flows between the eNodeB and the S-GW accurately. Upon receiving the test packets at the logical port the eNodeB 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. 9. IANA Considerations This memo adds one mode to the IANA registry for the TWAMP Modes Field, and describes behavior when the new mode is used. This field is a recognized extension mechanism for TWAMP. 10. Acknowledgments The authors gratefully acknowledge reviews and contributions from Peter McCann and Qinglei Qi. 11. References 11.1. Normative Reference [I-D.morton-ippm-twamp-rate] Morton, A. and L. Ciavattone, "TWAMP Burst Rate Measurement Features", draft-morton-ippm-twamp-rate-02 (work in progress), September 2012. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. Sun, et al. Expires August 12, 2013 [Page 17] Internet-Draft TWAMP Flow-based performance measurement February 2013 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, October 2010. 11.2. Informative Reference [I-D.sun-ippm-flowbased-pm] Sun, L., Yu, F., and W. Wang, "Flow-based Performance Measurement", draft-sun-ippm-flowbased-pm-00 (work in progress), October 2012. Authors' Addresses Lishun Sun Beijing University of Posts and Telecommunications Xitucheng road 10 Haidian District, Beijing 100876 P. R. China Email: lishunsun@Gmail.com Sun, et al. Expires August 12, 2013 [Page 18] Internet-Draft TWAMP Flow-based performance measurement February 2013 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 Xiangyang Gong Beijing University of Posts and Telecommunications Xitucheng road 10 Haidian District, Beijing 100876 P. R. China Email: xygong@bupt.edu.cn Sun, et al. Expires August 12, 2013 [Page 19]