Network Working Group Vishwas Manral Internet-Draft Hewlett-Packard Corp. Intended status: Standards Track Expires: February 12, 2012 August 08, 2011 Traffic Engineering architecture for services aware MPLS draft-manral-mpls-service-02 Abstract With more and more enterprises using cloud based services, the distances between the user and the applications are growing. A lot of the current applications are designed to work across LAN's and have various inherent assumptions. For multiple applications such as High Performance Computing and Electronic Financial markets, the response times are critical as is packet loss, while other applications require more throughput. [RFC3031] describes the architecture of MPLS based networks. This draft extends the MPLS architecture to allow for latency, loss and jitter as properties. Note MPLS architecture for Multicast will be taken up in a future version of the draft. Requirements Language 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Manral Expires January 27, 2012 [Page 1] Internet-Draft Link Latency, Jitter and Loss July 2011 This Internet-Draft will expire on January 27, 2012. Copyright Notice Copyright (c) 2011 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. Manral Expires January 27, 2012 [Page 2] Internet-Draft Link Latency, Jitter and Loss July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. End-to-End Latency Measurements . . . . . . . . . . . . . . . . 4 3. End-to-End Jitter Measurements . . . . . . . . . . . . . . . . 5 4. End-to-End Loss Measurements . . . . . . . . . . . . . . . . . 5 5. Protocol Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Manral Expires January 27, 2012 [Page 3] Internet-Draft Link Latency, Jitter and Loss July 2011 1. Introduction 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. Extremely low latency measurements for MPLS LSP tunnels are defined in draft-ietf-mpls-loss-delay. They allow a mechanism to measure and monitor performance metrics for packet loss, and one-way and two-way delay, as well as related metrics like delay variation and channel throughput. The measurements are however effective only after the LSP is created and cannot be used by MPLS Path computation engine to define paths that have the latest latency. This draft defines the architecture used, so that end-to-end tunnels can be set up based on latency, loss or jitter characteristics. 2. End-to-End Latency Measurements Latency or one-way delay is the time it takes for a packet within a stream going from measurement point 1 to measurement point 2. The architecture uses assumption that the sum of the latencies of the individual components approximately adds up to the average latency of an LSP. Though using the sum may not be perfect, it however gives a good approximation that can be used for Traffic Engineering (TE) purposes. The total latency of an LSP consists of the sum of the latency of the LSP hop, as well as the average latency of switching on a device, which may vary based on queuing and buffering. Hop latency can be measured by getting the latency measurement between the ingress of one MPLS LSR to the ingress of the nexthop LSR. This value may be constant for most part, unless there is protection switching, or other similar changes at a lower layer. The switching latency on a device, can be measured internally, and multiple mechanisms and data structures to do the same have been defined. Add references to papers by Verghese, Kompella, Duffield. Though the mechanisms define how to do flow based measurements, the amount of information gathered in such a case, may become too cumbersome for the Path Computation element to effectively use. Manral Expires January 27, 2012 [Page 4] Internet-Draft Link Latency, Jitter and Loss July 2011 An approximation of Flow based measurement is the per DSCP value, measurement from the ingress of one port to the egress of every other port in the device. Another approximation that can be used is per interface DSCP based measurement, which can be an agrregate of the average measurements per interface. The average can itself be calculated in ways, so as to provide closer approximation. The delay is measured in terms of 10's of nano-seconds. 3. End-to-End Jitter Measurements Jitter or Packet Delay Variation of a packet within a stream of packets is defined for a selected pair of packets in the stream going from measurement point 1 to measurement point 2. The architecture uses assumption that the sum of the jitter of the individual components approximately adds up to the average jitter of an LSP. Though using the sum may not be perfect, it however gives a good approximation that can be used for Traffic Engineering (TE) purposes. There may be very less jitter on a link-hop basis. The buffering and queuing within a device will lead to the jitter. Just like latency measurements, jitter measurements can be appproximated as either per DSCP per port pair (Ingresss and Egress) or as per DSCP per egress port. The jitter is measured in terms of 10's of nano-seconds. 4. End-to-End Loss Measurements Loss or Packet Drop probability of a packet within a stream of packets is defined as the number of packets dropped within a given interval. The architecture uses assumption that the sum of the loss of the individual components approximately adds up to the average loss of an LSP. Though using the sum may not be perfect, it however gives a good approximation that can be used for Traffic Engineering (TE) purposes. There may be very less loss on a link-hop basis, except in case of physical link issues. Manral Expires January 27, 2012 [Page 5] Internet-Draft Link Latency, Jitter and Loss July 2011 The buffering and queuing mechanisms within a device will decide which packet is to be dropped. Just like latency and jitter measurements, the loss can best be appproximated as either per DSCP per port pair (Ingresss and Egress) or as per DSCP per egress port. The loss is measured in terms of the number of packets per million packets. 5. Protocol Considerations The protocol metrics above can be sent in IGP protocol packets RFC 3630. They can then be used by the Path Computation engine to dervice paths with the desired path properties. As Link-state IGP information is flooded throughout an area, frequent changes can cause a lot of control traffic. To prevent such flooding, data should only be flooded when it crosses a certain configured maximum. A seperate measurement should be done for an LSP when it is UP. Also LSP's path should only be recalculated when the end-to-end metrics changes in a way it becomes more then desired. 6. IANA Considerations No new IANA consideration are raised by this document. 7. Security Considerations This document raises no new security issues. 8. Acknowledgements TBD. Manral Expires January 27, 2012 [Page 6] Internet-Draft Link Latency, Jitter and Loss July 2011 Authors' Addresses Vishwas Manral Hewlett-Packard Corp. 191111 Pruneridge Ave. Cupertino, CA 95014 US Phone: 408-447-1497 Email: vishwas.manral@hp.com URI: Manral Expires January 27, 2012 [Page 7]