How does latency-based LSP rerouting work?

Latency-based LSP rerouting

NSP can optimize and reroute LSPs based on live link latency telemetry from TWAMP-light or EthCFM tests on the NE. NSP measures latency per link, and the end-to-end latency of an LSP is assumed to be the sum of the latencies of the links through which it is routed. If the latency of the LSP increases beyond the latency threshold or maximum latency specified in the LSP's path profile policy, NSP will re-signal the LSP, calculate a path with reduced latency, and reroute the LSP. Latency changes to links not on the LSP's path will not immediately trigger a reroute, however, LSPs are re-signaled at regular intervals to ensure that the paths they take are relatively optimal - in terms of latency - at any point in time. When an LSP is routed off its original path due to an increase in latency, it will only return back to its original path if the latency of that path is optimal at the time of the next re-signal. A re-signal can be triggered by:

Note: Changes to latency can make it necessary for many LSPs to be rerouted at once. To reduce the load on NSP - and to potentially reduce LSP reroutes - LSPs that cross their latency threshold constraint are randomly queued for rerouting within a one minute period by default. This may cause a delay in LSP movement after latency thresholds are initially crossed.

Note: A delay may occur between the time the link latency measurement is collected and the time it appears on the link. Link latency updates are throttled in order to prevent excessive noise in large scale setups.

Modes

Note: "modelDriven" latency collection mode should be used for both classic routers and ModelDriven routers as "classic" latency collection mode was deprecated in NSP Release 23.4.

The following API is used to enable latency collection:

PATCH /sdn/api/v4/nsp/configuration/latency

{
  "data": {
  "modelDriven": true,
  }
}

The model-driven option must be enabled in order to collect latency via either the MD-OAM application or the NFM-P (for 7210 and 7705 NEs). To do this, all actions to create, modify, or execute tests must be performed within either the MD-OAM application or the NFM-P (depending on NE type). When results are available for a given test, MD-OAM or NFMP obtain the results, adds all stored test information to the results, and publishes the result to one of the following Kafka topics:

Note: When using modelDriven mode to collect EthCFM latency telemetry from the MD-OAM app, the session mappings must still be defined under ethcfmTests.

Note: If link latency measurements are not being applied on the link automatically, confirm the measurements are being produced to the corresponding Kafka topic above. If the results are showing up on the Kafka topic but not being applied to the link, the session name and IP link mapping must be configured explicitly using the latency configuration API below:

PATCH /sdn/api/v4/nsp/configuration/latency

{
  "data": {
  "twampTests": [
   {
    "session": "<TWAMP-light-session-name>",  // Session name of the TWAMP-Light test
    "source": "x.x.x.x",                       // Source interface IP
    "destination": "x.x.x.x"                  // Destination interface IP
    }
  ]
  "ethcfmTests": [
   {
    "session": "<EthCFM-session-name>",  // Name of CFM Two Way Delay Test
    "source": "x.x.x.x",                 // Source interface IP
    "destination": "x.x.x.x"            // Destination interface IP
   }
  ]
  }
}
Latency timeout

Latency timeout values can be configured using the latency configuration API below:

PATCH /sdn/api/v4/nsp/configuration/latency.

"timeout": {

"enabled": true,

"staleTtl": <stale_timeout>

"expiredTtl" <expired_timeout>

}

The timeout specified for “staleTtl” indicates, in seconds, when link latency will be considered stale. Links with stale latency are identified by an orange dot within the NSP's path control views. Links with stale latency values are still considered during latency-based path optimization and are treated the same as links with valid latency values, however, stale links should be investigated by an operator. An alarm is raised in NSP when a link's latency becomes stale.

The timeout specified for “expiredTtl” indicates, in seconds, when link latency will be considered expired. Links with expired latency are identified by a red dot within the NSP's path control views. The path-optimization algorithm will attempt to route traffic away from links with an expired latency value, however, expired links can still be taken if they are the only remaining option. This functionality can be disabled by setting the parameter to 0. Links with no active latency are marked as undefined, and are identified by a dash (-) within the NSP's path control views.

Note: Latency timeout functionality is exclusive to telemetry sourced (MDM or NFM-P) OAM latency. If modelDriven mode is disabled, all MDM-sourced OAM latency values will be reset to 0, latency timestamps will be reset to null, and latency states will be reset to undefined. Links with API-configured latency values will not be affected.

Streaming template configuration

The type of latency measurements MD-OAM collects from nodes is based on the value of the fd-avg parameter that is configured within the node's streaming template. The options are:

Note: Configuring the fd-avg parameter to collect the forward latency value, and exclusively supplying interface IPs (both in config>oam-pm>session>ip config and in the NSP REST API) will ensure that the TWAMP packets take the directly-connected link and report accurate forward latency to NSP, which will apply the forward latency to that link.

© 2024 Nokia. Nokia Confidential Information

Use subject to agreed restrictions on disclosure and use.