Hi Fu,
There are some basic issues in the documents, especially regarding loss and
jitter. I had written a document addressing the same, but never got into
actually posting it.
I have attached the same here. Do let me know what you feel about the same?
Thanks,
Vishwas
2011/6/27 <[email protected]>
>
> Hi All,
>
> I read through the draft-giacalone. For the portion of latency, there is no
> any essential difference between both of drafts.
> In the latest version, they added a bit in sub-TLV and gave some
> consideration for the advertisment control. This has aslo been described in
> our draft.
> Control plane always combines routing constraints with pre-defined
> priorities, e.g., SRLG diversity, latency, cost, and bandwidth.
> But I don't understand why we need to add *Residual*and *Available*bandwidth
> in draft-giacalone. Why don't you use RFC4203 and RFC3630 to calculate them?
>
> We will restructure draft-wang into a framework and some protocol specific
> parts (i.e., OSPF-TE and RSVP-TE) to address the issues raised in the
> framework.
> Based on suggestions from Lou and Acee, we agree that the OSPF protions
> from our draft is combined with draft-giacalone. OSPF extension will be
> developed in draft-giacalone.
> The framework document will mainly focus on the requirement of latency
> application and how to use latency information.
> I prefer framework document is done in CCAMP. But it is related to RTGWG
> and MPLS.
> Before we define the ability to report latency, it must be clear what we
> are reporting. So different implementations will report the same thing.
> Based on the discussion with Adrian by email, we will give some description
> about what we are gong to report in this framework document.
> The rsvp-te document in CCAMP will give some solution for latency TE (e.g.,
> accumulation and verification of the delay).
>
> Xihua Fu
>
>
> *Lou Berger <[email protected]>*
> 发件人: [email protected]
>
> 2011-06-22 下午 11:16
> 收件人
> Acee Lindem <[email protected]>
> 抄送
> CCAMP <[email protected]>, OSPF WG List <[email protected]>
> 主题
> Re: [CCAMP] [OSPF] draft-giacalone-ospf-te-express-path-01
>
>
>
>
> OSPF WG for the OSPF extensions seems very reasonable to me ;-)
>
> I still hope that the OSPF portions of
> draft-wang-ccamp-latency-te-metric can be combined with
> draft-giacalone-ospf-te-express-path given that both drafts state that
> they are addressing essentially the same high-level problem.
>
> Lou
>
> On 6/22/2011 8:40 AM, Acee Lindem wrote:
> > Hi John,
> > As it stands, the draft contains mainly OSPF TE encodings and
> considerations. Hence, my inclination would be to keep it in the OSPF WG.
> However, I'm willing to listen to other proposals.
> >
> > Thanks,
> > Acee
> > On Jun 21, 2011, at 11:10 PM, John E Drake wrote:
> >
> >> Hi,
> >>
> >> I am a bit confused. I thought the proper home for this work would
> either be the rtg wg or the mpls wg. I thought it was presented to the OSPF
> wg for information only.
> >>
> >> Thanks,
> >>
> >> John
> >>
> >> Sent from my iPhone
> >>
> >>
> >>> -----Original Message-----
> >>> From: [email protected] [mailto:[email protected]] On Behalf
> >>> Of Alia Atlas
> >>> Sent: Tuesday, June 21, 2011 6:45 PM
> >>> To: Acee Lindem
> >>> Cc: Spencer Giacalone; CCAMP; OSPF WG List
> >>> Subject: Re: [CCAMP] [OSPF] draft-giacalone-ospf-te-express-path-01
> >>>
> >>> Hi Acee,
> >>>
> >>> I do agree that we should explicitly document this in the draft & work
> >>> on better names for the sub-TLVs that might be confused.
> >>> I also agree that we need to give the decision explicit consideration;
> >>> to give this the exposure necessary and consideration for
> >>> applications was why we had this draft discussed in rtgwg as well as
> >>> ospf.
> >>>
> >>> In addition to the obvious uses for RSVP-TE, another potential
> >>> application is the idea of a path-weighted ECMP, where traffic is
> >>> split to the different next-hops based upon the total path bandwidths
> >>> out those next-hops. This is a pure IP application (LDP follows
> >>> of course) and I'd prefer not to lose track of those options when
> >>> considering the RSVP-TE applications.
> >>>
> >>> Alia
> >>>
> >>> On Tue, Jun 21, 2011 at 9:06 PM, Acee Lindem <[email protected]
> >
> >>> wrote:
> >>>> Hi Alia,
> >>>> I guess I agree with Lou - heretofore, we've done TE requirements in
> >>> the MPLS/CCAMP WGs and the TE encodings in the IGP WGs. I think we
> >>> should give the decision explicit consideration before we branch off
> >>> and do TE for application X independently. Additionally, if we do
> >>> decide to split this off independently, an E-mail to the list saying
> >>> there is no overlap is not sufficient to move forward. At a minimum, I
> >>> believe we need to:
> >>>>
> >>>> 1. Explicitly document this alternate applicability and
> >>> relationship to existing TE in the draft.
> >>>> 2. Determine whether any sub-TLVs can be shared (my opinion was
> >>> consistent with yours that there are not due to differences in
> >>> requirements and measurement).
> >>>> 3. Assure the sub-TLVs are appropriately named to avoid confusion
> >>> between the latency applications.
> >>>>
> >>>> Thanks,
> >>>> Acee
> >>>> On Jun 21, 2011, at 2:08 PM, Alia Atlas wrote:
> >>>>
> >>>>> Hi Acee,
> >>>>>
> >>>>> John Drake and I did take a look at the draft mentioned in CCAMP.
> >>> It
> >>>>> had a large number of requirements and extensions to
> >>>>> a number of different protocols. There is one sub-TLV (latency)
> >>> that
> >>>>> appears the same - but the expectations
> >>>>> as to averaging vs. instantaneous were different.
> >>>>>
> >>>>> The OSPF TE Express Path work is fairly self-contained and doesn't
> >>>>> specify in exact detail how the information
> >>>>> for the sub-TLVs is measured or obtained. I think it could be used
> >>>>> for multiple purposes.
> >>>>>
> >>>>> Alia
> >>>>>
> >>>>> On Tue, Jun 21, 2011 at 12:49 PM, Acee Lindem
> >>> <[email protected]> wrote:
> >>>>>> Hi Spencer (CCAMP copied as well),
> >>>>>>
> >>>>>> Here is a link for everyone's convenience:
> >>>>>>
> >>>>>> http://www.ietf.org/id/draft-giacalone-ospf-te-express-path-01.txt
> >>>>>>
> >>>>>> At IETF 80, there were questions about overlap with other CCAMP
> >>> drafts containing interface delay metrics and proposals for new TE sub-
> >>> TLVs. Have you or your co-authors, done looked at how your draft is
> >>> positioned versus these other drafts? While these applications have
> >>> differing goals, the CCAMP/OSPF chairs requested that this analysis be
> >>> done.
> >>>>>>
> >>>>>> http://www.ietf.org/id/draft-wang-ccamp-latency-te-metric-03.txt
> >>>>>>
> >>>>>> We would like to avoid having exactly the same information
> >>> advertised in two different link Sub-TLVs. I'd hope we could agree on
> >>> common units.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Acee
> >>>>>>
> >>>>>> On Jun 20, 2011, at 4:30 PM, Spencer Giacalone wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> As you may have noticed, another version of the OSPF TE Express
> >>> Path
> >>>>>>> draft has been posted. We made a number of changes based on
> >>> feedback
> >>>>>>> from IETF 80. We invite your comments and suggestions. The main
> >>>>>>> changes include:
> >>>>>>>
> >>>>>>> -We have consolidated some sub-TLVs for efficiency. There are no
> >>>>>>> longer nominal and anomalous sub-TLVs for delay and loss. The
> >>>>>>> functionality for signaling steady state verses abnormal
> >>> performance
> >>>>>>> for these parameters have been moved into two sub-TLVs (where we
> >>> used
> >>>>>>> to have four).
> >>>>>>>
> >>>>>>> -In order to advertise both normal and abnormal network
> >>> performance
> >>>>>>> state in consolidated sub-TLVs, a bit, called the anomalous (A)
> >>> but
> >>>>>>> has been added to certain sub-TLVs. The A bit is set when the
> >>> measured
> >>>>>>> value of a parameter exceeds a configured maximum threshold. The A
> >>> bit
> >>>>>>> is cleared when the measured value falls below its configured
> >>> reuse
> >>>>>>> threshold. If the A bit is clear, the sub-TLV represents steady
> >>> state
> >>>>>>> link performance.
> >>>>>>>
> >>>>>>> -We changed the encodings of certain variables from floating point
> >>> to
> >>>>>>> fixed point. This change permits the addition of the A bit (when
> >>>>>>> necessary), it allows bit-space reservations to be made, and it
> >>>>>>> permits a common TLV format across the bulk of the TLVs in the
> >>> draft.
> >>>>>>> In addition, the new encodings address concerns about granularity
> >>> and
> >>>>>>> interoperability.
> >>>>>>>
> >>>>>>> -We added sub-TLVs for Residual Bandwidth and Available Bandwidth.
> >>>>>>> Residual bandwidth is defined as the Maximum Bandwidth [RFC3630]
> >>> minus
> >>>>>>> the bandwidth currently allocated to RSVP-TE LSPs. Available
> >>> bandwidth
> >>>>>>> is defined to be residual bandwidth minus the measured bandwidth
> >>> used
> >>>>>>> for the actual forwarding of non-RSVP-TE LSP packets.
> >>>>>>>
> >>>>>>> -Various other modifications were made across the draft. These
> >>>>>>> include, but are not limited to, the abstract, the introduction,
> >>> the
> >>>>>>> thresholding specifications, and a number of field descriptions.
> >>>>>>>
> >>>>>>> -Last, but certainly not least, Stefano Providi has joined the
> >>> draft
> >>>>>>>
> >>>>>>> We look forward to hearing your comments and concerns.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Spencer, Alia, Dave, John, Stefano
> >>>>>>> _______________________________________________
> >>>>>>> OSPF mailing list
> >>>>>>> [email protected]
> >>>>>>> https://www.ietf.org/mailman/listinfo/ospf
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> OSPF mailing list
> >>>>>> [email protected]
> >>>>>> https://www.ietf.org/mailman/listinfo/ospf
> >>>>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> CCAMP mailing list
> >>> [email protected]
> >>> https://www.ietf.org/mailman/listinfo/ccamp
> >
> > _______________________________________________
> > OSPF mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ospf
> >
> >
> >
> >
> _______________________________________________
> CCAMP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>
> _______________________________________________
> CCAMP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
Network Working Group V. Manral
Internet-Draft Hewlett-Packard Corp.
Intended status: Standards Track
Expires: November 17, 2011
May 16, 2011
Traffic Engineering architecture for services aware MPLS
draft-manral-mpls-service-00
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 & Giacalone Expires November 17, 2011 [Page 1]
Internet-Draft Link Latency, Jitter and Loss May 2011
This Internet-Draft will expire on November 17, 2011.
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 & Giacalone Expires November 17, 2011 [Page 2]
Internet-Draft Link Latency, Jitter and Loss May 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 & Giacalone Expires November 17, 2011 [Page 3]
Internet-Draft Link Latency, Jitter and Loss May 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 & Giacalone Expires November 17, 2011 [Page 4]
Internet-Draft Link Latency, Jitter and Loss May 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 & Giacalone Expires November 17, 2011 [Page 5]
Internet-Draft Link Latency, Jitter and Loss May 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 & Giacalone Expires November 17, 2011 [Page 6]
Internet-Draft Link Latency, Jitter and Loss May 2011
Authors' Addresses
Vishwas Manral
Hewlett-Packard Corp.
191111 Pruneridge Ave.
Cupertino, CA 95014
US
Phone: 408-447-1497
Email: [email protected]
URI:
Spencer Giacalone
Thomson Reuters
195 Broadway
New York, NY 10007
US
Phone: 646-822-3000
Email: [email protected]
URI:
Manral & Giacalone Expires November 17, 2011 [Page 7]
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
