<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<rfc category="std" docName="draft-anish-reliable-pim-registers-02" ipr="trust200902">

<!-- ID Version 02 -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title>Reliable Transport For PIM Register States</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <author initials="A." surname="Peter" fullname="Anish Peter" role="editor">
      <organization>Individual contributor</organization>
      <address>
      <postal>
      <street>Brunton Road</street>
      <code>560001</code>
      <city>Bangalore</city>
      <region>KA</region>
      <country>India</country>
      </postal>
      <email>anish.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Robert Kebler" initials="R." surname="Kebler">
      <organization>Juniper Networks, Inc.</organization>
      <address>
      <postal>
      <street>1194 N. Mathilda Ave.</street>
      <city>Sunnyvale</city>
      <region>CA</region>
      <code>94089</code>
      <country>US</country>
      </postal>
      <email>rkebler@juniper.net</email>
      </address>
    </author>

    <author initials="V." surname="Nagarajan" fullname="Vikram Nagarajan">
      <organization>Juniper Networks, Inc.</organization>
      <address>
      <postal>
      <street>Electra, Exora Business Park</street>
      <city>Bangalore</city>
      <region>KA</region>
      <code>560103</code>
      <country>India</country>
      </postal>
      <email>vikramna@juniper.net</email>
      </address>
    </author>

    <author fullname="Toerless Eckert" initials="T." surname="Eckert">
      <organization>Huawei USA - Futurewei Technologies Inc.</organization>
      <address>
      <email>tte+ietf@cs.fau.de</email>
      </address>
    </author>

    <author fullname="Stig Venaas" initials="S." surname="Venaas">
      <organization>Cisco Systems, Inc.</organization>
      <address>
      <email>stig@cisco.com</email>
      </address>
    </author>

    <date day="19" month="March" year="2018"/>

    <area>Routing</area>

    <workgroup>Protocol Independent Multicast (pim) </workgroup>

    <keyword>PIM</keyword>
    <keyword>Register</keyword>
    <keyword>TCP</keyword>
    <keyword>SCTP</keyword>
    <keyword>PORT</keyword>
    <keyword>RP</keyword>

    <abstract>
      <t> This document introduces a hard-state, reliable transport for the
      existing PIM-SM registers states. This eliminates the needs for 
      periodic NULL-registers and register-stop in response to each
      data-register or NULL-registers. </t>
      <t> This specification uses the existing PIM reliability mechanisms defined
      by <xref target="RFC6559"> PIM Over Reliable Transport  </xref>.  
      This is simply a means to
      transmit reliable PIM messages and does not require the support for
      Join/Prune messages over PORT as defined in <xref target="RFC6559"> </xref>.  </t>

    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC2119</xref>.</t>
    </note>
  </front>

  <middle>
  <section title="Introduction">
      <t>Protocol Independent Multicast-Sparse Mode Register mechanism
      serves the following purposes. </t>

      <t><list style="format %c,">
	<t> With a register, First-Hop-Router (FHR) informs the RP (that way the network) that a particular
	multicast stream is active </t>
	<t> A register helps avoid initial packet loss. (Initial packet loss could
		happen in an anycast-RP deployment even when packet registers
		are used.) </t>
	<t> Through its periodic refreshes register keeps RP informed about the aliveness of
	this multicast stream.</t> 
      </list></t> 
      <t> As it is defined in <xref target="RFC4601"> </xref> , 
      register mechanisms face limitations, 
      when the number of multicast streams on the network is high, especially
      when one RP is expected to serve a large number of streams. These
      problems are mainly due to these factors.</t>

      <t><list style="format %c,">
      <t>PIM register needs control-plane and data-plane intervention to
      handle it.</t>
      <t>Due to the nature of PIM register, First-Hop-Router and RP now needs
      to maintain states and timers for each register state entry.</t> 
      <t>PIM register's requirements for periodic refresh and expiry, is quite
      aggressive and makes them vulnerable when the PIM speaker could not find
      cycles to meet these needs</t> 
      </list></t> 
      <t> To take for instance a major multicast application the IPTV. With the streaming servers connected to FHR. A restarting, FHR would result 
	      in a burst of register messages at line rate. The RP may get overloaded with packet registers. 
	      Which will continue untill RP is able to create states and do a register-stop. In the meantime many flows may go unserviced due to drops. 
	      In addition to affecting multicast streams it may lead to starvation for other processing done by the controlplane application. 
	      With Anycast RP, this becomes even more tricky due to the control-plane's job to forward the registers to the rp-set. </t>
      <t> In general: PIM registers have limitation in connections across WAN. It has no flow-control mechanisms, making PIM not compatible with 
      IETF transport/congestion control expectations. It is challenging to deployed it over WAN or other bandwidth limited networks. 
      High amount of state: periodic retransmission creates undesirable processing load. Especially with larger mesh-groups (re-send same (S,G) N-times, periodically).  </t>

  </section>

  <section title="Reliable Register Overview">
  <t>Reliable PIM register extends <xref target="RFC6559"> PIM PORT</xref> to
  have PIM register states to be sent over a reliable transport.</t> 

  <t>This document introduces 'targeted' hellos between any two PIM peers. This
  helps in capability negotiation and discovery between two PIM speakers (FHR
  and RP in the context of this document). Once this discovery happens,
  First-Hop-Router would setup a reliable transport connection based on the
  negotiated parameters.</t>

  <t>Over this reliable connection, First-Hop-Router would
  start sending to RP the source and group addresses of the multicast streams
  active with it. When any of this stream stops, First-Hop-Router would sent
  an update to RP about the streams that have stopped. This way once a reliable
  connection is setup, First-Hop-Router would update RP with its existing
  active multicast streams. Subsequently it would sent incremental updates
  about the change to RP.</t> 

  <t>For a multicast application that may demand initial packets or for bursty
  sources existing data-registers may be used. For them the RP would now
  respond with a 'reliable'-register-stop, which could persist until the
  First-Hop-Router withdraws the register-state.</t> 
  </section>

  <section title="Targeted Hellos">
    <t> PIM hellos defined in <xref target="RFC4601" > PIM-SM </xref> confines
    them to link level. This document extends these hellos to support
    'targeted' hellos. </t>
    <t> Targeted hellos are identical to existing hellos messages except that
    they would have an unicast address as its destination address. It would
    traverse multiple hops using the unicast routing to reach the targeted hello
    neighbor. </t>
    <section title="New Hello Optional TLV's">
	<t>Option Type: Targeted hello </t>

	<figure anchor="Hello-opt-tlvH0" title="PIM Hello Optional TLV">
	 <artwork>
    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 = H1 (for alloc)     |           Length = 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|R|                        Reserved                   |  Exp  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        </artwork>
      </figure>
   <t>Assigned Hello Type values can be found in IANA PIM registry.</t>

   <t>Type: 	This is subject to IANA allocation. Its stated as H1 for 
   reference </t> 
   <t>Length:  	Length in bytes for the value part of the Type/Length/Value
      encoding fixed as 4. </t>

   <t>F:        To be set by a router that wants to be a First-Hop-Router. </t>
   <t>R:        To be set by a RP that is capable taking the role of an RP as per
   the current states. </t>
   <t>Reserved:	Set to zero on transmission and ignored on receipt.</t>
   <t> Exp:   	For experimental use [RFC3692].  One expected use of these bits
   would be to signal experimental capabilities.  For example, if a router
   supports an experimental feature, it may set a bit to indicate this.  The
   default behavior, unless a router supports a particular experiment, is to
   keep these bits reset and ignore the bits on receipt. </t> 

    </section>
    <section title="Differences from Link-Level hellos">
    <t>The Major differences that Link-Level-Hellos have over Interface hellos
    are, </t> 
    <t> <list style="format %d." counter="cnt1">
    <t>Destination address would be an unicast address unlike
    ALL-PIM-ROUTER destination address for link-level hellos</t>
    <t>TTL value would be the system default TTL</t>
    <t>Targeted Hellos SHOULD carry Targeted Hello Optional TLV (Defined in
	    this document.)</t>
    <t>Holdtime SHOULD NOT be set as 0xffff by a targeted hello sender, and
    such hellos should be discarded up on receive.</t>
    </list>
    </t>
    </section>
    <section title="Address in Hello message">
    <t>When sending targeted hellos, the sender SHOULD send with its primary
    reachable address (may be its loopback address) as the source 
    address for the hellos. The other addresses
    that are relevant SHOULD be added in the secondary address list.
    </t> 
    </section>
    <section title="Timer Values">
    <t>The timers relevant to this specification are in relation to PIM hello.
    The recommended timer values are </t> 
    <t><list style="format %d:" counter="count 1">
    <t>   PIM Targeted Hello default refresh time : 60s 
    (2 * Default Link-level hello time)</t> 
    <t>   PIM Targeted Hello default hold time : 210s (3.5 times targeted hello
	    default refresh time)</t> 
    </list></t> 
    </section>
    <section title="Targeted Neighbor">
    <t> A Targeted PIM neighbor is a neighbor-ship established by virtue of
    exchanging targeted hello messages.</t> 
    <t>A First-Hop-Router (The initiator) 
    that learns the RP's address would start sending
    hellos to the known RP address (could be anycast-address).</t>
    <t>The RP (The Responder) when it
    receives this hello, would add sender as a targeted neighbor and would
    respond to this targeted neighbor from it primary address. 
    The responder SHOULD also include its
    any-cast address (If available) in the secondary address list. 
    The First-Hop-Router when
    receiving this hello would form a targeted neighbor with the anycast
    address.</t> 
    <t>The RP upon hold-time-out for the neighbor would remove this neighbor
    and its associated states.</t>
    <t>The initiator or responder upon having a need to terminate a targeted
    neighbor MAY send hello with hold-time as 0.</t> 
    </section>
    <!--
    <section title="Good-bye Hello">
    <t>A hello message with holdtime 0 indicates a goodbye hello. A PIM router
    may send goodbye hello to indicate its neighbor to timeout that
    neighborhood immediately. This behavior is desirable when router has to
    reboot or when finds that new properties of the router does not require
    retaining this targeted neighbor.</t> 
    <t>When goodbye hello is received from a targeted neighbor, the peer
    should immediately timeout the neighbor and would subsequently terminate
    the reliable connection (if not already terminated).</t> 
    </section> 
    -->
  </section>
  <section title="Reliable Connection setup">
    <t>A reliable connection has to be setup between the First-Hop-Router and
    RP for reliable registers to happen. Targeted hellos works as the medium
    for discovery and capability-negotiation between the two peers. </t> 
    <section title="Active FHR">
    <t>Once First-Hop-Router and RP discovery each other, First-Hop-Router
    takes the active role. First-Hop-Router would listen for RP to
    connect once it forms targeted neighbor-ship with RP. 
    The RP would be expected to use its primary address, which it would have 
    used as the source address in its PIM hellos.</t> 
    </section>
    <section title="Connection setup between two RP's">
    <t>In a network if there happens to be two RP's which are
    First-Hop-Router's too, then the mechanism could result in two connections
    getting established. It's desirable to have just one connection instead of
    two. First-Hop-Router could detect this condition the when it
    receives hello with targeted hello header identifying that the RP want to be
    First-Hop-Router too.</t>
    <t>In this condition the connection setup could used the procedures
    stated in <xref target="RFC6559">PIM over reliable transport </xref> </t> 
    </section>
    <section title="Hello Generation ID and reconnect">
    <t>If RP or First-Hop-Router gets into a situation needing for
    capability-renegotiation or reconnect, it would change the hello
    generation ID (gen-ID) to
    notify it peer to reset all the states and re-init this peering. The
    trigger for this could be configuration change or local operating parameter
    change, restart, etc. . .</t> 
    </section> 
    <section title="Handling Connection or reachability loss">
    <t>Connection loss or reachability loss could happen for one or more of the
    following reasons</t> 
    <t><list style="format %d:" counter="count ">
	<t>PORT Keep-alive time out</t>
	<t>Targeted neighbor loss</t>
	<t>Reliable Connection close</t> 
    </list></t> 
    <t>Upon detecting one of these conditions, the connection with the
    peer SHOULD be closed immediately and the states created by the peer
    SHOULD be cleared after a grace-period, long enough for the peer to 
    re-establish connection and re-sync the states. </t> 
    <t>This interval for re-sync would involve the initial time needed for
    re-establishing the connection, followed by transmission and reception of
    the states from FHR to RP over the reliable connection.</t>
    <t>The ideal interval for this re-sync period could not be predicted, 
    hence the this should be a configurable parameter with default
    value as 300s.</t> 
    </section> 
  </section>
  <section title="Anycast RP's">
    <t>PIM uses <xref target="RFC4610"> Anycast-RP </xref> as a mechanism for 
    RP redundancy. This section
    describes how anycast-RP would work with this specification.</t>
    <section title="Targeted Hellos and Neighbors">
    <t>An RP that serves an anycast RP address, would know the primary
    addresses of other RP's serving the anycast address. These
    anycast-RP's would form a full mesh of targeted hello-neighbor-ships. In
    its targeted hello options tlv, the R bit MUST be set. The secondary 
    address list in the PIM hello message SHOULD include the anycast-addresses that
    the sender is servicing.</t> 
    </section> 
    <section title="Anycast-RP connection setup">
    <t>A full mesh of connection is needed among the anycast-RP's of the same
    anycast address. Once targeted
    neighbor-ship is established, it would use the <xref target="RFC6559">PIM
    PORT</xref> procedures to setup reliable connection among them.</t>
    </section> 
    <section title="Anycast-RP state sync">
    <t>An anycast-RP that gets the register state from a peer who's address is
    in the RP-set of address for the given group would update the register
    state and would retain the state. If the peer address is not in the RP-set
    address for the RP-group range, then the RP would replicate the state to
    all the other RP's in the RP-set. This procedure and forwarding rules are
    similar to the existing forwarding rules in 
    <xref target="RFC4610"> Anycast-rp </xref> register
    specification.</t> 
    <t>An RP should identify register state as a combinations of (source,
    group, 'PORT connection'). Where 'PORT connection' is the 
    reliable connection with the PORT peer which had reported this s,g. 
    Following considerations
    are made for a register-state identity. </t>
    <t><list style="format %C." >
    <t>Reconnect: Connection between RP and First-Hop-Router could get
    re-established for various reasons. The register-states would get
    retransmitted over the new connection. Then it should be possible for RP to
    identify and 
    timeout register-states on the old connection and retain the right set of 
    states.</t>
    <t>DR-change: When DR in the First-Hop-LAN changes, a new First-Hop-Router
    would be retransmitting the same set of SG's that are already known and
    the old DR would be withdrawing the states advertised by it.</t> 
    <t>FHR primary address change: In this case too connection would get
    re-established and state handling would be similar to case A. </t> 
    <t>Multi-homed sources (but not on same LAN): In this case different
    First-Hop-Routers could be sending the same register-states. Then RP should
    be capable of identifying register-state along with the peer.</t> 
    </list></t> 

    </section> 
    <section title="Anycast-RP change">
    <t>In the event of nearest anycast-RP changing over to a different router,
    First-Hop-Router would detect that when it starts receiving PIM hellos with
    a different primary address for the same anycast address. This
    can also happen if the primary address of present anycast-RP has changed.
    </t>
    <t>Upon detecting
    this scenario, the First-Hop-Router would establish connection and
    transmit its states to the new peer. Subsequently 
    older connection would get terminated due to neighbor timeout.</t> 
    </section> 
    <section title="Anycast-RP with MSDP">
    <t><xref target="RFC3618"> MSDP </xref> is an alternative mechanism for 
    'active multicast stream state' synchronization between RP's. When MSDP is used, PIM's anycast 
    synchronization need not be used. An anycast-RP network could use MSDP
    instead of PIM procedures for
    state synchronization among anycast-RP's. This document does not state any
    change in MSDP specification and usage</t>
    <t>In such deployments, PIM will
    not have RP-set configured. As RP-set address is not available PIM
    procedures for Anycast-RP synchronization does not apply. </t> 
    <t>MSDP being a soft-state oriented protocol, it depends on frequent state
    refreshes over the reliable TCP transport. The support for mesh-groups in MSDP
    could be advantageous in some case.</t> 
    </section> 
  </section> 
  <section title="PIM-registers and Interoperation with legacy PIM nodes">
  <t>It may not be possible for PIM node to migrate altogether onto a
  PORT-registers in one go. Also there could be a few nodes in the network,
  which may not support PORT register states. This section states how both
  could interoperate.</t>
    <section title="Initial packet-loss avoidance with PORT">
    <t>If its found that a few streams in the multicast network has to have
    initial packets to be delivered to the receiver, the existing PIM register
    mechanism could be used for them. For these streams a PORT register-stop
    message would be sent by the RP to First-Hop-Router. </t> 
    </section> 
    <section title="First-Hop-Router does not support PORT">
    <t>If the First-Hop-Router is not capable of doing PORT-register, then it
    would not establish targeted hello neighbor-ship with the RP. Hence
    reliable connection also would not be established. To handle such
    scenarios RP should accept PIM register messages and should respond to
    them with register-stop messages. </t> 
    </section> 
    <section title="RP does not support PORT">
    <t>If the RP is not capable of doing PORT-register, then it
    would not respond to the targeted hellos from the RP. Hence 
    reliable connection also would not be established. In this case
    First-Hop-Router could sent existing packet registers to RP.  </t> 
    </section> 
    <section title="Data-Register free operations">
    <t>If initial packet loss is acceptable in a multicast network, then
    Data-Registers could be avoided altogether in such networks. In such
    network PORT-Register-state specified in this document alone would be
    supported. </t> 
    </section> 
  </section> 
  <!-- TODO
  <section title="PORT-Register-Stops">
  </section> 
  -->
  <section title="PORT message">
    <t> This document defines new PORT register state message and PORT
    register-stop messages, to the existing
    messages in PORT specification. </t> 
    <section title="PORT register message TLV">
    <figure anchor="PORT-reg-msg" title="PORT Register State Message">
     <artwork>
   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 = P1 (for alloc)     |        Message Length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            Reserved                   | Exp.  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |B|N|A|                      Reserved-1                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            src addr-1                         z
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  z                            grp addr-1                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  z                            2, 3, . . .                        z
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |B|N|A|                      Reserved-n                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            src addr-n                         z
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  z                            grp addr-n                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     </artwork>
     </figure>

   <t>Type: This is subject to IANA allocation. 
   It would be next unallocated value, which is referred untill allocation as
   P1. </t> 
   <t>Length:   Length in bytes for the value part of the Type/Length/Value
      </t>
   <t>B: As specified in <xref target="RFC4601"> </xref>  (set as 0 on
          send and ignore when received)</t>

   <t>N: As specified in <xref target="RFC4601"> </xref>  (set as 1 on 
          send and ignore when received.) </t>
   <t>A: This flag signifies if the SG is to be Added or Deleted. When
   cleared, it indicates that the First-Hop-Router is withdrawing the SG
   .</t>
   <t>src addr-x : This is the encoded source address of an ipv4/ipv6 stream </t> 
   <t>grp addr-x : This is the encoded group address of an ipv4/ipv6 stream </t> 
   <t>Reserved:  Set to zero on transmission and ignored on receipt. These
   reserved bits are for properties that apply to the entire message.</t>
   <t>Reserved-n:  Set to zero on transmission and ignored on receipt. These
   reserved bits are for properties that apply to any particular sg.</t>
   <t>Exp:    :  For experimental use.</t> 

    <t></t>
    </section> 
    <section title="Sending and receiving PORT register messages">
    <t>The First-Hop-Router upon learning a new stream would send a register
    state
    add message to the corresponding RP. If the reliable connection got setup
    later, then once the connection becomes established it would send the
    entire list of streams active with it. </t> 
    <t>When KAT timer for a multicast stream expires, it would send
    an update to RP to remove that stream from its list.</t> 
    <t>An RP would maintain a database of multicast streams (src, grp) active
    along with the peer from which it had learned it. If the receiver RP is an
    anycast RP, it SHOULD re-transmit this register state message to each of
    the other anycast RP. An RP SHOULD not re-transmit a register state message
    it received from an another anycast-RP.</t> 
    </section> 
    <section title="PORT register-stop message TLV">
    <figure anchor="PORT-reg-stop-msg" title="PORT Register Stop Message">
     <artwork>
   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 = P2(for alloc)      |        Message Length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            Reserved                   | Exp.  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            Reserved-1                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            src addr-1                         z
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  z                            grp addr-1                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  z                           2, 3, . . .                         z
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            Reserved-n                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            src addr-n                         z
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  z                            grp addr-n                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     </artwork>
     </figure>

   <t>Type: This is subject to IANA allocation. 
   It would be next unallocated value, which is referred untill allocation as
   P2. </t> 
   <t>Length:   Length in bytes for the value part of the Type/Length/Value </t>

   <t>src addr-x : This is the encoded source address of an ipv4/ipv6 stream </t> 
   <t>grp addr-x : This is the encoded group address of an ipv4/ipv6 stream </t> 
   <t>Reserved:  Set to zero on transmission and ignored on receipt. These
   reserved bits are for properties that apply to the entire message.</t>
   <t>Reserved-n:  Set to zero on transmission and ignored on receipt. These
   reserved bits are for properties that apply to any particular sg.</t>
   <t>Exp:    :  For experimental use.</t> 

    <t></t>
    </section> 
    <section title="Sending and receiving PORT register stop messages">
    <t>PORT register-stop messages are send only as a response to receiving
    packet registers from a PIM peer, with which a reliable connection has
    been established. If reliable connection is not available, the RP
    should consider the peer as a legacy node and should respond to this PIM
    register-stop message as defined in <xref target="RFC4601"> PIM-SM</xref> 
    </t> 
    <t>The First-Hop-Router up on receiving PORT-Register-Stop message should
    treat that as an indication from RP that it does not require the packets
    over the PIM tunnel and should stop sending register messages.</t> 
    </section> 
    <section title="PORT Keep-Alive Message">
    <t>The PORT Keep-alive messages as specified in 
    <xref target="RFC6559"> PIM over Reliable Transport </xref> would be used
    to check the liveliness of the peer and the reliable session</t> 
    </section>
  </section>

  <section title="Management Considerations">
  <t>PORT-register is capable of configuration free operations. But its recommended
  to have it as configuration controlled. </t> 
  <t>Implementation should provide knobs needed to stop supporting
  data-registers on a router. </t> 
  <!-- TODO 
  <t>In an implementation having support for PORT registers and data registers
  preference should be give for PORT registers over data registers.</t> 
  -->
  </section> 
  <!-- TODO TBW
  <section anchor="Acknowledgements" title="Acknowledgements">
  </section>
  -->

  <section anchor="IANA" title="IANA Considerations">
  <t>This specification introduces new TLV in PIM hello and in PIM PORT
  messages. Hence the tlv ids for these needs IANA allocation</t> 
      <section title="PIM Hello Options TLV">
	<t>The following Hello TLV types needs IANA allocation. 
        Place holder are kept to differentiate the different types.</t> 
	 <texttable anchor="PIM-Hello-Options-IANA-Allocation" 
          title="Place holder values for PIM Hello TLV type until IANA allocation">
          <ttcol align="center">Value</ttcol>
          <ttcol align="left">Length</ttcol>
          <ttcol align="left">Name</ttcol>
          <ttcol align="left">Reference</ttcol>
          <c>H1 (next-available)</c>
          <c>4 (Fixed)</c>
          <c>Targeted-Hello-Options</c>
          <c>This document</c>
        </texttable>
      </section> 
      <section title="PIM PORT Message Type">
      <t>The following PIM PORT message TLV types needs IANA allocation.
        Place holder are kept to differentiate the different types.</t> 
	 <texttable anchor="PIM-PORT-Message-IANA-Allocation"
          title="Place holder values for PIM PORT TLV type for IANA allocation">
          <ttcol align="left">Value</ttcol>
          <ttcol align="left">Name</ttcol>
          <ttcol align="left">Reference</ttcol>
          <c>P1 (Next available)</c>
          <c>PORT Register-state</c>
          <c>This document</c>
          <c>P2 (Next available)</c>
          <c>PORT Register-stop</c>
          <c>This document</c>
        </texttable>
      </section> 
  </section>

  <section anchor="Security" title="Security Considerations">
    <section title="PIM Register Threats">
    <t>PIM register is considered as security vulnerability for PIM networks.
    <xref target="RFC4609"> </xref> 
    The concern arises mainly due to the existing PIM register protocol design
    where in any remote node could start sending line-rate multicast traffic
    as PIM registers due to malfunction, mis-configuration or from a malicious remote
    node. 
    </t> 
    </section> 
    <section title="Targeted Hello Threats">
    <t>This document introduces targeted hellos. This could be a seen as a
    new security threat. Targeted hellos are part of other IETF protocol
    implementations, which are widely deployed. In future introduction of a
    mechanism similar to those stated in <xref target="RFC7349"> RFC 7349 
    </xref> could be used in PIM.</t>
    </section> 
    <section title="TCP or SCTP security threats">
    <t> The security perception for this is stated in <xref target="RFC6559">
    </xref>. </t> 
    </section> 
  </section>

  <!-- TODO TBW 
  <section title="Appendix 1: PIM changes due to PORT Register">
  <t>TBW</t> 
  </section> 
  -->
  </middle>

  <!-- *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <!--msdp-->
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3618.xml"?>
      <!--pim-sm-->
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml"?>
      <!--pim-threats-->
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4609.xml"?>
      <!--anycast-->
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4610.xml"?>
      <!--port-->
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6559.xml"?> 
    </references>

    <references title="Informative References">
    <!--
      <?rfc include="http://www.iana.org/assignments/pim-parameters"?>
      -->
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7349.xml"?>
    </references>
  </back>
</rfc>

