idnits 2.17.1 draft-tian-bupt-inwt-mechanism-policy-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 28, 2020) is 1459 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1157' is defined on line 590, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BUPT T. Pan 3 Internet-Draft M. Gao 4 Intended status: Informational E. Song 5 Expires: October 30, 2020 Z. Bian 6 X. Lin 7 Beijing University of Posts and Telecommunications 8 April 28, 2020 10 In-band Network-Wide Telemetry 11 draft-tian-bupt-inwt-mechanism-policy-00 13 Abstract 15 This document describes INT-path, a cost-effective network-wide 16 telemetry framework based on INT(In-band Network Telemetry), by 17 decoupling the network monitoring system into a routing mechanism and 18 a routing path generation policy. INT-path embed SR(Source Routing) 19 into INT probes to allow specifying the route that the probe packet 20 takes through the network. Above this probing path control 21 mechanism, an Euler trail-based path planning policy is developed to 22 generate non-overlapped INT paths that cover the entire network with 23 a minimum path member, reducing the overall telemetry overhead. INT- 24 path is very suitable for deployment in data center networks thanks 25 to their symmetric topologies. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14 [RFC2119][RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on October 30, 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Source Routing-based Path Monitoring (Mechanism) . . . . . . 4 71 3.1. Packet Header Format . . . . . . . . . . . . . . . . . . 5 72 3.2. Forwarding Behaviors . . . . . . . . . . . . . . . . . . 6 73 4. DFS-based path planning algorithm . . . . . . . . . . . . . . 8 74 4.1. Algorithm Outline . . . . . . . . . . . . . . . . . . . . 8 75 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5. Euler trail-based path planning algorithm . . . . . . . . . . 10 77 5.1. Algorithm Outline . . . . . . . . . . . . . . . . . . . . 10 78 5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 8.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 At present, conducting fine-grained, network-wide traffic monitoring 89 plays an increasingly significant role in maintaining large-scale 90 computer networks. It enables fine-grained network-wide visibility 91 to ease the fast detection and localization of network gray failures. 92 It also improves the network traffic load balancing with the prior 93 knowledge of link congestion. The network-wide traffic monitoring 94 can be well applied to all types of networks, especially data center 95 networks, where traffic is highly dynamic and network failures occur 96 silently, while user perception of network latency is expected to be 97 bounded. 99 In traditional network monitoring, management protocols, such as 100 SNMP(Simple Network Management Protocol)[RFC1157]are coarse-grained 101 and involve a large device query latency due to the constant 102 interaction between the control plane and the data plane. To 103 ameliorate the performance issue, INT is proposed to achieve fine- 104 grained network monitoring. INT allows packets to query device- 105 internal states such as queue depth, queuing latency when they pass 106 through the data plane pipeline, without requiring additional 107 intervention from the control plane CPU. At the last hop of the 108 path, the packet containing the end-to-end monitoring data can be 109 sent to a remote central controller for data analysis. INT can print 110 device-internal states to either specified flows of traffic or 111 additionally introduced probe packets. In this document, our 112 proposal relies on INT's probe packet mode. 114 INT is essentially an underlying primitive that need the support of 115 special hardware for device-internal state exposure. To achieve 116 network-wide traffic monitoring, INT further requires a high-level 117 orchestration built upon it. In our proposal, multiple controllable 118 probing paths are generated to monitor the entire network. To reduce 119 the telemetry overhead of additional probe packets for the original 120 network, such orchestration should be better follow the following 121 design principles: 123 o It should use non-overlapped probing paths to completely cover all 124 network edges to reduce unnecessary bandwidth occupation. 126 o It should keep the path number as small as possible to lessen the 127 processing overhead of the telemetry workload sent to the 128 controller. 130 This document addresses the problem of "In-band Network-wide 131 Telemetry", and proposes INT-path, a telemetry framework to achieve 132 lightweight network-wide traffic monitoring. Specifically, we embed 133 SR into INT probes to allow specifying the route the probe packet 134 takes through the network. Based on the routing mechanism, we design 135 two path planning policies to generate multiple non-overlapped INT 136 paths that cover the entire network. The first is based on DFS 137 (Depth-First Search) which is straightforward but computationally- 138 efficient. The second is an Euler trail-based algorithm that can 139 optimally generate non-overlapped INT paths with a minimum path 140 number. 142 2. Problem Statement 144 This document proposes INT-path to solve the following technical 145 challenges of building a network-wide telemetry system based on INT: 147 o Uncontrollable probing path. As an underlying primitive, INT only 148 defines how to extract device-internal states using probe packets. 149 However, the probe packet itself cannot proactively decide which 150 path to monitor since it does not have any path-related prior 151 knowledge. If the INT header is embedded in an IP packet, the 152 probing path will be passively decided by its destination IP 153 address together with the routing table in each network device, 154 leaving probing path totally uncontrollable by the INT packet 155 sender. Given the uncontrollable probing path, it is not easy to 156 work out purposive strategies to optimally generate multiple 157 probing paths for achieving cost-effective network-wide telemetry. 159 o Telemetry overhead. During traffic monitoring, we need 160 periodically perform the INT operation at all devices and notify 161 the controller about the underlying traffic status. However, 162 straightforwardly conducting INT at each device or device chain 163 incurs significant performance overhead: (1) INT will inject 164 probes into the network, which will occupy a fraction of link 165 bandwidth (the finer INT sampling granularity, the more bandwidth 166 will be consumed). (2) INT agents must be deployed for probe 167 generation and collection as the extra cost(the higher number of 168 separated INT paths, the more INT agents need to be deployed). 169 (3) Besides, as the INT agent number grows, the controller will 170 suffer from a performance penalty for handling increased telemetry 171 workload sent from those INT agents. 173 To tackle these problems, this document proposes INT-path, a 174 framework for network-wide telemetry, by decoupling the system into a 175 routing mechanism and a route generation policy. The underlying 176 mechanism allows network operators or INT agents to specify a 177 particular path for monitoring, addressing the uncontrollable path 178 issue (see section3 for details). The policy built upon the 179 mechanism generates multiple INT paths to cover the entire network 180 and a good policy is expected to minimize the telemetry overhead with 181 the least path overlapping as well as the minimized total path 182 number(see section4 and section5 for details). 184 3. Source Routing-based Path Monitoring (Mechanism) 186 This document addresses the uncontrollable path issue via the 187 technique of SR. Figure 1 shows the SR-based telemetry architecture 188 as well as the probe packet format. Although SR is not a new 189 technique, we innovate to couple it with the INT probe using the P4 190 language [P4] to implement user-specified or on demand path 191 monitoring. 193 |<-- Variable length -->| 194 | 22B | 195 +------+------+------+------+ 196 | INTn | .... | INT2 | INT1 | 197 +------+------+------+------+ 198 \ / 199 \ / 200 \ / 201 \ / 202 +-------+------+------+-------+-------+ 203 | ETH | IP | SR | INT | UDP | 204 +-------+------+------+-------+-------+ 205 / \ 206 / \ 207 / \ 208 / \ 209 +-------+------+-------+-------+ 210 | Portn | .... | Port2 | Port1 | 211 +-------+------+-------+-------+ 212 | 4b | 213 |<---------- 512b --------->| 215 Figure 1. Probe packet format 217 3.1. Packet Header Format 219 Theoretically, the SR label stack and the INT label stack can be 220 placed above either the IP header or the UDP header. If placed above 221 the UDP header, they need to occupy an extra port number, which is 222 likely to conflict with the port number chosen by the end hosts for a 223 certain application. While, if placed above the IP header, they only 224 occupy an IP protocol number, and then we can choose an unused 225 protocol number according to existing RFC specifications. Therefore, 226 the program chosen by this document is to place the SR label stack 227 and the INT label stack above the IP header as shown in Figure1. One 228 thing to declare is that although we design a customized header 229 format as follows for the probe packets, the network devices can 230 still correctly forward these packets provided that protocol- 231 independent forwarding is supported. 233 o DP: DP means Destination Port which is set to "SR_INT_PORT" to 234 inform the packet parser that it is an SR-INT probe(i.e., INT 235 probe packet with an SR label stack). 237 o DIP: DIP means destination IP address of the probe packet which is 238 set using controller's IP to guarantee that the probe packet will 239 finally be forwarded to the controller for further analysis. 241 o SR: A 512-bit space is reserved for the SR label stack above the 242 IP header. A 4-bit space is allocated for each SR label to denote 243 the router output port ID thus can maximally support 16 output 244 ports for each router. 246 o INT: Above the fixed-length SR label stack, a variable-length INT 247 label stack is allocated. Each INT label occupies 22B containing 248 the information such as device ID, ingress/egress port, egress 249 queue depth. Since P4 currently does not well support parsing 250 double variable length stacks in the packet header, the SR label 251 stack with a fixed length is statically allocated and the right 252 shift operation is used to perform the "stack pop" behavior. 254 3.2. Forwarding Behaviors 256 In the SR-based telemetry architecture, three types of logic routers 257 are proposed with different functionalities: the INT generator, the 258 INT forwarder and the INT collector(as shown in Figure 2). 260 +--------+ +--------+ 261 |End Host| |End Host| 262 +--------+ +--------+ 263 | | 264 | | 265 +---------+ +---------+ 266 | INT | | INT | 267 |generator| |collector| 268 +---------+ +---------+ 269 | | +---------+ | | 270 | | | INT | | | 271 | | |forwarder| | | 272 | | +---------+ | | 273 | | / \ | | 274 | | / \ | | 275 | +---------+ +---------+ | 276 | | INT | | INT | | 277 | |forwarder| |forwarder| | 278 | +---------+ +---------+ | 279 | \ / | 280 | \ / | 281 | +---------+ | 282 | | INT | | 283 | |forwarder| | 284 | +---------+ | 285 | | 286 +-------------------------------------------+ 287 | Controller | 288 +-------------------------------------------+ 290 Figure 2. Source routing-based path monitoring 292 o INT generator: The INT generator is responsible for spawning the 293 SR-INT probe packets at the first hop of the monitoring path. 294 Since packet generation directly from the data plane is currently 295 undefined in P4, we consider a workaround to periodically generate 296 "empty" probes from the outside by either the router/switch CPU or 297 a host attached to the network device. When the probe arrives at 298 the data plane, the INT generator will rewrite its packet header 299 to allocate the SR label stack and add its local INT information 300 using header.setValid() in P4 before forwarding the packet. 301 Specifically, the INT generator will push the output port IDs into 302 the SR label stack in the packet header. The sequence of the 303 output port IDs (i.e., how to forward the packet across the 304 network) is predetermined at the controller via centralized route 305 calculation. 307 o INT forwarder: The INT forwarder performs packet forwarding of 308 either the SR-INT probes or the background traffic, according to 309 the DP number of the incoming traffic. If the DP is 310 "SR_INT_PORT", the INT forwarder will perform label switching and 311 forward the packet only according to the output port ID popped 312 from the SR label stack. The SR label is popped once at a router 313 by right shifting the SR header by 4 bits at each hop. Besides, 314 the INT forwarder will also push its local INT information into 315 the INT label stack before forwarding the probe. 317 o INT collector: At the last hop of the monitoring path, since the 318 DIP is filled with controller's IP address, the INT collector will 319 finally forward the probe packet to the controller for further 320 analysis. 322 4. DFS-based path planning algorithm 324 4.1. Algorithm Outline 326 In this section, we propose a simple algorithm based on DFS. 328 When traversing a tree or a graph, DFS starts at the root and 329 explores as far as possible along each branch before backtracking. 330 The basic idea of the DFS-based path planning algorithm is to 331 consecutively add the visited vertices into the current path before 332 backtracking; if we have nowhere to go and have to backtrack, we just 333 create a new path and add the fork vertex (the first vertex along the 334 backtracking path that has unvisited edges) as the first node of the 335 new path. After all the edges are visited in the DFS order, we can 336 extract multiple non-overlapped paths covering the entire graph. 338 A recursive version of the DFS-based path planning algorithm is as 339 follows: 341 o Step1: Choose v0 as the first vertex of the depth-first traversal 342 and start the algorithm. 344 o Step2: Select one of v0's adjacency vertices v1 and mark the edge 345 between v0 and v1 as visited, add v0 and v1 into the current INT 346 path; continue to search for v1's adjacency vertex v2 and mark the 347 edge between v1 and v2 as visited, add v2 into the current INT 348 path; continue to search for v2's adjacency vertex v3 and mark the 349 edge between v2 and v3 as visited, add v3 into the current INT 350 path; and continue until a vertex vi has no adjacency vertices 351 that has unvisited edges, then mark the vertex vi as visited, and 352 store the current INT path into set INT path. 354 o Step3: Backtrack at the visited vertex vi until a previous vertex 355 that has unvisited edges is found, and find an adjacency vertex of 356 the previous vertex and mark the edge between them as visited, 357 then add the previous vertex and the adjacency vertex into a new 358 current INT path, that is, continue as step2. If all the 359 adjacency vertices of the previous vertex have been accessed, then 360 mark the previous vertex as visited. Step3 continues until all of 361 the vertices that are reachable by backtracking from vi are 362 visited. 364 o Step4: If there are any unvisited vertices, this algorithm selects 365 one of them as a new source and repeats step2 and step3 from that 366 vertex. Step4 continues until every edge and every vertex has 367 been visited. Then the set INT path is the multiple non- 368 overlapped paths covering the entire graph. 370 4.2. Example 372 We show an algorithm example on a network graph of five devices as 373 shown in Figure 3. 375 +----+ +----+ +----+ 376 | v0 |-----| v1 |-----| v2 | 377 +----+ +-+--+ +--+-+ 378 | / | 379 | / | 380 | / | 381 | / | 382 | / | 383 +-+--+ +--+-+ 384 | v3 |-----| v4 | 385 +----+ +----+ 387 Figure 3. Depth-first graph traversal 389 At the beginning, v0 is pushed into the call stack, path1 = {v0, v1} 390 and the edge between v0 and v1 is marked as visited. The path1 391 expands as more and more vertices are visited in the DFS order. When 392 path1 expands to {v0, v1, v2, v3, v1}, we have nowhere to go and have 393 to find the fork vertex. At this time, we pop v1 from the stack and 394 return to v3, which has an unvisited edge to v4 (notice that the call 395 stack push/pop operations are implicitly performed during recursion). 396 Then, we identify v3 as the fork vertex because it is the first 397 vertex along the backtracking path that has unvisited edges. Based 398 on v3, we create a new path as path2 = {v3, v4}. When path2 expands 399 to {v3, v4, v2}, we have again nowhere to go and have to backtrack. 400 But at this time, although we check all the vertices popped from the 401 call stack, we still cannot find any fork vertex. The recursion 402 halts when the call stack finally becomes empty. At last, we extract 403 two non-overlapped INT probing paths (i.e., path1 and path2). 405 5. Euler trail-based path planning algorithm 407 5.1. Algorithm Outline 409 Although the DFS-based path planning algorithm is computationally- 410 efficient, it has no guarantee to minimize the number of generated 411 paths, which will potentially increase the telemetry overhead, 412 especially the telemetry workload at the centralized. Here, we 413 propose an optimal path planning algorithm taking advantage of the 414 mathematical properties of the Euler trail/circuit. 416 In fact, the mathematical properties of the Euler trail/circuit 417 already indicated the theoretical value of the minimum non-overlapped 418 path number for covering a given graph. To achieve the theoretical 419 minimum, each extracted path from a graph should start from one odd 420 vertex and end at another odd vertex. In other words, removing one 421 such path from a graph will eliminate a pair of odd vertices from 422 that graph. According to the above observation, we devise an Euler 423 trail-based algorithm to iteratively extract a path between a pair of 424 odd vertices until all the vertices/edges are extracted from the 425 original graph. 427 Although the algorithm sounds rather straightforward as an iterative 428 path extraction process, the devil lies in the detail of dealing with 429 several boundary cases. To be more specific, the devil lies in the 430 possibility that an extracted path can split one connected graph into 431 multiple subgraphs, which definitely complicates the iterative path 432 extraction process. 434 Next we explain the optimal algorithm in detail. We use G to 435 represent the network graph, which is initialized to be one connected 436 graph and may also become multiple disconnected subgraphs caused by 437 path extraction during algorithm iteration. We use Q to represent 438 the path set which is initialized as an empty set and will finally 439 contain the generated non-overlapped INT paths. We use G-p to 440 represent extracting a path p from the graph G which will possibly 441 further split the graph(s) G into more subgraphs. 443 Actually, without considering the complexity of graph split, for a 444 given connected graph, there are mainly three different cases for 445 path extraction. We propose solutions in each of these three cases 446 as follows: 448 o The first case is: The graph does not contain any odd vertex. We 449 can extract an Euler circuit from the graph, which will traverse 450 every vertex of the graph. The Euler circuit can be found with 451 the Hierholzer's algorithm [Hierholzer] and inserted into Q. The 452 Hierholzer's algorithm is an efficient algorithm for finding Euler 453 trails and Euler circuits. 455 o The second case is: The graph contains two odd vertices. We just 456 find an Euler trail between the two odd vertices as the path to be 457 extracted. Under this circumstance, an Euler trail can also be 458 found with the Hierholzer's algorithm and inserted into Q. 460 o The last case is: The graph contains more than two odd vertices. 461 We should extract an Euler trail between any pair of odd vertices. 462 In this case, the specific algorithm is as follows: 464 Step1: If G is not empty, perform the following steps. Otherwise 465 the algorithm terminates. 467 Step2: Choose two odd vertices randomly and find a path p to 468 connect the pair of odd vertices with the Dijkstra's algorithm or 469 any other algorithms. Then delete the edges along path p from G, 470 and add path p into Q. After this, if the graph(s) in G have been 471 broken into multiple disconnected subgraphs, then go to step3. If 472 the graph in G has not been broken into multiple disconnected 473 subgraphs, then go to step1. 475 Step3: Use S to store the disconnected subgraphs split from G. 476 Then, select graphs with no odd vertex from S and store them into 477 T. If neither set T nor set Q is an empty set, then go to step4. 478 If set T is not empty and set Q is empty, each subgraph in the set 479 T is processed in the same way as in the first case, that is, 480 using Hierholzer's algorithm to extract an Euler circuit from the 481 subgraph, then delete the edges along the Euler circuit from G and 482 add the Euler circuit into Q. For each subgraph in set S, if it 483 has two odd vertices, the subgraph is processed in the same way as 484 in the second case, that is, using Hierholzer's algorithm to find 485 an Euler trail between the two odd vertices as the path to be 486 extracted, then delete the edges along the Euler trail from G and 487 add the Euler trail into Q. For each subgraph in set S, if it has 488 more than two odd vertices, then go to step2. 490 Step4: For each graph in set T, generate an Euler circuit 491 T_circuit for its full edge coverage. Then search the current Q 492 to find a path T_path having at least a same vertex with 493 T_circuit. Then, connect T_circuit with T_path to create a longer 494 new path, and replace the original T_path with the new path in Q, 495 and delete the edges along path T_circuit from G. 497 5.2. Example 499 Figure 4 shows a path extraction process of the Euler trail-based 500 algorithm. At the start, there is only one connected graph G1 501 {1,2,3,4,5,6,7} with 4 odd vertices. Since the number of the odd 502 vertices is larger than 2, we randomly choose two odd vertices (1 and 503 3), extract a path 1-4-3 from G1 and insert the path into Q. The 504 above path extraction behavior will split the original G1 into two 505 subgraphs G1 {1,2,3} and G2 {4,5,6,7}. Since G1 has no odd vertex 506 and set Q is not empty, we paste the path 1-4-3 in Q with the Euler 507 circuit 1-2-3-1 generated from G1 to create a new path 1-2-3-1-4-3. 508 The new path will replace the original path 1-4-3 in Q. After the 509 path paste, there is only one graph G1 {4,5,6,7} with 2 odd vertices. 510 We use the Hierholzer's algorithm to find its Euler trail 5-4-6-5-7-6 511 as the second INT path in Q. The algorithm halts after all the paths 512 are extracted. 514 +----+3+----+ +----+6+----+ 515 / + \ / + \ 516 + | + | + 517 2 | 4 | 7 518 + | + | + 519 \ + / \ + / 520 +----+1+----+ +----+5+----+ 521 (a) 522 G1={1,2,3,4,5,6,7}; 523 S={G1}, T=Empty; 524 odd_num=4>2; 525 Q={1-4-3}; 527 +----+3 +----+6+----+ 528 / + / + \ 529 + | + | + 530 2 | 4 | 7 531 + | + | + 532 \ + \ + / 533 +----+1 +----+5+----+ 534 (b) 535 G1={1,2,3},G2={4,5,6,7}; 536 S={G1,G2}, T={G1}; 537 T_path=1-4-3,T_circuit=1-2-3-1; 538 path=1-2-3-1-4-3; 539 Q={1-2-3-1-4-3}; 541 +----+6+----+ 542 / + \ 543 + | + 544 4 | 7 545 + | + 546 \ + / 547 +----+5+----+ 548 (c) 549 G1={4,5,6,7}; 550 S={G2}, T=Empty; 551 odd_num=2; 552 Q={1-2-3-1-4-3,5-4-6-5-7-6}; 554 Figure 4. Path extraction process of the Euler trail-based algorithm 556 6. IANA Considerations 558 This document introduces no new security issues. 560 7. Security Considerations 562 This document makes no request of IANA. 564 8. References 566 8.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, 570 DOI 10.17487/RFC2119, March 1997, 571 . 573 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 574 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 575 May 2017, . 577 8.2. Informative References 579 [Hierholzer] 580 Hierholzer, H. and W. Wiener, "Ueber die Moeglichkeit, 581 einen Linienzug ohne Wiederholung und ohne Unterbrechung 582 zu umfahren", March 1873, 583 . 585 [P4] Bosshart, P., Daly, D., Gibb, G., Izzard, M., McKeown, N., 586 Rexford, J., Schlesinger, C., and D. Talayco, "P4: 587 programming protocol-independent packet processors", July 588 2014, . 590 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 591 "Simple Network Management Protocol (SNMP)", RFC 1157, 592 DOI 10.17487/RFC1157, May 1990, 593 . 595 Authors' Addresses 597 Tian Pan 598 Beijing University of Posts and Telecommunications 599 Beijing 600 China 602 Email: pan@bupt.edu.cn 603 Minglan Gao 604 Beijing University of Posts and Telecommunications 605 China 607 Email: gml@bupt.edu.cn 609 Enge Song 610 Beijing University of Posts and Telecommunications 611 China 613 Email: songenge@bupt.edu.cn 615 Zizheng Bian 616 Beijing University of Posts and Telecommunications 617 China 619 Email: zizheng_bian@bupt.edu.cn 621 Xingchen Lin 622 Beijing University of Posts and Telecommunications 623 China 625 Email: linxchen3907@163.com