idnits 2.17.1 draft-lts-pim-hello-mtu-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 13, 2012) is 4303 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) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Downref: Normative reference to an Experimental RFC: RFC 3973 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group H. Liu 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track T. Tsou 5 Expires: January 14, 2013 Huawei Technologies (USA) 6 July 13, 2012 8 PIM MTU Hello Option for PIM Message Encapsulation 9 draft-lts-pim-hello-mtu-01 11 Abstract 13 This memo introduces a new PIM Hello MTU Option which is carried in 14 PIM Hello messages. The MTU option enables interface MTU information 15 to be exchanged among PIM neighbors, and PIM messages to be 16 encapsulated in an efficient and consistent way. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 14, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. MTU Option and its Operation Rule . . . . . . . . . . . . . . . 4 55 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 59 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 A PIM router often needs to preserve a great many (*,G) or (S,G) 65 multicast forwarding states to enable traffic forwarding for large 66 scale of multicast channels. These states are usually set up and 67 kept alive by each downstream router periodically sending Join 68 Messages carrying its own forwarding states to its upstream neighbor. 69 For each round of assembling these states into a PIM message, 70 multiple segments of packets might be generated due to the MTU 71 limitation on the sending PIM interface. 73 Current implementation uses merely sending link MTU to calculate 74 maximum PIM packet length without considering the receiving MTU of 75 the neighbor(s). It has some drawbacks because if the MTU of the 76 sending interface is larger than that of the receiving one, PIM 77 protocol packets encapsulated according to the sending MTU will most 78 possibly be discarded by the receiving router and the forwarding 79 states cannot be properly established as a result. There are already 80 faults being reported caused by inconsistent MTU configuration among 81 PIM neighbors. 83 Even though the problem could be resolved by requiring each PIM 84 downstream interface to take less or equal MTU value than its 85 upstream interface, it is inflexible for operation and does not scale 86 because the interface or link conditions across the network might be 87 diverse in practice. As a remedy, this memo recommends exchanging 88 link MTU information among PIM neighbors by using a new Hello MTU 89 Option. The option is carried in periodical PIM Hello messages for a 90 router to inform its receiving link MTU parameter on an interface to 91 the connected neighbor(s), so that the MTU information could be 92 referenced by the neighbor(s) when they are sending PIM protocol 93 messages on this link. 95 PIM MTU Option can be applied to all variants of PIM protocols, i.e., 96 PIM-SM, PIM-SSM, PIM-DM, and BIDIR-PIM, on both IPv4 and IPv6 97 networks. There is an exception for the processing of PIM-SM 98 Register/Register-Stop Message, which should reference the MTU 99 information on the entire path between source DR and RP, as described 100 in 4.4.1 of [RFC4601]. 102 It should be noted that PIM MTU Option extension is different from 103 multicast PMTU discovery mentioned in [RFC1981] . Section 5.2 of 104 RFC1981 describes that an implementation could maintain a single PMTU 105 learned across the whole multicast distribution tree. This might 106 result in using smaller packets than necessary for a lot of paths. 107 And because the end to end paths can be very dynamic it could make 108 the effort too complex. This PMTU is used in encapsulating a 109 'multicast data packet' to avoid fragmentation in multicast data 110 plane as the packet travels on all paths of the tree. Whereas PIM 111 MTU option works in control plane and has a per-hop nature - it only 112 functions between adjacent one-hop PIM neighbors to guide the sending 113 of a 'PIM protocol message'. 115 The maintenance of MTU in control plane (by PIM Hello MTU Option) and 116 data plane (by PMTU) are for different purposes and are run 117 independently - the control plane makes sure that forwarding paths 118 are setup even there exists asymmetric MTUs on different links, while 119 the data plane is to make multicast delivery efficient by avoiding 120 fragmenting/reassembling operation, which could be done by means of 121 acquiring minimal MTU on all paths, and of applying it in generating 122 a data packet on first-hop or head-end. Control plane cannot 123 preclude fragmentation, but it is the premise of normal data 124 forwarding - even if some data packets exceeding limitation of some 125 points of the paths cannot be processed properly, other packets 126 meeting the PMTU requirements will be normally forwarded and 127 delivered. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. MTU Option and its Operation Rule 137 To record the minimum usable sending MTU value on an interface, a new 138 General Purpose non-group-specific state - Sending MTU state is 139 introduced in PIM protocols (for General Purpose State referring to 140 4.1.1 of [RFC4601] and [RFC3973], and 3.1.1 of [RFC5015]). It is 32- 141 bit long and is unique on an interface whether the link connected is 142 point-to-point or multi-accessed. The initial value of the Sending 143 MTU state should be set to the outbound MTU of the interface, taking 144 either the configured MTU or the default MTU value (referring to 7.1 145 of [RFC1191] for common MTU for different link types). 147 When an MTU Hello Option is received from a neighbor, a PIM router 148 parses the MTU value in the option and decides whether or not it 149 should accept the value and store it in the Sending MTU field. A 150 router should not accept too small a value to prevent extreme 151 fragmentation from deteriorating the router's performance. If the 152 MTU value is valid from a legal neighbor, it compares the value with 153 the MTU value currently stored in the Sending MTU field, and makes 154 the replacement if the former is less than the latter. 156 Unlike other PIM Hello option, MTU Option is not required being 157 supported simultaneously by all PIM neighbors connecting to a 158 network. An MTU-capable router only considers the MTU of a trusty 159 neighbor from which a valid MTU option is received. An MTU-capable 160 PIM router should use MTU option in its Hello message, and should 161 keep the Sending MTU state to the initial value if no neighbor 162 reports a valid MTU Option. Finally, an MTU-incapable router should 163 ignore an MTU option on reception. 165 The Sending MTU state should be checked before sending a multicast 166 PIM message, to ensure the length of the message does not exceed the 167 MTU limit of both the sending and receiving links. It should be 168 noted that as a convention, the length calculation starts from the 169 beginning of an IP header. 171 4. Option Format 173 A Hello MTU Option has the following format: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type = TBD | Length = 4 | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Value = inbound MTU of this interface | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Type: to be assigned by IANA if this option is accepted. The field 184 is 16-bit long. 186 Length: the length of the Value field. The field is 16-bit long. 188 Value: inbound MTU value for this interface. The field is 32-bit 189 long. 191 5. IANA Considerations 193 The Type field should be allocated by IANA if MTU option is accepted. 195 6. Security Considerations 197 The potential security threat for MTU option should be the denial- 198 of-service attack of extremely fragmenting PIM messages, by 199 advertising much smaller MTU value than necessary. A remedy is to 200 require a PIM router to check the validity of a neighbor's MTU value 201 before accepting it. 203 7. Acknowledgements 205 The authors would like to acknowledge Hou Yunlong, Mach Chen, Liu 206 Yisong, Stig Venaas, Bill Fenner, Dino Farinacci, and Chiranjeevi 207 Ramana Rao for their valuable comments and discussions on the work. 209 8. Normative References 211 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 212 November 1990. 214 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 215 for IP version 6", RFC 1981, August 1996. 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 221 Independent Multicast - Dense Mode (PIM-DM): Protocol 222 Specification (Revised)", RFC 3973, January 2005. 224 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 225 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 226 Protocol Specification (Revised)", RFC 4601, August 2006. 228 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 229 "Bidirectional Protocol Independent Multicast (BIDIR- 230 PIM)", RFC 5015, October 2007. 232 Authors' Addresses 234 Liu Hui 235 Huawei Technologies 236 Building Q14, No.156, Beiqing Rd. 237 Beijing 100095 238 China 240 Phone: 8610-60610012 241 Email: helen.liu@huawei.com 242 Tina Tsou 243 Huawei Technologies (USA) 244 2330 Central Expressway 245 Santa Clara CA 95050 246 USA 248 Phone: +1 408 330 4424 249 Email: Tina.Tsou.Zouting@huawei.com