Re: Tkined - A few questions

Doug Hughes (Doug.Hughes@Eng.Auburn.EDU)
Wed, 11 Jun 1997 08:02:02 -0500

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

You'd almost need a map that has links of multiple colors (or dashed or
something) to represent physical/logical relationships. You'd lose any
kind of auto-extensibility this way (dynamic map building, auto-reconfiguration,
discovery, etc) because if you did it, your physical updates would become
a jumbled mess. So, the end result would be something totally manual to
manage. This might not be bad depending on the level of effort you wanted
to put into it.
On the other hand, if you had all your views visible at the same time, it
would probably be very ugly. You'd want a way to ascribe an object into
one or more views with a tag of some sort, and that way hide or show the
views that you wanted to see. For the physical stuff, how would you determine
that the link is down? You'd have to have some sort of out-of-band management
strategy for your T-1 mux for instance (unless it was new enough to support
some sort of SNMP management).
You'd need an arbitrary way to desginate a management policy to a device
regardless of its layer/level. Then, your map would have to make all of
the links connected to that device go down.

Boy, the devil is in the details isn't it? ;)

____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
doug@eng.auburn.edu

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