Network Working Group Y. Kikuchi Internet-Draft Kochi University of Technology Expires: August 30, 2007 S. Matsushima Softbank Telecom Corp. K. Nagami Intec Netcore Inc. S. Uda Japan Advanced Institute of Science and Technology, Hokuriku N. Ogashiwa Network Oriented Software Inc. February 26, 2007 Quality Measurement Requirements for Tunneling Protocols draft-kikuchi-tunnel-measure-req-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Kikuchi, et al. Expires August 30, 2007 [Page 1] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 Abstract This draft describes requirements to measure end-to-end qualities of tunnels passively and to monitor them via Simple Network Management Protocol (SNMP) [1]. This feature is necessary for Service Providers (SPs), especially, who provide transports to users using tunnels. In addition, the draft shows an example to measure Generic Routing Encapsulation (GRE) [2] [3] tunnels. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Service Model . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Active vs. Passive . . . . . . . . . . . . . . . . . . . . 6 4.2. Quality Evaluation . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Indication of Sequence Number . . . . . . . . . . . . 6 4.2.2. Field Length Condideration . . . . . . . . . . . . . . 7 4.2.3. Quality Measurement . . . . . . . . . . . . . . . . . 7 4.3. Getting Quality Information . . . . . . . . . . . . . . . 8 4.4. Overhead Consideration . . . . . . . . . . . . . . . . . . 8 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Counters and Functions . . . . . . . . . . . . . . . . . . 9 5.2. Measurement Algorithm . . . . . . . . . . . . . . . . . . 10 5.2.1. Algorithm Behavior . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 7. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Kikuchi, et al. Expires August 30, 2007 [Page 2] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 1. Introduction This draft describes requirements to measure end-to-end qualities of tunnels passively and to monitor them via SNMP. In this document, tunnel means various technologies in order to provide networks or datalinks virtually. Examples of tunneling are GRE, IP Encapsulation within IP (IPIP) [4], Pseudo Wire Emulation Edge-to-Edge (PWE3) [5], and so on. Measuring end-to-end quality of tunnels is necessary for Transport Service Providers (TSPs) who provide transport to users using tunnels. However, the standards do not define measurement and monitoring when TSPs want to know quality of their traffic through tunnels. Therefore, we must define standards for these. 1.1. Requirements notation 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 [6]. Kikuchi, et al. Expires August 30, 2007 [Page 3] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 2. Service Model Figure 1 shows that TSP X provides a transport between user A and user B using a tunnel. The users make an application over the transport. The TSP may apply two or more tunnels to provide one transport. USER A USER B | | + ................... Application .................. + | | LAN A ---* ... Transport by TSP X (e.g. GRE) ... *--- LAN B | | --- ISP 1 --- ISP 2 --- ... --- ISP n --- Figure 1: A Service Model of TSP TSPs provide a reachability of IP datagrams or layer 2 frames to users. The users are not able to know about the details of the path, that is the sequence of transit ISPs, under the transport because the tunnel eliminates the path so that the users must recognize that both ends of the transport as a neighbor. The reachability maintenance and the quality management are served as TSPs' communication services. TSPs provide simplified and virtual transports by hiding the underlying layers to the users. The users are able to reduce the cost of operation and management because they need not maintain the underlying layers. In addition, TSPs may be able to provide better transports when the users would have some tunnels via different paths. Furthermore, TSPs may be able to provide protocols needed by the users even if there are no such protocols served by the ISPs. Kikuchi, et al. Expires August 30, 2007 [Page 4] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 3. Motivations TSPs need to know the quality of their tunnels in order to know whether the tunnels are in the normal state or not. It could be an important material to trace down the cause of the trouble when the applications is not working properly. Without the information, it is difficult for TSP to determine whether the problem come from user, TSP itself, or ISP. TSPs need to know the tunnels' quality when they have multiple tunnels to serve transports. The TSPs may be able to serve appropriate transports to users by selecting better quality tunnels. using better tunnels based on the quality. In addition, the TSPs may be able to distribute the load of the transports to the tunnels over different paths. Kikuchi, et al. Expires August 30, 2007 [Page 5] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 4. Requirements This section describes each requirement to measure end-to-end quality of tunnel for TSPs. 4.1. Active vs. Passive There are two ways to measure a quality of tunnel, one is active and the other is passive. Active measurement uses additional probing packets to determine the quality of the channel. Passive measurement uses the tunnel packets to measure. From the TSPs point of view, passive measurement SHOULD be supported, because TSPs want to measure the tunnel quality for management of contracts with their customers. Service Level Agreement (SLA) in the contracts should describe maximum out-of-sequence rate such as loss, duplicate and reordering. SLA should refer the users' packets themselves, therefore, the measurement should be determined passively rather than actively. The protocols that support passive measurement are Real Time Protocol (RTP) [7], GRE and PWE3, which have sequence numbers in their headers. On the other hand, it is not necessary to let the protocol have quality measurement function in active measurement. In this case, TSPs MAY construct the active measurement method independently from the target protocol. The typical example is PING that uses Internet Control Message Protocol (ICMP) [8]. 4.2. Quality Evaluation In the standards of GRE and PWE3 that have sequence number field in header, sequence numbers are defined to be used on receivers' processing. The receivers may discard and/or buffer packets according to loss, duplicate and reordering based on sequence numbering. However, there is no definition to determine the quality of tunnels and for monitoring by TSPs and users. Therefore, it is necessary to define how we use sequence numbers in the standards. The definition SHOULD contain two items, one is what quality the protocols measure, and the other is how the protocols evaluate the quality. 4.2.1. Indication of Sequence Number There are two ways to indicate whether the sequence numbers are enabled or not. Tunneling protocol SHOULD support the indication either sequencing is enabled or not. Kikuchi, et al. Expires August 30, 2007 [Page 6] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 One is to prepare an indication field in the header independent from the sequence number field. GRE is an example of this. The other is to indicate a special sequence number, typically 0, meaning disabled. In this case, we need an additional process on wrapping sequence number overflow because the number will skip 0 that does not seem continuous even the tunnel packets are still in- sequence. 4.2.2. Field Length Condideration The length of sequence number field should be long enough to the transmission speed. Otherwise, the period of a lap of the sequence number become short so that the reliability of the measurement will go down. For example, the algorithm may determine as reordering even if there is a burst packet loss in case of the path change. It is necessary to determine whether a burst packet loss is happened or an arrival of a very past packet when the difference of the sequence numbers between two continuous packets is very large. The typical technique is to use a half of the representable maximum value. This is simple and adequate if the field is long enough. However, the existence of the sequence number field generates more amount of transmission. Thus, in the circumstance of insufficiently long field makes overhead for protocols that are sensitive to resource consumption. The sequence number field length should be consider about tradeoff between bandwidth efficiency and quality assurance. 4.2.3. Quality Measurement It is REQUIRED to detect whether packets in a tunnel are in-sequence or out-of-sequence. It is easy for protocols with sequence numbers to introduce such a function by watching the continuity. Moreover, it is REQUIRED to monitor quantity of irregular packets i.e. loss, duplicate and reordering. A simple method will be showed in Section 5. Measuring the packet arrival delay and/or jitter of a tunnel MAY be required. In this requirement, timestamp that synchronized to reference clock would exist as sequence number field. In current protocol, RTP and PWE3 have such functions, however GRE does not so that neither delay nor jitter can be measured. Kikuchi, et al. Expires August 30, 2007 [Page 7] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 4.3. Getting Quality Information Tunneling protocols SHOULD support not only quality measurement but also monitoring. However GRE and PWE3 use sequence numbers only for internal processing. The result of the quality measurement of tunnels MUST be monitored by TSPs and users. In addition, it is needed to modify some parameters used in the measurement mechanisms. Moreover, it may be needed to notify on irregular occasions and illegal operations. These functions SHOULD be defined as standard MIBs in SNMP. 4.4. Overhead Consideration We should consider the computing and space costs of the implementations where the standard defines the measurement and monitoring. These are overhead of traffic transmission, which may reflect the cost of equipment introductions and operational expenses. We should not adopt non-scalable mechanisms. we should pay much attention especially for resource consumption sensitive protocols e.g. mobile protocols. The types of overheads are following. o the space of sequence number in protocol header, o the space of counters and registers implemented in routers, o the computing resources for quality measurement, and so on. We should adopt a simplified determination in some cases when there are a precise complex determination and a simpler one. For example, we do not need a precise state but also an approximation of the degree of the difference from the normal operation. Kikuchi, et al. Expires August 30, 2007 [Page 8] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 5. Implementation We will illustrate an example of the quality measurement mechanism of GRE in accordance with the discussion above. The headers of GRE packets can contain sequence numbers. We will show an algorithm to determine the quality, i.e. loss, duplicate and reordering, of a GRE tunnel while the receive side of the tunnel observes the sequence numbers. We make the following assumptions to simplify the situation. o Each S bit of the packets in a tunnel is always 1, which is the indication flag of sequence number validity. o Each K bit is always 0 that means the key field is unused so that we do not distinguish any flow in the tunnel. o The parameter OUTOFORDER_TIMER and MAX_PERFLOW_BUFFER are both 0 that means all the buffering on the receiving side is disabled. Note that according to the standard of GRE[3] we should discard packets that are not in-sequence. 5.1. Counters and Functions We need the following counters for each receiving side of GRE tunnel. o recvcnt: maintains the number the successive packet should have o losscnt: the number of loss of packets o duplcnt: the number of packet duplications o reodcnt: the number of reordering packets The counters above are unsigned 32bit integer and initialized by 0. Note that recvcnt is slightly different from GRE standard[3] because the initial value should be (2**32)-1 in the standard. The value of the counters above SHOULD be obtained by SNMP R/O MIB. The counters MAY be resettable by SNMP R/W MIB. This algorithm uses three following functions. o measure: invoked by the reception of packets; the algorithm itself o raise: pass the packet to the higher layer Kikuchi, et al. Expires August 30, 2007 [Page 9] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 o discard: drop the packet 5.2. Measurement Algorithm This algorithm determines a receiving packet is whether normal or not while comparison of a counter "recvcnt" with the sequence number of the packet named "seqno". The basic idea consists of the following conditions. 1. if recvcnt and seqno are same then "in-sequence", 2. else if seqno is just a predecessor of recvcnt then "duplicate"; 3. otherwise if seqno proceed then "loss" else "reordering". In detail, GRE receivers can measure the quality by the following C-like codes. measure(packet_t packet) { unsigned int seqno; seqno = packet->header->seqno; // get seq # from header if (seqno == recvcnt) { // no problem recvcnt++; raise(packet); return; } elsif (seqno+1 == recvcnt) { // same seq # as predecessor duplcnt++; discard(packet); return; } signed int diff; diff = (signed int)(seqno - recvcnt); if (diff > 0) { // loss (future packet) losscnt += diff; recvcnt = seqno; } else { // reordering (past packet) reodcnt++; } discard(packet); return; } Figure 2 Kikuchi, et al. Expires August 30, 2007 [Page 10] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 5.2.1. Algorithm Behavior The following diagrams show behaviors of the algorithm on receiving out_of_sequence packets. Figure 4 shows the legend of flow diagram here. Left and right sides are a sender and receiver of a GRE tunnel respectively. Time flows upper to lower in the diagrams. This illustrates a normal transmission with the sequence number n. time sender receiver | | | | n | | n 0 0 0 | |----[seq #: n]----->| | n+1 | | n+1 0 0 0 | | | V V V Figure 3 Figure 4, Figure 5 and Figure 6 show simple cases such as loss, duplicates and reordering packets respectively. Kikuchi, et al. Expires August 30, 2007 [Page 11] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 [reodcnt]................ [duplcnt].............. : [losscnt]............ : : : : : [recvcnt]......... : : : ........[sendcnt] : : : : : : : : : : : : : : : : : : : | | 0 | | 0 0 0 0 |------------------->| 1 | | 1 0 0 0 |------------------->| 2 | | 2 0 0 0 |-----> !LOST! | 3 | | |------------------->| 4 | | 4 1 0 0 |-----> !LOST! | 5 | | |-----> !LOST! | 6 | | |------------------->| 7 | | 7 3 0 0 | | V V Figure 4 Kikuchi, et al. Expires August 30, 2007 [Page 12] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 [reodcnt]................ [duplcnt].............. : [losscnt]............ : : : : : [recvcnt]......... : : : ........[sendcnt] : : : : : : : : : | | 0 | | 0 0 0 0 |------------------->| 1 | | 1 0 0 0 |-------!DUP!------->| | \ | 2 0 0 0 | \-------->| 2 | | 2 0 1 0 |------------------->| 3 | | 3 0 1 0 |-------!DUP!------->| 4 | \ | 4 0 1 0 | !DUP!------>| | \ | 4 1 2 0 | \------>| | | 4 1 3 0 |------------------->| 5 | | 5 1 3 0 | | V V Figure 5 Kikuchi, et al. Expires August 30, 2007 [Page 13] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 [reodcnt]................ [duplcnt].............. : [losscnt]............ : : : : : [recvcnt]......... : : : ........[sendcnt] : : : : : : : : : | | 0 | | 0 0 0 0 |------------------->| 1 | | 1 0 0 0 |-------\ | 2 | \ | |---------\--------->| 3 | \ | 3 1 0 0 | \------->| | | 3 1 0 1 |------------------->| 4 | | 4 1 0 1 |-------\ | 5 | \ | |------\ \ | 6 | \ \ | |--------\--\------->| 7 | \ \ | 7 3 0 1 | \ \----->| | \ | 7 3 0 2 | \------>| | | 7 3 0 3 | | V V Figure 6 Figure 7 and Figure 8 show cases in a little bit complex situations. Figure 7 shows that the algorithm can not distinguish a combination of duplication and loss from a reordering. Compare the flow to former of Figure 6. Kikuchi, et al. Expires August 30, 2007 [Page 14] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 [reodcnt]................ [duplcnt].............. : [losscnt]............ : : : : : [recvcnt]......... : : : ........[sendcnt] : : : : : : : : : | | 0 | | 0 0 0 0 |------------------->| 1 | | 1 0 0 0 |-----!DUP!-->!LOST! | 2 | \ | |---------\--------->| 3 | \ | 3 1 0 0 | \------->| | | 3 1 0 1 | | V V Figure 7 Figure 8 shows that the algorithm interprets it reordering when a duplicated packet does not come just in succession. There is no storage to hold all the information of packet arrivals in order to make the measurement overhead light instead of accuracy. [reodcnt]................ [duplcnt].............. : [losscnt]............ : : : : : [recvcnt]......... : : : ........[sendcnt] : : : : : : : : : | | 0 | | 0 0 0 0 |------------------->| 1 | | 1 0 0 0 |------!DUP!-------->| 2 | \ | 2 0 0 0 |----------\-------->| 3 | \ | 3 0 0 0 | \------>| | | 3 0 0 1 V V Figure 8 Kikuchi, et al. Expires August 30, 2007 [Page 15] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 6. Security Considerations Fraud sequence numbers cause measurement into a muddle. This discussion boils down to the issues of the header protection. Kikuchi, et al. Expires August 30, 2007 [Page 16] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 Appendix A. Acknowledgements The authors would like to thank for helpful discussions in TEReCo research project: Traffic Engineering for Regional Communities, Japan. Kikuchi, et al. Expires August 30, 2007 [Page 17] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 7. Normative References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [2] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [3] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [4] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [5] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [8] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. Kikuchi, et al. Expires August 30, 2007 [Page 18] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 Authors' Addresses KIKUCHI Yutaka Kochi University of Technology 306B Research Collaboration Center 185 Miyanokuchi, Tosayamada-cho Kami-shi, Kochi 782-0003 JP Email: yu@kikuken.org MATSUSHIMA Satoru Softbank Telecom Corp. NAGAMI Ken'ichi Intec Netcore Inc. UDA Satoshi Japan Advanced Institute of Science and Technology, Hokuriku OGASHIWA Nobuo Network Oriented Software Inc. Kikuchi, et al. Expires August 30, 2007 [Page 19] Internet-Draft draft-kikuchi-tunnel-measure-req-00.txt February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kikuchi, et al. Expires August 30, 2007 [Page 20]