idnits 2.17.00 (12 Aug 2021) /tmp/idnits2409/draft-kikuchi-tunnel-measure-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 406. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Nov 12, 2007) is 5297 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Kikuchi 3 Internet-Draft Kochi University of Technology 4 Intended status: Informational S. Matsushima 5 Expires: May 15, 2008 Softbank Telecom Corp. 6 K. Nagami 7 Intec Netcore Inc. 8 S. Uda 9 Japan Advanced Institute of 10 Science and Technology 11 Nov 12, 2007 13 Quality Measurement Requirements for Tunneling Protocols 14 draft-kikuchi-tunnel-measure-req-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 15, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This draft describes the necessary requirements to passively measure 48 the quality of end-to-end tunnels and to monitor them via applicable 49 ways. This feature is crucial for Service Providers (SPs), 50 especially who provide transports to users using tunnels. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. Service Model . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. Active vs. Passive . . . . . . . . . . . . . . . . . . . . 7 63 4.2. Quality Evaluation . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Getting Quality Information . . . . . . . . . . . . . . . 8 65 4.4. Overhead Consideration . . . . . . . . . . . . . . . . . . 8 66 4.5. Header Information . . . . . . . . . . . . . . . . . . . . 8 67 4.5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . 9 68 4.5.2. Time Stamping . . . . . . . . . . . . . . . . . . . . 9 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 76 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 Intellectual Property and Copyright Statements . . . . . . . . . . 14 81 1. Introduction 83 This draft describes the necessary requirements to passively measure 84 the quality of end-to-end tunnels passively and to monitor them via 85 some applicable ways. 87 In this document, ``tunnel'' refers to the various technologies used 88 to provide networks or datalinks virtually over real networks. 89 Examples of tunneling are GRE [2], IP Encapsulation within IP (IPIP) 90 [3], and Pseudo Wire Emulation Edge-to-Edge (PWE3) [4]. 92 Measuring end-to-end quality of tunnels is necessary for Transport 93 Service Providers (TSPs) who provide transport to users using 94 tunnels. However, the standards do not define the measurement and 95 monitoring of a network, which is helpful when TSPs want to know the 96 quality of their traffic through tunnels. Therefore, measurement and 97 monitoring standards need to be defined. 99 1.1. Requirements notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [1]. 105 2. Service Model 107 Figure 1 shows that TSP X provides a transport between user A and 108 user B using a tunnel. The users construct an application over the 109 transport. The TSP may apply two or more tunnels to provide one 110 transport. 112 USER A USER B 113 | \ / | 114 | \--SLA A SLA B--/ | 115 | \ / | 116 + ................... Application ................... + 117 | \ / | 118 | ------------- / | 119 | \ / | 120 | \ / | 121 LAN A ............. Transport by TSP X ............. LAN B 122 | | 123 *-- ISP 1_1 -- ISP 1_2 -- ... -- ISP 1_n1 --* 124 | | 125 *-- ISP 2_1 -- ISP 2_2 -- ... -- ISP 2_n2 --* 126 : : 127 *-- ISP m_1 -- ISP m_2 -- ... -- ISP m_nm --* 129 Figure 1: A Service Model of TSP 131 TSPs provide a reachability of IP datagrams or layer 2 frames to 132 users. Typically, users are not able to identify the path details 133 under the transport, which is the sequence of transit ISPs, because 134 the tunnel eliminates the path information so that the users must 135 recognize that both ends of the transport as a neighbor. 137 TSPs provide simplified and virtual transports by hiding the 138 underlying layers from the users. The users are able to reduce the 139 cost of operation and management because they need not maintain the 140 underlying layers. The reachability maintenance and the quality 141 management are served as TSPs' communication services. 143 There must be a Service Level Agreement (SLA) in the contract between 144 a TSP and its user. The SLA specifies the level that the TSP must 145 maintain, which is a set of measurable characteristics such as the 146 total unavailable time in a month, maximum out-of-sequence rates and 147 some qualities for real time applications. 149 In addition, TSPs may be able to provide better transports when the 150 TSPs have several tunnels via different paths. Furthermore, TSPs may 151 be able to provide protocols needed by the users even if there are no 152 such protocols served by the ISPs. 154 3. Motivations 156 TSPs need to know the quality of their tunnels in order to know 157 whether the tunnels are in a normal state or not. The measured 158 quality could be important information to trace down the cause of the 159 trouble when an application is not working properly. Without the 160 necessary information, it is difficult for TSPs to determine whether 161 problems come from the user, the TSP itself, or the ISPs. 163 The tunnel quality measurement is specially needed by TSPs because 164 they have SLAs to their customers. They must be aware of the status 165 of underlying tunnels well and must report it as an evidence of 166 quality to the users. 168 TSPs also need to know the tunnels' quality when they have multiple 169 tunnels to serve transports. TSPs may be able to serve appropriate 170 transports to users by selecting better quality tunnels. In 171 addition, the TSPs may be able to distribute the load of a transport 172 to different path tunnels. 174 4. Requirements 176 This section describes each requirement necessary to measure end-to- 177 end tunnel quality for TSPs. 179 The quality should be measured for tunnel traffic in operation 180 because the measured quality is used to maintain the tunnel, to 181 report regarding to the SLA and to select the best tunnel. The 182 measurement would be used not only for testing and benchmarking but 183 also for the daily operational tool. Therefore, the requirements are 184 from operational points of view. 186 4.1. Active vs. Passive 188 There are two ways to measure the quality of a tunnel, one is active 189 and the other is passive. Active measurement uses additional probing 190 packets to determine the quality of the channel. Passive measurement 191 uses the traffic packets to measure quality. 193 From the TSPs point of view, passive measurement should be supported. 194 Because SLAs should refer to the users' packets, the measurement 195 should be determined passively rather than actively. 197 On the other hand, it is not necessary to let the protocol have a 198 quality measurement function with active measurement. TSPs can 199 construct the active measurement method independently from the target 200 protocol. A typical example is PING, which uses Internet Control 201 Message Protocol (ICMP) [5]. 203 4.2. Quality Evaluation 205 The standard that define a passive measurement of a tunneling 206 protocol must contain two items, one is `WHAT' type of quality the 207 protocol measure, or `metrics', and the other is `HOW' the protocol 208 evaluate the quality. 210 The most basic metric is to detect whether the packets in a tunnel 211 are in-sequence or out-of-sequence. Measurements of out-of-sequence 212 packets are also basic metrics, such as loss, duplication and 213 reordering. Additionally, it may support to measure delay and/or 214 jitter when the packets are in-sequence. 216 It is required to disable the measurement function for avoiding the 217 measurement overhead in case when TSPs need not to measure the tunnel 218 quality. See also the discussion in the Section 4.4. 220 Note that the tunnel quality discussed in this document shall not 221 refer any specific application, so that the metrics must be 222 independent from the payload information. See also the discussion in 223 the Section 4.5. 225 4.3. Getting Quality Information 227 Tunneling protocols must support monitoring when the protocols have 228 quality measurement functions. The protocol must define how to 229 monitor the result of the quality measurement of tunnels, such as 230 SNMP [6]. 232 The parameters used in the measurement mechanisms might be modified 233 by TSPs' operators. Moreover, it may notify exceptional situations 234 and illegal operations to the operators. 236 4.4. Overhead Consideration 238 Protocol designers should take into account the computing and space 239 costs of the implementations where the standard defines the 240 measurement and monitoring. This includes overhead of traffic 241 transmission, which may reflect the cost of equipment introductions 242 and operational expenses. The designers should not adopt non- 243 scalable mechanisms and should pay particular attention to resource 244 consumption sensitive protocols such as mobile protocols. 246 The types of overheads are as follows. 248 o the space of additional information in protocol header, 250 o the time of sending and receiving the information above, and 252 o the computing resources for quality measurement implemented in 253 routers. 255 We should adopt a simplified determination in some cases when both a 256 precise complex determination and a simpler one exist. Sometimes it 257 is sufficient for operators to show an approximate degree different 258 from the normal operation rather than a precise state. 260 4.5. Header Information 262 The target tunneling protocol must provide information to measure the 263 quality. This means that the protocol header has enough information 264 because the measurement must be passive and must not refer to the 265 payload, according to the Section 4.1 and the Section 4.2. 267 For example, in an extreme case, IPIP [3] does not have any extra 268 field in the outer header on encapsulation, so that it is difficult 269 to define passive metrics for IPIP. However many tunneling protocols 270 have some information in their headers, which allows to detect some 271 quality passively. 273 4.5.1. Sequence Numbering 275 If a protocol has a sequence number field, it is easy for egress 276 router to determine the tunnel is in-sequence or not. Moreover, it 277 can recognize how the irregular is, such as loss, duplication and 278 reordering. 280 The original GRE [2] does not have much information but the extended 281 GRE [7] has a sequence number field, therefore it can detect out-of- 282 sequence and how irregular. 284 4.5.2. Time Stamping 286 If there is a timestamp in the header of a tunneling protocol, even 287 the timestamps might be synchronized to a reference clock, it can 288 measure delay and jitter. Such kinds of metrics provide the tunnel 289 quality when the packets are in-sequence rather than out-of-sequence. 291 5. Security Considerations 293 Fraud header information, such as sequence numbers and time stamps, 294 causes the measurement process to become disorganized. This 295 discussion boils down to the issues of the header protection. 297 Appendix A. Acknowledgements 299 The authors would like to thank for helpful discussions in TEReCo 2.0 300 research project sponsored in part by the ministry of internal 301 affairs and communications Japan (SCOPE 072309007). 303 6. References 305 6.1. Normative References 307 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 308 Levels", BCP 14, RFC 2119, March 1997. 310 6.2. Informative References 312 [2] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, 313 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 315 [3] Perkins, C., "IP Encapsulation within IP", RFC 2003, 316 October 1996. 318 [4] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge 319 (PWE3) Architecture", RFC 3985, March 2005. 321 [5] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 322 September 1981. 324 [6] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 325 Describing Simple Network Management Protocol (SNMP) Management 326 Frameworks", STD 62, RFC 3411, December 2002. 328 [7] Dommety, G., "Key and Sequence Number Extensions to GRE", 329 RFC 2890, September 2000. 331 Authors' Addresses 333 Yutaka Kikuchi 334 Kochi University of Technology 335 306B Research Collaboration Center 336 185 Miyanokuchi, Tosayamada-cho 337 Kami-shi, Kochi 782-0003 338 JP 340 Phone: +81-887-57-2068 341 Email: yu@kikuken.org 343 Satoru Matsushima 344 Softbank Telecom Corp. 345 1-9-1 Higashi-Shinbashi 346 Minato-ku, Tokyo 347 JP 349 Email: satoru@ft.solteria.net 351 Ken-ichi Nagami 352 Intec Netcore Inc. 353 1-3-3 Shin-suna 354 Koto-ku, Tokyo 355 JP 357 Phone: +81-3-5565-5069 358 Email: nagami@inetcore.com 360 Satoshi Uda 361 Japan Advanced Institute of Science and Technology 362 1-1 Asahi-dai 363 Nomi-shi, Ishikawa-ken 923-1292 364 JP 366 Email: zin@jaist.ac.jp 368 Full Copyright Statement 370 Copyright (C) The IETF Trust (2007). 372 This document is subject to the rights, licenses and restrictions 373 contained in BCP 78, and except as set forth therein, the authors 374 retain all their rights. 376 This document and the information contained herein are provided on an 377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 379 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 380 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 381 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 384 Intellectual Property 386 The IETF takes no position regarding the validity or scope of any 387 Intellectual Property Rights or other rights that might be claimed to 388 pertain to the implementation or use of the technology described in 389 this document or the extent to which any license under such rights 390 might or might not be available; nor does it represent that it has 391 made any independent effort to identify any such rights. Information 392 on the procedures with respect to rights in RFC documents can be 393 found in BCP 78 and BCP 79. 395 Copies of IPR disclosures made to the IETF Secretariat and any 396 assurances of licenses to be made available, or the result of an 397 attempt made to obtain a general license or permission for the use of 398 such proprietary rights by implementers or users of this 399 specification can be obtained from the IETF on-line IPR repository at 400 http://www.ietf.org/ipr. 402 The IETF invites any interested party to bring to its attention any 403 copyrights, patents or patent applications, or other proprietary 404 rights that may cover technology that may be required to implement 405 this standard. Please address the information to the IETF at 406 ietf-ipr@ietf.org. 408 Acknowledgment 410 Funding for the RFC Editor function is provided by the IETF 411 Administrative Support Activity (IASA).