Traffic Engineering

Note: Traffic Engineering is supported on 7250 IXR and 7730 SXR platforms.
Traffic engineering (TE) is a method for efficiently routing network traffic to maximize throughput and minimize delay.

Without TE, network traffic follows the shortest or most efficient paths calculated by IGP (IS-IS/OSPF) or BGP protocols. These paths, however, disregard link state attributes, including bandwidth utilization, individual link delays, and other real-time network conditions, which can result in congestion.

IGP protocols are extended with new Type Length Values (TLVs) that specify these link and node state attributes. IGP TE extensions are responsible for advertising the TE attributes within the IGP domain. Currently, SR Linux supports only IS-IS extensions for Traffic Engineering (TE).

Uncolored SR-MPLS TE policies define the rules for traffic engineering in an SR-enabled network. See Uncolored SR-MPLS TE-Policy.

SR Linux supports the following features to enable TE within the SR framework:

Configuring TE identifier

SR Linux supports configuring routable IPv4 and IPv6 router addresses to identify the router uniquely in a TE domain.

Configuring an IPv4 TE identifier

--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering ipv4-te-router-id
    network-instance default {
        traffic-engineering {
            ipv4-te-router-id 10.1.1.1
        }
    }

Configuring an IPv6 TE identifier

--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering ipv6-te-router-id
    network-instance default {
        traffic-engineering {
            ipv6-te-router-id 2001:db8::1
        }
    }

Configuring TE interface

The configurable TE interface allows the selection of which interfaces are used for traffic engineering. To configure TE on an interface, use the command network-instance traffic-engineering interface. When TE is enabled, the TE-related Type-Length-Value (TLV) and sub-TLV fields are incorporated into the OSPF Link State Advertisements (LSAs) or IS-IS Link State Packets (LSPs) generated by these IGPs.

Enabling TE on an interface

--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering
    network-instance default {
        traffic-engineering {
            interface srl_test_interface {
            }
        }
    }

Configuring TE using interface-ref

The interface-ref parameter in TE configuration commands allows you to reference an interface or subinterface instead of configuring TE for an interface. Based on the specified interface and subinterface leaves, the interface is uniquely referenced.
--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering interface srl_test_interface interface-ref
    network-instance default {
        traffic-engineering {
            interface srl_test_interface {
                interface-ref {
                    interface ethernet-1/1
                    subinterface 0
                }
            }
        }
    }

Configuring TE metric

Configuring TE metrics for each TE interface influences routing decisions based on network conditions and policies. When the TE metric is selected for an LSP, the shortest path calculation selects the path based on the TE metric instead of the IGP metric after applying the TE constraints. Both the TE and IGP metrics are advertised by IGP protocols for each link in the network. The TE metric is part of the traffic engineering extensions of IGP protocols. SR Linux supports only IS-IS TE extensions and implements the TE metric as defined in RFC 8570. The te-metric value is advertised in sub-TLV (type 18) of the Extended IS Reachability TLV (type 22). 

--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering interface srl_test_interface
    network-instance default {
        traffic-engineering {
            interface srl_test_interface {
                te-metric 564
            }
        }
    }

Configuring TE admin-groups

SR Linux supports Administrative Groups (AGs) as defined in RFC 5305. Administrative groups are manually assigned attributes that describe the color of the links. The administrative group, also referred to as link colors or resource classes, helps to identify and manage links that belong to the same administrative or resource class and is used to implement policy/constraint-based LSPs. Links with the same color are grouped into the same class. The admin-group is advertised in sub-TLV (type 3) of the Extended IS Reachability TLV (type 22). Configuring an admin group for TE interface allows network administrators to classify and control routing decisions based on specific criteria or policies.

Configuring admin-groups

In this example, an admin-group named blue is configured. 

--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering admin-groups
    network-instance default {
        traffic-engineering {
            admin-groups {
                group blue {
                }
            }
        }
    }

Configuring admin-group bit position

The administrative group contains a 4-octet bit mask assigned by the administrator. The bit-position value corresponds to the location of the bit set starting from the least significant bit in the admin-group bit mask. Each set bit corresponds to the administrative group assigned to an interface. An admin-group can be associated with only one bit-position.

In this example, the bit-position two corresponds to the blue admin-group.

--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering admin-groups group blue bit-position    network-instance default {
        traffic-engineering {
            admin-groups {
                group blue {
                    bit-position 2
                }
            }
        }
    }

Associating admin-groups with a TE interface

By associating admin groups to each TE interface, you can identify the groups to which an interface belongs. The IGPs use the group information to construct link-state packets that are flooded throughout the network, providing information to all network nodes. An interface can be associated with multiple admin groups. For information about configuring the TE interface, see Configuring TE interface.

--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering interface srl_test_interface
    network-instance default {
        traffic-engineering {
            interface srl_test_interface {
                te-metric 564
                admin-group [
                    blue
                ]
            }
        }
    }

Configuring Shared Risk Link Groups and SRLG membership

Configuring Shared Risk Link Groups (SRLGs) to group links with common risk factors ensures alternate path selection for reliability. SRLGs allow users to establish a backup secondary label switched path (LSP) or a fast-reroute (FRR) LSP, which is disjoint from the primary LSP. A backup path is an alternative route for network traffic when the primary path becomes unavailable due to network issues. Links that are members of the same SRLG represent resources that share the same risk. In an SRLG, if one link fails, all the other links in that SRLG also fail. For example, sub-interfaces go down if their main interface goes down because of shared risks. SR Linux supports SRLGs as defined in RFC 4205. SRLGs (shared-risk-link-groups) are used to identify the links that belong to the same SRLG. The shared-risk-link-groups is advertised in new Shared Risk Link Group Type Length Values (TLVs) (type 138).

Configuring shared-risk-link-groups

--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering shared-risk-link-groups
    network-instance default {
        traffic-engineering {
            shared-risk-link-groups {
                group gray {
                }
            }
        }
    }

Configuring shared-risk-link-groups value

Each SRLG is represented by a specific group value (value). The group value associated with shared-risk-link-groups uniquely identifies an SRLG. In this example, SRLG group gray is assigned a group value of one.

--{ * candidate shared default }--[  ]--# 
info network-instance default traffic-engineering shared-risk-link-groups group gray
    network-instance default {
        traffic-engineering {
            shared-risk-link-groups {
                group gray {
                    value 1
                }
            }
        }
    }

Associating SRLG membership with a TE interface

An SRLG membership lists all SRLGs associated with the interface. Backup paths are computed based on the SRLG membership information exchanged between routers. Routers avoid using links belonging to the same SRLG when creating backup paths. In this example, the srl_test_interface interface is linked to SRLG membership, which includes the black, gray, and red SRLGs.

--{ * candidate shared default }--[  ]--
# info network-instance default traffic-engineering interface srl_test_interface srlg-membership
    network-instance default {
        traffic-engineering {
            interface srl_test_interface {
                srlg-membership [
                    black
                    gray
                    red
                ]
            }
        }
    }

Advertising link delay with IS-IS

The link delay is an interface attribute described in RFC8570 and is advertised by SR Linux using the Minimum/Maximum Unidirectional Link Delay TLV (type 34).

The static delay represents a forward-path metric, measured in microseconds, between two routers. The static delay can be configured under network-instance traffic-engineering interface with a configurable range of 1 to 16777215 microseconds.

When you configure interface delay for an IGP, the IGP automatically includes the delay TLV34 in its Link State Packet (LSP) when TE extensions are enabled. For more information about configuring an interface delay for an IS-IS instance, see Configuring interface delay. SR Linux supports the configuration of both static and dynamic interface delay measurements. The IGP must determine which of these delay measurments to advertise. There are four potential options for the IGP to consider when deciding between the two delay measurments associated with a particular interface.

Table 1. Interface delay and link delay advertisement
Interface delay Link delay advertised
static Only the statically configured link delay is advertised. If no static delay is configured, the Type 34 TLV is not generated for the link.
static-preferred The IGP advertises the statically configured link delay and defaults to the dynamically measured delay if no static delay is configured. If neither a static delay is configured nor a dynamic delay is reported, the Type 34 TLV is not generated for the link.
dynamic Only the dynamically measured link delay is advertised. If no dynamic delay is reported, the Type 34 TLV is not generated for the link.
dynamic-preferred The IGP advertises the dynamically measured link delay and defaults to the static link delay if no dynamic delay is configured. If neither a static delay is configured nor a dynamic delay is reported, the Type 34 TLV is not generated for the link.

SR Linux supports the advertising of link delay using either the legacy-link-attribute-advertisement or application-specific link attributes (ASLA) encodings, or both. The routers store the link delay parameters in the shared Link State Database (LSDB).

Configuring static delay

The following example shows the configuration of static delay.

--{ * candidate shared default }--[  ]--
# info interface ethernet-1/1 subinterface 0
    interface ethernet-1/1 {
        subinterface 0 {
            admin-state enable
            unidirectional-link-delay {
                static-delay 1234
            }
            ipv4 {
                admin-state enable
                address 192.168.0.0/31 {
                }
            }
            ipv6 {
                admin-state enable
                address 2002::c0a8:0/31 {
                }
            }
        }
    }

Advertising of link delay

In the following config example, the statically configured link delay is advertised.
--{ + candidate shared default }--[  ]--
info network-instance default protocols isis instance srl_test_instance
    network-instance default {
        protocols {
            isis {
                instance srl_test_instance {
                    interface ethernet-1/1.0 {
                        delay {
                            delay-selection static
                        }
                    }
                }
            }
        }
    }
Note: The TE attributes are only supported for Ethernet and LAG interfaces in network instances of type default, not for VPRN.