idnits 2.17.1 draft-mirsky-bier-path-mtu-discovery-01.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 (April 5, 2016) is 2936 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) == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-03 == Outdated reference: A later version (-03) exists of draft-kumarzheng-bier-ping-02 ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) == Outdated reference: A later version (-14) exists of draft-ietf-bier-oam-requirements-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Przygienda 5 Expires: October 7, 2016 Juniper Networks 6 A. Dolganow 7 Nokia 8 April 5, 2016 10 Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit 11 Replication (BIER) Layer 12 draft-mirsky-bier-path-mtu-discovery-01 14 Abstract 16 This document describes Path Maximum Transmission Unit Discovery 17 (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 7, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 56 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 58 3. PMTUD Mechanism for BIER . . . . . . . . . . . . . . . . . . 4 59 3.1. Data TLV for BIER Ping . . . . . . . . . . . . . . . . . 6 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 In packet switched networks when a host seeks to transmit a sizable 71 amount of data to a target destination the data is transmitted as a 72 set of datagrams. In most cases it is more efficient to use the 73 largest possible datagrams but so that these datagrams do not have to 74 be fragmented at any point along the path from the host to the 75 destination in order to avoid performance degradation caused by 76 fragmentation. Fragmentation occurs on hops along the route where an 77 Maximum Transmission Unit (MTU) is smaller than the size of the 78 datagram. To avoid such fragmentation the MTU for each hop along a 79 path from a host to a destination must be known to select an 80 appropriate datagram size. Such MTU determination along a specific 81 path is referred to as path MTU discovery (PMTUD). 83 [I-D.ietf-bier-architecture] introduces and explains Bit Index 84 Explicit Replication (BIER) architecture and how it supports 85 forwarding of multicast data packets. A BIER domain consists of Bit- 86 Forwarding Routers (BFRs) that are uniquely identified by their 87 respective BFR-ids. An ingress border router (acting as a Bit 88 Forwarding Ingress Router (BFIR)) inserts a Forwarding Bit Mask 89 (F-BM) into a packet. Each targeted egress node (referred to as a 90 Bit Forwarding Egress Router (BFER)) is represented by Bit Mask 91 Position (BMP) in the BMS. A transit or intermediate BIER node, 92 referred as BFR, forwards BIER encapsulated packets to BFERs, 93 identified by respective BMPs, according to a Bit Index Forwarding 94 Table (BIFT). 96 1.1. Conventions used in this document 98 1.1.1. Terminology 100 BFR: Bit-Forwarding Router 102 BFER: Bit-Forwarding Egress Router 104 BFIR: Bit-Forwarding Ingress Router 106 BIER: Bit Index Explicit Replication 108 BIFT: Bit Index Forwarding Tree 110 F-BM: Forwarding Bit Mask 112 MTU: Maximum Transmission Unit 114 OAM: Operations, Administration and Maintenance 116 PMTUD: Path MTU Discovery 118 1.1.2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119]. 125 2. Problem Statement 127 [I-D.ietf-bier-oam-requirements] sets forth the requirement to define 128 PMTUD protocol for BIER domain. This document describes the 129 extension to [I-D.kumarzheng-bier-ping] for use in BIER PMTUD 130 solution. 132 Current PMTUD mechanisms [RFC1191], [RFC1981], and [RFC4821] are 133 primarily targeted to work on point-to-point, i.e. unicast paths. 134 These mechanisms use packet fragmentation control by disabling 135 fragmentation of the probe packet. As result, a transient node that 136 cannot forward a probe packet that is bigger than its link MTU sends 137 to the ingress node an error notification, otherwise the egress 138 responds with a positive acknowledgement. Thus, through series of 139 iterations, decreasing and increasing size of the probe packet, the 140 ingress node discovers the MTU of the particular path. 142 Thus applied such existing PMTUD solutions are inefficient for point- 143 to-multipoint paths constructed for multicast traffic. Probe packets 144 must be flooded through the whole set of multicast distribution paths 145 over and over again until the very last egress responds with a 146 positive acknowledgement. Consider without loss of generality an 147 example multicast network presented in Figure 1, where MTU on all 148 links but one (B,D) is the same. If MTU on link (B,D) is smaller 149 than the MTU on the other links, using existing PMTUD mechanism 150 probes will unnecessary flood to leaf nodes E, F, and G for the 151 second and consecutive times and positive responses will be generated 152 and received by root A repeatedly. 154 ----- 155 --| D | 156 ----- / ----- 157 --| B |-- 158 / ----- \ ----- 159 / --| E | 160 ----- / ----- 161 | A |--- ----- 162 ----- \ --| F | 163 \ ----- / ----- 164 --| C |-- 165 ----- \ ----- 166 --| G | 167 ----- 169 Figure 1: Multicast network 171 3. PMTUD Mechanism for BIER 173 A BFIR selects a set of BFERs for the specific multicast 174 distribution. Such BFIR determines, by explicitly controlling subset 175 of targeted BFERs and transmitting series of probe packets, the MTU 176 of that multicast distribution path. The critical step is that in 177 case of failure at an intermediate BFR to forward towards the subset 178 of targeted downstream BFERs, the BFR responds with a partial 179 (compared to the one it received in the request) bitmask towards the 180 originating BFIR in error notification. That allows for 181 retransmission of the next probe with smaller MTU address only 182 towards the failed downstream BFERs instead of all BFERs addressed in 183 the previous probe. In the scenario discussed in Section 2 the 184 second and all following (if needed) probes will be sent only to the 185 node D since MTU discovery of E, F, and G has been completed already 186 by the first probe successfully. 188 [I-D.kumarzheng-bier-ping] introduced BIER Ping as transport- 189 independent OAM mechanism to detect and localize failures in BIER 190 data plane. This document specifies how BIER Ping can be used to 191 perform efficient PMTUD in BIER domain. 193 Consider network displayed in Figure 1 to be presentation of a BIER 194 domain and all nodes to be BFRs. To discover MTU over BIER domain to 195 BFERs D, F, E, and G BFIR A will use BIER Ping with Data TLV, defined 196 in Section 3.1. Size of the first probe set to _M_max_ determined as 197 minimal MTU value of BFIR's links to BIER domain. As been assumed in 198 Section 2, MTUs of all links but link (B,D) are the same. Thus BFERs 199 E. F, and G would receive BIER Echo Request and will send their 200 respective replies to BFIR A. BFR B may pass the packet which is too 201 large to forward over egress link (B, D) to the appropriate network 202 layer for error processing where it would be recognized as BIER Echo 203 Request packet. BFR B MUST send BIER Echo Reply to BFIR A and MUST 204 include Downstream Mapping TLV, defined in [I-D.kumarzheng-bier-ping] 205 setting its fields in the following fashion: 207 o MTU SHOULD be set to minimal MTU value among all egress BIER links 208 that could be used to reach B's downstream BFERs; 210 o Address Type MUST be set to 0 [Ed.note: we need to define 0 as 211 valid value for the Address Type field with the specific semantics 212 to "Ignore" it.] 214 o I flag MUST be cleared; 216 o Downstream Interface Address field (4 octets) MUST be zeroed and 217 MUST include in Egress Bitstring sub-TLV the list of all BFERs 218 that cannot be reached because the attempted MTU turned out to be 219 too small. 221 The BFIR will receive either of the two types of packets: 223 o a positive Echo Reply from one of BFERs to which the probe has 224 been sent. In such case the bit corresponding to the BFER MUST be 225 cleared from the BMS; 227 o a negative Echo Reply with bit string listing unreached BFERs and 228 recommended MTU value MTU". The BFIR MUST add the bit string to 229 its BMS and set size of the next probe as min(MTU, MTU") 231 If upon expiration of the Echo Request timer BFIR didn't receive any 232 Echo Replies, then the size of the probe SHOULD be decreased. There 233 are scenarios when an implementation of the PMTUD would not decrease 234 the size of the probe. For example, if upon expiration of the Echo 235 Request timer BFIR didn't receive any Echo Reply, then BFIR MAY 236 continue to retransmit the probe using the initial size and MAY apply 237 probe delay retransmission procedures. The algorithm used to delay 238 retransmission procedures on BFIR is outside the scope of this 239 specification. The BFIR MUST continue sending probes using BMS until 240 the bit string is clear or the discovery is declared unsuccessful. 241 In case of convergence of the procedure, the size of the last probe 242 indicates the MTU size that can be used for all BFERs in the initial 243 BMS without incurring fragmentation. 245 Thus we conclude that in order to comply with the requirement in 246 [I-D.ietf-bier-oam-requirements]: 248 o a BFR SHOULD support PMTUD; 250 o a BFR MAY use defined per BIER sub-domain MTU value as initial MTU 251 value for discovery or use it as MTU for this BIER sub-domain to 252 reach BFERs. 254 3.1. Data TLV for BIER Ping 256 There need to be control of probe size in order to support the BIER 257 PMTUD. Data TLV format is presented in Figure 2. 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type (TBA1) | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Data | 265 ~ ~ 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 2: Data TLV format 271 o Type: indicates Data TLV, to be allocated by IANA Section 4. 273 o Length: the length of the Data field in octets. 275 o Data: n octets (n = Length) of arbitrary data. The receiver 276 SHOULD ignore it. 278 4. IANA Considerations 280 IANA is requested to assign new Type value for Data TLV Type from its 281 registry of TLV and sub-TLV Types of BIER Ping as follows: 283 +-------+-------------+---------------+ 284 | Value | Description | Reference | 285 +-------+-------------+---------------+ 286 | TBA1 | Data | This document | 287 +-------+-------------+---------------+ 289 Table 1: Data TLV Type 291 5. Security Considerations 293 Routers that support PMTUD based on this document are subject to the 294 same security considerations as defined in [I-D.kumarzheng-bier-ping] 296 6. Acknowledgement 298 TBD 300 7. References 302 7.1. Normative References 304 [I-D.ietf-bier-architecture] 305 Wijnands, I., Rosen, E., Dolganow, A., P, T., and S. 306 Aldrin, "Multicast using Bit Index Explicit Replication", 307 draft-ietf-bier-architecture-03 (work in progress), 308 January 2016. 310 [I-D.kumarzheng-bier-ping] 311 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 312 and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng- 313 bier-ping-02 (work in progress), December 2015. 315 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 316 DOI 10.17487/RFC1191, November 1990, 317 . 319 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 320 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 321 1996, . 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, 325 DOI 10.17487/RFC2119, March 1997, 326 . 328 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 329 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 330 . 332 7.2. Informative References 334 [I-D.ietf-bier-oam-requirements] 335 Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., 336 Aldrin, S., Zheng, L., Chen, M., Akiya, N., and S. 337 Pallagatti, "Operations, Administration and Maintenance 338 (OAM) Requirements for Bit Index Explicit Replication 339 (BIER) Layer", draft-ietf-bier-oam-requirements-01 (work 340 in progress), March 2016. 342 Authors' Addresses 344 Greg Mirsky 345 Ericsson 347 Email: gregory.mirsky@ericsson.com 349 Tony Przygienda 350 Juniper Networks 352 Email: prz@juniper.net 354 Andrew Dolganow 355 Nokia 357 Email: andrew.dolganow@nokia.com