Network Working Group X. Fu(Ed.), M. Betts, Q. Wang Internet Draft ZTE Intended Status: Informational V. Manral Expires: April 21, 2013 Hewlett-Packard Corp. D. McDysan (Ed.), A. Malis Verizon S. Giacalone Thomson Reuters J. Drake Juniper Networks October 22, 2012 Loss and Delay Traffic Engineering Framework for MPLS draft-fuxh-mpls-delay-loss-te-framework-06 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 April 17, 2011. 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. Fu, McDysan et al Expires April 21, 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 framework and architecture to solve operator problems and requirements using current/proposed approaches, documents scalability assessment and recommendations, and identifies any needed protocol development. Table of Contents 1. Introduction...................................................3 1.1. Scope.....................................................3 2. Conventions used in this document..............................3 2.1. Acronyms..................................................3 3. Overview of Functional Requirements............................4 4. Augment LSP Requestor Signaling with Performance Parameter Values ..................................................................4 5. Specify Criteria for Node and Link Performance Parameter Estimation, Measurement Methods...............................................5 6. Support Node Level Performance Information when Needed.........5 7. Augment Routing Information with Performance Parameter Estimates5 8. Augment Signaling Information with Concatenated Estimates......6 9. Define Significant Performance Parameter Change Thresholds and Frequency.........................................................6 10. Define Thresholds and Timers for Links with Unusable Performance ..................................................................7 11. Communicate Significant Performance Changes between Layers....7 12. Support for Networks with Composite Links.....................8 13. Support Performance Sensitive Restoration, Protection and Rerouting ..................................................................8 14. Support Management and Operational Requirements...............8 15. Major Architectural and Scaling Challenges....................8 16. Approaches Considered but not Taken...........................9 17. IANA Considerations...........................................9 18. Security Considerations.......................................9 19. References....................................................9 19.1. Normative References.....................................9 19.2. Informative References...................................9 20. Acknowledgments..............................................10 Fu, McDysan et al Expires April 21, 2012 [Page 2] 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 framework in response to the problem statement and requirements described in a peer document [DELAY-LOSS-PS]. The purpose of this draft is to summarize a framework and architecture to meet requirements using current/proposed approaches, documents scalability assessment and recommendations, and identifies any needed protocol development. However, computing an LSP path to meet the Network Performance Objective(NPO) for delay, loss and delay variation of these QoS classes is an open problem [DELAY-LOSS-PS]. This draft describes a framework for how the MPLS TE architecture can be augmented use information on configured, measured and/or estimated delay, loss and delay variation for use in LSP path computation and selection. 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. An MPLS architecture for Multicast with awareness of delay, loss and delay variation will be taken up in a future version of the draft. 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 DS-TE Differentiated Services Traffic Engineering IGP Interior Gateway Protocol (G)MPLS (Generalized) Multi-Protocol Label Switching LSP Label Switched Path RSVP-TE Resource reservation Protocol - Traffic Engineering Fu, McDysan et al Expires April 21, 2012 [Page 3] 3. Overview of Functional Requirements [DELAY-LOSS-PS] describes the general problem to be solved and describes a number of requirements grouped in the following subject areas for performance sensitive LSP computation and placement: o Augment LSP Requestor Signaling with Performance Parameter Values o Specify Criteria for Node and Link Performance Parameter Estimation, Measurement Methods o Support Node Level Performance Information when Needed o Augment Routing Information with Performance Parameter Estimates o Augment Signaling Information with Concatenated Estimates o Define Significant Performance Parameter Change Thresholds and Frequency o Define Thresholds and Timers for Links with Unusable Performance o Communicate Significant Performance Changes between Layers o Support for Networks with Composite Link o Support Performance Sensitive Restoration, Protection and Rerouting o Support Management and Operational Requirements The following sections describe aspects of a framework for each of the above requirement sets in terms of functions, protocols and operational scenarios for meeting the requirements. In some cases the descriptions reference current/proposed potentially applicable IETF approaches. Throughout the following sections, certain scalability challenges are identified and in most cases a potential resolution approach is described - these are summarized at the end of the document. 4. Augment LSP Requestor Signaling with Performance Parameter Values As described in [DELAY-LOSS-PS] the LSP requestor must be able to make a request for one of two types 1) a minimum possible value or 2)a maximum acceptable valuefor each performance parameter for each LSP. The proposed approach [EXPRESS-PATH] within a single IGP area/level, is that only the origin (or head-end) need be aware of the required performance aspects of the LSP, since the origin has performance information for all of the candidate nodes and links from a performance parameter augmented IGP [OSPF-TE-METRIC-EXT], [ISIS-TE-METRIC-EXT]. For LSPs that traverse multiple area/levels or multiple domains, what is needed in addition to [EXPRESS-PATH] is knowledge of the node and link level performance to determine a path that meets the concatenated performance estimates as described in [DELAY-LOSS-PS]. Furthermore, information available to the LSP originator (e.g., the request type Fu, McDysan et al Expires April 21, 2012 [Page 4] (minimum possible value, maximum acceptable parameter value) may need to be carried in the RSVP_TE signaling message. An alternative approach could make the performance information available to a (set of) Path Computation Elements (PCE), which the LSP requestor could consult. In this case, there would likely need to be extensions made to the PCE Protocol to carry LSP performance parameter information. 5. Specify Criteria for Node and Link Performance Parameter Estimation, Measurement Methods Procedures to measure delay and loss on a path level between measurement points have been specified in ITU-T [Y.1731], [G.709] and [RFC 6374]. Ideally, a measurement point would occur within adjacent nodes to measure the delay, loss and delay variation performance for a combination of node and link performance. However, since this method is not universally deployed (and may never be deployed in some nodes), other methods of performance parameter estimation are needed to meet the requirements of [DELAY-LOSS-PS]. Important assumptions from [DELAY-LOSS-PS] are: o the timeframe of the performance parameter estimate, which is specified as the order of minutes o delay and loss are defined as an average and delay variation is defined based upon statistical quantiles These assumptions could allow other methods to estimate performance parameters, such as usage of models to predict values based upon other parameters, such as load, queue thresholds and/or meters. For example, one such method could be a per QoS class based measurement from the ingress of one port to the egress of another port on a node as a function of load in a field test or laboratory to create an empirical model that could be used to insert performance parameter estimates into routing or signaling. The switching delay on a node can be measured internally, and multiple mechanisms and data structures to do this have been defined [LEE]. 6. Support Node Level Performance Information when Needed If the IGP structure of link-level advertisements is to be used, then nodal delays can be combined with link-level performance [EXPRESS-PATH]. For example, a solution provide configuration knob to add some fixed value of a portion (e.g., one half) of node delay to link delay. Alternatively, IGPs or a PCE information base could be extended with node-level performance parameter estimates. 7. Augment Routing Information with Performance Parameter Estimates [DSTE-PROTO] and [EXPRESS-PATH] use information regarding bandwidth from an IGP area/level for use by performance sensitive LSPs. For a single IGP area/level, the IGP could be augmented with estimates of delay, loss Fu, McDysan et al Expires April 21, 2012 [Page 5] and delay variation as described in [OSPF-TE-METRIC-EXT], [ISIS-TE- METRIC-EXT]. This should also apply to a Forwarding Adjacency LSP (FA- LSP) [RFC4206]. [EXPRESS-PATH] describes how to use these augmented IGP performance measures to compute explicit paths, for example, at a path computation entity. For LSPs that cross an IGP area/level boundary and/or traverse multiple domains, some other solution is needed for LSP path computation and selection, such as augmented PCE information bases. These PCE information bases can then be used by origin or the Path Computation engine to decide paths with the desired path properties. Routing information could use two components to represent performance, "static" and "dynamic". The dynamic component is that caused by traffic load and queuing and would be an approximate value. The static component should be fixed and independent of load (e.g., propagation delay). 8. Augment Signaling Information with Concatenated Estimates [DELAY-LOSS-PS] cites specific sections/appendices from [ITU-T Y.1541] regarding how performance estimates are to be composed and concatenated. For LSPs that cross an IGP area/level boundary and/or traverse multiple domains (e.g., Autonomous Systems), if detailed performance parameter information is not provided, then one approach would be to signal the requested performance parameters for the LSP in the RSVP_TE signaling message as described in [DELAY-LOSS-RSVP-TE]. If each area/level and/or domain is unaware of the composition of performance parameters from the prior area/level and/or domains, then signaling would also need to carry the concatenation of these composed performance estimates. Signaling information could use two components to represent performance, "static" and "dynamic". The dynamic component is that caused by traffic load and queuing and would be an approximate value. The static component should be fixed and independent of load (e.g., propagation delay). RSVP-TE signaling across multiple area/levels or domains could include recording status of previous attempts, retries and correlation with end- end LSP performance measures to improve on a trial-and-error approach. Another approach that could meet the requirements could be a (stateful) PCE listening to each domain, communicating amongst PCEs in other domains approximating global state to reduce probing and retries to improve scalability. 9. Define Significant Performance Parameter Change Thresholds and Frequency In the augmented IGP approach, performance value changes should be updated and flooded in the IGP only when there is significant change in the value. The LSP originator could determine the IGP update affects performance and can decide on whether to accept the changed value, or request another computation of the LSP. Fu, McDysan et al Expires April 21, 2012 [Page 6] Since performance characteristics of links, nodes and FA-LSPs may change dynamically the amount of information flooded in an augmented IGP approach could be excessive and cause instability. In order to control IGP messaging and avoid being unstable when the delay, delay variation and packet loss value changes, thresholds and a limit on rate of change should be configured in the IGP control plane. 10. Define Thresholds and Timers for Links with Unusable Performance For the extended IGP or augmented PCE information base approaches, an acceptable and unacceptable target performance value could be configured for each link (and node, if supported). This should also apply to a Forwarding Adjacency LSP (FA-LSP) [RFC4206]. If a measured or dynamically estimated (e.g., based upon load) performance value increases above the unacceptable threshold, the link (node) could be removed from consideration for future LSP path computations. If it decreases below the acceptable target value, it can then be considered for future LSP path computations. Performance-sensitive LSPs whose path traverses links (nodes) whose performance has been deemed unacceptable by this threshold should be notified. The LSP originator can then decide if it will accept the changed performance, or else request computation of a new path that meets the performance objective. The frequency of a link (node) changing from an unacceptable to an acceptable state should be controlled by configurable parameters. 11. Communicate Significant Performance Changes between Layers The generic requirement is for a lower layer network to communicate significant performance changes to a higher layer network. An end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may traverse a FA-LSP of a server layer (e.g., an OTN ring). The boundary nodes of the FA-LSP SHOULD be aware of the performance information for this FA-LSP. If the FA-LSP is used to form a routing adjacency and/or used as a TE link in the client network, the composition of the performance values of the links and nodes that the FA-LSP trail traverses needs to be made available for path computation. This is especially important when the performance information of the FA-LSP changes (e.g., due to a maintenance action or failure in an OTN ring). The frequency of a lower layer network indicating a significant performance change should be controlled by configurable parameters. A separate end-end performance measurement could be done for an LSP after it has been established (e.g., RFC 6374) if it is a lower level FA-LSP used in an LSP hierarchy. The measurement of end-to-end LSP performance may be used to inform the higher layer network of a performance parameter change. If the performance of FA-LSP changes, the client layer must at least be notified. The client layer can then decide if it will accept the Fu, McDysan et al Expires April 21, 2012 [Page 7] changed performance, or else request computation of a new path that meets the performance objective. 12. Support for Networks with Composite Links In order to assign the LSP to one of component links with different performance characteristics [CL-REQ], the RSVP-TE message could carry a indication of the request type (i.e., minimum possible value or a maximum acceptable performance parameter value ) for use in component link selection or creation. The composite link should be able to take these parameters into account when assigning LSP traffic to a component link. When Composite Links [CL-REQ] are advertised into an augmented IGP, the desirable solution is to advertise performance information for all component links into the augmented IGP [CL-FW]. Otherwise, if only partial or summarized information is advertised then the originator or a PCE cannot determine whether a computed path will meet the LSP performance objective and this could lead to crank back signaling. 13. Support Performance Sensitive Restoration, Protection and Rerouting A change in performance of links and nodes (e.g., due to a lower level restoration action) may affect the performance of one or more end-to-end LSPs. Pre-defined protection or dynamic re-routing could be triggered to handle this case. In the case of predefined protection, large amounts of redundant capacity may have a significant negative impact on the overall network cost. If the LSP performance objective cannot be met after a re-route is attempted, an alarm should be generated to the management plane. The solution should periodically attempt restoration for as controlled by configuration parameters to prevent excessive load on the control plane. 14. Support Management and Operational Requirements A separate end-end performance measurement should be done for an LSP after it has been established (e.g., RFC 6374, G.709 or Y.1731). An LSP originator may re-compute a re-signal a path when the measured end-to- end performance is unacceptable. The choice by the originator to re- signal could consider a history of how accurate the performance parameter estimate is delivered by the implementation. The re- computation and re-signaling rates should be controlled by configuration parameters to prevent excessive load on the control plane. 15. Major Architectural and Scaling Challenges As described in the preceding sections, there are a several scaling and architectural challenges, with proposed resolution as described below: o Frequency of performance parameter value changes limited to the order of minutes by definition o Augmented IGP flooding performance parameter change frequency within one area/level controlled by configuration parameters Fu, McDysan et al Expires April 21, 2012 [Page 8] o Augmented PCE information base performance parameter change frequency within one area/level controlled by configuration parameters o Re-computation and re-signaling of LSPs whose composition of performance parameter values changes to unacceptable controlled by configuration parameters o Declaration of links, nodes, FA-LSPs as unacceptable/acceptable controlled by configuration parameters o Frequency of a lower layer network indicating a significant performance change controlled by configuration parameters o Re-computation and re-signaling of LSPs whose measured end-end performance is unacceptable controlled by configuration parameters 16. Approaches Considered but not Taken One approach would be for the PCE to compute paths for use by the LSP originator for signaling. Some measurement method (e.g., RFC 6374) could then be used to measure the performance of this path. If the measurement indicates that the performance is not met then another request is made to the PCE for a different path, the originator signals for the LSP to be set up and then measured again. This "trial and error" process is very inefficient and a more predictable method is required. 17. IANA Considerations No new IANA consideration are raised by this document. 18. Security Considerations This document raises no new security issues. 19. References 19.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 19.2. Informative References [DELAY-LOSS-PS] X.Fu, D. McDysan et al., "Delay and Loss Traffic Engineering Problem Statement for MPLS," draft-fuxh-mpls- delay-loss-te-problem-statement [DSTE-PROTO] Le Faucheur, F., Ed., "Protocol Extensions for Supportof Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [ISIS-TE-METRIC-EXT] S. Previdi, "IS-IS Traffic Engineering (TE) Metric Extensions", draft-previdi-isis-te-metric-extensions. [OSPF-TE-METRIC-EXT] S. Giacalone, "OSPF Traffic Engineering (TE) Metric Extensions", draft-ietf-ospf-te-metric-extensions. Fu, McDysan et al Expires April 21, 2012 [Page 9] [EXPRESS-PATH] A. Atlas et al, "Performance-based Path Selection for Explicitly Routed LSPs", draft-atlas-mpls-te-express-path. [Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms for Ethernet based networks", Feb 2008. [G.709] ITU-T Recommendation G.709, "Interfaces for the Optical Transport Network (OTN)", December 2009. [RFC 6374] D. Frost, S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks," RFC 6374, September 2011. [DELAY-LOSS-RSVP-TE] X. Fu, "RSVP-TE extensions for Delay and Loss Traffic Engineering", draft-fuxh-mpls-delay-loss-rsvp-te-ext. [ITU-T.Y.1541] ITU-T, "Network performance objectives for IP-based services", 2011, . [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite Link", draft-ietf-rtgwg-cl-requirement [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [CL-FW] C. Villamizar et al, "Composite Link Framework in Multi Protocol Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework [LEE] Myungjin Lee , Sharon Goldberg , Ramana Rao Kompella , George Varghese "Fine-Grained Latency and Loss Measurements in the Presence of Reordering," http://www.cs.bu.edu/fac/goldbe/papers/sigmet2011.pdf 20. 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, McDysan et al Expires April 21, 2012 [Page 10] This code was derived from IETF RFC [insert RFC number]. Please reproduce this note if possible. Fu, McDysan et al Expires April 21, 2012 [Page 11] 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, McDysan et al Expires April 21, 2012 [Page 12]