idnits 2.17.1 draft-xu-mpls-payload-protocol-identifier-09.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 (September 1, 2021) is 939 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETYPES' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Capitalonline 4 Intended status: Standards Track H. Assarpour 5 Expires: March 3, 2022 Broadcom 6 S. Ma 7 Google 8 F. Clad 9 Cisco Systems, Inc. 10 September 1, 2021 12 MPLS Payload Protocol Identifier 13 draft-xu-mpls-payload-protocol-identifier-09 15 Abstract 17 The MPLS label stack has no explicit protocol identifier field to 18 indicate the protocol type of the MPLS payload. This document 19 proposes a mechanism for containing a protocol identifier field 20 within the MPLS packet, which is useful for any new encapsulation 21 header (e.g., INT metadata) which may need to be encapsulated with an 22 MPLS header. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 3, 2022. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Protocol Type Field . . . . . . . . . . . . . . . . . . . . . 3 62 4. Data Plane Processing of PIL . . . . . . . . . . . . . . . . 4 63 4.1. Egress LSRs . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Ingress LSRs . . . . . . . . . . . . . . . . . . . . . . 4 65 4.3. Transit LSRs . . . . . . . . . . . . . . . . . . . . . . 5 66 4.4. Penultimate Hop LSRs . . . . . . . . . . . . . . . . . . 5 67 5. Signaling for PIL Processing Capability . . . . . . . . . . . 5 68 6. Alternative Approaches . . . . . . . . . . . . . . . . . . . 5 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 10.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 The MPLS label stack has no explicit protocol identifier field to 80 indicate the protocol type of the MPLS payload. This document 81 proposes a mechanism for containing a protocol identifier field 82 within the MPLS packet, which is useful for any new encapsulation 83 header (e.g., INT metadata) which may need to be encapsulated with an 84 MPLS header. With this explicit protocol identifier field, there is 85 no need any more for each new encapsulation header to deal with the 86 notorious first nibble issue associated with MPLS individually. More 87 specifically, there is no need to intentionally avoid the first 88 nibble of each new encapsulation header from being 0100 (IPv4) or 89 0110 (IPv6) and even worsely misuse the first nibble of each new 90 encapsulation header as an MPLS payload type field (e.g., MPLS-BIER 91 [RFC8296]). The tacit permission of misusing the first nibble of 92 each new encapsulation header as an MPLS payload type field would 93 exhause the valuable nibble space quickly. Furthermore, there is no 94 need to insert one additional label indicating the MPLS payload type 95 when transporting any new encapsulation header over MPLS LSPs (e.g., 96 transporting Network Service Header (NSH) [RFC8300] over MPLS LSPs) 97 therefore the signalling for that additional label is not needed 98 anymore. 100 To some extent, this situation is much similar to that of the MPLS 101 reserved label space (a.k.a., the special purpose label space) 102 [RFC7274] . Due to the concern over the scarcity of the special- 103 purpose label space , the extended special purpose label concept is 104 introduced accordingly. Similarily, the IETF MPLS community should 105 take precautions on the the scarcity of the first nibble of the MPLS 106 payload before it is too late. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Terminology 116 This memo makes use of the terms defined in [RFC3032]. 118 3. Protocol Type Field 120 The encapsulation format for Protocol Type field is depicted as 121 below: 123 0 1 2 3 124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | PIL | TC |1| TTL | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 |0 0 0 0| Reserved | Protocol Type | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Payload | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Figure 1 134 Protocol Identifier Label (PIL): This field contains a special 135 purpose label with value of or an extended special purpose 136 label [RFC7274] with value of which indicates that a 137 Protocol Type field appears immediately after the bottom of the 138 label stack. 140 Traffic Class (TC): The usage of this field is in accordance with 141 the current MPLS specification [RFC3032]. 143 S: The Bottom of Stack (BoS) field is set since the PIL MUST 144 always appear at the bottom of the label stack. 146 TTL: The usage of this field is in accordance with the current 147 MPLS specification [RFC3032]. 149 Reserved MUST be set to 0 and ignored on reception. 151 Protocol Type: This field indicates the protocol type of the MPLS 152 payload as per [ETYPES]. 154 Payload: This field contains the MPLS payload which can be an IP 155 packet, an Ethernet frame, or any other type of payload, e.g., 156 Network Service Header (NSH) [RFC8300]. 158 4. Data Plane Processing of PIL 160 4.1. Egress LSRs 162 Suppose egress LSR Y is capable of processing the Protocol Type field 163 contained in MPLS packets. LSR Y indicates this to all ingress LSRs 164 via signaling (see Section 5). LSR Y MUST be prepared to deal with 165 both packets with an imposed Protocol Type field and those without; 166 the PIL will distinguish these cases. If a particular ingress LSR 167 chooses not to impose a Protocol Type field, LSR Y's processing of 168 the received label stack (which might be empty) is as if LSR Y chose 169 not to accept Protocol Type field. If an ingress LSR X chooses to 170 impose the Protocol Type field, then LSR Y will receive an MPLS 171 packet constructed as follows: . Note that 173 here the TL could be replaced with an IP-based tunnel [RFC4023] and 174 the AL is optional. LSR Y recognizes TL as the label it distributed 175 to its upstream LSR and pops the TL (note that the TL may be an 176 implicit null label, in which case it doesn't appear in the label 177 stack and LSR Y MUST process the packet starting with the AL label 178 (if present) and/or the PIL.) LSR Y recognizes the PIL with S bit 179 set. LSR Y then processes the Protocol Type field, which will 180 determine how LSR Y processes the MPLS payload. 182 4.2. Ingress LSRs 184 If an egress LSR Y indicates via signaling that it can process the 185 Protocol Type field, an ingress LSR X can choose whether or not to 186 insert it into the MPLS packet destined for LSR Y. The ingress LSR X 187 MUST NOT insert the Protocol Type field into that MPLS packet unless 188 the egress LSR X has explicitly announced that it could process it. 189 The steps that ingress LSR X performs to insert the Protocol Type 190 field are as follows: 192 1. On an incoming packet, identify the application to which the 193 packet belongs and determine whether the Protocol Type field 194 needs to be added to the incoming packet. 196 2. For packets requiring the insertion of the Protocol Type field, 197 prepend the Protocol Type field to the existing MPLS payload; 198 then, push the PIL on to the label stack with the S bit set. 200 3. Push the application label (AL) label (if required) on to the 201 label stack. 203 4. Push the EL and the ELI labels [RFC6790] on to the label stack 204 (if required). 206 5. Determine the top label (TL) and push it on to the label stack. 208 6. Determine the output interface and send the packet out. 210 4.3. Transit LSRs 212 Transit LSRs MAY operate with no change in forwarding behavior. If a 213 transit LSR recognizes the PIL and the subsequent Protocol Type 214 field, it MAY be allowed to do some additional value-added 215 processing, such as MPLS payload inspection, on the received MPLS 216 packet containing the PIL and the Protocol Type field. 218 4.4. Penultimate Hop LSRs 220 No change is needed at penultimate hop LSRs. 222 5. Signaling for PIL Processing Capability 224 TBD. 226 6. Alternative Approaches 228 As illustrated in Section 3 and Section 4, the existence of the 229 Protocol Type field immediately after the MPLS label stack is 230 indicated by inserting the PIL into an MPLS packet. Alternatively, 231 by setting the first nibble of the 4-octet entry containing the 232 Protocol Type field to a dedicated value (e.g., 1111), the existence 233 of the Protocol Type field could be indicated as well (see Figure 2). 234 In this way, there is no need to insert additional label(s) (i.e., 235 the PIL) into an MPLS packet. As for which approach should be 236 selected in the end, it depends on a wide-scope discussion within the 237 IETF. 239 0 1 2 3 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Bottom Label | TC |1| TTL | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |1 1 1 1| Reserved | Protocol Type | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Payload | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 2 250 7. Acknowledgements 252 TBD. 254 8. IANA Considerations 256 A special purpose label with value of or an extended special 257 purpose label with value of for the PIL needs to be assigned by 258 the IANA 260 9. Security Considerations 262 TBD. 264 10. References 266 10.1. Normative References 268 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012. 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, 272 DOI 10.17487/RFC2119, March 1997, 273 . 275 10.2. Informative References 277 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 278 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 279 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 280 . 282 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 283 "Encapsulating MPLS in IP or Generic Routing Encapsulation 284 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 285 . 287 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 288 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 289 RFC 6790, DOI 10.17487/RFC6790, November 2012, 290 . 292 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 293 and Retiring Special-Purpose MPLS Labels", RFC 7274, 294 DOI 10.17487/RFC7274, June 2014, 295 . 297 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 298 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 299 for Bit Index Explicit Replication (BIER) in MPLS and Non- 300 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 301 2018, . 303 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 304 "Network Service Header (NSH)", RFC 8300, 305 DOI 10.17487/RFC8300, January 2018, 306 . 308 Authors' Addresses 310 Xiaohu Xu 311 Capitalonline. 313 Email: 13910161692@qq.com 315 Hamid Assarpour 316 Broadcom 318 Email: hamid.assarpour@broadcom.com 320 Shaowen Ma 321 Google 323 Email: mashaowen@gmail.com 325 Francois Clad 326 Cisco Systems, Inc. 328 Email: fclad@cisco.com