PIM BABEL EXT
draft-zhang-pim-babel-ext-00

Abstract

This document describes a method that uses Babel protocol extension to deliver multicast information.

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 June 25, 2017.

Copyright Notice

Copyright (c) 2016 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.

Table of Contents

• 1. Terminology
• 2. Introduction
• 3. Babel extensions for multicast information
• 4. Protocol treatment
• 4.1. LHR treatment
• 4.2. FHR treatment
• 4.2.1. Confliction treatment
• 4.3. Process
• 5. Security Consideration
• 6. IANA Considerations
• 7. Acknowledgements
• 8. Normative References
• Authors' Addresses

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 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. In the other hand, in case PIM protocol is used in the network, multicast information can be delivered by PIM protocol that is defined in [I-D.ietf-pim-source-discovery-bsr]. The user device must support Babel protocol and PIM protocol at the same time.

It is very suitable that use MLD/PIM protocol in large and well-managed network. But in middle or small network, the management of MLD/PIM 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

[I-D.ietf-pim-source-discovery-bsr] defines an effective way to deliver multicast information by the way of PIM packet flooding. The extensions of Babel will reference the format that is defined in [I-D.ietf-pim-source-discovery-bsr]. 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |     flag      |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         sub-sub-type          |            length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Group Address (Encoded-Group format)             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Src Address (Encoded-Unicast format)             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            ......                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 1 Multicast information extension format
            

• Type : Type: The sub-type of Babel multicast information sub-TLV. The value is TBD.
• Flag: Indicates that the sub-TLV is from a FHR. The value is TBD.
• Length: The total length of the sub-TLV.
• Type: The sub-sub-TLV Indicates the IPv4/IPv6 multicast information. The value is TBD.
• Length: The length of group and source address.
• 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.
• 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.

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

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 for his valuable contributions.

8. Normative References

Authors' Addresses