Network Working Group X. Fu(Ed.), M. Betts, Q. Wang Internet Draft ZTE Intended Status: Informational V. Manral Expires: April 14, 2013 Hewlett-Packard Corp. D. McDysan(Ed.), 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-01 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. Mechanisms exist to measure and monitor MPLS path performance parameters for packet loss and delay, but the mechanisms work only after the path has been setup. The 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 before LSP setup and then the 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. This also allows 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. Delay................................................4 2.2.2. Packet Loss..........................................4 2.2.3. Packet Delay Variation...............................5 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-to-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 ..............................................................11 5.8. Communicate Significant Performance Changes between Layers11 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).....................11 5.10. Support for Networks with Composite Link................11 5.11. Restoration, Protection and Rerouting...................11 5.12. 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, for delay and loss based Traffic Engineering for MPLS networks. A peer document focuses on the 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 delay, 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 delay, 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 Fu et al Expires April 14, 2013 [Page 3] NPO Network Performance Objective 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, delay, 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 delay, 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. Delay 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 "delay" 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." Fu et al Expires April 14, 2013 [Page 4] 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. 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 contribute to the performance parameters in the network.Another significant contributor is that of the host stack, but that is outside the scope of this document. For many applications, the delay NPO is very important. In networks with wide geographic separation, propagation delay may dominate delay, while in local or metro networks nodal delay 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. Packet loss can be caused due to signal degradation/ high noise, which causes corrupted packets which in turn are discarded in the network. Furthermore, the loading of queues (congestion) may also result in 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. It can also be caused when packets take different paths, due to lower layer routing. 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-delay direct market access. In certain networks, such as financial information networks (e.g. stock market data providers), network performance information (e.g. delay) 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 delay) in a cost-effective and scalable way. Fu et al Expires April 14, 2013 [Page 5] 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 delay, 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. 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-to-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-to-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 delay, delay variation and Fu et al Expires April 14, 2013 [Page 6] 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. 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 delay 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 delay 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 delay, 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., delay) 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 delay relates directly to the best customer experience (e.g., in TCP closer is faster or in financial trading the absolute minimum delay possible provides a competitive advantage). In other cases, user experience is relatively insensitive to delay, 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 delay, and as long as this bound is met, the NPO is met - - decreasing the delay is not necessary. In some NPOs, if the specified delay 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 delay NPO cannot be determined. Fu et al Expires April 14, 2013 [Page 7] One operational approach is to provision IP/MPLS networks over unprotected circuits and set the metric and/or TE-metric proportional to delay. This resulted in traffic being directed over the least delay 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 proportional to delay. 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., delay) 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. Fu et al Expires April 14, 2013 [Page 8] 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 delay. 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 delay and packet loss and a maximum value of delay 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 delay, 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 delay, 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 (delay, 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 delay 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 delay is very important but link delay may be negligible. 3. The case of some number of nodes with medium geographic separation, where usage of both link and node delay may be desirable. The intent in case 1 is to measure the predominant delay 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]. Fu et al Expires April 14, 2013 [Page 9] 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. 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 delay, 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 delay 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 Delay, 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. Fu et al Expires April 14, 2013 [Page 10] 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. 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., delay, 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. Fu et al Expires April 14, 2013 [Page 11] 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. 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 delay performance of pre-defined protection or dynamic reroutable LSP MUST be defined by the solution in terms of the maximum acceptable delay 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 MUST not 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 Fu et al Expires April 14, 2013 [Page 12] [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, . [ITU-T.Y.1541] ITU-T, "Network performance objectives for IP-based services", 2011, . [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. Fu et al Expires April 14, 2013 [Page 13] This code was derived from IETF RFC [insert RFC number]. Please reproduce this note if possible. 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]