idnits 2.17.1 draft-andersson-mpls-indicators-and-anxillary-data-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 9, 2021) is 1042 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Andersson 3 Internet-Draft Bronze Dragon Consulting 4 Intended status: Informational June 9, 2021 5 Expires: December 11, 2021 7 Indicators and anxillary data in the MPLS Label Stack 8 draft-andersson-mpls-indicators-and-anxillary-data-00 10 Abstract 12 This document is a living document, meaning that during the life 13 timme of the MPLS Open Design Team we will to survey the relationship 14 between indicators and anxillary dat. 16 Ideally when the Design Team is closed this document will be empty, 17 or maybe we just add a pointer to where the answer to quesstion is 18 documented. Thus this document will never go on to become an RFCc. 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 December 11, 2021. 37 Copyright Notice 39 Copyright (c) 2021 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 2 56 1.2. Local terminology . . . . . . . . . . . . . . . . . . . . 3 57 1.2.1. Indicator . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2.2. Anxillary Data . . . . . . . . . . . . . . . . . . . 3 59 1.2.3. Scan, Parse and Readable Depth . . . . . . . . . . . 3 60 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Combiinations or Indicators anbd Anxillary Data . . . . . . . 4 62 3.1. No extra data . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Associated Channel Style . . . . . . . . . . . . . . . . 5 64 3.3. Extended Associated Channel Style . . . . . . . . . . . . 5 65 3.4. Modified Associated Channel Style . . . . . . . . . . . . 6 66 3.5. Modified Associated Channel Style . . . . . . . . . . . . 7 67 3.6. Enhanced Associated Channel Style . . . . . . . . . . . . 8 68 3.7. Enhanced Associated Channel Style . . . . . . . . . . . . 9 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 6. Normative References . . . . . . . . . . . . . . . . . . . . 11 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 This document discusses in-label-stack indicators to locate anxillary 77 data carried in the label stack or after the Bottom of Stack (BoS) 78 bit. 80 The document is intended to be a "living document", meaning that it 81 will be updated as long as the Open DT finds it useful, but it is not 82 intended to become an RFC. Information in this document might be 83 captured in "real" output documents from the Open DT. 85 "Living Documents" are not commonly used in the IETF, but we have 86 considered it to be a good way of documenting the state of the issues 87 worked on by the design team. 89 1.1. Requirement Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 For a document that is not intended to become and RFC on the 98 Standards Track it might seem moot to have the requirement language 99 included, however it might be that a question or an answer to one of 100 the questions might use the BCP 14 language, so to avoid ambiguity we 101 left it in. 103 1.2. Local terminology 105 Two terms are frequently used in this document. "indicator" and 106 "anxillary data". This section gives a high level definition of the 107 two terms. 109 1.2.1. Indicator 111 An indicator is a Spoecial Purpose Label (bSPL or eSPL), or part of 112 such a label, carried in MPLS Lael Stack. 114 1.2.2. Anxillary Data 116 Anxillary data is data that is used to improve the precission of 117 packet forwarding, it can be carried as part of a indicator label or 118 after the the label with BoS bit set. 120 1.2.3. Scan, Parse and Readable Depth 122 The three terms are used in the context of finding e.g. indicators or 123 the BoS in a label stack. 125 The terms "scan" and "parse" are virtually synonymous aand relates to 126 an activity to consequtively read the labels in a label stack in 127 order to find certain information. 129 Readable depths tell you have deep into the label stack a scanning 130 (a.k.a parsing) operation can go, expressed in the number of labels. 132 2. Background 134 When MPLS was first designed the label stack was fairly simple, you 135 had a label at the top of the stack on which a forwarding decision 136 were taken. The only exception the few labels (values 0-15) that 137 were set aside as Special Purpose Labels, such labels have a special 138 action or interpretation assigned to them. 140 When Pseudowires were designed it beccame clear that i would be 141 beneficial to be possible to send anxillary data together with the 142 MPLS packets that transported the Pseudowire payload data. 144 The method develooped was to create an Associated Channel as a shim 145 between the bottom of the label stack and the Pseudowire payload. 147 When the MPLS Transport Profile (MPLS-TP) the assiciated channel were 148 were generalized to applocable to all MPLS networks. 150 From the start only one associated channel is allowed per packet. 151 Lately there has been discussions on allowing multiple associated 152 channels or other types of channelized ifo, like MPLS Extension 153 headers. 155 It should be noted that this "background" does not aspire to be 100% 156 historically corect, but is the recollection of the author. 158 3. Combiinations or Indicators anbd Anxillary Data 160 The aim of this docment is to list all the combinations of of 161 indicators and anxillary data that we can think of. And also make 162 note for each case if it is a "requirement" or not. The different 163 types indicators and anxillary data are discussed as they they are 164 listed. 166 3.1. No extra data 168 For completness the Plain Old MPLS Service label stack is included 169 here, it does not carry any indicator or anxillary data. 171 +-------------+ 172 | L1 (0) | 173 +-------------+ 174 | L2 (0) | 175 +-------------+ 176 | L3 (0) | 177 +-------------+ 178 | L4 (1) | 179 +-------------+ 180 | Pay Load | 181 ~ ~ 182 | | 183 +-------------+ 185 Figure 1: Plain Old MPLS Service 187 Question: If we normally scan the label stack for indicators is it 188 possible to stop the scanning for this type of packet? 189 In scope: Yes 191 3.2. Associated Channel Style 193 The combination of a GAL in the label stack and an Associated Channel 194 after the BoS is the the original model for the "Associated Channel". 195 Originally only one set of anxillary data and only one indicator was 196 allowed. 198 +-------------------+ 199 | L1 (0) | 200 +-------------------+ 201 | indicator (0) | 202 +-------------------+ 203 | L3 (0) | 204 +-------------------+ 205 | L4 (1) | 206 +-------------------+ 207 | anxillary data | 208 ~ ~ 209 | | 210 +-------------------+ 211 | Pay Load | 212 ~ ~ 213 | | 214 +-------------------+ 216 Figure 2: Associated Channel Service 218 Question: If we normally scan the label stack for indicators is it 219 possible to stop the scanning once the single indicator for this type 220 of packet is found? 222 In scope: Yes 224 3.3. Extended Associated Channel Style 226 Recently there has been a discussion about what happen if the label 227 stack grow to such a depth that some LSRs can't scan the stack to 228 such a depth that the indicator can't be read. The maximum readable 229 depth has been exceeded. It has been proposed to allow inserting a 230 copy of the indicator higher up in the stack. There is still only 231 one set of anxillary data after the BoS. 233 +-------------------+ 234 | L1 (0) | 235 +-------------------+ 236 | indicator b (0) | 237 +-------------------+ 238 | L3 (0) | 239 +-------------------+ 240 | L4 [0) | 241 +-------------------+ 242 | indicator a (0) | 243 +-------------------+ 244 | L6 (1) | 245 +-------------------+ 246 | anxillary data | 247 ~ ~ 248 | | 249 +-------------------+ 250 | Pay Load | 251 ~ ~ 252 | | 253 +-------------------+ 255 Figure 3: Extended Associated Channel Service 257 Question: If we normally scan the label stack for indicators is it 258 possible to stop the scanning once the first copy indicator for this 259 type of packet is found? 261 In scope: Yes 263 3.4. Modified Associated Channel Style 265 It has been discussed to allow more than one set of anxillary data, 266 indicated byt different indicators in the label stack. 268 +-------------------+ 269 | L1 (0) | 270 +-------------------+ 271 | indicator 2 (0) | 272 +-------------------+ 273 | L3 (0) | 274 +-------------------+ 275 | L4 [0) | 276 +-------------------+ 277 | indicator 1 (0) | 278 +-------------------+ 279 | L6 (1) | 280 +-------------------+ 281 | anxillary data 1 | 282 ~ ~ 283 | | 284 +-------------------+ 285 | anxillary data 2 | 286 ~ ~ 287 | | 288 +-------------------+ 289 | Pay Load | 290 ~ ~ 291 | | 292 +-------------------+ 294 Figure 4: Modified Associated Channel Service 296 Question: There might be a problem to decide which set of anxillary 297 data is indicated by which indicator. Some method to disambiguiate 298 this need to be designed. 300 In scope: Yes 302 3.5. Modified Associated Channel Style 304 It has been discussed to allow more than one set of anxillary data, 305 indicated byt different indicators in the label stack. 307 +-------------------+ 308 | L1 (0) | 309 +-------------------+ 310 | indicator 2 (0) | 311 +-------------------+ 312 | L3 (0) | 313 +-------------------+ 314 | L4 [0) | 315 +-------------------+ 316 | indicator 1 (0) | 317 +-------------------+ 318 | L6 (1) | 319 +-------------------+ 320 | anxillary data 1 | 321 ~ ~ 322 | | 323 +-------------------+ 324 | anxillary data 2 | 325 ~ ~ 326 | | 327 +-------------------+ 328 | Pay Load | 329 ~ ~ 330 | | 331 +-------------------+ 333 Figure 5: Modified Associated Channel Service 335 Question: There might be a problem to decide which set of anxillary 336 data is indicated by which indicator. Some method to disambiguiate 337 this need to be designed. 339 In scope: Maybe, but we should really aim for Section 3.6 340 Enhanced Associated Channel Style if we want to do multiple sets of 341 anxillary data. 343 3.6. Enhanced Associated Channel Style 345 The discussion to allow more than one set of anxillary data, 346 indicated by different indicators in the label stack, also has 347 resulted in that a need to have the indicators to better indicate 348 which set of anxillary data is the target. 350 +-------------------+ 351 | L1 (0) | 352 +-------------------+ 353 +---| indicator 2 (0) | 354 | +-------------------+ 355 | | L3 (0) | 356 | +-------------------+ 357 | | L4 [0) | 358 | +-------------------+ 359 | | indicator 1 (0) |---+ 360 | +-------------------+ | 361 | | L6 (1) | | 362 | +-------------------+ | 363 | | anxillary data 1 |<--+ 364 | ~ ~ 365 | | | 366 | +-------------------+ 367 +-->| anxillary data 2 | 368 ~ ~ 369 | | 370 +-------------------+ 371 | Pay Load | 372 ~ ~ 373 | | 374 +-------------------+ 376 Figure 6: Enhanceded Associated Channel Service 378 Question: Nil 380 In scope: Yes 382 3.7. Enhanced Associated Channel Style 384 There is also a proposal to allocate a new bSPL called Farwarding 385 Action Indicator (FAI). The FAI uses the "unused" bits in the label 386 format, i.e. the TTL and the TC bits. These bits can bothe be "self 387 contained", i.e. the bit give all the information needed for the 388 required forwarding action, or they point to anxillary data after the 389 BoS. 391 +-------------------+ 392 | L1 (0) | 393 +-------------------+ 394 (the FAI expanded below) | FAI (0) | 395 +-------------------+ 396 | L3 (0) | 397 +-------------------+ 398 | L4 [0) | 399 +-------------------+ 400 | indicator 1 (0) |---+ 401 +-------------------+ | 402 | L6 (1) | | 403 +-------------------+ | 404 | anxillary data 1 |<--+ 405 ~ ~ 406 | | 407 +-------------------+ 408 | anxillary data 2 | 409 ~ ~ 410 | | 411 +-------------------+ 412 | Pay Load | 413 ~ ~ 414 | | 415 +-------------------+ 416 1 2 3 417 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 8 9 0 1 2 3 4 5 6 7 8 9 0 1 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 name | FAI | TC |S| TTL | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 bits | [to be alloacted) |x x x|-|x x x x x x x x| 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Exmp | |0 0 0|-|0 0 0 1 0 0 1 0| 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Legend: 427 The "-" in the BoS (s) means that it is not availabel for 428 FAI encoding 429 Bits 20-22 and 24-31 are availabel for FAI encodings 430 On the example line two bits are set, bit 27 and 30. 431 Without claiming that this aligns with the existing 432 proposal, we can imaging that bit 27 is self contained and 433 directly gives forwarding actioins required, and that 434 bit 30 indicates presence of anxillary data after the BoS. 436 Figure 7: Enhanceded Associated Channel Service 438 Question: Can we make the bits in an SPL exactly point out which set 439 of anxillary data that should be used? 441 In scope: Likely 443 4. IANA Considerations 445 This document does not make any allocations of code points from IANA 446 registries. 448 5. Acknowledgements 450 - 452 - 454 6. Normative References 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, 458 DOI 10.17487/RFC2119, March 1997, 459 . 461 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 462 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 463 May 2017, . 465 Author's Address 467 Loa Andersson 468 Bronze Dragon Consulting 470 Email: loa@pi.nu