Encapsulation of MPLS Network Actions and associated Data

The use cases and requirements to carry additional network instructions and the associated data in data packets in MPLS networks, i.e., MPLS Network Actions (MNA), are described in and respectively. introduces a framework of MNA, in which the In-stack Data (ISD) and Post-Stack Data (PSD) are considered as two possible mechanisms to carry the MPLS network actions and the optional data associated with the actions. This document specifies a general solution for carrying MPLS network actions and the optional data associated with the network actions either in the MPLS label stack or after the MPLS label stack. The specification of specific type of network action and the associated data is out of the scope of this document.

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 when, and only when, they appear in all capitals, as shown here.

The MPLS architecture as specified in provides a mechanism for forwarding packets through a network without requiring any analysis of the packet payload's network layer header by intermediate nodes (Label Switching Routers - LSRs). The encoding of MPLS label stack is specified in . Section 3.1 of provides the general requirements on the MNA solution. Specifically, it is required that any solution must maintain the properties of MPLS: extensibility, flexibility and efficiency by using control plane context combined with a simple data plane mechanism to allow the network to make forwarding decisions about a packet. The proposed solution in this document aims to meet the requirements in with the following design principles: Minimize the length of MNA information carried as ISD in the MPLS label stack. When ISD is needed, an ISD design with fixed length is RECOMMENDED. Carry the MNA information with large and/or variable length and possibly flexible structure as PSD in the post-stack extension headers as defined in .

The MNA Indicator is introduced to indicate the presence of any MNA information in the packet. It can be used to indicate the existence of MNA actions and the optional associated data in the ISD, or the PSD or both. Since this indicator is generic for all types of MPLS network actions, it is reasonable to allocate a basic Special Purpose MPLS label (bSPL) for it. The TC and TTL fields of the MNA Indicator are redefined as flags. The format of the MNA Indicator is shown as below:

Where: MNA Indicator label: A new bSPL, the value is TBA by IANA. H (Hop-by-Hop processing) flag: When set, it indicates that the MNA information in the packet needs to be processed hop-by-hop. I (In-stack MNA information) flag: When set, it indicates the next label entry is used to carry the MNA information. P (Post-stack MNA information) flag: When set, it indicates there is post-stack data following the MPLS label stack. S: Bottom of Stack. The value of the S bit depends on the position of the MNA indicator in the label stack. ISF (In-stack data Format): The first 2-bit of the original TTL field. When the I bit is set, the ISF field is used to indicate the format of the in-stack MNA information in the following label stack.The following ISF values are defined in this document. ISF = 00: There is no in-stack MNA information. When the I flag is 0, the value of the ISF field MUST be set to 0 on transmit and MUST be ignored on receipt. ISF = 01: The following label stack entry is used to carry a list of network actions without any associated data. ISF = 10: The following label stack entry is used to carry a domain significant label value which could be used by the network nodes to determine the set of network actions based on local policy. ISF = 11: Reserved. It could be used to indicate other format of the in-stack MNA information. RSV: The rest 6 bits in the original TTL field are reserved for future use. They MUST be set to 0 on transmit and MUST be ignored on receipt.

When the I flag in the MNA Indicator is set, and the ISF field is set to 01, the MPLS label stack entry which follows the MNA indicator is encoded as a list of flags of network actions which do not require any associated action data to be carried in the packet. The format of the In-stack network actions without data is shown as below:

Where: Label field: The 20-bit label field is used to encode the in-stack network actions which do not require any associated data. TC field: The value of the TC field SHOULD be set to zero. It be may be redefined for future use. TTL field: The value of TTL field SHOULD be set to 0. This is to ensure that it is not used inadvertently for forwarding. It may be redefined for future use.

When the I flag in the MNA Indicator is set, and the ISF field is set to 10, the MPLS label stack entry which follows the MNA indicator is encoded as a domain significant label value which could be used by the network nodes to determine the set of network actions to be performed based on local policy. This label serves as an implicit identifier of the in-stack network actions. The encoding and functionality is the same as the Reference Forwarding Value (RFV) as defined in. The format of in-stack network actions identifier is shown as below:

Where: RFV (Referenced Forwarding Value), this is defined in . TC: The value of the TC field SHOULD be set to zero. It be may be redefined for future use. S: Bottom of Stack. TTL: The value of the TTL field SHOULD be set to 0. It may be redefined for future use.

When the P flag in the MNA Indicator is set, it indicates there is post-stack data (PSD) carried after the MPLS label stack. The encoding of post-stack network actions and the optional associated data is based on the MPLS post-stack extension headers as defined in .

IANA is requested to allocate a new value for the MNA Indicator label from the "Base Special-Purpose MPLS Label Values" registry. IANA is requested to create a new registry for the bit positions of the In-stack network action flags without data.

TBD

The authors would like to thank XXX for the review and discussion.