Re: GGF-NMWG: "Hop" definition?

[Bruce Lowekamp <lowekamp@CS.WM.EDU>]

I haven't yet seen an argument that convinces me that there is an 
alternative representation that is more expressive.  In particular, I still 
believe that the path-only representation described in the hierarchy 
document is capable of expressing the more restrictive representations, 
while also capturing more flexible information.  I wrote up the following 
text as a proposed modification to clarify how it should be used.  I think 
it needs a few examples at the bottom, but wanted to put it out to see what 
people think.

Bruce

(I expressed it in latex, although the final version will need to be in 
word)
-----------------

remove current network paths section

add new subsection as 6.1

\subsection{Representing Topology}
Representing network entities is challenging because entities serve as
both the object being measured, for example in bandwidth measurements,
and as the ``measurement'' themselves, in the case of topology
discovery.  Network measurements can be reported for:
\begin{description}
\item[End-to-End Paths] In the common case of host-to-host
 measurements
\item[Links] Frequently measured for capacity, availability, and
 latency
\item[Nodes] Router queue discipline or host interface speed
\end{description}
Topologies are best representing using a graph structure, with nodes
and edges.

Furthermore, different systems care about topology at different
levels.  An ISP or network manager focusing on SLA satisfaction might
be most interested in a topology of AS to AS, reflecting the different
ISP's contractual relationships.  Many systems collect topology at
layer-3 through traceroute, typically discovering all routers along a
path.  Other systems might report only layer-2 topology between
routers, or both layer-2 and layer-3 topology.  Most often, a single
system does not have access to the layer-2 devices across an entire
end-to-end path, so might report the layer-2 topology at one or both
leaf networks, but be unable to discover more than the layer-3 routers
across the Internet connections.

To design a representation capable of capturing the levels of details
offered by each of these possibilities, we focused on maximizing the
{\em flexibility} of our representation.  We adopt an entity
representation consisting only of {\em paths} and {\em nodes}, as
shown in Figure~\ref{fig:entities}.  While some representations focus
more on distinguishing between paths, links, and hops, we avoid making
that distinction at the first level of our representation to avoid
imposing structure that would be incompatible with some systems.
However, our system captures the distinctions implied by such
classifications without enforcing such terminology as ``lowest-level
hop'' that might not be true in another system that, for example,
represents layer-1 repeaters.

The most confusing aspect of this representation is the multiple uses
of {\em path}.  Simply, a {\em path} is a connection between two
nodes.  When a measurement tool reports on the behavior of a
connection between two nodes, it is always reporting about a {\em
 path}.  A system that reports host-to-host TCP measurements and a
system that reports utilization of each link in a LAN both use paths.

There are two keys to using this simplistic {\em path} type:
\begin{itemize}
\item The type of path is distinguished by the types of nodes.
 Because nodes are distinguished as {\em host}, {\em router}, {\em
   switch}, etc., the layer of the {\em path} can be readily
 determined.
\item Each path can be divided into its constituent hops using the
 {\em hoplist} characteristic.  A {\em hoplist} is an ordered set of
 {\em hops}.  {\em hop} is a subclass of {\em path} and therefore
 also a {\em path} that can be described, or subdivided, as described
 above.  The only reason for including a separate {\em hop} type is
 if a particular measurement system wishes to include additional
 attributes for {\em hop} that are not used for {\em path}.
\end{itemize}

A very common representation is to use path to describe a host-to-host
connection, hop to describe a router-to-router connection, and link to
describe a switch-to-switch connection.  Paths can be composed of hops
and hops can be composed of links.  The path-only representation is
capable of expressing these details because the type of a path can be
determined by the source and destination nodes.  Therefore, paths,
hops, and links can be represented in the path-only form.
Furthermore, a host-to-host path in the path-only representation can
be subdivided into all of the known steps---both layer-3 and
layer-2---using a single {\em hoplist}.  Systems wishing to import
such a representation with the multiple-type approach would need to
convert this to the multiple types in their representation.  However,
there are significant programming advantages to being able to iterate
over a list of a single type to calculate capacity, for example.