Synonymous Flow Label Framework
Extracted elements (15)
A Synonymous Flow Label (SFL) is defined as a label that causes exactly the same forwarding behavior at the egress LER as the label it replaces, but also triggers one or more additional agreed actions such as packet counting, IPFIX capture, or deep packet inspection. This allows per-flow operations without changing the packet-forwarding system.
An aggregate SFL can be introduced as an additional label to record actions against a group of application labels, used when the number of labels needed to support per-label SFL actions becomes too large to be viable. This is not strictly synonymous action since the SFL is not replacing an existing label.
SFLs for multipoint-to-point MPLS applications (e.g., VPNs) must be source-specific so that packet batches from different ingress LERs are marked differently, allowing each ingress LER to independently and asynchronously coordinate with the destination for per-flow performance monitoring.
When sending IP over a single-label LSP (no application label), replacing the LSP label with an SFL would introduce network-wide forwarding state, which is unacceptable for scaling reasons. Therefore, an additional label must be pushed rather than replacing the existing label.
When the LSP label has been penultimate hop popped, the receiving LSR may treat the exposed SFL either as an LSP label that was not PHPed (executing the SFL action on label processing) or as an MPLS Explicit NULL with associated SFL actions. Both behaviors are indistinguishable from the measurement system's perspective, so either may be implemented.
Introducing an SFL may cause a flow to take a different ECMP path, invalidating performance measurement. As a solution, the operator MAY elect to always run with the SFL in place in the MPLS label stack.
SFLs need to be allocated from the platform label table to achieve the flow identification goals described in the framework.
The TTL and Traffic Class bits in the SFL label stack entry would normally be set to the same value as would have been set in the label that the SFL is synonymous with; however, if there is an application need, these fields MAY be set to some other value.
When entropy labels are used as the ECMP solution for SFLs, the intervening MPLS network MUST NOT load balance on any packet field other than the entropy label — stricter than the base RFC 6790 requirement.
Including originating and/or flow information in a packet via SFLs provides additional identity information, potentially degrading communication privacy for an attacker able to observe the identifier. Mitigations include encrypting control protocol packets, regularly rotating synonymous labels, or concurrently using multiple such labels.
SFL-based identification does not specifically identify which node originated the packet unless the attacker can inspect the network at the point of ingress or inspect control protocol packets. Minimizing the scope of the identity indication reduces observability of flow characteristics.
In the single-label stack case, the ingress LER must first push the SFL and then push the LSP label on top. The SFL is synonymous with an MPLS Explicit NULL and sits at the bottom of stack beneath the LSP label.
In the two-label stack case (LSP label plus application label), the SFL replaces the application label at the bottom of stack. At the egress LER, the LSP label is popped first, then the SFL is processed executing both the synonymous forwarding function and the additional per-flow action.
The aggregate SFL is inserted between the LSP label and the application label in the label stack. Its position before or after the application label is application-specific, depending on whether the SFL action requires full application context.
There are no new security issues associated with the MPLS data plane from SFL use. Any control protocol used to request SFLs must ensure the legitimacy of the request, verifying that the requesting node is authorized by the network operator.