Skip to main content

PIM MTU Hello Option for PIM Message Encapsulation
draft-lts-pim-hello-mtu-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Hui Liu , Tina Tsou (Ting ZOU)
Last updated 2012-02-29
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lts-pim-hello-mtu-00
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]