Abstract Hops for MPLS LSPs Overview

 

An abstract hop is a logical combination of the existing traffic engineering constraints, such as administrative groups, extended administrative groups, and Shared Risk Link Groups (SRLGs), which results in a user-defined group or cluster of routers that can be sequenced and used as constraints for setting up an MPLS label-switched path (LSP). Abstract hops overcome the limitations of existing path constraint specifications and provide several benefits to the traffic engineering capabilities of MPLS.

Understanding Abstract Hops

The path constraint for setting up of an MPLS LSP can be specified as either individual routers in the form of real hops or as a set of routers by way of administrative group or color specification. When a path constraint uses real hops (strict or loose), the LSP is set up along a specified sequence of routers (for example, R1, R2, … Rn). When a path constraint uses an administrative group or color specification, a group of routers that meet the specified criteria is used to set up the LSP without picking a specific router, and unlike real-hop constraint, there is no sequence among the different groups of routers used in the constraint.

The drawback of real-hop constraint is that in a failure scenario, if any of the router hops goes down or the bandwidth utilization of the attached interface gets saturated, the path goes down (or relies on local or end-to-end protection). Although other alternative routers might be available to recover or set up the LSP, the LSP remains down until the operator configures another router hop sequence as the path constraint to bring the path up again or to disengage the protection path.

The administrative group or color specification constraint overcomes this limitation of a real-hop constraint to a certain extent. Here, when one of the routers in the group goes down or has its link capacity saturated, setting up of the LSP is not affected. This is because the next hop router to be used in the path constraint is not picked beforehand, and the LSP is set up along other routers that have the same administrative group or color without operator intervention. However, the drawback with router group constraints is that a sequence cannot be specified among the hop constraints.

Abstract hops overcome these drawbacks by creating user-defined router groups, where each member router meets a user-defined constraint. The user-defined constraint is a logical combination of the existing traffic engineering constraints, such as administrative groups, extended administrative groups, and Shared Risk Link Groups (SRLGs). Ordering is achieved among the router groups by specifying a sequence of abstract hops used in a path constraint. As a result, abstract hops combine the ordering property of real-hop constraint specification and the resilience that comes with the other traffic engineering constraints.

A path can use a combination of real and abstract hops as constraints. When using abstract hops, instead of specifying a sequence of routers (R1, R2, … Rn) as with real hops, you specify an ordered set of router groups or abstract hops (G1, G2, … Gn) as the path constraint. Each specified router group, Gi for example, consists of some user-defined set of routers—R1, R2, Rj, … Rn. When one of the routers in the group goes down, say Router Rj in group Gi, another router, say Router Rk, from the same group Gi is picked up by path computation to replace the router that went down (that is, Router Rj). This is because the path constraint is sequenced and has to go through a sequence of abstract hops, instead of a sequence of individual routers.

Benefits of Using Abstract Hops

Abstract hops are user-defined router groups. Similar to real-hop constraints that use a sequence of individual routers, a sequence of abstract hops can be used for setting up a label-switched path (LSP). The use of abstract hops provides resiliency to sequenced path constraints. The other benefits of using abstract hops include:

Specifying a Sequence of Constraint Combinations

Currently, it is possible to specify a path that can go through links that satisfy multiple attributes. Such a path constraint is called a compound constraint combination; for example, a constraint (Ci) that includes low latency links of green color and also excludes SRLG north.

However, there is no support for specifying a path with a sequence of compound constraint combinations. For example, a sequenced constraint (C1, C2, Ci, …Cn) that includes low latency green links, no latency blue links, and then low latency red links.

The need for such a sequenced compound constraint combination arises when there is a requirement to establish paths through a sequence of geographical regions with a different link affinity (attributes) requirement in each region. Abstract hops meet this requirement by allowing computing nodes to map each constraint combination (Ci, for example) with the user-defined group of routers—that is, the abstract hops.

Avoiding New Network Configuration on Transit Nodes

With current path constraint specification capabilities, it is possible to include or exclude links of certain attributes along an entire path; for example, excluding SRLG west from a path. However, there is no support to either conditionally exclude or include attributes, or to apply different exclude or include attributes in different parts of the path; for example, excluding SRLG west only when traversing red links.

As a workaround, a new administrative group can be created to identify all such red links that do not have SRLG west, and configure all the relevant links appropriately with that administrative group. The drawback of this approach is that configuration changes are required throughout the network to reflect the new administrative group membership.

Instead, by using abstract hops, the configuration changes can be contained on the ingress router only. At the ingress router, the constraint combination is mapped to the abstract hop, thereby meeting the aforementioned requirement without the need for any new configuration on the transit nodes.

Combining Centralized and Distributed Path Computation Paradigms

Traffic engineering of MPLS paths can be achieved by distributed computing or with a centralized controller for computing paths. A combination of both the computation types is called the hybrid computation paradigm. The key feature of the hybrid computation approach is the ability of the centralized controller—referred to as a Path Computation Element (PCE)—to loosely specify the path computation directives, per path, to the ingress router—referred to as a Path Computation Client (PCC)—and the ability of the ingress router to use it as input for path computation.

A sequence of abstract hops serves the purpose of acting as the guideline from the centralized controller. Abstract hops provide the flexibility to the controller to weave into the path constraint and attributes. This also enables the controller to build in the element of sequence in the constraint. The controller does not have to specify each hop the path needs to take, leaving room for the ingress router to act within the limits of the guideline or directive.

Table 1 lists the key features of the hybrid computation paradigm and provides a comparison of this approach with the current path computation methods.

Table 1: Hybrid Computation for Abstract Hops

Features

Distributed Constrained Shortest Path First

Centralized Constrained Shortest Path First

Hybrid Constrained Shortest Path First

React to frequent changes in a large network

Yes

 

Yes

Sophisticated path computation with global view

 

Yes

Yes

Incorporation of business logic in path computation

 

Yes

Yes

Resilience (no single point of failure)

Yes

 

Yes

Predictability

 

Yes

Yes

React to network load in (close to) real time

Yes

 

Yes

Field tested (versus early adoption)

Yes

 

Yes

Junos OS Implementation of Abstract Hops

The order-aware abstract hops feature is introduced in Junos OS Release 17.1. The following sections describe the implementation of abstract hops in Junos OS:

Defining Abstract Hops

An abstract hop is a group of routers that users can define to be used in setting up a label-switched path (LSP). The user can control which routers to include in the group by defining a logical combination of heterogeneous link attributes or constraints called constituent attributes. The routers with links that satisfy the defined constituent attributes make it to the group of routers representing the abstract hop.

The mapping of constituent attributes with the abstract hop is local to the computing node or the ingress of the LSP being setup. As a result, abstract hops do not have associated interior gateway protocol updates or signaling protocol extensions, and implementing abstract hops in a network does not require new configuration on the transit nodes.

A constituent list enables defining of a set of constituent traffic engineering attributes, that is identified by a user-defined name. Constituent lists are used in an abstract hop definition by using any of the following configuration statements:

  • include-any-list—Link satisfies the constituent-list if any of the specified constituent attributes are true for the link.

  • include-all-list—Link satisfies the constituent-list if all the specified constituent attributes are true for the link.

  • exclude-all-list—Link satisfies the constituent-list if none of the specified constituent attributes are true for the link.

  • exclude-any-list—Link satisfies the constituent-list if at least one of the specified constituent attributes is not true for the link.

An abstract hop is defined as a logical combination of constituent-list references that can belong to any of the aforementioned categories. To achieve this, logical operators AND and OR are included in the abstract hop definition, and applied to the constituent list.

  • OR—At least one of the constituent-list references in the abstract hop definition must be satisfied by a link for the attached node to be part of the abstract hop.

  • AND—All of the constituent-list references in the abstract hop definition must be satisfied by a link for the attached node to be part of the abstract hop.

Sample Abstract Hop Definition

Taking as an example, the definition of abstract hops hopA is as follows:

Abstract hops hopA must include all routers whose emanating links satisfy the logical combination of the following link attributes, respectively:

  • hopA—((administrative group red && Srlg south) || (administrative group green || Srlg north)), where:

    • administrative group red and Srlg south belong to include-all constituent list (listA1, in this example).

    • administrative group green and Srlg north belong to include-any constituent list (listA2, in this example).

    • || is the OR operator.

The configuration for abstract hops hopA is as follows:

  • hopA configuration

Verifying Abstract Hop Configuration

The show mpls abstract hop membership <abstract hop name> command is used to view members of an abstract hop. The command output provides the abstract hop to traffic engineering database node mapping.

user@host> show mpls abstract-hop-membership

Here, the output field Credibility indicates the credibility associated with interior gateway protocol in use.



The output of the show ted database extensive local command provides the view captured in traffic engineering database. A keyword local is added to indicate that the output would include any local instrumentation. The command output shows the abstract hop as an attribute of links that satisfy the associated logical combination of link attributes.

user@host> show ted database extensive local

Abstract hop hopA is for low latency AND SRLG west, and abstract hop hopB is for excluding SRLG west. Figure 1 displays the ingress view of these abstract hops.

Figure 1: Ingress View of Abstract Hops
Ingress View
of Abstract Hops

Using Abstract Hops in Path Constraint

The user associates a unique identifier with each abstract hop definition. This identifier is used for referring to the abstract hop in the path constraint. A sequence of abstract hops can be specified as the path constraint, similar to how real IP hops are used. The path constraint could also be a sequence of abstract hops interleaved by real IP hops.

Using abstract hops or real hops in a path constraint requires more than one Constrained Shortest Path First pass to the destination, typically one pass per hop. When real hops are provided as the path constraint, the constraint computation involves as many passes as the number of hops in the path constraint, where each pass ends on reaching a hop in the constraint list. The starting point for each pass is the destination of the previous pass, with the first pass using the ingress router as the start.

Alternatively, when path constraint uses strict or loose abstract hops, constraint computation comprises passes where each pass processes the subsequent abstract hop in the constraint list. In such a case, more than one node qualifies to be the destination for the pass. The set of nodes is called the viable router set for the pass.

An abstract hop traverses member nodes by using the following:

  • Links that satisfy the logical combination of defined constituent attributes

  • Any kind of links

The means of abstract hops traversing the member nodes is controlled by the use of the abstract hop qualifiers—strict, loose, and loose-link—in defining the path constraint. Taking for example, abstract hop hopA is processed differently with different qualifiers:

  • Strict—After the last processed hop in the constraint list, the path traverses only links or nodes having membership of abstract hop hopA, before reaching a node with hopA’s membership that is a feasible starting point for processing the next abstract hop.

  • Loose—After the last processed hop in the constraint list, the path can traverse any real nodes that do not have abstract hop membership of hopA, before reaching a node with abstract hop membership hopA, which is a feasible starting point for processing the next abstract hop.

  • Loose-link—After the last processed hop in the constraint list, the path can traverse any real nodes that do not have abstract hop membership of hopA, before reaching a node with abstract hop membership hopA, which is a feasible starting point for processing the next abstract hop. But the path should have traversed at least one link of abstract hop hopA membership in the course of the same.

    In other words, the abstract hop of type loose-link is said to be processed only if any of the viable routers in the constraint is reachable through a link of associated abstract hop membership.

Sample Abstract Hops Specification

Table 2 provides sample use case for using abstract hops in path constraints.

Table 2: Using Abstract Hops in Path Constraints

Purpose of Path Constraint

Abstract Hop Qualifier

Configuration

Viable Router Set

Affinity

Traverse nodes that are members of hopA taking only links that satisfy hopA.

Strict

[edit protocols mpls]
Path path_hopA_s {
hopA abstract strict;
}

All members of abstract hopA. That is, A1, A2…An.

hopA (pick only links that satisfy abstract hopA).

Traverse nodes that are members of hopA but not necessarily links that satisfy hopA

Loose

[edit protocols mpls]
Path path_hopA_l {
hopA abstract loose;
}

All members of abstract hopA. That is, A1, A2…An.

None (any kind of links).

Traverse nodes that are members of hopA by taking at least one link that satisfies hopA.

Loose-link

Note: The loose-link qualifier is viewed as loose followed by strict for the same abstract hop. In other words, hopA loose-link is the same as hopA loose and hopA strict.

[edit protocols mpls]
Path path_hopA_ll {
hopA abstract loose-link;
}

In this case, there are two computation passes associated with hopA in the path constraint. The viable router set for both passes is:

All members of abstract hopA. That is, A1, A2…An.

Note: During path computation, a router is traversed only once.

In this case, there are two computation passes associated with hopA in the path constraint. The affinity for the two passes is:

  • Pass 1—None (any kind of links).

  • Pass 2—hopA (pick only links that satisfy abstract hopA).

Traverse nodes that are members of hopA, taking only links that satisfy hopA, followed by nodes that are members of hopB taking only links that satisfy hopB.

Strict

[edit protocols mpls]
Path path_hopA_hopB_s {
hopA abstract strict;
hopB abstract strict;
}
  • hopA—Intersection of member set of hopA and hopB.

    Note: When an abstract hop is followed by a strict abstract hop, the intersection of the two member sets is considered as viable router set.

  • hopB—All members of abstract hopB. That is, B1, B2…Bn.

  • hopA—hopA (pick only links that satisfy abstract hopA).

  • hopB—hopB (pick only links that satisfy abstract hopB).

Traverse nodes that are members of hopA taking only links that satisfy hopA, followed by nodes that are members of hopB taking any kind of links.

Strict and loose

[edit protocols mpls]
Path path_hopA_s_hopB_l {
hopA abstract strict;
hopB abstract loose;
}
  • hopA—All members of abstract hopA. That is, A1, A2…An.

  • hopB—All members of abstract hopB. That is, B1, B2…Bn.

  • hopA—hopA (pick only links that satisfy abstract hopA).

  • hopB—None (pick any links).

Traverse nodes that are members of hopA by taking any kinds of links, followed by nodes that are members of hopB taking any kind of links.

Loose

[edit protocols mpls]
Path path_hopA_l_hopB_l {
hopA abstract loose;
hopB abstract loose;
}
  • hopA—All members of abstract hopA. That is, A1, A2…An.

  • hopB—All members of abstract hopB. That is, B1, B2…Bn.

None (pick any links).

Traverse nodes that are members of hopA by taking any kinds of links, followed by nodes that are members of hopB taking only links that satisfy hopB.

Loose and strict

[edit protocols mpls]
Path path_hopA_l_hopB_s {
hopA abstract loose;
hopB abstract strict;
}
  • hopA—Intersection of the members of hopA and hopB.

    When an abstract hop is followed by a strict abstract hop, the intersection of the two member sets is considered as viable router set.

  • hopB—All members of abstract hopB. That is, B1, B2…Bn.

  • hopA—None (pick any links).

  • hopB—hopB (pick only links that satisfy abstract hopB).

Figure 2 displays path constraints for abstract hops hopA, hopB, and hopC with loose, strict, and loose abstract hop qualifiers, respectively.

Figure 2: Sample Path Constraints for Abstract Hops
Sample
Path Constraints for Abstract Hops

The Constrained Shortest Path First passes for the abstract hops are as follows:

  • Pass 1 associated with hopA

    • Viable routers—Routers R1 and R2 (intersection of hopA and hopB, as hopB is a strict abstract hop).

    • Affinity—None (as hopA is loose).

  • Pass 2 associated with hopB

    • Viable routers—Routers R1, R2, R3, and R4

    • Affinity—Pick only hopB-compliant links (as hopB is a strict abstract hop).

  • Pass 3 associated with hopC

    • Viable routers—Routers R5, R6, R7, and the egress router.

    • Affinity—None (as hopC is a loose abstract hop).

Path Computation and Backtracking

In each Constrained Shortest Path First pass, when the nearest router from a viable router set is reached using links satisfying the affinity figured for the pass, the abstract hop associated with the pass is said to be processed. The viable router thus reached serves as the start for the next constraint pass. If any constraint pass fails, and it is not the one with the ingress router as start router, then the pass is backtracked to the previous pass and the process is repeated.

Sample Backtracking

When a Constrained Shortest Path First pass p (other than the first one) fails, the exit router of the previous pass (p – 1) that served as start for the current pass p is disqualified in the viable router set of the previous pass (p – 1). Then the previous pass (p – 1) is re-executed to find the next best exit router or destination for the pass p – 1 from the viable router set.

The router thus determined serves as the new start router for the pass p. This procedure is repeated as long as there are failures and there are viable routers that are not explored.

The show mpls lsp abstract-hop-computation name lsp-name command provides the various computation passes involved per LSP and the qualifying exit routers for each pass. The command output also gives the affinity per pass, and shows the current start router chosen for the pass. For each viable router, the state of backtracking is displayed, where it can be either valid or disqualified.

user@host> show mpls lsp abstract-computation

The output field Credibility indicates the credibility associated with the interior gateway protocol in use.