Re: Tkined - A few questions

Louis A. Mamakos (louie@TransSys.COM)
Tue, 10 Jun 1997 23:30:04 -0400

> >Bones was a nice project where we made several experiments and learned
> >a lot about how to do it wrong. Database integration is really
> >difficult, at least if you do not want to dictate a particular
> >database system and a particular database model. I am currently not
> >working on database integration. Instead, I am adding the core of
> >Tkined into the Tnm extension which will lead to a "standard" file
> >format to describe network maps.
>
> Any thought to being able to describe the physical structure of
> a network -- like including labels on wires/fibers. Each
> link might be more than one cable with connections -- each
> connection needs to be included in the description.

Oh boy, you got me inspired now!

What I really need, nay, am desperate for is a tool which can describe a
network with different views. The problem I'm faced with is that most network
management tools are very much oriented to a particular point of view - that
is, of managing an IP network, or managing a level-2 ATM or Frame Relay network
or perhaps being a cable managment tool.

I need a tool which can describe various physical and logical relationships
between network elements, and the connections between them. Let me give
you an example based on a real network. The network is composed of many
different types of network elements:

- IP routers. There are hundreds of these, in a few different classes (e.g.,
backbone transit routers, customer aggregation routers, border/peering routers,
multicast routers).

- Level 2 Frame Relay switches. Yes, I actually own and operate these on the
network in question. These are used in two different roles: port concentration
and backbone transit.

- Level 3 ATM switches. Uses in multiple roles for intra-hub connectivity and
inter-hub transit switches.

- Level 1 mux/DACS equipment. I've got a bunch of M13 muxes that mux up DS1
circuits into channelized DS3 circuits. And these are just the ones that I
own; various carriers are also performing muxing for me too.

The Backbone routers are interconnected with each other using level-2 virtual
circuits, either over the frame relay network or the ATM network. The physical
connectivity between the routers and switches is either HSSI/Frame Relay, or
OC3/ATM or OC12/ATM. The backbone routers are installed in redundant pairs,
and have multiple connections to the switches.

Here you can begin to see the problem - the management systems for the routers
see only a L2 "cloud" (if you're lucky!) which interconnect them. It would
be very, very nice to be able to have one management platform which can be
used to record the relationships between the L3 devices and the L2 devices,
rather than having them be completely distinct from each other.

Another example: consider you customers are terminated into a network hub.
Say you've got a customer with a T1 access circuit. Well, the circuit is
not an atomic object - it has many constituent components. There could be a
local-loop from the customer premise to an inter-exchange carrier. There's
a circuit segment provided by the IXC. There's a local loop between the
IXC and the serving network hub location. But wait, there's more! The
T1 circuit being delivered to the network hub is muxed up into a channelized
DS3. The channelized DS3 connects to a frame relay switch, and there's a
frame relay VC that terminates in a router also connected to the switch.
(I'm not making this up; there's lots of stuff like this, and even more
complicated).

What I'd like to be able to do is determine:

- which customers are affected if the channelized DS3 goes out of service?
That
is, there is a notion of the DS3 acting as a container for a number of other
circuits.

- which customers are affected if the HSSI between the frame switch and the
router fails? That is, which customer Frame Relay VCs are on which ports on
which devices?

- how many customer circuits are using some specific IXC coming into the
pop? What are their circuit numbers?

To answer these questions, you need to be able to record and express both
physical connectivity and logical connections made over the physical resources.
You don't need to model the VC routing that the frame network does; you
only need to know what the end points of a series of concatenated components
are.

And these relationships have to be extensible. Consider that I now have
a DS3 frame relay NNI between MY frame relay switch and a local exchange
provider's
frame switch, with multiple VCs, each corresponding to a customer. This is
now stat-muxing done at L2 for me, rather than TDM muxing done a L1, but
there's
still many of the same issues.

And I haven't even talked about physical cable management with DSX-1 and DSX-3
panels, cross-connects and other detail.

The world is getting much more complex, rather than simpler, and these
"island management systems" are not going to continue to work. While I
believe they will continue to exist, they'll need to operate on an extract
of some more comprehensive topological description of the network. The problem
now is that there isn't just one; there lots of them. And when there is more
than one, then most (if not all) are wrong.

Louis Mamakos

--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.