Subject: time tracing utility

From: Tom Scott <[email-masked]>
Date: Mon, 09 Sep 2002 21:21:59 -0400

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.

-- TIA, TT

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 09 Sep 2002 22:25:59 -0400

>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.