Network Working Group W. Sun Internet-Draft SJTU Intended status: Standards Track G. Zhang Expires: December 26, 2008 CATR J. Gao Huawei G. Xie SJTU June 24, 2008 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks draft-ietf-ccamp-lsp-dppm-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Sun, et al. Expires December 16, 2008 [Page 1] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 This Internet-Draft will expire on December 16, 2008. Sun, et al. Expires December 16, 2008 [Page 2] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 Abstract Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for Dynamicly provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the Dynamic LSP setup/release performance. These metrics can depict the features of GMPLS networks in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. Sun, et al. Expires December 16, 2008 [Page 3] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Overview of Performance Metrics . . . . . . . . . . . . . . . 8 3. A Singleton Definition for Single Unidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9 3.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11 4. A Singleton Definition for multiple Unidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 12 4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 14 5. A Singleton Definition for Single Bidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 15 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 16 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 16 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 17 6. A Singleton Definition for multiple Bidirectional LSPs Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20 7. A Singleton Definition for LSP Graceful Release Delay . . . . 21 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21 7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21 7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21 7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22 7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23 Sun, et al. Expires December 16, 2008 [Page 4] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 8. A Definition for Samples of Single Unidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 25 8.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 25 8.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 25 8.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 26 8.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 26 8.7. Typical testing cases . . . . . . . . . . . . . . . . . . 26 8.7.1. With No LSP in the Network . . . . . . . . . . . . . . 27 8.7.2. With a Number of LSPs in the Network . . . . . . . . . 27 9. A Definition for Samples of Multiple Unidirectional LSPs Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 28 9.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 28 9.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 28 9.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 29 9.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 29 9.7. Typical testing cases . . . . . . . . . . . . . . . . . . 29 9.7.1. With No LSP in the Network . . . . . . . . . . . . . . 29 9.7.2. With a Number of LSPs in the Network . . . . . . . . . 30 10. A Definition for Samples of Single Bidirectional LSP Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 31 10.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 31 10.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 31 10.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 31 10.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 32 10.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 32 10.7. Typical testing cases . . . . . . . . . . . . . . . . . . 32 10.7.1. With No LSP in the Network . . . . . . . . . . . . . . 33 10.7.2. With a Number of LSPs in the Network . . . . . . . . . 33 11. A Definition for Samples of Multiple Bidirectional LSPs Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 34 11.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 34 11.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 34 11.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 34 11.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 35 11.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 35 11.7. Typical testing cases . . . . . . . . . . . . . . . . . . 35 11.7.1. With No LSP in the Network . . . . . . . . . . . . . . 35 11.7.2. With a Number of LSPs in the Network . . . . . . . . . 36 12. A Definition for Samples of LSP Graceful Release Delay . . . . 37 12.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 37 12.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 37 12.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 37 Sun, et al. Expires December 16, 2008 [Page 5] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 12.4. Definition . . . . . . . . . . . . . . . . . . . . . . . . 37 12.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 37 12.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 38 13. Discussion for unsuccessful setup/release cases . . . . . . . 39 14. Some Statistics Definitions for Metrics to Report . . . . . . 40 14.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 40 14.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 40 14.3. The percentile of Metric . . . . . . . . . . . . . . . . . 40 14.4. The Failure Probability . . . . . . . . . . . . . . . . . 40 15. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 41 16. Security Considerations . . . . . . . . . . . . . . . . . . . 42 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 19.1. Normative References . . . . . . . . . . . . . . . . . . . 45 19.2. Informative References . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . . . . 48 Sun, et al. Expires December 16, 2008 [Page 6] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 1. Introduction Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising control plane solutions for future transport and service network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. The introduction of a control plane into optical circuit switching networks automates the provisioning of connections and drastically reduces connection provision delay. As more and more services and applications are seeking to use GMPLS controled networks as their underlying transport network, and increasingly in a dynamic way, the need is growing for measuring and characterizing the performance of LSP provisioning in GMPLS networks, such that requirement from applications and the provisioning capability of the network can be mapped to each other. This draft defines performance metrics and methodologies that can be used to depict the dynamic LSP provisioning performance of GMPLS networks, more specifically, performance of the signaling protocol. The metrics defined in this document can in the one hand be used to depict the averaged performance of GMPLS implementations. On the other hand, it can also be used in operational environments for carriers to monitor the control plane operation in realtime. For example, an new object can be added to GMPLS TE STD MIB [RFC4802] such that the current and past control plane performance can be monitored through network management systems. The extension of TE- MIB to support the metrics defined is out the scope of this document. Sun, et al. Expires December 16, 2008 [Page 7] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 2. Overview of Performance Metrics In this memo, to depict the dynamic LSP provisioning performance of a GMPLS network, we define 3 performance metrics: unidirectional LSP setup delay, bidirectional LSP setup delay, and LSP graceful release delay. The latency of the LSP setup/release signal is similar to the Round-trip Delay in IP networks. So we refer the structures and notions introduced and discussed in the IPPM Framework document, [RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar with the notions in those documents. Sun, et al. Expires December 16, 2008 [Page 8] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 3. A Singleton Definition for Single Unidirectional LSP Setup Delay This part defines a metric for single unidirectional Label Switched Path setup delay across a GMPLS network. 3.1. Motivation Single unidirectional Label Switched Path setup delay is useful for several reasons: o Single LSP setup delay is an important metric that depicts the provisioning performance of a GMPLS network. Longer LSP setup delay will incur higher overhead for the requesting application, especially when the LSP duration is comparable to the LSP setup delay. o The minimum value of this metric provides an indication of the delay that will likely be experienced when the LSP traversed the shortest route at the lightest load in the control plane. As the delay itself consists of several components, such as link propagation delay and nodal processing delay, this metric also reflects the status of control plane. For example, for LSPs traversing the same route, longer setup delays may suggest congestion in the control channel or high control element load. For this reason, this metric is useful for testing and diagnostic purposes. o LSP setup delay variance has different impact on to applications. Erratic variation in LSP setup delay makes it difficult to support applications that has stringent setup delay requirement. The measurement of single unidirectional LSP setup delay instead of bidirectional LSP setup delay is motivated by the following factors: o Some applications may only use unidirectional LSPs rather than bidirectional ones. For example, content delivery services in multicast method (IPTV) only use unidirectional LSPs. 3.2. Metric Name single unidirectional LSP setup delay 3.3. Metric Parameters o ID0, the ingress LSR ID o ID1, the egress LSR ID Sun, et al. Expires December 16, 2008 [Page 9] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 o T, a time when the setup is attempted 3.4. Metric Units The value of single unidirectional LSP setup delay is either a real number, or an undefined number of milliseconds. 3.5. Definition The single unidirectional LSP setup delay from the ingress node ID0 to the egress node ID1 [RFC3945] at T is dT means that ingress node ID0 sends the first bit of a PATH message packet to egress node ID1 at wire-time T, and that the ingress node ID0 received the last bit of responding RESV message packet from the egress node ID1 at wire- time T+dT in the unidirectional LSP setup case. The single unidirectional LSP setup delay from the ingress node ID0 to the egress node ID1 at T is undefined, means that ingress node ID0 sends the first bit of PATH message packet to egress node ID1 at wire-time T and that ingress node ID0 does not receive the corresponding RESV message within a reasonable period of time. 3.6. Discussion The following issues are likely to come up in practice: o The accuracy of unidirectional LSP setup delay at time T depends on the clock resolution in the ingress node; but synchronization between the ingress node and egress node is not required since unidirectional LSP setup uses two-way signaling. o A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds could be used. But GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move the micro mirrors. This physical motion may take several milliseconds. But the common electronic switches finish the nodal process within several microseconds. So the unidirectional LSP setup delay varies drastically from a network to another. In practice, the upper bound should be chose carefully. o If ingress node sends out the PATH message to set up LSP, but never receive corresponding RESV message, unidirectional LSP setup delay is deemed to be undefined. o If ingress node sends out the PATH message to set up LSP but receive PathErr message, unidirectional LSP setup delay is also Sun, et al. Expires December 16, 2008 [Page 10] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 deemed to be undefined. There are many possible reasons for this case. For example, the PATH message has invalid parameters or the network has not enough resource to set up the requested LSP, etc. 3.7. Methodologies Generally the methodology would proceed as follows: o Make sure that the network has enough resource to set up the requested LSP. o At the ingress node, form the PATH message according to the LSP requirements. A timestamp (T1) may be stored locally in the ingress node when the PATH message packet is sent towards the egress node. o If the corresponding RESV message arrives within a reasonable period of time, take the timestamp (T2) as soon as possible upon receipt of the message. By subtracting the two timestamps, an estimate of unidirectional LSP setup delay (T2 -T1) can be computed. o If the corresponding RESV message fails to arrive within a reasonable period of time, the unidirectional LSP setup delay is deemed to be undefined. Note that the 'reasonable' threshold is a parameter of the methodology. o If the corresponding response message is PathErr, the unidirectional LSP setup delay is deemed to be undefined. Sun, et al. Expires December 16, 2008 [Page 11] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 4. A Singleton Definition for multiple Unidirectional LSP Setup Delay This part defines a metric for multiple unidirectional Label Switched Paths setup delay across a GMPLS network. 4.1. Motivation multiple unidirectional Label Switched Paths setup delay is useful for several reasons: o Upon traffic interruption caused by network failure or network upgrade, carriers may require a large number of LSPs be set up during a short time period o The time needed to setup a large number of LSPs during a short time period can not be deduced by single LSP setup delay 4.2. Metric Name multiple unidirectional LSPs setup delay 4.3. Metric Parameters o ID0, the ingress LSR ID o ID1, the egress LSR ID o Lambda_m, a rate in reciprocal milliseconds o X, the number of LSPs to setup o T, a time when the first setup is attempted 4.4. Metric Units The value of multiple unidirectional LSPs setup delay is either a real number, or an undefined number of milliseconds. 4.5. Definition Given Lambda_m and X, the multiple unidirectional LSPs setup delay from the ingress node to the egress node [RFC3945] at T is dT means: o ingress node ID0 sends the first bit of the first PATH message packet to egress node ID1 at wire-time T o all subsequent (X-1) PATH messages are sent according to the specified poisson process with arrival rate Lambda_m Sun, et al. Expires December 16, 2008 [Page 12] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 o ingress node ID0 receives all corresponding RESV message packets from egress node ID1, and o ingress node ID0 receives the last RESV message packet at wire- time T+dT The multiple unidirectional LSPs setup delay at T is undefined, means that ingress node ID0 sends all the PATH messages toward the egress node ID1 and the first bit of the first PATH message packet is sent at wire-time T and that ingress node ID0 does not receive the one or more of the corresponding RESV messages within a reasonable period of time. 4.6. Discussion The following issues are likely to come up in practice: o The accuracy of multiple unidirectional LSPs setup delay at time T depends on the clock resolution in the ingress node; but synchronization between the ingress node and egress node is not required since unidirectional LSP setup uses two-way signaling. o A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds could be used. But GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move the micro mirrors. This physical motion may take several milliseconds. But the common electronic switches finish the nodal process within several microseconds. So the multiple unidirectional LSP setup delay varies drastically from a network to another. In practice, the upper bound should be chose carefully. o If ingress node sends out the multiple PATH messages to set up the LSPs, but never receives one or more of the corresponding RESV messages, multiple unidirectional LSP setup delay is deemed to be undefined. o If ingress node sends out the PATH messages to set up the LSPs but receives one or more PathErr messages, multiple unidirectional LSPs setup delay is also deemed to be undefined. There are many possible reasons for this case. For example, one of the PATH messages has invalid parameters or the network has not enough resource to set up the requested LSPs, etc. o The arrival rate of the poisson process Lambda_m should be carefully chosen such that in the one hand the control plane is not overburdened.On the other hand, the arrival rate should also Sun, et al. Expires December 16, 2008 [Page 13] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 be large enough to meet the requirements of applications or services. 4.7. Methodologies Generally the methodology would proceed as follows: o Make sure that the network has enough resource to set up the requested LSPs. o At the ingress node, form the PATH messages according to the LSPs' requirements. o At the ingress node, select the time for each of the PATH messages according to the specified poisson process. o At the ingress node, sends out the PATH messages according to the selected time. o Store a timestamp (T1) locally in the ingress node when the first PATH message packet is sent towards the egress node. o If all of the corresponding RESV messages arrives within a reasonable period of time, take the final timestamp (T2) as soon as possible upon the receipt of all the messages. By subtracting the two timestamps, an estimate of multiple unidirectional LSPs setup delay (T2 -T1) can be computed. o If one or more of the corresponding RESV messages fails to arrive within a reasonable period of time, the multiple unidirectional LSPs setup delay is deemed to be undefined. Note that the 'reasonable' threshold is a parameter of the methodology. o If one of the corresponding response message is PathErr, the multiple unidirectional LSPs setup delay is deemed to be undefined. Sun, et al. Expires December 16, 2008 [Page 14] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 5. A Singleton Definition for Single Bidirectional LSP Setup Delay GMPLS allows establishment of bi-directional symmetric LSPs (not of asymmetric LSPs). This part defines a metric for single bidirectional LSP setup delay across a GMPLS network. 5.1. Motivation Single bidirectional Label Switched Path setup delay is useful for several reasons: o LSP setup delay is an important metric that depicts the provisioning performance of a GMPLS network. Longer LSP setup delay will incur higher overhead for the requesting application, especially when the LSP duration is comparable to the LSP setup delay. Thus, measuring the setup delay is important for applications scheduling. o The minimum value of this metric provides an indication of the delay that will likely be experienced when the LSP traversed the shortest route at the lightest load in the control plane. As the delay itself consists of several components, such as link propagation delay and nodal processing delay, this metric also reflects the status of control plane. For example, for LSPs traversing the same route, longer setup delays may suggest congestion in the control channel or high control element load. For this reason, this metric is useful for testing and diagnostic purposes. o LSP setup delay variance has different impact on to applications. Erratic variation in LSP setup delay makes it difficult to support applications that has stringent setup delay requirement. The measurement of single bidirectional LSP setup delay instead of unidirectional LSP setup delay is motivated by the following factors: o Bidirectional LSPs are seen as a requirement for many GMPLS networks. Its provisioning performance is important to applications that generates bi-directional traffic. 5.2. Metric Name Single bidirectional LSP setup delay 5.3. Metric Parameters Sun, et al. Expires December 16, 2008 [Page 15] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 o ID0, the ingress LSR ID o ID1, the egress LSR ID o T, a time when the setup is attempted 5.4. Metric Units The value of single bidirectional LSP setup delay is either a real number, or an undefined number of milliseconds. 5.5. Definition For a real number dT, the single bidirectional LSP setup delay from ingress node ID0 to egress node ID1 at T is dT, means that ingress node ID0 sends out the first bit of a PATH message including an Upstream Label [RFC3473] heading for egress node ID1 at wire-time T, egress node ID1 receives that packet, then immediately sends a RESV message packet back to ingress node ID0, and that ingress node ID0 receives the last bit of that packet at wire-time T+dT. The single bidirectional LSP setup delay from ingress node ID0 to egress node ID1 at T is undefined, means that ingress node ID0 sends the first bit of PATH message to egress node ID1 at wire-time T and that ingress node ID0 does not receive that response packet within a reasonable period of time. 5.6. Discussion The following issues are likely to come up in practice: o The accuracy of single bidirectional LSP setup delay depends on the clock resolution in the ingress node; but synchronization between the ingress node and egress node is not required since single bidirectional LSP setup uses two-way signaling. o A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds could be used. But GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move the micro mirrors. This physical motion may take several milliseconds. But the common electronic switches finish the nodal process within several microseconds. So the bidirectional LSP setup delay varies drastically from a network to another. In the process of bidirectional LSP setup, if the downstream node overrides the label suggested by the upstream node, the setup delay will also increase obviously. Thus, in practice, the upper bound, should be Sun, et al. Expires December 16, 2008 [Page 16] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 chosen carefully. o If the ingress node sends out the PATH message to set up the LSP, but never receives the corresponding RESV message, single bidirectional LSP setup delay is deemed to be undefined. o If the ingress node sends out the PATH message to set up the LSP, but receives PathErr message, single bidirectional LSP setup delay is also deemed to be undefined. There are many possible reasons for this case. For example, the PATH message has invalid parameters or the network has not enough resource to set up the requested LSP. 5.7. Methodologies Generally the methodology would proceed as follows: o Make sure that the network has enough resource to set up the requested LSP. o At the ingress node, form the PATH message (including the Upstream Label or suggested label) according to the LSP requirements. A timestamp (T1) may be stored locally in the ingress node when the PATH message packet is sent towards the egress node. o If the corresponding RESV message arrives within a reasonable period of time, take the final timestamp (T2) as soon as possible upon the receipt of the message. By subtracting the two timestamps, an estimate of bidirectional LSP setup delay (T2 -T1) can be computed. o If the corresponding RESV message fails to arrive within a reasonable period of time, the single bidirectional LSP setup delay is deemed to be undefined. Note that the 'reasonable' threshold is a parameter of the methodology. o If the corresponding response message is PathErr, the single bidirectional LSP setup delay is deemed to be undefined. Sun, et al. Expires December 16, 2008 [Page 17] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 6. A Singleton Definition for multiple Bidirectional LSPs Setup Delay This part defines a metric for multiple bidirectional LSPs setup delay across a GMPLS network. 6.1. Motivation multiple Bidirectional LSPs setup delay is useful for several reasons: o Upon traffic interruption caused by network failure or network upgrade, carriers may require a large number of LSPs be set up during a short time period o The time needed to setup a large number of LSPs during a short time period can not be deduced by single LSP setup delay 6.2. Metric Name Multiple bidirectional LSPs setup delay 6.3. Metric Parameters o ID0, the ingress LSR ID o ID1, the egress LSR ID o Lambda_m, a rate in reciprocal milliseconds o X, the number of LSPs to setup o T, a time when the first setup is attempted 6.4. Metric Units The value of multiple bidirectional LSPs setup delay is either a real number, or an undefined number of milliseconds. 6.5. Definition Given Lambda_m and X, for a real number dT, the multiple bidirectional LSPs setup delay from ingress node to egress node at T is dT, means that: o ingress node ID0 sends the first bit of the first PATH message heading for egress node ID1 at wire-time T Sun, et al. Expires December 16, 2008 [Page 18] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 o all subsequent (X-1) PATH messages are sent according to the specified poisson process with arrival rate Lambda_m o ingress node ID1 receives all corresponding RESV message packets from egress node ID1, and o ingress node ID0 receives the last RESV message packets at wire- time T+dT The multiple bidirectional LSPs setup delay from ingress node to egress node at T is undefined, means that ingress node sends all the PATH messages to egress node and that the ingress node fails to receive one or more of the response messages within a reasonable period of time. 6.6. Discussion The following issues are likely to come up in practice: o The accuracy of multiple bidirectional LSPs setup delay depends on the clock resolution in the ingress node; but synchronization between the ingress node and egress node is not required since bidirectional LSP setup uses two-way signaling. o A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds could be used. But GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move the micro mirrors. This physical motion may take several milliseconds. But the common electronic switches finish the nodal process within several microseconds. So the multiple bidirectional LSPs setup delay varies drastically from a network to another. In the process of multiple bidirectional LSPs setup, if the downstream node overrides the label suggested by the upstream node, the setup delay will also increase obviously. Thus, in practice, the upper bound should be chosen carefully. o If the ingress node sends out the PATH messages to set up the LSPs, but never receive all the corresponding RESV messages, the multiple bidirectional LSPs setup delay is deemed to be undefined. o If the ingress node sends out the PATH messages to set up the LSPs, but receive one or more responding PathErr messages,the multiple bidirectional LSPs setup delay is also deemed to be undefined. There are many possible reasons for this case. For example, one or more of the PATH messages have invalid parameters or the network has not enough resource to set up the requested Sun, et al. Expires December 16, 2008 [Page 19] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 LSPs. o The arrival rate of the poisson process Lambda_m should be carefully chosen such that in the one hand the control plane is not overburdened.On the other hand, the arrival rate should also be large enough to meet the requirements of applications or services. 6.7. Methodologies Generally the methodology would proceed as follows: o Make sure that the network has enough resource to set up the requested LSPs. o At the ingress node, form the PATH messages (including the Upstream Label or suggested label) according to the LSPs' requirements. o At the ingress node, select the time for each of the PATH messages according to the specified poisson process. o At the ingress node, sends out the PATH messages according to the selected time. o Store a timestamp (T1) locally in the ingress node when the first PATH message packet is sent towards the egress node. o If all of the corresponding RESV messages arrives within a reasonable period of time, take the final timestamp (T2) as soon as possible upon the receipt of all the messages. By subtracting the two timestamps, an estimate of multiple bidirectional LSPs setup delay (T2 -T1) can be computed. o If one or more of the corresponding RESV messages fails to arrive within a reasonable period of time, the multiple bidirectional LSPs setup delay is deemed to be undefined. Note that the 'reasonable' threshold is a parameter of the methodology. o If one or more of the corresponding response messages is PathErr, the multiple bidirectional LSPs setup delay is deemed to be undefined. Sun, et al. Expires December 16, 2008 [Page 20] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 7. A Singleton Definition for LSP Graceful Release Delay There are two different kinds of LSP release mechanisms in GMPLS networks: graceful release and forceful release. Memo in current version has not taken forceful LSP release procedure into account. 7.1. Motivation LSP graceful release delay is useful for several reasons: o The LSP graceful release delay is part of the total cost of dynamic LSP provisioning. For some short duration applications, the LSP release time can not be ignored o The LSP graceful release procedure is more prefered in a GMPLS controled network, particularly the optical networks. Since it doesn't trigger restoration/protection, it is "alarm-free connection deletion" in [RFC4208]. 7.2. Metric Name LSP graceful release delay 7.3. Metric Parameters o ID0, the ingress LSR ID o ID1, the egress LSR ID o T, a time when the release is attemped 7.4. Metric Units The value of LSP graceful release delay is either a real number, or an undefined number of milliseconds. 7.5. Definition There are two different LSP graceful release procedures, one is initiated by the ingress node, and another is initiated by egress node. The two procedures are depicted in the [RFC3473]. We define the graceful LSP release delay for these two procedures separately. For a real number dT, the LSP graceful release delay from ingress node ID0 to egress node ID1 at T is dT, means that ingress node ID0 sends the first bit of a PATH message including Admin Status Object with setting the Reflect (R) and Delete (D) bits to egress node at wire-time T, that egress node ID1 receives that packet, then Sun, et al. Expires December 16, 2008 [Page 21] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 immediately sends a RESV message including Admin Status Object with the Delete (D) bit set back to ingress node. The ingress node ID0 sends out PathTear downstream to remove the LSP, and egress node ID1 receives the last bit of PathTear packet at wire-time T+dT. Also as an option, upon receipt of the PATH message including Admin Status Object with setting the Reflect (R) and Delete (D) bits, the egress node ID1 may respond with PathErr message with the Path_State_Removed flag set. The LSP graceful release delay from ingress node ID0 to egress node ID1 at T is undefined, means that ingress node ID0 sends the first bit of PATH message to egress node ID1 at wire-time T and that (either egress node does not receive the PATH packet, egress node does not send corresponding RESV message packet in response, ingress node does not receive that RESV packet, or) the egress node ID1 does not receive the PathTear within a reasonable period of time. The LSP graceful release delay from egress node ID1 to ingress node ID0 at T is dT, means that egress node ID1 sends the first bit of a RESV message including Admin Status Object with setting the Reflect (R) and Delete (D) bits to ingress node at wire-time T. The ingress node ID0 sends out PathTear downstream to remove the LSP, and egress node ID1 receives the last bit of PathTear packet at wire-time T+dT. The LSP graceful release delay from egress node ID1 to ingress node ID0 at T is undefined, means that egress node ID1 sends the first bit of RESV message including Admin Status Object with setting the Reflect (R) and Delete (D) bits to ingress node ID0 at wire-time T and that (either ingress node does not receive the RESV packet, ingress node does not send PathTear message packet in response or) the egress node ID1 does not receive the PathTear within a reasonable period of time. 7.6. Discussion The following issues are likely to come up in practice: o In the first (second) circumstance, the accuracy of LSP graceful release delay at time T depends on the clock resolution in the ingress (egress) node. In the first circumstance, synchronization between the ingress node and egress node is required; but not in the second circumstance; o A given methodology has to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds could be used. But the upper bound should be chosen carefully in practice; Sun, et al. Expires December 16, 2008 [Page 22] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 o In the first circumstance, if ingress node sends out PATH message including Admin Status Object with the Reflect (R) and Delete (D) bits set to initiate LSP graceful release, but never receive corresponding RESV message, LSP graceful release delay is deemed to be undefined. In the second circumstance, if egress node sends out RESV message including Admin Status Object with the Reflect (R) and Delete (D) bits set to initiate LSP graceful release, but never receive corresponding PathTear message, LSP graceful release delay is deemed to be undefined; 7.7. Methodologies In the first circumstance, the methodology may proceed as follows: o Make sure the LSP to be deleted is set up; o At the ingress node, form the PATH message including Admin Status Object with the Reflect (R) and Delete (D) bits set. A timestamp (T1) may be stored locally in the ingress node when the PATH message packet is sent towards the egress node; o Upon receiving the PATH message including Admin Status Object with the Reflect (R) and Delete (D) bits set, the egress node sends a RESV message including Admin Status Object with the Delete (D) and Reflect (R) bits set. Or, alternatively, the egress node sends a PathErr message with the Path_State_Removed flag set upstream; o When the ingress node receive the RESV message or the PathErr message, it sends a PathTear message to remove the LSP; o Egress node takes a timestamp (T2) once it receives the last bit of the PathTear message. The LSP graceful release delay is then (T2-T1). o If the ingress node sends the PATH message downstream, but the egress node fails to receive the PathTear message within a reasonable period of time, the LSP graceful release delay is deemed to be undefined. Note that the 'reasonable' threshold is a parameter of the methodology. In the second circumstance, the methodology would proceed as follows: o Make sure the LSP to be deleted is set up; o On the egress node, form the RESV message including Admin Status Object with the Reflect (R) and Delete (D) bits set. A timestamp may be stored locally in the egress node when the RESV message packet is sent towards the ingress node; Sun, et al. Expires December 16, 2008 [Page 23] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 o Upon receiving the Admin Status Object with the Reflect (R) and Delete (D) bits set in the RESV message, the ingress node sends a PathTear message downstream to remove the LSP; o Egress node takes a timestamp (T2) once it receives the last bit of the PathTear message. The LSP graceful release delay is then (T2-T1). o If the ingress node sends the PATH message downstream, but the egress node fails to receive the PathTear message within a reasonable period of time, the LSP graceful release delay is deemed to be undefined. Note that the 'reasonable' threshold is a parameter of the methodology. Sun, et al. Expires December 16, 2008 [Page 24] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 8. A Definition for Samples of Single Unidirectional LSP Setup Delay In Section 3, we define the singleton metric of Single unidirectional LSP setup delay. Now we define how to get one particular sample of Single unidirectional LSP setup delay. Sampling is to select a particular potion of singleton values of the given parameters. Like in [RFC2330], we use Poisson sampling as an example. 8.1. Metric Name Single unidirectional LSP setup delay sample 8.2. Metric Parameters o ID0, the ingress LSR ID o ID1, the egress LSR ID o T0, a time o Tf, a time o Lambda, a rate in the reciprocal seconds o Th, LSP holding time o Td, the maximum waiting time for successful setup 8.3. Metric Units A sequence of pairs; the elements of each pair are: o T, a time when setup is attemped o dT, either a real number or an undefined number of milli-seconds. 8.4. Definition Given T0, Tf, and lambda, compute a pseudo-random Poisson process beginning at or before T0, with average arrival rate lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of the times in this process, we obtain the value of unidirectional LSP setup delay sample at this time. The value of the sample is the sequence made up of the resulting pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty. Sun, et al. Expires December 16, 2008 [Page 25] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 8.5. Discussion The parameters lambda should be carefully chosen. If the rate is too high, too frequent LSP setup/release procedure results in high overhead in the control plane. In turn, the high overhead will increase unidirectional LSP setup delay. On the other hand if the rate is too low, the sample could not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate lambda value depends on the given network. The parameters Td should be carefully chosen. Different switching technologies may vary significantly in performing a cross-connect operation. At the same time, the time needed in setting up an LSP under different traffic may also vary significantly. In the case of active measurement, the parameters Th should be carefully chosen. The combination of lambda and Th reflects the load of the network. The selection of Th should take into account that the network has sufficient resource to perform subsequent tests. The value of Th may be constant during one sampling process for simplicity considerations. Note that for online or passive measurements, the holding time of an LSP is determined by actual traffic, hence in this case Th is not an input parameter. 8.6. Methodologies o The selection of specific times, using the specified Poisson arrival process, and o Set up the LSP as the methodology for the singleton unidirectional LSP setup delay, and obtain the value of unidirectional LSP setup delay o Release the LSP after Th, and wait for the next Poisson arrival process Note that: it is possible that before the previous LSP release procedure completes, the next Poisson arrival process has arrived and the LSP setup procedure is initiated. If there is resource contention between the two LSPs, the LSP setup may fail. 8.7. Typical testing cases Sun, et al. Expires December 16, 2008 [Page 26] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 8.7.1. With No LSP in the Network 8.7.1.1. Motivation Single unidirectional LSP setup delay with no LSP in the network is important because this reflects the inherent delay of an RSVP-TE implementation. The minimum value provides an indication of the delay that will likely be experienced when an LSP traverses the shortest route with the lightest load in the control plane. 8.7.1.2. Methodologies Make sure that there is no LSP in the network, and proceed with the methodologies described in Section 8.6. 8.7.2. With a Number of LSPs in the Network 8.7.2.1. Motivation Single unidirectional LSP setup delay with a number of LSPs in the network is important because it reflects the performance of an operational network with considrable load. This delay can vary significantly as the number of existing LSPs vary. It can be used as a scalability metric of an RSVP-TE implementation. 8.7.2.2. Methodologies Setup the required number of LSPs, and wait until the network reaches a stable state, then proceed with the methodologies described in Section 8.6. Sun, et al. Expires December 16, 2008 [Page 27] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 9. A Definition for Samples of Multiple Unidirectional LSPs Setup Delay In Section 4, we define the singleton metric of multiple unidirectional LSPs setup delay. Now we define how to get one particular sample of multiple unidirectional LSP setup delay. Sampling is to select a particular potion of singleton values of the given parameters. Like in [RFC2330], we use Poisson sampling as an example. 9.1. Metric Name Multiple unidirectional LSPs setup delay sample 9.2. Metric Parameters o ID0, the ingress LSR ID o ID1, the egress LSR ID o T0, a time o Tf, a time o Lambda_m, a rate in the reciprocal seconds o Lambda, a rate in the reciprocal seconds o X, the number of LSPs to setup o Td, the maximum waiting time for successful multiple unidirectional LSPs setup 9.3. Metric Units A sequence of pairs; the elements of each pair are: o T, a time when the first setup is attemped o dT, either a real number or an undefined number of milli-seconds. 9.4. Definition Given T0, Tf, and lambda, compute a pseudo-random Poisson process beginning at or before T0, with average arrival rate lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of the times in this process, we obtain the value of multiple unidirectional LSP setup delay sample at this time. The value of the sample is the Sun, et al. Expires December 16, 2008 [Page 28] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 sequence made up of the resulting pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty. 9.5. Discussion The parameter lambda is used as arrival rate of "bacth unidirectional LSPs setup" operation. It regulates the interval in between each batch operatoin. The parameter lambda_m is used within each batch operation, as described in Section 4. The parameters lambda and lambda_m should be carefully chosen. If the rate is too high, too frequent LSP setup/release procedure results in high overhead in the control plane. In turn, the high overhead will increase unidirectional LSP setup delay. On the other hand if the rate is too low, the sample could not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate lambda and lambda_m value depends on the given network. The parameters Td should be carefully chosen. Different switching technologies may vary significantly in performing a cross-connect operation. At the same time, the time needed in setting up an LSP under different traffic may also vary significantly. 9.6. Methodologies o The selection of specific times, using the specified Poisson arrival process, and o Set up the LSP as the methodology for the singleton multiple unidirectional LSPs setup delay, and obtain the value of multiple unidirectional LSPs setup delay o Release the LSP after Th, and wait for the next Poisson arrival process Note that: it is possible that before the previous LSP release procedure completes, the next Poisson arrival process has arrived and the LSP setup procedure is initiated. If there is resource contention between the two LSP, the LSP setup may fail. 9.7. Typical testing cases 9.7.1. With No LSP in the Network Sun, et al. Expires December 16, 2008 [Page 29] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 9.7.1.1. Motivation multiple unidirectional LSP setup delay with no LSP in the network is important because this reflects the inherent delay of an RSVP-TE implementation. The minimum value provides an indication of the delay that will likely be experienced when an LSPs traverse the shortest route with the lightest load in the control plane. 9.7.1.2. Methodologies Make sure that there is no LSP in the network, and proceed with the methodologies described in Section 9.6. 9.7.2. With a Number of LSPs in the Network 9.7.2.1. Motivation multiple unidirectional LSPs setup delay with a number of LSPs in the network is important because it reflects the performance of an operational network with considrable load. This delay can vary significantly as the number of existing LSPs vary. It can be used as a scalability metric of an RSVP-TE implementation. 9.7.2.2. Methodologies Setup the required number of LSPs, and wait until the network reaches a stable state, then proceed with the methodologies described in Section 9.6.. Sun, et al. Expires December 16, 2008 [Page 30] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 10. A Definition for Samples of Single Bidirectional LSP Setup Delay In Section 5, we define the singleton metric of Single Bidirectional LSP setup delay. Now we define how to get one particular sample of Single Bidirectional LSP setup delay. Sampling is to select a particular potion of singleton values of the given parameters. Like in [RFC2330], we use Poisson sampling as an example. 10.1. Metric Name Single Bidirectional LSP setup delay sample with no LSP in the network 10.2. Metric Parameters o ID0, the ingress LSR ID o ID1, the egress LSR ID o T0, a time o Tf, a time o Lambda, a rate in the reciprocal seconds o Th, LSP holding time o Td, the maximum waiting time for successful setup 10.3. Metric Units A sequence of pairs; the elements of each pair are: o T, a time when setup is attemped o dT, either a real number or an undefined number of milli-seconds. 10.4. Definition Given T0, Tf, and lambda, compute a pseudo-random Poisson process beginning at or before T0, with average arrival rate lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of the times in this process, we obtain the value of Bidirectional LSP setup delay sample at this time. The value of the sample is the sequence made up of the resulting pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty. Sun, et al. Expires December 16, 2008 [Page 31] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 10.5. Discussion The parameters lambda should be carefully chosen. If the rate is too high, too frequent LSP setup/release procedure results in high overhead in the control plane. In turn, the high overhead will increase Bidirectional LSP setup delay. On the other hand if the rate is too low, the sample could not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate lambda value depends on the given network. The parameters Td should be carefully chosen. Different switching technologies may vary significantly in performing a cross-connect operation. At the same time, the time needed in setting up an LSP under different traffic may also vary significantly. In the case of active measurement, the parameters Th should be carefully chosen. The combination of lambda and Th reflects the load of the network. The selection of Th should take into account that the network has sufficient resource to perform subsequent tests. The value of Th may be constant during one sampling process for simplicity considerations. Note that for online or passive measurements, the holding time of an LSP is determined by actual traffic, hence in this case Th is not an input parameter. 10.6. Methodologies o The selection of specific times, using the specified Poisson arrival process, and o Set up the LSP as the methodology for the singleton bidirectional LSP setup delay, and obtain the value of bidirectional LSP setup delay o Release the LSP after Th, and wait for the next Poisson arrival process Note that: it is possible that before the previous LSP release procedure completes, the next Poisson arrival process has arrived and the LSP setup procedure is initiated. If there is resource contention between the two LSP, the LSP setup may fail. 10.7. Typical testing cases Sun, et al. Expires December 16, 2008 [Page 32] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 10.7.1. With No LSP in the Network 10.7.1.1. Motivation Single bidirectional LSP setup delay with no LSP in the network is important because this reflects the inherent delay of an RSVP-TE implementation. The minimum value provides an indication of the delay that will likely be experienced when an LSP traverses the shortest route with the lightest load in the control plane. 10.7.1.2. Methodologies Make sure that there is no LSP in the network, and proceed with the methodologies described in Section 10.6. 10.7.2. With a Number of LSPs in the Network 10.7.2.1. Motivation Single bidirectional LSP setup delay with a number of LSPs in the network is important because it reflects the performance of an operational network with considrable load. This delay can vary significantly as the number of existing LSPs vary. It can be used as a scalability metric of an RSVP-TE implementation. 10.7.2.2. Methodologies Setup the required number of LSPs, and wait until the network reaches a stable state, then proceed with the methodologies described in Section 10.6. . Sun, et al. Expires December 16, 2008 [Page 33] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 11. A Definition for Samples of Multiple Bidirectional LSPs Setup Delay In Section 6, we define the singleton metric of multiple bidirectional LSPs setup delay. Now we define how to get one particular sample of multiple bidirectional LSP setup delay. Sampling is to select a particular potion of singleton values of the given parameters. Like in [RFC2330], we use Poisson sampling as an example. 11.1. Metric Name Multiple bidirectional LSPs setup delay sample 11.2. Metric Parameters o ID0, the ingress LSR ID o ID1, the egress LSR ID o T0, a time o Tf, a time o Lambda_m, a rate in the reciprocal seconds o Lambda, a rate in the reciprocal seconds o X, the number of LSPs to setup o Td, the maximum waiting time for successful multiple unidirectional LSPs setup 11.3. Metric Units A sequence of pairs; the elements of each pair are: o T, a time when the first setup is attemped o dT, either a real number or an undefined number of milli-seconds. 11.4. Definition Given T0, Tf, and lambda, compute a pseudo-random Poisson process beginning at or before T0, with average arrival rate lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of the times in this process, we obtain the value of multiple unidirectional LSP setup delay sample at this time. The value of the sample is the Sun, et al. Expires December 16, 2008 [Page 34] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 sequence made up of the resulting pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty. 11.5. Discussion The parameter lambda is used as arrival rate of "bacth bidirectional LSPs setup" operation. It regulates the interval in between each batch operatoin. The parameter lambda_m is used within each batch operation, as described in Section 6. The parameters lambda and lambda_m should be carefully chosen. If the rate is too high, too frequent LSP setup/release procedure results in high overhead in the control plane. In turn, the high overhead will increase unidirectional LSP setup delay. On the other hand if the rate is too low, the sample could not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate lambda and lambda_m value depends on the given network. The parameters Td should be carefully chosen. Different switching technologies may vary significantly in performing a cross-connect operation. At the same time, the time needed in setting up an LSP under different traffic may also vary significantly. 11.6. Methodologies o The selection of specific times, using the specified Poisson arrival process, and o Set up the LSP as the methodology for the singleton multiple bidirectional LSPs setup delay, and obtain the value of multiple unidirectional LSPs setup delay o Release the LSP after Th, and wait for the next Poisson arrival process Note that: it is possible that before the previous LSP release procedure completes, the next Poisson arrival process has arrived and the LSP setup procedure is initiated. If there is resource contention between the two LSP, the LSP setup may fail. 11.7. Typical testing cases 11.7.1. With No LSP in the Network Sun, et al. Expires December 16, 2008 [Page 35] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 11.7.1.1. Motivation multiple bidirectional LSP setup delay with no LSP in the network is important because this reflects the inherent delay of an RSVP-TE implementation. The minimum value provides an indication of the delay that will likely be experienced when an LSPs traverse the shortest route with the lightest load in the control plane. 11.7.1.2. Methodologies Make sure that there is no LSP in the network, and proceed with the methodologies described in Section 9.6. 11.7.2. With a Number of LSPs in the Network 11.7.2.1. Motivation multiple bidirectional LSPs setup delay with a number of LSPs in the network is important because it reflects the performance of an operational network with considrable load. This delay can vary significantly as the number of existing LSPs vary. It can be used as a scalability metric of an RSVP-TE implementation. 11.7.2.2. Methodologies Setup the required number of LSPs, and wait until the network reaches a stable state, then proceed with the methodologies described in Section 11.6.. Sun, et al. Expires December 16, 2008 [Page 36] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 12. A Definition for Samples of LSP Graceful Release Delay In Section 7, we define the singleton metric of LSP graceful release delay. Now we define how to get one particular sample of LSP graceful release delay. We also use Poisson sampling as an example. 12.1. Metric Name LSP graceful release delay sample 12.2. Metric Parameters o ID0, the ingress LSR ID o ID1, the egress LSR ID o T0, a time o Tf, a time o Lambda, a rate in reciprocal seconds o Td, the maximum waiting time for successful LSP release 12.3. Metric Units A sequence of pairs; the elements of each pair are: o T, a time, and o dT, either a real number or an undefined number of milli-seconds. 12.4. Definition Given T0, Tf, and lambda, we compute a pseudo-random Poisson process beginning at or before T0, with average arrival rate lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of the times in this process, we obtain the value of LSP graceful release delay sample at this time. The value of the sample is the sequence made up of the resulting pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty. 12.5. Discussion The parameter lambda should be carefully chosen. If the rate is too large, too frequent LSP setup/release procedure results in high Sun, et al. Expires December 16, 2008 [Page 37] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 overhead in the control plane. In turn, the high overhead will increase unidirectional LSP setup delay. On the other hand if the rate is too small, the sample could not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate lambda value depends on the given network. 12.6. Methodologies Generally the methodology would proceed as follows: o Setup the LSP to be deleted o The selection of specific times, using the specified Poisson arrival process, and o Release the LSP as the methodology for the singleton LSP graceful release delay, and obtain the value of LSP graceful release delay o Setup the LSP, and restart the Poisson arrival process, wait for the next Poisson arrival process Sun, et al. Expires December 16, 2008 [Page 38] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 13. Discussion for unsuccessful setup/release cases As has been mentioned earlier, LSP setup/release may fail due to various reasons. For example, setup/release may fail when the control plane is overburdened or when there is resource shortage in one of the intermediat nodes. Since the setup/release failure may have significant impact on network operation, it is worthwhile to report each failure cases, so that appropriate operations can be performed to check the possible implementation,configuration or other deficiency. Although not commonly seen, an LSP setup/release attemp may be falsely carried out. for example, the setup/release request may be targed to a wrong egress node. Although faulty results may have totally different implications to the control plane, if compared with failure cases, for the purpose of performance evaluation, it is still reasonable to treat such results as unsuccessful cases. Thus the unsuccessful cases include both failure and incorrect cases. Once a sample of a particular metric, e.g, single unidirectional LSP setup delay, is obtained, we can deduce the unsuccessful cases by sorting out from the sample the pairs with undefined delay value. Sun, et al. Expires December 16, 2008 [Page 39] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 14. Some Statistics Definitions for Metrics to Report Given the samples of the performance metric, we now offer several statistics of these samples to report. From these statistics, we can draw some useful conclusions of a GMPLS network. The value of these metrics is either a real number, or an undefined number of milliseconds. In the following discussion, we only consider the finite values. 14.1. The Minimum of Metric The minimum of metric is the minimum of all the dT values in the sample. In computing this, undefined values are treated as infinitely large. Note that this means that the minimum could thus be undefined if all the dT values are undefined. In addition, the metric minimum is undefined if the sample is empty. 14.2. The Median of Metric Metric median is the median of the dT values in the given sample. In computing the median, the undefined values are not counted in. 14.3. The percentile of Metric Given a metric and a percent X between 0% and 100%, the Xth percentile of all the dT values in the sample. In addition, the unidirectional LSP setup delay percentile is undefined if the sample is empty. Example: suppose we take a sample and the results are: Stream1 = < , , , , > Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller, and 110 and 500 msec are larger (undefined values are not counted in). 14.4. The Failure Probability In the process of LSP setup/release, it may fail for some reason. The failure probability is the ratio of the unsucessful times to the total times. Note here that both failure and incorrect cases are counted as unsucessful cases. Sun, et al. Expires December 16, 2008 [Page 40] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 15. Discussion It is worthwhile to point out that: o The unidirectional/bidirectional LSP setup delay is one ingress- egress round trip time plus processing time. But in this document, unidirectional/bidirectional LSP setup delay has not taken the processing time in the end nodes (ingress or/and egress) into account. The timestamp T2 is taken after the endpoint node receives it. Actually, the last node has to take some time to process local procedure. Similarly, in the LSP graceful release delay, the memo has not considered the processing time in the endpoint node. o All these metrics are defined from the point of control plane's view. In fact, the control plane and data plane are not always synchronized. In some cases, the LSPs have been set up in the control plane. But the data can not be forwarded immediately. The unidirectional/bidirectional LSP setup delay in the data plane is longer than in the control plane. Sun, et al. Expires December 16, 2008 [Page 41] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 16. Security Considerations Samples of the metrics can be obtained in either active or passive manners. In the active manner, ingress nodes inject probing messages into the control plane. The measurement parameters must be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement, and in extreme cases cause congestion and denial of service. When samples of the metrics are collected in a passive manner, e.g., by monitoring the operations on real-life LSPs, the implementation of the monitoring and reporting mechanism must be careful so that they will not be used to attack the control plane. Besides, the security considerations pertaining to the original RSVP protocol [RFC2205] and its TE extensions [RFC3209] also remain relevant. Sun, et al. Expires December 16, 2008 [Page 42] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 17. IANA Considerations This document makes no requests for IANA action. Sun, et al. Expires December 16, 2008 [Page 43] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 18. Acknowledgements We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique Morrow, Al Morton, Adrian Farrel, Deborah Brungard, Thomas D. Nadeau for their comments and helps. This document contains ideas as well as text that have appeared in existing IETF documents. The authors wish to thank G. Almes, S. Kalidindi and M. Zekauskas. We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the state key laboratory of advanced optical communication systems and networks for the valuable comments. We also wish to thank the support from NSFC and 863 program of China. Sun, et al. Expires December 16, 2008 [Page 44] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 19. References 19.1. Normative References [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User- Network Interface (UNI): Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007. 19.2. Informative References [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. Sun, et al. Expires December 16, 2008 [Page 45] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 Authors' Addresses Weiqiang Sun Shanghai Jiao Tong University 800 Dongchuan Road Shanghai 200240 CN Phone: +86 21 3420 5359 Email: sunwq@sjtu.edu.cn Guoying Zhang China Academy of Telecommunication Research,MII. Beijing 200240 CN Phone: +86 1068094272 Email: zhangguoying@mail.ritt.com.cn Jianhua Gao Huawei Technologies Co., LTD. CN Phone: +86 755 28973237 Email: gjhhit@huawei.com Guowu Xie Shanghai Jiao Tong University 800 Dongchuan Road Shanghai 200240 CN Phone: +86 21 3420 4596 Email: blithe@sjtu.edu.cn Rajiv Papneja Isocore 12359 Sunrise Valley Drive, STE 100 Reston, VA 20190 USA Phone: +1 703 860 9273 Email: rpapneja@isocore.com Sun, et al. Expires December 16, 2008 [Page 46] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 Bin Gu IXIA Oriental Kenzo Plaza 8M,48 Dongzhimen Wai Street,Dongcheng District Beijing 200240 CN Phone: +86 13611590766 Email: BGu@ixiacom.com Xueqing Wei Fiberhome Telecommunicaiton Technology Co.,Ltd. Wuhan CN Phone: +86 13871127882 Email: xqwei@fiberhome.com.cn Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama 356-8502 Japan Phone: +81-49-278-7357 Email: otani@kddilabs.jp Ruiquan Jing China Telecom Beijing Research Institute 118 Xizhimenwai Avenue Beijing 100035 CN Phone: +86-10-58552000 Email: jingrq@ctbri.com.cn Sun, et al. Expires December 16, 2008 [Page 47] Internet-Draft LSP Dynamic PPM in GMPLS Networks June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Sun, et al. Expires December 16, 2008 [Page 48]