PCEP Extensions for BIER

defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional list of sub-TLVs which are intended to convey parameters that are associated with the path setup types supported by a PCEP speaker. This document defines a new Path Setup Type (PST) for BIER as follows: PST = TBD2: Path is setup using BIER Traffic Engineering technique. A PCEP speaker SHOULD indicate its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PST included in the PST list. This document also defines the BIER-TE-PCE-CAPABILITY sub-TLV. PCEP speakers use this sub-TLV to exchange BIER capability. If a PCEP speaker includes PST=TBD1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the BIER-TE-PCE- CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. The format of the BIER-TE-PCE-CAPABILITY sub-TLV is shown in the following figure:

The code point for the TLV type is to be defined by IANA. Length: 4 bytes. The "Reserved" (2 octet) and "Flags" (2 octet) fields are currently unused, and MUST be set to zero on transmission and ignored on reception.

In order to setup an BIER-TE, a new PATH-SETUP-TYPE TLV MUST be contained in RP/SRP object. This document defines a new Path Setup Type (PST=TBD2) for BIER-TE.

The END-POINTS object which is defined in is used in a PCReq message to specify the BIER information of the path for which a path computation is requested. To represent the end points for a BIER path efficiently, we reuse the P2MP END-POINTS object body for IPv4(Object-Type 3) and END-POINTS object body for IPv6 (Object-Type 4) which is defined in .

In the case of BIER and BIER-TE coexistence scenario, we reuse the BFR-id where is assigned For each sub-domain to which a given BFR belongs, if the BFR is capable of acting as a BFIR or a BFER, it MUST be provisioned with a "BFR-id" that is unique within the sub-domain which is defined in , so in this scenario, we define a new BIER END-POINT Object.It is optional. The format of the new END-POINTS Object for BFR-id is as follows:

leaf type: It is the same with the type which is defined in . Source BFR-id:A 2 octet field encoding the source BFR-id, A BFR-id is just a number in the range [1,65535], identifies a BFIR uniquely in a BIER subdomain.If no BFR-id has been assigned, the value of this field is set to "Invalid BFR-id", which is defined as illegal in . Destniation BFR-id:A 2 octet field encoding the destniation BFR-id.A BFR-id is just a number in the range [1,65535], identifies a BFER uniquely.If no BFR-id has been assigned, the value of this field is set to "Invalid BFR-id", which is defined as illegal in .

BIER-TE consists of one or more adjacencies BitStrings where every BitPosition of the BitString indicates one or more adjacencies, as described in(). The ERO object specified in is used to encode the path of a TE LSP through the network.The ERO is carried within a PCRep message to provide the computed TE LSP if the path computation was successful.In order to carry BIER-TE explicit paths, this document defines a new ERO subobjects referred to as "BIER-ERO subobjects" whose formats are specified in the following section. An BIER-ERO subobjects carrying a adjacencies BitStrings consists of one or more BIER-ERO subobject(s).

The 'L' Flag: Indicates whether the subobject represents a loose-hop in the LSP. If the bit is not set, the subobject represents a strict hop in the explicit route. Type: TBD4 Length: 1 octet (). Contains the total length of the subobject in octets. The Length MUST be at least 8, and MUST be a multiple of 4. BS Length: A 1 octet field encodes the length in bits of the BitString as per , the maximum length of the BitString is 5, it indicates the length of BitString is 1024.It is used to refer to the number of bits in the BitString. subdomain-id: Unique value identifying the BIER subdomain. 1 octet. SI: Set Identifier (Section 1 of used in the encapsulation for this BIER subdomain for this BitString length, 1 octet. The "Reserved" (1 octets) fields are currently unused, and MUST be set to zero on transmission and ignored on reception. Adjacency BitString: a variable length field encoding the Adjacency BitString where every BitPosition of the BitString indicates one or more adjacencies.the length of this field is according the BS length. The minimum value of this field is 64 bits, and the maximum value of this field is 1024 bits. Notice: The maximum value of BS Length is limited to the 1024 bits, in case the BIER-ERO Subobject is too long.

The ERO and SR-ERO subobject processing remains as per . If a PCC receives an BIER-ERO subobject in which either BitStringLength or Adjacency BitString or SI is absent, it MUST consider the entire BIER-ERO subobject invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object"), Error-Value = TBD5 ("BitStringLength is absent ") or Error-Value = TBD6 ("Adjacency BitString is absent")or Error-Value = TBD7("SI is absent "). If a PCC receives an BIER-ERO subobject in which BitStringLength values are not chosen from: 64, 128, 256, 512, 1024, as it described in ( ). The PCC MUST send a PCErr message with Error-Type =10 ("Reception of an invalid object") and Error-Value = TBD8 ("Invalid BitStringLength").