idnits 2.17.1 draft-xu-mpls-payload-protocol-identifier-05.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 (August 8, 2018) is 2086 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 Alibaba, Inc. 4 Intended status: Standards Track H. Assarpour 5 Expires: February 9, 2019 Broadcom 6 S. Ma 7 Juniper 8 F. Clad 9 Cisco Systems, Inc. 10 August 8, 2018 12 MPLS Payload Protocol Identifier 13 draft-xu-mpls-payload-protocol-identifier-05 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 which may need to be encapsulated with an MPLS header. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 9, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Protocol Type Field . . . . . . . . . . . . . . . . . . . . . 3 61 4. Data Plane Processing of PIL . . . . . . . . . . . . . . . . 4 62 4.1. Egress LSRs . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Ingress LSRs . . . . . . . . . . . . . . . . . . . . . . 4 64 4.3. Transit LSRs . . . . . . . . . . . . . . . . . . . . . . 5 65 4.4. Penultimate Hop LSRs . . . . . . . . . . . . . . . . . . 5 66 5. Signaling for PIL Processing Capability . . . . . . . . . . . 5 67 6. Alternative Approaches . . . . . . . . . . . . . . . . . . . 5 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 10.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 The MPLS label stack has no explicit protocol identifier field to 79 indicate the protocol type of the MPLS payload. This document 80 proposes a mechanism for containing a protocol identifier field 81 within the MPLS packet, which is useful for any new encapsulation 82 header which may need to be encapsulated with an MPLS header. With 83 this explicit protocol identifier field, there is no need any more 84 for each new encapsulation header to deal with the notorious first 85 nibble issue associated with MPLS individually. More specifically, 86 there is no need to intentionally avoid the first nibble of each new 87 encapsulation header from being 0100 (IPv4) or 0110 (IPv6) and even 88 worsely misuse the first nibble of each new encapsulation header as 89 an MPLS payload type field (e.g., MPLS-BIER 90 [I-D.ietf-bier-mpls-encapsulation]). The tacit permission of 91 misusing the first nibble of each new encapsulation header as an MPLS 92 payload type field would exhause the valuable nibble space quickly. 93 Furthermore, there is no need to insert one additional label 94 indicating the MPLS payload type when transporting any new 95 encapsulation header over MPLS LSPs (e.g., transporting Network 96 Service Header (NSH) [I-D.ietf-sfc-nsh] over MPLS LSPs) therefore the 97 signalling for that additional label is not needed anymore. 99 To some extent, this situation is much similar to that of the MPLS 100 reserved label space (a.k.a., the special purpose label space) 101 [RFC7274] . Due to the concern over the scarcity of the special- 102 purpose label space , the extended special purpose label concept is 103 introduced accordingly. Similarily, the IETF MPLS community should 104 take precautions on the the scarcity of the first nibble of the MPLS 105 payload before it is too late. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Terminology 115 This memo makes use of the terms defined in [RFC3032]. 117 3. Protocol Type Field 119 The encapsulation format for Protocol Type field is depicted as 120 below: 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | PIL | EXP |1| TTL | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 |0 0 0 0| Reserved | Protocol Type | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Payload | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Figure 1 133 Protocol Identifier Label (PIL): This field contains a special 134 purpose label with value of or an extended special purpose 135 label [RFC7274] with value of which indicates that a 136 Protocol Type field appears immediately after the bottom of the 137 label stack. 139 EXP: The usage of this field is in accordance with the current 140 MPLS specification [RFC3032]. 142 S: The Bottom of Stack (BoS) field is set since the PIL MUST 143 always appear at the bottom of the label stack. 145 TTL: The usage of this field is in accordance with the current 146 MPLS specification [RFC3032]. 148 Reserved MUST be set to 0 and ignored on reception. 150 Protocol Type: This field indicates the protocol type of the MPLS 151 payload as per [ETYPES]. 153 Payload: This field contains the MPLS payload which can be an IP 154 packet, an Ethernet frame, or any other type of payload, e.g., 155 Network Service Header (NSH) [I-D.ietf-sfc-nsh]. 157 4. Data Plane Processing of PIL 159 4.1. Egress LSRs 161 Suppose egress LSR Y is capable of processing the Protocol Type field 162 contained in MPLS packets. LSR Y indicates this to all ingress LSRs 163 via signaling (see Section 5). LSR Y MUST be prepared to deal with 164 both packets with an imposed Protocol Type field and those without; 165 the PIL will distinguish these cases. If a particular ingress LSR 166 chooses not to impose a Protocol Type field, LSR Y's processing of 167 the received label stack (which might be empty) is as if LSR Y chose 168 not to accept Protocol Type field. If an ingress LSR X chooses to 169 impose the Protocol Type field, then LSR Y will receive an MPLS 170 packet constructed as follows: . Note that 172 here the TL could be replaced with an IP-based tunnel [RFC4023] and 173 the AL is optional. LSR Y recognizes TL as the label it distributed 174 to its upstream LSR and pops the TL (note that the TL may be an 175 implicit null label, in which case it doesn't appear in the label 176 stack and LSR Y MUST process the packet starting with the AL label 177 (if present) and/or the PIL.) LSR Y recognizes the PIL with S bit 178 set. LSR Y then processes the Protocol Type field, which will 179 determine how LSR Y processes the MPLS payload. 181 4.2. Ingress LSRs 183 If an egress LSR Y indicates via signaling that it can process the 184 Protocol Type field, an ingress LSR X can choose whether or not to 185 insert it into the MPLS packet destined for LSR Y. The ingress LSR X 186 MUST NOT insert the Protocol Type field into that MPLS packet unless 187 the egress LSR X has explicitly announced that it could process it. 188 The steps that ingress LSR X performs to insert the Protocol Type 189 field are as follows: 191 1. On an incoming packet, identify the application to which the 192 packet belongs and determine whether the Protocol Type field 193 needs to be added to the incoming packet. 195 2. For packets requiring the insertion of the Protocol Type field, 196 prepend the Protocol Type field to the existing MPLS payload; 197 then, push the PIL on to the label stack with the S bit set. 199 3. Push the application label (AL) label (if required) on to the 200 label stack. 202 4. Push the EL and the ELI labels [RFC6790] on to the label stack 203 (if required). 205 5. Determine the top label (TL) and push it on to the label stack. 207 6. Determine the output interface and send the packet out. 209 4.3. Transit LSRs 211 Transit LSRs MAY operate with no change in forwarding behavior. If a 212 transit LSR recognizes the PIL and the subsequent Protocol Type 213 field, it MAY be allowed to do some additional value-added 214 processing, such as MPLS payload inspection, on the received MPLS 215 packet containing the PIL and the Protocol Type field. 217 4.4. Penultimate Hop LSRs 219 No change is needed at penultimate hop LSRs. 221 5. Signaling for PIL Processing Capability 223 TBD. 225 6. Alternative Approaches 227 As illustrated in Section 3 and Section 4, the existence of the 228 Protocol Type field immediately after the MPLS label stack is 229 indicated by inserting the PIL into an MPLS packet. Alternatively, 230 by setting the first nibble of the 4-octet entry containing the 231 Protocol Type field to a dedicated value (e.g., 1111), the existence 232 of the Protocol Type field could be indicated as well (see Figure 2). 233 In this way, there is no need to insert additional label(s) (i.e., 234 the PIL) into an MPLS packet. As for which approach should be 235 selected in the end, it depends on a wide-scope discussion within the 236 IETF. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Bottom Label | EXP |1| TTL | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |1 1 1 1| Reserved | Protocol Type | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Payload | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 2 249 7. Acknowledgements 251 TBD. 253 8. IANA Considerations 255 A special purpose label with value of or an extended special 256 purpose label with value of for the PIL needs to be assigned by 257 the IANA 259 9. Security Considerations 261 TBD. 263 10. References 265 10.1. Normative References 267 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012. 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 10.2. Informative References 276 [I-D.ietf-bier-mpls-encapsulation] 277 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 278 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 279 Explicit Replication in MPLS and non-MPLS Networks", 280 draft-ietf-bier-mpls-encapsulation-12 (work in progress), 281 October 2017. 283 [I-D.ietf-sfc-nsh] 284 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 285 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 286 November 2017. 288 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 289 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 290 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 291 . 293 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 294 "Encapsulating MPLS in IP or Generic Routing Encapsulation 295 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 296 . 298 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 299 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 300 RFC 6790, DOI 10.17487/RFC6790, November 2012, 301 . 303 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 304 and Retiring Special-Purpose MPLS Labels", RFC 7274, 305 DOI 10.17487/RFC7274, June 2014, 306 . 308 Authors' Addresses 310 Xiaohu Xu 311 Alibaba, Inc. 313 Email: xiaohu.xxh@alibaba-inc.com 315 Hamid Assarpour 316 Broadcom 318 Email: hamid.assarpour@broadcom.com 320 Shaowen Ma 321 Juniper 323 Email: mashao@juniper.net 324 Francois Clad 325 Cisco Systems, Inc. 327 Email: fclad@cisco.com