draft-ietf-ccamp-lsp-dppm-06.txt   draft-ietf-ccamp-lsp-dppm-07.txt 
Network Working Group W. Sun, Ed. Network Working Group W. Sun, Ed.
Internet-Draft SJTU Internet-Draft SJTU
Intended status: Standards Track G. Zhang, Ed. Intended status: Standards Track G. Zhang, Ed.
Expires: January 10, 2010 CATR Expires: February 2, 2010 CATR
July 9, 2009 August 26, 2009
Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in
Generalized MPLS Networks Generalized MPLS Networks
draft-ietf-ccamp-lsp-dppm-06.txt draft-ietf-ccamp-lsp-dppm-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2010. This Internet-Draft will expire on February 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 26 skipping to change at page 3, line 26
increasing because optical networks are being deployed in metro increasing because optical networks are being deployed in metro
areas. As different applications have varied requirements in the areas. As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other. of networks and application needs can be mapped to each other.
This document provides a series of performance metrics to evaluate This document provides a series of performance metrics to evaluate
the dynamic LSP provisioning performance in GMPLS networks, the dynamic LSP provisioning performance in GMPLS networks,
specifically the dynamic LSP setup/release performance. These specifically the dynamic LSP setup/release performance. These
metrics can depict the features of GMPLS networks in LSP dynamic metrics can depict the features of GMPLS networks in LSP dynamic
provisioning. They can also be used in operational networks for provisioning.
carriers to monitor the control plane performance in realtime.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Conventions Used in This Document . . . . . . . . . . . . . . 8 2. Conventions Used in This Document . . . . . . . . . . . . . . 8
3. Overview of Performance Metrics . . . . . . . . . . . . . . . 9 3. Overview of Performance Metrics . . . . . . . . . . . . . . . 9
4. A Singleton Definition for Single Uni-directional LSP 4. A Singleton Definition for Single Uni-directional LSP
skipping to change at page 7, line 17 skipping to change at page 7, line 17
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising control plane solutions for future transport and service promising control plane solutions for future transport and service
network. GMPLS has been developed to control and operate different network. GMPLS has been developed to control and operate different
kinds of network elements, such as conventional routers, switches, kinds of network elements, such as conventional routers, switches,
Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop
Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc. Dynamic provisioning ability of these connects (OXCs), etc. Dynamic provisioning ability of these
physically diverse devices differs from each other drastically. physically diverse devices differs from each other drastically.
The introduction of a control plane into optical circuit switching The introduction of a control plane into optical circuit switching
networks automates the provisioning of connections and drastically networks provides the basis for automating the provisioning of
reduces connection provision delay. As more and more services and connections and drastically reduces connection provision delay. As
applications are seeking to use GMPLS controlled networks as their more and more services and applications are seeking to use GMPLS
underlying transport network, and increasingly in a dynamic way, the controlled networks as their underlying transport network, and
need is growing for measuring and characterizing the performance of increasingly in a dynamic way, the need is growing for measuring and
LSP provisioning in GMPLS networks, such that requirement from characterizing the performance of LSP provisioning in GMPLS networks,
applications and the provisioning capability of the network can be such that requirement from applications and the provisioning
mapped to each other. capability of the network can be mapped to each other.
This draft defines performance metrics and methodologies that can be This draft defines performance metrics and methodologies that can be
used to depict the dynamic LSP provisioning performance of GMPLS used to depict the dynamic LSP provisioning performance of GMPLS
networks, more specifically, performance of the signaling protocol. networks, more specifically, performance of the signaling protocol.
The metrics defined in this document can on the one hand be used to The metrics defined in this document can be used to depict the
depict the average performance of GMPLS implementations. On the average performance of GMPLS implementations.
other hand, it can also be used in operational environments for
carriers to monitor the control plane operation in real-time. For
example, a new object can be added to GMPLS TE STD MIB [RFC4802] so
that the current and past control plane performance can be monitored
through network management systems. The extension of TE-MIB to
support the defined metrics is outside the scope of this document.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Overview of Performance Metrics 3. Overview of Performance Metrics
In this memo, to depict the dynamic LSP provisioning performance of a In this memo, to depict the dynamic LSP provisioning performance of a
GMPLS network, we define 3 performance metrics: uni-directional LSP GMPLS network, we define 3 performance metrics: uni-directional LSP
setup delay, bi-directional LSP setup delay, and LSP graceful release setup delay, bi-directional LSP setup delay, and LSP graceful release
delay. The latency of the LSP setup/release signal is similar to the delay. The latency of the LSP setup/release signal is conceptually
Round-trip Delay in IP networks. So we refer the structures and similar to the Round-trip Delay in IP networks. This enables us to
notions introduced and discussed in the IPPM Framework document, refer to the structures and notions introduced and discussed in the
[RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar IPPM Framework document, [RFC2330] [RFC2679] [RFC2681]. The reader
with the notions in those documents. is assumed to be familiar with the notions in those documents.
Note that data path related metrics, for example, the time between Note that data path related metrics, for example, the time between
the reception of RESV message by ingress node and forward data path the reception of RESV message by ingress node and forward data path
becomes operational, are defined in another document becomes operational, are defined in another document
[I-D.sun-ccamp-dpm]. An implementation MAY choose whether to [I-D.sun-ccamp-dpm]. An implementation MAY choose whether to
implement metrics in the two documents together. However, it is implement metrics in the two documents together. However, it is
RECOMMENDED that both measurements are performed to complement each RECOMMENDED that both measurements are performed to complement each
other. other.
4. A Singleton Definition for Single Uni-directional LSP Setup Delay 4. A Singleton Definition for Single Uni-directional LSP Setup Delay
skipping to change at page 10, line 17 skipping to change at page 10, line 17
This part defines a metric for single uni-directional Label Switched This part defines a metric for single uni-directional Label Switched
Path setup delay across a GMPLS network. Path setup delay across a GMPLS network.
4.1. Motivation 4.1. Motivation
Single uni-directional Label Switched Path setup delay is useful for Single uni-directional Label Switched Path setup delay is useful for
several reasons: several reasons:
o Single LSP setup delay is an important metric that depicts the o Single LSP setup delay is an important metric that depicts the
provisioning performance of a GMPLS network. Longer LSP setup provisioning performance of a GMPLS network. Longer LSP setup
delay will incur higher overhead for the requesting application, delay will most likely incur higher overhead for the requesting
especially when the LSP duration is comparable to the LSP setup application, especially when the LSP duration itself is comparable
delay. to the LSP setup delay.
o The minimum value of this metric provides an indication of the o The minimum value of this metric provides an indication of the
delay that will likely be experienced when the LSP traversed the delay that will likely be experienced when the LSP traversed the
shortest route at the lightest load in the control plane. As the shortest route at the lightest load in the control plane. As the
delay itself consists of several components, such as link delay itself consists of several components, such as link
propagation delay and nodal processing delay, this metric also propagation delay and nodal processing delay, this metric also
reflects the status of control plane. For example, for LSPs reflects the status of control plane. For example, for LSPs
traversing the same route, longer setup delays may suggest traversing the same route, longer setup delays may suggest
congestion in the control channel or high control element load. congestion in the control channel or high control element load.
For this reason, this metric is useful for testing and diagnostic For this reason, this metric is useful for testing and diagnostic
purposes. purposes.
o LSP setup delay variance has different impact on applications. o The observed variance in a sample of LSP setup delay metric values
Erratic variation in LSP setup delay makes it difficult to support variance may serve as an early indicator on the feasibility of
applications that have stringent setup delay requirement. support of applications that have stringent setup delay
requirements.
The measurement of single uni-directional LSP setup delay instead of The measurement of single uni-directional LSP setup delay instead of
bi-directional LSP setup delay is motivated by the following factors: bi-directional LSP setup delay is motivated by the following factors:
o Some applications may use only uni-directional LSPs rather than o Some applications may use only uni-directional LSPs rather than
bi-directional ones. For example, content delivery services with bi-directional ones. For example, content delivery services with
multicasting may use only uni-directional LSPs. multicasting may use only uni-directional LSPs.
4.2. Metric Name 4.2. Metric Name
skipping to change at page 10, line 50 skipping to change at page 11, line 4
bi-directional ones. For example, content delivery services with bi-directional ones. For example, content delivery services with
multicasting may use only uni-directional LSPs. multicasting may use only uni-directional LSPs.
4.2. Metric Name 4.2. Metric Name
single uni-directional LSP setup delay single uni-directional LSP setup delay
4.3. Metric Parameters 4.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
o T, a time when the setup is attempted o T, a time when the setup is attempted
4.4. Metric Units 4.4. Metric Units
The value of single uni-directional LSP setup delay is either a real The value of single uni-directional LSP setup delay is either a real
number, or an undefined number of milliseconds. number, or an undefined number of milliseconds.
4.5. Definition 4.5. Definition
The single uni-directional LSP setup delay from the ingress node ID0 The single uni-directional LSP setup delay from ingress node ID0 to
to the egress node ID1 [RFC3945] at T is dT means that ingress node egress node ID1 [RFC3945] at T is dT means that ingress node ID0
ID0 sends the first bit of a PATH message packet to egress node ID1 sends the first bit of a PATH message packet to egress node ID1 at
at wire-time T, and that the ingress node ID0 received the last bit wire-time T, and that ingress node ID0 received the last bit of
of responding RESV message packet from the egress node ID1 at wire- responding RESV message packet from egress node ID1 at wire-time
time T+dT in the uni-directional LSP setup case. T+dT.
The single uni-directional LSP setup delay from the ingress node ID0 The single uni-directional LSP setup delay from ingress node ID0 to
to the egress node ID1 at T is undefined, means that ingress node ID0 egress node ID1 at T is undefined, means that ingress node ID0 sends
sends the first bit of PATH message packet to egress node ID1 at the first bit of PATH message packet to egress node ID1 at wire-time
wire-time T and that ingress node ID0 does not receive the T and that ingress node ID0 does not receive the corresponding RESV
corresponding RESV message within a reasonable period of time. message within a reasonable period of time.
The undefined value of this metric indicates an event of Single Uni- The undefined value of this metric indicates an event of Single Uni-
directional LSP Setup Failure, and would be used to report a count or directional LSP Setup Failure, and would be used to report a count or
an percentage of Single Uni-directional LSP Setup failures. See an percentage of Single Uni-directional LSP Setup failures. See
section Section 14.4 for definitions of LSP setup/release failures. section Section 14.4 for definitions of LSP setup/release failures.
4.6. Discussion 4.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
skipping to change at page 12, line 5 skipping to change at page 12, line 5
whether a latency value is infinite or whether it is merely very whether a latency value is infinite or whether it is merely very
large. Simple upper bounds MAY be used. But GMPLS networks may large. Simple upper bounds MAY be used. But GMPLS networks may
accommodate many kinds of devices. For example, some photonic accommodate many kinds of devices. For example, some photonic
cross-connects (PXCs) have to move micro mirrors. This physical cross-connects (PXCs) have to move micro mirrors. This physical
motion may take several milliseconds. But the common electronic motion may take several milliseconds. But the common electronic
switches can finish the nodal processing within several switches can finish the nodal processing within several
microseconds. So the uni-directional LSP setup delay varies microseconds. So the uni-directional LSP setup delay varies
drastically from one network to another. In practice, the upper drastically from one network to another. In practice, the upper
bound should be chosen carefully and the value MUST be reported. bound should be chosen carefully and the value MUST be reported.
o If ingress node sends out the PATH message to set up LSP, but o If ingress node sends out the PATH message to set up an LSP, but
never receives the corresponding RESV message, uni-directional LSP never receives the corresponding RESV message, the uni-directional
setup delay MUST be set to undefined. LSP setup delay MUST be set to undefined.
o If ingress node sends out the PATH message to set up LSP but o If the ingress node sends out the PATH message to set up an LSP
receives PathErr message, uni-directional LSP setup delay MUST be but receives a PathErr message, the uni-directional LSP setup
set to undefined. There are many possible reasons for this case. delay MUST be set to undefined. There are many possible reasons
For example, the PATH message has invalid parameters or the for this case. For example, the PATH message has invalid
network does not have enough resource to set up the requested LSP, parameters or the network does not have enough resource to set up
etc. the requested LSP, etc.
4.7. Methodologies 4.7. Methodologies
Generally the methodology would proceed as follows: Generally the methodology would proceed as follows:
o Make sure that the network has enough resource to set up the o Make sure that the network has enough resource to set up the
requested LSP. requested LSP.
o At the ingress node, form the PATH message according to the LSP o At the ingress node, form the PATH message according to the LSP
requirements. A timestamp (T1) may be stored locally on the requirements. A timestamp (T1) may be stored locally on the
skipping to change at page 13, line 15 skipping to change at page 13, line 15
5. A Singleton Definition for multiple Uni-directional LSP Setup Delay 5. A Singleton Definition for multiple Uni-directional LSP Setup Delay
This part defines a metric for multiple uni-directional Label This part defines a metric for multiple uni-directional Label
Switched Paths setup delay across a GMPLS network. Switched Paths setup delay across a GMPLS network.
5.1. Motivation 5.1. Motivation
Multiple uni-directional Label Switched Paths setup delay is useful Multiple uni-directional Label Switched Paths setup delay is useful
for several reasons: for several reasons:
o Upon traffic interruption caused by network failure or network o Carriers may require a large number of LSPs be set up during a
upgrade, carriers may require a large number of LSPs be set up short time period. This request may arise e.g. as a consequence
during a short time period. to interruptions on established LSPs or other network failures.
o The time needed to setup a large number of LSPs during a short 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. time period can not be deduced from single LSP setup delay.
5.2. Metric Name 5.2. Metric Name
Multiple uni-directional LSPs setup delay Multiple uni-directional LSPs setup delay
5.3. Metric Parameters 5.3. Metric Parameters
o ID0, the ingress LSR ID o ID0, the ingress LSR ID
o ID1, the egress LSR ID o ID1, the egress LSR ID
skipping to change at page 14, line 11 skipping to change at page 14, line 11
o all subsequent (X-1) PATH messages are sent according to the o all subsequent (X-1) PATH messages are sent according to the
specified Poisson process with arrival rate Lambda_m specified Poisson process with arrival rate Lambda_m
o ingress node ID0 receives all corresponding RESV message packets o ingress node ID0 receives all corresponding RESV message packets
from egress node ID1, and from egress node ID1, and
o ingress node ID0 receives the last RESV message packet at wire- o ingress node ID0 receives the last RESV message packet at wire-
time T+dT time T+dT
The multiple uni-directional LSPs setup delay at T is undefined, The multiple uni-directional LSPs setup delay at T is undefined,
means that ingress node ID0 sends all the PATH messages toward the means that ingress node ID0 sends all the PATH messages toward egress
egress node ID1 and the first bit of the first PATH message packet is node ID1 and the first bit of the first PATH message packet is sent
sent at wire-time T and that ingress node ID0 does not receive the at wire-time T and that ingress node ID0 does not receive one or more
one or more of the corresponding RESV messages within a reasonable of the corresponding RESV messages within a reasonable period of
period of time. time.
The undefined value of this metric indicates an event of Multiple The undefined value of this metric indicates an event of Multiple
Uni-directional LSP Setup Failure, and would be used to report a Uni-directional LSP Setup Failure, and would be used to report a
count or an percentage of Multiple Uni-directional LSP Setup count or an percentage of Multiple Uni-directional LSP Setup
failures. See section Section 14.4 for definitions of LSP setup/ failures. See section Section 14.4 for definitions of LSP setup/
release failures. release failures.
5.6. Discussion 5.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
skipping to change at page 22, line 52 skipping to change at page 22, line 52
There are two different LSP graceful release procedures, one is There are two different LSP graceful release procedures, one is
initiated by the ingress node, and another is initiated by the egress initiated by the ingress node, and another is initiated by the egress
node. The two procedures are depicted in [RFC3473]. We define the node. The two procedures are depicted in [RFC3473]. We define the
graceful LSP release delay for these two procedures separately. graceful LSP release delay for these two procedures separately.
For a real number dT, the LSP graceful release delay from ingress 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 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 sends the first bit of a PATH message including Admin Status Object
with the Reflect (R) and Delete (D) bits set to the egress node at with the Reflect (R) and Delete (D) bits set to the egress node at
wire-time T, that the egress node ID1 receives that packet, then wire-time T, that egress node ID1 receives that packet, then
immediately sends a RESV message including Admin Status Object with immediately sends a RESV message including Admin Status Object with
the Delete (D) bit set back to the ingress node. The ingress node the Delete (D) bit set back to the ingress node. Ingress node ID0
ID0 sends out PathTear downstream to remove the LSP, and egress node sends out PathTear downstream to remove the LSP, and egress node ID1
ID1 receives the last bit of PathTear packet at wire-time T+dT. receives the last bit of PathTear packet at wire-time T+dT.
Also as an option, upon receipt of the PATH message including Admin Also as an option, upon receipt of the PATH message including Admin
Status Object with the Reflect (R) and Delete (D) bits set, the Status Object with the Reflect (R) and Delete (D) bits set, egress
egress node ID1 may respond with PathErr message with the node ID1 may respond with PathErr message with the Path_State_Removed
Path_State_Removed flag set. flag set.
The LSP graceful release delay from ingress node ID0 to egress node 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 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 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 (either egress node does not receive the PATH packet, egress node
does not send corresponding RESV message packet in response, or does not send corresponding RESV message packet in response, or
ingress node does not receive that RESV packet, and) the egress node ingress node does not receive that RESV packet, and) egress node ID1
ID1 does not receive the PathTear within a reasonable period of time. does not receive the PathTear within a reasonable period of time.
The LSP graceful release delay from egress node ID1 to ingress node 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 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 RESV message including Admin Status Object with setting the Reflect
(R) and Delete (D) bits to ingress node at wire-time T. The ingress (R) and Delete (D) bits to ingress node at wire-time T. Ingress node
node ID0 sends out PathTear downstream to remove the LSP, and egress ID0 sends out PathTear downstream to remove the LSP, and egress node
node ID1 receives the last bit of PathTear packet at wire-time T+dT. 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 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 ID0 at T is undefined, means that egress node ID1 sends the first bit
of RESV message including Admin Status Object with setting the of RESV message including Admin Status Object with setting the
Reflect (R) and Delete (D) bits to ingress node ID0 at wire-time T 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, or and that (either ingress node does not receive the RESV packet, or
ingress node does not send PathTear message packet in response, and) ingress node does not send PathTear message packet in response, and)
the egress node ID1 does not receive the PathTear within a reasonable egress node ID1 does not receive the PathTear within a reasonable
period of time. period of time.
The undefined value of this metric indicates an event of LSP Graceful The undefined value of this metric indicates an event of LSP Graceful
Release Failure, and would be used to report a count or an percentage Release Failure, and would be used to report a count or an percentage
of LSP Graceful Release failures. See section Section 14.4 for of LSP Graceful Release failures. See section Section 14.4 for
definitions of LSP setup/release failures. definitions of LSP setup/release failures.
8.6. Discussion 8.6. Discussion
The following issues are likely to come up in practice: The following issues are likely to come up in practice:
skipping to change at page 33, line 30 skipping to change at page 33, line 30
In the case of active measurement, the parameters Th should be In the case of active measurement, the parameters Th should be
carefully chosen. The combination of lambda and Th reflects the load carefully chosen. The combination of lambda and Th reflects the load
of the network. The selection of Th SHOULD take into account that of the network. The selection of Th SHOULD take into account that
the network has sufficient resource to perform subsequent tests. The the network has sufficient resource to perform subsequent tests. The
value of Th MAY be constant during one sampling process for value of Th MAY be constant during one sampling process for
simplicity considerations. simplicity considerations.
Note that for online or passive measurements, the arrival rate and Note that for online or passive measurements, the arrival rate and
the LSP holding time are determined by actual traffic, hence in this the LSP holding time are determined by actual traffic, hence in this
case Lambda and Th are not an input parameter. case Lambda and Th are not input parameters.
11.6. Methodologies 11.6. Methodologies
o Select the times using the specified Poisson arrival process, and o Select the times using the specified Poisson arrival process, and
o Set up the LSP as the methodology for the singleton bi-directional o Set up the LSP as the methodology for the singleton bi-directional
LSP setup delay, and obtain the value of bi-directional LSP setup LSP setup delay, and obtain the value of bi-directional LSP setup
delay delay
o Release the LSP after Th, and wait for the next Poisson arrival o Release the LSP after Th, and wait for the next Poisson arrival
skipping to change at page 40, line 29 skipping to change at page 40, line 29
be undefined if all the dT values are undefined. In addition, the be undefined if all the dT values are undefined. In addition, the
metric minimum SHOULD be set to undefined if the sample is empty. metric minimum SHOULD be set to undefined if the sample is empty.
14.2. The Median of Metric 14.2. The Median of Metric
Metric median is the median of the dT values in the given sample. In Metric median is the median of the dT values in the given sample. In
computing the median, the undefined values MUST NOT be counted in. computing the median, the undefined values MUST NOT be counted in.
14.3. The percentile of Metric 14.3. The percentile of Metric
Given a metric and a percent X between 0% and 100%, the Xth The percentile of Metric is defined as: given a metric and a percent
percentile of all the dT values in the sample. In addition, the X between 0% and 100%, the Xth percentile of all the dT values in the
percentile is undefined if the sample is empty. sample." In addition, the percentile is undefined if the sample is
empty.
Example: suppose we take a sample and the results are: Stream1 = < Example: suppose we take a sample and the results are: Stream1 = <
<T1, 100 msec>, <T2, 110 msec>, <T3, undefined>, <T4, 90 msec>, <T5, <T1, 100 msec>, <T2, 110 msec>, <T3, undefined>, <T4, 90 msec>, <T5,
500 msec> > 500 msec> >
Then the 50th percentile would be 110 msec, since 90 msec and 100 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 msec are smaller, and 110 and 500 msec are larger (undefined values
are not counted in). are not counted in).
14.4. Failure statistics of Metric 14.4. Failure statistics of Metric
skipping to change at page 42, line 42 skipping to change at page 42, line 42
is RECOMMENDED that both the measurements defined in this document is RECOMMENDED that both the measurements defined in this document
and the measurements defined in [I-D.sun-ccamp-dpm] are performed and the measurements defined in [I-D.sun-ccamp-dpm] are performed
to complement each other. to complement each other.
o Note that, in implementing the tests described in this document a o Note that, in implementing the tests described in this document a
tester should be sure to measure the time taken for the control tester should be sure to measure the time taken for the control
plane messages including the processing of those messages by the plane messages including the processing of those messages by the
nodes under test. nodes under test.
o Bi-directional LSPs may be setup using three way signalling, where o Bi-directional LSPs may be setup using three way signalling, where
the initiating node will send a RESV_CONF message downsteam upon the initiating node will send a RESV_CONF message downstream upon
receiving the RESV message. The RESV_CONF message is used to receiving the RESV message. The RESV_CONF message is used to
notify the terminate node that it can transfer data upstream. notify the terminate node that it can transfer data upstream.
Actually, both direction should be ready to transfer data when the Actually, both direction should be ready to transfer data when the
RESV message is received by the initiate node. Therefore, the bi- RESV message is received by the initiate node. Therefore, the bi-
directional LSP setup delay defined in this document does not take directional LSP setup delay defined in this document does not take
the confirmation procedure into account. the confirmation procedure into account.
16. Security Considerations 16. Security Considerations
Samples of the metrics can be obtained in either active or passive Samples of the metrics can be obtained in either active or passive
skipping to change at page 45, line 8 skipping to change at page 45, line 8
protocol [RFC2205] and its TE extensions [RFC3209] also remain protocol [RFC2205] and its TE extensions [RFC3209] also remain
relevant. relevant.
17. IANA Considerations 17. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
18. Acknowledgements 18. Acknowledgements
We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique
Morrow, Al Morton, Henk Uijterwaal, Adrian Farrel, Deborah Brungard, Morrow, Adrian Farrel, Deborah Brungard, Lou Berger, Thomas D. Nadeau
Lou Berger, Thomas D. Nadeau for their comments and helps. for their comments and helps.
We wish to thank experts from IPPM and BMWG - Reinhard Schrage, Al
Morton and Henk Uijterwaal, for reviewing this document.
This document contains ideas as well as text that have appeared in This document contains ideas as well as text that have appeared in
existing IETF documents. The authors wish to thank G. Almes, S. existing IETF documents. The authors wish to thank G. Almes, S.
Kalidindi and M. Zekauskas. Kalidindi and M. Zekauskas.
We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the We also wish to thank Weisheng Hu, Yaohui Jin and Wei Guo in the
state key laboratory of advanced optical communication systems and state key laboratory of advanced optical communication systems and
networks for the valuable comments. We also wish to thank the networks for the valuable comments. We also wish to thank the
support from NSFC and 863 program of China. support from NSFC and 863 program of China.
skipping to change at page 46, line 43 skipping to change at page 46, line 43
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User- "Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol- Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005. 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 19.2. Informative References
[I-D.shiomoto-ccamp-switch-programming] [I-D.shiomoto-ccamp-switch-programming]
Shiomoto, K. and A. Farrel, "Advice on When It is Safe to Shiomoto, K. and A. Farrel, "Advice on When It is Safe to
Start Sending Data on Label Switched Paths Established Start Sending Data on Label Switched Paths Established
Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-00 Using RSVP-TE", draft-shiomoto-ccamp-switch-programming-00
(work in progress), February 2009. (work in progress), February 2009.
[I-D.sun-ccamp-dpm] [I-D.sun-ccamp-dpm]
Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R., Gu, B., Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R., Gu, B.,
 End of changes. 29 change blocks. 
87 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/