Internet DRAFT - draft-zhang-pim-babel-ext
draft-zhang-pim-babel-ext
PIM WG Zheng. Zhang
Internet-Draft ZTE Corporation
Intended status: Standards Track March 27, 2017
Expires: September 28, 2017
Multicast BABEL Extension
draft-zhang-pim-babel-ext-02
Abstract
This document describes a method that uses Babel protocol extension
to deliver multicast information. Babel protocol extension is used
to signal receiver multicast interest.
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 September 28, 2017.
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zhang Expires September 28, 2017 [Page 1]
Internet-Draft Multicast BABEL Extension March 2017
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Babel extensions for multicast information . . . . . . . . . 3
4. Protocol treatment . . . . . . . . . . . . . . . . . . . . . 4
4.1. LHR treatment . . . . . . . . . . . . . . . . . . . . . . 4
4.2. FHR treatment . . . . . . . . . . . . . . . . . . . . . . 4
4.2.1. Confliction treatment . . . . . . . . . . . . . . . . 4
4.3. Process . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Consideration . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Terminology
FHR: First Hop Router, directly connected to the source.
LHR: Last Hop Router, directly connected to the receiver.
2. Introduction
As described in [I-D.ietf-babel-applicability], Babel is a loop-
avoiding distance-vector routing protocol that aims to be robust in a
variety of environments. And it has seen a number of successful
deployments in hybrid network; large scale overlay networks and small
unchanged networks.
BIER introduces a novel architecture for multicast packet forwarding.
It does not require a signaling protocol to explicitly build
multicast distribution trees, nor does it require intermediate nodes
to maintain any per-flow state.
When BIER is deployed in a network, a protocol such as MLD is used to
deliver the multicast overlay information. The multicast information
includes multicast source address and group address, and other
information that may be used to indicate the multicast flow. It is
the commonly used method in large network that is well-managed. But
when BIER is used in middle or small network that is not well-
managed, such as some data centers and home network, the overlay
protocol will cause the complication of network management.
Suppose that there is a middle size network that uses Babel protocol
to connect every router, and there are dozens of routers in it. The
users in the network have the IPTV and other live broadcast
requirement. It is obviously that it will be more efficient that use
Zhang Expires September 28, 2017 [Page 2]
Internet-Draft Multicast BABEL Extension March 2017
multicast technology in the network. BIER is a good choice to deploy
multicast technology in the network.
[I-D.zhang-bier-babel-extensions] defines the method to establish the
BIER forwarding plane.
In case MLD protocol is used to deliver the program multicast
information such as group address and source address, the uses device
must support Babel protocol and MLD protocol at the same time.
It is very suitable that use MLD protocol in large and well-managed
network. But in middle or small network, the management of MLD
protocol may cause the network to be more complicated.
In order to simplify the management in the middle or small network,
it may be better that use one protocol to solve the delivery of BIER
node information and multicast information. This document describes
a method to use Babel protocol extension to convey the multicast
information.
3. Babel extensions for multicast information
In order to flood the multicast information, the Babel prefix that is
associated with multicast information extensions MUST not be
aggregated, and the Babel prefix and its multicast information sub-
TLV MUST be delivered transitive.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-type | Flag | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-sub-type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Multicast information extension format
o Sub-type: The sub-type of Babel multicast information sub-TLV.
The value is TBD.
o Flag: Indicates that the sub-TLV is from a FHR. The value is TBD.
o Length: The total length of the sub-TLV.
Zhang Expires September 28, 2017 [Page 3]
Internet-Draft Multicast BABEL Extension March 2017
o Sub-sub-type: The sub-sub-TLV Indicates the IPv4/IPv6 multicast
information. The value is TBD.
o Length: The length of group and source address.
o Group address: The group address. When the type is IPv4, the
group address is 4 octets. When the type is IPv6, the group
address is 16 octets.
o Source address: The source address. When the type is IPv4, the
source address is 4 octets. When the type is IPv6, the source
address is 16 octets. Because more than one source address may be
associated with one group address, more than one source address
may appear. And receiver may be interested in receiving all
sources for a group, like IGMPv2/ASM. Hence 0 sources are
allowed.
4. Protocol treatment
4.1. LHR treatment
When a router announces its own prefix such as a loopback interface
address, no matter the prefix is IPv4 or IPv6, in case the router is
also a LHR, the router should announce the multicast information sub-
TLV to the other routers. And the other routers MUST convey the sub-
TLV to more routers in the network. And at last all the routers will
receive the multicast information and know that where the LHRs are.
4.2. FHR treatment
In case a router is a FHR, when the router announces its own prefix
such as a loopback interface address, no matter the prefix is IPv4 or
IPv6, the router send update message with multicast information sub-
TLV. Other routers MUST convey the sub-TLV associate with the prefix
to more routers in the network, and then every router knows that
where the FHR is.
4.2.1. Confliction treatment
In case one or more FHRs announce some same multicast information,
the function defined in [I-D.wijnands-bier-mld-lan-election] should
be used to judge the unique designed FHR to forward the flow.
4.3. Process
When the router who is FHR receives the multicast information that is
sent by the LHRs, the designed FHR will encapsulate all the LHRs in
the header of multicast flows. Then the routers in the network will
Zhang Expires September 28, 2017 [Page 4]
Internet-Draft Multicast BABEL Extension March 2017
use the BIER forwarding plane to forward the multicast flows to all
the LHRs according to the packet header. And the IPv4 or IPv6
multicast flows will be unified to use the same transport
encapsulation.
LHR1 LHR2 LHR3
\ / \ /
\ / \ /
R11 R12
| |
| |
R21 R22
/ \
/ \
FHR31 FHR32
Figure 2: Example
For example, there are some users who want to receive multicast
flows, such as LHR1, LHR2 and LHR3. In case the users support the
transport encapsulation function, the LHR may be the users self. In
case the users can not support the transport encapsulation function,
the LHR may be the closest router that is connects the users.
Suppose that LHR1 want to receive a multicast flow (*, G1), LHR2 and
LHR3 want to receive a multicast flow (S1, G2), LHR3 also want to
receive a multicast (S3, G1). LHRs will send the update messages
with multicast information sub-TLV to other routers.
Suppose that FHR31 is in charge of (*, G2), and FHR31 and FHR32 all
in charge of (*, G1), FHRs will send Babel extensions associate with
the multicast information sub-TLV with the Sender flag set. And
FHR31 and FHR32 will judge that who is in charge of (*, G1). Suppose
that the FHR32 is the designed FHR for the (*, G1).
Then FHR31 is in charge of (*, G2), FHR32 is in charge of (*, G1), so
FHR31 will encapsulate the multicast flow (*, G2) with the header
that includes LHR2 and LHR3, FHR32 will encapsulate the multicast
flow (*, G1) with the header that includes LHR1 and LHR3. Then the
multicast flows will be forwarded into the network and reach the
LHRs. LHR decapsulate the packet and send it to users/receivers.
5. Security Consideration
The security function that is defined in [I-D.ietf-babel-rfc6126bis]
and [RFC7298] is used directly.
Zhang Expires September 28, 2017 [Page 5]
Internet-Draft Multicast BABEL Extension March 2017
6. IANA Considerations
A new Babel multicast information sub-TLV type need to be defined.
Two sub-sub-TLV IPv4/IPv6 types need to be defined for the multicast
information sub-TLV.
7. Acknowledgements
The authors would like to thank Juliusz Chroboczek, Stig Venaas,
Pierre Pfister for their valuable contributions.
8. Normative References
[I-D.ietf-babel-applicability]
Chroboczek, J., "Applicability of the Babel routing
protocol", draft-ietf-babel-applicability-00 (work in
progress), July 2016.
[I-D.ietf-babel-rfc6126bis]
Chroboczek, J., "The Babel Routing Protocol", draft-ietf-
babel-rfc6126bis-00 (work in progress), August 2016.
[I-D.wijnands-bier-mld-lan-election]
Wijnands, I., Pfister, P., and Z. Zhang, "Generic
Multicast Router Election on LAN's", draft-wijnands-bier-
mld-lan-election-01 (work in progress), July 2016.
[I-D.zhang-bier-babel-extensions]
Zhang, Z. and T. Przygienda, "BIER in BABEL", draft-zhang-
bier-babel-extensions-00 (work in progress), October 2016.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
DOI 10.17487/RFC6126, April 2011,
<http://www.rfc-editor.org/info/rfc6126>.
[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
(HMAC) Cryptographic Authentication", RFC 7298,
DOI 10.17487/RFC7298, July 2014,
<http://www.rfc-editor.org/info/rfc7298>.
Author's Address
Zhang Expires September 28, 2017 [Page 6]
Internet-Draft Multicast BABEL Extension March 2017
Zheng(Sandy) Zhang
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing
China
Email: zhang.zheng@zte.com.cn
Zhang Expires September 28, 2017 [Page 7]
