Complex Systems & Autonomic Networks, Part 3: Modeling the wrong map

Modeling the wrong map

“We read unconsciously into the world the structure of the language we use.”
- Alfred Korzybski

---

Applying “Map is not the Territory” to data modeling:

The prior Frame Relay Billing example (This blog: The New Telecom Ecosystem, Part 6 & Complex Systems & Autonomic Networks, Part 2) also underscores significant issues with standard, universal data models. These models seek to abstract similar features and build root organizing principles from which other more detailed objects and features will be derived. This abstraction to principle or root features is fundamental to achieving the unification promised by a data model. But the source idea from which abstraction is pulled is past networks and experience - picking from the past data and experience cannot reliably predict a future network organizing principle.

Models which rely on circuits as high level organizing principles can never represent packet routed networks. John Strassner in originally designing DEN recognized this, but few users of DEN do. But there are more subtle implications (picking again on the older stuff). An issue with TINA modeling was its reliance on past architectures as a unifying principle. Now TINA worked very hard to abstract out biases from the past and the then current ways of representing networks as layers and circuits. So they abstracted the notion of a circuit into a path, and represented paths as ordered lists of other path links (almost but not quite reaching the dynamite principle of recursion - too bad). This was a much better way of capturing what went on in Frame Relay networks than the virtual circuit model. But it still forced on networks the notion that networks built a road which channeled communication from one part to another - a product-oriented business goal, not an intrinsic part of the network. Paths were “nailed up” in the model; where in routed networks, each switch just knows who it is linked to and what links to put and outgoing packet on. TINA worked for ATM but not for IP, at least prior to MPLS.

Fallacy of layers: In abstracting the traditional concept of layers in a network, TINA-C went too far. They tried to capture both the structural organization of a network and the layering of protocols in one concept. As such, TINA-C layers were always uncertain/fuzzy and often applied differently by different modelers. Linking one layer to another was the concept of a lower level path being associated with a higher level path. Again, if you step back, this is not a physical construct of modern networks. Layering is not real; what occurs is actually tunneling: Fiber carries optical information (SONET), SONET carries ATM which carries IP, or better, SONET caries IP directly. Ethernet links are different but can be similarly described. The only real connection is when switches of one network type are directly connected to another via protocol matching boards connected between switches/routers.

There is no real identity of a SONET ring with an ATM virtual circuit with an IP/MPLS path. In fact, to make networks resilient, you must discard the notion of a solid association; this should be a decision of the network as each technology seeks to maintain its own continuity during outages. In autonomic restoration time (microseconds to seconds), you cannot have a central network manager trying to tell the ATM network to switch in a transactional coordination with the SONET cutover.

Modeling with agents: What might work is a distributed systems model (not data/information model) where the action of restoration was embodied in a software agent who maps the same rules as the SONET switch; and another agent which maps the ATM restoration rules. Each follows the switching actions and time of the other; but in this case there might be time for the SONET agent, monitoring a switchover of its switch, to send a message to the ATM agent that corrective restoration is accomplished before the ATM switches. Then the ATM agent could intervene to keep the ATM circuit from jumping unnecessarily. Or else could coordinate an automated switch from where the ATM virtual circuit landed to the restored SONET path.

Of course, real, modern networks are more complex than this. Each network has its own technology and rules for QoS. Each might make separate decisions on the acceptability of a route. Perhaps it is better to let the decisions remain independent and float the network. Again, an agent can be complex enough, and identified in its rules closely enough, to adapt to these policy details. Distributed agents model the system accurately, precisely because (1) the agent talks directly to the device and (2) agent talks directly to another device agent if and only if the network switch is directly connected to another network switch.

“Any organism must be treated as-a-whole; in other words, that an organism is not an algebraic sum, a linear function of its elements, but always more than that. It is seemingly little realized, at present, that this simple and innocent-looking statement involves a full structural revision of our language…”
- Alfred Korzybski

Distributed Agents were a key component in the origin of the Fine Grained approach to network management. Each switch has its own agent and agents interact with other agents and with higher management services. Instead of the current trend of massive element managers doing everything possible for a network domain and costing millions of dollars, you have essentially a cheap autonomic element manager for every switch. A group of agents/services, properly implemented, will automatically find each other and dynamically associate into interaction communities - based on the switching/routing parameters in the interlink boards of the monitored/controlled device the agent is modeling. It does not matter to the model or the agent if the parameters are pushed down into the device (provisioning/configuration) or pulled from the device (performance, state management, or inventory) - it is all the same. So old FCAPS silo organizing functions are irrelevant.

In the Fine Grain approach, the intelligence lies in the self-organizing system of agents/services, not in the data model. No overall data model is needed. Each agent/service only needs to know how to communicate with the immediate community with which it associates. Because decisions are distributed, the information does not need to be funneled up to one common description for action by a centralized management application. The agents are distributed, distributing the policy information, instead of the data being shared out via a common central data repository.

Loosely coupled: In the Fine Grain approach, interfaces become more important than information models. Because communities can be localized and specialized, an agent in another community need not understand anything in common with an agent elsewhere. Hypothetical example, the SONET switch agent for Verizon can be a completely different implementation from the multi-service switch agent for Massergy. They only need a translation agent where the networks interconnect to perform secure distributed decision making about coordinated network actions where they intersect.

Large component SOAs (Service Oriented Architecture) can also use this principle. (IBM is a leader in applying and designing macro agent-based SOA’s; however, they discontinued efforts at applying these to networks.) The interface is still the key and the domain of common knowledge and similarity need not extend beyond immediate interface interactions. But in these cases, unified data models are often needed to coordinate macro-scale business principles. But here the 80-20 rule works: you can satisfy 80% of the business needs by unifying 20% of the information.

Smaller component efficiencies: Now there are still economies of scale that can be realized by making agents similar to each other. Agents can be built from a similar template. The agent can be specialized by (1) assembling in the needed interface definitions, (2) the local data interaction model and (3) by specialized policy. The interface establishes the dialects the agent understands. The policy determines the behavior of the agent. We will cover policy in later parts of the blog series and look much deeper into efficiency.

There are also economies of scale in having a common information model shared by all (even Fine Grain). What I am emphasizing is that this common model, while valuable, cannot itself become a goal of architecture (as we once made it.) It is only a means that must be selectively applied and held to rigorous scrutiny. While we scrutinize data models today, it is for correctness to the principles of data modeling. We should even more so, take a hard look at “if the model is congruent with the reality of the modern network”.

It is also not possible to future proof an information model. It cannot be detailed enough to be useful and still accurately predict the way future networks will be organized. A model may last a whole technology generation - but new models must arise for new network generations. And these could be fundamentally different. By fundamentally different, I emphasize that future mdoels may not be data models at all, but complex systems models.

Wedge Greene is a consultant for LTC International.