PIM Working Group H. Liu Internet-Draft Huawei Technologies Intended status: Standards Track T. Tsou Expires: September 1, 2012 Huawei Technologies (USA) February 29, 2012 PIM MTU Hello Option for PIM Message Encapsulation draft-lts-pim-hello-mtu-00 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 September 1, 2012. 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 September 1, 2012 [Page 1] Internet-Draft PIM Hello MTU Option February 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 . . . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Liu & Tsou Expires September 1, 2012 [Page 2] Internet-Draft PIM Hello MTU Option February 2012 1. Introduction A PIM router often needs to preserve a great many (*,G) or (S,G) states to enable traffic forwarding for large scale multicast channels. These states are usually set up and kept alive by periodical PIM messages (e.g.PIM Join) sent from its downstream neighbors. For each periodical assembling of these states into a PIM message, multiple packets will possibly be generated due to MTU limitation on the sending PIM interface. Current implementation uses merely sending link MTU to calculate maximum PIM packet length without considering the receiving interface link MTU of the neighbor. It has some drawbacks because if the MTU of the downstream sending interface is larger than that of the upstream receiving interface, PIM protocol packets encapsulated according to the sending MTU will most possibly be discarded for exceeding the MTU limitation of the upstream receiving interface. 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 taking 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, and introduces a new PIM MTU Hello option. PIM MTU option is carried in periodical PIM Hello messages. A PIM router uses the option to inform its own receiving link MTU on an interface to its neighbor(s). The neighbor(s) will use the MTU when encapsulating and sending PIM protocol messages to this router. 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 PIM networks. Because MTU issue for unicast Register Message has already been considered in PIM-SM (4.4.1 in [1]), neighboring MTU is only referred when encapsulating PIM messages with multicast destination. It should be noted that PIM MTU discovery proposed here is different from multicast PMTU discovery described in RFC1981 [2]. Section 5.2 of RFC1981 requires that an implementation should 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 this could make the effort too complex. PMTU is used in encapsulating a 'multicast data packet' (not a 'PIM protocol packet' as here) to avoid fragmentation as the packet travels on the paths of the tree. Whereas PIM MTU option works in control plane and has a per-hop Liu & Tsou Expires September 1, 2012 [Page 3] Internet-Draft PIM Hello MTU Option February 2012 nature - it only functions between one-hop PIM neighbors and helps PIM protocols to establish correctly the multicast forwarding states. 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 RFC 2119 [3]. 3. MTU Option and its Operation Rule To record the minimum sending MTU value on an interface, a new General Purpose non-group-specific state (say Sending MTU state) is introduced in PIM protocols (for General Purpose State referring to 4.1.1 of [1] and [4], and 3.1.1 of [5]. It is 32-bit long and is unique on an interface even if what is connected is a multi-access network. The initial value of the Sending MTU state should be set to the outbound MTU, or if unavailable, set to the default MTU of the interface. When an MTU Hello Option is received from a neighbor, the PIM router parses the MTU value in the option and decides whether or not it should accept the value and should store it in the Sending MTU field. A router should not accept too small a value to prevent extreme fragmentation 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. 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. Liu & Tsou Expires September 1, 2012 [Page 4] Internet-Draft PIM Hello MTU Option February 2012 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 before accepting it. 7. Acknowledgements The authors would like to acknowledge Hou Yunlong and Mach Chen for their valuable comments on the work. 8. Normative References [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2007. [2] McCann, J., Deering, S., Mogul, J., and L. Vicisano, "Path MTU Liu & Tsou Expires September 1, 2012 [Page 5] Internet-Draft PIM Hello MTU Option February 2012 Discovery for IP version 6", RFC 1981, August 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [4] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [5] 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 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 September 1, 2012 [Page 6]