One document matched: draft-ietf-ccamp-lsp-dppm-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.2119.xml'>
<!ENTITY rfc2205 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.2205.xml'>
<!ENTITY rfc2330 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.2330.xml'>
<!ENTITY rfc2679 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.2679.xml'>
<!ENTITY rfc3209 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.3209.xml'>
<!ENTITY rfc3473 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.3473.xml'>
<!ENTITY rfc3945 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.3945.xml'>
<!ENTITY rfc4208 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.4208.xml'>
<!ENTITY rfc2681 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.2681.xml'>
<!ENTITY rfc4802 SYSTEM
'D:\papers\ID\bibxml\reference.RFC.4802.xml'>
<!--
<!ELEMENT front (title,author+,contributor*,date,area*,workgroup*,keyword*,
abstract?,note*)>
<!ELEMENT contributor (organization,address?,t+)>
<!ATTLIST contributor
initials %ATEXT; #IMPLIED
surname %ATEXT; #IMPLIED
fullname %ATEXT; #IMPLIED><?rfc toc="yes" ?>
-->
]>
<rfc category="std" ipr="full3978" docName="draft-ietf-ccamp-lsp-dppm-00.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev='LSP Dynamical PPM in GMPLS Networks'>
Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized
MPLS Networks
</title>
<author initials='W.' surname="Sun" fullname='Weiqiang Sun'>
<organization abbrev='SJTU'>
Shanghai Jiao Tong University
</organization>
<address>
<postal>
<street>800 Dongchuan Road</street>
<city>Shanghai</city>
<code>200240</code>
<country>CN</country>
</postal>
<phone>+86 21 3420 5359</phone>
<email>sunwq@sjtu.edu.cn</email>
</address>
</author>
<author initials='G.' surname="Zhang" fullname='Guoying Zhang'>
<organization abbrev='CATR'>
China Academy of Telecommunication Research,MII.
</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<code>200240</code>
<country>CN</country>
</postal>
<phone>+86 1068094272</phone>
<email>zhangguoying@mail.ritt.com.cn</email>
</address>
</author>
<author initials='J.' surname="Gao" fullname='Jianhua Gao'>
<organization abbrev='Huawei'>
Huawei Technologies Co., LTD.
</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country>CN</country>
</postal>
<phone>+86 755 28973237</phone>
<email>gjhhit@huawei.com</email>
</address>
</author>
<author initials='G.' surname="Xie" fullname='Guowu Xie'>
<organization abbrev='SJTU'>
Shanghai Jiao Tong University
</organization>
<address>
<postal>
<street>800 Dongchuan Road</street>
<city>Shanghai</city>
<code>200240</code>
<country>CN</country>
</postal>
<phone>+86 21 3420 4596</phone>
<email>blithe@sjtu.edu.cn</email>
</address>
</author>
<author initials='R.' surname="Papneja" fullname='Rajiv Papneja'>
<organization abbrev='Isocore'>
Isocore
</organization>
<address>
<postal>
<street>12359 Sunrise Valley Drive, STE 100</street>
<city>Reston, VA</city>
<code>20190</code>
<country>USA</country>
</postal>
<phone>+1 703 860 9273</phone>
<email>rpapneja@isocore.com</email>
</address>
</author>
<author initials='B.' surname="Gu" fullname='Bin Gu'>
<organization abbrev='IXIA'>
IXIA
</organization>
<address>
<postal>
<street>Oriental Kenzo Plaza 8M,48 Dongzhimen Wai Street,Dongcheng
District</street>
<city>Beijing</city>
<code>200240</code>
<country>CN</country>
</postal>
<phone>+86 13611590766</phone>
<email>BGu@ixiacom.com</email>
</address>
</author>
<author initials='X.' surname="Wei" fullname='Xueqing Wei'>
<organization abbrev='Fiberhome'>
Fiberhome Telecommunicaiton Technology Co.,Ltd.
</organization>
<address>
<postal>
<street></street>
<city>Wuhan</city>
<code></code>
<country>CN</country>
</postal>
<phone>+86 13871127882</phone>
<email>xqwei@fiberhome.com.cn</email>
</address>
</author>
<date month="November" year="2007"/>
<area>ccamp</area>
<workgroup>ccamp</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for the future data transmission
network. The GMPLS has been developed to control and cooperate
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 dynamically provisioned connections is
increasing because optical networks are being deployed in metro area.
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.</t>
<t>This document provides a series of performance metrics to evaluate
the dynamic LSP provisioning performance in GMPLS networks,
specifically the dynamical LSP setup/release performance. These
metrics can depict the features of the GMPLS network in LSP dynamic
provisioning. They can also be used in operational networks for
carriers to monitor the control plane performance in realtime.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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 cooperate 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.
</t>
<t>
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.
</t>
<t>
This draft intends to define performance metrics and methodologies
that can be used to depict the dynamic connection provisioning
performance of GMPLS networks. The metrics defined in this draft 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
the GMPLS TE STD MIB <xref target="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.
</t>
</section>
<section title="Conventions Used in This Document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>
<section title="Overview of Performance Metrics">
<t>
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,
<xref target="RFC2330"/> <xref target="RFC2679"/> <xref target="RFC2681"/>.
The reader is assumed to be familiar with the notions in those documents.
</t>
</section>
<section title="A Singleton Definition for single unidirectional LSP Setup Delay">
<t>
This part defines a metric for single unidirectional Label Switched Path setup delay
across a GMPLS network.
</t>
<section title="Motivation">
<t> Single unidirectional Label Switched Path setup delay is useful for several
reasons:</t>
<t>
<list style='symbols'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
The measurement of single unidirectional LSP setup delay instead of bidirectional
LSP setup delay is motivated by the following factors:
</t>
<t>
<list style='symbols'>
<t>
Some applications may only use unidirectional LSPs rather than bidirectional ones. For
example, content delivery services in multicast method (IPTV) only use
unidirectional LSPs.
</t>
</list>
</t>
</section>
<section title="Metric Name">
<t> single unidirectional LSP setup delay</t>
</section>
<section title="Metric Parameters">
<t>
<list style='symbols'>
<t>ID0, the ingress LSR ID</t>
<t> ID1, the egress LSR ID</t>
<t>T, a time</t>
</list>
</t>
</section>
<section title="Metric Units">
<t>The value of single unidirectional LSP setup delay is either a real number, or an
undefined (informally, infinite) number of milliseconds.</t>
</section>
<section title="Definition">
<t>The single unidirectional LSP setup delay from the ingress node to the egress node
<xref target="RFC3945"/> at T is dT means that ingress node sends the first bit of a PATH message packet to egress
node at wire-time T, and that the ingress node received the last bit of responding
RESV message packet from egress node at wire-time T+dT in the unidirectional LSP
setup case.</t>
<t>The single unidirectional LSP setup delay from the ingress node to the egress node at T is
undefined (informally, infinite), means that ingress node sends the first bit of
PATH message packet to egress node at wire-time T and that ingress node does not
receive the corresponding RESV message within a reasonable period of time.</t>
</section>
<section title="Discussion">
<t>The following issues are likely to come up in practice:</t>
<t>
<list style='symbols'>
<t>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.</t>
<t>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 the GMPLS network accommodates 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.</t>
<t>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
infinite.</t>
<t>If ingress node sends out the PATH message to set up LSP but receive PathErr
message, unidirectional LSP setup delay is also deemed to be infinite. 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.</t>
</list>
</t>
</section>
<section title="Methodologies">
<t>Generally the methodology would proceed as follows:</t>
<t>
<list style='symbols'>
<t>Make sure that the network has enough resource to set up the requested
LSP.</t>
<t>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. </t>
<t>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.</t>
<t>If the corresponding RESV message fails to arrive within a reasonable
period of time, the unidirectional LSP setup delay is deemed to be undefined
(informally, infinite). Note that the 'reasonable' threshold of the unidirectional LSP setup delay is a
parameter of the methodology.</t>
<t>If the corresponding response message is PathErr, the unidirectional LSP
setup delay is deemed to be undefined (informally, infinite).</t>
</list>
</t>
</section>
</section>
<!-- ....................................................................... -->
<!-- ......................................................................................-->
<!-- ............A Singleton Definition for Multiple uni-directional LSP setup delay.......-->
<!-- ......................................................................................-->
<section title="A Singleton Definition for multiple unidirectional LSP Setup Delay">
<t>
This part defines a metric for multiple unidirectional Label Switched Paths setup delay
across a GMPLS network.
</t>
<section title="Motivation">
<t> multiple unidirectional Label Switched Paths setup delay is useful for several
reasons:</t>
<t>
<list style='symbols'>
<t>
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
</t>
<t>
The time needed to setup a large number of LSPs during a short time period can
not be deduced by single LSP setup delay
</t>
</list>
</t>
</section>
<section title="Metric Name">
<t> multiple unidirectional LSPs setup delay</t>
</section>
<section title="Metric Parameters">
<t>
<list style='symbols'>
<t>ID0, the ingress LSR ID</t>
<t>ID1, the egress LSR ID</t>
<t>Lambda, a rate in reciprocal milliseconds</t>
<t>X, the number of LSPs to setup</t>
<t>T, a time</t>
</list>
</t>
</section>
<section title="Metric Units">
<t>The value of multiple unidirectional LSPs setup delay is either a real number, or an
undefined (informally, infinite) number of milliseconds.</t>
</section>
<section title="Definition">
<t>Given lambda and X, the multiple unidirectional LSPs setup delay from the ingress node to the egress node
<xref target="RFC3945"/> at T is dT means:</t>
<t>
<list style='symbols'>
<t>ingress node sends the first bit of the first PATH message packet to egress node at wire-time T</t>
<t>all subsequent (X-1) PATH messages are sent according to the specified poisson process with arrival rate lambda</t>
<t>ingress node receives all corresponding RESV message packets from egress node, and</t>
<t>ingress node receives the last RESV message packet at wire-time T+dT</t>
</list>
</t>
<t>The multiple unidirectional LSPs setup delay at T is undefined (informally, infinite),
means that ingress node sends all the PATH messages toward the egress and the first bit of the first PATH message
packet is sent at wire-time T and that ingress node does not receive the one or more of the corresponding RESV messages within a
reasonable period of time.</t>
</section>
<section title="Discussion">
<t>The following issues are likely to come up in practice:</t>
<t>
<list style='symbols'>
<t>
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.
</t>
<t>
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 the GMPLS network accommodates 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.
</t>
<t>
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, the unidirectional LSP setup delay is deemed to be
infinite.
</t>
<t>
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 infinite. There are
many possible reasons for this case. For example, one of the PATH message has invalid
parameters or the network has not enough resource to set up the requested LSPs,
etc.
</t>
<t>
The arrival rate of the poisson process lambda 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.
</t>
</list>
</t>
</section>
<section title="Methodologies">
<t>Generally the methodology would proceed as follows:</t>
<t>
<list style='symbols'>
<t>
Make sure that the network has enough resource to set up the requested LSPs.
</t>
<t>
At the ingress node, form the PATH messages according to the LSPs' requirements.
</t>
<t>
At the ingress node, select the time for each of the PATH messages according
to the specified poisson process.
</t>
<t>
At the ingress node, sends out the PATH messages according to the selected time.
</t>
<t>
Store a timestamp (T1) locally in the ingress node when the first PATH message packet
is sent towards the egress node.
</t>
<t>
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.
</t>
<t>
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
(informally, infinite). Note that the 'reasonable' threshold is a parameter of
the methodology.
</t>
<t>
If one of the corresponding response message is PathErr, the multiple unidirectional LSPs
setup delay is deemed to be undefined (informally, infinite).
</t>
</list>
</t>
</section>
</section>
<!-- ......................................................................................-->
<!-- ............A Singleton Definition for single Bidirectional LSP setup delay...........-->
<!-- ......................................................................................-->
<section title="A Singleton Definition for single Bidirectional LSP Setup Delay">
<t>
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.
</t>
<section title="Motivation">
<t>
Single bidirectional Label Switched Path setup delay is useful for several reasons:
</t>
<t>
<list style='symbols'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
The measurement of single bidirectional LSP setup delay instead of unidirectional LSP
setup delay is motivated by the following factors:
</t>
<t>
<list style='symbols'>
<t>
Bidirectional LSPs are seen as a requirement for many GMPLS networks. Its provisioning
performance is important to applications that generates bi-directional traffic.
</t>
</list>
</t>
</section>
<section title="Metric Name">
<t>Single bidirectional LSP setup delay</t>
</section>
<section title="Metric Parameters">
<t>
<list style='symbols'>
<t>ID0, the ingress LSR ID</t>
<t>ID1, the egress LSR ID</t>
<t>T, a time</t>
</list>
</t>
</section>
<section title="Metric Units">
<t>The value of single bidirectional LSP setup delay is either a real number, or an
undefined (informally, infinite) number of milliseconds.</t>
</section>
<section title="Definition">
<t>For a real number dT, the single bidirectional LSP setup delay from ingress node to
egress node at T is dT, means that ingress node sends out the first bit of a PATH
message including an Upstream Label <xref target="RFC3473"/> heading for egress node at wire-time T,
egress node receives that packet, then immediately sends a RESV message packet back
to ingress node, and that ingress node receives the last bit of that packet at
wire-time T+dT.</t>
<t>The single bidirectional LSP setup delay from ingress node to egress node at T is
undefined (informally, infinite), means that ingress node sends the first bit of
PATH message to egress node at wire-time T and that ingress node does not receive
that response packet.</t>
</section>
<section title="Discussion">
<t>
The following issues are likely to come up in practice:</t>
<t>
<list style='symbols'>
<t>
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.
</t>
<t>
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 the GMPLS network accommodates 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 chosen carefully.
</t>
<t>
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 infinite.
</t>
<t>
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
infinite. 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.
</t>
</list>
</t>
</section>
<section title="Methodologies">
<t>Generally the methodology would proceed as follows:</t>
<t>
<list style='symbols'>
<t>Make sure that the network has enough resource to set up the requested
LSP.</t>
<t>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.</t>
<t>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.</t>
<t>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
(informally, infinite). Note that the 'reasonable' threshold is a parameter of
the methodology.</t>
<t>If the corresponding response message is PathErr, the single bidirectional LSP
setup delay is deemed to be undefined (informally, infinite).</t>
</list>
</t>
</section>
</section>
<!-- ......................................................................................-->
<!-- ............A Singleton Definition for multiple Bidirectional LSP setup delay.........-->
<!-- ......................................................................................-->
<section title="A Singleton Definition for multiple Bidirectional LSPs Setup Delay">
<t>
This part defines a metric for multiple bidirectional LSPs setup delay across a GMPLS network.
</t>
<section title="Motivation">
<t>
multiple Bidirectional LSPs setup delay is useful for several reasons:
</t>
<t>
<list style='symbols'>
<t>
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
</t>
<t>
The time needed to setup a large number of LSPs during a short time period can
not be deduced by single LSP setup delay
</t>
</list>
</t>
</section>
<section title="Metric Name">
<t>Multiple bidirectional LSPs setup delay</t>
</section>
<section title="Metric Parameters">
<t>
<list style='symbols'>
<t>ID0, the ingress LSR ID</t>
<t>ID1, the egress LSR ID</t>
<t>Lambda, a rate in reciprocal milliseconds</t>
<t>X, the number of LSPs to setup</t>
<t>T, a time</t>
</list>
</t>
</section>
<section title="Metric Units">
<t>The value of multiple bidirectional LSPs setup delay is either a real number, or an
undefined (informally, infinite) number of milliseconds.</t>
</section>
<section title="Definition">
<t>
Given lambda 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:
</t>
<t>
<list style='symbols'>
<t>ingress node sends the first bit of the first PATH message heading for egress node at wire-time T</t>
<t>all subsequent (X-1) PATH messages are sent according to the specified poisson process with arrival rate lambda</t>
<t>ingress node receives all corresponding RESV message packets from egress node, and</t>
<t>ingress node receives the last RESV message packets at wire-time T+dT</t>
</list>
</t>
<t>
The multiple bidirectional LSPs setup delay from ingress node to egress node at T is
undefined (informally, infinite), means that ingress node sends all the
PATH messages to egress node and that the ingress node dose not receive one or more of the response messages.
</t>
</section>
<section title="Discussion">
<t>
The following issues are likely to come up in practice:</t>
<t>
<list style='symbols'>
<t>
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.
</t>
<t>
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 the GMPLS network accommodates 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 chosen carefully.
</t>
<t>
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 infinite.
</t>
<t>
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
infinite. 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 LSPs.
</t>
<t>
The arrival rate of the poisson process lambda 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.
</t>
</list>
</t>
</section>
<section title="Methodologies">
<t>Generally the methodology would proceed as follows:</t>
<t>
<list style='symbols'>
<t>
Make sure that the network has enough resource to set up the requested LSPs.
</t>
<t>
At the ingress node, form the PATH messages (including the Upstream Label or
suggested label) according to the LSPs' requirements.
</t>
<t>
At the ingress node, select the time for each of the PATH messages according
to the specified poisson process.
</t>
<t>
At the ingress node, sends out the PATH messages according to the selected time.
</t>
<t>
Store a timestamp (T1) locally in the ingress node when the first PATH message packet
is sent towards the egress node.
</t>
<t>
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.
</t>
<t>
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
(informally, infinite). Note that the 'reasonable' threshold is a parameter of
the methodology.
</t>
<t>
If one or more of the corresponding response messages is PathErr, the multiple bidirectional LSPs
setup delay is deemed to be undefined (informally, infinite).
</t>
</list>
</t>
</section>
</section>
<!-- ......................................................................................-->
<!-- ............A Singleton Definition for LSP Graceful Release Delay.....................-->
<!-- ......................................................................................-->
<section title="A Singleton Definition for LSP Graceful Release Delay">
<t>
There are two different kinds of LSP release mechanisms in the GMPLS network:
graceful release and forceful release. Memo in current version has not
taken forceful LSP release procedure into account.
</t>
<section title="Motivation">
<t>
LSP graceful release delay is useful for several reasons:
</t>
<t>
<list style='symbols'>
<t>
The LSP graceful release delay is part of the total cost of dynamic LSP
provisioning. For some short duration applications, the LSP tear down
time can not be ignored
</t>
<t>
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 <xref
target="RFC4208"/>.
</t>
</list>
</t>
</section>
<section title="Metric Name">
<t>
LSP graceful release delay
</t>
</section>
<section title="Metric Parameters">
<t>
<list style='symbols'>
<t>ID0, the ingress LSR ID</t>
<t>ID1, the egress LSR ID</t>
<t>T, a time</t>
</list>
</t>
</section>
<section title="Metric Units">
<t>The value of LSP graceful release delay is either a real number, or an
undefined (informally, infinite) number of milliseconds.</t>
</section>
<section title="Definition">
<t>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 <xref target="RFC3473"/>. We define the graceful LSP release
delay for these two procedures separately.</t>
<t>For a real number dT, the LSP graceful release delay from ingress node to
egress node at T is dT, means that ingress node 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 receives that packet, then
immediately sends a RESV message including Admin Status Object with the Delete (D)
bit set back to ingress node. The ingress node sends out PathTear downstream to
remove the LSP, and egress node receives the last bit of PathTear packet at
wire-time T+dT.</t>
<t>
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 may respond with
PathErr message with the Path_State_Removed flag set.
</t>
<t>The LSP graceful release delay from ingress node to egress node at T is
undefined (informally, infinite), means that ingress node sends the first bit of
PATH message to egress node 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
does not receive the PathTear.</t>
<t>The LSP graceful release delay from egress node to ingress node at T is dT,
means that egress node 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 sends out PathTear downstream to remove the LSP,
and egress node receives the last bit of PathTear packet at wire-time T+dT.</t>
<t>The LSP graceful release delay from egress node to ingress node at T is
undefined (informally, infinite), means that egress node sends the first bit of
RESV message including Admin Status Object with setting the Reflect (R) and Delete
(D) bits to ingress node 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 does not receive the PathTear.</t>
</section>
<section title="Discussion">
<t>The following issues are likely to come up in practice:</t>
<t>
<list style='symbols'>
<t>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;</t>
<t>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;</t>
<t>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 infinite. 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
infinite;</t>
</list>
</t>
</section>
<section title="Methodologies">
<t>In the first circumstance, the methodology may proceed as follows:</t>
<t>
<list style='symbols'>
<t>Make sure the LSP to be deleted is set up;</t>
<t>At the egress 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;</t>
<t>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;</t>
<t>When the ingress node receive the RESV message or the PathErr message,
it sends a PathTear message to remove the LSP;</t>
<t>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).</t>
</list>
</t>
<t>In the second circumstance, the methodology would proceed as follows:</t>
<t>
<list style='symbols'>
<t>Make sure the LSP to be deleted is set up;</t>
<t>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;</t>
<t>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;</t>
<t>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).</t>
</list>
</t>
</section>
</section>
<!-- ....................................................................... -->
<!-- ......Typical Testing cases of single unidirectional LSP Setup Delay... -->
<!-- ....................................................................... -->
<section title="Typical Testing cases of single Unidirectional LSP Setup Delay">
<t>
Now we define typical test cases of getting unidirectional LSP
setup delay.
</t>
<section title="With no LSP in the Network">
<section title="Motivation">
<t>
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.
</t>
</section>
<section title="Methodologies">
<t>
Make sure that there is no or very few LSPs in the network. The methodology would proceed as follows:
</t>
<t>
<list style='symbols'>
<t>
Set up the LSP using the methodology for the singleton single unidirectional LSP setup delay,
and obtain the value of unidirectional LSP setup delay
</t>
<t>
Release the LSP
</t>
<t>
Repeat this process if multiple samples are needed
</t>
</list>
</t>
<t>
Note that: in case multiple samples are to be obtained, the interval between each process should
be large enough to guarantee the network has already reached a stable state.
</t>
</section>
</section>
<section title="With a Number of LSPs in the Network">
<section title="Motivation">
<t>
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.
</t>
</section>
<section title="Methodologies">
<t>
Setup the required number of LSPs, and wait until the network reaches a stable state, then proceed as follows:
</t>
<t>
<list style='symbols'>
<t>
Set up the LSP using the methodology for the singleton single unidirectional LSP setup delay,
and obtain the value of unidirectional LSP setup delay
</t>
<t>
Release the LSP
</t>
<t>
Repeat this process if multiple samples are needed
</t>
</list>
</t>
<t>
Note that: in case multiple samples are to be obtained, the interval between each process should
be large enough to guarantee the network has already reached a stable state.
</t>
</section>
</section>
</section>
<!-- ....................................................................... -->
<!-- XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -->
<!-- ....................................................................... -->
<section title="Typical Testing cases of multiple Unidirectional LSPs Setup Delay">
<t>
Now we define typical test cases of getting multiple unidirectional LSPs
setup delay.
</t>
<section title="With no LSP in the Network">
<section title="Motivation">
<t>
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 a number of LSPs are setup with the lightest load in the control plane.
</t>
</section>
<section title="Methodologies">
<t>
Make sure that there is no or very few LSPs in the network. The methodology would proceed as follows:
</t>
<t>
<list style='symbols'>
<t>
Set up the LSPs using the methodology for the singleton multiple unidirectional LSP setup delay,
and obtain the value of multiple unidirectional LSP setup delay
</t>
<t>
Release the LSPs
</t>
<t>
Repeat this process if multiple samples are needed
</t>
</list>
</t>
<t>
Note that: in case multiple samples are to be obtained, the interval between each process should
be large enough to guarantee the network has already reached a stable state.
</t>
</section>
</section>
<section title="With a Number of LSPs in the Network">
<section title="Motivation">
<t>
multiple 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.
</t>
</section>
<section title="Methodologies">
<t>
Setup the required number of LSPs, and wait until the network reaches a stable state, then proceed as follows:
</t>
<t>
<list style='symbols'>
<t>
Set up the LSPs using the methodology for the singleton multiple unidirectional LSP setup delay,
and obtain the value of multiple unidirectional LSP setup delay
</t>
<t>
Release the LSPs
</t>
<t>
Repeat this process if multiple samples are needed
</t>
</list>
</t>
<t>
Note that: in case multiple samples are to be obtained, the interval between each process should
be large enough to guarantee the network has already reached a stable state.
</t>
</section>
</section>
</section>
<!-- ....................................................................... -->
<!-- ......Typical Testing cases of single Bidirectional LSP Setup Delay.... -->
<!-- ....................................................................... -->
<section title="Typical Testing cases of single Bidirectional LSP Setup Delay">
<t>
Now we define typical test cases of getting single bidirectional LSP
setup delay.
</t>
<section title="With no LSP in the Network">
<section title="Motivation">
<t>
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.
</t>
</section>
<section title="Methodologies">
<t>
Make sure that there is no or very few LSPs in the network. The methodology would proceed as follows:
</t>
<t>
<list style='symbols'>
<t>
Set up the LSP using the methodology for the singleton bidirectional LSP setup delay,
and obtain the value of unidirectional LSP setup delay
</t>
<t>
Release the LSP
</t>
<t>
Repeat this process if multiple samples are needed
</t>
</list>
</t>
<t>
Note that: in case multiple samples are to be obtained, the interval between each process should
be large enough to guarantee the network has already reached a stable state.
</t>
</section>
</section>
<section title="With a Number of LSPs in the Network">
<section title="Motivation">
<t>
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.
</t>
</section>
<section title="Methodologies">
<t>
Setup the required number of LSPs, and wait until the network reaches a stable state, then proceed as follows:
</t>
<t>
<list style='symbols'>
<t>
Set up the LSP using the methodology for the singleton bidirectional bidirectional LSP setup delay,
and obtain the value of bidirectional LSP setup delay
</t>
<t>
Release the LSP
</t>
<t>
Repeat this process if multiple samples are needed
</t>
</list>
</t>
<t>
Note that: in case multiple samples are to be obtained, the interval between each process should
be large enough to guarantee the network has already reached a stable state.
</t>
</section>
</section>
</section>
<!-- ....................................................................... -->
<!-- .....Typical Testing cases of multiple Bidirectional LSP Setup Delay... -->
<!-- ....................................................................... -->
<section title="Typical Testing cases of multiple Bidirectional LSPs Setup Delay">
<t>
Now we define typical test cases of getting multiple bidirectional LSPs
setup delay.
</t>
<section title="With no LSP in the Network">
<section title="Motivation">
<t>
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 a number of LSPs are setup with the lightest load in the control plane.
</t>
</section>
<section title="Methodologies">
<t>
Make sure that there is no or very few LSPs in the network. The methodology would proceed as follows:
</t>
<t>
<list style='symbols'>
<t>
Set up the LSPs using the methodology for the singleton multiple multiple bidirectional LSP setup delay,
and obtain the value of multiple bidirectional LSP setup delay
</t>
<t>
Release the LSPs
</t>
<t>
Repeat this process if multiple samples are needed
</t>
</list>
</t>
<t>
Note that: in case multiple samples are to be obtained, the interval between each process should
be large enough to guarantee the network has already reached a stable state.
</t>
</section>
</section>
<section title="With a Number of LSPs in the Network">
<section title="Motivation">
<t>
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.
</t>
</section>
<section title="Methodologies">
<t>
Setup the required number of LSPs, and wait until the network reaches a stable state, then proceed as follows:
</t>
<t>
<list style='symbols'>
<t>
Set up the LSPs using the methodology for the singleton multiple bidirectional LSPs setup delay,
and obtain the value of multiple bidirectional LSPs setup delay
</t>
<t>
Release the LSPs
</t>
<t>
Repeat this process if multiple samples are needed
</t>
</list>
</t>
<t>
Note that: in case multiple samples are to be obtained, the interval between each process should
be large enough to guarantee the network has already reached a stable state.
</t>
</section>
</section>
</section>
<!-- ....................................................................... -->
<!-- .....Some Statistics Definitions for Metrics to Report................. -->
<!-- ....................................................................... -->
<section title="Some Statistics Definitions for Metrics to Report">
<t>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 (informally, infinite) number of milliseconds. In the following discussion, we
only consider the finite values.</t>
<section title="The Minimum of Metric">
<t>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 (informally, infinite) if all the
dT values are undefined. In addition, the metric minimum is undefined if the
sample is empty.</t>
</section>
<section title="The Median of Metric">
<t>Metric median is the median of the dT values in the given sample. In computing
the median, the undefined values are not counted in.</t>
</section>
<section title="The percentile of Metric">
<t>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.</t>
<t>Example: suppose we take a sample and the results are: Stream1 = <
<T1, 100 msec>,
<T2, 110 msec>,
<T3, undefined>,
<T4, 90 msec>,
<T5, 500 msec> ></t>
<t>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).</t>
</section>
<section title="The failure probability">
<t>In the process of LSP setup/release, it may fail for some reason. The failure
probability is the ratio of the failure times to the total times.</t>
</section>
</section>
<section title="Discussion">
<t>It is worthwhile to point out that:</t>
<t>
<list style='symbols'>
<t>The unidirectional/bidirectional LSP setup delay is
one ingress-egress round trip time plus processing time. But in the draft,
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.</t>
<t>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.</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>The security considerations pertaining to the original RSVP protocol <xref
target="RFC2205"/> and its TE extensions <xref target="RFC3209"/>
remain relevant.</t>
</section>
<section title="Acknowledgements">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc2205;
&rfc2330;
&rfc2679;
&rfc2681;
&rfc3209;
&rfc3473;
&rfc3945;
&rfc4208;
&rfc4802;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:13:28 |