PIM Working Group H. Liu Internet-Draft Huawei Technologies Intended status: Standards Track T. Tsou Expires: January 14, 2013 Huawei Technologies (USA) July 13, 2012 PIM MTU Hello Option for PIM Message Encapsulation draft-lts-pim-hello-mtu-01 Abstract This memo introduces a new PIM Hello MTU Option which is carried in PIM Hello messages. The MTU option enables interface MTU information to be exchanged among PIM neighbors, and PIM messages to be encapsulated in an efficient and consistent way. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 14, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Liu & Tsou Expires January 14, 2013 [Page 1] Internet-Draft PIM Hello MTU Option July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. MTU Option and its Operation Rule . . . . . . . . . . . . . . . 4 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Liu & Tsou Expires January 14, 2013 [Page 2] Internet-Draft PIM Hello MTU Option July 2012 1. Introduction A PIM router often needs to preserve a great many (*,G) or (S,G) multicast forwarding states to enable traffic forwarding for large scale of multicast channels. These states are usually set up and kept alive by each downstream router periodically sending Join Messages carrying its own forwarding states to its upstream neighbor. For each round of assembling these states into a PIM message, multiple segments of packets might be generated due to the MTU limitation on the sending PIM interface. Current implementation uses merely sending link MTU to calculate maximum PIM packet length without considering the receiving MTU of the neighbor(s). It has some drawbacks because if the MTU of the sending interface is larger than that of the receiving one, PIM protocol packets encapsulated according to the sending MTU will most possibly be discarded by the receiving router and the forwarding states cannot be properly established as a result. There are already faults being reported caused by inconsistent MTU configuration among PIM neighbors. Even though the problem could be resolved by requiring each PIM downstream interface to take less or equal MTU value than its upstream interface, it is inflexible for operation and does not scale because the interface or link conditions across the network might be diverse in practice. As a remedy, this memo recommends exchanging link MTU information among PIM neighbors by using a new Hello MTU Option. The option is carried in periodical PIM Hello messages for a router to inform its receiving link MTU parameter on an interface to the connected neighbor(s), so that the MTU information could be referenced by the neighbor(s) when they are sending PIM protocol messages on this link. PIM MTU Option can be applied to all variants of PIM protocols, i.e., PIM-SM, PIM-SSM, PIM-DM, and BIDIR-PIM, on both IPv4 and IPv6 networks. There is an exception for the processing of PIM-SM Register/Register-Stop Message, which should reference the MTU information on the entire path between source DR and RP, as described in 4.4.1 of [RFC4601]. It should be noted that PIM MTU Option extension is different from multicast PMTU discovery mentioned in [RFC1981] . Section 5.2 of RFC1981 describes that an implementation could maintain a single PMTU learned across the whole multicast distribution tree. This might result in using smaller packets than necessary for a lot of paths. And because the end to end paths can be very dynamic it could make the effort too complex. This PMTU is used in encapsulating a 'multicast data packet' to avoid fragmentation in multicast data Liu & Tsou Expires January 14, 2013 [Page 3] Internet-Draft PIM Hello MTU Option July 2012 plane as the packet travels on all paths of the tree. Whereas PIM MTU option works in control plane and has a per-hop nature - it only functions between adjacent one-hop PIM neighbors to guide the sending of a 'PIM protocol message'. The maintenance of MTU in control plane (by PIM Hello MTU Option) and data plane (by PMTU) are for different purposes and are run independently - the control plane makes sure that forwarding paths are setup even there exists asymmetric MTUs on different links, while the data plane is to make multicast delivery efficient by avoiding fragmenting/reassembling operation, which could be done by means of acquiring minimal MTU on all paths, and of applying it in generating a data packet on first-hop or head-end. Control plane cannot preclude fragmentation, but it is the premise of normal data forwarding - even if some data packets exceeding limitation of some points of the paths cannot be processed properly, other packets meeting the PMTU requirements will be normally forwarded and delivered. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. MTU Option and its Operation Rule To record the minimum usable sending MTU value on an interface, a new General Purpose non-group-specific state - Sending MTU state is introduced in PIM protocols (for General Purpose State referring to 4.1.1 of [RFC4601] and [RFC3973], and 3.1.1 of [RFC5015]). It is 32- bit long and is unique on an interface whether the link connected is point-to-point or multi-accessed. The initial value of the Sending MTU state should be set to the outbound MTU of the interface, taking either the configured MTU or the default MTU value (referring to 7.1 of [RFC1191] for common MTU for different link types). When an MTU Hello Option is received from a neighbor, a PIM router parses the MTU value in the option and decides whether or not it should accept the value and store it in the Sending MTU field. A router should not accept too small a value to prevent extreme fragmentation from deteriorating the router's performance. If the MTU value is valid from a legal neighbor, it compares the value with the MTU value currently stored in the Sending MTU field, and makes the replacement if the former is less than the latter. Liu & Tsou Expires January 14, 2013 [Page 4] Internet-Draft PIM Hello MTU Option July 2012 Unlike other PIM Hello option, MTU Option is not required being supported simultaneously by all PIM neighbors connecting to a network. An MTU-capable router only considers the MTU of a trusty neighbor from which a valid MTU option is received. An MTU-capable PIM router should use MTU option in its Hello message, and should keep the Sending MTU state to the initial value if no neighbor reports a valid MTU Option. Finally, an MTU-incapable router should ignore an MTU option on reception. The Sending MTU state should be checked before sending a multicast PIM message, to ensure the length of the message does not exceed the MTU limit of both the sending and receiving links. It should be noted that as a convention, the length calculation starts from the beginning of an IP header. 4. Option Format A Hello MTU Option has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value = inbound MTU of this interface | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: to be assigned by IANA if this option is accepted. The field is 16-bit long. Length: the length of the Value field. The field is 16-bit long. Value: inbound MTU value for this interface. The field is 32-bit long. 5. IANA Considerations The Type field should be allocated by IANA if MTU option is accepted. 6. Security Considerations The potential security threat for MTU option should be the denial- of-service attack of extremely fragmenting PIM messages, by advertising much smaller MTU value than necessary. A remedy is to require a PIM router to check the validity of a neighbor's MTU value Liu & Tsou Expires January 14, 2013 [Page 5] Internet-Draft PIM Hello MTU Option July 2012 before accepting it. 7. Acknowledgements The authors would like to acknowledge Hou Yunlong, Mach Chen, Liu Yisong, Stig Venaas, Bill Fenner, Dino Farinacci, and Chiranjeevi Ramana Rao for their valuable comments and discussions on the work. 8. Normative References [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. Authors' Addresses Liu Hui Huawei Technologies Building Q14, No.156, Beiqing Rd. Beijing 100095 China Phone: 8610-60610012 Email: helen.liu@huawei.com Liu & Tsou Expires January 14, 2013 [Page 6] Internet-Draft PIM Hello MTU Option July 2012 Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara CA 95050 USA Phone: +1 408 330 4424 Email: Tina.Tsou.Zouting@huawei.com Liu & Tsou Expires January 14, 2013 [Page 7]