idnits 2.17.1 draft-bocci-mpls-miad-adi-requirements-03.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 04, 2022) is 751 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 6, 2022 University of Surrey 5GIC 6 April 04, 2022 8 Requirements for MPLS Label Stack Indicators and Ancillary Data 9 draft-bocci-mpls-miad-adi-requirements-03 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 6, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 60 3. MPLS Ancillary Data Indicator Requirements . . . . . . . . . 5 61 3.1. General Requirements . . . . . . . . . . . . . . . . . . 5 62 3.2. Requirements on ADIs . . . . . . . . . . . . . . . . . . 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 Note: This terminology and any terms used in the naming of this draft 92 may change as a result of working group consensus. Other content of 93 the draft may also change, particularly as a result of 94 [I-D.andersson-mpls-miad-fwk]. The editors will reflect this change 95 as soon as consensus is achieved. 97 1.1. Terminology 99 o Ancillary Data: Data relating to the MPLS packet that may be used 100 to affect the forwarding or other processing of that packet, 101 either at an LER [RFC4221] or LSR. This data may be encoded 102 within the label stack (in-stack data), and/or after the bottom of 103 the label stack (post-stack data). 105 o In-Stack Data: Any data within the MPLS label stack including the 106 outer LSE and the bottom of stack (the LSE with the S-bit set). 108 o Post-Stack Data: Any data beyond the LSE with the S-Bit set, but 109 before the first octet of the user payload. This document does 110 not prescribe whether post-stack data precedes or follows any 111 other protocol structure such as a control word or associated 112 channel header (ACH). 114 o Ancillary Data Indicator (ADI): A indicator in the MPLS label 115 stack that ancillary data exists in this packet. It MAY also 116 indicate the specific type of the ancillary data. [Note: the 117 framework and requirements draft authors have discussed changing 118 this to Network Action Indicators] 120 o End-to-End: End to end is defined as from one end of an LSP to the 121 terminating end of the LSP. [Note: this needs to be defined in 122 the framework]. 124 o Hop-by-Hop: From the ingress LER or an intermediate LSR to another 125 intermediate LSR or egress LSR. This implies processing along the 126 LSP rather than at the endpoints, only [Note: this needs to be 127 defined in the framework]. 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 [Reference to MIAD use cases]. [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 Ancillary Data Indicator Requirements 204 This document specifies requirements of MPLS Indicators for Ancillary 205 Data (MIAD) and the Ancillary Data itself. The requirements are for 206 the behavior of the protocol mechanisms and procedures that 207 constitute building blocks out of which indicators for ancillary data 208 are constructed. It does not specify the detailed processing that 209 may be required by an application of that ancillary data by an LSR or 210 LER. The requirements in this document do not describe what 211 functions an implementation must support. The purpose of this 212 document is to identify the toolkit and any new protocol work that is 213 required. This new protocol work MUST be based on the existing MPLS 214 architecture. 216 3.1. General Requirements 218 1. MPLS combines extensibility, flexibility and efficiency by using 219 control plane context combined with a simple data plane mechanism 220 to allow the network to make forwarding decisions about a packet. 221 Any solution MUST maintain these properties of MPLS. 223 2. Any solutions to these requirements MUST NOT restrict the 224 generality of MPLS architecture [RFC3031], [RFC3032]. 226 3. If extensions to the MPLS data plane are required, they MUST NOT 227 be inconsistent with the MPLS architecture [RFC3031], [RFC3032]. 229 4. The design of any mechanism SHOULD be such that an LSR is able to 230 efficiently parse the label stack. 232 5. Mechanisms MUST NOT add more labels to the stack than is 233 necessary. 235 3.2. Requirements on ADIs 237 1. When ancillary data is present in the MPLS label stack, a 238 mechanism is REQUIRED to indicate its presence. This mechanism 239 is the ADI. 241 2. When ancillary data is present below the MPLS label stack, a 242 mechanism is REQUIRED to indicate its presence. This mechanism 243 is the ADI. 245 3. Any solution MUST respect the principle that Special Purpose 246 Labels are the mechanism of last resort and therefore must 247 minimise the number of new SPLs that are allocated. 249 4. Solutions for the ADI MUST be able to coexist with and MUST NOT 250 obsolete existing MPLS mechanisms. 252 5. If the ADI is in the MPLS label stack, Ancillary Data Indicators 253 (ADIs) SHOULD make use of existing MPLS data plane operations. 255 6. An ADI MUST NOT be delivered to a node that is not capable of 256 processing it. That is, an ADI MUST NOT become top of stack at 257 a node that does not understand the ADI and is thus is not able 258 to perform a disposition operation on it. Disposition includes 259 both processing and ignoring. 261 7. The ADI design MUST support end-to-end (E2E) processing of 262 ancillary data. 264 8. The ADI design MUST support hop-by-hop (HBH) processing of 265 ancillary data. 267 9. If a design allows both HBH and E2E ancillary data indicators to 268 be present in the same packet, a mechanisms MUST be provided to 269 specify the precedence. 271 10. A mechanism is REQUIRED to enable an LER inserting ADIs to 272 determine if the far-end LER can accept and process a packet 273 containing a given ADI. 275 11. ADIs SHOULD be supported for both P2P and P2MP paths, but any 276 specific ADI may only be supported for one or the other. 278 12. Data plane mechanisms for ADIs MUST be independent of the 279 control plane type (LDP, RSVP, BGP, static, IGP, etc). 281 13. A mechanism MUST be defined for control planes in use (e.g. 282 LDP, RSVP, BGP, static, IGP, etc) to determine the ability of 283 downstream LSRs/LERs to accept/process a given ADI. 285 14. A mechanism is REQUIRED to enable an LSR to determine if an ADI 286 is present in a packet. 288 15. ADIs can only be inserted at LERs, but MAY be processed at LSRs 289 and LERs. If it is required to insert an ADI at a transit 290 router on an LSP, then a new label stack MUST be pushed. 292 16. It SHOULD be possible to include indicators for multiple 293 ancillary data objects in the same packet. 295 17. The solution MUST allow ADI-carrying and non-ADI-carrying 296 packets to coexist on the same LSP. 298 18. The solution MUST support the processing of a subset of the ADIs 299 on a packet. 301 19. The design of the ADIs MUST NOT expose confidential information 302 [RFC6973] [RFC3552] to the LSRs. 304 20. Any specification of a solution that inserts or modifies the ADI 305 MUST discuss the possible ECMP consequences. 307 3.3. Requirements on Ancillary Data 309 1. Solutions for ancillary data within the label stack MUST be able 310 to coexist with and MUST NOT obsolete existing MPLS mechanisms. 312 2. A common preamble for ancillary data MUST be defined so that a 313 node receiving the ancillary data can determine whether to 314 process, ignore, skip over or discard it according to network or 315 local policies. 317 3. Any specification of a mechanism MUST describe whether it can 318 coexist with existing post-stack data mechanisms e.g. control 319 words and G-ACH, and if so how this coexistence operates. 321 4. A mechanism MUST be defined for an LER inserting ancillary data 322 to determine that each node that needs to process the ancillary 323 data can read the required distance into the packet at that 324 node, for example [RFC9088]. 326 5. Ancillary data MAY be associated with control or maintenance 327 information for traffic carried by an LSP, and/or it MAY be 328 associated with the user traffic itself. 330 6. For HBH ancillary data, a mechanism is REQUIRED to enable an LER 331 inserting ADIs to determine if the ADI will be processed by LSRs 332 along the path. Such a mechanism MAY need to determine if LSRs 333 along the path can process a specific type of AD indicated by 334 the ADI at the depth in the stack that it will be presented to 335 the LSR. 337 7. Application specifications MUST specify if the ancillary data 338 needs to be processed as a part of the immediate forwarding 339 operation and whether packet mis-ordering is allowed to occur as 340 a result of the time taken to process the ancillary data. 342 8. In order to prevent unnecessary scanning of the packet, care 343 needs to be taken in the location of post stack ancillary data, 344 for example it SHOULD be located as close to the bottom of the 345 label stack as possible. 347 9. A solution MUST be provided to verify the authenticity of 348 ancillary data processed to LSRs [RFC3552]. 350 10. The design of the ancillary data MUST NOT expose confidential 351 information [RFC6973] [RFC3552] to the LSRs. 353 4. IANA Considerations 355 This document makes no request of IANA. 357 Note to RFC Editor: this section may be removed on publication as an 358 RFC. 360 5. Security Considerations 362 The mechanisms required by this document introduce new security 363 considerations to MPLS. Individual solution specifications meeting 364 these requirements MUST address any security considerations. 366 6. Acknowledgements 368 The authors gratefully acknowledge the contributions from Greg 369 Mirsky, Yingzhen Qu, Haoyu Song, Tarek Saad, Loa Andersson, and Bruno 370 Decraene. 372 The authors also gratefully acknowledge the input of the members of 373 the MPLS Open Design Team. 375 7. References 377 7.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 385 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 386 May 2017, . 388 7.2. Informative References 390 [I-D.andersson-mpls-miad-fwk] 391 Andersson, L., Bryant, S., and M. Bocci, "MPLS MIAD 392 Framework", draft-andersson-mpls-miad-fwk-01 (work in 393 progress), March 2022. 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