Inband Flow Learning Framework

3.2.1. Telemetry Mode

There are two modes to deploy inband flow information telemetry: End-to-End (E2E) and Hop-by-Hop (HbH). For majority of the services, E2E telemetry of service flows can meet the requirements of network operators by providing the entire performance insight of the service. In E2E mode shown in Figure 2, ingress node discovers the characteristics of service flows and proceed on-path telemetry on the flows to be monitored. Egress node need to deploy the same monitoring flows and complete the telemetry. If the telemetry data is not carried in the data packet but is reported at each node, flow identifier is required to associate the data on data consumer. Documents like [RFC9326] [RFC9343] [I-D.ietf-mpls-inband-pm-encapsulation] provide the encapsulation format of flow identifier.¶

                    +-------------+
                    |Data Consumer| compute E2E flow info
                    +-------------+
                       |        |
         ___flow info__|        |____flow info____
        |   telemetry                telemetry    |
        |                                         |
 +---------+   +---------+    +---------+   +---------+
 | Ingress |---| Transit | ...| Transit |---| Egress  |
 |   Node  |   |   Node  |    |   Node  |   |   Node  |
 +---------+   +---------+    +---------+   +---------+

Figure 2 End-to-End Telemetry Mode¶

The distinction of HbH mode to E2E mode is that transit node also participates the inband flow information learning and telemetry. In HbH mode shown in Figure 3, telemetry covers the flow information on every node of the forwarding path the flow packet is transmitted, which provides detailed flow information on each hop. Hop-by-Hop telemetry usually works in the need of an on-demand fault diagnose.¶

                  +-------------+
                  |Data Consumer| compute HbH flow info
                  +-------------+
                    |   |  |   |  flow info telemetry
      ______________|   |  |   |_________________
     |               ___|  |___                  |
     |              |          |                 |
 +---------+   +---------+    +---------+   +---------+
 | Ingress |---| Transit | ...| Transit |---| Egress  |
 |   Node  |   |   Node  |    |   Node  |   |   Node  |
 +---------+   +---------+    +---------+   +---------+

Figure 3 Hop-by-Hop Telemetry Mode¶

3.2.2. Telemetry Policy

Telemetry policy is used to determine which flow should be monitored. By configuring telemetry policy, it can increase the priority of learning and telemetry to critical flow and reduce or filter the learning and telemetry of unimportant flows. It is crucial to network deployment for two reasons, one is the number of flows can be huge, another is the limitation of processing capability either on the controller or the network node. There might be millions of flows in a large scale network, for example 5G mobile backhaul network. It is important to wisely choose the granularity of inband flow information telemetry.¶

Regarding IP traffics, the telemetry policy can be based on either one of or combination of flow characteristics, such as IP source/destination address, TCP/UDP port number, VRFs, or network device interfaces etc. An IP address with a flexible wildcard mask can also be used as means to provide telemetry policy to an aggregation of flows.¶

3.2.3. Telemetry Instance

Inband Flow Information Telemetry Instance(IFITI), in short called telemetry instance, is the management object of the monitored flow for the deployment of flow-oriented on-path telemetry techniques under the framework of IFL. During its life cycle, IFITI is responsible for providing performance telemetry data on the nodes that the flow it monitors traverses.¶

On ingress nodes IFITIs can be automatically generated in either distributed or centralized way by implementing telemetry policies for automatically discovered service flows. The transit nodes and egress nodes can also automatically generate IFITIs by learning some special information of the monitored flows whitch is embedded by the ingress nodes without configuring flow characteristics. Flow identifier is such special information whitch may be a unique value within a domain encapsulated in the service packets to setup the relationship between the characteristic information, telemetry instance and the service flow. It can not only correlate the telemetry data of flows on each node, as mentioned in the previous section, but also serve as the key marker for the forwarding plane to identify the monitored flow. For the forwarding plane, it is much easier to identify a piece of data in a service packet than to identify various types of flow characteristics.¶

The following uses flow identifier as an example to describe the flow learning process on transit and egress node. Once the telemetry instance is created, ingress node can start the telemetry of flow information based on the method of on-path telemetry techniques. At the same time, ingress node encodes inband monitoring information in the service packets, including the identifier. When a service flow packet passes through the transit node or egress node, if the node detects that the packet contains a flow identifier, it considers that the packet is a service flow packet to be monitored, and automatically creates a telemetry instance using the identifier as the key.¶

The automatic creation of telemetry instance on network node can greatly facilitate the dynamic and incremental deployment. On all types of nodes, network operators do not need to statically configure characteristics of monitored flows, which saves a lot of workload and reduces error probability in a large-scale deployment scenario. When the path of the monitored flow changes, the monitored flow can be automatically detected on the new path node and the corresponding telemetry instance can be automatically deployed.¶