idnits 2.17.1 draft-xu-bier-encapsulation-06.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 23, 2016) is 2772 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' == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-04 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-05 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-02 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track S. Somasundaram 5 Expires: March 27, 2017 Alcatel-Lucent 6 C. Jacquenet, Ed. 7 France Telecom 8 R. Raszuk 9 Bloomberg LP 10 Z. Zhang, Ed. 11 Juniper 12 September 23, 2016 14 A Transport-Independent Bit Index Explicit Replication (BIER) 15 Encapsulation Header 16 draft-xu-bier-encapsulation-06 18 Abstract 20 Bit Index Explicit Replication (BIER) is a new multicast forwarding 21 paradigm which doesn't require an explicit tree-building protocol nor 22 intermediate routers to maintain any multicast state. This document 23 proposes a transport-independent BIER encapsulation header which is 24 applicable regardless of the underlying transport technology. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 27, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. BIER Header . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. BIER Header Transport . . . . . . . . . . . . . . . . . . . . 5 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is 76 a new multicast forwarding paradigm which doesn't require an explicit 77 tree-building protocol nor intermediate routers to maintain any 78 multicast state. As described in [I-D.ietf-bier-architecture], BIER 79 adds a header to a multicast data packet (e.g., an IP packet or an 80 MPLS packet). The BIER header carries the information needed for 81 supporting the BIER forwarding procedures. This document proposes a 82 transport-independent BIER encapsulation header which is applicable 83 regardless of the underlying transport technology. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Terminology 93 This memo makes use of the terms defined in 94 [I-D.ietf-bier-architecture]. 96 3. BIER Header 98 The BIER header is shown in Figure 1. 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Ver | BSL | Resv | Entropy | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | BFIR-ID | DS | Protocol | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | SI | Sub-domain |O| Resv| TTL | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | BitString (first 32 bits) ~ 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 ~ ~ 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 ~ BitString (last 32 bits) | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Figure 1: BIER Header Format. 117 Ver(sion): a 4-bit field identifying the version of the BIER 118 header. This document specifies version 0 of the BIER header. 120 BSL: Bit String Length. If k is the length of the BitString, the 121 value of this field is log2(k)-5. However, only the following 122 values are supported [I-D.ietf-bier-mpls-encapsulation] : 124 * 64 bits 126 * 128 bits 128 * 256 bits 130 * 512 bits 132 * 1024 bits 134 * 2048 bits 136 * 4096 bits 137 The value of the BSL field MUST NOT be set to any value other than 138 those listed above. A received packet containing another value in 139 this field SHOULD be discarded, and an error logged. 141 Entropy: a 20-bit field containing an "entropy" value that can be 142 used for load balancing purposes. 144 BFIR-ID: a 2-octet field encoding the BFR-ID of the Bit-Forwarding 145 Ingress Router (BFIR), in the BIER sub-domain where the packet is 146 forwarded to. 148 DS: The usage of this field is no different from that of the 149 Differentiated Services (DS) field of IPv4 and IPv6 headers. 150 [RFC2474]. 152 Protocol: a one-octet field indicating the protocol type of the 153 BIER payload as per the protocol numbers used in the Protocol 154 field [RFC5237] of the IPv4 header and the Next Header field of an 155 IPv6 header. Theoretically, with the use of the IPv4/IPv6 156 equivalent Protocol/Next-Header field, the payload of a BIER 157 packet could be any type of payload permitted within the IPv4/IPv6 158 packet. However, this document currently only considers the use 159 of the BIER encapsulation for "transport" type services where the 160 encapsulated packets are either L2.5 (e.g., MPLS) or L3 (e.g., IP) 161 packets . The valid BIER payload types include (but are not 162 limited to) IPv4, IPv6, MPLS, VXLAN [RFC7348],VXLAN-GPE 163 [I-D.ietf-nvo3-vxlan-gpe] and LISP [RFC6830]. The corresponding 164 IP Protocol numbers for VXLAN, VXLAN-GPE and LISP are to be 165 allocated by IANA. 167 SI: a 10-bit field encoding the Set-Identifier (SI) for this 168 packet in the case where the O-Flag bit is cleared. 170 Sub-domain: a 10-bit field encoding the sub-domain where the 171 packet is forwarded to in the case where the O-Flag bit is 172 cleared. 174 O-flag: If it's set, the leftmost 20 bits (i.e., the combination 175 of the SI and Sub-domain fields) should be interpreted as an 176 opaque number signaled and used much as the MPLS-BIER label in 177 MPLS BIER encapsulation [I-D.ietf-bier-mpls-encapsulation]. A BFR 178 signals the mapping between the opaque number and (subdomain-id, 179 set-id, BSL) and it derives the (subdomain-id,set-id,BSL) from the 180 opqaue number in an incoming BIER header just like in the MPLS 181 BIER encapsulation case, except that regular MPLS signaling and 182 forwarding infrastructure is not required. 184 TTL: The usage of this field is no different from that of the Time 185 To Live (TTL) field in the IPv4 header. 187 BitString: a variable-length BitString field that, together with 188 the SI and Sub-domain fields, identifies all the destination BFERs 189 for this packet. 191 4. BIER Header Transport 193 Since the BIER header format as specified in Section 3 is transport- 194 independent by design, it can be carried with any type of transport 195 encapsulation headers, such as an Ethernet header, a PPP header, an 196 IP header, an MPLS header, a GRE header, an UDP header, etc. Any 197 possible transport encapsulation header must be able to indicate the 198 payload is an BIER header. For instance, in the BIER-in-MAC 199 encapsulation case, the EtherType [ETYPES] field of the Ethernet 200 header is used for that purpose. In the BIER-in-IP encapsulation 201 case, the Protocol field of the IPv4 header or the Next-Header field 202 of the IPv6 header are used. In the MPLS transport case, the MPLS- 203 BIER encapsulation [I-D.ietf-bier-mpls-encapsulation] SHOULD be used 204 instead. Note that more details about BIER-in-UDP encapsualtion 205 (e.g., UDP checksum and congestion control) will be specified in 206 future versions of this document. 208 5. Acknowledgements 210 Thanks Antoni Przygienda, IJsbrand Wijnands, Eric Rosen and Toerless 211 Eckert for their valuable comments and suggestions on this document. 213 6. IANA Considerations 215 This document includes a request to IANA to allocate an EtherType 216 code,a PPP protocol code, an IPv4 protocol code/an IPv6 Next-Header 217 code, a UDP destination port to indicate that BIER-encapsulated data 218 follows. Furthermore, this document includes a request to IANA to 219 allocate IP Protocol numbers for VXLAN, VXLAN-GPE and LISP 220 respectively. 222 7. Security Considerations 224 As mentioned in [I-D.ietf-bier-architecture], when BIER is paired 225 with any transport underlay, it inherits the security considerations 226 of the corresponding transport layer. Also, SI and BFIR-ID fields of 227 the BIER header may carry values other than those intended by the 228 BFIR at the risk of misdelivering the packet. Means to protect BFR 229 routers against Man-in-the-Middle and Denial of Service attacks must 230 be provided. 232 8. References 234 8.1. Normative References 236 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012. 238 [I-D.ietf-bier-architecture] 239 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 240 S. Aldrin, "Multicast using Bit Index Explicit 241 Replication", draft-ietf-bier-architecture-04 (work in 242 progress), July 2016. 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, 246 DOI 10.17487/RFC2119, March 1997, 247 . 249 8.2. Informative References 251 [I-D.ietf-bier-mpls-encapsulation] 252 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 253 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 254 Explicit Replication in MPLS Networks", draft-ietf-bier- 255 mpls-encapsulation-05 (work in progress), July 2016. 257 [I-D.ietf-nvo3-vxlan-gpe] 258 Kreeger, L. and U. Elzur, "Generic Protocol Extension for 259 VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress), 260 April 2016. 262 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 263 "Definition of the Differentiated Services Field (DS 264 Field) in the IPv4 and IPv6 Headers", RFC 2474, 265 DOI 10.17487/RFC2474, December 1998, 266 . 268 [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for 269 the Protocol Field", BCP 37, RFC 5237, 270 DOI 10.17487/RFC5237, February 2008, 271 . 273 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 274 Locator/ID Separation Protocol (LISP)", RFC 6830, 275 DOI 10.17487/RFC6830, January 2013, 276 . 278 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 279 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 280 eXtensible Local Area Network (VXLAN): A Framework for 281 Overlaying Virtualized Layer 2 Networks over Layer 3 282 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 283 . 285 Authors' Addresses 287 Xiaohu Xu (editor) 288 Huawei 290 Email: xuxiaohu@huawei.com 292 S Somasundaram 293 Alcatel-Lucent 295 Email: somasundaram.s@alcatel-lucent.com 297 Christian Jacquenet (editor) 298 France Telecom 300 Email: christian.jacquenet@orange.com 302 Robert Raszuk 303 Bloomberg LP 305 Email: robert@raszuk.net 307 Zhaohui Zhang (editor) 308 Juniper 310 Email: zzhang@juniper.net