One document matched: draft-manral-mpls-service-01.txt

Differences from draft-manral-mpls-service-00.txt

Network Working Group                                     Vishwas Manral
Internet-Draft                                     Hewlett-Packard Corp.
Intended status: Standards Track                            
Expires: January 17, 2012                               
                                                           July 26, 2011


        Traffic Engineering architecture for services aware MPLS
                      draft-manral-mpls-service-01

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@ipinfusion.com
   URI:






























Manral                  Expires January 27, 2012                        [Page 7]