BGP Request for Candidate Paths of SR TE Policies

A BGP request UPDATE message is based on the update message defined in with some extensions described below.

The SR Policy NLRI defined in has the following format:

where: NLRI Length: 1 octet of length expressed in bits as defined in . Distinguisher: 4-octet value uniquely identifying the policy in the context of <color, endpoint> tuple. The distinguisher has no semantic value and is solely used by the SR Policy originator to make unique (from an NLRI perspective) multiple occurrences of the same SR Policy. Policy Color: 4-octet value identifying (with the endpoint) the policy. The color is used to match the color of the destination prefixes to steer traffic into the SR Policy Endpoint: identifies the endpoint of a policy. The Endpoint may represent a single node or a set of nodes (e.g., an anycast address). The Endpoint is an IPv4 (4-octet) address or an IPv6 (16-octet) address according to the AFI of the NLRI. NLRI Length, Policy Color, Endpoint field remains unchanged, while the Distinguisher field will be set to FF:FF:FF:FF to indicate that the UPDATE message with this NLRI is a request message to the controller.

The content of the SR Policy is encoded in the Tunnel Encapsulation Attribute TLV of type 23 defined in containing a new Tunnel Type TLV of type 15. The SR Policy Encoding structure is as follows:

Attributes: Tunnel Encaps Attribute (23) Tunnel Type (15): SR Policy ]]> Preference, Binding SID, Priority, Policy Name, ENLP, Segment List, Weight and Segment Sub-TLVs are all defined in for a SR Policy to be advertised to a headend. Additional 6 new Sub-TLVs are defined below for the request mechanism. They are SR Path Attributes, Synchronization, Metric, Include Route, Load Balance, and Request Parameters Sub-TLVs.

A SR Path Attributes Sub-TLV contains the attributes of the SR paths requested, which are similar to an LSP Attributes Object defined in and . It is optional and specifies various attributes or constraints of the paths requested. Its format is shown below.

where: Type: TBD1 Length: specifies the length of the value field not including Type and Length fields. Flags (8 bits): No flag is currently defined. Undefined flags MUST be set to zero on transmission and be ignored on receipt. Reserved (8 bits): This field MUST be set to zero on transmission and be ignored on receipt. Exclude-any: A 32-bit vector representing a set of attribute filters associated with a path any of which renders a link unacceptable. Include-any: A 32-bit vector representing a set of attribute filters associated with a path any of which renders a link acceptable (with respect to this test). A null set (all bits set to zero) automatically passes. Include-all: A 32-bit vector representing a set of attribute filters associated with a path all of which must be present for a link to be acceptable (with respect to this test). A null set (all bits set to zero) automatically passes. Optional sub-TLVs: No optional sub-TLV is currently defined.

A Synchronization Sub-TLV allows a headend to request the synchronization of a set of M dependent or independent SR path requests. This TLV is similar to the SVEC Object defined in . It is optional and has the following format.

where: Type: TBD2 Length: specifies the length of the value field not including Type and Length fields. Flags (16 bits): Defines the potential dependency among a set of SR paths (i.e., segment lists). Three flags are defined as follows: L (Link diverse) bit: when set, it indicates that the computed SR paths (i.e., segment lists) MUST NOT have any link in common. N (Node diverse) bit: when set, it indicates that the computed SR paths (i.e., segment lists) MUST NOT have any node in common. S (SRLG diverse) bit: when set, it indicates that the computed SR paths (i.e., segment lists) MUST NOT share any SRLG (Shared Risk Link Group). Request-ID No1, ..., NoM: each of which uniquely identifies one of M SR path requests. In case of M synchronized independent path requests, the bits L, N, and S are set to zero. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.

A Metric Sub-TLV carries the same content as a Metric Object defined in and . It has following format:

Type: TBD3. Length: specifies the length of the value field not including Type and Length fields. Flags (8 bits): Two flags are currently defined: B (Bound - 1 bit): When set, the metric-value indicates a bound (a maximum) for the path metric that must not be exceeded for the headend to consider the computed path as acceptable. The path metric must be less than or equal to the value specified in the metric-value field. When the B flag is cleared, the metric-value field is not used to reflect a bound constraint. C (Computed Metric - 1 bit): When set, it indicates that the controller MUST provide the computed path metric value (should a path satisfying the constraints be found) in the advertisement message for the corresponding metric. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. T (Type - 8 bits): Specifies the metric type. Four metric types are currently defined: T=1: IGP metric T=2: TE metric T=3: Hop Counts T=11: Maximum SID Depth of the requested path Metric-Value (32 bits): It is a metric value encoded in 32 bits IEEE floating point format (see [IEEE.754.1985]).

The Include Route Sub-TLV is optional and can be used to specify that the computed candidate path MUST traverse a set of specified network elements. The Include Route Sub-TLV carries the same content as IRO Object defined in, and SR-ERO defined in The Include Route Sub-TLV has following format:

Where: Type: TBD4. Length: It specifies the length of the value field not including Type and Length fields. NAI Type (NT): It indicates the type and format of the NAI contained, if any is present. If the F bit is set to zero, then the NT field has no meaning and MUST be ignored by the receiver. This document describes the following NT values: NT=0: The NAI is absent. NT=1: The NAI is an IPv4 node ID. NT=2: The NAI is an IPv6 node ID. NT=3: The NAI is an IPv4 adjacency. NT=4: The NAI is an IPv6 adjacency with global IPv6 addresses. NT=5: The NAI is an unnumbered adjacency with IPv4 node IDs. NT=6: The NAI is an IPv6 adjacency with link-local IPv6 addresses. SID and NAI are the same as SR-ERO defined in

A Load Balance Sub-TLV specifies how many SR paths (i.e., segment lists) should be computed for a path request. It has following format:

Where: Type: TBD5. Length: It specifies the length of the value field not including Type and Length fields. Flags (8 bits): No flag is currently defined. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt. Max-Slist (8 bits): It indicates the maximum number of SR paths (i.e., segment lists) to be computed for the request. The load is distributed among these SR paths. Optional sub-TLVs: No Optional sub-TLV is currently defined.

A Request Parameter (RP) Sub-TLV specifies the request identifier and other parameters for a path request. It has the format below.

Where: Type: TBD6. Length: It specifies the length of the value field not including Type and Length fields. Flags (16 bits): Three flag bits are currently defined as follows: R (Reoptimization - 1 bit): when set, it indicates that the SR path request message is for the reoptimization of an existing SR path, which is represented by a segment list Sub-TLV in the message. B (Bi-directional - 1 bit): when set, it indicates that the SR path request relates to bi-directional paths that has the same traffic engineering requirements including fate sharing, TE links, and other requirements (such as latency and jitter) in each direction. O (strict/loose - 1 bit): when set, it indicates that a loose path is acceptable. Otherwise (i.e., when cleared), it indicates that a path exclusively made of strict hops is required.