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]