ccamp W. Sun
Internet-Draft SJTU
Intended status: Standards Track G. Zhang
Expires: May 22, 2008 CATR
J. Gao
Huawei
G. Xie
SJTU
R. Papneja
Isocore
B. Gu
IXIA
X. Wei
Fiberhome
November 19, 2007
Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in
Generalized MPLS Networks
draft-xie-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.
Copyright Notice
Sun, et al. Expires May 22, 2008 [Page 1]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
Copyright (C) The IETF Trust (2007).
Sun, et al. Expires May 22, 2008 [Page 2]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
Abstract
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.
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.
Sun, et al. Expires May 22, 2008 [Page 3]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions Used in This Document . . . . . . . . . . . . . . 7
3. Overview of Performance Metrics . . . . . . . . . . . . . . . 8
4. A Singleton Definition for single unidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 9
4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 11
5. A Singleton Definition for multiple unidirectional LSP
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 12
5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 14
6. A Singleton Definition for single Bidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 15
6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 16
6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 16
6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 17
7. A Singleton Definition for multiple Bidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 18
7.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 18
7.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 18
7.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19
7.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 20
8. A Singleton Definition for LSP Graceful Release Delay . . . . 21
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 21
8.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 21
8.5. Definition . . . . . . . . . . . . . . . . . . . . . . . . 21
8.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22
Sun, et al. Expires May 22, 2008 [Page 4]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
8.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 23
9. Typical Testing cases of single Unidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. With no LSP in the Network . . . . . . . . . . . . . . . . 25
9.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 25
9.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 25
9.2. With a Number of LSPs in the Network . . . . . . . . . . . 25
9.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 25
9.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 25
10. Typical Testing cases of multiple Unidirectional LSPs
Setup Delay . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. With no LSP in the Network . . . . . . . . . . . . . . . . 27
10.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 27
10.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 27
10.2. With a Number of LSPs in the Network . . . . . . . . . . . 27
10.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 27
10.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 27
11. Typical Testing cases of single Bidirectional LSP Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. With no LSP in the Network . . . . . . . . . . . . . . . . 29
11.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 29
11.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 29
11.2. With a Number of LSPs in the Network . . . . . . . . . . . 29
11.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 29
11.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 29
12. Typical Testing cases of multiple Bidirectional LSPs Setup
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. With no LSP in the Network . . . . . . . . . . . . . . . . 31
12.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 31
12.1.2. Methodologies . . . . . . . . . . . . . . . . . . . . 31
12.2. With a Number of LSPs in the Network . . . . . . . . . . . 31
12.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 31
12.2.2. Methodologies . . . . . . . . . . . . . . . . . . . . 31
13. Some Statistics Definitions for Metrics to Report . . . . . . 33
13.1. The Minimum of Metric . . . . . . . . . . . . . . . . . . 33
13.2. The Median of Metric . . . . . . . . . . . . . . . . . . . 33
13.3. The percentile of Metric . . . . . . . . . . . . . . . . . 33
13.4. The failure probability . . . . . . . . . . . . . . . . . 33
14. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. Security Considerations . . . . . . . . . . . . . . . . . . . 35
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
17. Normative References . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 40
Sun, et al. Expires May 22, 2008 [Page 5]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
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 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.
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 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 [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 May 22, 2008 [Page 6]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
2. Conventions Used in This Document
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 [RFC2119].
Sun, et al. Expires May 22, 2008 [Page 7]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
3. 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 May 22, 2008 [Page 8]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
4. 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.
4.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.
4.2. Metric Name
single unidirectional LSP setup delay
4.3. Metric Parameters
o ID0, the ingress LSR ID
o ID1, the egress LSR ID
Sun, et al. Expires May 22, 2008 [Page 9]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o T, a time
4.4. Metric Units
The value of single unidirectional LSP setup delay is either a real
number, or an undefined (informally, infinite) number of
milliseconds.
4.5. Definition
The single unidirectional LSP setup delay from the ingress node to
the egress node [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.
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.
4.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 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 chosen 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 infinite.
Sun, et al. Expires May 22, 2008 [Page 10]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o 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.
4.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 (informally, infinite). Note that the
'reasonable' threshold of the unidirectional LSP setup delay is a
parameter of the methodology.
o If the corresponding response message is PathErr, the
unidirectional LSP setup delay is deemed to be undefined
(informally, infinite).
Sun, et al. Expires May 22, 2008 [Page 11]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
5. 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.
5.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 set up a large number of LSPs during a short
time period can not be deduced by single LSP setup delay
5.2. Metric Name
multiple unidirectional LSPs setup delay
5.3. Metric Parameters
o ID0, the ingress LSR ID
o ID1, the egress LSR ID
o Lambda, a rate in reciprocal milliseconds
o X, the number of LSPs to set up
o T, a time
5.4. Metric Units
The value of multiple unidirectional LSPs setup delay is either a
real number, or an undefined (informally, infinite) number of
milliseconds.
5.5. Definition
Given lambda 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 sends the first bit of the first PATH message packet
to egress node at wire-time T
Sun, et al. Expires May 22, 2008 [Page 12]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o all subsequent (X-1) PATH messages are sent according to the
specified poisson process with arrival rate lambda
o ingress node receives all corresponding RESV message packets from
egress node, and
o ingress node receives the last RESV message packet at wire-time
T+dT
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.
5.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 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 chosen 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, the unidirectional LSP setup delay is deemed to be
infinite.
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 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.
Sun, et al. Expires May 22, 2008 [Page 13]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o 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.
5.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 (informally, infinite).
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
(informally, infinite).
Sun, et al. Expires May 22, 2008 [Page 14]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
6. 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.
6.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.
6.2. Metric Name
Single bidirectional LSP setup delay
6.3. Metric Parameters
Sun, et al. Expires May 22, 2008 [Page 15]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o ID0, the ingress LSR ID
o ID1, the egress LSR ID
o T, a time
6.4. Metric Units
The value of single bidirectional LSP setup delay is either a real
number, or an undefined (informally, infinite) number of
milliseconds.
6.5. Definition
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
[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.
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.
6.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 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
Sun, et al. Expires May 22, 2008 [Page 16]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
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 infinite.
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 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.
6.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 (informally, infinite). 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
(informally, infinite).
Sun, et al. Expires May 22, 2008 [Page 17]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
7. A Singleton Definition for multiple Bidirectional LSPs Setup Delay
This part defines a metric for multiple bidirectional LSPs setup
delay across a GMPLS network.
7.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
7.2. Metric Name
Multiple bidirectional LSPs setup delay
7.3. Metric Parameters
o ID0, the ingress LSR ID
o ID1, the egress LSR ID
o Lambda, a rate in reciprocal milliseconds
o X, the number of LSPs to setup
o T, a time
7.4. Metric Units
The value of multiple bidirectional LSPs setup delay is either a real
number, or an undefined (informally, infinite) number of
milliseconds.
7.5. Definition
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:
o ingress node sends the first bit of the first PATH message heading
for egress node at wire-time T
Sun, et al. Expires May 22, 2008 [Page 18]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o all subsequent (X-1) PATH messages are sent according to the
specified poisson process with arrival rate lambda
o ingress node receives all corresponding RESV message packets from
egress node, and
o ingress node 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 (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.
7.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 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.
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 infinite.
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
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.
Sun, et al. Expires May 22, 2008 [Page 19]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o 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.
7.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 (informally, infinite).
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 (informally, infinite).
Sun, et al. Expires May 22, 2008 [Page 20]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
8. A Singleton Definition for LSP Graceful Release Delay
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.
8.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 tear down 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].
8.2. Metric Name
LSP graceful release delay
8.3. Metric Parameters
o ID0, the ingress LSR ID
o ID1, the egress LSR ID
o T, a time
8.4. Metric Units
The value of LSP graceful release delay is either a real number, or
an undefined (informally, infinite) number of milliseconds.
8.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 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
Sun, et al. Expires May 22, 2008 [Page 21]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
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.
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.
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.
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.
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.
8.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 May 22, 2008 [Page 22]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
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 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;
8.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 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;
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).
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;
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;
Sun, et al. Expires May 22, 2008 [Page 23]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
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).
Sun, et al. Expires May 22, 2008 [Page 24]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
9. Typical Testing cases of single Unidirectional LSP Setup Delay
Now we define typical test cases of getting unidirectional LSP setup
delay.
9.1. With no LSP in the Network
9.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.
9.1.2. Methodologies
Make sure that there is no or very few LSPs in the network. The
methodology would proceed as follows:
o Set up the LSP using the methodology for the singleton single
unidirectional LSP setup delay, and obtain the value of
unidirectional LSP setup delay
o Release the LSP
o Repeat this process if multiple samples are needed
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.
9.2. With a Number of LSPs in the Network
9.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.
9.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed as follows:
Sun, et al. Expires May 22, 2008 [Page 25]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o Set up the LSP using the methodology for the singleton single
unidirectional LSP setup delay, and obtain the value of
unidirectional LSP setup delay
o Release the LSP
o Repeat this process if multiple samples are needed
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.
Sun, et al. Expires May 22, 2008 [Page 26]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
10. Typical Testing cases of multiple Unidirectional LSPs Setup Delay
Now we define typical test cases of getting multiple unidirectional
LSPs setup delay.
10.1. With no LSP in the Network
10.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 a number of LSPs are set up
with the lightest load in the control plane.
10.1.2. Methodologies
Make sure that there is no or very few LSPs in the network. The
methodology would proceed as follows:
o 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
o Release the LSPs
o Repeat this process if multiple samples are needed
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.
10.2. With a Number of LSPs in the Network
10.2.1. Motivation
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.
10.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed as follows:
Sun, et al. Expires May 22, 2008 [Page 27]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o 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
o Release the LSPs
o Repeat this process if multiple samples are needed
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.
Sun, et al. Expires May 22, 2008 [Page 28]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
11. Typical Testing cases of single Bidirectional LSP Setup Delay
Now we define typical test cases of getting single bidirectional LSP
setup delay.
11.1. With no LSP in the Network
11.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.
11.1.2. Methodologies
Make sure that there is no or very few LSPs in the network. The
methodology would proceed as follows:
o Set up the LSP using the methodology for the singleton
bidirectional LSP setup delay, and obtain the value of
unidirectional LSP setup delay
o Release the LSP
o Repeat this process if multiple samples are needed
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.
11.2. With a Number of LSPs in the Network
11.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.
11.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed as follows:
Sun, et al. Expires May 22, 2008 [Page 29]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o Set up the LSP using the methodology for the singleton
bidirectional bidirectional LSP setup delay, and obtain the value
of bidirectional LSP setup delay
o Release the LSP
o Repeat this process if multiple samples are needed
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.
Sun, et al. Expires May 22, 2008 [Page 30]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
12. Typical Testing cases of multiple Bidirectional LSPs Setup Delay
Now we define typical test cases of getting multiple bidirectional
LSPs setup delay.
12.1. With no LSP in the Network
12.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 a number of LSPs are setup
with the lightest load in the control plane.
12.1.2. Methodologies
Make sure that there is no or very few LSPs in the network. The
methodology would proceed as follows:
o 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
o Release the LSPs
o Repeat this process if multiple samples are needed
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.
12.2. With a Number of LSPs in the Network
12.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.
12.2.2. Methodologies
Setup the required number of LSPs, and wait until the network reaches
a stable state, then proceed as follows:
Sun, et al. Expires May 22, 2008 [Page 31]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
o 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
o Release the LSPs
o Repeat this process if multiple samples are needed
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.
Sun, et al. Expires May 22, 2008 [Page 32]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
13. 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 (informally,
infinite) number of milliseconds. In the following discussion, we
only consider the finite values.
13.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 (informally, infinite) if all the dT values are
undefined. In addition, the metric minimum is undefined if the
sample is empty.
13.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.
13.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 = <
<T1, 100 msec>, <T2, 110 msec>, <T3, undefined>, <T4, 90 msec>, <T5,
500 msec> >
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).
13.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 failure times to the
total times.
Sun, et al. Expires May 22, 2008 [Page 33]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
14. 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 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.
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 May 22, 2008 [Page 34]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
15. Security Considerations
The security considerations pertaining to the original RSVP protocol
[RFC2205] and its TE extensions [RFC3209] remain relevant.
Sun, et al. Expires May 22, 2008 [Page 35]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
16. 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 May 22, 2008 [Page 36]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
17. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
[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.
Sun, et al. Expires May 22, 2008 [Page 37]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
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 May 22, 2008 [Page 38]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
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
Sun, et al. Expires May 22, 2008 [Page 39]
Internet-Draft LSP Dynamical PPM in GMPLS Networks November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sun, et al. Expires May 22, 2008 [Page 40]