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]