[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: time tracing utility

At 09:21 PM 9/9/2002 -0400, Tom Scott wrote:

In a thread on the CCAMP list regarding draft-ietf-ccamp-tracereq-00.txt,
the authors indicated that a time-tracing application was beyond the
scope of the draft. Is there any interest in the TE WG for such a utility,
as applied to the delay-based metric suggested in section 2 of
draft-ietf-tewg-te-metric-igp-01.txt:

  In current MPLS TE deployments, network administrators often want
  Constraint Based Routing of TE LSPs carrying data traffic to be
  based on the same metric as the metric used for Shortest Path
  Routing. Where this is the case, this practice allows the Constraint
  Based Routing algorithm running on the Head-End LSR to use the IGP
  metric advertised in the IGP to compute paths for data TE LSPs
  instead of the advertised TE metric. The TE metric can then be used
  to convey another metric (e.g. a delay-based metric) which can be
  used by the Constraint Based Routing algorithm on the Head-End LSR
  to compute path for the TE LSPs with different requirements (e.g.
  Voice TE LSP).

The management model in RFC 3290/89 describes ten "datapath elements" and
"traffic conditioning blocks" that are constructed from the elements. Is
it possible to use these elements (and TCBs?), along with the metric
recommendations of the IPPM WG, to define a time-tracing utility that
measures not only where traffic travels but also the time that packets
take to travel from A to B, where the endpoints of interest are nodes or
"functional groupings" on any layer or components such as the datapath
elements in any of those nodes?

If this is out of scope for the TE WG, I would be grateful to anyone who
could refer me to publications on this topic.
My question would be whether such a standard mechanism/metrics
is/are necessary. As you point out, for TE that information could be automatically
fed back into the routing protocols used to flood TE information and thus govern the
signaling (or re-signaling) of TE tunnels that do not behave correctly. However,
I will point out that other mechanisms exist for measuring the RTT/jitter of
of a tunnel such as GTTP, LSP ping and automated versions of these.
The information gathered can then be fed into the TE control software on the
head-end LSR to determine whether or not the tunnel is truly meeting the
SLA for the tunnel and/or whether an alternative (perhaps more conforming)
path option chosen. Although the feedback mechanism is not built-into the
signaling software, it is certainly possible (and being done). I am just not so sure
that anyone is clamoring for a more standard way of achieving this other than
what is being provided today. It would be interesting to hear from service providers
on this topic.

--Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.