idnits 2.17.1 draft-ietf-ippm-rate-problem-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2015) is 3369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) == Outdated reference: A later version (-13) exists of draft-ietf-ippm-model-based-metrics-03 == Outdated reference: A later version (-14) exists of draft-ietf-lmap-framework-10 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Intended status: Informational February 5, 2015 5 Expires: August 9, 2015 7 Rate Measurement Test Protocol Problem Statement and Requirements 8 draft-ietf-ippm-rate-problem-10 10 Abstract 12 This memo presents an access rate-measurement problem statement for 13 test protocols to measure IP Performance Metrics. Key rate 14 measurement test protocol aspects include the ability to control 15 packet characteristics on the tested path, such as asymmetric rate 16 and asymmetric packet size. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 9, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 5 61 4. Measurement Method Categories . . . . . . . . . . . . . . . . 7 62 5. Test Protocol Control & Generation Requirements . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. Operational Considerations . . . . . . . . . . . . . . . . . 11 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 10.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 There are many possible rate measurement scenarios. This memo 75 describes one rate measurement problem and presents a rate- 76 measurement problem statement for test protocols to measure IP 77 Performance Metrics (IPPM). 79 When selecting a form of access to the Internet, subscribers are 80 interested in the performance characteristics of the various 81 alternatives. Standardized measurements can be a basis for 82 comparison between these alternatives. There is an underlying need 83 to coordinate measurements that support such comparisons, and test 84 control protocols to fulfill this need. The figure below depicts 85 some typical measurement points of access networks. 87 User /====== Fiber ======= Access Node \ 88 Device -|------ Copper ------- Access Node -|-- Infrastructure -- GW 89 or Host \------ Radio ------- Access Node / 91 The access-rate scenario or use case has received wide-spread 92 attention of Internet access subscribers and seemingly all Internet 93 industry players, including regulators. This problem is being 94 approached with many different measurement methods. The eventual 95 protocol solutions to this problem (and the systems that utilize the 96 protocol) may not directly involve users, such as when tests reach 97 from the Infrastructure to a service-specific device, such as a 98 residential gateway. However, no aspect of the problem precludes 99 users from developing a test protocol controlled via command line 100 interfaces on both ends. Thus, a very wide range of test protocols, 101 active measurement methods and system solutions are the possible 102 outcomes of this problem statement. 104 2. Purpose and Scope 106 The scope and purpose of this memo is to define the measurement 107 problem statement for test protocols conducting access rate 108 measurement on production networks. Relevant test protocols include 109 [RFC4656] and [RFC5357], but the problem is stated in a general way 110 so that it can be addressed by any existing test protocol, such as 111 [RFC6812]. 113 This memo discusses possibilities for methods of measurement, but 114 does not specify exact methods which would normally be part of the 115 solution, not the problem. 117 We are interested in access measurement scenarios with the following 118 characteristics: 120 o The Access portion of the network is the focus of this problem 121 statement. The user typically subscribes to a service with bi- 122 directional access partly described by rates in bits per second. 123 The rates may be expressed as raw capacity or restricted capacity 124 as described in [RFC6703]. These are the quantities that must be 125 measured according to one or more standard metrics, and for which 126 measurement methods must also be agreed as a part of the solution. 128 o Referring to the reference path illustrated below and defined in 129 [I-D.ietf-ippm-lmap-path], possible measurement points include a 130 Subscriber's host, the access service demarcation point, Intra IP 131 access where a globally routable address is present, or the 132 gateway between the measured access network and other networks. 134 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 135 device Net #1 Net #2 Demarc. Access GW GRA GW 137 GRA = Globally Routable Address, GW = Gateway 139 o Rates at some links near the edge of the provider's network can 140 often be several orders of magnitude less than link rates in the 141 aggregation and core portions of the network. 143 o Asymmetrical access rates on ingress and egress are prevalent. 145 o In many scenarios of interest, extremely large scale of access 146 services requires low complexity devices participating at the user 147 end of the path, and those devices place limits on clock and 148 control timing accuracy. 150 This problem statement assumes that the most-likely bottleneck device 151 or link is adjacent to the remote (user-end) measurement device, or 152 is within one or two router/switch hops of the remote measurement 153 device. 155 Other use cases for rate measurement involve situations where the 156 packet switching and transport facilities are leased by one operator 157 from another and the link capacity available cannot be directly 158 determined (e.g., from device interface utilization). These 159 scenarios could include mobile backhaul, Ethernet Service access 160 networks, and/or extensions of layer 2 or layer 3 networks. The 161 results of rate measurements in such cases could be employed to 162 select alternate routing, investigate whether capacity meets some 163 previous agreement, and/or adapt the rate of traffic sources if a 164 capacity bottleneck is found via the rate measurement. In the case 165 of aggregated leased networks, available capacity may also be 166 asymmetric. In these cases, the tester is assumed to have a sender 167 and receiver location under their control. We refer to this scenario 168 below as the aggregated leased network case. 170 This memo describes protocol support for active measurement methods, 171 consistent with the IPPM working group's traditional charter. Active 172 measurements require synthetic traffic streams dedicated to testing, 173 and do not make measurements on user traffic. See section 2 of 174 [RFC2679], where the concept of a stream is first introduced in IPPM 175 literature as the basis for collecting a sample (defined in section 176 11 of [RFC2330]). 178 As noted in [RFC2330] the focus of access traffic management may 179 influence the rate measurement results for some forms of access, as 180 it may differ between user and test traffic if the test traffic has 181 different characteristics, primarily in terms of the packets 182 themselves (see section 13 of [RFC2330] for the considerations on 183 packet type, or Type-P). 185 There are several aspects of Type-P where user traffic may be 186 examined and selected for special treatment that may affect 187 transmission rates. Various aspects of Type-P are known to influence 188 Equal-Cost Multi-Path (ECMP) routing with possible rate measurement 189 variability across parallel paths. Without being exhaustive, the 190 possibilities include: 192 o Packet length 193 o IP addresses 195 o Transport protocol (e.g. where TCP packets may be routed 196 differently from UDP) 198 o Transport Protocol port numbers 200 This issue requires further discussion when specific solutions/ 201 methods of measurement are proposed, but for this problem statement 202 it is sufficient to identify the problem and indicate that the 203 solution may require an extremely close emulation of user traffic, in 204 terms of one or more factors above. 206 Although the user may have multiple instances of network access 207 available to them, the primary problem scope is to measure one form 208 of access at a time. It is plausible that a solution for the single 209 access problem will be applicable to simultaneous measurement of 210 multiple access instances, but treatment of this scenario is beyond 211 the current scope this document. 213 A key consideration is whether active measurements will be conducted 214 with user traffic present (In-Service testing), or not present (Out- 215 of-Service testing), such as during pre-service testing or 216 maintenance that interrupts service temporarily. Out-of-Service 217 testing includes activities described as "service commissioning", 218 "service activation", and "planned maintenance". Opportunistic In- 219 Service testing when there is no user traffic present (e.g., outside 220 normal business hours) throughout the test interval is essentially 221 equivalent to Out-of-Service testing. Both In-Service and Out-of- 222 Service testing are within the scope of this problem. 224 It is a non-goal to solve the measurement protocol specification 225 problem in this memo. 227 It is a non-goal to standardize methods of measurement in this memo. 228 However, the problem statement mandates support for one category of 229 rate measurement methods in the test protocol and adequate control 230 features for the methods in the control protocol (assuming the 231 control and test protocols are separate). 233 3. Active Rate Measurement 235 This section lists features of active measurement methods needed to 236 measure access rates in production networks. 238 Coordination between source and destination devices through control 239 messages and other basic capabilities described in the methods of 240 IPPM RFCs [RFC2679][RFC2680], and assumed for test protocols such as 241 [RFC5357] and [RFC4656], are taken as given. 243 Most forms of active testing intrude on user performance to some 244 degree, especially In-Service testing. One key tenet of IPPM methods 245 is to minimize test traffic effects on user traffic in the production 246 network. Section 5 of [RFC2680] lists the problems with high 247 measurement traffic rates ("too much traffic"), and the most relevant 248 for rate measurement is the tendency for measurement traffic to skew 249 the results, followed by the possibility of introducing congestion on 250 the access link. Section 4 of [RFC3148] provides additional 251 considerations. The user of protocols for In-Service testing MUST 252 respect these traffic constraints. Obviously, categories of rate 253 measurement methods that use less active test traffic than others 254 with similar accuracy are preferred for In-Service testing, and the 255 specifications of this memo encourage traffic reduction through 256 asymmetric control capabilities. 258 Out-of-Service tests where the test path shares no links with In- 259 Service user traffic, have none of the congestion or skew concerns. 260 Both types should address practical matters common to all test 261 efforts, such as conducting measurements within a reasonable time 262 from the tester's point of view, and ensuring that timestamp accuracy 263 is consistent with the precision needed for measurement [RFC2330]. 264 Out-of-Service tests where some part of the test path is shared with 265 In-Service traffic MUST respect the In-Service constraints described 266 above. 268 The intended metrics to be measured have strong influence over the 269 categories of measurement methods required. For example, using the 270 terminology of [RFC5136], it may be possible to measure a Path 271 Capacity Metric while In-Service if the level of background (user) 272 traffic can be assessed and included in the reported result. 274 The measurement *architecture* MAY be either of one-way (e.g., 275 [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity 276 aspects of end-user or aggregated access measurement clearly favor 277 two-way (with low-complexity user-end device and round-trip results 278 collection, as found in [RFC5357]). However, the asymmetric rates of 279 many access services mean that the measurement system MUST be able to 280 evaluate performance in each direction of transmission. In the two- 281 way architecture, both end devices MUST include the ability to launch 282 test streams and collect the results of measurements in both (one- 283 way) directions of transmission (this requirement is consistent with 284 previous protocol specifications, and it is not a unique problem for 285 rate measurements). 287 The following paragraphs describe features for the roles of test 288 packet SENDER, RECEIVER, and results REPORTER. 290 SENDER: 292 Generate streams of test packets with various characteristics as 293 desired (see Section 4). The SENDER MAY be located at the user end 294 of the access path or elsewhere in the production network, such as at 295 one end of an aggregated leased network segment. 297 RECEIVER: 299 Collect streams of test packets with various characteristics (as 300 described above), and make the measurements necessary to support rate 301 measurement at the receiving end of an access or aggregated leased 302 network segment. 304 REPORTER: 306 Use information from test packets and local processes to measure 307 delivered packet rates, and prepare results in the required format 308 (the REPORTER role may be combined with another role, most likely the 309 SENDER). 311 4. Measurement Method Categories 313 A protocol that addresses the rate measurement problem MUST serve the 314 test stream generation and measurement functions (SENDER and 315 RECEIVER). The follow-up phase of analyzing the measurement results 316 to produce a report is outside the scope of this problem and memo 317 (REPORTER). 319 For the purposes of this problem statement, we categorize the many 320 possibilities for rate measurement stream generation as follows; 322 1. Packet pairs, with fixed intra-pair packet spacing and fixed or 323 random time intervals between pairs in a test stream. 325 2. Multiple streams of packet pairs, with a range of intra-pair 326 spacing and inter-pair intervals. 328 3. One or more packet ensembles in a test stream, using a fixed 329 ensemble size in packets and one or more fixed intra-ensemble 330 packet spacings (including zero spacing, meaning that back-to- 331 back burst ensembles and constant rate ensembles fall in this 332 category). 334 4. One or more packet chirps (a set of packets with specified 335 characteristics), where inter-packet spacing typically decreases 336 between adjacent packets in the same chirp and each pair of 337 packets represents a rate for testing purposes. 339 The test protocol SHALL support test packet ensemble generation 340 (category 3), as this appears to minimize the demands on measurement 341 accuracy. Other stream generation categories are OPTIONAL. 343 For all supported categories, the following is a list of additional 344 variables that the protocol(s) MUST be able to specify, control, and 345 generate: 347 a. Variable payload lengths among packet streams 349 b. Variable length (in packets) among packet streams or ensembles 351 c. Variable IP header markings among packet streams 353 d. Choice of UDP transport and variable port numbers, OR, choice of 354 TCP transport and variable port numbers for two-way architectures 355 only, OR BOTH. See below for additional requirements on TCP 356 transport generation. 358 e. Variable number of packet-pairs, ensembles, or streams used in a 359 test session. 361 The ability to revise these variables during an established test 362 session is OPTIONAL, as multiple test sessions could serve the same 363 purpose. Another OPTIONAL feature is the ability to generate streams 364 with VLAN tags and other markings. 366 For measurement systems employing TCP as the transport protocol, the 367 ability to generate specific stream characteristics requires a sender 368 with the ability to establish and prime the connection such that the 369 desired stream characteristics are allowed. See Mathis' work in 370 progress for more background [I-D.ietf-ippm-model-based-metrics]. 372 Beyond simple connection handshake and options establishment, an 373 "open-loop" TCP sender requires the SENDER ability to: 375 o generate TCP packets with well-formed headers (all fields valid), 376 including Acknowledgement aspects. 378 o produce packet streams at controlled rates and variable inter- 379 packet spacings, including packet ensembles (back-to-back at 380 server rate). 382 o continue the configured sending stream characteristics despite all 383 control indications except receive window exhaust. 385 The corresponding TCP RECEIVER performs normally, having some ability 386 to configure the receive window sufficiently large so as to allow the 387 SENDER to transmit at will (up to a configured target). 389 It may also be useful (for diagnostic purposes) to provide a control 390 for Bulk Transfer Capacity measurement with fully-specified (and 391 congestion-controlled) TCP senders and receivers, as envisioned in 392 [RFC3148], but this would be a brute-force assessment which does not 393 follow the conservative tenets of IPPM measurement [RFC2330]. 395 Measurements for each UDP test packet transferred between SENDER and 396 RECEIVER MUST be compliant with the singleton measurement methods 397 described in IPPM RFCs [RFC2679][RFC2680]. The time-stamp 398 information or loss/arrival status for each packet MUST be available 399 for communication to the REPORTER function. 401 5. Test Protocol Control & Generation Requirements 403 In summary, the test protocol must support the measurement features 404 described in the sections above. This requires: 406 1. Communicating all test variables to the SENDER and RECEIVER 408 2. Results collection in a one-way architecture 410 3. Remote device control for both one-way and two-way architectures 412 4. Asymmetric packet rates in a two-way measurement architecture, or 413 coordinated one-way test capabilities with the same effect 414 (asymmetric rates may be achieved through directional control of 415 packet rate or packet size) 417 The ability to control and generate asymmetric rates in a two-way 418 architecture is REQUIRED. Two-way architectures are RECOMMENDED to 419 include control and generation capability for both asymmetric and 420 symmetric packet sizes, because packet size often matters in the 421 scope of this problem and test systems SHOULD be equipped to detect 422 directional size dependency through comparative measurements. 424 Asymmetric packet size control is indicated when the result of a 425 measurement may depend on the size of the packets used in each 426 direction, i.e. when any of the following conditions hold: 428 o there is a link in the path with asymmetrical capacity in opposite 429 directions (in combination with one or more of the conditions 430 below, but their presence or specific details may be unknown to 431 the tester), 433 o there is a link in the path which aggregates (or divides) packets 434 into link-level frames, and may have a capacity that depends on 435 packet size, rate, or timing, 437 o there is a link in the path where transmission in one direction 438 influences performance in the opposite direction, 440 o there is a device in the path where transmission capacity depends 441 on packet header processing capacity (in other words, the capacity 442 is sensitive to packet size), 444 o the target application stream is nominally MTU size packets in one 445 direction vs. ACK stream in the other, (noting that there are a 446 vanishing number of symmetrical-rate application streams for which 447 rate measurement is wanted or interesting, but such streams might 448 have some relevance at this time), 450 o the distribution of packet losses is critical to rate assessment, 452 and possibly other circumstances revealed by measurements comparing 453 streams with symmetrical size and asymmetrical size. 455 Implementations may support control and generation for only symmetric 456 packet sizes when none of the above conditions hold. 458 The test protocol SHOULD enable measurement of the [RFC5136] Capacity 459 metric, either Out-of-Service, In-Service, or both. Other [RFC5136] 460 metrics are OPTIONAL. 462 6. Security Considerations 464 The security considerations that apply to any active measurement of 465 live networks are relevant here as well. See [RFC4656] and 466 [RFC5357]. 468 Privacy considerations for measurement systems, particularly when 469 Internet users participate in the tests in some way, are described in 470 [I-D.ietf-lmap-framework]. 472 There may be a serious issue if a proprietary Service Level Agreement 473 involved with the access network segment provider were somehow leaked 474 in the process of rate measurement. To address this, test protocols 475 SHOULD NOT convey this information in a way that could be discovered 476 by unauthorized parties. 478 7. Operational Considerations 480 All forms of testing originate traffic on the network, through their 481 communications for control and results collection, or from dedicated 482 measurement packet streams, or both. Testing traffic primarily falls 483 in one of two categories, subscriber traffic or network management 484 traffic. There is an on-going need to engineer networks so that 485 various forms of traffic are adequately served, and publication of 486 this memo does not change this need. Service subscribers and 487 authorized users SHOULD obtain their network operator's or service 488 provider's permission before conducting tests. Likewise, a service 489 provider or third party SHOULD obtain the subscriber's permission to 490 conduct tests, since they might temporarily reduce service quality. 491 The protocol SHOULD communicate the permission status once the 492 overall system has obtained it, either explicitly or through other 493 means. 495 Subscribers, their service providers and network operators, and 496 sometimes third parties, all seek to measure network performance. 497 Capacity testing with active traffic often affects the packet 498 transfer performance of streams traversing shared components of the 499 test path, to some degree. The degradation can be minimized by 500 scheduling such tests infrequently, and restricting the amount of 501 measurement traffic required to assess capacity metrics. As a 502 result, occasional short-duration estimates with minimal traffic are 503 preferred to measurements based on frequent file transfers of many 504 Megabytes with similar accuracy. New measurement methodologies 505 intended for standardization should be evaluated individually for 506 potential operational issues. However, the scheduled frequency of 507 testing is as important as the methods used (and schedules are not 508 typically submitted for standardization). 510 The new test protocol feature of asymmetrical packet size generation 511 in two-way testing is recommended in this memo. It can appreciably 512 reduce the load and packet processing demands of each test and 513 therefore reduce the likelihood of degradation in one direction of 514 the tested path. Current IETF standardized test protocols (e.g., 515 [RFC5357], also [RFC6812]) do not possess the asymmetric size 516 generation capability with two-way testing. 518 8. IANA Considerations 520 This memo makes no requests of IANA. 522 9. Acknowledgements 524 Dave McDysan provided comments and text for the aggregated leased use 525 case. Yaakov Stein suggested many considerations to address, 526 including the In-Service vs. Out-of-Service distinction and its 527 implication on test traffic limits and protocols. Bill Cerveny, 528 Marcelo Bagnulo, Kostas Pentikousis (a persistent reviewer), and 529 Joachim Fabini have contributed insightful, clarifying comments that 530 made this a better draft. Barry Constantine also provided 531 suggestions for clarification. 533 10. References 535 10.1. Normative References 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 541 "Framework for IP Performance Metrics", RFC 2330, May 542 1998. 544 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 545 Delay Metric for IPPM", RFC 2679, September 1999. 547 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 548 Packet Loss Metric for IPPM", RFC 2680, September 1999. 550 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 551 Zekauskas, "A One-way Active Measurement Protocol 552 (OWAMP)", RFC 4656, September 2006. 554 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 555 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 556 RFC 5357, October 2008. 558 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 559 IP Network Performance Metrics: Different Points of View", 560 RFC 6703, August 2012. 562 10.2. Informative References 564 [I-D.ietf-ippm-lmap-path] 565 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 566 A. Morton, "A Reference Path and Measurement Points for 567 Large-Scale Measurement of Broadband Performance", draft- 568 ietf-ippm-lmap-path-07 (work in progress), October 2014. 570 [I-D.ietf-ippm-model-based-metrics] 571 Mathis, M. and A. Morton, "Model Based Bulk Performance 572 Metrics", draft-ietf-ippm-model-based-metrics-03 (work in 573 progress), July 2014. 575 [I-D.ietf-lmap-framework] 576 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 577 Aitken, P., and A. Akhter, "A framework for large-scale 578 measurement platforms (LMAP)", draft-ietf-lmap- 579 framework-10 (work in progress), January 2015. 581 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 582 Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 583 2001. 585 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 586 RFC 5136, February 2008. 588 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 589 S., and E. Yedavalli, "Cisco Service-Level Assurance 590 Protocol", RFC 6812, January 2013. 592 Author's Address 594 Al Morton 595 AT&T Labs 596 200 Laurel Avenue South 597 Middletown,, NJ 07748 598 USA 600 Phone: +1 732 420 1571 601 Fax: +1 732 368 1192 602 Email: acmorton@att.com 603 URI: http://home.comcast.net/~acmacm/