idnits 2.17.1 draft-bocci-mpls-miad-adi-requirements-04.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2022) is 744 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-bryant-mpls-dev-primer-01 == Outdated reference: A later version (-02) exists of draft-saad-mpls-miad-usecases-01 == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group M. Bocci 3 Internet-Draft Nokia 4 Intended status: Informational S. Bryant 5 Expires: October 13, 2022 University of Surrey 5GIC 6 April 11, 2022 8 Requirements for MPLS Network Action Indicators and MPLS Ancillary Data 9 draft-bocci-mpls-miad-adi-requirements-04 11 Abstract 13 This draft specifies requirements for indicators in the MPLS label 14 stack to support ancillary data in the packet and high level 15 requirements on that ancillary data. This work is the product of the 16 IETF MPLS Open Design Team. Requirements are derived from a number 17 of new proposals for additions to the MPLS label stack to allow 18 forwarding or other processing decisions to be made, either by a 19 transit or terminating LSR (i.e. the LER), based on application data 20 that may be in or below the bottom of the label stack. 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 October 13, 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 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 60 3. MPLS Network Action Indicator Requirements . . . . . . . . . 5 61 3.1. General Requirements . . . . . . . . . . . . . . . . . . 5 62 3.2. Requirements on Network Action Indicators . . . . . . . . 6 63 3.3. Requirements on Ancillary Data . . . . . . . . . . . . . 7 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 There is significant interest in developing the MPLS data plane to 75 address the requirements of new applications 76 [I-D.saad-mpls-miad-usecases]. These applications typically require 77 the inclusion of ancillary data in the MPLS packet. This data may be 78 encoded either in the label stack or below the bottom of the label 79 stack. This data is then either intercepted and processed, or some 80 other forwarding decision is taken by routers processing the packet. 81 The ancillary data is added by the ingress LSR, and is then processed 82 using mechanisms implemented by intermediate and/or egress LSRs that 83 comply with the MPLS base architecture and potentially its 84 extensions, including (but not limited to) [RFC3031], [RFC3032], 85 [RFC6790]. 87 This draft specifies requirements for indicators in the MPLS label 88 stack to support these applications, as well as the encoding and use 89 of the ancillary data. 91 1.1. Terminology 93 o Ancillary Data (AD): Data relating to the MPLS packet that may be 94 used to affect the forwarding or other processing of that packet, 95 either at an Label Edge Router (LER) [RFC4221] or Label Switching 96 Router (LSR). This data may be encoded within a network action 97 sub-stack (see below) (in-stack data), and/or after the bottom of 98 the label stack (post-stack data). 100 o Network Action: An operation to be performed on a packet. A 101 network action may affect router state, packet forwarding, or it 102 may affect the packet in some other way. 103 A network action is said to be present if there is an indicator in 104 the packet that invokes the action. 106 o Network Action Indication (NAI): An indication in the packet that 107 a certain network action is to be perfomed. There may be 108 associated ancillary data in the packet. 110 o Network Action Sub-Stack (NAS): A set of related, contiguous Label 111 Stack Entries (LSEs). 112 The first LSE contains the NAI. The TC and TTL values in the sub- 113 stack may be redefined. 114 The label field in the second and following LSE may be redefined. 115 Solutions MUST NOT redefine the S bit. See Section 3.1 through 116 Section 3.5. 118 o In-Stack Data: Any data within the MPLS label stack including the 119 outer LSE and the bottom of stack (the LSE with the S-bit set). 121 o Post-Stack Data: Any data beyond the LSE with the S-Bit set, but 122 before the first octet of the user payload. This document does 123 not prescribe whether post-stack data precedes or follows any 124 other protocol structure such as a control word or associated 125 channel header (ACH). 127 o Scope: The set of nodes that should perform a given action. 129 1.2. Background 131 The MPLS architecture is specified in [RFC3031] and provides a 132 mechanism for forwarding packets through a network without requiring 133 any analysis of the packet payload's network layer header by 134 intermediate nodes (Label Switching Routers - LSRs). Formally, 135 inspection may only occur at network ingress (the Label edge router - 136 LER) where the packet is assigned to a forwarding equivalence class 137 (FEC). 139 MPLS uses switching based on a label pushed on the packet to achieve 140 efficient forwarding and traffic engineering of flows associated with 141 the FEC. While originally used for IP traffic, MPLS has been 142 extended to support point-to-point, point-to-multipoint and 143 multipoint-to-multipoint layer 2 and layer 3 services. An overview 144 of the development of MPLS is provided in 145 [I-D.bryant-mpls-dev-primer]. 147 A number of applications have emerged which require LSRs to make 148 forwarding or other processing decisions based on inspection of the 149 network layer header, or some other ancillary information in the 150 protocol stack encapsulated deeper in the packet. An early example 151 of this was generation of a hash of the payload header to be used for 152 load balancing over Equal Cost Multipath (ECMP) or Link Aggregation 153 Group (LAG) next hops. This is based on an assumption that the 154 network layer protocol is IP. MPLS was extended to avoid the need 155 for LSRs to perform this operation if load balancing was needed based 156 on the payload and instead use only the MPLS label stack, using the 157 Entropy Label / Entropy Label Indicator [RFC6790] which are inserted 158 at the LER. Other applications where the intermediate LSRs may need 159 to inspect and process a packet on an LSP include OAM, which can make 160 use of mechanisms such the Router Alert Label [RFC3032] or the 161 Generic Associated Channel Label (GAL) [RFC5586] to indicate that an 162 intercepted packet should be processed locally. See 163 [I-D.bryant-mpls-dev-primer] for detailed list of such applications. 165 There have been a number of new proposals for how ancillary data is 166 carried in MPLS and how its presence is indicated to the LSR or 167 egress LER, for example In-situ OAM and Service Function Chaining 168 (SFC). A summary of these proposals is contained in 169 [I-D.bryant-mpls-dev-primer], an overview of use cases is provided in 170 [I-D.saad-mpls-miad-usecases]. [I-D.song-mpls-extension-header] 171 summarises some of the issues with existing solutions to address 172 these new applications (note that this document draws on the 173 requirements and issues without endorsing a specific solution from 174 [I-D.song-mpls-extension-header]): 176 These solutions rely on either the built-in next-protocol 177 indicator in the header or the knowledge of the format and size of 178 the header to access the following packet data. The node is 179 required to be able to parse the new header, which is unrealistic 180 in an incremental deployment environment. 182 A piecemeal solution often assumes the new header is the only 183 extra header and its location in the packet is fixed by default. 184 It is impossible or difficult to support multiple new headers in 185 one packet due to the conflicted assumption. An example of this 186 is that the GAL/G-ACH mechanism assumes that if the GAL is 187 present, only a single G-ACH header follows. 189 New applications therefore require the definition of extensions to 190 the MPLS architecture and label stack operations that can be used 191 across these applications in order to minimise implementation 192 complexity and promote interoperability and extensibility. 194 2. Requirements Language 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 198 "OPTIONAL" in this document are to be interpreted as described in BCP 199 14 [RFC2119] [RFC8174] when, and only when, they appear in all 200 capitals, as shown here. 202 3. MPLS Network Action Indicator Requirements 204 This document specifies requirements of MPLS Network Action 205 Indicators, and the associated Ancillary Data. The requirements are 206 for the behavior of the protocol mechanisms and procedures that 207 constitute building blocks out of which indicators for network 208 actions and associated ancillary data are constructed. 209 It does not specify the detailed actions and processing that may be 210 required by an application for any ancillary data by an LSR or LER. 211 The requirements in this document do not describe what functions an 212 implementation must support. The purpose of this document is to 213 identify the toolkit and any new protocol work that is required. 214 This new protocol work MUST be based on the existing MPLS 215 architecture. 217 3.1. General Requirements 219 1. MPLS combines extensibility, flexibility and efficiency by using 220 control plane context combined with a simple data plane mechanism 221 to allow the network to make forwarding decisions about a packet. 222 Any solution MUST maintain these properties of MPLS. 224 2. Any solutions to these requirements MUST NOT restrict the 225 generality of MPLS architecture [RFC3031], [RFC3032]. 227 3. If extensions to the MPLS data plane are required, they MUST NOT 228 be inconsistent with the MPLS architecture [RFC3031], [RFC3032]. 230 4. Solutions meeting the requirements set out in this document MUST 231 be able to coexist with and MUST NOT obsolete existing MPLS 232 mechanisms. 234 5. The design of any mechanism SHOULD be such that an LSR is able to 235 efficiently parse the label stack. 237 6. Mechanisms MUST NOT increase the size of the MPLS label stack 238 more than is necessary. 240 7. The design of solutions MUST NOT expose confidential information 241 [RFC6973] [RFC3552] to the LSRs. 243 8. Solution specifications MUST document any changes to the existing 244 MPLS data plane security model that they introduce. 246 3.2. Requirements on Network Action Indicators 248 1. When an MPLS Network Action is required, and indicator is 249 REQUIRED in the label stack. 251 2. An MPLS Network Action MUST specify whether ancillary data is 252 required in the label stack and/or post-stack data. 254 3. Any solution MUST respect the principle that Special Purpose 255 Labels are the mechanism of last resort and therefore must 256 minimise the number of new SPLs that are allocated. 258 4. Insertion, parsing, processing and disposition of Network Action 259 Indicators SHOULD make use of existing MPLS data plane 260 operations. 262 5. An NAI MUST NOT be delivered to a node that is not capable of 263 processing in the way in a way that is acceptable to the 264 imposing LER. 266 6. NAI MUST NOT become top of stack at a node that does not 267 understand how to perform a disposition operation on it. 268 Disposition includes both processing and ignoring. 270 7. The NAI design MUST support scoping of network actions. 272 8. A given NAI specification MUST specify if the scope is end-to- 273 end, hop-by-hop, or directed at one or more selected nodes. 275 9. If a design allows more than one scope, a mechanism MUST be 276 provided to specify the precedence of the scopes. 278 10. A mechanism is REQUIRED to enable an LER inserting NAIs to 279 determine if the far-end LER can accept and process a packet 280 containing a given NAI. 282 11. NAIs SHOULD be supported for both P2P and P2MP paths, but any 283 specific NAI may only be supported for one or the other. 285 12. Data plane mechanisms for NAIs MUST be consistent across 286 different control plane protocol types. 288 13. A mechanism MUST be defined for control / management planes in 289 use to determine the ability of downstream LSRs/LERs to accept/ 290 process a given NAI. 292 14. A mechanism is REQUIRED to enable an LSR to determine if an NAI 293 is present in a packet. 295 15. NAIs can only be inserted at LERs, but MAY be processed at LSRs 296 and LERs. If it is required to insert an NAI at a transit LSR 297 on an LSP, then a new label stack MUST be pushed. 299 16. It SHOULD be possible to include indicators for multiple network 300 actions in the same packet. 302 17. The solution MUST allow NAI-carrying and non-NAI-carrying 303 packets to coexist on the same LSP. 305 18. The solution MUST support the processing of a subset of the NAIs 306 on a packet. 308 19. Any specification of a solution that inserts or modifies the NAI 309 MUST discuss the possible ECMP consequences. 311 3.3. Requirements on Ancillary Data 313 1. Solutions for in-stack ancillary data MUST be able to coexist 314 with and MUST NOT obsolete existing MPLS mechanisms. 316 2. A common preamble for ancillary data MUST be defined so that a 317 node receiving the ancillary data can determine whether to 318 process, ignore, skip over or discard it according to network or 319 local policies. 321 3. Any specification of a mechanism MUST describe whether it can 322 coexist with existing post-stack data mechanisms e.g. control 323 words and G-ACH, and if so how this coexistence operates. 325 4. A mechanism MUST be defined for an LER inserting ancillary data 326 to determine that each node that needs to process the ancillary 327 data can read the required distance into the packet at that 328 node, for example [RFC9088]. 330 5. Ancillary data MAY be associated with control or maintenance 331 information for traffic carried by an LSP, and/or it MAY be 332 associated with the user traffic itself. 334 6. For scoped ancillary data, a mechanism is REQUIRED to enable an 335 LER inserting NAIs whose network actions make use of that 336 ancillary data, to determine if the NAI and ancillary data will 337 be processed by LSRs within the scope along the path. Such a 338 mechanism MAY need to determine if LSRs along the path can 339 process a specific type of AD implied by the NAI at the depth in 340 the stack that it will be presented to the LSR. 342 7. Network action specifications MUST specify if the ancillary data 343 needs to be processed as a part of the immediate forwarding 344 operation and whether packet mis-ordering is allowed to occur as 345 a result of the time taken to process the ancillary data. 347 8. In order to prevent unnecessary scanning of the packet, care 348 needs to be taken in the location of post stack ancillary data, 349 for example it SHOULD be located as close to the bottom of the 350 label stack as possible. 352 9. A solution MUST be provided to verify the authenticity of 353 ancillary data processed to LSRs [RFC3552]. 355 10. The design of the ancillary data MUST NOT expose confidential 356 information [RFC6973] [RFC3552] to the LSRs. 358 4. IANA Considerations 360 This document makes no request of IANA. 362 Note to RFC Editor: this section may be removed on publication as an 363 RFC. 365 5. Security Considerations 367 The mechanisms required by this document introduce new security 368 considerations to MPLS. Individual solution specifications meeting 369 these requirements MUST address any security considerations. 371 6. Acknowledgements 373 The authors gratefully acknowledge the contributions from Greg 374 Mirsky, Yingzhen Qu, Haoyu Song, Tarek Saad, Loa Andersson, Tony Li, 375 John Drake and Bruno Decraene. 377 The authors also gratefully acknowledge the input of the members of 378 the MPLS Open Design Team. 380 7. References 382 7.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, 387 . 389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 391 May 2017, . 393 7.2. Informative References 395 [I-D.bryant-mpls-dev-primer] 396 Bryant, S., "A Primer on the Development of MPLS", draft- 397 bryant-mpls-dev-primer-01 (work in progress), December 398 2021. 400 [I-D.saad-mpls-miad-usecases] 401 Saad, T., Makhijani, K., Song, H., and G. Mirsky, "Use 402 Cases for MPLS Function Indicators and Ancillary Data", 403 draft-saad-mpls-miad-usecases-01 (work in progress), March 404 2022. 406 [I-D.song-mpls-extension-header] 407 Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang, 408 "MPLS Extension Header", draft-song-mpls-extension- 409 header-06 (work in progress), January 2022. 411 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 412 Label Switching Architecture", RFC 3031, 413 DOI 10.17487/RFC3031, January 2001, 414 . 416 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 417 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 418 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 419 . 421 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 422 Text on Security Considerations", BCP 72, RFC 3552, 423 DOI 10.17487/RFC3552, July 2003, 424 . 426 [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol 427 Label Switching (MPLS) Management Overview", RFC 4221, 428 DOI 10.17487/RFC4221, November 2005, 429 . 431 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 432 "MPLS Generic Associated Channel", RFC 5586, 433 DOI 10.17487/RFC5586, June 2009, 434 . 436 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 437 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 438 RFC 6790, DOI 10.17487/RFC6790, November 2012, 439 . 441 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 442 Morris, J., Hansen, M., and R. Smith, "Privacy 443 Considerations for Internet Protocols", RFC 6973, 444 DOI 10.17487/RFC6973, July 2013, 445 . 447 [RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 448 and M. Bocci, "Signaling Entropy Label Capability and 449 Entropy Readable Label Depth Using IS-IS", RFC 9088, 450 DOI 10.17487/RFC9088, August 2021, 451 . 453 Authors' Addresses 455 Matthew Bocci 456 Nokia 458 Email: matthew.bocci@nokia.com 460 Stewart Bryant 461 University of Surrey 5GIC 463 Email: sb@stewartbryant.com