Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks
Extracted elements (25)
Clock synchronization between ingress and egress nodes is not required for any of the LSP setup delay measurements because GMPLS LSP setup uses two-way signaling — both timestamps T1 and T2 are taken at the ingress node, making synchronization unnecessary.
LSP setup delay is conceptually similar to Round-trip Delay in IP networks, which justifies direct reuse of IPPM framework structures and notions (RFC 2330, RFC 2679, RFC 2681) including Poisson sampling methodology rather than defining a wholly new measurement framework.
Only graceful LSP release is measured (not forceful) because graceful release is preferred in GMPLS-controlled optical networks: it does not trigger restoration or protection mechanisms and constitutes 'alarm-free connection deletion' as described in RFC 4208.
The bidirectional LSP setup delay metric does not account for the ResvConf confirmation message used in three-way signaling because both directions are ready for data transfer when the Resv message is received by the initiating node, making the confirmation superfluous for measuring setup completion.
The setup and release delay metrics do not include end-node processing time — timestamps are taken upon packet reception, not after local processing completes. This is a known scope limitation noted in the Discussion section.
For ingress-initiated LSP graceful release, clock synchronization between ingress and egress is required (T1 at ingress, T2 at egress). For egress-initiated graceful release, synchronization is not required because both timestamps are taken at the egress node.
This document measures only control-plane signaling performance. Data-path metrics (e.g., time from Resv reception until the forward data path becomes operational) are defined in a companion document [CCAMP-DPM]; it is RECOMMENDED that both measurement sets be performed to complement each other.
For LSP graceful release delay, if the egress node does not receive the PathTear message within a reasonable period of time (regardless of which end initiated release), the LSP graceful release delay MUST be set to undefined.
For multiple LSP metrics, all LSPs MUST traverse the same route. If multiple routes exist between ingress ID0 and egress ID1, Explicit Route Objects (EROs) or an alternate method such as static configuration MUST be used to enforce same-route traversal.
For sampling, the LSP holding time Th SHOULD take into account that the network has sufficient resources to perform subsequent tests; Th MAY be constant during one sampling process for simplicity.
If the ingress node sends a Path message but receives a PathErr message in response, the LSP setup delay MUST be set to undefined. Reasons include invalid Path parameters or insufficient network resources.
In computing the median, maximum, and percentile statistics, undefined values MUST NOT be included. For computing the minimum, undefined values SHOULD be treated as infinitely large.
Sample metric reporting MUST include both real and undefined values together with the total number of values, the selected parameters, the route traversed by the LSPs, and the testing case used.
The metric result (real number or undefined) MUST be reported together with the selected upper bound. The route that the LSP traverses MUST also be reported, either via the record route object (RFC 3209) or via the management plane.
The Poisson arrival rate Lambda_m SHOULD be chosen carefully: large enough to meet application requirements but not so high as to overburden the control plane, which would itself increase setup delay and skew results.
The upper bound for determining whether a latency value is infinite SHOULD be chosen carefully, as setup delay varies drastically across device types — photonic cross-connects with micro-mirror motion take milliseconds while electronic switches process in microseconds.
LSP Graceful Release Delay is defined for two procedures: ingress-initiated (Path message with Admin Status Object R and D bits set, measured until egress receives PathTear) and egress-initiated (Resv message with R and D bits set, measured until egress receives PathTear). Forceful release is explicitly out of scope.
Multiple Bidirectional LSPs Setup Delay is defined as the time from the first Path message (including Upstream Label) sent to the last of all X corresponding Resv messages received, where X Path messages follow a Poisson process with rate Lambda_m. The metric is undefined if any Resv is not received in time.
Multiple Unidirectional LSPs Setup Delay is defined as the elapsed time from the first Path message sent to the last Resv received, where X Path messages are sent according to a Poisson process with arrival rate Lambda_m. The metric is undefined if any corresponding Resv is not received within the timeout.
Sample metrics for each singleton metric use Poisson sampling: given T0, Tf, and Lambda, a pseudo-random Poisson process generates arrival times and the sample is the resulting sequence of <time, delay> pairs. This approach is adopted directly from the IPPM framework (RFC 2330).
Single Bidirectional LSP Setup Delay is defined using GMPLS bidirectional symmetric LSP signaling: ingress ID0 sends a Path message including an Upstream Label (RFC 3473) and the metric spans until the last bit of the Resv is received. GMPLS supports only symmetric, not asymmetric, bidirectional LSPs.
Single Unidirectional LSP Setup Delay is defined as the elapsed time from when ingress node ID0 sends the first bit of a Path message at wire-time T to when it receives the last bit of the corresponding Resv message at wire-time T+dT. The value is either a real number of milliseconds or 'undefined' when no Resv is received within the timeout.
Statistics definitions include: Minimum (undefined treated as infinity), Median (undefined excluded), Maximum (undefined excluded), Percentile via empirical distribution function (undefined excluded), Failure Count (integer count of undefined values), and Failure Ratio (failure events divided by total requests, expressed as a percentage).
Active measurement by injecting probing Path messages must use carefully selected parameters to avoid injecting excessive control-plane traffic that could skew results or, in extreme cases, cause congestion and denial of service in the measured network.
Passive monitoring implementations that expose performance data to other applications (e.g., via SNMP) must use authentication to prevent unauthorized reads and modifications; SNMPv3 with full cryptographic mechanisms is RECOMMENDED. Rate limiting on performance queries is also desirable to prevent overwhelming the data store.