Skip to main content

Reliable Transport For PIM Register States
draft-anish-reliable-pim-registers-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 Anish Peter , Robert Kebler , Vikram Nagarajan
Last updated 2015-03-09
RFC stream (None)
Formats
Additional resources
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-anish-reliable-pim-registers-00
Protocol Independent Multicast (pim)                       A. Peter, Ed.
Internet-Draft                                                 R. Kebler
Intended status: Standards Track                            V. Nagarajan
Expires: September 10, 2015                       Juniper Networks, Inc.
                                                           March 9, 2015

               Reliable Transport For PIM Register States
                 draft-anish-reliable-pim-registers-00

Abstract

   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.

   This specification uses the existing PIM reliability mechanisms
   defined by PIM Over Reliable Transport [RFC6559].  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 [RFC6559].

Requirements Language

   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 [RFC2119].

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 10, 2015.

Peter, et al.          Expires September 10, 2015               [Page 1]
Internet-Draft Reliable Transport For PIM Register States     March 2015

Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Reliable Register Overview  . . . . . . . . . . . . . . . . .   3
   3.  Targeted Hellos . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  New Hello Optional TLV's  . . . . . . . . . . . . . . . .   4
     3.2.  Differences from Link-Level hellos  . . . . . . . . . . .   5
     3.3.  Address in Hello message  . . . . . . . . . . . . . . . .   5
     3.4.  Timer Values  . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  Targeted Neighbor . . . . . . . . . . . . . . . . . . . .   6
   4.  Reliable Connection setup . . . . . . . . . . . . . . . . . .   6
     4.1.  Active FHR  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Connection setup between two RP's . . . . . . . . . . . .   6
     4.3.  Hello Generation ID and reconnect . . . . . . . . . . . .   7
     4.4.  Handling Connection or reachability loss  . . . . . . . .   7
   5.  Anycast RP's  . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Targeted Hellos and Neighbors . . . . . . . . . . . . . .   7
     5.2.  Anycast-RP connection setup . . . . . . . . . . . . . . .   8
     5.3.  Anycast-RP state sync . . . . . . . . . . . . . . . . . .   8
     5.4.  Anycast-RP change . . . . . . . . . . . . . . . . . . . .   8
     5.5.  Anycast-RP with MSDP  . . . . . . . . . . . . . . . . . .   9
   6.  PIM-registers and Interoperation with legacy PIM nodes  . . .   9
     6.1.  Initial packet-loss avoidance with PORT . . . . . . . . .   9
     6.2.  First-Hop-Router does not support PORT  . . . . . . . . .   9
     6.3.  RP does not support PORT  . . . . . . . . . . . . . . . .   9
     6.4.  Data-Register free operations . . . . . . . . . . . . . .  10
   7.  PORT message  . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  PORT register message TLV . . . . . . . . . . . . . . . .  10
     7.2.  Sending and receiving PORT register messages  . . . . . .  13
     7.3.  PORT register-stop message TLV  . . . . . . . . . . . . .  13
     7.4.  Sending and receiving PORT register stop messages . . . .  16
     7.5.  PORT Keep-Alive Message . . . . . . . . . . . . . . . . .  16
   8.  Management Considerations . . . . . . . . . . . . . . . . . .  16

Peter, et al.          Expires September 10, 2015               [Page 2]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  PIM Hello Options TLV . . . . . . . . . . . . . . . . . .  16
     9.2.  PIM PORT Message Type . . . . . . . . . . . . . . . . . .  17
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  17
     10.1.  PIM Register Threats . . . . . . . . . . . . . . . . . .  17
     10.2.  Targeted Hello Threats . . . . . . . . . . . . . . . . .  17
     10.3.  TCP or SCTP security threats . . . . . . . . . . . . . .  17
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     11.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Protocol Independent Multicast-Sparse Mode Register mechanism serves
   the following purposes.

   a,  With a register, First-Hop-Router (FHR) informs the RP (that way
       the network) that a particular multicast stream is active

   b,  A register helps avoid initial packet loss.  (Initial packet loss
       could happen in an anycast-RP deployment even when packet
       registers are used.)

   c,  Throught its periodic refreshes register keeps RP informed about
       the aliveness of this multicast stream.

   As it is defined in [RFC4601] , 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.

   a,  PIM register needs control-plane and data-plane intervention to
       handle it.

   b,  Due to the nature of PIM register, First-Hop-Router and RP now
       needs to maintain states and timers for each register state
       entry.

   c,  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

2.  Reliable Register Overview

   Reliable PIM register extends PIM PORT [RFC6559] to have PIM register
   states to be sent over a reliable transport.

Peter, et al.          Expires September 10, 2015               [Page 3]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   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.

   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.

   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.

3.  Targeted Hellos

   PIM hellos defined in PIM-SM [RFC4601] confines them to link level.
   This document extends these hellos to support 'targeted' hellos.

   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.

3.1.  New Hello Optional TLV's

   Option Type: Targeted hello

       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 = 36 (suggested)     |           Length = 4          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|R|                        Reserved                   |  Exp  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: PIM Hello Optional TLV

   Assigned Hello Type values can be found in IANA PIM registry.

   Type: This is subject to IANA allocation.  Suggested is 36 which is
   the next unused type.

Peter, et al.          Expires September 10, 2015               [Page 4]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   Length: Length in bytes for the value part of the Type/Length/Value
   encoding fixed as 4.

   F: To be set by a router that wants to be a First-Hop-Router.

   R: To be set by a RP that is capable taking the role of an RP as per
   the current states.

   Reserved: Set to zero on transmission and ignored on receipt.

   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.

3.2.  Differences from Link-Level hellos

   The Major differences that Link-Level-Hellos have over Interface
   hellos are,

   1.  Destination address would be an unicast address unlike ALL-PIM-
       ROUTER destination address for link-level hellos

   2.  TTL value would be the system default TTL

   3.  Targeted Hellos SHOULD carry Targeted Hello Optional TLV (Defined
       in this document.)

   4.  Holdtime SHOULD NOT be set as 0xffff by a targeted hello sender,
       and such hellos should be discarded up on receive.

3.3.  Address in Hello message

   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.

3.4.  Timer Values

   The timers relevant to this specification are in relation to PIM
   hello.  The recommended timer values are

   1:  PIM Targeted Hello default refresh time : 60s (2 * Default Link-
       level hello time)

Peter, et al.          Expires September 10, 2015               [Page 5]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   2:  PIM Targeted Hello default hold time : 210s (3.5 times targeted
       hello default refresh time)

3.5.  Targeted Neighbor

   A Targeted PIM neighbor is a neighbor-ship established by virtue of
   exchanging targeted hello messages.

   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).

   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.

   The RP upon hold-time-out for the neighbor would remove this neighbor
   and its associated states.

   The initiator or responder upon having a need to terminate a targeted
   neighbor MAY send hello with hold-time as 0.

4.  Reliable Connection setup

   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.

4.1.  Active FHR

   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.

4.2.  Connection setup between two RP's

   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.

Peter, et al.          Expires September 10, 2015               [Page 6]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   In this condition the connection setup could used the procedures
   stated in PIM over reliable transport [RFC6559]

4.3.  Hello Generation ID and reconnect

   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. . .

4.4.  Handling Connection or reachability loss

   Connection loss or reachability loss could happen for one or more of
   the following reasons

   1:  PORT Keep-alive time out

   2:  Targeted neighbor loss

   3:  Reliable Connection close

   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.

   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.

   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.

5.  Anycast RP's

   PIM uses Anycast-RP [RFC4610] as a mechanism for RP redundancy.  This
   section describes how anycast-RP would work with this specification.

5.1.  Targeted Hellos and Neighbors

   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.

Peter, et al.          Expires September 10, 2015               [Page 7]
Internet-Draft Reliable Transport For PIM Register States     March 2015

5.2.  Anycast-RP connection setup

   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 PIM PORT [RFC6559] procedures to setup reliable
   connection among them.

5.3.  Anycast-RP state sync

   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 Anycast-rp [RFC4610] register specification.

   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.

   A.  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.

   B.  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.

   C.  FHR primary address change: In this case too connection would get
       re-established and state handling would be similar to case A.

   D.  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.

5.4.  Anycast-RP change

   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.

Peter, et al.          Expires September 10, 2015               [Page 8]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   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.

5.5.  Anycast-RP with MSDP

   MSDP [RFC3618] 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

   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.

   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.

6.  PIM-registers and Interoperation with legacy PIM nodes

   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.

6.1.  Initial packet-loss avoidance with PORT

   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.

6.2.  First-Hop-Router does not support PORT

   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.

6.3.  RP does not support PORT

   If the RP is not capable of doing PORT-register, then it would not
   respond to the targeted hellos from the RP.  Hence reliable

Peter, et al.          Expires September 10, 2015               [Page 9]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   connection also would not be established.  In this case First-Hop-
   Router could sent existing packet registers to RP.

6.4.  Data-Register free operations

   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.

7.  PORT message

   This document defines new PORT register state message and PORT
   register-stop messages, to the existing messages in PORT
   specification.

7.1.  PORT register message TLV

      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 = 3 (suggested)      |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                   | Exp.  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |B|N|A|                      Reserved-1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            src addr-1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            grp addr-1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            2, 3, . . .                        z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |B|N|A|                      Reserved-n                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            src addr-n                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            grp addr-n                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: PORT Register State Message for IPv4

   Type: This is subject to IANA allocation.  Suggested is 3 which is
   the next unused type.

   Length: Length in bytes for the value part of the Type/Length/Value
   In this case it would be 12 * (number of sg's present in the register
   message.) + 4

Peter, et al.          Expires September 10, 2015              [Page 10]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   B: As specified in [RFC4601]  (set as 0 on send and ignore when
   received)

   N: As specified in [RFC4601]  (set as 1 on send and ignore when
   received.)

   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
   .

   src addr-x : This is the 4-byte source address of an ipv4 stream with
   out any encoding.

   grp addr-x : This is the 4-byte group address of an ipv4 stream with
   out any encoding.

   Reserved: Set to zero on transmission and ignored on receipt.  These
   reserved bits are for properties that apply to the entire message.

   Reserved-n: Set to zero on transmission and ignored on receipt.
   These reserved bits are for properties that apply to any particular
   sg.

   Exp: : For experimental use.

Peter, et al.          Expires September 10, 2015              [Page 11]
Internet-Draft Reliable Transport For PIM Register States     March 2015

      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 = 5 (suggested)      |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                   | Exp.  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |B|N|A|                      Reserved-1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            src addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            grp addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            2, 3, . . .                        z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |B|N|A|                      Reserved-n                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            src addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            grp addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: PORT Register State Message for IPv6

   Type: This is subject to IANA allocation.  Suggested is 5 which is
   the next unused type.

   Length: Length in bytes for the value part of the Type/Length/Value
   In this case it would be 36 * (number of sg's present in the register
   message.) + 4

   B: As specified in [RFC4601]  (set as 0 on send and ignore when
   received)

   N: As specified in [RFC4601]  (set as 1 on send and ignore when
   received.)

   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
   .

Peter, et al.          Expires September 10, 2015              [Page 12]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   src addr-x : This is the 16-byte source address of an ipv6 stream
   with out any encoding.

   grp addr-x : This is the 16-byte group address of an ipv6 stream with
   out any encoding.

   Reserved: Set to zero on transmission and ignored on receipt.  These
   reserved bits are for properties that apply to the entire message.

   Reserved-n: Set to zero on transmission and ignored on receipt.
   These reserved bits are for properties that apply to any particular
   SG.

   Exp: : For experimental use.

7.2.  Sending and receiving PORT register messages

   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.

   When KAT timer for a multicast stream expires, it would send an
   update to RP to remove that stream from its list.

   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.

7.3.  PORT register-stop message TLV

Peter, et al.          Expires September 10, 2015              [Page 13]
Internet-Draft Reliable Transport For PIM Register States     March 2015

      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 = 4 (suggested)      |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                   | Exp.  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved-1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            src addr-1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            grp addr-1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                           2, 3, . . .                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved-n                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            src addr-n                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            grp addr-n                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: PORT Register Stop Message for IPv4

   Type: This is subject to IANA allocation.  Suggested is 4 which is
   the next unused type.

   Length: Length in bytes for the value part of the Type/Length/Value
   In this case it would be 12 * (number of sg's present in the register
   message.) + 4

   src addr-x : This is the 4-byte source address of an ipv4 stream with
   out any encoding.

   grp addr-x : This is the 4-byte group address of an ipv4 stream with
   out any encoding.

   Reserved: Set to zero on transmission and ignored on receipt.  These
   reserved bits are for properties that apply to the entire message.

   Reserved-n: Set to zero on transmission and ignored on receipt.
   These reserved bits are for properties that apply to any particular
   sg.

   Exp: : For experimental use.

Peter, et al.          Expires September 10, 2015              [Page 14]
Internet-Draft Reliable Transport For PIM Register States     March 2015

      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 = 6 (suggested)      |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                   | Exp.  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved-1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            src addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            grp addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                           2, 3, . . .                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved-n                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            src addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            grp addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 5: PORT Register Stop Message for IPv6

   Type: This is subject to IANA allocation.  Suggested is 4 which is
   the next unused type.

   Length: Length in bytes for the value part of the Type/Length/Value
   In this case it would be 36 * (number of sg's present in the register
   message.) + 4

   src addr-x : This is the 16-byte source address of an ipv6 stream
   with out any encoding.

   grp addr-x : This is the 16-byte group address of an ipv6 stream with
   out any encoding.

   Reserved: Set to zero on transmission and ignored on receipt.  These
   reserved bits are for properties that apply to the entire message.

Peter, et al.          Expires September 10, 2015              [Page 15]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   Reserved-n: Set to zero on transmission and ignored on receipt.
   These reserved bits are for properties that apply to any particular
   sg.

   Exp: : For experimental use.

7.4.  Sending and receiving PORT register stop messages

   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 PIM-SM [RFC4601]

   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.

7.5.  PORT Keep-Alive Message

   The PORT Keep-alive messages as specified in PIM over Reliable
   Transport [RFC6559] would be used to check the liveliness of the peer
   and the reliable session

8.  Management Considerations

   PORT-register is capable of configuration free operations.  But its
   recommended to have it as configuration controlled.

   Implementation should provide knobs needed to stop supporting data-
   registers on a router.

9.  IANA Considerations

   This specification introduces new TLV in PIM hello and in PIM PORT
   messages.  Hence the tlv ids for these needs IANA allocation

9.1.  PIM Hello Options TLV

   The following Hello TLV types needs IANA allocation.  Suggested
   values for these are provided below.

Peter, et al.          Expires September 10, 2015              [Page 16]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   +---------------+-----------+------------------------+--------------+
   |     Value     | Length    | Name                   | Reference    |
   +---------------+-----------+------------------------+--------------+
   |       36      | 4 (Fixed) | Targeted-Hello-Options | This         |
   |  (suggested)  |           |                        | document     |
   +---------------+-----------+------------------------+--------------+

   Table 1: Suggested values for PIM Hello TLV type for IANA allocation

9.2.  PIM PORT Message Type

   The following PIM PORT message TLV types needs IANA allocation.
   Suggested values for these are provided below.

     +---------------+------------------------------+---------------+
     | Value         | Name                         | Reference     |
     +---------------+------------------------------+---------------+
     | 3 (suggested) | PORT Register-state for Ipv4 | This document |
     | 4 (suggested) | PORT Register-stop for Ipv4  | This document |
     | 5 (suggested) | PORT Register-state for Ipv6 | This document |
     | 6 (suggested) | PORT Register-stop for Ipv6  | This document |
     +---------------+------------------------------+---------------+

    Table 2: Suggested values for PIM PORT TLV type for IANA allocation

10.  Security Considerations

10.1.  PIM Register Threats

   PIM register is considered as security vulnerability for PIM
   networks.  [RFC4609] 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.

10.2.  Targeted Hello Threats

   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 RFC 7349 [RFC7349] could be
   used in PIM.

10.3.  TCP or SCTP security threats

   The security perception for this is stated in [RFC6559].

Peter, et al.          Expires September 10, 2015              [Page 17]
Internet-Draft Reliable Transport For PIM Register States     March 2015

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4609]  Savola, P., Lehtonen, R., and D. Meyer, "Protocol
              Independent Multicast - Sparse Mode (PIM-SM) Multicast
              Routing Security Issues and Enhancements", RFC 4609,
              October 2006.

   [RFC4610]  Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
              Independent Multicast (PIM)", RFC 4610, August 2006.

   [RFC6559]  Farinacci, D., Wijnands, IJ., Venaas, S., and M.
              Napierala, "A Reliable Transport Mechanism for PIM", RFC
              6559, March 2012.

11.2.  Informative References

   [RFC7349]  Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
              Cryptographic Authentication", RFC 7349, August 2014.

Authors' Addresses

   Anish Peter (editor)
   Juniper Networks, Inc.
   Electra, Exora Business Park
   Bangalore, KA  560103
   India

   Email: anishp@juniper.net

Peter, et al.          Expires September 10, 2015              [Page 18]
Internet-Draft Reliable Transport For PIM Register States     March 2015

   Robert Kebler
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: rkebler@juniper.net

   Vikram Nagarajan
   Juniper Networks, Inc.
   Electra, Exora Business Park
   Bangalore, KA  560103
   India

   Email: vikramna@juniper.net

Peter, et al.          Expires September 10, 2015              [Page 19]