Framework of MPLS Reference Augmented Forwarding

Abstract

This document specifies an architectural framework for enabling MPLS based forwarding with optional reference based packet processing in transit network elements.¶

1. Introduction

Growth of network services results in increased demand for custom transit packet processing. Traditional per destination based best effort or constrained based forwarding is no longer sufficient. Hop by hop switching in addition to label or destination based LSP switching can be augmented with additional packet processing at all or at selective transit network elements.¶

Such additional processing can be triggered in a number of ways. Today some networks can apply local policies which enable selective processing on subset of packets based on the header's elements. Alternative to such filtering is to embed additional information in the packet header itself to indicate implicitly or explicitly what additional processing is required.¶

Examples of explicit encoding of such network actions can be found in SRv6 Network Programming [RFC8986] document. For MPLS data plane an analogy to SRv6 has been recently proposed in draft-andersson-mpls-mna-fwk [I-D.andersson-mpls-mna-fwk].¶

In this document authors propose an implicit model. Instead of explicitly encoding all required actions as a variable size ordered list in every packet this document proposes to insert fixed size 20 bit reference identifier. Such value will be used to mark groups of flows with identical custom forwarding behaviour.¶

By forwarding behaviour (further abbreviated as FB) this document assumes additional network actions which may exclude packet from default processing, may include additional security screening, OAM triggering actions or any other special handling including, but not limited to rate limited, queue mapping, redirection etc ...¶

2. Terminology

3. Encoding

A Reference Forwarding Value MUST be clearly distinguished from any forwarding label. LSE immediately preceding label stack entry containing RFV is called Reference Forwarding Indicator. RFI is REQUIRED to use Special Purpose Label value (TBA by IANA).¶

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               RFI - bSPL              | TC  |S|      TTL      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  RFV                  | TC  |S|      TTL      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               RFI:    Reference Forwarding Indicator, 20 bits
               RFV:    Reference Forwarding Value, 20 bits
               TC:     Traffic Class, 3 bits
               S:      Bottom of Stack, 1 bit
               TTL:    Time To Live

RFI and RFV tuple is always of fixed size of 8 octets. It also should occur only once in a given packet. It is optional. If a network uses the concept of LSPs it MUST be placed after the topmost label. If LSP is not setup and the network uses the concept of SDN based path computation it can be preset as topmost LSE.¶

How to set values of the TTL, TC, and Bottom of Stack (S bit) fields [RFC3032] for the RFI and RFV entries should be the same as described in [RFC6790] Section 4.2. Ingress LSR SHOULD put the same TTL and TC fields for the RFI as it does for transport label. Such ingress LSR MAY choose different values for the TTL and TC fields if it is known that the RFI will not be exposed as the top label at any point along the LSP (as may happen in cases where PHP is used and the RFI and RFV are not stripped at the penultimate hop. The BoS bit for the RFI MUST be set to zero (i.e., BoS is not set). The TTL for the RFV MUST be zero to ensure that it is not used inadvertently for forwarding. The TC for the RFV may be any value. The BoS bit for the RFV depends on whether or not there are more labels in the label stack.¶

4. Processing

Any network element can insert, delete or modify RFV or RFI-RFV tuple if instructed to do so by special action instructions.¶

If a network element understands RFI and recognizes based on the top most lable value special handling requirement it MAY direct packet for special processing. MAY or MUST processing of all requested actions (or subset of those actions) really depend on the special action instructions.¶

5. Reference to Special Instructions Mapping

As the proposed architecture is based on indirection, what is present in the packet is only a reference to special handling instructions. Such instructions are not to be explicitly carried in the packet. As each network operator has a different set of operational preferences, embedding insertion of actions into a data plane parsing of each packet is very operationally limiting and inefficient.¶

Special Network Actions or Forwarding Behaviours are to be distributed by configuration or by control plane. Details of their distribution are outside of scope of this framework document. However, it is important to recognize that this model in its roots allows open innovation for vendors in developing accelerated data plane action dictionaries as mapping and execution has only a local scope.¶

It needs to be further observed that format of such configuration or control plane (including PUB-SUB model) distributed Forwarding Behaviours MAY have a TLV/sub-TLV structure as illustrated on Figure 2 and 3 below:¶

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Type     |    Flags      |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          DST NODE ID(s)                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              RFV                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Sub-TLV(s)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+
 |     Type      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Special Actions and Optional Ancillary Data (variable)      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With such encoding option it needs to be observed that for a given RFV only nodes listed in the TLV will accept and install special handling instructions.¶

6. Operational Considerations

The proposed model is designed to operate both in the networks using traditional MPLS LSP (with local labels) as well with SR-MPLS (domain wide labels).¶

Nodes which utilize MPLS LSPs and did not receive any special handling instructions via control plane are NOT REQUIRED to inspect anything above the top label and will continue to perform basic label switching. If a node is enabled to perform additional actions on the packets it should leave the RFI/RFV tuple as received immediately after the top label swap on the stack. The PHP action may take place as usuall exposing RFI LSE. In such cases egress LSR MUST be able to understand bSPL and either discard RFI/RFV tuple or if configured so execute special actions on those packets before further forwarding it.¶

[Discussion point for WG: Should nodes inserting additional labels on the stack for example during FRR should copy the RFI/RFV to enable it to be executed on the repair path or not ?].¶

Nodes which utilize the concept of SR-MPLS and use global labels as a replacement for use of LDP can apply the same set of procedures as nodes using MPLS-LSP.¶

Nodes which utilize the concept of SR-MPLS and use global labels with segment endpoints encoded in the label stack MUST understand RFI bSPL in order to correctly copy the tuple to always place it immediately behind the top most segment endpoint during label stack modification.¶

To further simplify the concept of MPLS RAF deployment networks which utilize concept of domain wide labels can allocate two label values from each LSR. One would indicate non RAF forwarding and the other one RAF enhanced forwarding. With such allocation only nodes which recognize that arriving packets contain RAF aware label value and which received any special handling instructions may need to perform additional RFI/RFV lookup and processing. Such allocation may be unified to differentiate normal vs RAF enabled labels with common label block offset or selected label bit set.¶

7. Capability Advertisement

This document does not require any new capability to be defined.¶

11. References