Internet-Draft | MNA Solution | July 2022 |
Dong & Zhou | Expires 25 January 2023 | [Page] |
This document specifies a solution for carrying MPLS network actions and the associated data either in the MPLS label stack or after the MPLS label stack.¶
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."¶
This Internet-Draft will expire on 25 January 2023.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [I-D.ietf-mpls-mna-usecases] and [I-D.ietf-mpls-mna-requirements] respectively. [I-D.andersson-mpls-mna-fwk] 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The MPLS architecture as specified in [RFC3031] 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 [RFC3032].¶
Section 3.1 of [I-D.ietf-mpls-mna-requirements] 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 [I-D.ietf-mpls-mna-requirements] with the following design principles:¶
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:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MNA Indicator=SPL (TBA) |H|I|P|S|ISF| RSV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. The format of MNA Indicator¶
Where:¶
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.¶
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:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-stack action flags w/o data | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The format of In-stack action flags without Data¶
Where:¶
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[I-D.raszuk-mpls-raf-fwk].¶
The format of in-stack network actions identifier is shown as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFV | TC |S| TTL=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. The format of In-stack Network Actions Identifier¶
Where:¶
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 [I-D.song-mpls-extension-header].¶
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.¶
The authors would like to thank XXX for the review and discussion.¶