PCE for BIER-TE Path

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 Element PCE communication Protocol Path Computation Client Customer Edge Provider Edge Bit 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.

Objective Function Code: TBD8 Name: Minimum Bit Sets (MBS) Description: Find a path represented by BitPositions that has the minimum number of bit sets.

Objective Function Code: TBD9 Name: Minimum Bits (MB) Description: Find a path represented by BitPositions that has the minimum bit distance. The bit distance of BitPositions is the distance from the lowest bit to the highest bit in BitPositions.

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:

+==========+=============================+=================+ | Value | Description | Reference | +==========+=============================+=================+ | TBD1 (2) | Path is setup using BIER-TE | This document | +----------+-----------------------------+-----------------+

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:

+===========+=============================+=================+ | Value | Meaning | Reference | +===========+=============================+=================+ | TBD2 (1) | PCE-BIER-TE-Path Capability | This document | +-----------+-----------------------------+-----------------+

IANA is requested to allocate the following bits in the "SRP Object Flag Field" subregistry under the "Path Computation Element Protocol (PCEP) Numbers" registry:

+=========+===============================+=================+ | Value | Description | Reference | +=========+===============================+=================+ | 27-29 | Assistant Operations for Path | This document | +---------+-------------------------------+-----------------+

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:

+============+=============================+=================+ | Code Point | Name | Reference | +============+=============================+=================+ | TBD8 (18) | Minimum Bit Sets (MBS) | This document | +------------+-----------------------------+-----------------+ | TBD9 (19) | Minimum Bit Distance (MBD) | This document | +------------+-----------------------------+-----------------+

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:

+===========+=============================+=================+ | Value | Name | Reference | +===========+=============================+=================+ | TBDa (63) | PCEP BIER-TE Path | This document | +-----------+-----------------------------+-----------------+ 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:

TBD

The authors would like to thank Dhruv Dhody, and others for their comments to this work.