idnits 2.17.00 (12 Aug 2021) /tmp/idnits49552/draft-raszuk-mpls-raf-fwk-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (25 April 2022) is 19 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-andersson-mpls-mna-fwk-00 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Raszuk, Ed. 3 Internet-Draft NTT NI 4 Intended status: Informational 25 April 2022 5 Expires: 27 October 2022 7 Framework of MPLS Reference Augmented Forwarding 8 draft-raszuk-mpls-raf-fwk-00 10 Abstract 12 This document specifies an architectural framework for enabling MPLS 13 based forwarding with optional reference based packet processing in 14 transit network elements. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 27 October 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Reference to Special Instructions Mapping . . . . . . . . . . 5 62 6. Operational Considerations . . . . . . . . . . . . . . . . . 6 63 7. Capability Advertisement . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 11.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Growth of network services results in increased demand for custom 75 transit packet processing. Traditional per destination based best 76 effort or constrained based forwarding is no longer sufficient. Hop 77 by hop switching in addition to label or destination based LSP 78 switching can be augmented with additional packet processing at all 79 or at selective transit network elements. 81 Such additional processing can be triggered in a number of ways. 82 Today some networks can apply local policies which enable selective 83 processing on subset of packets based on the header's elements. 84 Alternative to such filtering is to embed additional information in 85 the packet header itself to indicate implicitly or explicitly what 86 additional processing is required. 88 Examples of explicit encoding of such network actions can be found in 89 SRv6 Network Programming [RFC8986] document. For MPLS data plane an 90 analogy to SRv6 has been recently proposed in 91 draft-andersson-mpls-mna-fwk [I-D.andersson-mpls-mna-fwk]. 93 In this document authors propose an implicit model. Instead of 94 explicitly encoding all required actions as a variable size ordered 95 list in every packet this document proposes to insert fixed size 20 96 bit reference identifier. Such value will be used to mark groups of 97 flows with identical custom forwarding behaviour. 99 By forwarding behaviour (further abbreviated as FB) this document 100 assumes additional network actions which may exclude packet from 101 default processing, may include additional security screening, OAM 102 triggering actions or any other special handling including, but not 103 limited to rate limited, queue mapping, redirection etc ... 105 2. Terminology 107 2.1. Definitions 109 * Network Action aka Forwarding Behaviour: An operation to be 110 performed on a packet or be triggered based on given packet's 111 arrival without affecting the packet switching decision. A 112 network action may affect forwarding decisions, queuing 113 classification, OAM measurement and reporting etc .... Network 114 Actions are not carried in packets. They are distributed by 115 configuration or control plane. 117 * Reference Augmented Forwarding: Packet forwarding in addition to 118 or instead of normal lookup (by address or label) based on a set 119 of Network Actions or Forwarding Behaviours indicated by Reference 120 Identifier. 122 * Reference Forwarding Value: A 20 bit value carried in a packet 123 used to identify a set of Network Actions defining given packet's 124 special handling. 126 * Reference Forwarding Indicator: A base Special Purpose Label 127 carried in a packet used to indicate to the packet processor that 128 the following LSE is containing Reference Forwarding Value. 130 2.2. Abbreviations 132 * FB - Network Actions or Forwarding Behaviours 134 * LSE - Label Stack Entry 136 * RAF - Reference Augmented Forwarding 138 * bSPL - Base Special Purpose Label 140 * ECMP - Equal Cost Multipath 141 * RFI - Reference Forwarding Indicator 143 * RFV - Reference Forwarding Value 145 * TBA - To Be Allocated 147 * SDN - Software Defined Network 149 3. Encoding 151 A Reference Forwarding Value MUST be clearly distinguished from any 152 forwarding label. LSE immediately preceding label stack entry 153 containing RFV is called Reference Forwarding Indicator. RFI is 154 REQUIRED to use Special Purpose Label value (TBA by IANA). 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | RFI - bSPL | TC |S| TTL | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | RFV | TC |S| TTL | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 RFI: Reference Forwarding Indicator, 20 bits 164 RFV: Reference Forwarding Value, 20 bits 165 TC: Traffic Class, 3 bits 166 S: Bottom of Stack, 1 bit 167 TTL: Time To Live 169 Figure 1: RFI and RFV Tuple 171 RFI and RFV tuple is always of fixed size of 8 octets. It also 172 should occur only once in a given packet. It is optional. If a 173 network uses the concept of LSPs it MUST be placed after the topmost 174 label. If LSP is not setup and the network uses the concept of SDN 175 based path computation it can be preset as topmost LSE. 177 How to set values of the TTL, TC, and Bottom of Stack (S bit) fields 178 [RFC3032] for the RFI and RFV entries should be the same as described 179 in [RFC6790] Section 4.2. Ingress LSR SHOULD put the same TTL and TC 180 fields for the RFI as it does for transport label. Such ingress LSR 181 MAY choose different values for the TTL and TC fields if it is known 182 that the RFI will not be exposed as the top label at any point along 183 the LSP (as may happen in cases where PHP is used and the RFI and RFV 184 are not stripped at the penultimate hop. The BoS bit for the RFI 185 MUST be set to zero (i.e., BoS is not set). The TTL for the RFV MUST 186 be zero to ensure that it is not used inadvertently for forwarding. 187 The TC for the RFV may be any value. The BoS bit for the RFV depends 188 on whether or not there are more labels in the label stack. 190 4. Processing 192 Any network element can insert, delete or modify RFV or RFI-RFV tuple 193 if instructed to do so by special action instructions. 195 If a network element understands RFI and recognizes based on the top 196 most lable value special handling requirement it MAY direct packet 197 for special processing. MAY or MUST processing of all requested 198 actions (or subset of those actions) really depend on the special 199 action instructions. 201 5. Reference to Special Instructions Mapping 203 As the proposed architecture is based on indirection, what is present 204 in the packet is only a reference to special handling instructions. 205 Such instructions are not to be explicitly carried in the packet. As 206 each network operator has a different set of operational preferences, 207 embedding insertion of actions into a data plane parsing of each 208 packet is very operationally limiting and inefficient. 210 Special Network Actions or Forwarding Behaviours are to be 211 distributed by configuration or by control plane. Details of their 212 distribution are outside of scope of this framework document. 213 However, it is important to recognize that this model in its roots 214 allows open innovation for vendors in developing accelerated data 215 plane action dictionaries as mapping and execution has only a local 216 scope. 218 It needs to be further observed that format of such configuration or 219 control plane (including PUB-SUB model) distributed Forwarding 220 Behaviours MAY have a TLV/sub-TLV structure as illustrated on 221 Figure 2 and 3 below: 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Type | Flags | Length | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | DST NODE ID(s) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | RFV | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Sub-TLV(s) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: FB TLV 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+ 240 | Type | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Special Actions and Optional Ancillary Data (variable) | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 3: FB sub-TLV 249 With such encoding option it needs to be observed that for a given 250 RFV only nodes listed in the TLV will accept and install special 251 handling instructions. 253 6. Operational Considerations 255 The proposed model is designed to operate both in the networks using 256 traditional MPLS LSP (with local labels) as well with SR-MPLS (domain 257 wide labels). 259 Nodes which utilize MPLS LSPs and did not receive any special 260 handling instructions via control plane are NOT REQUIRED to inspect 261 anything above the top label and will continue to perform basic label 262 switching. If a node is enabled to perform additional actions on the 263 packets it should leave the RFI/RFV tuple as received immediately 264 after the top label swap on the stack. The PHP action may take place 265 as usuall exposing RFI LSE. In such cases egress LSR MUST be able to 266 understand bSPL and either discard RFI/RFV tuple or if configured so 267 execute special actions on those packets before further forwarding 268 it. 270 [Discussion point for WG: Should nodes inserting additional labels on 271 the stack for example during FRR should copy the RFI/RFV to enable it 272 to be executed on the repair path or not ?]. 274 Nodes which utilize the concept of SR-MPLS and use global labels as a 275 replacement for use of LDP can apply the same set of procedures as 276 nodes using MPLS-LSP. 278 Nodes which utilize the concept of SR-MPLS and use global labels with 279 segment endpoints encoded in the label stack MUST understand RFI bSPL 280 in order to correctly copy the tuple to always place it immediately 281 behind the top most segment endpoint during label stack modification. 283 To further simplify the concept of MPLS RAF deployment networks which 284 utilize concept of domain wide labels can allocate two label values 285 from each LSR. One would indicate non RAF forwarding and the other 286 one RAF enhanced forwarding. With such allocation only nodes which 287 recognize that arriving packets contain RAF aware label value and 288 which received any special handling instructions may need to perform 289 additional RFI/RFV lookup and processing. Such allocation may be 290 unified to differentiate normal vs RAF enabled labels with common 291 label block offset or selected label bit set. 293 7. Capability Advertisement 295 This document does not require any new capability to be defined. 297 8. IANA Considerations 299 This document defines a new bSPL label called Reference Forwarding 300 Indicator and is requesting IANA to allocate one from Base Special- 301 Purpose MPLS Label Values registry. 303 9. Security Considerations 305 This document does not introduce any new security risks. 307 10. Acknowledgements 309 Author would like to thank Tony Li and Jeff Tantsura for encouraging 310 me to write this up. 312 11. References 314 11.1. Normative References 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, 318 DOI 10.17487/RFC2119, March 1997, 319 . 321 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 322 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 323 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 324 . 326 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 327 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 328 RFC 6790, DOI 10.17487/RFC6790, November 2012, 329 . 331 11.2. Informative References 333 [I-D.andersson-mpls-mna-fwk] 334 Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS 335 Network Actions Framework", Work in Progress, Internet- 336 Draft, draft-andersson-mpls-mna-fwk-00, 4 April 2022, 337 . 340 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 341 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 342 (SRv6) Network Programming", RFC 8986, 343 DOI 10.17487/RFC8986, February 2021, 344 . 346 Author's Address 348 Robert Raszuk (editor) 349 NTT NI 350 Email: robert@raszuk.net