idnits 2.17.1 draft-bocci-mpls-miad-adi-requirements-02.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 (March 03, 2022) is 783 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-00 == 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: September 4, 2022 University of Surrey 5GIC 6 March 03, 2022 8 Requirements for MPLS Label Stack Indicators and Ancillary Data 9 draft-bocci-mpls-miad-adi-requirements-02 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 September 4, 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 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. MPLS Ancillary Data Indicator Requirements . . . . . . . . . 5 60 3.1. General Requirements . . . . . . . . . . . . . . . . . . 5 61 3.1.1. Requirements on ADIs . . . . . . . . . . . . . . . . 5 62 3.1.2. Requirements on Ancillary Data . . . . . . . . . . . 7 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 7.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 There is significant interest in developing the MPLS data plane to 74 address the requirements of new applications 75 [I-D.saad-mpls-miad-usecases]. These applications typically require 76 the inclusion of ancillary data in the MPLS packet. This data may be 77 encoded either in the label stack or below the bottom of the label 78 stack. This data is then either intercepted and processed, or some 79 other forwarding decision is taken by routers processing the packet. 80 The ancillary data is added by the ingress LSR, and then makes use of 81 mechanisms implemented by an/or intermediate or egress LSRs that 82 comply with the MPLS base architecture and potentially its 83 extensions, including (but not limited to) [RFC3031], [RFC3032], 84 [RFC6790]. 86 This draft specifies requirements for indicators in the MPLS label 87 stack to support these applications, as well as the encoding and use 88 of the ancillary data. 90 1.1. Terminology 92 o Ancillary Data: Data relating to the MPLS packet that may be used 93 to affect the forwarding or other processing of that packet, 94 either at an LER [RFC4221] or LSR. This data may be encoded 95 within the label stack (in-stack data), and/or after the bottom of 96 the label stack (post-stack data). 98 o In-Stack Data: Any data within the MPLS label stack including the 99 outer LSE and the bottom of stack (the LSE with the S-bit set). 101 o Post-Stack Data: Any data beyond the LSE with the S-Bit set, but 102 before the first octet of the user payload. This document does 103 not prescribe whether post-stack data precedes or follows any 104 other protocol structure such as a control word or associated 105 channel header (ACH). 107 o Ancillary Data Indicator (ADI): A indicator in the MPLS label 108 stack that ancillary data exists in this packet. It MAY also 109 indicate the specific type of the ancillary data. 111 o End-to-End: End to end is defined as from one end of an LSP to the 112 terminating end of the LSP.[Ed. this needs to be defined in the 113 framework]. 115 o Hop-by-Hop: From the ingress LER or an intermediate LSR to another 116 intermediate LSR or egress LSR. This implies processing along the 117 LSP rather than at the endpoints, only [Ed. this needs to be 118 defined in the framework]. ## Background 120 The MPLS architecture is specified in [RFC3031] and provides a 121 mechanism for forwarding packets through a network without requiring 122 any analysis of the packet payload's network layer header by 123 intermediate nodes (Label Switching Routers - LSRs). Formally, 124 inspection may only occur at network ingress (the Label edge router - 125 LER) where the packet is assigned to a forwarding equivalence class 126 (FEC). 128 MPLS uses switching based on a label pushed on the packet to achieve 129 efficient forwarding and traffic engineering of flows associated with 130 the FEC. While originally used for IP traffic, MPLS has been 131 extended to support point-to-point, point-to-multipoint and 132 multipoint-to-multipoint layer 2 and layer 3 services. An overview 133 of the development of MPLS is provided in 134 [I-D.bryant-mpls-dev-primer]. 136 A number of applications have emerged which require LSRs to make 137 forwarding or other processing decisions based on inspection of the 138 network layer header, or some other ancillary information in the 139 protocol stack encapsulated deeper in the packet. An early example 140 of this was generation of a hash of the payload header to be used for 141 load balancing over Equal Cost Multipath (ECMP) or Link Aggregation 142 Group (LAG) next hops. This is based on an assumption that the 143 network layer protocol is IP. MPLS was extended to avoid the need 144 for LSRs to perform this operation if load balancing was needed based 145 on the payload and instead use only the MPLS label stack, using the 146 Entropy Label / Entropy Label Indicator [RFC6790] which are inserted 147 at the LER. Other applications where the intermediate LSRs may need 148 to inspect and process a packet on an LSP include OAM, which can make 149 use of mechanisms such the Router Alert Label [RFC3032] or the 150 Generic Associated Channel Label (GAL) [RFC5586] to indicate that an 151 intercepted packet should be processed locally. See 152 [I-D.bryant-mpls-dev-primer] for detailed list of such applications. 154 There have been a number of new proposals for how ancillary data is 155 carried in MPLS and how its presence is indicated to the LSR or 156 egress LER, for example In-situ OAM and Service Function Chaining 157 (SFC). A summary of these proposals is contained in 158 [I-D.bryant-mpls-dev-primer], an overview of use cases is provided in 159 [Reference to MIAD use cases]. [I-D.song-mpls-extension-header] 160 summarises some of the issues with existing solutions to address 161 these new applications (note that this document draws on the 162 requirements and issues without endorsing a specific solution from 163 [I-D.song-mpls-extension-header]): 165 These solutions rely on either the built-in next-protocol 166 indicator in the header or the knowledge of the format and size of 167 the header to access the following packet data. The node is 168 required to be able to parse the new header, which is unrealistic 169 in an incremental deployment environment. 171 A piecemeal solution often assumes the new header is the only 172 extra header and its location in the packet is fixed by default. 173 It is impossible or difficult to support multiple new headers in 174 one packet due to the conflicted assumption. An example of this 175 is that the GAL/G-ACH mechanism assumes that if the GAL is 176 present, only a single G-ACH header follows. 178 New applications therefore require the definition of extensions to 179 the MPLS architecture and label stack operations that can be used 180 across these applications in order to minimise implementation 181 complexity and promote interoperability and extensibility. 183 2. Requirements Language 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 187 "OPTIONAL" in this document are to be interpreted as described in BCP 188 14 [RFC2119] [RFC8174] when, and only when, they appear in all 189 capitals, as shown here. 191 3. MPLS Ancillary Data Indicator Requirements 193 This document specifies requirements of MPLS Indicators for Ancillary 194 Data (MIAD) and the Ancillary Data itself. The requirements are for 195 the behavior of the protocol mechanisms and procedures that 196 constitute building blocks out of which indicators for ancillary data 197 are constructed. It does not specify the detailed processing that 198 may be required by an application of that ancillary data by an LSR or 199 LER. The requirements in this document do not describe what 200 functions an implementation must support. The purpose of this 201 document is to identify the toolkit and any new protocol work that is 202 required. This new protocol work MUST be based on the existing MPLS 203 architecture. 205 [Ed. Note: for each of the sections below, we need to validate the 206 order of the requirements]. 208 3.1. General Requirements 210 1. MPLS combines extensibility, flexibility and efficiency by using 211 control plane context combined with a simple data plane mechanism 212 to allow the network to make forwarding decisions about a packet. 213 Any solution MUST maintain these properties of MPLS. 215 2. Any solutions to these requirements MUST NOT restrict the 216 generality of MPLS architecture [RFC3031], [RFC3032]. 218 3. If extensions to the MPLS data plane are required, they MUST NOT 219 be inconsistent with the MPLS architecture [RFC3031], [RFC3032]. 221 4. The design of any mechanism SHOULD be such that an LSR is able to 222 efficiently parse the label stack. 224 5. Mechanisms MUST NOT add more labels to the stack than is 225 necessary. 227 3.1.1. Requirements on ADIs 229 1. When ancillary data is present in the MPLS label stack, a 230 mechanism is REQUIRED to indicate its presence. This mechanism 231 is the ADI. 233 2. When ancillary data is present below the MPLS label stack, a 234 mechanism is REQUIRED to indicate its presence. This mechanism 235 is the ADI. 237 3. Any solution MUST respect the principle that Special Purpose 238 Labels are the mechanism of last resort and therefore must 239 minimise the number of new SPLs that are allocated. 241 4. Solutions for the ADI MUST be able to coexist with and MUST NOT 242 obsolete existing MPLS mechanisms. 244 5. If the ADI is in the MPLS label stack, Ancillary Data Indicators 245 (ADIs) SHOULD make use of existing MPLS data plane operations. 247 6. An ADI MUST NOT be delivered to a node that is not capable of 248 processing it. That is, an ADI MUST NOT become top of stack at 249 a node that does not understand the ADI and is thus is not able 250 to perform a disposition operation on it. Disposition includes 251 both processing and ignoring. 253 7. The ADI design MUST support end-to-end (E2E) processing of 254 ancillary data. 256 8. The ADI design MUST support hop-by-hop (HBH) processing of 257 ancillary data. 259 9. If a design allows both HBH and E2E ancillary data indicators to 260 be present in the same packet, a mechanisms MUST be provided to 261 specify the precedence. 263 10. A mechanism is REQUIRED to enable an LER inserting ADIs to 264 determine if the far-end LER can accept and process a packet 265 containing a given ADI. 267 11. ADIs SHOULD be supported for both P2P and P2MP paths, but any 268 specific ADI may only be supported for one or the other. 270 12. Data plane mechanisms for ADIs MUST be independent of the 271 control plane type (LDP, RSVP, BGP, static, IGP, etc). 273 13. A mechanism MUST be defined for control planes in use (e.g. 274 LDP, RSVP, BGP, static, IGP, etc) to determine the ability of 275 downstream LSRs/LERs to accept/process a given ADI. 277 14. A mechanism is REQUIRED to enable an LSR to determine if an ADI 278 is present in a packet. 280 15. ADIs can only be inserted at LERs, but MAY be processed at LSRs 281 and LERs. If it is required to insert an ADI at a transit 282 router on an LSP, then a new label stack MUST be pushed. 284 16. It SHOULD be possible to include indicators for multiple 285 ancillary data objects in the same packet. 287 17. The solution MUST allow ADI-carrying and non-ADI-carrying 288 packets to coexist on the same LSP. 290 18. The solution MUST support the processing of a subset of the ADIs 291 on a packet. 293 19. The design of the ADIs MUST NOT expose confidential information 294 [RFC6973] [RFC3552] to the LSRs. 296 20. Any specification of a solution that inserts or modifies the ADI 297 MUST discuss the possible ECMP consequences. 299 3.1.2. Requirements on Ancillary Data 301 1. Solutions for ancillary data within the label stack MUST be able 302 to coexist with and MUST NOT obsolete existing MPLS mechanisms. 304 2. A common mechanism for ancillary data MUST be defined so that a 305 node receiving the ancillary data can determine whether to 306 process, ignore or discard it. 308 3. Any specification of a mechanism MUST describe whether it can 309 coexist with existing post-stack data mechanisms e.g. control 310 words and G-ACH, and if so how this coexistence operates. 312 4. A mechanisms SHOULD be defined for an LER or LSR inserting 313 ancillary data to determine that each node that needs to process 314 the ancillary data can read the required distance into the 315 packet at that node, for example [RFC9088]. 317 5. Ancillary data MAY be associated with control or maintenance 318 information for traffic carried by an LSP, and/or it MAY be 319 associated with the user traffic itself. 321 6. For HBH ancillary data, a mechanism is REQUIRED to enable an LER 322 inserting ADIs to determine if the ADI will be processed by LSRs 323 along the path. This MAY require a mechanism to determine if 324 LSRs along the lath can process a specific type of AD indicated 325 by the ADI at the depth in the stack that it will be presented 326 to the LSR. 328 7. Application specifications MUST specify if the ancillary data 329 needs to be processed as a part of the immediate forwarding 330 operation and whether packet mis-ordering is allowed to occur as 331 a result of the time taken to process the ancillary data. 333 8. In order to prevent unnecessary scanning of the packet, care 334 needs to be taken in the location of the ancillary data, for 335 example it SHOULD be located as close to the label stack as 336 possible. 338 9. A solution MUST be provided to verify the authenticity of 339 ancillary data processed to LSRs [RFC3552]. 341 10. The design of the ancillary data MUST NOT expose confidential 342 information [RFC6973] [RFC3552] to the LSRs. 344 4. IANA Considerations 346 This document makes no request of IANA. 348 Note to RFC Editor: this section may be removed on publication as an 349 RFC. 351 5. Security Considerations 353 The mechanisms required by this document introduce new security 354 considerations to MPLS. Individual solution specifications meeting 355 these requirements MUST address any security considerations. 357 6. Acknowledgements 359 The authors gratefully acknowledge the contributions from Yingzhen 360 Qu, Haoyu Song, Tarek Saad, Loa Andersson, and Bruno Decraene. 362 The authors also gratefully acknowledge the input of the members of 363 the MPLS Open Design Team. 365 7. References 367 7.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 375 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 376 May 2017, . 378 7.2. Informative References 380 [I-D.bryant-mpls-dev-primer] 381 Bryant, S., "A Primer on the Development of MPLS", draft- 382 bryant-mpls-dev-primer-01 (work in progress), December 383 2021. 385 [I-D.saad-mpls-miad-usecases] 386 Saad, T., Makhijani, K., and H. Song, "Usecases for MPLS 387 Indicators and Ancillary Data", draft-saad-mpls-miad- 388 usecases-00 (work in progress), January 2022. 390 [I-D.song-mpls-extension-header] 391 Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang, 392 "MPLS Extension Header", draft-song-mpls-extension- 393 header-06 (work in progress), January 2022. 395 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 396 Label Switching Architecture", RFC 3031, 397 DOI 10.17487/RFC3031, January 2001, 398 . 400 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 401 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 402 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 403 . 405 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 406 Text on Security Considerations", BCP 72, RFC 3552, 407 DOI 10.17487/RFC3552, July 2003, 408 . 410 [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol 411 Label Switching (MPLS) Management Overview", RFC 4221, 412 DOI 10.17487/RFC4221, November 2005, 413 . 415 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 416 "MPLS Generic Associated Channel", RFC 5586, 417 DOI 10.17487/RFC5586, June 2009, 418 . 420 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 421 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 422 RFC 6790, DOI 10.17487/RFC6790, November 2012, 423 . 425 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 426 Morris, J., Hansen, M., and R. Smith, "Privacy 427 Considerations for Internet Protocols", RFC 6973, 428 DOI 10.17487/RFC6973, July 2013, 429 . 431 [RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 432 and M. Bocci, "Signaling Entropy Label Capability and 433 Entropy Readable Label Depth Using IS-IS", RFC 9088, 434 DOI 10.17487/RFC9088, August 2021, 435 . 437 Authors' Addresses 439 Matthew Bocci 440 Nokia 442 Email: matthew.bocci@nokia.com 444 Stewart Bryant 445 University of Surrey 5GIC 447 Email: sb@stewartbryant.com