PCE for BIER-TE PathFutureweiBoston, MAUSAHuaimo.chen@futurewei.comFutureweimichael.mcbride@futurewei.comChina TelecomBeiqijia Town, Changping DistrictBeijing102209Chinawangaj3@chinatelecom.cnVerizon Inc.13101 Columbia PikeSilver SpringMD 20904USA 301 502-1347gyan.s.mishra@verizon.comChina Mobileliuyisong@chinamobile.comCasa SystemsUSAyfan@casa-systems.comFujitsuUSAliulei.kddi@gmail.comVolta NetworksMcLeanVAUSAxufeng.liu.ietf@gmail.comThis document describes extensions to Path
Computation Element (PCE) communication Protocol (PCEP)
for supporting Bit Index Explicit Replication (BIER)
Traffic Engineering (TE) paths.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) Traffic/Tree Engineering
(BIER-TE).
It is an architecture for per-packet stateless explicit
point to multipoint (P2MP) multicast path/tree and
based on the BIER architecture defined in .A Bit-Forwarding Ingress Router (BFIR) in a BIER-TE domain
receives the information or instructions from a controller
such as a stateful PCE about
which multicast flows/packets are mapped to which P2MP paths.
The multicast flows/packets are indicated by multicast
and source addresses.
The paths 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 P2MP paths,
replicates and forwards the packets with the BitPositions
along the P2MP paths. describes a set of extensions to
PCEP to provide stateful control.
A stateful PCE has access to not only the information
carried by the network's Interior Gateway Protocol (IGP)
but also the set of active paths and their reserved resources.
The additional state allows the PCE to compute constrained
paths while considering individual paths and their
interactions.To compute and initiate BIER-TE P2MP paths, the stateful PCE
needs to be extended.
For a BIER-TE P2MP path, some new state information will be
stored and maintained, which includes the BitPositions,
multicast group and multicast source for the path.
The PCE gets the egresses of the path, the same multicast group
and source from the egresses when each of the egresses reports
to the PCE that it receives a multicast join with the
multicast group and source.
With this information, the PCE finds an ingress for the path,
computes the path from the ingress to the egresses that
has the optimal BitPositions and satisfies the constraints, and
then initiates the BIER-TE path at the ingress of the path
through sending the ingress the BitPositions of the path,
multicast group and source in a PCEP message such as PCInitiate.
After receiving the message, the ingress creates
a forwarding entry that imports the packets with the multicast
group/address and source into the BIER-TE path (i.e.,
encapsulates the packets with a BIER-TE header having the
BitPositions of the path), and then reports the status of the
path to the PCE in a PCEP message such as PCRpt. describes part of
the solution for this, which is mainly the BIER-ERO subobject
used for P2MP paths.This document proposes a comprehensive solution
for computing and establishing BIER-TE P2MP paths.The following terminologies are used in this document.
Path Computation ElementPCE communication ProtocolPath Computation ClientCustomer EdgeProvider EdgeBit Index Explicit Replication.BIER Traffic/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.Label Switching Path DataBase.Traffic/Tree Engineering DataBase.
This section briefly describes PCE for BIER-TE and illustrates
some details through a simple example BIER-TE topology.An example BIER-TE topology for a BIER-TE domain with a PCE
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).
There is a connection (i.e., PCE session) between the PCE and
the PCC running on each of the possible ingress and egress
nodes in the domain.
Note that some of connections and the PCC on each 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 of Y.
The BitPosition assigned on Y is the forward connected
adjacency of X.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 of node C.
BitPosition 6' is assigned on node C to C's end of the link.
It is the forward connected adjacency of node B.For a BIER-TE Path to transport the packets with a given
multicast group/address and source in a BIER-TE domain,
a sequence of PCEP messages are exchanged between the PCE
for the domain and the PCEs for the domains containing the source,
and between the PCE for the domain and the PCCs running
on the BFERs/BFIRs of the domain. Suppose that each of nodes H, D and F receives a multicast
join with a same multicast group/address and source,
which are MGa and MSa respectively.
For simplicity, assume that the multicast source MSa is in
the left domain containing the CE in .
The following is a brief flow of PCEP messages for
computing and creating a BIER-TE Path to transport
the packets to H, D and F.At first, the PCC running on each of nodes H, D and F
sends the PCE a PCEP message such as PCRpt.
The message contains the multicast group and source
(i.e., MGa and MSa), which reports to the PCE
that the node receives a multicast join with MGa and MSa.
Note that a PCEP message is sent to the PCE from the PCC on
a node to report that the node leaves
when the node receives a multicast leave with MGa and MSa.After receiving the PCEP messages from nodes H, D and F
reporting multicast join with MGa and MSa,
the PCE for the domain containing these nodes
determines that nodes H, D and F are the egress nodes
of a BIER-TE path since they have the same multicast group
and source. Second, the PCE for the domain sends a PCEP message such as
PCReq to each of the PCEs for the domains that may contain
the multicast source. This message requests the PCE
(that may contain the source) to find an ingress node
for the BIER-TE path having egress nodes H, D and F.
The message contains the multicast group and source
(i.e., MGa and MSa).
For example, the PCE for the BIER-TE domain sends the PCEP
message to the PCE (called PCE-L) for the left domain
containing CE (note that this PCE is not shown in the figure).
After receiving the PCEP message requesting to find an ingress
node, the PCE (e.g., PCE-L) for the domain containing the
multicast source computes the ingress node that is reachable
from the source with minimum cost (e.g., ingress node A).
The PCE for the domain
without the source can not find any ingress node.Third, the PCE for the domain with the source sends the
PCE for the BIER-TE domain a PCEP message such as PCRep
with the ingress node.
The PCE for the domain without the source sends the
PCE for the BIER-TE domain a PCEP message such as PCRep
with NO INGRESS FOUND.After receiving the PCEP message with the ingress
node, the PCE for the BIER-TE domain computes a P2MP path
from the ingress node (e.g., A) to the egress nodes
(e.g., H, D and F). The path has the optimal BitPositions
and satisfies the constraints. The optimal BitPositions means
the BitPositions for the path has the minimum number of bit
sets and the minimum bit distance.Fourth, the PCE for the BIER-TE domain sends a PCEP message
such as PCInitiate to the PCC on the ingress node (e.g., A) for
the ingress to create a BIER-TE path to transport the packets
for the given multicast group and source. The message contains
the BitPositions for the path, the multicast group and source.After receiving the PCEP message with the path,
the PCC on the ingress (e.g., A) creates the BIER-TE path,
i.e., a forwarding entry that imports the packets with the
multicast group/address and source into the BIER-TE path (i.e.,
encapsulates the packets with a BIER-TE header having the
BitPositions of the path).And then the PCC on the ingress sends the PCE a PCEP message
such as PCRpt reporting the status of the path to the PCE.
After receiving the PCEP message with the status of the path,
the PCE for the domain updates the information about the path
accordingly.This section introduces the procedures for the ingress
node of a P2MP path to get the BitPositions representing
the explicit P2MP path from the ingress node to its
egress nodes from the PCE.Suppose that node A in
wants to have an explicit P2MP path
from ingress node A to egress nodes H and F.
The path satisfies a set of constraints.
In one case, the PCC running on ingress node A
sends a request for the path to the PCE.
The request contains the set of constraints, objective functions,
the ingress node and the egress nodes.
After receiving the request, the PCE computes
an explicit P2MP path, which satisfies the constraints
and is from the given ingress node to the egress nodes.
While computing the path, the PCE will optimize the
BitPositions of the path.
That is that, for a given length of BitString, the path computed
uses the minimum number of BitStrings (i.e., bit sets)
and satisfies the constraints. The length is given by
the value in BitStrLen field in
the PCE-BIER-TE-Path-Capability sub-TLV.
The PCE sends a reply with the path to the PCC.
The reply contains the BitPositions representing
the explicit P2MP path.For example, assume that
the explicit P2MP path computed by the PCE 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 reply sent to the PCC on node A by the PCE
contains the path represented by
{2', 4', 6', 16', 18', 2, 4}.In another case, a request for a P2MP path is from a
user or application.
After receiving the request, the PCE finds an ingress node
if no ingress is given, and computes
an explicit P2MP path from the ingress node
to the egress nodes and
sends the path to the PCC running on the ingress node.After receiving the P2MP path, for any packet from CE to be
transported by the path,
such as the packet with the multicast address,
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
encapsulates every packet from CE with the multicast address
with the BitPositions and then forwards the packet
along the P2MP 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 P2MP 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 P2MP 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 describes extensions to PCEP.During a PCEP session establishment, PCEP Speakers (PCE or PCC)
indicate their ability to support BIER-TE paths.
The OPEN object in the Open message contains the
PATH-SETUP-TYPE-CAPABILITY TLV, which
is defined in . The TLV
contains a list of Path Setup Types (PSTs) and
optional sub-TLVs associated with the PSTs.
The sub-TLVs convey the parameters that are associated
with the PSTs supported by a PCEP speaker.This document defines a new PST value:
Path is setup using
BIER-TE.
A new sub-TLV associated with this new PST is defined,
which is called PCE-BIER-TE-Path-Capability sub-TLV.
The format of this new sub-TLV is illustrated in the figure
below.
TBD2 is to be assigned by IANA. 4 is the total length in bytes of
the remainder of the TLV, excluding
the Type and Length fields.
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 BitStrLen
is log2(k)-5. For example, BitStrLen = 1 indicates k = 64,
BitStrLen = 7 indicates k = 4096.MUST be set to zero by the sender
and MUST be ignored by the receiver. A PCEP speaker supporting BIER-TE paths includes the new PST
and sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TLV.For a PCEP message, when it is used for a BIER-TE path,
the SRP (Stateful PCE Request Parameters) object in the message
MUST include the PATH-SETUP-TYPE TLV defined
in . The TLV MUST contain
the PST = TBD1 for path setup using BIER-TE.Three contiguous bits
in SRP Object Flag Field are defined
to indicate one of the assistant operations
for a BIER-TE path. This three bits field is called AOP
(Assistant Operations).
In addition, the Multicast Flow Specification TLV defined
in
is re-used in the SRP object for indicating
Multicast Traffic.The three bits for AOP are bits 27 to 29
(the exact bits to be assigned by IANA) in
the SRP Object Flag Field.
The values of AOP are defined as follows:
The value of AOP indicates one of the three operations above.
When any of the other values is received,
an error MUST be reported.
When the PCC running on an edge node of a BIER-TE domain
sends the PCE for the domain a PCEP message such as PCRpt
to report that the edge node receives a multicast join,
the message MUST include a SRP object with AOP == 0x001 (J).When the PCC running on an edge node of a BIER-TE domain
sends the PCE for the domain a PCEP message such as PCRpt
to report that the edge node receives a multicast leave,
the message MUST include a SRP object with AOP == 0x010 (L).When the PCE for the domain sends a PCEP message such as
PCReq to another PCE for requesting to find an ingress node
for a BIER-TE path,
the message MUST include a SRP object with AOP == 0x011 (I).For a PCE-Initiated BIER-TE path,
when a PCE sends a PCC a message such as PCInitiate message
to create a BIER-TE path in a BIER-TE domain,
the message MUST contain a Multicast Flow Specification TLV in the
SRP object. The TLV indicates the multicast traffic
that the BIER-TE path will carry.When the PCC running on an edge node of a BIER-TE domain
sends the PCE for the domain a PCEP message
to report that the edge node receives a multicast join or leave
with a multicast group/address and source,
the message MUST contain a Multicast Flow Specification TLV
in the SRP object. The TLV indicates the multicast group by
the multicast group adress and/or multicast source address.When the PCE for a BIER-TE domain sends another PCE
a PCEP message to request for finding an ingress node of
a BIER-TE path,
the message MUST contain a Multicast Flow Specification TLV
in the SRP object. The TLV indicates the multicast source.To represent an ingress node,
a new ingress node object is defined.
The format of the new object
for IPv4 (OT = 1) is as follows:
TBD is to be assigned by IANA. 1 for IPv4. Same as
those defined in Common Object Header
in . Indicates an IPv4
address of an ingress node. Indicates the cost from
the multicast source to the ingress node.
No optional TLV is defined so far.
The format of the new object
for IPv6 (OT = 2) is as follows:
Same as those defined in Ingress Node Object for IPv4. 2 for IPv6. Indicates an IPv6
address of an ingress node.
No optional TLV is defined so far.
defines a mechanism
to specify an objective function (OF) that
is used by a PCE when it computes a path.
For a BIER-TE path, the following new OF is defined.A BIER-TE path is represented by the BitPositions
for the adjacencies through which the path traverses.
A BitPosition is represented by a SI:BitString or a number.
A new subobject, called BIER-TE Path subobject
(or BIER-TE-ERO subobject), is defined to
contain the information about one or more BitPositions.The format of a BIER-TE Path subobject in a ERO is shown
in the figure below.
It indicates whether the
subobject represents a loose-hop in the path. It is to be assigned by IANA.
It identifies the BIER subobject type.It contains the total length of
the subobject in octets. The Length MUST be at least 4.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.It MUST be at least one BitPosition.
For the subobject in a message received from a PCEP session,
the format of the BitPositions in the subobject is determined
by the values of SILen and BitStrLen in the
PCE-BIER-TE-Path-Capability
sub-TLV exchanged during the establishment of the session.
When both SILen and BitStrLen are greater than zero,
each of the BitPositions has two parts SI and BitString,
where SI occupies SILen bits and BitString occupies BitStrLen bits.
When both SILen and BitStrLen are zeros,
each of the BitPositions is a number of 16 bits.
For example, when SILen = 8 and BitStrLen = 1
(indicating BitString is of 64 bits),
each BitPosition has a SI of 8 bits and a BitString of 64 bits.
For simplicity, BitString of 8 bits is used below.
The BitPositions for a BIER-TE path are sorted in
descending order before they are put into a BIER-TE
path subobject.
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 BIER-TE path subobject in the figure below. The path uses
four BitStrings of 8 bits.
The ERO defined in may contain
a BIER-TE Path subobject for the BitPositions of a
BIER-TE path.
The BitPositions in the BIER-TE Path subobject for the BIER-TE
path MUST be in descending order.
When an ERO contains one or more BIER-TE Path subobjects for
a BIER-TE path, the ERO MUST NOT include any other type of
subobjects (i.e., it MUST include only BIER-TE Path subobjects).
The first one is used and the others are ignored.A BIER-TE Path Subobject in a RRO (Record Route Object)
has the same format
as a BIER-TE Path subobject in a ERO except for L flag.
The former does not have L flag.
The format of a BIER-TE Path Subobject in a RRO is
shown in the firgure below.
A PCC may send a PCE a message such as a PCRpt message
defined in .
The message contains a RRO with one BIER-TE Path subobject
having the BitPositions for the actual BIER-TE path that is used
to transport the traffic in the BIER-TE domain.
The BitPositions in the BIER-TE Path subobject for the BIER-TE path
MUST be in descending order.This section describes the procedures related to
a BIER-TE path.For PCC-Initiated BIER-TE path, a PCC MUST delegate the path
by sending a path computation
report (PCRpt) message with its demanded
resources to a stateful PCE.
Note the PCC MAY use the PCReq/PCRep before delegating.Upon receiving the delegation via PCRpt message, the
stateful PCE MUST compute a path based on the network resource
availability stored in the TED.The stateful PCE will send a PCUpd
message for the BIER-TE path to the PCC.
The stateful PCE MUST update its local LSP-DB and
TED and would need to synchronize the
information with other PCEs in the domain. For PCE-Initiated BIER-TE path, the stateful PCE MUST compute a
BIER-TE path per request from network management
systems or applications automatically based on the network
resource availability in
the TED and send a PCInitiate message with the
path information to the PCC.
After receiving the PCInitiate message,
the PCC creates the BIER-TE path.
For both PCC-Initiated and PCE-Initiated BIER-TE paths:The stateful PCE MUST update its local LSP-DB
and TED with the paths.Upon receiving the PCUpd message or PCInitiate message for the
path from the PCE with a found path, the PCC determines that it is a
BIER-TE path by the PST = TBD1 for path setup using BIER-TE
in the PATH-SETUP-TYPE TLV of the SRP object
in the message.After a BIER-TE path is created in a BIER-TE domain,
when some network events such as a node failure happen
on the path (called old path) or a leaf/egress joins/leaves,
the PCE computes a new BIER-TE path and
replaces the old path with the new path.
The new path satisfies the same constraints as
the old path.The PCE sends a PCUpd message to the PCC running on
the ingress node. The message contains the information
about the new BIER-TE path.
After receiving the message, the PCC overwrites (or replaces)
the BIER-TE path with the new BIER-TE path.For a BIER-TE path that has been created in a BIER-TE domain,
after receiving a request for deleting the path from
a user or application, the PCE MUST send a PCInitiate or PCUpd
message to the PCC running on the ingress node of the path
to remove the path.The Path Computation State Report (PCRpt) message is a PCEP
message sent by a PCC to a PCE to report the status of one
or more LSPs, as per .
Each LSP State Report in a PCRpt message contains the
actual LSP's path, bandwidth, operational and administrative
status, etc. An LSP Status Report carried in a PCRpt message
is also used in delegation or revocation of control of an
LSP to/from a PCE. In the case of a BIER-TE path, a
PATH-SETUP-TYPE TLV with PST = TBD1 for path setup using BIER-TE
MUST be carried in the SRP object in the PCRpt message.
A BIER-TE path in the message is represented
by a BIER-TE path subobject.In addition, a PCRpt message is sent from the PCC running on
an edge node to the PCE to report that
the edge node as leaf/egress joins/leaves to/from a multicast
group and source.
The Path Computation Update Request (PCUpd) message is a
PCEP message sent by a PCE to a PCC to update LSP parameters
on one or more LSPs, as per .
In the case of a BIER-TE path, a
PATH-SETUP-TYPE TLV with PST = TBD1 for path setup using BIER-TE
MUST be carried in the SRP object in the PCUpd message.
Each BIER-TE path Update Request in a PCUpd message
contains all parameters that a PCE wishes to be set
for a given BIER-TE path.
A BIER-TE path in the message is represented
by a BIER-TE path subobject.The LSP Initiate Request (PCInitiate) message is a PCEP
message sent by a PCE to a PCC to trigger LSP instantiation
or deletion, as per .
In the case of a BIER-TE path, a
PATH-SETUP-TYPE TLV with PST = TBD1 for path setup using BIER-TE
MUST be carried in the SRP object in the PCInitiate message.
A BIER-TE path in the message is represented
by a BIER-TE path subobject.
The multicast packets to be transported by the BIER-TE path is
specified by the Multicast Flow Specification TLV included
in the SRP object.
The Path Computation Request (PCReq) message is a PCEP
message sent by a PCC to a PCE to request a path computation
, and it may
contain the LSP object
to identify the LSP for which the
path computation is requested.
In the case of a BIER-TE path, a
PATH-SETUP-TYPE TLV with PST = TBD1 for path setup using BIER-TE
MUST be carried in the SRP object in the PCReq message.In addition, a PCReq message is sent from the PCE (as a PCC)
for the BIER-TE
domain to another PCE for the domain that may contain the
multicast source for a BIER-TE path in order to find an ingress
node for the BIER-TE path.
The Path Computation Reply (PCRep) message is a PCEP message
sent by a PCE to a PCC in reply to a path computation request
, and
it may contain the LSP object
to identify the LSP for which
the path is computed. A PCRep message can contain either
a set of computed paths if the request can be satisfied or
a negative reply if not. A negative
reply may indicate the reason why no path could be found.
In the case of a BIER-TE path, a
PATH-SETUP-TYPE TLV with PST = TBD1 for path setup using BIER-TE
MUST be carried in the SRP object in the PCRep message.
Each of the computed paths in the message is represented
by a BIER-TE path subobject.In addition, a PCRep message is sent from the PCE for the domain
that may contain the
multicast source for a BIER-TE path to the PCC (i.e., the PCE
for the BIER-TE domain) in response to the request for finding
an ingress node for the BIER-TE path.
A PCRep message can contain either
a set of ingress nodes represented by ingress node objects
if the request can be satisfied or
a negative reply if not.
IANA is requested to allocate a new code point
within registry "PCEP Path Setup Types"
under "Path Computation Element Protocol (PCEP)
Numbers" as follows:
IANA is requested to allocate a new code point within registry
"PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators"
under "Path Computation Element Protocol (PCEP) Numbers"
as follows:
IANA is requested to allocate the following bits
in the "SRP Object Flag Field" subregistry
under the "Path Computation Element Protocol (PCEP) Numbers"
registry:
IANA is requested to allocate the following Object-Class Value
in the "PCEP Objects" subregistry
under the "Path Computation Element Protocol (PCEP) Numbers"
registry:
IANA is requested to allocate the following Objective
Function Code Points
in the "Objective Function" subregistry
under the "Path Computation Element Protocol (PCEP) Numbers"
registry:
This document defines a new subobject,
called PCE BIER-TE Path (or BIER-TE-ERO) subobject, for PCEP ERO object.
It also defines a new subobject,
called PCE BIER-TE Path (or BIER-TE-RRO) subobject, for PCEP RRO object.
The code points of the subobjects for the objects are
maintained under ERO and RRO objects
in the RSVP Parameters registry.IANA is requested to allocate a code point
under "Subobject type - 20 EXPLICIT_ROUTE - Type 1 Explicit Route"
within registry "Resource Reservation Protocol (RSVP) Parameters"
for PCEP BIER-TE path subobject as follows:
IANA is requested to allocate a code point
under "Subobject type - 21 ROUTE_RECORD - Type 1 Explicit Route"
within registry "Resource Reservation Protocol (RSVP) Parameters"
for PCEP BIER-TE path subobject as follows:
TBDThe authors would like to thank Dhruv Dhody,
and others
for their comments to this work.