Delay and Loss Traffic Engineering Problem Statement for MPLS
draft-fuxh-mpls-delay-loss-te-problem-statement-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Xihua Fu , Malcolm Betts , Qilei Wang , Vishwas Manral , Dave McDysan , Andrew G. Malis , Spencer Giacalone , John Drake | ||
| Last updated | 2012-10-15 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fuxh-mpls-delay-loss-te-problem-statement-00
Network Working Group X. Fu, M. Betts, Q. Wang
Internet Draft ZTE
Intended Status: Informational V. Manral
Expires: April 14, 2013 Hewlett-Packard Corp.
D. McDysan, A. Malis
Verizon
S. Giacalone
Thomson Reuters
J. Drake
Juniper Networks
October 15, 2012
Delay and Loss Traffic Engineering Problem Statement for MPLS
draft-fuxh-mpls-delay-loss-te-problem-statement-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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
This Internet-Draft will expire on February 27, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document
authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) in
effect on the date of publication of this document. Please review these
documents carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this document
must include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
McDysan Expires April 14, 2013 [Page 1]
Abstract
Deployment and usage of cloud based applications and services that use
an underlying MPLS network are expanding and an increasing number of
applications are extremely sensitive to delay and packet loss.
Furthermore, in cloud computing an additional decision problem arises of
simultaneously choosing the data center to host applications along with
MPLS network connectivity such that the overall performance of the
application is met. Existing mechanisms exist to measure and monitor
MPLS path performance parameters for packet loss and delay, but only
after the path has been setup. These cloud-based and performance
sensitive applications would benefit from measurement of MPLS network
and potential path information that would be provided for use in the
computation and selection of LSPs.
This document provides a statement of problems faced by these cloud
based and performance sensitive applications and describes requirements
to enable the efficient and accurate measurement of the MPLS network and
allow new performance parameters to be reported and used in the
computation of MPLS services in support of these cloud based and
performance sensitive applications.
Table of Contents
1. Introduction...................................................3
1.1. Scope.....................................................3
2. Conventions used in this document..............................3
2.1. Acronyms..................................................3
2.2. Terminology and Assumptions...............................4
2.2.1. Latency..............................................4
2.2.2. Packet Loss..........................................4
2.2.3. Packet Delay Variation...............................4
3. Motivation and Background......................................5
3.1. General Characteristics of Performance Parameters.........5
3.2. Use Cases for Performance Parameter Sensitive LSP Placement5
4. Problem Statement..............................................6
4.1. End-end Measurement Insufficient for Performance Sensitive LSP
Path Selection.................................................6
4.2. Lower Layer MPLS Networks Unable to Communicate Significant
Performance Changes............................................7
4.3. No Method to Communicate Significant Node/Link Performance
Changes........................................................7
4.4. Routing Metrics Insufficient for Performance Sensitive Path
Selection......................................................7
4.5. LSP Signaling Methods Insufficient for Performance Sensitive
Path Selection.................................................8
5. Functional Requirements........................................8
5.1. Augment LSP Requestor Signaling with Performance Parameter
Values.........................................................8
5.2. Specify Criteria for Node and Link Performance Parameter
Estimation, Measurement Methods................................9
5.3. Support Node Level Performance Information when Needed....9
5.4. Augment Routing Information with Performance Parameter Estimates
..............................................................10
5.5. Augment Signaling Information with Concatenated Estimates10
Fu et al Expires April 14, 2013 [Page 2]
5.6. Define Significant Performance Parameter Change Thresholds and
Frequency.....................................................10
5.7. Define Thresholds and Timers for Links with Unusable Performance
..............................................................10
5.8. Communicate Significant Performance Changes between Layers11
5.9. Support for Networks with Composite Link.................11
5.10. Restoration, Protection and Rerouting...................11
5.11. Management and Operational Requirements.................12
6. IANA Considerations...........................................12
7. Security Considerations.......................................12
8. References....................................................12
8.1. Normative References.....................................12
8.2. Informative References...................................12
9. Acknowledgments...............................................13
1. Introduction
This draft is one of two created from draft-fuxh-mpls-delay-loss-te-
framework-05 in response to comments from an MPLS Review Team (RT). This
draft focuses on a problem statement and requirements while the other
focuses on a framework.
The intent of this document is to focus on stating the technical aspects
of the application oriented problems to be solved and specific
requirements targeted to solve these problems.
It describes requirements and application needs for bounded values of
latency, packet loss and delay variation.
1.1. Scope
A (G)MPLS network may have multiple layers of packet, TDM and/or optical
network technology and an important objective is to make a prediction of
end-to-end latency, loss and delay variation based upon the current
state of this network with acceptable accuracy before an LSP is
established.
The (G)MPLS network may cover a single IGP area/level, may be a
hierarchical IGP under control of a single administrator, or may involve
multiple domains under control of multiple administrators.
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 RFC-2119 [RFC2119].
2.1. Acronyms
SLA Service Level Agreement
SLS Service Level Specification
NPO Network Performance Objective
Fu et al Expires April 14, 2013 [Page 3]
2.2. Terminology and Assumptions
A Service Level Agreement (SLA) is a contractual agreement that service
providers have with customers for services comprised of numerical values
for performance measures; for example, latency, loss and delay
variation. Additionally, network operators may have Service Level
Specification (SLS) that is for internal use by the operator. See [ITU-
T.Y.1540], [ITU-T.Y.1541], RFC 3809, Section 4.9 [RFC3809] for examples
of the form of such SLA and SLS specifications.
Network Performance Objective (NPO) is defined in section 5 of [ITU-
T.Y.1541] in terms of numerical values for performance measures,
principally latency, loss, and delay variation.. The term NPO is used in
this document since the SLA and SLS measures have network operator and
service specific implications. Furthermore, the NPO measures are
sufficiently well defined to address other use cases and the stated
problems.
Of particular interest is the composition methods defined in Y.1541 for
estimating performance parameters of candidate LSP paths based upon the
performance parameter estimates/measurements of individual nodes and
links.
This document assumes that the evaluation interval for a performance
parameter is on the order of minutes as stated in [ITU-T Y.1541, 5.3.2],
which is the same of that used in some commercial networks.
2.2.1. Latency
Section 6.2.1 of [ITU-T Y.1540] defines mean IP Packet Transfer Delay
(IPTD) as the arithmetic average of the one-way delay observed between
measurement points IPTD is referred to as "latency" in this document.
Section 8.2.1 of [ITU-T Y.1541] defines composition of the IPTD UNI-UNI
performance parameter as "the mean IP packet transfer delay (IPTD)
performance parameter, the UNI-UNI performance is the sum of the means
contributed by network sections."
2.2.2. Packet Loss
Section 6.4 of [ITU-T Y.1540] defines IP Packet Loss Ratio (IPLR) as the
"ratio of total lost IP packet outcomes to total transmitted IP packets
in a population of interest," which is referred to as "loss" in this
document.
Section 8.2.2 of [ITU-T Y.1541] defines composition of the IPLR UNI-UNI
performance parameter as "may be estimated by inverting the probability
of successful packet transfer across n network sections."
2.2.3. Packet Delay Variation
Section 6.2.4.2 of [ITU-T Y.1540] defines quantile-based limits on IP
Packet Delay Variation (IPDV), which is referred to as "delay variation"
in this document.
Fu et al Expires April 14, 2013 [Page 4]
Section 8.2.4 of [ITU-T Y.1541] defines composition of the IPDV UNI-UNI
performance parameter as "must recognize their sub-additive nature and
it is difficult to estimate accurately without considerable information
about the individual delay distributions." Appendix IV of [ITU-T Y.1541]
gives several examples of IPDV estimate calculations.
3. Motivation and Background
3.1. General Characteristics of Performance Parameters
In general, nodes and links may contribute to the performance
parameters.
For many applications, the latency NPO is very important. In networks
with wide geographic separation, propagation delay may dominate latency,
while in local or metro networks nodal latency may become important.
Some link technologies (e.g., wireless, wifi, satellite) may have packet
loss characteristics inherently different from those of other link
technologies(e.g., fiber optic, cable) networks. Furthermore, the
loading of queues may also create packet loss.
Delay variation (sometimes also referred to as packet jitter) is
important to some applications, such as interactive voice, video and/or
multimedia communication, gaming, and simulations. If delay varies too
much, then a playback buffer for such applications may underflow or
overflow, resulting in a disruption to the application. Delay variation
is caused primarily by queuing within a node.
3.2. Use Cases for Performance Parameter Sensitive LSP Placement
In High Frequency trading for Electronic Financial markets, computers
make decisions based on the Electronic Data received, without human
intervention. These trades now account for a majority of the trading
volumes and rely exclusively on ultra-low-latency direct market access.
In certain networks, such as financial information networks (e.g. stock
market data providers), network performance information (e.g. latency)
is critical to data path selection. In these networks, extremely large
amounts of money rest on the ability to access market data as quickly as
possible and to predictably make trades faster than the competition.
Using metrics such as hop count or link cost as routing may not always
meet this need. In such networks it would be beneficial to be able to
make path selection decisions based on performance data (such as
latency) in a cost-effective and scalable way.
In other networks, for example, network-based VPNs there are in place
between a customer and a provider a Service Level Agreement (SLA) which
specifies performance objectives, such as latency, loss, and delay
variation. In some cases these performance objectives are defined
between specific customer locations. Furthermore, packets may be
associated with certain classes as identified by packet header fields
(e.g., IP DSCP, IEEE P-bits, MPLS TC bits) that are associated with
different performance objectives. In these types of networks, the
objective is to provide service that is no worse than the performance
objective. A single SLA may support many customers of the same type.
Fu et al Expires April 14, 2013 [Page 5]
There is also a need to support specific SLAs, typically for very large
customers who demand premium performance for which they are willing to
pay a premium price.
In emerging cloud-based services, an additional decision problem where
the application may be placed in a choice of more than one data center
and the (G)MPLS network connectivity may also be chosen [CLO, CSO]. In
these types of applications, the objective so to meet the overall
performance of the application deployed in one more or more data
centers. The performance of the intra- data center performance
component is out of scope of this draft, but this overall cloud plus
networking decision problem would benefit from a prediction of the MPLS
network performance as part of path establishment.
4. Problem Statement
With the use cases in the previous section as motivation, there are
several technical problems that currently standardized IETF protocols do
not adequately address:
o End-end Measurement Insufficient for Performance Sensitive LSP Path
o Routing Metrics Insufficient for Performance Sensitive Path Selection
o LSP Signaling Methods Insufficient for Performance Sensitive Path
Selection
o Lower Layer MPLS Networks Unable to Communicate Significant
Performance Changes
o No Method to Communicate Significant Node/Link Performance Changes
The following sections expand on each of these technical problem areas
in more detail. Although some of the problem statements are made in
terms of existing/proposed protocols, there is no intention to imply
that the solution requires a revision to these protocols.
4.1. End-end Measurement Insufficient for Performance Sensitive LSP Path
Selection
Methods exist to measure established LSP performance, e.g., [RFC 6374]
for MPLS-TP, and are most useful in verifying support for an NPO. RFC
6374 specifies a mechanism to measure and monitor performance parameters
for packet loss, and one-way and two-way latency, delay variation and
throughput. However, if measured performance is not met for an LSP there
is not a standardized method to aid in an LSP originator or a proxy
(e.g., PCE) to select a modified path that would meet the performance
objective.
Therefore, there is a need to enable path computation that has access to
an up to date recent performance estimate.
Fu et al Expires April 14, 2013 [Page 6]
4.2. Lower Layer MPLS Networks Unable to Communicate Significant
Performance Changes
Historically, when an IP/MPLS network was operated over a lower layer
circuit switched network (e.g., SONET rings), a change in latency caused
by the lower layer network (e.g., due to a maintenance action or
failure) this was not known to the MPLS network. This resulted in
latency affecting end user experience, sometimes violating NPO, SLS
and/or SLA values and/or resulting in user complaints.
Using lower layer networks to provide restoration and grooming may be
more efficient than performing packet only restoration, but the
inability to communicate performance parameters, in particular latency,
from the lower layer network to the higher layer network is an important
problem to be solved in not only the composite link case [CL-REQ,
section 4.2], but also in the case of single links connecting nodes.
In summary, Multi-layer GMPLS networks do not have a means to
communicate a significant change in performance (e.g., latency) from one
layer to another.
4.3. No Method to Communicate Significant Node/Link Performance Changes
Performance characteristics of links and nodes may change dynamically in
response to a number of events. There is currently no way to
automatically indicate which nodes and/or links have had significant
performance changes to LSP originators or proxies so that they can
attempt to recompute and signal a path that would meet the LSP
performance objective.
4.4. Routing Metrics Insufficient for Performance Sensitive Path Selection
Optimization on a single metric does not meet the needs for all cases of
performance sensitive path selection. In some cases, minimizing latency
relates directly to the best customer experience (e.g., in TCP closer is
faster or in financial trading the absolute minimum latency possible
provides a competitive advantage). In other cases, user experience is
relatively insensitive to latency, up to a specific limit at which point
user perception of quality degrades significantly (e.g., interactive
human voice and multimedia conferencing). A number of NPOs have a bound
on point-point latency, and as long as this bound is met, the NPO is met
-- decreasing the latency is not necessary. In some NPOs, if the
specified latency is not met, the user considers the service as
unavailable. An unprotected LSP can be manually provisioned on a set of
links to meet this type of NPO, but this lowers availability since an
alternate route that meets the latency NPO cannot be determined.
One operational approach is to provision IP/MPLS networks over
unprotected circuits and set the metric and/or TE-metric proportional to
latency. This resulted in traffic being directed over the least latency
path, even if this was not needed to meet an NPO or user experience
objectives. This results in reduced flexibility and increased cost for
network operators. However, the (TE) metric is often used to represent
other information, such as link speed, economic cost or in support of
ECMP (as described below) and may not be able to be set to be
Fu et al Expires April 14, 2013 [Page 7]
proportional to latency. Furthermore, if performance metrics such as
loss and delay variation are to be supported in path selection, then
proportional mapping is not possible.
Link attributes and LSP affinities [RFC 3209] can be used operationally
to encode some information regarding performance, for example,
indicating wired versus wireless, satellite versus terrestrial, etc.
However, these attributes/affinities are used to encode other attributes
and the 32 bit format is limiting in terms of numerical representation
of performance objective parameters.
Another operational approach is to set (TE) metrics to (nearly) the same
value so that LSPs are placed across multiple links using Equal Cost
Multi-Path (ECMP) path selection. However, these parallel links may
have markedly different performance characteristics (e.g., latency) and
choice of a link that meets the performance objective is needed [CL-REQ,
section 4.3].
IGP link and TE metrics are not sufficient to support performance
sensitive path selection in a single IGP area/level [EXPRESS-PATH].
4.5. LSP Signaling Methods Insufficient for Performance Sensitive Path
Selection
Current signaling approaches do not support inter area/level or inter-
domain performance sensitive path selection. There is no standard for
setting link attributes and LSP resource affinities [RFC 3209] between
administrative domains, and since these have been used within some
domains they are not a viable candidate to solve the aforementioned
problems in this context. Augmenting an IGP with performance information
does not solve the problem in these cases.
What is needed is a means for the originator/proxy of an LSP to confirm
whether the estimated performance of a computed LSP path will meet the
performance objective.
5. Functional Requirements
This section groups functional requirements intended to address the
problems stated in the previous section into related areas.
5.1. Augment LSP Requestor Signaling with Performance Parameter Values
The solution needs to provide a means for an LSP requestor to signal
performance parameter sensitive paths. The following requirements state
the types of requests that are required.
The solution MUST provide a means to indicate which performance
parameters are supported by the network area/level or domain.
The solution MUST provide a means for the LSP requestor to ask for the
minimum possible value for each supported performance parameter.
For example, an LSP requestor may ask for an LSP that has the minimum
possible value of latency.
Fu et al Expires April 14, 2013 [Page 8]
The solution MUST provide a means for the LSP requestor to ask for a
range of acceptable values for each supported performance parameter.
For example, an LSP requestor may ask for an LSP that has performance
between a minimum value of latency and packet loss and a maximum value
of latency and packet.
5.2. Specify Criteria for Node and Link Performance Parameter Estimation,
Measurement Methods
The solution MUST provide a means to configure the one-way link and node
performance parameters for latency, loss and delay variation.
The solution SHOULD provide a means to dynamically measure and/or
estimate the one-way link and node performance parameters for latency,
loss and delay variation.
As defined in section 2.2. , the estimation interval for the performance
parameters is assumed to be on the order of minutes. The solution MUST
not impact stability nor significantly increase convergence time if
performance parameters change over a timeframe on the order of minutes.
5.3. Support Node Level Performance Information when Needed
There are several scenarios under which node-related performance
parameters (latency, loss, delay variation) has a different level of
importance:
1. The case of few nodes with large geographic separation, (e.g.,trans-
oceanic), where link latency alone would be a good approximation.
2. The case of many nodes with small geographic separation (e.g.,
interconnected nearby data centers) where node/device latency is very
important but link latency may be negligible.
3. The case of some number of nodes with medium geographic separation,
where usage of both link and node latency may be desirable.
The intent in case 1 is to measure the predominant latency in
uncongested service provider networks, where geographic delay dominates
and is on the order of milliseconds or more. The argument in cases 2
and 3 for including node-level queuing performance parameters is that it
better represents the performance experienced by applications. The
argument against including queuing related performance parameters is
that it if used in routing decisions it can result in routing
instability. This tradeoff is discussed in detail in [CL-FW, Section
4.1.1].
The solution MUST define methods to include node level performance
estimate information to routing protocols.
The solution MUST define methods to include node level performance
estimate information to signaling protocols.
Fu et al Expires April 14, 2013 [Page 9]
A specific deployment of the solution MAY choose to not use the node
level performance estimates.
5.4. Augment Routing Information with Performance Parameter Estimates
The solution MUST provide a means to communicate performance parameters
of both links and nodes as an estimate for use in performance sensitive
LSP path selection within nodes of a single IGP area/level.
The solution SHOULD provide a means to communicate latency, loss and
delay variation of links and nodes as a traffic engineering performance
parameter for use in performance sensitive LSP path selection across a
set of nodes in a hierarchy of IGP areas/levels.
5.5. Augment Signaling Information with Concatenated Estimates
The solution MUST provide a means to signal concatenated performance
parameter estimates for both links and nodes as an estimate for use in
performance sensitive LSP path selection traversing two or more separate
administrative domains. See the terminology section for references on
the concatenation method for specific performance parameters.
For example, the solution needs to support the capability to compute a
route with X amount of bandwidth with less than Y ms of latency and less
than Z% loss across multiple domains.
The solution MUST support the means to concatenate performance parameter
estimates and report this for each traversed domain on the end-end path
The solution MUST interoperate with existing path selection and
signaling methods traversing multiple domains.
5.6. Define Significant Performance Parameter Change Thresholds and
Frequency
Latency, loss and delay variation measurements and/or estimates may be
time varying. The solution MUST provide a means to control the
advertisement rate of performance parameter estimates to avoid
instability.
Any automatic LSP routing and/or load balancing solutions MUST NOT
oscillate such that performance observed by users changes such that an
NPO is violated. Since oscillation may cause reordering, there MUST be
means to control the frequency of changing the path over which an LSP is
placed.
5.7. Define Thresholds and Timers for Links with Unusable Performance
The solution MUST provide a means to configure a performance parameter
threshold which defines placement of a node or link into an unusable
state. The solution MUST provide a means to configure a performance
parameter threshold which defines transition of a node or a link from an
unusable state to a useable state. The solution MUST provide a means to
control the minimum transition time between these states.
Fu et al Expires April 14, 2013 [Page 10]
This unusable state is intended to operate on a link/node capability
basis and not a global basis. Since state transition conditions are
locally configured, all routers within a domain should synchronize this
configuration value.
With current TE protocols, a refreshed LSP would use the most recent
performance parameter estimates and may be rerouted based upon nodes or
links being placed in an unusable performance state. Section 5.11.
defines requirements for a desirable function where performance
sensitive LSP re-routing would occur.
5.8. Communicate Significant Performance Changes between Layers
In order to support network NPOs and provide acceptable user experience,
the solution MUST specify a protocol means to allow a lower layer server
network to communicate performance parameters (e.g., latency, loss,
delay variation) to the higher layer client network.
5.9. The above requirement applies to layering with different technologies
(e.g., MPLS over OTN) or to different levels within the same technology
(e.g., hierarchical LSPs).
5.10. Support for Networks with Composite Link
An LSP may traverse a network with Composite Links [CL-REQ]. The
solution's selection of performance sensitive paths SHOULD be compatible
with the general availability, stability and transient response
requirements of [CL-REQ, Section 4.1].
When an LSP traverses a network with composite links that has component
links provided by lower layer networks, the solution MUST interoperate
with the requirements [CL-REQ, Section 4.2].
When an LSP traverses a network with composite links that has parallel
component links with different characteristics, the solution MUST
interoperate with the requirements [CL-REQ, Section 4.3].
5.11. Restoration, Protection and Rerouting
The ability to re-route an LSP if one or more NPO objectives are not met
is highly desirable. The solution SHOULD support the capability to
configure an LSP as capable of implementing performance sensitive re-
routing, as detailed in the following conditional requirements.
If performance sensitive re-routing is implemented, the solution MUST
provide a means to configure performance parameter threshold crossing
and time values.
If performance sensitive re-routing is implemented, the solution MUST
support a configuration option to move an end-to-end LSP away from any
link or node whose performance violates the configured threshold.
If implemented, the solution MUST provide a means to control the
frequency of LSP rerouting to avoid instability.
Fu et al Expires April 14, 2013 [Page 11]
If performance sensitive re-routing is implemented, and revertive
behavior to a preferred LSP is supported, then the preferred LSP MUST
not be released. When the end-to-end performance of the preferred LSP
becomes acceptable, the service is restored to this preferred LSP.
The latency performance of pre-defined protection or dynamic reroutable
LSP MUST be defined by the solution in terms of the maximum acceptable
latency difference between the primary and protection/restoration path
MUST be specifiable in the solution. For example, [MPLS-TP-USE-CASE]
defines a Relative Delay Time which is the difference of the Absolute
Delay between the primary and protection path.
5.12. Management and Operational Requirements
Existing management and diagnostic protocols MUST be able to operate
over networks supporting performance sensitive LSP placement.
If performance sensitive re-routing is implemented, and end-to-end
measurements of the LSP performance are made, then the LSP requestor is
able to request path placement for a performance sensitive LSP using the
previously stated requirements. Since a threshold crossing of the end-
to-end performance measurement may or may not correspond to a change in
the concatenated performance parameter estimates, making any automatic
decision on this basis is not recommended since it could create
instability.
6. IANA Considerations
No new IANA consideration are raised by this document.
7. Security Considerations
This document raises no new security issues.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[CL-UC] C. Villamizer et al, "Composite Link Use Cases and Design
Considerations," draft-ietf-rtgwg-cl-use-cases-01
[CL-REQ] C. Villamizar et al, "Requirements for MPLS Over a Composite
Link", draft-ietf-rtgwg-cl-requirement-08 .
[CL-FW] C. Villamizar et al, "Composite Link Framework in Multi Protocol
Label Switching (MPLS)", work in progress
[ITU-T.Y.1540] ITU-T, "Internet protocol data communication service - IP
packet transfer and availability performance parameters",
2011, <http://www.itu.int/rec/T-REC-Y.1540/en>.
Fu et al Expires April 14, 2013 [Page 12]
[ITU-T.Y.1541] ITU-T, "Network performance objectives for IP-based
services", 2011, <http://www.itu.int/rec/T-REC-Y.1541/en>.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned
Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[CLO] Young Lee et al, "Problem Statement for Cross-Layer
Optimization," work in progress.
[CSO] Greg Bernstein, Young Lee, "Cross Stratum Optimization Use-
cases," work in progress.
[EXPRESS-PATH] A. Atlas, "Performance-based Path Selection for
Explicitly Routed LSPs", work in progress.
[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.
[MPLS-TP-USE-CASE] L. Fang, "MPLS-TP Applicability; Use Cases and
Design", draft-ietf-mpls-tp-use-cases-and-design-01 .
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
The authors would like to thank the MPLS Review Team of Stewart Bryant,
Daniel King and He Jia for their many helpful comments suggestions in
July 2012.
Copyright (c) 2012 IETF Trust and the persons identified as authors of
the code. All rights reserved.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This code was derived from IETF RFC [insert RFC number]. Please
reproduce this note if possible.
Fu et al Expires April 14, 2013 [Page 13]
Authors' Addresses
Xihua Fu
ZTE
Email: fu.xihua@zte.com.cn
Vishwas Manral
Hewlett-Packard Corp.
191111 Pruneridge Ave.
Cupertino, CA 95014
US
Phone: 408-447-1497
Email: vishwas.manral@hp.com
Dave McDysan
Verizon
Email: dave.mcdysan@verizon.com
Andrew Malis
Verizon
Email: andrew.g.malis@verizon.com
Spencer Giacalone
Thomson Reuters
195 Broadway
New York, NY 10007
US
Phone: 646-822-3000
Email: spencer.giacalone@thomsonreuters.com
Malcolm Betts
ZTE
Email: malcolm.betts@zte.com.cn
Qilei Wang
ZTE
Email: wang.qilei@zte.com.cn
John Drake
Juniper Networks
Email: jdrake@juniper.net
Fu et al Expires April 14, 2013 [Page 14]