idnits 2.17.1 draft-geib-ippm-connectivity-monitoring-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 (July 4, 2019) is 1756 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm R. Geib, Ed. 3 Internet-Draft Deutsche Telekom 4 Intended status: Standards Track July 4, 2019 5 Expires: January 5, 2020 7 A Connectivity Monitoring Metric for IPPM 8 draft-geib-ippm-connectivity-monitoring-01 10 Abstract 12 Segment Routed measurement packets can be sent along pre-determined 13 paths. This allows new kinds of measurements. Connectivity 14 monitoring allows to supervise the state of a connection or a 15 (sub)path from one or a few central monitoring systems. This 16 document specifies a suitable type-P connectivity monitoring metric. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 5, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. A brief segment routing connectivity monitoring framework . . 4 55 3. Singleton Definition for Type-P-SR-Path-Connectivity-and- 56 Congestion . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7 59 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 8 60 3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 8 63 3.7. Errors and Uncertainties . . . . . . . . . . . . . . . . 10 64 3.8. Reporting the Metric . . . . . . . . . . . . . . . . . . 10 65 4. Singleton Definition for Type-P-SR-Path-Round-Trip-Delay- 66 Estimate . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 7.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 Segment Routing enables sending measurement packets along pre- 77 determined segment routed paths [RFC8402]. A segment routed path may 78 consist of pre-determined sub paths down to specific router- 79 interfaces. It may also consist of sub paths spanning multiple 80 routers, given that all segments to address a desired path are 81 available and known at the SR domain edge interface. 83 A Path Monitoring System or PMS (see [RFC8403]) is a dedicated rather 84 central Segment Routing domain monitoring device (as compared to a 85 distributed monitoring approach based on router data and functions 86 only). Monitoring individual sub-paths or point-to-point connections 87 is executed for different purposes. IGP routing exchanges hello 88 messages between neighbors to keep alive routing and switfly adapt to 89 changes. Network Operators may be interested in monitoring 90 connectivity and lasting congestion of interfaces or sub-paths at a 91 higher timescale,e.g., on the order of seconds. This is still 92 significantly faster than interface monitoring based on router 93 information, which may be collected on a minute timescale to reduce 94 the CPU load caused by monitoring. 96 The IPPM architecture was a first step to that direction [RFC2330]. 97 Commodity IPPM solutions require dedicated measurement systems, a 98 large number of measurement agents and synchronised clocks. 99 Monitoring a domain from edge to edge by commodity IPPM solutions 100 helps to increase scalability of the monitoring system, but 101 localising a source cause of a detected change in network behaviour 102 then may require network tomography methods. 104 The IPPM Metrics for Measuring Connectivity offer generic 105 connectivity metrics [RFC2678]. These metrics allow to measure 106 connectivity between end nodes without making any assumption on the 107 paths between them. The metric and the type-p packet specified by 108 this document follow a different approach: they are designed to 109 monitor connectivity of a specific single link or a path segment. 110 The underlying definition of connectivity is partially the same, a 111 packet not reaching a destination indicates a loss of connectivity. 112 An IGP re-route may indicate a loss of a link, while it might not 113 cause loss of connectivity beween end systems. The metric specified 114 here is able to detect the loss of a link, if the change in end-to- 115 end delay along a new route are differing from that of the original 116 path. 118 A Segment Routing PMS which is part of an SR domain is IGP topology 119 aware, covering the IP and (if present) the MPLS layer topology 120 [RFC8402]. This allows to design a PMS which can steer packets along 121 arbitrary pre-determined concatenated sub-paths, identified by 122 suitable segments. Combining the SR measurement path configuration 123 with a priori network tomography assumptions and methods allows for 124 localisation of detected changes. The latter requires setting up 125 multiple measurement paths which share sub-paths following the 126 constraints derived from network tomography, and a suitable 127 evaluation of measurement results. 129 This document specifies a type-p metric determining properties of an 130 SR path which allows to monitor connectivity and congestion of 131 interfaces and further allows to locate the path or interface which 132 caused a change in the reported type-p metric. This document is 133 focussed on the MPLS layer, but the methodolgy may be applied within 134 SR domains or MPLS domains in general. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2. A brief segment routing connectivity monitoring framework 144 The Segment Routing IGP topology information consists of the IP and 145 (if present) the MPLS layer topology. The minimum SR topology 146 information consists of Node-Segment-Identifiers (Node-SID), 147 identifying an SR router. The IGP exchange of Adjacency-SIDs [I- 148 D.draft-ietf-isis-segment-routing-extensions], which identify local 149 interfaces to adjacent nodes, is optional. It is RECOMMENDED to 150 distribute Adj-SIDs in a domain operating a PMS to monitor 151 connectivity as specified below. If Adj-SIDs aren't availbale, 152 [RFC8029] provides methods how to steer packets along desired paths 153 by the proper choice of an MPLS Echo-request IP-destination address. 154 A detailed description of [RFC8029] methods as a replacement of Adj- 155 SIDs is out of scope of this document. 157 A round trip measurement between two adjacent nodes is a simple 158 method to monitor connectivity of a connecting link. If multiple 159 links are operational between two adjacent nodes and only a single 160 one fails, a single plain round trip measurement may fail to identify 161 which link has failed. A round trip measurement also fails to 162 identify which inteface is congested, even if only a single link 163 connects two adjacent nodes. 165 Segment Routing enables the set-up of extended measurement loops. 166 Several different measurement loops can be set up. If these form a 167 partial overlay, any change in the network properties impacts more 168 than a single loops round trip time (or causes drops of packets of 169 more than one loop). Randomly chosen loop paths including the 170 interfaces or paths to be monitored may fail to produce unique result 171 patterns. The approach picked here uses specified measurement loop 172 and path overlay design. A centralised monitoring approach benefits 173 from keeping the number of required measurement loops low. This 174 improves scalability by minimising the number of measurement loops. 175 This also keeps the number of required packets and results to be 176 evaluated and correlated low. 178 An additional property of the measurement path set-up specified below 179 is that it allows to estimate the packet round trip and the one way 180 delay of a monitored link (or path). The delay along a single link 181 is not perfectly symmetric. Packet processing causes small delay 182 differences per interface and direction. These cause an error, which 183 can't be quantified or removed by the specified method. Quantifying 184 this error requires a different measurement set-up. As this will 185 introduce additional measurements loops, packets and evaluations, the 186 cost in terms of reduced scalability is not felt to be worth the 187 benefit in measurement accuracy. IPPM however honors precision more 188 than accuracy and the mentioned processing differences are relatively 189 stable, resulting in relatively precise delay estimates. 191 An example SR domain is shown below. The PMS shown should monitor 192 the connectivity of all 6 links between nodes L100 and L200 one one 193 side and the connected nodes L050, L060 and L070 on the other side. 194 The round trip times per measurement loop are assumed to exhibit 195 unique delays. 197 +---+ +----+ +----+ 198 |PMS| |L100|-----|L050| 199 +---+ +----+\ /+----+ 200 | / \ \_/_____ 201 | / \ / \+----+ 202 +----+/ \/_ +----|L060| 203 |L300| / |/ +----+ 204 +----+\ / /\_ 205 \ / / \ 206 \+----+ / +----+ 207 |L200|-----|L070| 208 +----+ +----+ 210 Connectivity verification with a PMS 212 Figure 1 214 The SID values are picked for convenient reading only. Node-SID: 100 215 identifies L100, Node-SID: 300 identifies L300 and so on. Adj-SID 216 10050: Adjacency L100 to L050, Adj-SID 10060: Adjacency L100 to L060, 217 Adj-SID 60200: Adjacency L60 to L200 219 Monitoring the 6 links between Ln00 and L0m0 nodes requires 6 220 measurement loops, each of which has the following properties: 222 o Each loop follows a single round trip from one Ln00 to one L0m0 223 (e.g., between L100 and L050). 225 o Each loop passes two more links: one between that Ln00 and another 226 L0m0 and from there to the other Ln00 (e.g., between L100 and L060 227 and then L060 to L200) 229 o Every link is passed by a single round trip per measurement loop 230 only once and only once unidirectional by two other loops, and the 231 latter two pass along opposing directions (that's three loops 232 passing each single link, e.g., one having a round trip L100 to 233 L050 and back, a second passing L100 to L050 only and a third loop 234 passing L050 to L100 only). 236 Note that any 6 links between two to six nodes can be monitored that 237 way too (if multiple parallel links between two nodes are monitored, 238 the differences in delay may require a sufficiently high clock 239 resulotion, if applicable). 241 This results in 6 measurement loops for the given example (the start 242 and end of each measurement loop is PMS to L300 to L100 or L200 and a 243 similar sub-path on the return leg. It is ommitted here for 244 brevity): 246 1. M1 is the delay along L100 -> L050 -> L100 -> L060 -> L200 248 2. M2 is the delay along L100 -> L060 -> L100 -> L070 -> L200 250 3. M3 is the delay along L100 -> L070 -> L100 -> L050 -> L200 252 4. M4 is the delay along L200 -> L050 -> L200 -> L060 -> L100 254 5. M5 is the delay along L200 -> L060 -> L200 -> L070 -> L100 256 6. M6 is the delay along L200 -> L070 -> L200 -> L050 -> L100 258 An example for a stack of a loop consisting of Node-SID segments 259 allowing to caprture M1 is (top to bottom): 100 | 050 | 100 | 060 | 260 200 | PMS. 262 An example for a stack of Adj-SID segments the loop resulting in M1 263 is (top to bottom): 100 | 10050 | 50100 | 10060 | 60200 | PMS. As 264 can be seen, the Node-SIDs 100 and PMS are present at top and bottom 265 of the segment stack. Their purpose is to transport the packet from 266 the PMS to the start of the measurement loop at L100 and return it to 267 the PMS from its end. 269 The measurement loops set up as shown have the following properties: 271 o If the loops are set up using Node-SIDs only, any single complete 272 loss of connectivity caused by a failing single link between any 273 Ln00 and any L0m0 node briefly disturbs (and changes the measured 274 delay) of three loops. Traffic to Node-SIDs is rerouted. 276 o If the loops are set up using Adj-SIDs only (and Node-SIDs only to 277 send the packet from PMS to the loop starting point and from the 278 loop end back to the PMS), any single complete loss of 279 connectivity caused by a failing single link between any Ln00 and 280 any L0m0 node terminates the traffic along three loops. The 281 packets of these loops will be dropped, until the link gets back 282 into service. Traffic to Adj-SIDs is not rerouted. 284 o Any congested single interface between any Ln00 and any L0m0 node 285 only impacts the measured delay of two measurement loops. 287 o As an example, the formula for a single Round Trip Delay (RTD) is 288 shown here 4 * RTD_L100-L050-L100 = 3 * M1 + M3 + M6 - M2 - M4 - 289 M5 291 A closer look reveals that each single event of interest for the 292 proposed metric, which are a loss of connectivity or a case of 293 congestion, uniquely only impacts a single a-priori determinable set 294 of measurement loops. If, e.g., connectivity is lost between L200 295 and L050, measurement loops (3), (4) and (6) indicate a change in the 296 measured delay. 298 As a second example, if the interface L070 to L100 is congested, 299 measurement loops (3) and (5) indicate a change in the measured 300 delay. Without listing all events, all cases of single losses of 301 connectivity or single events of congestion influence only delay 302 measurements of a unique set of measurement loops. 304 A congestion event adding latency to two specific measurement loops 305 allows calculation of the delay added by the queue at the congested 306 interface. Thus, the resulting RTD increase can be assigned to a 307 single interface. 309 3. Singleton Definition for Type-P-SR-Path-Connectivity-and-Congestion 311 3.1. Metric Name 313 Type-P-SR-Path-Connectivity-and-Congestion 315 3.2. Metric Parameters 317 o Src, the IP address of a source host 319 o Dst, the IP address of a destination host if IP routing is 320 applicable; in the case of MPLS routing, a diagnostic address as 321 specified by [RFC8029] 323 o T, a time 325 o lambda, a rate in reciprocal seconds 327 o L, a packet length in bits. The packets of a Type P packet stream 328 from which the sample Path-Connectivity-and-Congestion metric is 329 taken MUST all be of the same length. 331 o MLA, a Monitoring Loop Address information ensuring that a 332 singleton passes a single sub-path_a to be monitored 333 bidirectional, a sub-path_b to be monitored unidirectional and a 334 sub-path_c to be monitored unidirectional, where sub-path_a, -_b 335 and -_c MUST NOT be identical. 337 o P, the specification of the packet type, over and above the source 338 and destination addresses 340 o DS, a constant time interval between two type-P packets 342 3.3. Metric Units 344 A sequence of consecutive time values. 346 3.4. Definition 348 A moving average of AV time values per measurement path is compared 349 by a change point detection algorithm. The temporal packet spacing 350 value DS represents the smallest period within which a change in 351 connectivity or congestion may be detected. 353 A single loss of connectivity of a sub-path between two nodes affects 354 three different measurement paths. Depending on the value chosen for 355 DS, packet loss might occur (note that the moving average evaluation 356 needs to span a longer period than convergence time; alternatively, 357 packet-loss visible along the three measurement paths may serve as an 358 evaluation criterium). After routing convergence the type-p packets 359 along the three measurement paths show a change in delay. 361 A congestion of a single interface of a sub-path connecting two nodes 362 affects two different measurement paths. The the type-p packets 363 along the two congested measurement paths show an additional change 364 in delay. 366 3.5. Discussion 368 Detection of a multiple losses of monitored sub-path connectivity or 369 congestion of a multiple monitored sub-paths may be possible. These 370 cases have not been investigated, but may occur in the case of Shared 371 Risk Link Groups. Monitoring Shared Risk LinkGroups and sub-paths 372 with multiple failures abd congestion is not within scope of this 373 document. 375 3.6. Methodologies 377 For the given type-p, the methodology is as follows: 379 o The set of measurement paths MUST be routed in a way that each 380 single loss of connectivity and each case of single interface 381 congestion of one of the sub-paths passed by a type-p packet 382 creates a unique pattern of type-p packets belonging to a subset 383 of all configured measurement paths indicate a change in the 384 measured delay. As a minimum, each sub-path to be monitored MUST 385 be passed 387 o 389 * by one measurement_path_1 and its type-p packet in 390 bidirectional direction 392 * by one measurement_path_2 and its type-p packet in "downlink" 393 direction 395 * by one measurement_path_3 and its type-p packet in "uplink" 396 direction 398 o "Uplink" and "Downlink" have no architectural relevance. The 399 terms are chosen to express, that the packets of 400 measurement_path_2 and measuremnt_path_3 pass the monitored sub- 401 path unidirectional in opposing direction. Measuremnt_path_1, 402 measurement_path_2 and measurement_path_3 MUST NOT be identical. 404 o All measurement paths SHOULD terminate between identical sender 405 and receiver interfaces. It is recommended to connect the sender 406 and receiver as closely to the paths to be monitored as possible. 407 Each intermediate sub-path between sender and receiver one one 408 hand and sub-paths to be monitored is an additional source of 409 errors requiring separate monitoring. 411 o Segment Routed domains supporting Node- and Adj-SIDs should enable 412 the monitoring path set-up as specified. Other routing protocols 413 may be used as well, but the monitoring path set up might be 414 complex or impossible. 416 o Pre-compute how the two and three measurement path delay changes 417 correlate to sub-path connectivity and congestion patterns. 418 Absolute change valaues aren't required, a simultaneous change of 419 two or three particular measurement paths is. 421 o Ensure that the temporal resolution of the measurement clock 422 allows to reliably capture a unique delay value for each 423 configured measurement path while sub-path connectivity is 424 complete and no congestion is present. 426 o Synchronised clocks are not strictly required, as the metric is 427 evaluating differences in delay. Changes in clock synchronisation 428 SHOULD NOT be close to the time interval within which changes in 429 connectivity or congestion should be monitored. 431 o At the Src host, select Src and Dst IP addresses, and address 432 information to route the type-p packet along one of the configured 433 measurement path. Form a test packet of Type-P with these 434 addresses. 436 o Configure the Dst host access to receive the packet. 438 o At the Src host, place a timestamp, a sequence number and a unique 439 identifier of the measurement path in the prepared Type-P packet, 440 and send it towards Dst. 442 o Capture the one-way delay and determine packet-loss by the metrics 443 specified by [RFC7679] and [RFC7680] respectively and store the 444 result for the path. 446 o If two or three subpaths indicate a change in delay, report a 447 change in connectivity or congestion status as pre-computed above. 449 o If two or three sub paths indicate a change in delay, report a 450 change in connectivity or congestion status as pre-computed above. 452 Note that monitoring 6 sub paths requires setting up 6 monitoring 453 paths as shown in the figure above. 455 3.7. Errors and Uncertainties 457 Sources of error are: 459 o Measurement paths whose delays don't indicate a change after sub- 460 path connectivity changed. 462 o A timestamps whose resolution is missing or inacurrate at the 463 delays measured for the different monitoring paths. 465 o Multiple occurrences of sub path connectivity and congestion. 467 o Loss of connectivity and congestion along sub-paths connecting the 468 measurement device(s) with the sub-paths to be monitored. 470 3.8. Reporting the Metric 472 The metric reports loss of connectivity of monitored sub-path or 473 congestion of an interface and identifies the sub-path and the 474 direction of traffic in the case of congestion. 476 4. Singleton Definition for Type-P-SR-Path-Round-Trip-Delay-Estimate 478 This section will be added in a later version, if there's interest in 479 picking up this work. 481 5. IANA Considerations 483 If standardised, the metric will require an entry in the IPPM metric 484 registry. 486 6. Security Considerations 488 This draft specifies how to use methods specified or described within 489 [RFC8402] and [RFC8403]. It does not introduce new or additional SR 490 features. The security considerations of both references apply here 491 too. 493 7. References 495 7.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 503 Connectivity", RFC 2678, DOI 10.17487/RFC2678, September 504 1999, . 506 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 507 Ed., "A One-Way Delay Metric for IP Performance Metrics 508 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 509 2016, . 511 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 512 Ed., "A One-Way Loss Metric for IP Performance Metrics 513 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 514 2016, . 516 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 517 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 518 Switched (MPLS) Data-Plane Failures", RFC 8029, 519 DOI 10.17487/RFC8029, March 2017, 520 . 522 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 523 Decraene, B., Litkowski, S., and R. Shakir, "Segment 524 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 525 July 2018, . 527 7.2. Informative References 529 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 530 "Framework for IP Performance Metrics", RFC 2330, 531 DOI 10.17487/RFC2330, May 1998, 532 . 534 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 535 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 536 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 537 2018, . 539 Author's Address 541 Ruediger Geib (editor) 542 Deutsche Telekom 543 Heinrich Hertz Str. 3-7 544 Darmstadt 64295 545 Germany 547 Phone: +49 6151 5812747 548 Email: Ruediger.Geib@telekom.de