Internet DRAFT - draft-anish-bier-overlay-pim

draft-anish-bier-overlay-pim







bier                                                       A. Peter, Ed.
Internet-Draft                                                 R. Kebler
Intended status: Standards Track                            V. Nagarajan
Expires: January 7, 2016                          Juniper Networks, Inc.
                                                            July 6, 2015


                Overlay for discovery in a BIER network
                    draft-anish-bier-overlay-pim-00

Abstract

   This document introduces an overlay model for signaling egress
   interest to the ingress BIER router.

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.

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



Peter, et al.            Expires January 7, 2016                [Page 1]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


   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.  BIER Overlay Overview . . . . . . . . . . . . . . . . . . . .   3
   3.  Targeted Hellos . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Optional Targeted Hello TLV's . . . . . . . . . . . . . .   4
     3.2.  Optional BIER Hello TLV's . . . . . . . . . . . . . . . .   5
   4.  Reliable Connection setup . . . . . . . . . . . . . . . . . .   6
     4.1.  Active BIER edge router . . . . . . . . . . . . . . . . .   6
   5.  Anycast RP's  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Anycast-RP change . . . . . . . . . . . . . . . . . . . .   6
       5.1.1.  Service Request Message . . . . . . . . . . . . . . .   6
       5.1.2.  Capabilites Message . . . . . . . . . . . . . . . . .   7
   6.  BIER Overlay messages . . . . . . . . . . . . . . . . . . . .   7
     6.1.  PORT Capability message . . . . . . . . . . . . . . . . .   7
       6.1.1.  Capability record for Source, Group . . . . . . . . .   8
       6.1.2.  Capability record for Source  . . . . . . . . . . . .   9
     6.2.  Sending and receiving Capability messages . . . . . . . .  10
   7.  PORT Service Request message  . . . . . . . . . . . . . . . .  10
     7.1.  Service request record for Source, Group  . . . . . . . .  12
     7.2.  Service request record for Group prefix . . . . . . . . .  12
     7.3.  Sending and receiving Service request messages  . . . . .  13
     7.4.  Service request messages between RP and First-Hop-Router   13
     7.5.  PORT Keep-Alive Message . . . . . . . . . . . . . . . . .  13
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  PIM Hello Options TLV . . . . . . . . . . . . . . . . . .  14
     9.2.  PIM PORT Message Type . . . . . . . . . . . . . . . . . .  14
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  14
     10.1.  TCP or SCTP security threats . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   BIER [I-D.ietf-bier-architecture] proposes a new forwarding plane for
   multicast packet delivery in a network.  The major advantage with
   BIER that it does not need per flow forwarding entry in the network.
   BIER accomplishes this by addressing each of the targeted egress
   router in a bit mask based addressing schema.




Peter, et al.            Expires January 7, 2016                [Page 2]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


   Each BIER Forwarding Router (BFR) is assigned and uniquely identified
   by a BFR-prefix which is a routable ipv4 or ipv6 address.  Each BIER
   egress (BFER) router needs a BFR-Identifier (1..65535) in addition to
   BFR-prefix.

   To accomplish forwarding in a BIER network, ingress router needs to
   know the list of egress routers to which the flow is supposed be
   multicasted.  For this learning, an overlay signaling is needed.  In
   some of the intended use cases of BIER such as BGP-MVPN, BGP is used
   for signaling, which could be used to provide the needed overlay
   service.  In other use-cases, BGP may not be used.  This opens the
   need for having an adequate overlay for BIER.

   PIM Over Reliable Transport (PORT) with its extensions in Reliable
   PIM Registers [I-D.anish-reliable-pim-registers] and LHR source
   discovery [I-D.anish-pim-stream-discovery] provides a mechanism for
   edge routers to share their interests and capabilities to a
   Rendezvous Point (RP).  RP could now facilitate service discovery
   based on this.  (PORT RP could be a router/controller/server as it
   need not handle the data-traffic)

   For BIER overlay this PORT-RP based model could talk to edge routers
   and then consolidate and filter this database and send to ingress,
   peer specific interest.

   This version of the documents states the case of First-Hop-Router
   also being the BFIR and Last-Hop-Router also being the BFER.

   BIER architecture includes a routing underlay achieved by extensions
   to OSPF [I-D.ietf-bier-ospf-bier-extensions] and ISIS
   [I-D.ietf-bier-isis-extensions].  This document assumes that this
   routing underlay exists and is defined outside of this document

2.  BIER Overlay Overview

   Reliable PIM register and PIM source discovery extends PORT [RFC6559]
   to discover and signal each other by advertising their capabilities
   and needs.  For achieving BIER overlay the basic requirement is for
   egress to advertise their needs and for ingress routers to advertise
   their capabilities so that a RP could keep the ingress informed about
   the set of egress routers interested in its capabilities.

   To achieve BIER-PORT overlay first, a transport connection is
   established between an edge router (ingress or egress) and a RP.
   When a receiver interest is known, egress route would pass that on to
   the RP.  Similarly when ingress router knows about its traffic
   sourcing capability it would inform the RP about it.  This way we




Peter, et al.            Expires January 7, 2016                [Page 3]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


   have the RP that knows about the sourcing capabilities and the
   receiver interest in the network.

   Based on these two databases RP would now inform ingress routers the
   set of egress routers that would subscribe to its capabilities.

3.  Targeted Hellos

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

3.1.  Optional Targeted Hello 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|B|                    Reserved                   |  Exp  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 1: PIM Optional Targeted Hello 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: As defined in Reliable PIM Registers
   [I-D.anish-pim-stream-discovery]





Peter, et al.            Expires January 7, 2016                [Page 4]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


   B: Identifies the PIM hellos senders capability of being a BIER edge
   router

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

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

3.2.  Optional BIER Hello TLV's

   Option Type: BIER capability 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 = H2 (for alloc)     |           Length = 6          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |E|                          Reserved                   |  Exp  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          BIER-Prefix                          z
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 2: PIM Optional BIER header TLV

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

   Type: This is subject to IANA allocation.  Its stated as H2 for ease
   of reference and as a continuation from H1 as defined in Reliable PIM
   Registers [I-D.anish-reliable-pim-registers].

   Length: Length in bytes for the value part of the Type/Length/Value
   encoding its length would vary based on the prefix being ipv4 or
   ipv6.

   E: To be set by a router that has a BIER id so that it could be
   identified as a egress router in a BIER domain.

   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.





Peter, et al.            Expires January 7, 2016                [Page 5]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


   BIER-Prefix: BIER-Prefix of the sender router in the encoded unicast
   ipv4 or ipv6 address family format as define in [RFC4601].

4.  Reliable Connection setup

   A reliable connection has to be setup between the BIER edge router
   and RP for message exchanges to happen.

4.1.  Active BIER edge router

   Once BIER edge and RP discovery each other with targeted hello
   neighborhood, BIER edge takes the active role.  BIER edge 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, BIER edge router would detect that when it starts receiving
   PIM hellos with a different primary address for the same anycast
   address.  Upon detecting this scenario, the edge router may wait for
   an interval before setting up connection with the newly found primary
   address of the RP.  Subsequently older connection would get
   terminated due to neighbor timeout.  Once the old connection is
   terminated, router should clear off the states that were advertised
   in the old connection and not by the new connection.

   The edge router should transmit its service requests and capabilites
   to this new found RP.  RP should transmit the service request
   messages to BFIR routers having capability.

   In order to accommodate for delays in a new RP discovering and
   messaging, state cleanup should be done only after a suitable delay.

5.1.1.  Service Request Message

   Service Request of BIER should be mirrored among the BIER RP's.  The
   BIER message format allows list of BFER's to be appended to SR
   message.  This message format could be used to reduce messaging.




Peter, et al.            Expires January 7, 2016                [Page 6]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


5.1.2.  Capabilites Message

   The capabilites message send by the ingress is NOT mirrored and would
   be retained only by the first RP.

6.  BIER Overlay messages

   BIER overlay is achieved with the help of 2 new messages in [RFC6559]
   PORT.

   1,  Capability message: Send by a BIER ingress stating its capability
       (in sourcing traffic)

   2,  Service Request message: Send by a BIER egress router stating the
       services that it needs.

6.1.  PORT Capability message

      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 = P4 (for alloc)     |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                   | Exp.  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |W|          Reserved-1         |RecType|     Record Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     z                            Record-1                           z
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Z                             . . .                             z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |W|          Reserved-n         |RecType|     Record Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     z                            Record-n                           z
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 3: PORT Capability advertisement Message

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

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




Peter, et al.            Expires January 7, 2016                [Page 7]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


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

   Exp: : For experimental use.

   W: This flag signifies if the Record is getting Withdrawn or added.
   When cleared, it indicates that the SG is getting added by the
   Ingress.

   RecType: This 4 bit value signifies the record type as define in
   section below.

   The record types define are

   1  0x0 Reserved

   2  0x1 SG capability

   3  0x2 S/S-prefix capability (For ssm)

   4  0x3 -> 0xd UNASSIGNED

   5  0xe -> 0xf For experimental use.

   Record Length: This 12 bit value is the length of record in bytes

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

6.1.1.  Capability record for Source, Group

   (src, grp)/sg record type is used by the first hop router to inform
   the src, grp address pair of a traffic it could source.  This is
   analogous to a pim-sm register.

















Peter, et al.            Expires January 7, 2016                [Page 8]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


       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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            src addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            grp addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            src addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            grp addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 4: PORT Capability for sg record

   src addr-x : This is the source address of a stream in the "Encoded-
   Source-Address" Format as specified in [RFC4601].

   grp addr-x : This is the group address of a stream in the "Encoded-
   Group-Address" Format as specified in [RFC4601].

6.1.2.  Capability record for Source

   Source prefix record type is used by the first hop router to inform
   one source address or source address subnet from which, could source
   traffic.  This capability record will be mainly of use for migrating
   a pim ssm network to BIER.

       Record type 0x2
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            src addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            src addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 5: PORT Capability for src record

   src addr-x : This is the source address of a stream in the "Encoded-
   Source-Address" Format as specified in [RFC4601].




Peter, et al.            Expires January 7, 2016                [Page 9]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


6.2.  Sending and receiving Capability messages

   A BIER router capable of being an ingress would send capability
   message.  Based on use-case new capabilities could be added besides
   the ones stated in previous section.

7.  PORT Service Request message

      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 = P5  (for alloc)     |        Message Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                   | Exp.  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |W|               Reserved-1    |RecType|     Record Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          m-bier-recv          |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     z                            Record-1                           z
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       BIER-prefix-1,1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                       BIER_prefix-1,m                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |W|               Reserved-1    |    RecType    | Record Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          n-bier-recv          |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     z                            Record-n                           z
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       BIER-prefix-1,1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                       BIER_prefix-1,m                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                  Figure 6: PORT Service Request Message




Peter, et al.            Expires January 7, 2016               [Page 10]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


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

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

   W: This flag signifies if the Record is getting Withdrawn or added.
   When cleared, it indicates that the SG is getting added by the
   Ingress.

   RecType: This 8 bit value signifies the record type as define in
   section below.

   The record types define are

   1  0x0 Reserved

   2  0x1 S,G Join

   3  0x2 *,G Join

   4  0x3 -> 0xe UNASSIGNED

   5  0xf Resv

   Record Length: Length of record in bytes

   n-bier-recv: The number of bier receivers bier id that follows the
   record.  For simple service request message send from a BIER egress,
   this could be 0 as the BIER id of the egress is known to RP via the
   targeted hellos.  This list of BIER id's plays a role when RP mirrors
   these message to an another RP or when BIER egress is proxying for an
   another edge router on when the message is send to Ingress router as
   with list of egress BIER routers for the service.

   BIER-prefix-x,y: This is the BIER-prefix of egress router in the
   encoded unicast ipv4 or ipv6 address family format as define in
   [RFC4601].

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

   Exp: : For experimental use.






Peter, et al.            Expires January 7, 2016               [Page 11]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


7.1.  Service request record for Source, Group

   (src, grp)/sg record type is used by the Egress router to inform the
   src, grp address pair of a traffic it wants.  This is analogous to a
   pim-sg join.

       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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            grp addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            src addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            grp addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            src addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 7: PORT Service Request for a sg record

   src addr-x : This is the encoded source address of a stream as
   specified in [RFC4601]

   grp addr-x : This is the encoded group address of a stream as
   specified in [RFC4601]

7.2.  Service request record for Group prefix

   group prefix record type is used by the Egress router to inform the
   multicast groups that are of interest to it.  This is analogous to a
   pim-*g join.
















Peter, et al.            Expires January 7, 2016               [Page 12]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


       Record type 0x3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            grp addr-1                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                             . . .                             z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     z                            grp addr-n                         z
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 8: PORT Service Request for *g record

   grp addr-x : This is the encoded group address of a stream as
   specified in [RFC4601]

7.3.  Sending and receiving Service request messages

   A BIER router capable of being an Egress would send service request
   messages.  This service request does not require the egress routers
   BIER-prefix as that may be already known from the hello options.  If
   for some reason the BIER-prefix tlv is not seen on the hello message,
   then the router MAY retain the service requests send but would send
   it to ingress only when the BIER-prefix is learned.

   Based on use-cases new capabilities could be added besides the ones
   stated in previous section.

7.4.  Service request messages between RP and First-Hop-Router

   The same Service request message used by LHR to notify RP, could be
   used for notifying First-Hop-Router with the consolidated list of
   egress BIER routers.

   On the First-Hop-Router, the BIER-prefix list for a service is
   updated incrementally.  Hence when two SR message for the identical
   record is received, RP should add/subtract the new list to the its
   list of egress

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






Peter, et al.            Expires January 7, 2016               [Page 13]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


8.  Acknowledgements

   The authors wish to thank Eric Rosen for his thoughts and
   contributions in this work.

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 need IANA allocation.  Place holder are
   kept to differentiate the different types.

   +---------------------+----------+--------------------+-------------+
   |        Value        | Length   | Name               | Reference   |
   +---------------------+----------+--------------------+-------------+
   |  H2 (next available | Variable | BIER-Hello-Options | This        |
   |         one)        |          |                    | document    |
   +---------------------+----------+--------------------+-------------+

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

9.2.  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     |
   +---------------------+-----------------------------+---------------+
   | P4 (Next available) | BIER Capability Message     | This document |
   | P5 (Next available) | BIER Service Request        | This document |
   |                     | Message                     |               |
   +---------------------+-----------------------------+---------------+

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

10.  Security Considerations

   TBW







Peter, et al.            Expires January 7, 2016               [Page 14]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


10.1.  TCP or SCTP security threats

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

11.  References

11.1.  Normative References

   [I-D.anish-pim-stream-discovery]
              Peter, A., Kebler, R., and V. Nagarajan, "PIM source
              discovery in Last-Hop-Router", draft-anish-pim-stream-
              discovery-00 (work in progress), March 2015.

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

   [I-D.ietf-bier-architecture]
              Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
              S. Aldrin, "Multicast using Bit Index Explicit
              Replication", draft-ietf-bier-architecture-01 (work in
              progress), June 2015.

   [I-D.ietf-bier-isis-extensions]
              Ginsberg, L., Aldrin, S., Zhang, J., and T. Przygienda,
              "BIER support via ISIS", draft-ietf-bier-isis-
              extensions-00 (work in progress), April 2015.

   [I-D.ietf-bier-ospf-bier-extensions]
              Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
              Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions
              For BIER", draft-ietf-bier-ospf-bier-extensions-00 (work
              in progress), April 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.







Peter, et al.            Expires January 7, 2016               [Page 15]

Internet-Draft   Overlay for discovery in a BIER network       July 2015


11.2.  Informative References

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

Authors' Addresses

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

   Email: anishp@juniper.net


   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 16]