[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
BUPT                                                              T. Pan
Internet-Draft                                                    M. Gao
Intended status: Informational                                   E. Song
Expires: April 28, 2021                                          Z. Bian
                                                                  X. Lin
                      Beijing University of Posts and Telecommunications
                                                        October 25, 2020


                     In-band Network-Wide Telemetry
                draft-tian-bupt-inwt-mechanism-policy-01

Abstract

   This document describes INT-path, a cost-effective network-wide
   telemetry framework based on INT (In-band Network Telemetry), by
   decoupling the network monitoring system into a routing mechanism and
   a routing path generation policy.  INT-path embeds SR (Source
   Routing) into INT probes to allow specifying the route that the probe
   packet takes through the network.  Above this probing path control
   mechanism, an Euler trail-based path planning policy is developed to
   generate non-overlapped INT paths that cover the entire network with
   a minimum path number, reducing the overall telemetry overhead.  INT-
   path is very suitable for deployment in data center networks thanks
   to their symmetric topologies.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."



Pan, et al.              Expires April 28, 2021                 [Page 1]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


   This Internet-Draft will expire on April 28, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Source Routing-based Path Monitoring (Mechanism)  . . . . . .   4
     3.1.  Packet Header Format  . . . . . . . . . . . . . . . . . .   5
     3.2.  Forwarding Behaviors  . . . . . . . . . . . . . . . . . .   6
   4.  DFS-based path planning algorithm . . . . . . . . . . . . . .   8
     4.1.  Algorithm Outline . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Euler trail-based path planning algorithm . . . . . . . . . .  10
     5.1.  Algorithm Outline . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   At present, conducting fine-grained, network-wide traffic monitoring
   plays an increasingly significant role in maintaining large-scale
   computer networks.  It enables fine-grained network-wide visibility
   to ease the fast detection and localization of network gray
   failures[Jia].  It also improves the network traffic load balancing
   with the prior knowledge of link congestion.  The network-wide
   traffic monitoring can be well applied to all types of networks,
   especially data center networks, where traffic is highly dynamic and




Pan, et al.              Expires April 28, 2021                 [Page 2]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


   network failures occur silently, while user perception of network
   latency is expected to be bounded.

   In traditional network monitoring, management protocols, such as SNMP
   (Simple Network Management Protocol)[RFC1157]are coarse-grained and
   involve a large device query latency due to the constant interaction
   between the control plane and the data plane.  To ameliorate the
   performance issue, INT is proposed to achieve fine-grained network
   monitoring.  INT allows packets to query device-internal states such
   as queue depth, queuing latency when they pass through the data plane
   pipeline, without requiring additional intervention from the control
   plane CPU.  At the last hop of the path, the packet containing the
   end-to-end monitoring data can be sent to a remote central controller
   for data analysis.  INT can print device-internal states to either
   specified flows of traffic or additionally introduced probe packets.
   In this document, our proposal relies on INT's probe packet mode.

   INT is essentially an underlying primitive that need the support of
   special hardware for device-internal state exposure.  To achieve
   network-wide traffic monitoring, INT further requires a high-level
   orchestration built upon it.  In our proposal, multiple controllable
   probing paths are generated to monitor the entire network.  To reduce
   the telemetry overhead of additional probe packets for the original
   network, such orchestration should be better follow the following
   design principles:

   o  It should use non-overlapped probing paths to completely cover all
      network edges to reduce unnecessary bandwidth occupation.

   o  It should keep the path number as small as possible to lessen the
      processing overhead of the telemetry workload sent to the
      controller.

   This document addresses the problem of "In-band Network-wide
   Telemetry", and proposes INT-path, a telemetry framework to achieve
   lightweight network-wide traffic monitoring.  Specifically, we embed
   SR into INT probes to allow specifying the route the probe packet
   takes through the network.  Based on the routing mechanism, we design
   two path planning policies to generate multiple non-overlapped INT
   paths that cover the entire network.  The first is based on DFS
   (Depth-First Search) which is straightforward but computationally-
   efficient.  The second is an Euler trail-based algorithm that can
   optimally generate non-overlapped INT paths with a minimum path
   number.







Pan, et al.              Expires April 28, 2021                 [Page 3]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


2.  Problem Statement

   This document proposes INT-path to solve the following technical
   challenges of building a network-wide telemetry system based on INT:

   o  Uncontrollable probing path.  As an underlying primitive, INT only
      defines how to extract device-internal states using probe packets.
      However, the probe packet itself cannot proactively decide which
      path to monitor since it does not have any path-related prior
      knowledge.  If the INT header is embedded in an IP packet, the
      probing path will be passively decided by its destination IP
      address together with the routing table in each network device,
      leaving probing path totally uncontrollable by the INT packet
      sender.  Given the uncontrollable probing path, it is not easy to
      work out purposive strategies to optimally generate multiple
      probing paths for achieving cost-effective network-wide telemetry.

   o  Telemetry overhead.  During traffic monitoring, we need
      periodically perform the INT operation at all devices and notify
      the controller about the underlying traffic status.  However,
      straightforwardly conducting INT at each device or device chain
      incurs significant performance overhead: (1) INT will inject
      probes into the network, which will occupy a fraction of link
      bandwidth (the finer INT sampling granularity, the more bandwidth
      will be consumed).  (2) INT agents must be deployed for probe
      generation and collection as the extra cost (the higher number of
      separated INT paths, the more INT agents need to be deployed).
      (3) Besides, as the INT agent number grows, the controller will
      suffer from a performance penalty for handling increased telemetry
      workload sent from those INT agents.

   To tackle these problems, this document proposes INT-path, a
   framework for network-wide telemetry, by decoupling the system into a
   routing mechanism and a route generation policy.  The underlying
   mechanism allows network operators or INT agents to specify a
   particular path for monitoring, addressing the uncontrollable path
   issue (see section3 for details).  The policy built upon the
   mechanism generates multiple INT paths to cover the entire network
   and a good policy is expected to minimize the telemetry overhead with
   the least path overlapping as well as the minimized total path number
   (see section4 and section5 for details).

3.  Source Routing-based Path Monitoring (Mechanism)

   This document addresses the uncontrollable path issue via the
   technique of SR.  Figure 1 shows the SR-based telemetry architecture
   as well as the probe packet format.  Although SR is not a new
   technique, we innovate to couple it with the INT probe using the P4



Pan, et al.              Expires April 28, 2021                 [Page 4]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


   language [P4] to implement user-specified or on demand path
   monitoring.

                             |<--   Variable length   -->|
                             | 22B  |
                             +------+------+------+------+
                             | INTn | .... | INT2 | INT1 |
                             +------+------+------+------+
                              \                         /
                                 \                    /
                                   \               /
                                      \         /
                 +-------+------+------+-------+-------+
                 |  ETH  |  IP  |  SR  |  INT  |  UDP  |
                 +-------+------+------+-------+-------+
                               /        \
                            /              \
                         /                    \
                      /                          \
                    +-------+------+-------+-------+
                    | Portn | .... | Port2 | Port1 |
                    +-------+------+-------+-------+
                    |  4b   |
                    |<----------  512b   --------->|

                      Figure 1.  Probe packet format

3.1.  Packet Header Format

   Theoretically, the SR label stack and the INT label stack can be
   placed above either the IP header or the UDP header.  If placed above
   the UDP header, they need to occupy an extra port number, which is
   likely to conflict with the port number chosen by the end hosts for a
   certain application.  While, if placed above the IP header, they only
   occupy an IP protocol number, and then we can choose an unused
   protocol number according to existing RFC specifications.  Therefore,
   the program chosen by this document is to place the SR label stack
   and the INT label stack above the IP header as shown in Figure1.  One
   thing to declare is that although we design a customized header
   format as follows for the probe packets, the network devices can
   still correctly forward these packets provided that protocol-
   independent forwarding is supported.

   o  DP: DP means Destination Port which is set to "SR_INT_PORT" to
      inform the packet parser that it is an SR-INT probe (i.e., INT
      probe packet with an SR label stack).





Pan, et al.              Expires April 28, 2021                 [Page 5]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


   o  DIP: DIP means destination IP address of the probe packet which is
      set using controller's IP to guarantee that the probe packet will
      finally be forwarded to the controller for further analysis.

   o  SR: A 512-bit space is reserved for the SR label stack above the
      IP header.  A 4-bit space is allocated for each SR label to denote
      the router output port ID thus can maximally support 16 output
      ports for each router.

   o  INT: Above the fixed-length SR label stack, a variable-length INT
      label stack is allocated.  Each INT label occupies 22B containing
      the information such as device ID, ingress/egress port, egress
      queue depth.  Since P4 currently does not well support parsing
      double variable length stacks in the packet header, the SR label
      stack with a fixed length is statically allocated and the right
      shift operation is used to perform the "stack pop" behavior.

3.2.  Forwarding Behaviors

   In the SR-based telemetry architecture, three types of logic routers
   are proposed with different functionalities: the INT generator, the
   INT forwarder and the INT collector (as shown in Figure 2).





























Pan, et al.              Expires April 28, 2021                 [Page 6]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


               +--------+                         +--------+
               |End Host|                         |End Host|
               +--------+                         +--------+
                    |                                 |
                    |                                 |
               +---------+                       +---------+
               |   INT   |                       |   INT   |
               |generator|                       |collector|
               +---------+                       +---------+
                |   |           +---------+           |   |
                |   |           |   INT   |           |   |
                |   |           |forwarder|           |   |
                |   |           +---------+           |   |
                |   |          /           \          |   |
                |   |         /             \         |   |
                |  +---------+               +---------+  |
                |  |   INT   |               |   INT   |  |
                |  |forwarder|               |forwarder|  |
                |  +---------+               +---------+  |
                |             \             /             |
                |              \           /              |
                |               +---------+               |
                |               |   INT   |               |
                |               |forwarder|               |
                |               +---------+               |
                |                                         |
               +-------------------------------------------+
               |                 Controller                |
               +-------------------------------------------+

              Figure 2.  Source routing-based path monitoring

   o  INT generator: The INT generator is responsible for spawning the
      SR-INT probe packets at the first hop of the monitoring path.
      Since packet generation directly from the data plane is currently
      undefined in P4, we consider a workaround to periodically generate
      "empty" probes from the outside by either the router/switch CPU or
      a host attached to the network device.  When the probe arrives at
      the data plane, the INT generator will rewrite its packet header
      to allocate the SR label stack and add its local INT information
      using header.setValid() in P4 before forwarding the packet.
      Specifically, the INT generator will push the output port IDs into
      the SR label stack in the packet header.  The sequence of the
      output port IDs (i.e., how to forward the packet across the
      network) is predetermined at the controller via centralized route
      calculation.





Pan, et al.              Expires April 28, 2021                 [Page 7]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


   o  INT forwarder: The INT forwarder performs packet forwarding of
      either the SR-INT probes or the background traffic, according to
      the DP number of the incoming traffic.  If the DP is
      "SR_INT_PORT", the INT forwarder will perform label switching and
      forward the packet only according to the output port ID popped
      from the SR label stack.  The SR label is popped once at a router
      by right shifting the SR header by 4 bits at each hop.  Besides,
      the INT forwarder will also push its local INT information into
      the INT label stack before forwarding the probe.

   o  INT collector: At the last hop of the monitoring path, since the
      DIP is filled with controller's IP address, the INT collector will
      finally forward the probe packet to the controller for further
      analysis.

4.  DFS-based path planning algorithm

4.1.  Algorithm Outline

   In this section, we propose a simple algorithm based on DFS.

   When traversing a tree or a graph, DFS starts at the root and
   explores as far as possible along each branch before backtracking.
   The basic idea of the DFS-based path planning algorithm is to
   consecutively add the visited vertices into the current path before
   backtracking; if we have nowhere to go and have to backtrack, we just
   create a new path and add the fork vertex (the first vertex along the
   backtracking path that has unvisited edges) as the first node of the
   new path.  After all the edges are visited in the DFS order, we can
   extract multiple non-overlapped paths covering the entire graph.

   A recursive version of the DFS-based path planning algorithm is as
   follows:

   o  Step1: Choose v0 as the first vertex of the depth-first traversal
      and start the algorithm.

   o  Step2: Select one of v0's adjacency vertices v1 and mark the edge
      between v0 and v1 as visited, add v0 and v1 into the current INT
      path; continue to search for v1's adjacency vertex v2 and mark the
      edge between v1 and v2 as visited, add v2 into the current INT
      path; continue to search for v2's adjacency vertex v3 and mark the
      edge between v2 and v3 as visited, add v3 into the current INT
      path; and continue until a vertex vi has no adjacency vertices
      that has unvisited edges, then mark the vertex vi as visited, and
      store the current INT path into set INT path.





Pan, et al.              Expires April 28, 2021                 [Page 8]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


   o  Step3: Backtrack at the visited vertex vi until a previous vertex
      that has unvisited edges is found, and find an adjacency vertex of
      the previous vertex and mark the edge between them as visited,
      then add the previous vertex and the adjacency vertex into a new
      current INT path, that is, continue as step2.  If all the
      adjacency vertices of the previous vertex have been accessed, then
      mark the previous vertex as visited.  Step3 continues until all of
      the vertices that are reachable by backtracking from vi are
      visited.

   o  Step4: If there are any unvisited vertices, this algorithm selects
      one of them as a new source and repeats step2 and step3 from that
      vertex.  Step4 continues until every edge and every vertex has
      been visited.  Then the set INT path is the multiple non-
      overlapped paths covering the entire graph.

4.2.  Example

   We show an algorithm example on a network graph of five devices as
   shown in Figure 3.

                       +----+     +----+     +----+
                       | v0 |-----| v1 |-----| v2 |
                       +----+     +-+--+     +--+-+
                                    |       /   |
                                    |      /    |
                                    |     /     |
                                    |    /      |
                                    |   /       |
                                  +-+--+     +--+-+
                                  | v3 |-----| v4 |
                                  +----+     +----+

                  Figure 3.  Depth-first graph traversal

   At the beginning, v0 is pushed into the call stack, path1 = {v0, v1}
   and the edge between v0 and v1 is marked as visited.  The path1
   expands as more and more vertices are visited in the DFS order.  When
   path1 expands to {v0, v1, v2, v3, v1}, we have nowhere to go and have
   to find the fork vertex.  At this time, we pop v1 from the stack and
   return to v3, which has an unvisited edge to v4 (notice that the call
   stack push/pop operations are implicitly performed during recursion).
   Then, we identify v3 as the fork vertex because it is the first
   vertex along the backtracking path that has unvisited edges.  Based
   on v3, we create a new path as path2 = {v3, v4}.  When path2 expands
   to {v3, v4, v2}, we have again nowhere to go and have to backtrack.
   But at this time, although we check all the vertices popped from the
   call stack, we still cannot find any fork vertex.  The recursion



Pan, et al.              Expires April 28, 2021                 [Page 9]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


   halts when the call stack finally becomes empty.  At last, we extract
   two non-overlapped INT probing paths (i.e., path1 and path2).

5.  Euler trail-based path planning algorithm

5.1.  Algorithm Outline

   Although the DFS-based path planning algorithm is computationally-
   efficient, it has no guarantee to minimize the number of generated
   paths, which will potentially increase the telemetry overhead,
   especially the telemetry workload at the centralized.  Here, we
   propose an optimal path planning algorithm taking advantage of the
   mathematical properties of the Euler trail/circuit.

   In fact, the mathematical properties of the Euler trail/circuit
   already indicated the theoretical value of the minimum non-overlapped
   path number for covering a given graph.  To achieve the theoretical
   minimum, each extracted path from a graph should start from one odd
   vertex and end at another odd vertex.  In other words, removing one
   such path from a graph will eliminate a pair of odd vertices from
   that graph.  According to the above observation, we devise an Euler
   trail-based algorithm to iteratively extract a path between a pair of
   odd vertices until all the vertices/edges are extracted from the
   original graph.

   Although the algorithm sounds rather straightforward as an iterative
   path extraction process, the devil lies in the detail of dealing with
   several boundary cases.  To be more specific, the devil lies in the
   possibility that an extracted path can split one connected graph into
   multiple subgraphs, which definitely complicates the iterative path
   extraction process.

   Next we explain the optimal algorithm in detail.  We use G to
   represent the network graph, which is initialized to be one connected
   graph and may also become multiple disconnected subgraphs caused by
   path extraction during algorithm iteration.  We use Q to represent
   the path set which is initialized as an empty set and will finally
   contain the generated non-overlapped INT paths.  We use G-p to
   represent extracting a path p from the graph G which will possibly
   further split the graph(s) G into more subgraphs.

   Actually, without considering the complexity of graph split, for a
   given connected graph, there are mainly three different cases for
   path extraction.  We propose solutions in each of these three cases
   as follows:

   o  The first case is: The graph does not contain any odd vertex.  We
      can extract an Euler circuit from the graph, which will traverse



Pan, et al.              Expires April 28, 2021                [Page 10]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


      every vertex of the graph.  The Euler circuit can be found with
      the Hierholzer's algorithm [Hierholzer] and inserted into Q.  The
      Hierholzer's algorithm is an efficient algorithm for finding Euler
      trails and Euler circuits.

   o  The second case is: The graph contains two odd vertices.  We just
      find an Euler trail between the two odd vertices as the path to be
      extracted.  Under this circumstance, an Euler trail can also be
      found with the Hierholzer's algorithm and inserted into Q.

   o  The last case is: The graph contains more than two odd vertices.
      We should extract an Euler trail between any pair of odd vertices.
      In this case, the specific algorithm is as follows:

      Step1: If G is not empty, perform the following steps.  Otherwise
      the algorithm terminates.

      Step2: Choose two odd vertices randomly and find a path p to
      connect the pair of odd vertices with the Dijkstra's algorithm or
      any other algorithms.  Then delete the edges along path p from G,
      and add path p into Q.  After this, if the graph(s) in G have been
      broken into multiple disconnected subgraphs, then go to step3.  If
      the graph in G has not been broken into multiple disconnected
      subgraphs, then go to step1.

      Step3: Use S to store the disconnected subgraphs split from G.
      Then, select graphs with no odd vertex from S and store them into
      T.  If neither set T nor set Q is an empty set, then go to step4.
      If set T is not empty and set Q is empty, each subgraph in the set
      T is processed in the same way as in the first case, that is,
      using Hierholzer's algorithm to extract an Euler circuit from the
      subgraph, then delete the edges along the Euler circuit from G and
      add the Euler circuit into Q.  For each subgraph in set S, if it
      has two odd vertices, the subgraph is processed in the same way as
      in the second case, that is, using Hierholzer's algorithm to find
      an Euler trail between the two odd vertices as the path to be
      extracted, then delete the edges along the Euler trail from G and
      add the Euler trail into Q.  For each subgraph in set S, if it has
      more than two odd vertices, then go to step2.

      Step4: For each graph in set T, generate an Euler circuit
      T_circuit for its full edge coverage.  Then search the current Q
      to find a path T_path having at least a same vertex with
      T_circuit.  Then, connect T_circuit with T_path to create a longer
      new path, and replace the original T_path with the new path in Q,
      and delete the edges along path T_circuit from G.





Pan, et al.              Expires April 28, 2021                [Page 11]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


5.2.  Example

   Figure 4 shows a path extraction process of the Euler trail-based
   algorithm.  At the start, there is only one connected graph G1
   {1,2,3,4,5,6,7} with 4 odd vertices.  Since the number of the odd
   vertices is larger than 2, we randomly choose two odd vertices (1 and
   3), extract a path 1-4-3 from G1 and insert the path into Q.  The
   above path extraction behavior will split the original G1 into two
   subgraphs G1 {1,2,3} and G2 {4,5,6,7}.  Since G1 has no odd vertex
   and set Q is not empty, we paste the path 1-4-3 in Q with the Euler
   circuit 1-2-3-1 generated from G1 to create a new path 1-2-3-1-4-3.
   The new path will replace the original path 1-4-3 in Q.  After the
   path paste, there is only one graph G1 {4,5,6,7} with 2 odd vertices.
   We use the Hierholzer's algorithm to find its Euler trail 5-4-6-5-7-6
   as the second INT path in Q.  The algorithm halts after all the paths
   are extracted.



































Pan, et al.              Expires April 28, 2021                [Page 12]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


                      +----+3+----+   +----+6+----+
                     /      +      \ /      +      \
                    +       |       +       |       +
                    2       |       4       |       7
                    +       |       +       |       +
                     \      +      / \      +      /
                      +----+1+----+   +----+5+----+
                                   (a)
                           G1={1,2,3,4,5,6,7};
                            S={G1}, T=Empty;
                              odd_num=4>2;
                               Q={1-4-3};

                      +----+3         +----+6+----+
                     /      +        /      +      \
                    +       |       +       |       +
                    2       |       4       |       7
                    +       |       +       |       +
                     \      +        \      +      /
                      +----+1         +----+5+----+
                                   (b)
                         G1={1,2,3},G2={4,5,6,7};
                            S={G1,G2}, T={G1};
                       T_path=1-4-3,T_circuit=1-2-3-1;
                            path=1-2-3-1-4-3;
                             Q={1-2-3-1-4-3};

                              +----+6+----+
                             /      +      \
                            +       |       +
                            4       |       7
                            +       |       +
                             \      +      /
                              +----+5+----+
                                   (c)
                              G1={4,5,6,7};
                             S={G2}, T=Empty;
                               odd_num=2;
                        Q={1-2-3-1-4-3,5-4-6-5-7-6};

   Figure 4.  Path extraction process of the Euler trail-based algorithm

6.  IANA Considerations

   This document introduces no new security issues.






Pan, et al.              Expires April 28, 2021                [Page 13]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


7.  Security Considerations

   This document makes no request of IANA.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [Hierholzer]
              Hierholzer, H. and W. Wiener, "Ueber die Moeglichkeit,
              einen Linienzug ohne Wiederholung und ohne Unterbrechung
              zu umfahren", March 1873,
              <https://doi.org/10.1007/BF01442866>.

   [Jia]      Jia, CH., Pan, T., Bian, ZZ., Lin, XC., Song, EG., Xu, C.,
              Huang, T., and YJ. Liu, "Rapid Detection and Localization
              of Gray Failures in Data Centers via In-band Network
              Telemetry", April 2020,
              <https://doi.org/10.1109/NOMS47738.2020.9110326>.

   [P4]       Bosshart, P., Daly, D., Gibb, G., Izzard, M., McKeown, N.,
              Rexford, J., Schlesinger, C., and D. Talayco, "P4:
              programming protocol-independent packet processors", July
              2014, <https://doi.org/10.1145/2656877.2656890>.

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
              "Simple Network Management Protocol (SNMP)", RFC 1157,
              DOI 10.17487/RFC1157, May 1990,
              <https://www.rfc-editor.org/info/rfc1157>.

Authors' Addresses









Pan, et al.              Expires April 28, 2021                [Page 14]


Internet-Draft       In-band Network-Wide Telemetry         October 2020


   Tian Pan
   Beijing University of Posts and Telecommunications
   Beijing
   China

   Email: pan@bupt.edu.cn


   Minglan Gao
   Beijing University of Posts and Telecommunications
   China

   Email: gml@bupt.edu.cn


   Enge Song
   Beijing University of Posts and Telecommunications
   China

   Email: songenge@bupt.edu.cn


   Zizheng Bian
   Beijing University of Posts and Telecommunications
   China

   Email: zizheng_bian@bupt.edu.cn


   Xingchen Lin
   Beijing University of Posts and Telecommunications
   China

   Email: linxchen3907@163.com

















Pan, et al.              Expires April 28, 2021                [Page 15]