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, <http://www.itu.int/rec/T-REC-Y.1541/en>.

   [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]