idnits 2.17.1 draft-turaga-lmap-special-loop-address-01.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 14, 2016) is 2752 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3927' is mentioned on line 178, but not defined == Missing Reference: 'RFC 4291' is mentioned on line 179, but not defined == Missing Reference: 'RFC792' is mentioned on line 261, but not defined == Unused Reference: 'RFC0792' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC3927' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 397, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5156 (Obsoleted by RFC 6890) ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Turaga 3 Internet-Draft R. Raszuk 4 Intended status: Standards Track Bloomberg LP 5 Expires: March 18, 2017 September 14, 2016 7 Special Loop Address 8 draft-turaga-lmap-special-loop-address-01 10 Abstract 12 This document describes a method for automatic detection of link 13 quality issues between two devices connected together by any standard 14 link in an IP based network. This document focuses on inline 15 detection in any network attached device (ie server, router, switch 16 etc..) 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 March 18, 2017. 41 Copyright Notice 43 Copyright (c) 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. IPv4/IPv6 Special Purpose Loop Addresses . . . . . . . . . . 4 62 5. Operation of test suite using Special Purpose IP Loop Address 5 63 6. Comparison with stated test requirements . . . . . . . . . . 6 64 7. Probe size and rate calculation . . . . . . . . . . . . . . . 7 65 8. Probe's QOS marking . . . . . . . . . . . . . . . . . . . . . 7 66 9. Bandwidth Considerations for link under test . . . . . . . . 7 67 10. I2RS and YANG modelling . . . . . . . . . . . . . . . . . . . 7 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 12. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 71 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 72 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 15.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 15.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Terminology 79 o RTT - Round Trip Time 80 o TTL - Time to Live 81 o BFD - BiDirectional Failure Detection 82 o LFM - Link Fault Management 83 o ICMP - Internet Control Message Protocol 85 2. Introduction 87 Real time monitoring of WAN or MAN link quality presents a real 88 operational challenge. The common use of circuit emulation 89 techniques by carriers makes detection of the circuits degradation 90 difficult. Very often such reduced link quality results in increased 91 queuing times or packet drops beyond SLA guarantees. Furthermore, 92 the characteristics of link degradation is different from link to 93 link. 95 The problem space described above is further complicated due to the 96 following reasons: 98 o Link anomalies may not occur at the same uniform rate or be of the 99 same constant and continuous pattern. This transient 100 characteristic maybe a function of load or other temporary 101 problems for example transport network over-subscription. 102 o Encountered degradated service behavior may not translate to link 103 errors or packet discards on either end of the suspected link 104 because the emulated link consisting of multiple independent L2 105 segments in the carrier's network. 107 Currently available tools on the circuit endpoints (usually routers) 108 do not allow easy way to diagnose circuit health. Tools used today 109 to detect link issues include: 111 o Creating hardware or software loops manually - this results in the 112 actual link under test to be taken out of service. Test traffic 113 is then sent through the link and based on the results of the 114 test, link quality issues are detected. 115 o Regular pings/probes on directly connected links between routers/ 116 network devices - Depending on the size of the probe packets and 117 the rate at which they are sent between the network devices and 118 the loss, the link issues are detected. The issue with this 119 approach is that network processor on the router has to process 120 all these packets. This causes an additional processing load on 121 the routers. 122 o BFD, IP protocol hellos etc are based on detecting neighbor state 123 based on tiny and lightweight hellos. Such probes were designed 124 for fast detection of end-to-end link state events .. not to 125 evaluate link quality. If say N hellos send in T interval are 126 lost it is an indication about link or peer down event. 127 o The layer 2 OAM tools are not capable of addressing the 128 requirements since by definition an emulated link consists of 129 number of different L2 links hidden by the emulation layer and its 130 encapsulation. L2 OAM could only indicate potential problems 131 within single layer 2 link. They are light weight and some of 132 these issues can only be detected at various levels of data rates 133 (within agreed SLAs) transiting via such links. 135 3. Requirements 137 The following are some of the key considerations required to be 138 addressed in an alternative diagnostics solutions: 140 o The testing should be atomic in nature - the UUT in this document 141 is a single p2p link. 142 o The test should not be subject to any alterations by externally 143 injected packets 144 o The probe packets should never be able to transit L3 node to any 145 other L3 node 147 o The level of diagnostics data should be configurable such that 148 operator is able to inject anywhere from 0.1% to 100% of test load 149 of a given max link capacity with build in automatic consideration 150 of existing average of production traffic load (unless link is 151 considered as taken out-of-service). 152 o The duration of the test traffic should be either configurable by 153 the operator or controlled by built-in detection heuristics. 154 o The frequency of the test traffic should be either configurable by 155 the operator or controlled by built-in detection heuristics. 156 o Probes should not be subject to process switching by the route 157 processors on either end of the link during the burst. 158 o The solution should strive to minimize amount of required protocol 159 extensions for as easy as possible inter-operability 160 characteristics. 161 o In the topologies where Link Aggregation is used, the aggregated 162 bandwidth of the link should be considered instead of the 163 individual links. The probe accounting should be recorded as 164 total of all link members. Probe's hashing should follow normal 165 data plane load balancing rules as configured on the directly 166 connected peering routers. 168 4. IPv4/IPv6 Special Purpose Loop Addresses 170 The mechanism for the set of proposed requirements can be constructed 171 by combining two standards based protocol elements: TTL field 172 processing and special purpose IPv4 or IPv6 loop addresses. 174 Special purpose loop address will allow to setup a scoped link based 175 loop and TTL field can be used to limit the loop duration. 177 The special purpose loop address for this purpose can be subset of 178 the link local range - 169.254/16 for IPv4 [RFC 3927] or FE80::/64 179 for IPv6 [RFC 4291] or it could be taken from an alternative pool if 180 IETF process suggests so. Selected and allocated special purpose 181 loop address would be therefor kept and maintained by IANA IPv4 or 182 IPv6 Special-Purpose Address Registries. 184 Routers must not forward any packets with loop source or destination 185 addresses to links other then the link packet arrived on. 187 The IPv4/IPv6 loop address MAY BE associated with numbered IP 188 addresses for the given link or with link local addresses. The 189 resolution to MAC address of L2 rewrites would be resolved locally 190 through corresponding L3 adjacency addresses. 192 IPv4/IPv6 test packet is directed towards L3 neighbor with even TTL 193 value. 195 5. Operation of test suite using Special Purpose IP Loop Address 197 The following is considered as a high level description of proposed 198 solution: 200 o Two routers R1 and R2 connected together by link L1 201 o Average RTT between R1 and R2 on link L1 is 5ms 202 o R1 and R2 have IP connectivity with each other on 10.10.10.0/30 203 numbered link. R1 has been configured with IP an address of 204 10.10.10.1 and R2 has been configured with an IP address of 205 10.10.10.2 206 o For the purpose of a test an IP loop address is configured on R1 207 and R2 to create local link loops. For the purpose of this 208 illustration the loop address has been named as L.O.O.P/32 210 The following IPv4 packet has been injected from R1: 212 o Source IP address: 10.10.10.1 213 o Destination IP address: L.O.O.P 214 o TTL = 254 215 o payload optional ... (to be discussed by WG) 217 Test sequence: 219 o Packet arrives at R2 and TTL is decremented following by 220 destination IP lookup and re-injection towards R1 221 o Packet keeps looping till the TTL expires on R1. 222 o Upon TTL expiration an ICMP TTL EXPIRED error message is being 223 sent to the source of the original packet (10.10.10.1). The ICMP 224 message contains the header information of the original packet 226 Observations: 228 o A test probe packet has been amplified 254 times for a short time 229 o An ICMP TTL expired message is indicative that result of the test 230 can be described as: probe packets were not dropped 231 o No ICMP TTL message implies that one copy of the original packet 232 was lost while it was looping between two routers. No reception 233 of ICMP TTL indicates potential issues with the link provided that 234 test sequence was assured never exceed agreed SLAs for a given 235 link. 236 o Ability to send multiple packets of different sizes on the link 237 with inherently controlled TTL loop can results in expected burst 238 of control/probe traffic on the link under test 239 o Such probe burst can be programmed to get to a certain % of the 240 link speed for a short time 242 Based on fine tuned testing scenario allowing to fill the bandwidth 243 up to a certain % of link capacity the count of packets originally 244 sent by router R1 should be the same as the number of ICMP TTL 245 expired messages. If the count of packets originally sent by router 246 is the same as the number of ICMP TTL expired messages then the test 247 is successful. If however the number of ICMP TTL expired messages is 248 less than the count of packets originally sent by the router then the 249 test is unsuccessful proving potential problems with the link. 251 A test probe packet with even initial TTL value will generate a TTL 252 time expired ICMP message on the originating router. A test probe 253 packet with odd initial TTL value will generate a TTL time expired 254 ICMP message on the neighboring router. It is RECOMMENDED that the 255 test probe is sent with even initial TTL value. So, ICMP messages 256 are not traversing the link under test. 258 It is RECOMMENDED that a special payload structure is used for these 259 test probes with sequence numbers. When the TTL expires and an ICMP 260 message is generated, the IP header + 64 bits from original packet 261 gets copied to ICMP message [RFC792]. This can be used for 262 associating the ICMP message and the test. 264 The MTU of the test probes can be adjusted up to maximum MTU value of 265 the link. Fragmentation of probe packets SHOULD be avoided. 267 6. Comparison with stated test requirements 269 Analysis of the proposed solution against the actual new test 270 methodology requirements: 272 o Provides means to potentially fill up the part of link bandwidth 273 very rapidly due to inherent amplification especially with high 274 initial TTL value. The fill level of the test traffic is a 275 function of: Initial packet size (higher the packet size the 276 higher the fill level), Initial TTL value (higher the TTL value, 277 higher the multiplicative factor for packets and hence higher the 278 fill level), Initial number of packets sent (the more the packets 279 sent the more the fill level) and MTU of the probe packets. 280 o Test can be run together with production traffic. There is no 281 impact on production traffic neither there is any requirement to 282 stop production traffic in order to perform the test. 283 o The amplification of the packets and looping happens as a part of 284 inherent forwarding in the routers. This solution does not 285 require a special process in software or hardware to send the test 286 probes between the two routers as special purpose loop address 287 would be part of standard FIB tables. 288 o This mechanism is light-weight and does not require any new 289 software implementations. Potential for local vendor's 290 optimizations however is still there in the area of segmenting TTL 291 equal zero errors of probes from other transit uses of TTL equal 292 zero errors or in the space of result presentation to the 293 operators. 295 7. Probe size and rate calculation 297 Initial packet size and rate are important to determine the test fill 298 level for the link. The test packet loops the same number of times 299 as the original TTL value of the original packet. The time it takes 300 for the original packet to come back to the original router is the 301 RTT (Round Trip Time) value between two routers. 303 Under the assumptions that: RTT of link under test is 1ms, link speed 304 1 Gb/s, packet size of test packet is 1536 bytes, TTL on original 305 packet is set to 254, would result in the test packets looping for 306 254 ms. 308 Under the above assumptions it is easy to calculate that in order 309 fill 1 Gb/s link to 100% 81 such probe packets need to be injected. 310 Likewise in order to fill such link to 20% of its capacity 16 probe 311 packets are required. 313 8. Probe's QOS marking 315 Since injected test packets are regular IP packets they can be marked 316 with any class of service. As a result the test probes similar to 317 actual data will be processed based on the real QoS configuration and 318 will be subject to treatment defined for a given packet class. 320 That allows both prioritization as well as de-prioritization of a 321 given set of test probes. 323 9. Bandwidth Considerations for link under test 325 The payload of the test packets can be of any IP protocol. 327 The link fill levels is also a function of Inter-packet gap of the 328 test and the RTT of that link. Deterministic fill levels can only be 329 derived by accounting for RTT of the link under test. 331 10. I2RS and YANG modelling 333 It is expected that link testing methodology described in this 334 document will be accessible by I2RS channel as well as extensions to 335 YANG models will be defined for both setting and retrieval of the 336 data. 338 11. IANA Considerations 340 This document requires IANA to allocate and maintain following 341 Special Purpose IP Addresses: 343 IPv4 Special Purpose Loop Address and maintain it the IANA IPv4 344 Special-Purpose Address Registry [RFC5735] 346 IPv6 Special Purpose Loop Address and maintain it the IANA IPv6 347 Special-Purpose Address Registry [RFC5156] 349 12. Security Considerations 351 While the proposed mechanism does not define any new protocols nor 352 protocol extensions of already existing specifications it does relay 353 on the TTL-expiry notifications. 355 Such notifications must be enabled and must not be limited in any way 356 for the specific class of probe packets. 358 It is highly recommended that test destinations LOOP addresses are 359 not routeable beyond their locally attached links. Using IPv4/IPv6 360 special purpose loop addresses will address that. 362 13. Contributors 364 Authors would like to thank Truman Boyes and Leo Pang for their 365 valuable input. 367 14. Acknowledgments 369 15. References 371 15.1. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, 375 DOI 10.17487/RFC2119, March 1997, 376 . 378 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 379 DOI 10.17487/RFC5156, April 2008, 380 . 382 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 383 RFC 5735, DOI 10.17487/RFC5735, January 2010, 384 . 386 15.2. Informative References 388 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 389 RFC 792, DOI 10.17487/RFC0792, September 1981, 390 . 392 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 393 Configuration of IPv4 Link-Local Addresses", RFC 3927, 394 DOI 10.17487/RFC3927, May 2005, 395 . 397 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 398 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 399 2006, . 401 Authors' Addresses 403 Partha Turaga 404 Bloomberg LP 405 731 Lexington Ave 406 New York City, NY 10022 407 USA 409 Email: pturaga@bloomberg.net 411 Robert Raszuk 412 Bloomberg LP 413 731 Lexington Ave 414 New York City, NY 10022 415 USA 417 Email: robert@raszuk.net