idnits 2.17.1 draft-saad-mpls-miad-usecases-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 January 2022) is 840 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-bestbar-teas-ns-packet-06 == Outdated reference: A later version (-05) exists of draft-decraene-mpls-slid-encoded-entropy-label-id-02 == Outdated reference: A later version (-12) exists of draft-gandhi-mpls-ioam-01 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-03 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-05 == Outdated reference: A later version (-03) exists of draft-kompella-mpls-mspl4fa-01 == Outdated reference: A later version (-03) exists of draft-li-mpls-enhanced-vpn-vtn-id-01 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group T. Saad 3 Internet-Draft Juniper Networks 4 Intended status: Informational K. Makhijani 5 Expires: 11 July 2022 H. Song 6 Futurewei Technologies 7 7 January 2022 9 Usecases for MPLS Indicators and Ancillary Data 10 draft-saad-mpls-miad-usecases-00 12 Abstract 14 This document presents a number of use cases that have a common need 15 for encoding MPLS function indicators and ancillary data inside MPLS 16 packets. The use cases described are not an exhaustive set, but 17 rather the ones that are actively discussed at the MPLS Working 18 Group. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 11 July 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 56 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. In-situ OAM . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Network Slicing . . . . . . . . . . . . . . . . . . . . . 4 59 2.2.1. Global Identifier as Slice Selector . . . . . . . . . 5 60 2.2.2. Forwarding Label as a Slice Selector . . . . . . . . 6 61 2.3. Time Sensitive Networking . . . . . . . . . . . . . . . . 6 62 2.3.1. Stack-based Methods for Latency Control . . . . . . . 6 63 2.3.2. Stack Entry Format . . . . . . . . . . . . . . . . . 7 64 2.4. NSH Based Service Function Chaining . . . . . . . . . . . 7 65 2.5. Network Programming . . . . . . . . . . . . . . . . . . . 7 66 2.6. Application Aware Networking (APN) . . . . . . . . . . . 8 67 3. Co-existence of Usecases . . . . . . . . . . . . . . . . . . 8 68 3.1. IOAM with Network Slicing . . . . . . . . . . . . . . . . 8 69 3.2. IOAM with Time Sensitive Networking . . . . . . . . . . . 8 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 8.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 This document describes important cases that require carrying 82 additional ancillary data within the MPLS packets, as well as the 83 means to indicate ancillary data is present. 85 These use cases have been identified by the MPLS working group design 86 team working on defining MPLS function indicators and ancillary data 87 for the MPLS data plane. The use cases described in this document 88 will be used to assist in identifying requirements and issues to be 89 considered for future resolution by the working group. 91 * ID: draft-gandhi-mpls-ioam describes applicability of IOAM to MPLS 92 dataplane. 94 * RFC 8986 describes the network programming usecase for SRv6 95 dataplane. 97 * RFC 8595 describes solution for MPLS-based forwarding for Service 98 Function Chaining 100 1.1. Terminology 102 The following terminology is used in the document: 104 IETF Network Slice: 105 a well-defined composite of a set of endpoints, the connectivity 106 requirements between subsets of these endpoints, and associated 107 requirements; the term 'network slice' in this document refers to 108 'IETF network slice' as defined in 109 [I-D.ietf-teas-ietf-network-slices]. 111 IETF Network Slice Controller (NSC): 112 controller that is used to realize an IETF network slice 113 [I-D.ietf-teas-ietf-network-slices]. 115 Network Resource Partition: 116 the collection of resources that are used to support a slice 117 aggregate. 119 Time Sensitive Networking: 120 Networks that transport time sensitive traffic. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 1.2. Acronyms and Abbreviations 130 MIAD: MPLS Label Stack Indicators for Ancillary Data 132 ISD: In-stack data 134 PSD: Post-stack data 136 MPLS: Multiprotocol Label Switching 138 2. Use Cases 140 2.1. In-situ OAM 142 In-situ Operations, Administration, and Maintenance (IOAM) records 143 operational and telemetry information within the packet while the 144 packet traverses a particular path in a network domain. 146 The term "in-situ" refers to the fact that the IOAM data fields are 147 added to the data packets rather than being sent within the probe 148 packets specifically dedicated to OAM or Performance Measurement 149 (PM). 151 IOAM can run in two modes End-to-End (E2E) and Hop-by-Hop (HbH). In 152 E2E mode, only the encapsulating and decapsulating nodes will process 153 IOAM data fields. In HbH mode, the encapsulating and decapsulating 154 nodes as well as intermediate nodes process IOAM data fields. 156 The IOAM data fields are defined in [I-D.ietf-ippm-ioam-data], and 157 can be used for various use-cases of OAM and PM. 159 [I-D.gandhi-mpls-ioam-sr] defines how IOAM data fields are 160 transported using the MPLS data plane encapsulations, including 161 Segment Routing (SR) with MPLS data plane (SR-MPLS). 163 IOAM data are added after the bottom of the label stack. The IOAM 164 data fields can be of fixed or incremental size as defined in 165 [I-D.ietf-ippm-ioam-data]. [I-D.gandhi-mpls-ioam] describes 166 applicability of IOAM to MPLS dataplane. The encapsulating MPLS node 167 needs to know if the decapsulating MPLS node can process the IOAM 168 data before adding it in the packet. 170 2.2. Network Slicing 172 [I-D.ietf-teas-ietf-network-slices] specifies the definition of a 173 network slice for use within the IETF and discusses the general 174 framework for requesting and operating IETF Network Slices, their 175 characteristics, and the necessary system components and interfaces. 177 Multiple network slices can be realized on top of a single shared 178 network. 180 In order to overcome scale challenges, IETF Network Slices may be 181 aggregated into groups according to similar characteristics. The 182 slice aggregate [I-D.bestbar-teas-ns-packet] is a construct that 183 comprises of the traffic flows of one or more IETF Network Slices of 184 similar characteristics. 186 A router that requires forwarding of a packet that belongs to a slice 187 aggregate may have to decide on the forwarding action to take based 188 on selected next-hop(s), and the forwarding treatment (e.g., 189 scheduling and drop policy) to enforce based on the associated per- 190 hop behavior. 192 The routers in the network that forward traffic over links that are 193 shared by multiple slice aggregates need to identify the slice 194 aggregate packets in order to enforce the associated forwarding 195 action and treatment. 197 An IETF network slice need MAY support the following key features: 199 1. A Slice Selector 201 2. A Network Resource Partition associated with a slice aggregate. 203 3. A Path selection criteria 205 4. Verification that per slice SLOs are being met. This may be done 206 by active measurements (inferred) or by using IOAM. 208 5. Additionally, there is an on-going discussion on using Service 209 Functions (SFs) with network slices. This may require insertion 210 of an NSH. 212 6. For multi-domain scenarios, a packet that traverses multiple 213 domains may encode different identifiers within each domain. 215 2.2.1. Global Identifier as Slice Selector 217 A Global Identifier as a Slice Selector (GISS) can be encoded in the 218 MPLS packet as defined in [I-D.kompella-mpls-mspl4fa], 219 [I-D.li-mpls-enhanced-vpn-vtn-id], and 220 [I-D.decraene-mpls-slid-encoded-entropy-label-id]. The Global 221 Identifier Slice Selector can be used to associate the packets to the 222 slice aggregate, independent of the MPLS forwarding label that is 223 bound to the destination. LSRs use the MPLS forwarding label to 224 determine the forwarding next-hop(s), and use the Global Identifier 225 Slice Selector field in the packet to infer the specific forwarding 226 treatment that needs to be applied on the packet. 228 The GISS can be encoded within an MPLS label that is carried in the 229 packet's MPLS label stack. All packets that belong to the same slice 230 aggregate MAY carry the same GISS in the MPLS label stack. It is 231 also possible to have multiple GISS's map to the same slice 232 aggregate. The GISS can be encoded in an MPLS label and may appear 233 in several positions in the MPLS label stack. 235 2.2.2. Forwarding Label as a Slice Selector 237 [RFC3031] states in Section 2.1 that: 'Some routers analyze a 238 packet's network layer header not merely to choose the packet's next 239 hop, but also to determine a packet's "precedence" or "class of 240 service"'. 242 It is possible by assigning a unique MPLS forwarding label to each 243 slice aggregate (FEC) to distinguish the packets forwarded to the 244 same destination but that belong to different slice aggregates. In 245 this case, LSRs can use the top forwarding label to infer both the 246 forwarding action and the forwarding treatment to be invoked on the 247 packets. A similar approach is described in 248 [I-D.ietf-spring-resource-aware-segments] and 249 [I-D.bestbar-teas-ns-packet]. 251 2.3. Time Sensitive Networking 253 The routers in a network can perform two distinct functions on 254 incoming packets, namely forwarding (where the packet should be sent) 255 and scheduling (when the packet should be sent). Time Sensitive 256 Networking (TSN) and Deterministic Networking provide several 257 mechanisms for scheduling under the assumption that routers are time 258 synchronized. The most effective mechanisms for delay minimization 259 involve per-flow resource allocation. 261 Segment Routing (SR) is a forwarding paradigm that allows encoding 262 forwarding instructions in the packet in a stack data structure, 263 rather than being programmed into the routers. The SR instructions 264 are contained within a packet in the form of a first-in first-out 265 stack dictating the forwarding decisions of successive routers. 266 Segment routing may be used to choose a path sufficiently short to be 267 capable of providing sufficiently low end- to-end latency but does 268 not influence the queueing of individual packets in each router along 269 that pat 271 TSN is required for networks transporting time sensitive traffic, 272 that is, packets that are required to be delivered to their final 273 destination by a given time. 275 2.3.1. Stack-based Methods for Latency Control 277 One efficient data structure for inserting local deadlines into the 278 headers is a "stack", similar to that used in Segment Routing to 279 carry forwarding instructions. The number of deadline values in the 280 stack equals the number of routers the packet needs to traverse in 281 the network, and each deadline value corresponds to a specific 282 router. The Top-of-Stack (ToS) corresponds to the first router's 283 deadline while the Bottom-of-Stack (BoS) refers to the last's. All 284 local deadlines in the stack are later or equal to the current time 285 (upon which all routers agree), and times closer to the ToS are 286 always earlier or equal to times closer to the BoS. 288 The ingress router inserts the deadline stack into the packet 289 headers; no other router needs to be aware of the requirements of the 290 time sensitive flows. Hence admitting a new flow only requires 291 updating the information base of the ingress router. 293 MPLS LSRs that expose the Top of Stack (ToS) label can also inspect 294 the associated "deadline" carried in the packet (either in MPLS stack 295 or after BoS). 297 2.3.2. Stack Entry Format 299 A number of different time formats commonly used in networking 300 applications and can be used to encode the local deadlines. 302 For the forwarding sub-entry we could adopt like SR-MPLS standard 303 32-bit MPLS labels (which contain a 20-bit label and BoS bit), and 304 thus SR-TSN stack entries could be 64-bits in size comprising a 305 32-bit MPLS label and the aforementioned nonstandard 32-bit 306 timestamp. 308 Alternatively, an SR-TSN stack entry could be 96 bits in length 309 comprising a 32-bit MPLS label and either of the standardized 64-bit 310 timestamps. 312 2.4. NSH Based Service Function Chaining 314 The Network Service Header (NSH) can be embedded in an Extended 315 Header (EH) to support the Path ID and any metadata that needs to be 316 carried and exchanged between Service Function Forwarders (SFFs). 318 A reference to the NSH SFC use case is defined in [RFC8596]. 320 2.5. Network Programming 322 In SR, an ingress node steers a packet through an ordered list of 323 instructions, called "segments". Each one of these instructions 324 represents a function to be called at a specific location in the 325 network. A function is locally defined on the node where it is 326 executed and may range from simply moving forward in the segment list 327 to any complex user-defined behavior. 329 Network Programming combines Segment Routing (SR) functions to 330 achieve a networking objective that goes beyond mere packet routing. 332 It may be desirable to encode a pointers to function and its 333 function-arguments within an MPLS packet transport header. For 334 example, in MPLS we can encode the FUNC::ARGs within the label stack 335 or after the bottom of stack to support the equivalent of FUNC::ARG 336 in SRv6 as described in [RFC8986]. 338 2.6. Application Aware Networking (APN) 340 Application-aware Networking (APN) allows application-aware 341 information (i.e., APN attribute) including APN identification (ID) 342 and/or APN parameters (e.g. network performance requirements) to be 343 encapsulated at network edge devices and carried in packets 344 traversing an APN domain in order to facilitate service provisioning, 345 perform fine-granularity traffic steering and network resource 346 adjustment. To support APN in MPLS networks, mechanisms are needed 347 to hold the APN attribute. 349 3. Co-existence of Usecases 351 Two or more of the aforementioned use cases MAY co-exist in the same 352 packet. Some examples of such usecases are described below. 354 3.1. IOAM with Network Slicing 356 IOAM may provide key functions with network slicing to help ensure 357 that critical network slice SLOs are being met by the network 358 provider. 360 In such a case, IOAM is able collect key performance measurement 361 parameters of network slice traffic flows as it traverses the 362 transport network. 364 This may require, in addition to carrying a specific network slice 365 selector (e.g., GISS), the MPLS network slice packets may have to 366 also carry IOAM ancillary data. 368 Note that the IOAM ancillary data may have to be modified, and 369 updated on some/all LSRs traversed by the network slice MPLS packets. 371 3.2. IOAM with Time Sensitive Networking 373 IOAM operation may also be desirable on MPLS packets that carry time- 374 sensitive related data. Similarly, this may require the presence of 375 multiple ancillary data (whether In-stack or Post-stack ancillary 376 data) to be present in the same MPLS packet. 378 4. IANA Considerations 380 This document has no IANA actions. 382 5. Security Considerations 384 This document introduces no new security considerations. 386 6. Acknowledgement 388 The authors gratefully acknowledge the input of the members of the 389 MPLS Open Design Team. 391 7. Contributors 393 The following individuals contributed to this document: 395 Kiran Makhijani 396 Futurewei Technologies 397 Email: kiranm@futurewei.com 399 Haoyu Song 400 Futurewei Technologies 401 Email: haoyu.song@futurewei.com 403 Loa Andersson 404 Bronze Dragon Consulting 405 Email: loa@pi.nu 407 8. References 409 8.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, 413 DOI 10.17487/RFC2119, March 1997, 414 . 416 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 417 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 418 May 2017, . 420 8.2. Informative References 422 [I-D.bestbar-teas-ns-packet] 423 Saad, T., Beeram, V. P., Wen, B., Ceccarelli, D., Halpern, 424 J., Peng, S., Chen, R., Liu, X., Contreras, L. M., Rokui, 425 R., and L. Jalil, "Realizing Network Slices in IP/MPLS 426 Networks", Work in Progress, Internet-Draft, draft- 427 bestbar-teas-ns-packet-06, 22 December 2021, 428 . 431 [I-D.decraene-mpls-slid-encoded-entropy-label-id] 432 Decraene, B., Filsfils, C., Henderickx, W., Saad, T., 433 Beeram, V. P., and L. Jalil, "Using Entropy Label for 434 Network Slice Identification in MPLS networks.", Work in 435 Progress, Internet-Draft, draft-decraene-mpls-slid- 436 encoded-entropy-label-id-02, 6 August 2021, 437 . 440 [I-D.gandhi-mpls-ioam] 441 Gandhi, R., Ali, Z., Brockners, F., Wen, B., Decraene, B., 442 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 443 OAM Data", Work in Progress, Internet-Draft, draft-gandhi- 444 mpls-ioam-01, 9 September 2021, 445 . 448 [I-D.gandhi-mpls-ioam-sr] 449 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 450 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 451 OAM Data", Work in Progress, Internet-Draft, draft-gandhi- 452 mpls-ioam-sr-06, 18 February 2021, 453 . 456 [I-D.ietf-ippm-ioam-data] 457 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 458 for In-situ OAM", Work in Progress, Internet-Draft, draft- 459 ietf-ippm-ioam-data-17, 13 December 2021, 460 . 463 [I-D.ietf-spring-resource-aware-segments] 464 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 465 Z., and F. Clad, "Introducing Resource Awareness to SR 466 Segments", Work in Progress, Internet-Draft, draft-ietf- 467 spring-resource-aware-segments-03, 12 July 2021, 468 . 471 [I-D.ietf-teas-ietf-network-slices] 472 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 473 Makhijani, K., Contreras, L. M., and J. Tantsura, 474 "Framework for IETF Network Slices", Work in Progress, 475 Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25 476 October 2021, . 479 [I-D.kompella-mpls-mspl4fa] 480 Kompella, K., Beeram, V. P., Saad, T., and I. Meilik, 481 "Multi-purpose Special Purpose Label for Forwarding 482 Actions", Work in Progress, Internet-Draft, draft- 483 kompella-mpls-mspl4fa-01, 12 July 2021, 484 . 487 [I-D.li-mpls-enhanced-vpn-vtn-id] 488 Li, Z. and J. Dong, "Carrying Virtual Transport Network 489 Identifier in MPLS Packet", Work in Progress, Internet- 490 Draft, draft-li-mpls-enhanced-vpn-vtn-id-01, 14 April 491 2021, . 494 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 495 Label Switching Architecture", RFC 3031, 496 DOI 10.17487/RFC3031, January 2001, 497 . 499 [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 500 "MPLS Transport Encapsulation for the Service Function 501 Chaining (SFC) Network Service Header (NSH)", RFC 8596, 502 DOI 10.17487/RFC8596, June 2019, 503 . 505 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 506 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 507 (SRv6) Network Programming", RFC 8986, 508 DOI 10.17487/RFC8986, February 2021, 509 . 511 Authors' Addresses 513 Tarek Saad 514 Juniper Networks 516 Email: tsaad@juniper.net 518 Kiran Makhijani 519 Futurewei Technologies 520 Email: kiranm@futurewei.com 522 Haoyu Song 523 Futurewei Technologies 525 Email: haoyu.song@futurewei.com