idnits 2.17.1 draft-kikuchi-passive-measure-reqs-00.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 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 304. 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 (Jul 08, 2008) is 5769 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: January 9, 2009 Softbank Telecom Corp. 6 K. Nagami 7 Intec Netcore Inc. 8 S. Uda 9 Japan Advanced Institute of 10 Science and Technology 11 Jul 08, 2008 13 Requirements of One-way Passive Measurement for End-to-End Quality 14 draft-kikuchi-passive-measure-reqs-00.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 January 9, 2009. 41 Abstract 43 This draft describes the necessary requirements to passively measure 44 end-to-end quality and to monitor them via applicable ways. This 45 feature is crucial for Service Providers (SPs), especially who 46 provide transports with Service Level Agreements (SLAs). 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 53 2. Service Model . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Active vs. Passive . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Quality Evaluation . . . . . . . . . . . . . . . . . . . . 6 60 4.3. Getting Quality Information . . . . . . . . . . . . . . . 6 61 4.4. Overhead Consideration . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 72 Intellectual Property and Copyright Statements . . . . . . . . . . 12 74 1. Introduction 76 This draft describes the necessary requirements to passively measure 77 end-to-end quality and to monitor them via applicable ways. 79 Measuring end-to-end quality in passive ways is necessary for Service 80 Providers (SPs) who provide transport to users. However, the 81 standards do not define the measurement and monitoring of a network, 82 which is helpful when the SPs want to know the quality of their end- 83 to-end traffic. Therefore, measurement and monitoring standards need 84 to be defined. 86 1.1. Requirements notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Service Model 94 Figure 1 shows that SP X and SP Y provide a transport between user A 95 and user B using some ISPs. Let SP X and SP Y "Transport Service 96 Providers" (TSPs) here because they should be distinguished from the 97 intermediate ISPs. The users construct an application over the 98 transport. The TSPs may apply two or more routes to provide one 99 transport. 101 USER A ................. Application ................ USER B 102 | | 103 (SLA) (SLA) 104 | | 105 TSP X >>................ Transport ................>> TSP Y 106 | | 107 *-> ISP 1_1 -> ISP 1_2 -> ... -> ISP 1_n1 ->* 108 | | 109 *-> ISP 2_1 -> ISP 2_2 -> ... -> ISP 2_n2 ->* 110 : : 111 *-> ISP m_1 -> ISP m_2 -> ... -> ISP m_nm ->* 113 Figure 1: Service Model 115 The TSPs maintain reachability and some required quality of the 116 transport of IP datagrams to users. There must be Service Level 117 Agreements (SLAs) in the contract between the TSPs and thier users. 118 The SLAs specify the level that the TSPs must maintain, which are 119 sets of measurable characteristics such as total unavailable time in 120 a month, loss of packets and some qualities for real time 121 applications. 123 3. Motivations 125 TSPs need to know the quality of their traffic in order to know 126 whether the traffic in a normal state or not. The measured quality 127 could be important information to trace down the cause of the trouble 128 when an application is not working properly. Without the necessary 129 information, it is difficult for TSPs to determine whether problems 130 come from the user, the TSPs, or the intermediate ISPs. 132 The quality measurement is specially required by TSPs when they have 133 SLAs to their customers. They must be aware of the status of 134 underlying traffic well and must report it as an evidence of quality 135 to the users. 137 TSPs also need to know the quality of a transport when they have 138 multiple paths to serve the transport. TSPs may be able to serve an 139 appropriate transport to users by selecting a better quality path. 140 In addition, the TSPs may be able to distribute the load of a 141 transport to different paths. 143 4. Requirements 145 This section describes each requirement necessary to measure one-way 146 end-to-end quality for TSPs. 148 The quality should be measured for transports in operation because 149 the measured quality is used to maintain the transports to report 150 regarding to the SLA and to select the best path. The measurement 151 would be used not only for testing and benchmarking but also for the 152 daily operational tool. Therefore, the requirements are from 153 operational points of view. 155 4.1. Active vs. Passive 157 There are two ways to measure the quality of transports, one is 158 active and the other is passive. Active measurement uses additional 159 probing packets to determine the quality of the tranports. Passive 160 measurement uses the traffic packets to measure quality. 162 From the TSPs point of view, passive measurement should be supported. 163 Because SLAs should refer to the users' transports, the measurement 164 should be determined passively rather than actively. 166 4.2. Quality Evaluation 168 The standard that define a passive measurement of transports must 169 contain two elements, one is `WHAT' type of quality the protocol 170 measure, or `metrics', and the other is `HOW' the protocol evaluate 171 the quality. 173 The most basic metric is to detect whether the packets in a transport 174 are in-sequence or out-of-sequence. Measurement of types of out-of- 175 sequence packets are also basic metrics, such as lost, duplication 176 and reordering in a transport. 178 It is required to disable the measurement function for avoiding the 179 measurement overhead in case when TSPs need not to measure the 180 quality. See also the discussion in the Section 4.4. 182 4.3. Getting Quality Information 184 The measurement mechanisms must define how to monitor the result of 185 the quality of transports, such as SNMP [RFC3411]. The parameters 186 used in the measurement mechanisms might be modified by TSPs' 187 operators. Moreover, they may notify exceptional situations and 188 illegal operations to the operators. 190 4.4. Overhead Consideration 192 Protocol designers should take into account the computing and space 193 costs of the implementations where the standard defines the 194 measurement and monitoring. This includes overhead of traffic 195 transmission, which may reflect the cost of equipment introductions 196 and operational expenses. The designers should not adopt non- 197 scalable mechanisms and should pay particular attention to resource 198 consumption sensitive protocols such as mobile protocols. 200 We should adopt a simplified determination in some cases when both a 201 precise complex determination and a simpler one exist. Sometimes it 202 is sufficient for operators to show an approximate degree different 203 from the normal operation rather than a precise state. 205 5. Security Considerations 207 Not yet. 209 Appendix A. Acknowledgements 211 The authors would like to thank for helpful discussions in TEReCo 2.0 212 research project sponsored in part by the ministry of internal 213 affairs and communications Japan (SCOPE 072309007). 215 6. References 217 6.1. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 6.2. Informative References 224 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 225 Architecture for Describing Simple Network Management 226 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 227 December 2002. 229 Authors' Addresses 231 Yutaka Kikuchi 232 Kochi University of Technology 233 306B Research Collaboration Center 234 185 Miyanokuchi, Tosayamada-cho 235 Kami-shi, Kochi 782-0003 236 JP 238 Phone: +81-887-57-2068 239 Email: yu@kikuken.org 241 Satoru Matsushima 242 Softbank Telecom Corp. 243 1-9-1 Higashi-Shinbashi 244 Minato-ku, Tokyo 245 JP 247 Email: satoru@ft.solteria.net 249 Ken-ichi Nagami 250 Intec Netcore Inc. 251 1-3-3 Shin-suna 252 Koto-ku, Tokyo 253 JP 255 Phone: +81-3-5565-5069 256 Email: nagami@inetcore.com 258 Satoshi Uda 259 Japan Advanced Institute of Science and Technology 260 1-1 Asahi-dai 261 Nomi-shi, Ishikawa-ken 923-1292 262 JP 264 Email: zin@jaist.ac.jp 266 Full Copyright Statement 268 Copyright (C) The IETF Trust (2008). 270 This document is subject to the rights, licenses and restrictions 271 contained in BCP 78, and except as set forth therein, the authors 272 retain all their rights. 274 This document and the information contained herein are provided on an 275 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 276 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 277 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 278 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 279 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 280 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 282 Intellectual Property 284 The IETF takes no position regarding the validity or scope of any 285 Intellectual Property Rights or other rights that might be claimed to 286 pertain to the implementation or use of the technology described in 287 this document or the extent to which any license under such rights 288 might or might not be available; nor does it represent that it has 289 made any independent effort to identify any such rights. Information 290 on the procedures with respect to rights in RFC documents can be 291 found in BCP 78 and BCP 79. 293 Copies of IPR disclosures made to the IETF Secretariat and any 294 assurances of licenses to be made available, or the result of an 295 attempt made to obtain a general license or permission for the use of 296 such proprietary rights by implementers or users of this 297 specification can be obtained from the IETF on-line IPR repository at 298 http://www.ietf.org/ipr. 300 The IETF invites any interested party to bring to its attention any 301 copyrights, patents or patent applications, or other proprietary 302 rights that may cover technology that may be required to implement 303 this standard. Please address the information to the IETF at 304 ietf-ipr@ietf.org.