Bidirectional Metric based Shortest Path First Mechanism

IGP SPF algorithm is computed based on the link metric value in each direction. If the metric value of the link in each direction is different at the two endpoints of the link, the forward and return path of one service may be different. This can cause the difficult to identify, control or QoS assurance for the specified services. And, for intra-domain source address validation(SAV mechanism) deployment, if the operator can assure there is no asymmetric path existing within its network, it will be easier for them to deploy the intra-domain SAV mechanism. But, there is no easy way to find the inconsistent settings of the bidirectional metric value of one link. There are also other scenarios that described in and that the operator wants to set the metric value of a link in one end to influence the traffic from the other ends. Reverse metric mechanism is one valid solution in some scenarios but it is not one general solution for other similar situation. This document proposes one general solution that can solve the above problems, which utilizes the bidirectional metric values during the SPF calculation to make sure the bidirectional traffic of one service always follow the same path, regardless of the metric values setting of a link in each direction. It can also get the effect of setting the metric value in one end to influence the traffic to and from the node in both directions.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

IS-IS, OSPF and OSPFv3 describes the basic process for calculating the shortest path between two endpoints in the IGP domain. The link metric is used to represent the output cost of the interface. Normally, such metric is set based on the link capacity and in current network, there is seldom situation that the bidirectional capacity of the link are different. It is possible to require the both endpoints of the link to set the same value for the metric value, but there is no easy way to assure this. To solve such problem, this document proposes the bidirectional metric based SPF calculation procedures as the followings: 1) The configured link metric is advertised as the normal process. 2) When the IGP neighbors are formed, the cost to each other are set to the maximum value of advertised link metric to each other. 3) The calculated value is stored in the LSDB and then the normal SPF calculation process will be applied. After the above procedures, the bidirectional route for one any service will be assured to follow the same path. There are also other benefits that such mechanism can afford, which are described in the followings sections.

This section described the application of BM-SPF mechanism in various scenarios.

Figure 1 illustrates one example that the inconsistence forwarding and return path will be emerged when the bidirectional metric values are different. Based on the value on the link metric, the traffic from R1 to R4 will follow R1-R2-R4 path, but the return traffic will follow R4-R3-R1.

Based on the BM-TE mechanism described in , the maximum value of the bidirectional link metric between each neighbor will be used to calculate the shortest path to each endpoint. The actual used values are shown in the Figure 2. It is obviously that the traffic from R1 to R4 and the return traffic from R4 to R1 will all follow the same path, as R1, R2, R4.

Figure 3 illustrates the situation that when the interface from R1 to R2 is in abnormal state and needs to be maintained, the operator can change the configured metric value on R1 for this interface to higher or the maximum value, and let the traffic from R1 to R2 switch to other link, for example, R1-R3-R2. But just doing so can't divert also the incoming traffic from R2 to R1 at the same time, thus the incoming traffic will be dropped during the maintenance period. Based on the BM-SPF mechanism, the configured higher value of the two directional metric will be used in the SPF calculation. Then the traffic from R2 to R1 will be diverted simultaneously when the operator increase the metric value on the R1.

In LAN environment described in Figure 4. If the bidirectional metric value are different in each side, there is no way to differentiate the metric for each pairs of the communication peers. For example, from the viewpoints of the R1, the cost 5 will be used to reach all of its peers on the LAN, and from the viewpoint of the R2, the cost 8 will be used to reach all of its peers on the LAN. Based on the BM-SPF mechanism, the cost for each pair can be different. For example, from the viewpoint of the R1, the cost 8 will be used to reach R2, the cost 10 will be used to reach R3 and the cost 12 will be reached to reach R4. The situation will be same for R2. It is easy to accomplish the UCMP traffic engineering effect among their neighbor based on the BM value. For R4, the same value will be used to reach each of its communication peer, and traffic from it will be distributed evenly to its neighbors.

To assure the consistence and determined behaviors within the network, it is necessary to assure the nodes have the same capabilities to support BM-SPF. The router should announce such capability within the IGP domain. For IS-IS, one bit(BM bit, 0x04) from the Flags field of IS-IS Router CAPABILITY TLV is assigned. For OSPFv2, one bit (BM bit, 0x20) from the OSPF Option field is assigned For OSPFv3, one bit(BM bit, 0x08) from the OSPF Option field is assigned BM bit: When BM bit is set, it indicates that the maximum value of the bidirectional metrics of a link between the neighbors will be used to calculate the SPF path to each peer. When BM bit is clear, it indicates that the configured metric on each end of the link will be used to calculate the path.

The BM-SPF mechanism can be deployed incrementally. If the neighbor doesn't support the BM-SPF capabilities, the metric value configured on the interface should be used instead.

Security concerns for ISIS are addressed in and Security concern for OSPFv3 is addressed in Advertisement of the additional information defined in this document introduces no new security concerns.

IANA is requested to the allocation in following registries:

TBD