Internet DRAFT - draft-zhang-bier-flooding
draft-zhang-bier-flooding
BIER WG Zheng. Zhang
Internet-Draft BenChong. Xu
Intended status: Standards Track ZTE Corporation
Expires: April 3, 2018 September 30, 2017
BIER Flooding Mechanism
draft-zhang-bier-flooding-00.txt
Abstract
This document introduces a method to flood BIER information in hybrid
network to build BIER forwarding plane.
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 https://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 April 3, 2018.
Copyright Notice
Copyright (c) 2017 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
(https://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.
Zhang & Xu Expires April 3, 2018 [Page 1]
Internet-Draft BIER Flooding September 2017
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Scheduled Update . . . . . . . . . . . . . . . . . . . . 4
2.2. Triggered Update . . . . . . . . . . . . . . . . . . . . 4
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. PFM message . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. BIER information TLV . . . . . . . . . . . . . . . . . . 5
3.3. BIER MPLS Encapsulation sub-TLV . . . . . . . . . . . . . 6
3.4. Optional BIER sub-domain BSL conversion sub-TLV . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Problem Statement
Some networks have been deployed widely are hybrid networks. There
are different dynamic routing protocols running in the hybrid
networks. Multicast services can also be provided in these kinds of
networks because of the protocol independent feature of PIM.
BIER [I-D.ietf-bier-architecture] provides a new architecture for the
forwarding of multicast data packets. It does not require a protocol
for explicitly building multicast distribution trees, nor does it
require intermediate nodes to maintain any per-flow state.
[I-D.ietf-bier-isis-extensions] and
[I-D.ietf-bier-ospf-bier-extensions] are good at establishing BIER
forwarding plane in network which uses OSPF or IS-IS as BIER underlay
protocol.
Zhang & Xu Expires April 3, 2018 [Page 2]
Internet-Draft BIER Flooding September 2017
| |
.........|................|.........
. ISIS | | .
. | | .
. MR1--------------MR2 .
. | . . | .
. | . . | .
. | . . | .
. | .. | .
. | . . | .
. | . . | .
. | . . | .
. MR3 MR4 .
. / \ / \ .
....................................
/ \ / \
/ \ / \
/ \ / \
................... ................
. B1--------B2 . .B3--------B4 .
. . . .
. Rm . . Rx .
. ... . . ... .
. Rn . . Ry .
. . . .
. OSPF . . OSPF .
................... ................
Figure 1: An typical hybrid network
In the mentioned networks, there are more than one dynamic routing
protocols running in the networks. For example in figure 1, this is
a partial typical network in actually deployment. Two different
dynamic routing protocols and are used in the network. Sometimes
static configured routes also are used in some parts of the network.
In order to deploy BIER multicast, we can divide the network into
several BIER domains. Obviously the efficiency slows down due to
multiple encapsulating/ decapsulating executions.
2. Solution
The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used
mechanism for distributing dynamic Group to RP mappings in PIM. It
is responsible for flooding information about such mappings
throughout a PIM domain, so that all routers in the domain can have
the same information. [I-D.ietf-pim-source-discovery-bsr] defines a
mechanism that can flood any kind of information throughout a PIM
domain. This document borrows the idea from the two drafts,
introduces a mechanism to flood BIER node's information throughout a
Zhang & Xu Expires April 3, 2018 [Page 3]
Internet-Draft BIER Flooding September 2017
BIER domain to build BIER forwarding plane. Nodes can use unicast
forwarding table directly to establish BIER forwarding plane.
The validation processing of PFM messages is the same as the
definition in [I-D.ietf-pim-source-discovery-bsr] section 3.2.
BIER node originates BIER information TLV and optional associated
sub-TLVs in PFM message. The PFM messages are flooded by throughout
the BIER domain. BFR gets routing information from the unicast
forwarding table directly, and computes BIER forwarding table. Then
BIER forwarding plane is established.
2.1. Scheduled Update
Because PIM advertisement is scheduled, the node's BIER information
is refreshed periodically. In case one node's BIER information
changes or expires, the other nodes recompute the BIER forwarding
table. The holdtime in the BIER information TLV is used to make the
item expired.
2.2. Triggered Update
If the BIER node's configuration changes, such as BFR-id, the node
should send update PFM messages immediately. Then other nodes can
recompute the new BIER forwarding table.
3. Message Format
3.1. PFM message
New TLVs are defined in PFM message to flood node's BIER information,
such as BFR-id, BFR-prefix and so on. The new TLVs align exactly
with the definition and restrictions in
[I-D.ietf-bier-isis-extensions] and
[I-D.ietf-bier-ospf-bier-extensions].
Zhang & Xu Expires April 3, 2018 [Page 4]
Internet-Draft BIER Flooding September 2017
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 1 | Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| Type n | Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value n |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PFM message format
The format of PFM message is defined in
[I-D.ietf-pim-source-discovery-bsr].
Originator Address: The router's address that originate the message.
The address SHOULD be the same with the node's BFR-prefix.
The other fields is the same as definition in
[I-D.ietf-pim-source-discovery-bsr].
3.2. BIER information TLV
A new type of TLV is defined in PFM message. This new type TLV is
named by BIER information TLV. Two types of sub-TLV are associated
with it. There is no optional BIER tree type sub-TLV in PFM message
because of the independence of routing protocol.
Zhang & Xu Expires April 3, 2018 [Page 5]
Internet-Draft BIER Flooding September 2017
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | subdomain-id | BFR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-prefix (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: BIER information TLV
o Type: The value of type should be assigned by IANA.
o Length: The total length of the BIER information TLV except for
the first two fields.
o Reserved: Must be 0 on transmission, ignored on reception. May be
used in future version. 1 octets.
o Subdomain-id: Unique value identifying the BIER sub-domain. 1
octet.
o BFR-id: The value of BFR-id defined in [BIER-arch], 2 octets. 0 is
invalid value. If the value of this field is set to 0, the whole
TLV MUST be ignored and not forwarded.
o Holdtime: The life cycle of the BIER information. The default
value is 60s.
o BFR-prefix: The BFR-prefix of the node in this sub-domain. The
format for this address is given in the Encoded-Unicast address in
[RFC7761].
A node may belong to several BIER sub-domains, so it is possible that
there are multiple BIER information TLVs in the PFM message.
3.3. BIER MPLS Encapsulation sub-TLV
In case the nodes in the network support MPLS forwarding, BIER MPLS
encapsulation sub-TLV can be advertised for a specific bitstring
length for a certain (MT,subdomain). This sub-TLV may appear
multiple times within single BIER information TLV. The format and
restriction is the same as the definition in
[I-D.ietf-bier-isis-extensions] and
[I-D.ietf-bier-ospf-bier-extensions].
Zhang & Xu Expires April 3, 2018 [Page 6]
Internet-Draft BIER Flooding September 2017
The type value of this sub-TLV should be assigned by IANA. The
suggestion value is 1.
3.4. Optional BIER sub-domain BSL conversion sub-TLV
The format and restriction is the same as the definition in
[I-D.ietf-bier-isis-extensions] and
[I-D.ietf-bier-ospf-bier-extensions]. The type value of this sub-TLV
should be assigned by IANA. The suggestion value is 2.
4. Security Considerations
The security considerations are mainly similar to what is documented
in [I-D.ietf-pim-source-discovery-bsr].
5. IANA Considerations
This document requires the assignment of a new PFM TLV type for the
BIER information Flooding Mechanism. IANA is also requested to
create two sub-TLV types for BIER MPLS encapsulation sub-TLV and BIER
sub-domain BSL conversion sub-TLV.
6. Normative References
[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-08 (work in
progress), September 2017.
[I-D.ietf-bier-isis-extensions]
Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang,
"BIER support via ISIS", draft-ietf-bier-isis-
extensions-05 (work in progress), July 2017.
[I-D.ietf-bier-ospf-bier-extensions]
Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions
for BIER", draft-ietf-bier-ospf-bier-extensions-07 (work
in progress), July 2017.
[I-D.ietf-pim-source-discovery-bsr]
Wijnands, I., Venaas, S., Brig, M., and A. Jonasson, "PIM
flooding mechanism and source discovery", draft-ietf-pim-
source-discovery-bsr-06 (work in progress), March 2017.
Zhang & Xu Expires April 3, 2018 [Page 7]
Internet-Draft BIER Flooding September 2017
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January
2008, <https://www.rfc-editor.org/info/rfc5059>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
Authors' Addresses
Zheng(Sandy) Zhang
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing
China
Email: zhang.zheng@zte.com.cn
BenChong Xu
ZTE Corporation
No. 68 Zijinghua Road, Yuhuatai Distinct
Nanjing
China
Email: xu.benchong@zte.com.cn
Zhang & Xu Expires April 3, 2018 [Page 8]
