Internet-Draft | MNA Label Stack Operations | September 2022 |
Andersson, et al. | Expires 30 March 2023 | [Page] |
- Workgroup:
- MPLS Working Group
- Internet-Draft:
- draft-andersson-mpls-mna-label-stack-operations-00
- Published:
- Intended Status:
- Standards Track
- Expires:
MPLS Label Stack Operations in Networks with MNA Incremental Deployment
Abstract
MPLS Network Action (MNA) allows MPLS packet to carry instruction and data for in-network services and functions in an MPLS network. This document describes the FEC-based optimized operations on the MPLS label stack when the network is mixed with LSRs which are capable or incapable of processing MNAs.¶
Status of This Memo
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 30 March 2023.¶
Copyright Notice
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.¶
1. Introduction
MPLS Network Actions (MNA) is used to support actions for Label Switched Paths (LSPs) and/or MPLS packets in addition to the normal forwarding. [I-D.ietf-mpls-mna-fwk] provides the architectural framework for MNA and [I-D.ietf-mpls-mna-requirements] provides the design requirements for MNA. MNA can support actions encoded within or below the label stack. [I-D.andersson-mpls-eh-architecture] describes some further architectural concepts for MNA.¶
This document provides the operating procedures for MNA-capable and non-MNA-capable LSRs where MNA encoding are carried within or below the MPLS label stack. We show that MNAs can be gradually introduced into an existing MPLS network. The capability to handle MNAs is announced throughout the MPLS network, and LSRs that do not understand this information simply ignore it.¶
The MNAs are carried below the top label and the presence of MNAs are indicated by a bSPL in the label stack.¶
The MNA use cases can be found in [I-D.ietf-mpls-mna-usecases]. A post-stack extension header may for example be used when it is required that the packet carry a large instruction header and/or metadata for an MNA [I-D.song-mpls-extension-header].¶
Only MNA capable LSRs will process MNAs, LSRs that are non-MNA-capable will ignore the MNA and forward the packet as if the information was not there.¶
1.1. Requirement Language
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.¶
2. Operations on an MPLS Label Stack in an MNA capable network
This document provides a set of examples to show the operations performed on MPLS encapsulated packets in a network where MPLS MNAs are used. The document does also illustrated the procedures for processing of the information carried within the MPLS label stack to indicate the presence of MNAs below the top label.¶
2.1. Physical Topology
Assume a physical topology that includes both MNA capable LSRs and non-MNA capable LSRs. The topology is intentionally kept quite simple.¶
LDP Downstream on Demand (DoD) or Downstream Unsolicited (DU), RSVP-TE, an IGP or a centralized controller could be used to create the label mappings between the LSRs in an MNA capable network. Referring to Figure 1, and using LDP DU for illustration, creation of an MNA path used by A to send MPLS encapsulated packets with MNAs to F is as show below.¶
For prefix F reachable at LSR F:¶
- F advertises labels F:[ldp: implicit-null, MNA-FEC: implicit-null] to E¶
- E advertises labels F:[ldp: 101, MNA-FEC: 201] to D¶
- D advertises label F:[ldp: 102] to c¶
- c advertises label F:[ldp: 103] to b¶
- b advertises label F:[ldp: 104] to A¶
This will result in installed labels as shown in Figure 2.¶
2.2. A day in the life of a packet
This section provides examples of forwarding for some common scenarios in networks with a mix of MNA-capable and non-MNA-capable LSRs and packets with and without MNAs encoded.¶
The examples assume the use of post-stack extension headers. The process is equally applicable to in-stack MNAs.¶
2.2.1. Non-VPN Case
For non-VPN there are two variants, either the MNA is present or it is not.¶
2.2.1.1. Non-VPN with an MNA in the packet
-
b is a legacy router so just swaps [104] to [103], and sends the packet to c¶
- stack = [103, bSPL, HEH, EH, IP]¶
-
c is a legacy router so just swaps [103] to [102], and sends the packet to D¶
- stack = [102, bSPL, HEH, EH, IP]¶
-
D is an MNA capable LSR and receives the packet with [102] on top of the stack; D scans the packet for an MNA; D finds the MNA and processes it and then swaps the top label to [101] and then sends the packet on to E¶
- i
- Note: this goes on the standard FEC because we only announce in the packet there is NO MNA. In this case MNA is present.¶
- stack = [101, bSPL, HEH, EH, IP]¶
-
E receives [101] and scans the packet for MNA; it finds the MNA and processes it and then pops the top label and send the packet to F¶
- F receives the packet and scans the packet for MNA; it finds the MNA and processes it. As F is the ultimate hop it pops GAL, and removes bSPL, HEH and EH, processes IP and forwards the packet.¶
2.2.1.2. Non-VPN without any MNA in the packet
In this example there is no MNA present in the packet.¶
-
b receives the packet, b is a legacy router so it just swaps [104] to [103] and sends the packet to c¶
- stack = [103, IP]¶
-
c receives the packet, c is a legacy router so it just swaps [103] to [102], and sends the packet to D¶
- stack = [102, IP]¶
-
D receives the packet. Since D is an MNA capable router, it searches the packet for MNA but finds nothing, so D swaps [102] to [201], and sends the packet to E¶
-
E receives the packet [201] and bypasses MNA searching and processing (received on the "no MNA present" FEC; E is penultimate node so it pops MNA-FEC label; and send the packet to F.¶
- stack = [IP]; not exactly a "label stack", but listed here for symmetry¶
- F receives [IP] and routes the packet¶
2.3. The VPN case
In these two examples there is VPN information in the label stack, in the first there also MNAs in the packet.¶
2.3.1. VPN with MNA in the packet
-
b receives the packet; b is a legacy router and just swaps [104] to [103] and sends the packet to c¶
- stack = [103, VPN, bSPL, HEH, EH, IP]¶
-
c receives the packet; c is a legacy router and just swaps [103] to [102] and sends the packet to D¶
- stack = [102, VPN, bSPL, HEH, EH, IP]¶
-
D receives the packet; D is an MNA capable LSR; D will search the packet for MNA and will find and process the MNA; D will then swap [102] to [101] and sends the packet to E¶
-
E receives the packet; E is MNA capable LSR; E will search the packet for MNA and will find and process the MNA; E will then pop [101] and sends the packet to F¶
- F receives and scans the packet for MNA; it finds an MNA and processes it. As F is the ultimate hop it pops the bSPL and removes HEH and EH, processes the VPN label and forwards the packet.¶
2.3.2. VPN without MNA in the packet
-
b receives the packet; b is a legacy router and just swaps [104] to [103] and sends the packet to c¶
- stack = [103, VPN, IP]¶
-
c receives the packet; c is a legacy router and just swaps [103] to [102] and sends the packet to D¶
- stack = [102, VPN, IP]¶
-
D receives the packet; D is MNA capable LSR; D will search the packet for MNA; D will not find any MNA; D will then swap [102] to [201] and sends the packet to E on the "no MNA present" FEC.¶
-
E receives the packet [201] and bypasses MNA processing (received on the "no MNA present" FEC; E is the penultimate node so it pops MNA- FEC label; and send the packet to F on the "no MNA present" FEC.¶
- F receives and scans the packet for MNA; finds no MNA and bypasses MNA processing. As F is the ultimate hop it processes the VPN label and forwards the packet.¶
2.4. RSVP-TE Tunnel case
The RSVP-TE tunnel is not MNA capable or the capability has been disabled.¶
Assume a physical topology that includes both MNA capable LSRs and non-MNA capable LSRs, as in the earlier examples. This topology also includes a low cost RSVP-TE tunnel between b and D.¶
For this example the following assumptions are made:¶
- An RSVP-TE tunnel has been established between b and D (packets will bypass c)¶
- F is reachable at b through RSVP-TE tunnel¶
- LDP is enabled on the RSVP-TE tunnel¶
For prefix [F]: The following label mappings are sent by the LSRs in the network.¶
- F advertises labels F: [ldp: implicit-null, MNA-FEC: implicit-null] to E¶
- E advertises labels F: [ldp: 101, MNA-FEC: 201] to D¶
- D advertises label F: [ldp: 102] to c and F:[ldp: 102] to b¶
- c advertises label F: [ldp: 103] to b¶
- b advertises label F: [ldp: 104] to A¶
This will result in label mappings like this.¶
To describe the label stack operations in this case the VPN label stack is used, starting with the case where an MNA is present in the packet.¶
2.4.1. RSVP Tunnel and MNA present in the packet
-
b receives the packet, since b is a legacy router it swaps [104] to [102], the next-hop reachable through the RSVP-TE tunnel; push the ingress RSVP-TE tunnel label and send it via the tunnel to the tunnel endpoint D¶
- stack = [RSVP, 102, VPN, bSPL, HEH, EH, IP]¶
- Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE label.¶
-
D receives the packet, D will pop the last RSVP-TE label; since D is an MNA capable router it will search the stack and find the MNA, after processing the MNA it will swap [102] to [101], and send the packet to E over the normal FEC¶
-
E receives the packet [101]; since E is an MNA capable router it will search the stack and find the MNA; after processing the MNA it will pop [101], and send the packet to E over the normal FEC¶
- F receives the packet with the VPN label on top [VPN]; E scans the packet for MNA; it finds the MNA and processes it. As F is the ultimate hop it pops bSPL, and removes HEH and EH, processes VPN label and forwards the packet.¶
2.4.2. RSVP Tunnel and no MNA present in the packet
-
b receives the packet [104]; be is legacy router and will not search for an MNA; b swaps [104] to [102]; pushes [RSVP] sends packet to D over the RSVP-TE tunnel.¶
- stack = [RSVP, 102, VPN, IP]¶
- Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE label.¶
-
D receives pops the tunnel label [RSVP], D is MNA capable and scans the packet for MNA; D finds no MNA is present; pops RSVP-TE label, and then swaps LDP label [102 ]to [201] and sends the packet to E¶
-
E receives [201] and bypasses MNA processing since the packet is received on the "no MNA present" FEC; E is the pen-ultimate hop so it pops the MNA-FEC label and forward the packet to F¶
- stack = [VPN, IP]¶
- F receives the packet [VPN]; and scans the packet for MNA; it does not find any MNA, and it processes VPN label and forwards the packet.¶
2.4.3. EH capable RSVP-TE tunnel
The case where an RSVP-TE tunnel is both MNA capable and MNA enabled is for further study.¶
4. IANA Considerations
There are no requests for IANA actions in this document.¶
Note to the RFC Editor - this section can be removed before publication.¶
5. Acknowledgments
TBA¶
-¶
6. References
6.1. Normative References
- [I-D.andersson-mpls-eh-architecture]
- Andersson, L., Guichard, J. N., Song, H., and S. Bryant, "MPLS Extension Header Architecture", Work in Progress, Internet-Draft, draft-andersson-mpls-eh-architecture-03, , <https://www.ietf.org/archive/id/draft-andersson-mpls-eh-architecture-03.txt>.
- [I-D.ietf-mpls-mna-fwk]
- Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS Network Actions Framework", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-fwk-01, , <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-fwk-01.txt>.
- [I-D.ietf-mpls-mna-requirements]
- Bocci, M., Bryant, S., and J. Drake, "Requirements for MPLS Network Action Indicators and MPLS Ancillary Data", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-requirements-03, , <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-requirements-03.txt>.
- [I-D.ietf-mpls-mna-usecases]
- Saad, T., Makhijani, K., Song, H., and G. Mirsky, "Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-usecases-00, , <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-usecases-00.txt>.
- [I-D.song-mpls-eh-indicator]
- Song, H., Li, Z., Zhou, T., and L. Andersson, "Options for MPLS Extension Header Indicator", Work in Progress, Internet-Draft, draft-song-mpls-eh-indicator-05, , <https://www.ietf.org/archive/id/draft-song-mpls-eh-indicator-05.txt>.
- [I-D.song-mpls-extension-header]
- Song, H., Li, Z., Zhou, T., Andersson, L., Zhang, Z., Gandhi, R., Rajamanickam, J., and J. Bhattacharya, "Support MPLS Network Actions using Post-Stack Extension Headers", Work in Progress, Internet-Draft, draft-song-mpls-extension-header-10, , <https://www.ietf.org/archive/id/draft-song-mpls-extension-header-10.txt>.
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC5586]
- Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, , <https://www.rfc-editor.org/info/rfc5586>.
6.2. Informative References
- [RFC7274]
- Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, , <https://www.rfc-editor.org/info/rfc7274>.
- [RFC8174]
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.