<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="exp" docName="draft-venaas-pim-port-pfm-00"
     ipr="trust200902">
  <?rfc toc="yes"?>

  <?rfc compact="yes"?>

  <?rfc subcompact="no"?>

  <?rfc symrefs="yes"?>

  <front>
    <title abbrev="PIM PORT PFM">PIM Flooding Protocol over Reliable Transport
    </title>

    <author fullname="Stig Venaas" initials="S." surname="Venaas">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Tasman Drive</street>

          <city>San Jose</city>

          <code>CA 95134</code>

          <country>USA</country>
        </postal>

        <email>stig@cisco.com</email>
      </address>
    </author>

    <author fullname="Balaji Ganesh" initials="B."
	    surname="Ganesh">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Tasman Drive</street>

          <city>San Jose</city>

          <code>CA 95134</code>

          <country>USA</country>
        </postal>

        <email>balagane@cisco.com</email>
      </address>
    </author>

    <author fullname="Kesavan Thiruvenkatasamy" initials="K."
	    surname="Thiruvenkatasamy">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Tasman Drive</street>

          <city>San Jose</city>

          <code>CA 95134</code>

          <country>USA</country>
        </postal>

        <email>kethiruv@cisco.com</email>
      </address>
    </author>

    <author fullname="Ramakrishnan Chokkanathapuram" initials="R."
	    surname="Chokkanathapuram">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Tasman Drive</street>

          <city>San Jose</city>

          <code>CA 95134</code>

          <country>USA</country>
        </postal>

        <email>ramaksun@cisco.com</email>
      </address>
    </author>

    <date/>
    <area>Routing</area>
    <keyword>Multicast</keyword>

    <abstract>
      <t>The PIM Flooding Protocol (PFM) defined in RFC8364 relies on sending
      periodic updates as it does not provide for any reliability. If a
      message is lost, the information will be provided in the next
      periodic update.</t>

      <t>This document extends the Reliable Transport Mechanism for PIM in
      RFC6559 to allow for sending PFM messages. This significantly reduces
      the PFM signaling by not requiring frequent periodic updates, and it
      provides for retransmission, allowing for quick recovery when an IP
      packet is dropped.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The PIM Flooding Protocol (PFM) defined in <xref target="RFC8364"/>
      relies on sending periodic updates as it does not provide for any
      reliability. If a message is lost, the information will be provided in
      the next periodic update. With PFM, a router will typically originate
      a full update every 60 seconds. This ensures that in case of packet
      drops, one usually will recover in 60 seconds. There is a trade-off
      between the number of updates and the recovery time.</t>

      <t>This document extends the Reliable Transport Mechanism for PIM in
      <xref target="RFC6559"/> to allow for sending PFM messages. We will
      refer to it as PORT (PIM Over Reliable Transport). The use of PORT
      significantly reduces the PFM signaling by not requiring frequent
      periodic updates, and it provides for retransmission, allowing for
      quick recovery when an IP packet is dropped. There will still be
      some full updates, but they can be sent much more rarely. If there
      is a packet drop, the reliable transport (TCP/SCTP) will ensure
      retransmission.</t>

      <t>The PORT sessions are established as specified in
      <xref target="RFC6559"/> between PIM neighbors. The sessions may
      be used to send other PORT messages, or they can be used only for
      PFM. Unless all the neighbors support PFM over PORT, regular PFM
      is used. How to signal support and how a router relays a PFM over
      PORT message as regular PFM and vice versa will be discussed in a
      later revision.</t>
    </section>

    <section title="Conventions used in this document">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when,
      and only when, they appear in all capitals, as shown here.</t>
    </section>

    <section title="Protocol specification">
      <t>PFM messages are sent over PORT by sending PORT PFM Update
      messages. They contain a PFM message as defined in
      <xref target="RFC8364"/>. They also contain a Full ID and a Delta ID
      that together specifies an ID for the update. Some updates are full
      updates, they contain all the information an originator is announcing.
      This would be similar to the periodic updates in regular PFM. Full
      updates over PORT are sent after some a configurable number of deltas
      have been sent, or whenever information needs to be withdrawn. Delta
      updates are used for triggered updates, similar to triggered updates
      in regular PFM. Each time there is some change a delta update can be
      triggered.</t>
      <t>The Full ID is an unsigned 48 bit value and it is assumed that it is
      always increasing. That is, any Full Update MUST always have a Full ID
      larger than any previous updates ever sent using the same Originator
      address. This MUST also be preserved if the router is reloaded. For the
      protocol to work, it may also be necessary to ensure this if an address
      used as an originator address is moved to a different router. It is
      RECOMMENDED that implementations use the number of seconds since 0h
      UTC on 1 January 1900 as the ID value. This allows for this protocol to
      be used for about four million years from the time of publication of
      this document. If for any reason the clock on a router is adjusted to
      a value back in time, an implementation would have to ensure that values
      are still increasing. Since Full Updates do not need to be sent every
      second, one should in this case be able to catch up.</t>
      <t>The first time a router originates a PFM message, it sends a Full
      update, even though it likely is triggered by some event. Full updates
      always have the Delta ID set to zero. After that it may send several
      Delta updates. For each Delta update, the Delta ID is incremented, while
      the Full ID remains the same. After some time it may decide to send a new
      full update. The Full ID in the full update MUST be larger than the
      Full ID in the previous update, and Delta ID is reset to zero. A Full
      update always has Delta ID zero, and a Delta update always has a
      non-zero Delta ID.</t>
      <t>When a router receives an update it performs RPF check as in regular
      PFM, boundary processing as in regular PFM. For each interface where the
      update would have been forwarded in regular PFM, it will be sent over
      PORT to all PFM PORT neighbors on the interface. If there are any
      neighbors on the interface not supporting PFM PORT it MAY revert to
      sending unreliable PFM messages.</t>
      <t>When a router receives a Full update it will remove any stored
      information from the originator and store the information in the
      new update. When it receives a Delta update it stores the update and
      keeps all previous information.</t>
      <t>Due to routers being restarted, PORT connections going down etc.,
      some routers MAY have missed some updates, potentially not having
      received any updates when restarting. In order to receive the most
      recent data from a neighbor it sends a PORT PFM Request message.
      For each originator the router has stored information from, it will
      include an option indicating the Full and Delta IDs of the last
      message received from that originator. A router receiving the
      Request compares the IDs of the specified originators
      with the latest data it has for these originators. If it has a more
      recent full update, it will first send it to the neighbor. Next, if
      it has more recent delta updates, it will send all the delta updates
      in the order they were received. This means that the requesting router
      receives the messages in order. It will first get a full update if a
      more recent version exists. The ID of this update may be much larger
      than the previously seen ID. The first Delta update received, if any,
      will have ID one if a Full update was received, or one larger than the
      Delta ID in the request, if not. If multiple Delta updates are received,
      the Delta ID will increment by one for each update. If the router has
      stored information for any originators not included in the request
      message, it will also send this information. It will first send the
      stored Full update, and then the Delta updates. As discussed above, the
      Delta updates MUST be sent in the order they were received, first sending
      update one, then update two, and so forth.
      </t>
      <t>The Delta ID is an unsigned 16 bits value. It never wraps around.
      A router MUST send a new full update if the Delta ID value is reaching
      its maximum value. It is RECOMMENDED having a configurable limit for
      how many Delta updates can be sent before sending a new Full update.
      Sending Full updates often is in some ways wasteful, but it limits how
      many deltas routers need to store, and they are also used to remove
      information that no longer is needed.
      </t>
      <t>When a router starts up, it is RECOMMENDED that before it originates
      any messages, it sends a PORT PFM Request message to receive any updates
      that neighbors may have stored for the originator address it would use.
      It could simply not include an option with the originator address it
      would use, and receive any information neighbors may have, or it could
      could include an option, but with the Full ID set to a value smaller
      than the Full ID it would use for the next Full Update. E.g., if the
      ID is based on the number of seconds since the epoch, it could send a
      request based on the current time. It would then normally get no updates
      from the neighbors with its own ID. If it does, it is RECOMMENDED to log
      an error, and ensure that the Full IDs of the next future Full Updates
      are larger than what was received.
      </t>
      <t>In order to handle extra ordinary cases where a router has
      originated messages with an erroneously large Full ID, it is
      RECOMMENDED that implementations provides a way for an administrator
      to clear the stored PFM state on a router, as well as a way to
      trigger sending of a Full Update on an originator. This means that as
      a last resort, an administrator could clear the state for an originator
      on all the routers, and optionally afterwards trigger a full update by
      the originator.
      </t>
    </section>

    <section title="PFM over PORT message definitions">
      <t>We define a new PORT message for sending a PFM message. This
      consists of an update version and a new PORT option containing a
      PFM message as defined in <xref target="RFC8364"/>. We also define
      a new PORT message for requesting a PFM update from a neighbor.
      This contains the latest update version that the router has from
      each originator and requests the neighbor to transmit any information
      that it is missing.</t>

      <section title="PORT PFM Update">
	<t>
	  <figure>
          <artwork><![CDATA[
     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 = TBD1          |        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Reserved                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Interface                           |
    |                               ID                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Full-update                         |
    |                               +-------------------------------|
    |              ID               |       Delta-update ID         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    PORT Option Type           |      Option Value Length      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Value                             |
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                               .                               \
    /                               .                               /
    \                               .                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    PORT Option Type           |      Option Value Length      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Value                             |
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
        </figure></t>
	<t>
	  <list style='hanging'>
            <t hangText='Type: '>
              Type is TBD.
            </t>
            <t hangText='Message Length: '>
	      Length in bytes for the value part of the Type/
	      Length/Value encoding.  If no PORT Options are included, the
	      length is 12.  If n PORT Options with Option Value lengths L1, L2,
	      ..., Ln are included, the message length is 12 + 4*n + L1 + L2 +
	      ... + Ln.
            </t>
            <t hangText='Reserved: '>
              Set to zero on transmission and ignored on receipt.
            </t>
            <t hangText='Interface ID: '>
	      This MUST be the Interface ID of the Interface ID Hello Option
	      contained in the PIM Hello messages that the PIM router is
	      sending to the PIM neighbor.  It indicates to the PIM neighbor
	      what interface to associate the update with. This is similar to
	      how the Interface ID is used in <xref target="RFC6559"/>.
	      The Interface ID allows us to do connection sharing while still
	      allowing the regular PFM RPF neighbor validation.
            </t>
            <t hangText='Full-update ID: '>
              If this is a full update, it is the ID of this update. If
	      this is a delta, then this is the ID of the last full update.
	      This is a 48 bit value.
            </t>
            <t hangText='Delta-update ID: '>
              If this is a delta update, this is the ID of the delta. Note that
	      the Full-update ID is also used for a delta. If this is a full
	      update, delta-update is set to 0. This is a 16 bit value.
            </t>
            <t hangText='PORT Options: '>
	      The general format is defined in <xref target="RFC6559"/>
	      section 5.3. This message MUST contain exactly one PFM Update
	      PORT option. The PFM Update PORT option is defined below. It
	      MAY contain other options that are defined for use in a PORT
	      PFM Update message.
            </t>
	  </list>
	</t>
      </section>

      <section title="PORT PFM Request">
	<t>
	  <figure>
            <artwork><![CDATA[
     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 = TBD2          |        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Reserved                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    PORT Option Type           |      Option Value Length      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Value                             |
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                               .                               \
    /                               .                               /
    \                               .                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    PORT Option Type           |      Option Value Length      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Value                             |
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
        </figure></t>
	<t>
	  <list style='hanging'>
            <t hangText='Type: '>
              Type is TBD.
            </t>

            <t hangText='Message Length: '>
	      Length in bytes for the value part of the Type/
	      Length/Value encoding.  If no PORT Options are included, the
	      length is 12.  If n PORT Options with Option Value lengths L1, L2,
	      ..., Ln are included, the message length is 12 + 4*n + L1 + L2 +
	      ... + Ln.
            </t>

            <t hangText='Reserved: '>
              Set to zero on transmission and ignored on receipt.
            </t>

            <t hangText='PORT Options: '>
	      The general format is defined in <xref target="RFC6559"/> section
	      5.3. This message MAY contain zero, one or multiple PFM Request
	      PORT options. The options indicate which versions the requesting
	      router has from which originators; one option per originator. No
	      options, means that the requesting router wants a full update
	      for all known originators. The PFM Request PORT option is
	      defined below. It MAY contain other options that are defined for
	      use in a PORT PFM Request message.
            </t>
	  </list>
	</t>
      </section>

      <section title="PORT PFM Update Option">
	<t>
	  <figure>
          <artwork><![CDATA[
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    PORT Option Type = TBD3    |     Option Value Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           PFM Message                         |
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
        </figure></t>
	<t>
	  <list style='hanging'>
            <t hangText='Type: '>
              Type is TBD.
            </t>
            <t hangText='Option Value Length: '>
	      The number of octets that make up the PFM Message.
            </t>
            <t hangText='PFM Message: '>
	      A PFM Message as defined in <xref target="RFC8364"/>.
            </t>
	  </list>
	</t>
      </section>

      <section title="PORT PFM Request Option">
	<t>
	  <figure>
          <artwork><![CDATA[
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    PORT Option Type = TBD4    |     Option Value Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Originator Address (Encoded-Unicast format)        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Full-update                         |
    |                               +-------------------------------|
    |              ID               |       Delta-update ID         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
        </figure></t>
	<t>
	  <list style='hanging'>
            <t hangText='Type: '>
              Type is TBD.
            </t>
            <t hangText='Option Value Length: '>
	      The length in octets of the originator address plus 6.
            </t>
            <t hangText='Originator Address: '>
	      The address of an originator as defined in
	      <xref target="RFC8364"/>.
            </t>
            <t hangText='Full-update ID: '>
	      The ID of the last full update that the router has stored.
	      It is requesting getting the most recent newer full update,
	      if any exists. Plus, any deltas after the last full update.
            </t>
            <t hangText='Delta-update ID: '>
	      The ID of the last delta update that the router has stored.
	      It is requesting getting the most recent newer full update,
	      using the Full-update ID, if it exists plus any deltas after
	      that. If there are no more recent full updates, then it is
	      requesting any delta updates more recent than this ID.
            </t>
	  </list>
	</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>To be completed. Largely similar to the considerations for PIM PORT.
      One may use TCP/SCTP authentication mechanisms.</t>
    </section>

    <section title="IANA considerations">
      <t>To be completed. IANA would need to assign types for the messages
      and options defined.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119' ?>
      <?rfc include='reference.RFC.6559'?>
      <?rfc include='reference.RFC.8174' ?>
      <?rfc include='reference.RFC.8364' ?>
    </references>

<!--
    <references title="Informative References">
      <?rfc include='reference.RFC.6166' ?>
    </references>
-->
  </back>
</rfc>
