Protocol Independent Multicast (pim)                       A. Peter, Ed.
Internet-Draft                                                 R. Kebler
Intended status: Standards Track                            V. Nagarajan
Expires: January 7, 2016                          Juniper Networks, Inc.
                                                            July 6, 2015


                PIM source discovery in Last-Hop-Router
                  draft-anish-pim-stream-discovery-01

Abstract

   This specification introduces a mechanism in PIM-SM [RFC4601] for the
   Last-Hop-Router (LHR) router to discover the stream information.
   Once this mechanism is available the complications of the shared tree
   procedures can be avoided.

   The document introduces a hard-state, reliable transport for the
   information about multicast streams active in the network.

   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 January 7, 2016.




Peter, et al.            Expires January 7, 2016                [Page 1]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  LHR Source Discovery Overview . . . . . . . . . . . . . . . .   3
   3.  Targeted Hellos . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  New Hello Optional TLV's  . . . . . . . . . . . . . . . .   4
   4.  Reliable Connection setup . . . . . . . . . . . . . . . . . .   5
     4.1.  Active LHR  . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Anycast RP's  . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Anycast-RP change . . . . . . . . . . . . . . . . . . . .   5
       5.1.1.  Anycast-RP state mirroring  . . . . . . . . . . . . .   5
   6.  Multicast Stream Liveness . . . . . . . . . . . . . . . . . .   6
   7.  PORT message  . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  PORT stream Receiver-Interest message TLV . . . . . . . .   6
       7.1.1.  Group prefix record . . . . . . . . . . . . . . . . .   8
   8.  Management Considerations . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  PIM PORT Message Type . . . . . . . . . . . . . . . . . .   9
     9.2.  PIM PORT Receiver-Interest message type . . . . . . . . .   9
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   9
     10.1.  Targeted Hello Threats . . . . . . . . . . . . . . . . .   9
     10.2.  TCP or SCTP security threats . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The existing specification for PIM-SM [RFC4601], requires a shared
   tree (*,G) tree to be setup for each multicast group as the LHR does
   not have the information about the sources active for the given
   group.  Once the LHR starts receiving traffic on this shared tree, it



Peter, et al.            Expires January 7, 2016                [Page 2]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 2015


   would discover the source and may switch to source path.  Once source
   path is established the RP shared tree is still maintained for
   discovering new sources.  In addition LHR would now have to maintain
   a prune state with to RP for not getting that particular stream over
   the shared tree and source tree.

   This behavior could be optimized if the LHR could have a means to
   know about the sources active for a multicast group.  Then it could
   directly do an SPT join without having to wait for the ASM shared-
   tree to be established.

2.  LHR Source Discovery Overview

   Reliable PIM register Reliable PIM Registers
   [I-D.anish-reliable-pim-registers]  extends PIM PORT [RFC6559] to
   have PIM register states to be send over a reliable transport.

   Independent of reliable register support as specified in Reliable PIM
   Registers [I-D.anish-reliable-pim-registers] this document introduces
   a reliable communication between LHR and RP, so that LHR would now
   learn all the source informations directly from RP with out the need
   for a shared tree.

   For achieving this on a LHR in a source discovery enabled network,
   targeted neighborhood is established between LHR and RP, with the LHR
   expressing its capability in the targeted hello.  This leads to a
   reliable connection setup as stated in Reliable PIM Registers
   [I-D.anish-reliable-pim-registers] . Subsequent to this LHR would
   send receiver-interest messages to RP stating the groups for which it
   wishes to receive.  This "Receiver-Interest" could be for,

   1:  Single group address, when the prefix-len would be equal to the
       prefix-length of a host address.

   2:  Group address range, when the prefix-len indicated a address mask
       for the groups of interest

   3:  Wild-card, which would indicate all the asm addresses that RP is
       aware of

   RP would respond back to LHR with the list of multicast streams
   active with it that matches this Receiver-Interest in a reliable
   register message.  Unless a 'One-time' flag is set RP would retain
   this Receiver-Interest with it for notifying the LHR about the
   incremental changes happening to the groups falling in this Receiver-
   Interest.





Peter, et al.            Expires January 7, 2016                [Page 3]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 2015


   When the interest in LHR ceases for a Receiver-Interest it had set
   with the RP, it could send the same Receiver-Interest message, but
   with the withdraw bit set.

3.  Targeted Hellos

   Reliable PIM Registers [I-D.anish-reliable-pim-registers] defined
   targeted hellos for PIM.  This specification extends them to apply it
   for the RP-LHR segment.  The only change it introduces is that it
   uses one bit among the reserved bits for the purpose of a router
   identifying itself as a LHR in the targeted hello optional TLV in
   targeted hello message

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 = H1 (for alloc)     |           Length = 4          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |F|R|L|                      Reserved                   |  Exp  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 1: PIM Hello Optional TLV

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

   Type: As defined in Reliable PIM Registers
   [I-D.anish-reliable-pim-registers]

   Length: As defined in Reliable PIM Registers
   [I-D.anish-reliable-pim-registers]

   F: As defined in Reliable PIM Registers
   [I-D.anish-reliable-pim-registers]

   R: As defined in Reliable PIM Registers
   [I-D.anish-reliable-pim-registers]

   L: Identifies the PIM hellos senders capability of being a LHR

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

   Exp: As defined in Reliable PIM Registers
   [I-D.anish-reliable-pim-registers]



Peter, et al.            Expires January 7, 2016                [Page 4]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 2015


4.  Reliable Connection setup

   A reliable connection has to be setup between the LHR and RP for
   reliable messaging to happen.

4.1.  Active LHR

   Once LHR and RP discovery each other with targeted hello
   neighborhood, LHR takes the active role.  LHR 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.

5.  Anycast RP's

   PIM uses Anycast-RP [RFC4610] as a mechanism for RP redundancy.
   Reliable PIM Registers [I-D.anish-reliable-pim-registers]introduced
   procedures to support anycast-RP with reliable connection.  This
   section describes how anycast-RP would work with this specification.

5.1.  Anycast-RP change

   In the event of nearest anycast-RP changing over to a different
   router, LHR would detect that when it starts receiving PIM hellos
   with a different primary address for the same anycast address.  Upon
   detecting this scenario, the LHR may wait for an interval before
   setting up connection with the newly found primary address of the RP.

   Upon detecting this scenario, the LHR would establish connection and
   transmit its states to the new peer.  Subsequently older connection
   would get terminated due to neighbor timeout.

   Once the old connection is terminated, LHR should clear off the
   states for the multicast streams that were advertised in the old
   connection and not by the new connection.  In order to accommodate
   for delays in a new RP discovering and advertising a stream, this
   state cleanup should be done only after a suitable delay.

5.1.1.  Anycast-RP state mirroring

   The Receiver Interest message from the LHR should not be mirrored to
   the other anycast RP peers as its sufficient for it to rest with the
   nearest RP.








Peter, et al.            Expires January 7, 2016                [Page 5]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 2015


6.  Multicast Stream Liveness

   Traditionally with PIM-SM [RFC4601] the LHR had the responsibility of
   checking the stream liveness, so that it could prune of the traffic
   that are not active any more in the SPT.  This is besides that same
   stream getting traced for liveness at the First-Hop-Router (FHR) and
   RP.

   With the extension in this document, this liveness motoring could be
   avoided on LHR.  LHR can now prune of a SPT path based on the
   withdraw of the stream.

   When deployed along with Reliable PIM Registers
   [I-D.anish-reliable-pim-registers]this liveness check could be
   restricted to FHR alone

7.  PORT message

   This document defines new PORT multicast stream Receiver-Interest
   messages and PORT multicast stream reports messages, to the existing
   messages in PORT specification.

   The records in the message could be defined as the use case be.  In
   the context of this draft this use case is only for multicast group
   joins.

7.1.  PORT stream Receiver-Interest message TLV

   This message format defines the receiver interest message.






















Peter, et al.            Expires January 7, 2016                [Page 6]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 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 = P3 (for alloc)     |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |W|O|                        Reserved                   | Exp.  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|         Reserved-1          |            Aux-len            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             Record-1                          z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                        Auxiliary-data-1                       z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                           2, 3, . . .                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|         Reserved-n          |            Aux-len            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             Record-n                          z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                        Auxiliary-data-n                       z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: PORT Stream Receiver-Interest Message for

   Type: This is subject to IANA allocation.  It would be next
   unallocated value, which is referred until allocation as P3.

   Length: Length in bytes for the value part of the Type/Length/Value

   W: This flag when set signifies if the record is to be Added or
   Withdrawn.  When set, it indicates that the record is withdrawn by
   the LHR.

   O: This flag when set identifies the Receiver-Interest as a One-time.

   A: This bit indicate the presence of an auxiliary data applicable to
   the record immediately following it.

   When A bit is cleared, reserved bits for the next record follows
   record.  Else it would be auxiliary data TLV.

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

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

   Exp: : For experimental use.



Peter, et al.            Expires January 7, 2016                [Page 7]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 2015


7.1.1.  Group prefix record

   This record type as stated before could be used for

   1:  Single group, when prefix len is 32

   2:  Group prefix, when 4 < prefix len > 32

   3:  Any group (Wildcard), when prefix len is 4

       Record type 0x1
      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 = 1 (suggested)      |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            grp addr                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 3: Record for Receiver-Interest

   Type: This is a new IANA registry, suggested value 1

   Length: Length in bytes for the value part of the Type/Length/Value
   In this case it would be 12bytes.

   grp addr: Group address for which there is Receiver-Interest.  This
   this group address should be of "Encoded-Group-Address Format as
   specified in [RFC4601]

8.  Management Considerations

   LHR multicast stream discovery is capable of configuration free
   operations.  But its recommended to have it as configuration
   controlled.

   Implementation should provide knobs needed to stop supporting *g
   join/prune states created by a neighboring router.

9.  IANA Considerations

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

   It also introduces a registry for PORT Receiver-Interest record type.





Peter, et al.            Expires January 7, 2016                [Page 8]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 2015


9.1.  PIM PORT Message Type

   The following PIM PORT message TLV types need IANA allocation.  Place
   holder are kept to differentiate the different types.

     +---------------------+------------------------+---------------+
     | Value               | Name                   | Reference     |
     +---------------------+------------------------+---------------+
     | P3 (Next available) | PORT Receiver-Interest | This document |
     +---------------------+------------------------+---------------+

        Table 1: Place holder values for PIM PORT TLV type for IANA
                                allocation

9.2.  PIM PORT Receiver-Interest message type

   +-------------------------+-------------------------+---------------+
   | Value                   | Name                    | Reference     |
   +-------------------------+-------------------------+---------------+
   | 1 (suggested)           | Group Receiver-Interest | This document |
   | 0, 2 - 65000            | Unassigned - Reserved   | This document |
   | (suggested)             |                         |               |
   | 65001 - 65535           | For experimental use    | This document |
   | (suggested)             |                         |               |
   +-------------------------+-------------------------+---------------+

    Table 2: Suggested values for PIM PORT Message types for Receiver-
                     Interest TLV for IANA allocation

10.  Security Considerations

10.1.  Targeted Hello Threats

   The state reduction introduced by this specification has
   possibilities for improving the vulnerabilities in a multicast
   network.

   Reliable PIM Registers [I-D.anish-reliable-pim-registers] 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.








Peter, et al.            Expires January 7, 2016                [Page 9]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 2015


10.2.  TCP or SCTP security threats

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

11.  References

11.1.  Normative References

   [I-D.anish-reliable-pim-registers]
              Peter, A., Kebler, R., and V. Nagarajan, "Reliable
              Transport For PIM Register States", draft-anish-reliable-
              pim-registers-00 (work in progress), March 2015.

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

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 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 January 7, 2016               [Page 10]


Internet-Draft   PIM source discovery in Last-Hop-Router       July 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 January 7, 2016               [Page 11]