BGP for BIER-TE PathFutureweiBoston, MAUSAhuaimo.chen@futurewei.comFutureweimichael.mcbride@futurewei.comZTE Corporationchen.ran@zte.com.cnVerizon Inc.13101 Columbia PikeSilver SpringMD 20904USA 301 502-1347gyan.s.mishra@verizon.comChina TelecomBeiqijia Town, Changping DistrictBeijing102209Chinawangaj3@chinatelecom.cnChina Mobileliuyisong@chinamobile.comCasa SystemsUSAyfan@casa-systems.comFujitsuUSAliulei.kddi@gmail.comVolta NetworksMcLeanVAUSAxufeng.liu.ietf@gmail.comThis document describes extensions to
Border Gateway Protocol (BGP) for distributing
a Bit Index Explicit Replication Traffic Engineering (BIER-TE)
path.
A new Tunnel Type for BIER-TE path
is defined to encode the information about a BIER-TE path.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. introduces Bit Index
Explicit Replication (BIER) Tree Engineering (BIER-TE).
It is an architecture for per-packet stateless explicit
point to multipoint (P2MP) multicast path/tree, which
is called BIER-TE path, and
based on the BIER architecture defined
in .A Bit-Forwarding Router (BFR) in a BIER-TE domain has
a BIER-TE Bit Index Forwarding Table (BIFT).
A BIER-TE BIFT on a BFR comprises a forwarding entry for
a BitPosition (BP) assigned to each of the adjacencies of the BFR.
If the BP represents a forward connected adjacency,
the forwarding entry for the BP forwards the multicast packet
with the BP to the directly connected BFR neighbor of the adjacency.
If the BP represents a BFER (i.e., egress node)
or say a local decap adjacency,
the forwarding entry for the BP decapsulates the multicast packet
with the BP and passes a copy of the payload of the packet
to the packet's NextProto within the BFR.A Bit-Forwarding Ingress Router (BFIR) in a BIER-TE domain
receives the information or instructions about
which multicast flows/packets are mapped to which BIER-TE paths
that are represented by BitPositions or say BitStrings.
After receiving the information or instructions,
the ingress node/router encapsulates the multicast packets
with the BitPositions for the corresponding BIER-TE paths,
replicates and forwards the packets with the BitPositions
along the BIER-TE paths.This document proposes some procedures and extensions
to BGP for distributing a BIER-TE path to
the Bit-Forwarding Ingress Router (BFIR) of the path.
It specifies a way of encoding the information about
a BIER-TE path in a BGP UPDATE message,
which can be distributed to the BFIR of the path.The following terminologies are used in this document.
Bit Index Explicit Replication.BIER Tree Engineering.Bit-Forwarding Router.Bit-Forwarding Ingress Router.Bit-Forwarding Egress Router.BFR Identifier.
It is a number in the range [1,65535].BFR Neighbor.An IP address (either IPv4 or IPv6) of a BFR.Bit Index Routing Table.
It is a table that maps from the BFR-id (in a particular sub-domain)
of a BFER to the BFR-prefix of that BFER, and to the BFR-NBR
on the path to that BFER.Bit Index Forwarding Table.A multicast tunnel through the network
of one or more SPs.Provider Multicast Service Interface.
PMSI is an abstraction that represents a multicast service
for carrying packets. A PMSI is instantiated via one or
more P-tunnels.Inclusive PMSI Auto-Discovery
route.Selective PMSI Auto-Discovery
route.A route that is either
an I-PMSI A-D route or an S-PMSI A-D route.This section briefs the BGP for BIER-TE path and illustrates
some details through a simple example BIER-TE topology.An example BIER-TE domain topology using SDN controllor
with a BGP to distribute BIER-TE path
is shown in .
There are 8 nodes/BFRs A, B, C, D, E, F, G and H in the domain.
Nodes/BFRs A, H, E, F and D are BFIRs (i.e., ingress nodes)
or BFERs (i.e., egress nodes).
The controller has a BGP session with
each of the edge nodes in the domain,
including BFIRs (i.e., ingress nodes A, H, E, F and D),
and each of the non edge nodes in the domain
(i.e., nodes B, C and G).
Note that some of connections and the BGP on each edge
node are not shown in the figure.
Nodes/BFRs D, F, E, H and A are BFERs (or BFIRs) and have
local decap adjacency BitPositions 1, 2, 3, 4, and 5 respectively.
For simplicity, these BPs are represented by (SI:BitString),
where SI = 0 and BitString is of 8 bits.
BPs 1, 2, 3, 4, and 5 are represented by
1 (0:00000001), 2 (0:00000010), 3 (0:00000100), 4 (0:00001000)
and 5 (0:00010000) respectively. The BitPositions for the forward connected adjacencies
are represented by i', where i is from 1 to 20.
In one option, they are encoded as (n+i),
where n is a power of 2 such as 32768.
For simplicity, these BitPositions are represented
by (SI:BitString),
where SI = (6 + (i-1)/8) and BitString is of 8 bits.
BitPositions i' (i from 1 to 20) are represented by
1'(6:00000001), 2'(6:00000010), 3'(6:00000100), 4'(6:00001000),
5'(6:00010000), 6'(6:00100000), 7'(6:01000000), 8'(6:10000000),
9'(7:00000001), 10'(7:00000010), . . . , 16'(7:10000000),
17'(8:00000001), 18'(8:00000010), . . . , 20'(8:00001000).For a link between two nodes X and Y,
there are two BitPositions for two forward connected adjacencies.
These two forward connected adjacency BitPositions are assigned
on nodes X and Y respectively.
The BitPosition assigned on X is the forward connected
adjacency from Y to X.
The BitPosition assigned on Y is the forward connected
adjacency from X to Y.For example, for the link between nodes B and C in the figure,
two forward connected adjacency BitPositions 5' and 6'
are assigned to two ends of the link.
BitPosition 5' is assigned on node B to B's end of the link.
It is the forward connected adjacency from C to B.
BitPosition 6' is assigned on node C to C's end of the link.
It is the forward connected adjacency from B to C.Every BFR in a BIER-TE domain has
a BIER-TE BIFT.
For the BIER-TE topology in ,
each of 8 nodes/BFRs A, B, C, D, E, F, G and H
has its BIER-TE BIFT for the topology.The controller sends each
BFR all its BitPositions
including its local decap adjacency BitPosition and
forward connected adjacency BitPositions
after the BitPositions are determined and assigned
in the controller.
For example, the controller sends
BFR A BitPosition 1 and
BitPosition 2', where the former is A's local decap
adjacency BitPosition and the latter is
A's forward connected adjacency BitPosition from A to B.
The controller sends BFR B
BitPositions 1', 4', 6' and 8', which are
B's forward connected adjacency BitPositions from
B to A, G, C and E respectively.When a BFR (i.e., the BGP running on the BFR)
receives its BitPositions from the controller,
it creates its BIER-TE BIFT based on them.
For example, when BFR A receives its BitPositions,
it creates its BIER-TE BIFT, which is shown in
.
There are two forwarding entries in the BIFT.The 1st forwarding entry in the BIFT will locally decapsulate
a multicast packet with BitPosition 5 and pass a copy of the
payload of the packet to the packet's NextProto.The 2nd forwarding entry in the BIFT will forward a multicast
packet with BitPosition 2' to B.
When BFR B receives its BitPositions 1', 4', 6' and 8',
it creates its BIER-TE BIFT, which is shown in
.
There are four forwarding entries in the BIFT.The 1st forwarding entry in the BIFT will forward a multicast
packet with BitPosition 1' to A.The 2nd forwarding entry in the BIFT will forward a multicast
packet with BitPosition 4' to G.The 3rd forwarding entry in the BIFT will forward a multicast
packet with BitPosition 6' to C.The 4-th forwarding entry in the BIFT will forward a multicast
packet with BitPosition 8' to E.
This section describes how the SDN controller distributes
a BIER-TE path to its ingress node.There are two scenarios for distributing the BIER-TE path
information.
In the first scenario,
the ingress node is directly connected to the controller.
The path information should not be propagated
beyond the ingress node.
In the second scenario, the ingress node is not directly
connected to the controller.
The path information should be propagated throughout
the domain until it reaches the ingress node.Suppose that node A in
wants to have a BIER-TE path
from ingress node A to egress nodes H and F.
The path satisfies a set of constraints.
The controller obtains the
request from an application or user configuration.
It finds a BIER-TE path satisfying the constraints
and distributes the path to ingress node A.If A is directly connected to the controller
(e.g., as the example network
in ),
then the controller sends A
the information about the path in a Update message
in one of two ways.
In one way, the controller sends each of its BGP peers,
including the BGP peer running on node A, a Update message
about the explicit path, with
a route target matching the BGP identifier of ingress node A,
and NO_ADVERTISE community.
Ingress node A accepts this message from the controller and
installs a forwarding entry for the BIER-TE path,
but will not advertise it to any peer.
All the other peers do not accept the message.In another way, the controller sends A
a Update message directly through the local session between them,
but does not send the message to any other peers,
which contains the information about the path,
a route target matching the BGP identifier of ingress node A
(the route target may be optional),
and the NO_ADVERTISE community.
Ingress node A accepts this message from the controller and
installs a forwarding entry for the BIER-TE path,
but will not advertise it.If A is not directly connected to the controller,
then the controller distributes the information about
the explicit path to the ingress node A across the network.
To achieve this, the controller advertises
a BGP Update message to all its BGP peers,
where the message contains the information about the path,
a route target matching
the BGP identifier of ingress node A, but
does not have NO_ADVERTISE community.
Each of the BGP peers advertises the received Update
to its BGP neighbors
according to normal BGP propagation rules.
Eventually, ingress node A accepts this message
and installs a forwarding entry for the BIER-TE path,
which imports the packets to be transported by the path
into the path.
For example, assume that
the BIER-TE path computed by the controller
traverses
the link/adjacency from A to B (indicated by BP 2'),
the link/adjacency from B to G (indicated by BP 4') and
the link/adjacency from B to C (indicated by BP 6'),
the link/adjacency from G to H (indicated by BP 18'),
and the link/adjacency from C to F (indicated by BP 16').
This path is represented by {2', 4', 6', 16', 18', 2, 4},
where BitPositions 2 and 4 indicate egress nodes F and H
respectively.
The Update message distributed to the BGP on node A
by the controller
contains the path represented by
{2', 4', 6', 16', 18', 2, 4}.After receiving the BIER-TE path, the ingress node
installs a forwarding entry for the path.
For any packet from CE to be
transported by the path, the ingress node encapsulates
the packet with the BitPositions representing the path and
forwards the packet according to its BIFT.For example, when ingress node A receives the path
represented by BitPositions {2', 4', 6', 16', 18', 2, 4}, it
installs a forwarding entry for the path. Node A
encapsulates a packet to be carried by the path
with a BIER header containing BitPositions
{2', 4', 6', 16', 18', 2, 4} using the entry and forwards
the encapsulated packet along the path according to its BIFT.A forwards the packet to B according to the forwarding
entry for BP 2' in its BIFT.After receiving the packet from A,
B forwards the packet to G and C according to the forwarding
entries for BPs 4' and 6' in B's BIFT respectively.
The packet received by G has path {16', 18', 2, 4}.
The packet received by C has path {16', 18', 2, 4}. After receiving the packet from B, G sends the
packet to H according to the forwarding
entry for BP 18' in G's BIFT.After receiving the packet from B, C sends the
packet to F according to the forwarding
entry for BP 16' in C's BIFT.Egress node H of the BIER-TE path receives
the packet with BitPosition 4. It decapsulates the
packet and pass the payload of
the packet to the packet's NextProto.Egress node F of the BIER-TE path receives
the packet with BitPosition 2. It decapsulates the
packet and pass the payload of
the packet to the packet's NextProto.This section specifies two options for extensions to BGP.
One option defines a new Tunnel Type for BIER-TE path
under Tunnel Encapsulation Attribute.
The other defines a new Tunnel Type
under PMSI_TUNNEL Attribute.This section defines a new Tunnel Type (or TLV) for
BIER-TE path/tunnel
under the PMSI_TUNNEL Attribute (PTA) defined
in .
It describes a couple of new sub-TLVs
encoding the information about a BIER-TE path.
The PMSI Tunnel attribute carried by an x-PMSI A-D
route identifies P-tunnel for PMSI.
For the PTA with Tunnel Type BIER-TE,
the PTA is constructed by the SDN controller and
distributed to the ingress node of the BIER-TE tunnel.
The format of the PMSI_TUNNEL Attribute with the
new Tunnel Type (TBD) for BIER-TE is shown in
. For BIER-TE tunnel/path, the fields in the PTA are set as
follows:
It is set to be TBD,
indicating BIER-TE tunnel.It contains:
It is id of the sub domain through which
the BIER-TE tunnel crosses.
It is the BFR-id of the BFIR of the BIER-TE tunnel.
It is a number uniquely identifying
a BIER-TE tunnel within the BFIR and sub domain.
It is a BFR-prefix of the BFIR of the BIER-TE tunnel.
It occupies 4 octets for IPv4 and
16 octets for IPv6.It contains
a Path BitPositions sub-TLV encoding an explicit
BIER-TE path. It may include a Path Name sub-TLV
for the name of the BIER-TE path.
The other fields are set
according to .This section describes two sub-TLVs for a BIER-TE path:
Path BitPositions sub-TLV for encoding the path and
Path Name sub-TLV for the name of the path. The bit positions of a BIER-TE path are encoded in a
Path BitPositions sub-TLV.
The format of the sub-TLV is illustrated below. Its value (TBD1) is to be assigned by IANA.It is variable.MUST be set to zero by the sender
and MUST be ignored by the receiver.
The length in bits of the SI field.
The length in bits of the BitString field according to
.
If k is the length of the BitString, the value of BitStringLen
is log2(k)-5. For example, BitStringLen = 1 indicates k = 64,
BitStringLen = 7 indicates k = 4096.Unique value identifying the BIER
sub-domain within the BIER domain.Multi-Topology ID identifying the topology
that is associated with the BIER sub-domain.
Each BIFT-id-i, SI-i and BitString-i (i = 1, 2, ..., n) tuple
represents/encodes a set of bit positions on the BIER-TE path
with a BIFT ID.
All the BIFT-id, SI and BitString tuples in the sub-TLV
represent/encode the BIER-TE path
(i.e., all the bit positions of the BIER-TE path).For example, when SI-Len = 8 and BitStringLen = 1
(indicating BitString is of 64 bits),
each BIFT-id, SI and BitString tuple
has a BIFT-id of 20 bits, a SI of 8 bits and
a BitString of 64 bits.
For simplicity, BitString of 8 bits and
BIFT-id of 16 bits are used below.
The BitPositions for a BIER-TE path are sorted in
descending order before they are put into a BIER-TE
Path BitPositions sub-TLV.
For BIER-TE path {2', 4', 6', 16', 18', 2, 4},
when its BitPositions are sorted,
it is {18', 16', 6', 4', 2', 4, 2},
which is {18'(8:00000010), 16'(7:10000000),
6'(6:00100000), 4'(6:00001000), 2'(6:00000010),
4 (0:00001000), 2 (0:00000010)}.
The BitPositions with the same SI are stored in
one BitString. For example,
6'(6:00100000), 4'(6:00001000) and 2'(6:00000010)
are stored in (SI:BitString) = (6:00101010), where SI = 6.
BIER-TE path {18', 16', 6', 4', 2', 4, 2} is encoded in
the Path BitPositions sub-TLV in the figure below. The path uses
four tuples of BIFT-id, SI and BitString.
The name of a BIER-TE path is encoded in a
Path Name sub-TLV.
The format of the sub-TLV is illustrated below. Its value (TBD2) is to be assigned by IANA.It is variable.MUST be set to zero by the sender
and MUST be ignored by the receiver.
It represents/encodes the name of the BIER-TE path
in a string of chars.This section define a new Tunnel Type (or say TLV)
for BIER-TE path/tunnel
under Tunnel Encapsulation Attribute.
A new Tunnel Type (or say TLV), called BIER-TE Path or Tunnel,
is defined under Tunnel Encapsulation Attribute in
.
Its codepoint is to be assigned by IANA.
This new TLV with a number of new sub-TLVs
encodes the information about a BIER-TE path.The structure encoding the information about a BIER-TE
path is shown below.
Where:
Tunnel Type (TBD) is to be assigned by IANA.Path BitPositions sub-TLV encodes the bit positions of the
BIER-TE path. It is defined in the previous section.Path Name sub-TLV encodes the name of a BIER-TE path.
It is defined in the previous section.Traffic Description sub-TLV encodes the multicast traffic
that is transported by the BIER-TE path.A Traffic Description Sub-TLV describes the traffic to be
imported into a BIER-TE path.
Two Traffic Description Sub-TLVs are defined.
They are multicast traffic sub-TLVs for IPv4 and IPv6.The multicast traffic sub-TLVs for IPv4 and IPv6
are shown in and
respectively.
The address fields and address mask lengths of the two Multicast
Traffic
sub-TLVs contain source and group prefixes for matching
against packets noting that the two address fields are up to 32 bits
for an IPv4 Multicast Traffic and up to
128 bits for an IPv6 Multicast Traffic.
The Reserved field MUST be set to zero and ignored on receipt.
Two bit flags (S and G) are defined to describe the multicast
wildcarding in use. If the S bit is set, then source wildcarding is
in use and the values in the Source Mask Length and Source Address
fields MUST be ignored. If the G bit is set, then group wildcarding
is in use and the values in the Group Mask Length and Group multicast
Address fields MUST be ignored. The G bit MUST NOT be set unless the
S bit is also set: if a Multicast Traffic sub-TLV is received
with S bit = 0 and G bit = 1 the receiver MUST respond with an error
(Malformed Multicast Traffic).
The three multicast mappings may be achieved as follows:
S bit = 0, G bit = 0, the Source Address and Group
multicast Address prefixes are both used to define
the multicast traffic.
S bit = 1, G bit = 0, the Group multicast Address prefix
is used to define the multicast traffic, but the Source
Address prefix is ignored.
S bit = 1, G bit = 1, the Source Address and Group
multicast Address prefixes are both ignored.TBDTBD