How to Enable Link Delay Measurement and Advertising in OSPF
Understanding Link Delay Measurement and Advertising in OSPF
- Benefits of link delay measurement and advertising in OSPF
- Overview of link delay measurement and advertising in OSPF
- Overview of Link Delay Normalization
Benefits of link delay measurement and advertising in OSPF
Link delay measurement and advertising in OSPF provides the following benefits:
- Highly beneficial in certain networks such as stock market data providers, where it is crucial to have access to market data in real-time to make trades faster than the competition. This is where network performance criteria or latency is becoming critical to data-path selection.
- Helps to make path-selection decisions based on performance data (such as latency) in a cost-effective and scalable way.
- Superior alternative to using metrics such as hop count or cost as routing metrics.
Overview of link delay measurement and advertising in OSPF
Network performance is measured by using TWAMP -Light. You can get the measurement of various performance metrics in IP networks, by using probe messages. OSPF Traffic Engineering Extensions helps to distribute network-performance information in a scalable fashion. This information can then be used to make path-selection decisions based on network performance.
Border Gateway Protocol Link-State (BGP-LS) allows BGP to carry link-state information acquired from IGPs, which then allows internet service providers (ISP) to selectively expose the information with other ISPs, service providers, CDNs and so on, through normal BGP peering. New BGP-Link State (BGP-LS) TLVs are defined to carry the IGP Traffic Engineering Metric Extensions.
The following illustration depicts the minimum IGP metric and minimum delay metric in networks that consist a core, metro, and access network.
In this scenario, core network is cheaper but has longer delay. Access shortcut, with lowest latency is expensive. As core network is cheaper, majority of traffic typically go from 1>2>3>4>5> to 6 by using minimum IGP metric. As displayed in scenario a), you can achieve minimum IGP requirement by running OSPF with appropriate cost configured and default OSPF algorithm set to zero. In businesses where ultra-low latency is crucial, packets need to go from 1 to 6. As displayed in scenario b), you can achieve minimum delay metric by defining OSPF flex algorithm with minimum latency, which minimize the delay to the endpoint. This flex algorithm consists only node 1 and node 6.
Overview of Link Delay Normalization
The Delay Normalization feature computes a normalized delay value and uses the normalized value instead of measured delay value. This value is advertised and used as a metric during the flexible algorithm computation. The normalization is performed when the delay is received from the delay measurement component. When the next value is received, it is normalized and compared to the previously saved normalized value. If the values are different, then the LSP generation is triggered.
Delay normalization is disabled by default. To enable and configure delay normalization across IGP instances, use the delay-measurement command.
set protocols ospf area aread interface interface-name delay-measurement normalize interval value offset value
See Also
Configuring OSPF Link Delay and Delay Normalization on an OSPF Interface
In IP networks, the bulk of traffic often goes through the core network, which reduces costs but might result in increased latency. Business traffic, however, often benefits from the ability to make path-selection decisions based on other performance metrics, such as path latency, rather than relaying on the traditional path optimization based simply on IGP metrics. Optimizing a path to reduce latency can greatly benefit applications like real-time voice and video. It can also enable high performance access to financial market data where milliseconds can translate into significant gains or losses.
You can enable OSPF link delay in IP networks. You can achieve minimum IGP metric paths by configuring OSPF with the appropriate link cost using the default OSPF algorithm. Doing so optimizes paths to the endpoint that are based strictly on the sum of the link metrics. By using the OSPF delay flex algorithm you can optimize paths based on their end-to-end delay.
Link delay can be dynamically measured using Two-Way Active Measurement Probes (TWAMP). The routers then flood their link delay parameters. The routers in the area store these parameters in the shared Link State Database (LSDB). Ingress nodes run an SPF algorithm against the LSDB to compute paths that are optimized on various attributes, such as link colors, IGP metric, traffic-engineering (TE) metric.
To configure link delay measurement for an OSPF Interface:
To configure delay metric for an OSPF Interface:
[edit protocols ospf area 0.0.0.0 interface ge-0/0/0.0] user@host#set delay-metric microseconds
For example:
[edit protocols ospf area 0.0.0.0 interface ge-0/0/0.0] user@host#set delay-metric 20000
Enter commit from the configuration mode.
To verify your configuration results, use the show protocols operational
command.
user@host# show protocols
ospf {
area 0.0.0.0
interface ge-0/0/0.0 {
delay-measurement {
advertisement {
accelerated {
threshold 100;
}
periodic {
interval 35;
threshold 100;
}
}
probe-count 10;
probe-interval 100;
}
delay-metric {
20000;
)
}
normalize interval 50 offset 10;
To verify that link delay parameters are present in the OSPF database use the show
ospf database extensive | match delay operational command.
user@host> show ospf database extensive | match delay
Unidirectional link delay: 20000
Min unidirectional link delay: 20000
Max unidirectional link delay: 20000
Unidirectional delay variation: 20000
The output displays the delay of 20000 microseconds that is configured on the interface.
To verify the normalized delay value, use the show ospf interface
extensive operational command.
user@host> show ospf interface extensive
root@R0# run show ospf interface ge-0/0/0.0 extensive Interface State Area DR ID BDR ID Nbrs ge-0/0/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 Type: P2P, Address: 21.0.1.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 1 Unidirectional link delay: 1616 Min unidirectional link delay: 712 Max unidirectional link delay: 8125 Unidirectional delay variation: 2992 Delay Normalization: Enabled (Interval: 50, Offset: 10) Normalized Delay: 860 (Last Normalized: Mon Jul 24 10:03:41)
The output displays that the unidirectional link delay 1616 microseconds has been normalized into a value (860) that OSPF uses in SPF computations for flexible algorithm. Last Normalized: Mon Jul 24 10:03:41 indicates the timestamp of the most recent normalization calculation.
See Also
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.