Internet DRAFT - draft-hfa-bier-pim-tunneling
draft-hfa-bier-pim-tunneling
BIER Workgroup H. Bidgoli, Ed.
Internet Draft A. Dolganow
Intended status: Standard Track Nokia
Fengman Xu
Verizon
Expires: December 23, 2017 June 21, 2017
PIM Tunneling Through BIER Core
draft-hfa-bier-pim-tunneling-00
Abstract
Bit Index Explicit Replication (BIER) is an architecture that
provides multicast forwarding through a "BIER domain" without
requiring intermediate routers to maintain multicast related per-flow
state. Neither does BIER require an explicit tree-building protocol
for its operation. A multicast data packet enters a BIER domain at a
"Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at
one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router
adds a BIER header to the packet. Such header contains a bit-string
in which each bit represents exactly one BFER to forward the packet
to. The set of BFERs to which the multicast packet needs to be
forwarded is expressed by the according set of bits switched on in
BIER packet header.
This document describes the procedure needed for PIM to be tunneled
through a BIER core. Allowing access CEs or PEs to run traditional
PIM multicast services including draft rosen multicast MVPN through a
core of BIER.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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." The list
Bidgoli, Xu et al. Expires December 23, 2017 [Page 1]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 8, 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PIM Tunneling Through BIER domain . . . . . . . . . . . . . . . 5
3.1. PIM-BFIR procedure . . . . . . . . . . . . . . . . . . . . 6
3.1.1. BIER packet construction at PIM BFIR . . . . . . . . . 6
3.2. Tunneling PIM through the BIER domain procedure . . . . . . 7
3.3. PIM-BFER procedure . . . . . . . . . . . . . . . . . . . . 7
4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . . 8
4.1. BIER reverse path forwarding table . . . . . . . . . . . . 8
4.2. Datapath traffic flow . . . . . . . . . . . . . . . . . . . 9
5. PIM-ASM behavior . . . . . . . . . . . . . . . . . . . . . . . 9
6. Draft Rosen multicast vpn behavior . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Bidgoli, Xu et al. Expires December 23, 2017 [Page 2]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
Most Service Providers understand the benefit of BIER and would like
a Core network that supports scalable multicast solution by removing
the multicast states and deploying BIER.
That said greenfield deployment of BIER might not be possible for
providers that deploy MVPN technology, or have more than 256 PEs in
their network. Consider the following:
1.Most service providers deploy MVPN technology for multicast today.
Their network structure typically is a Core network, which connects
edge networks containing PEs. These PEs run MVPN services like
draft rosen multicast vpns. In a typical tier one provider the
number of PEs is well beyond 1K of routers. As the edge network
expands the scale of multicast states in the core could test the
routers limits. As such it is attractive to create a stateless BIER
core which can transport MVPN technology. By deploying BIER in the
core of the network the bottle necks for multicast states is
removed. By pushing the multicast states to the edge provider (P)
routers, a more manageable multicast state can be achieved.
2.Deploying greenfield BIER services for most providers could be a
challenge. It might be attractive to deploy bier in multiple
phases. Starting from the core of the network to remove the massive
multicast state generated by traditional MVPN services is an ideal
evolution path. By tunneling traditional MVPN technology through a
BIER core an scalable and manageable network can be created.
3.Most vendors support 256 bits in the BIER header. Identifying only
256 PEs or CEs via a single BIER packet. Scaling beyond 256 PEs or
CEs "might" require packet duplation depending on network topology.
This packet duplication will be done via BIER Set Index (SI) which
is explained in draft-ietf-bier-architecture. In the cases that
packet duplication can't be avoid it might be desirable to segment
the network to traditional MVPN technology at the access and BIER
in the core. By moving the Bier in the core all core routers could
be presented via the 256 bits in the BIER header.
In all above cases it might be attractive to be able to tunnel
traditional MVPN services over a BIER core.
This draft explains the procedure to tunnel PIM through a BIER core,
as such enable tunneling of traditional MVPN services like draft-
rosen multicast vpns through a core of BIER.
The procedures of PIM tunneling should be used at the BIER edge
routers. The BIER edge routers (BER) are connected to legacy PIM
routers on one side and BIER routers on the other side. PIM routers
continue to send PIM state messages to the BER but the BER does not
Bidgoli, Xu et al. Expires December 23, 2017 [Page 3]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
propagate PIM packets natively into the BIER sub-domain. Instead it
will tunnel the PIM through BIER network.
In this draft the BFIR and BFER are the BER from multicast traffic
point of view and not PIM signaling. That said the PIM BFIR (P-BFIR)
and PIM (P-BFER) are BER from PIM signaling point of view.
As such a P-BFIR would be a BFER of the multicast traffic and a P-
BFER would be a BFIR of the multicast traffic.
2. Conventions used in this document
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 RFC 2119 [RFC2119].
2.1. Definitions
Some of the terminology specified in [I-D.draft-ietf-bier-
architecture-05] is replicated here and extended by necessary
definitions:
BIER:
Bit Index Explicit Replication (The overall architecture of
forwarding multicast using a Bit Position).
BFR:
Bit Forwarding Router (A router that participates in Bit Index
Multipoint Forwarding). A BFR is identified by a unique BFR-
prefix in a BIER domain.
BFIR:
Bit Forwarding Ingress Router (The ingress border router that
inserts the BM into the packet). Each BFIR must have a valid
BFR-id assigned. In this draft BIER will be used for
forwarding and tunneling of control plain packet (i.e. PIM)
and forwarding dataplain packets. BFIR is term used for
dataplain packet forwarding.
BFER:
Bit Forwarding Egress Router. A router that participates in
Bit Index Forwarding as leaf. Each BFER must be a BFR. Each
BFER must have a valid BFR-id assigned. In this draft BIER
will be used for forwarding and tunneling of control plain
Bidgoli, Xu et al. Expires December 23, 2017 [Page 4]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
packet (i.e. PIM) and forwarding dataplain packets. BFIR is
term used for dataplain packet forwarding.
P-BFIR:
PIM-Bit Forwarding ingress router. Ingress boundary router
between PIM domain and BIER domain. It tunnels PIM packet
through a BIER domain toward the source.
P-BFER:
PIM-Bit Forwarding egress router. Egress boundary router
between BIER domain and PIM domain. It decapsulates PIM packet
from a BIER tunnel and forwards it to the PIM domain.
BRT:
BIER RPF Table, is built on the P-BFER. It tracks which P-BFIR
is interested in a group. It is used to map the group to the
P-BFIR BIER prefix.
BFT:
Bit Forwarding Tree used to reach all BFERs in a domain.
BIFT:
Bit Index Forwarding Table.
BIER sub-domain:
A further distinction within a BIER domain identified by its
unique sub-domain identifier. A BIER sub-domain can support
multiple BitString Lengths.
BFR-id:
An optional, unique identifier for a BFR within a BIER sub-
domain.
3. PIM Tunneling Through BIER domain
Suppose BIER sub-domain is to be an IGP area or instance. The BIER
edge routers (BER) can be ABRs that are connected to edge network via
IGP or BGP, or they can be any provider (P) router that is selected
to act as the BER in that BIER sub-domain.
Bidgoli, Xu et al. Expires December 23, 2017 [Page 5]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
Each BER is configured as per BIER requirements explained in draft-
ietf-bier-architecture.
The BERs receive PIM joins from the downstream routers because they
are on the path toward the source. Additionally, on these BERs all
interfaces which are PIM enabled are configured to tunnel PIM over
BIER.
3.1. PIM-BFIR procedure
When PIM joins for a certain (S,G) arrives on a BER, in this case the
P-BFIR (BFIR from PIM signaling point of view). This router first
find the route to the source. The route to the source is assumed to
be an IGP route. The BER tries to resolve the source (S), in the
process it of resolving the source the SPF calculation can return the
P-BFER that is in the path to the source.
The procedure to find the P-BFER (BFER from PIM signaling point of
view) can be via 2 mechanism and is beyond the scope of this draft.
1.The P-BFER can be an ABR or ASBR router which is summarizing the
route to the source, and as such is the source of this route.
2.The P-BFER can be resolved via SPF calculation and finding the
first BFIR in the path the source.
The P-BFIR will become the BFER for multicast traffic point of view.
This P-BFIR will track all the PIM interfaces that are interested in
the (S,G) and create multicast states for all PIM routers attach to
it. This BFER route will have incoming interface (RPF) as BIER
"tunnel" interface and outgoing interface as the interface on which
PIM Join was received. If there is another PIM Join for the same
multicast (S,G) entry on some other interface, that interface gets
added in the outgoing interface list.
The P-BFIR after discovering the P-BFER and its BFR-ID (flooded via
IGP BIER extension) will construct the BIER header via the BIFT. The
PIM packet is encapsulated in the BIER header and transported through
BIER domain to P-BFER.
3.1.1. BIER packet construction at PIM BFIR
The BIER header will be encoded with the BFR-id of the P-BFER(with
appropriate bit set in the bitstring) and PIM Join is then
encapsulated in the packet.
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
Bidgoli, Xu et al. Expires December 23, 2017 [Page 6]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIFT-id | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nibble | Ver | BSL | Entropy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM|Rsv| DSCP | Proto | BFIR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BIERHeader.Proto = PIM
BIERHeader.BitString= Bit corresponding to the BFR-ID of the P-BFER
BIERHeader.BFIR-id = BFR-Id of the BER originating the encapsulated
PIM packet, i.e. the P-BFIR.
Rest of the values in the BIER header are determined based on the
network (MPLS/non-MPLS), capabilities (BSL), and network
configuration.
3.2. Tunneling PIM through the BIER domain procedure
Throughout the BIER domain the BIER forwarding procedure is in par
with draft-ietf-bier-architecture. No BIER router will examine the
tunnel PIM packet. As such there is no multicast state build in the
BIER domain.
The packet will be forwarded through the BIER domain until it reaches
the BER with matching BFR-ID as in the BIERHeader.Bitstring. This BER
(P-BFER) will examine the packet and know that it is a PIM packet
from BIERHeader.Proto field and farther processing is needed.
3.3. PIM-BFER procedure
After receiving the BIER packet and processing the PIM payload
encapsulated in BIER packet the P-BFER will remove the BIER header
from PIM packet and lookup the route to the source, if the source is
in PIM domain, it forwards the PIM packet toward the source.
With same token the P-BFER creates a multicast state with incoming
interface as same interface that PIM join packet was forwarded and
outgoing interfaces of BIER-Header.BFIR-id.
Bidgoli, Xu et al. Expires December 23, 2017 [Page 7]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
The P-BFER will also build a BIER reverse path forwarding table (BRT)
table, using the BIERHeader.BFIR-id and the Group specified in the
arriving PIM packet (S,G). BRT will be used by BFIR for datapath
forwarding.
The router keeps track of all BFIR-ids interested in the Group
specified in the (S,G) and updates the multicast state and populates
the BRT accordingly.
It should be noted this router can also receive and forward PIM
packet from other routers in the PIM domain and update the muticast
state accordingly.
At this point the end-to-end multicast traffic flow setup is
complete.
4. Datapath Forwarding
4.1. BIER reverse path forwarding table
The BIER RPF table (BRT) is needed on the BFIR so the multicast
traffic can find the P-BFIR ID and append the correct BIT index to
the BIER header for the multicast traffic before forwarding to BIER
domain.
This table is built on the P-BFER buy using info from PIM packet and
its corresponding BIER header. The PIM packet can provide the
specific Group (G) address, meanwhile its corresponding BIER header
can provide the originating P-BFIR ID. The P-BFIR is the last BIER
router in the BIER domain or the BFER from datapath point of view.
These two pieces of information will be used to build BRT.
It should be noted that a single group can be associated with
multiple P-BFIR IDs, as an example multiple MVPN leaf routers behind
BIER domain are interested in the same group. These LEAF PEs are
reachable via different P-BFIRs.
When the correct P-BFIR(s) (BFER(s)) are found in this table their P-
BFIR ID can be used to do a lookup in BIFT and appropriate BIT
indexes appended to the BIER header before forwarding the packet to
BIER domain.
As an example in the network below:
Bidgoli, Xu et al. Expires December 23, 2017 [Page 8]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
(BFIR) (BFER)
S--(P-BFER)---BIER-DOMAIN---(P-BFIR)--A (join (S,G1),(S,G2))
|-----C (join (S,G1),(S,G3))
|-----E (join (S,G3))
The BRT is as follow:
------------------------
| Group | P-BFIR |
========================
| (G1) | C,A |
------------------------
| (G2) | A |
------------------------
| (G3) | E,C |
------------------------
And the BIFT is as follow:
----------------------------
| BFR-id | BFR-NBR |
| (SI:Bitstring) | |
============================
| 1 (0:0001) | C |
----------------------------
| 3 (0:0100) | E |
----------------------------
| 4 (0:1000) | A |
----------------------------
As such a multicast dataplain packet arriving with destination G1
will have the BITs (0:1001) and a packet arriving with destination of
G3 will have the BITs of (0:0101)
4.2. Datapath traffic flow
When the multicast data traffic arrives on the BFIR (P-BFER) the
router will find the destination IP of the traffic (i.e. group
address) in the BRT. The BFIR then finds all the P-BFIR (BFER) that
are interested in this group from the BRT table. The router then
constructs the BIERHeader.BitString with all the BFIR interested in
the group and will forward the packet to the BIER domain. The BFER(s)
will accept the packets and remove the BIER header and forward the
multicast packet as per pre-build multicast state for (G) and its
outgoing interfaces.
5. PIM-ASM behavior
In case of PIM ASM the procedure for LEAFs joining RP or the source
Bidgoli, Xu et al. Expires December 23, 2017 [Page 9]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
is same as above. The unicast (source registration) traffic from
source to RP will be flooded throughout the BIER domain as regular
unicast traffic without BIER involvement.
6. Draft Rosen multicast vpn behavior
Over the years draft rosen mvpn has evolved with many different type
of signaling.
As an example, with AD and C-Multicast signaling of PIM or C-
Multicast of PIM and AD of BGP.
The above mechanism works with draft rosen mvpn as long the C-
multicast signaling is done via PIM. The provider PIM for MVPN can be
forwarded from Root and LEAF PE with above explained mechanism.
The multicast traffic has to be forwarded via GRE tunnel. That said
the AD signaling can be done via MP-BGP.
Future drafts will address the NG-MVPN and MPLS tunneling.
7. Security Considerations
TBD
7.1. Normative References
[BIER_ARCH] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T.,
and S. Aldrin, "Multicast using Bit Index Explicit Replication",
internet-draft draft-ietf-bier-architecture-05, October 2016.
[DRAFT ROSEN] E. Rosen, Y. Cai, I. Wijnands, draft-rosen-vpn.mcast-
15, June 2010 (RFC 6037)
7.2. Informative References
[BGP_BIER_EXTENSIONS] Xu, X., Chen, M., Patel, K., Wijnands, I., and
A. Przygienda, "BGP Extensions for BIER", internet-draft draft-ietf-
bier-idr-extensions-02.txt, June 2017.
[BIER-OAM] Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
and G. Mirsky, "BIER Ping and Trace", internet-draft draft-ietf-bier-
ping-01.txt, January 2017.
[BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S.,
Dolganow, A., and T. Przygienda, "Multicast VPN Using Bier",
internet-draft draft-ietf-bier-mvpn-05, January 2017.
Bidgoli, Xu et al. Expires December 23, 2017 [Page 10]
Internet-Draft PIM Tunneling Through BIER Core June 21, 2017
[ISIS_BIER_EXTENSIONS] Ginsberg, L., Przygienda, T., Aldrin, S., and
Z. Zhang, "BIER Support via ISIS", internet-draft draft-ietf-bier-
isis-extensions-04.txt, March 2017.
[OSPF_BIER_EXTENSIONS] Psenak, P., Kumar, N., Wijnands, IJ.,
Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF
Extensions for Bit Index Explicit Replication", internet-draft draft-
ietf-ospf-bier-extensions-05.txt, March 2017.
8. Acknowledgments <Add any acknowledgements>
Authors' Addresses
Hooman Bidgoli (editor)
Nokia
600 March Rd.
Ottawa, Ontario K2K 2E6
Canada
Email: hooman.bidgoli@nokia.com
Fengman Xu
Verizon
400 International PKWY
Richardson, Tx 75081
US
Email: fengman.xu@verizon.com
Andrew Dolganow
Nokia
750D Chai Chee Rd
06-06, Viva Business Park
Singapore 469004
Email: Andrew.dolganow@nokia.com
Bidgoli, Xu et al. Expires December 23, 2017 [Page 11]
