KP Architecture (v4) Dietterich’s summary of discussions with Clark, Langley & Ramming July 10-12, 2003 Revised September 2, 2003 Revised September 23, 2003 Revised October 7, 2003

Proposal: Hierarchical Reactive System Multiple layers Each layer has the following components –Sensors: measure aspects of network state, external inputs –State Model: (partial) description of the state of the network –Control Settings: “frobs” that higher-level layers can modify –Reasoning Engine: decides what actions to take based on the above three items –Effectors: actions that it can take (may involve setting lower-level frobs) Sensors State Model Control Settings Reasoning Engine Effectors

Example: Packet Forwarding and Routing Link State State Model Control Settings Shortest Path Algorithm Effectors Input Queues State Model Routing Table Hash Lookup Output Queues Forwarding Updates OSPF

Multilayer Architecture Higher layers exhibit –larger spatial and temporal scale –more complex reasoning –more complex models

How High Can We Go? Packet Forwarding OSPF MANET: dynamic service repositioning AS-level design?

AS-level Design and Configuration engineer Device Status/ Catalogs State Model: Available Components Goals and Policies Reasoning Engine Design net admin Device/ Link Status State Model: Current Status Design Reasoning Engine Transition Plan Device/ Link Status State Model: Current Status Plan Reasoning Engine Effectors Design Level Planning Level Deployment Level

Merge/Join Negotiation is needed at multiple levels –Negotiation of conflicting requirements (e.g., same mail security policy) –Coordination of design choices (e.g., use same type of routers) –Coordination of deployment schedules (e.g., cutover on same day) Goals and Policies Reasoning Engine Design net admin Design Reasoning Engine Transition Plan Reasoning Engine Effectors Design Level Planning Level Deployment Level Goals and Policies Reasoning Engine Design net admin Design Reasoning Engine Transition Plan Reasoning Engine Effectors

Why Do We Need Active Probing? If our multi-layer architecture could observe all relevant state changes and respond to them, then we would not need a separate diagnostic system Hypothesis: The internet is too large to make it practical to deliver all relevant information to edge-located reactive systems Conclusion: There is still a need for problem- driven diagnosis that actively gathers information to localize and repair network faults

Example: Missing mail When ISI changes their spam filter, do they notify the KP? Does some reactive level warn the sysadmin that this change will prevent large s from reaching the KP list? Maybe, but maybe this is the intent of the sysadmin. Does the KP propagate this information to Chris Ramming (and all other internet users) to tell him that IF he sends large s, they will not be distributed to the KP list? Impossible! It seems more efficient to wait for edge-users to complain and then diagnose the problem / policy conflict

Example: AS Prepending Typo Could a reactive level detect this typo and alert the net admin? If not (e.g., because some AS’s will not deploy the reactive architecture), then it must be detected during diagnosis In this sense, diagnosis is a backup to the reactive stack

Requirements for Diagnosis Inputs –End-user FIXIT requests –Sensor-detected problem signatures Knowledge –Desired behavior (“success stories”)? [Where does this come from? How is it represented?] Actions –Active sensing across multiple levels and regions expensive sensors network tomography Outputs –Detected policy conflicts –Detected configuration conflicts –Detected remote configuration errors I’m assuming local errors would be prevented and/or immediately caught by reactive levels

Scenarios The following slides give a series of scenarios that describe how the architecture might work.

Scenario 1: Policy Change Soldier requests satellite image download to help escape from tight position. Request is refused by firewall. He invokes the Diagnoser. Diagnoser determines that this is a policy conflict and alerts the Negotiator who resolves the conflict (with the help of the Network Administrator or Commanding Officer?). The policy is changed, the Configuration Manager changes the firewall rules, and these are uploaded into the firewall by the Executor. The soldier is told that he can download the image now. [We need to make this whole process fast!]

Scenario 2: Equipment Loss A router is destroyed as a result of a vehicle accident. The Design Level monitors the validity of the design it produced (which was based on a set of available components). It notices the mismatch between the current set of components and the original set upon which the design was based. It constructs a new design. The Planning Level then notices that the design has been changed, so it modifies its plan for implementing the design. The Deployment Level then makes appropriate changes to implement the plan (which may require asking technicians to install a new router, run new cables, etc. In a wireless network, it might just require assigning the routing function to a different node.)

Scenario 3: Move and Reassemble Network Part of the network is to be disassembled and moved to a new location. The Network Administrator changes the Goals to indicate this. The Designer changes the Design to reflect the changed goals. The Planner creates a schedule of network changes so that the overall network remains up throughout the move. It then interacts with technicians to execute the schedule. Note that incidents (like loss of connectivity) may occur during the schedule, but those will not be treated as problems if they are consistent with the design and schedule. Unanticipated problems (General X insists on being connected for 10 more minutes) may be detected (by a change in device availability at the Planning level? Or by General X complaining to the Diagnosis system?)

Scenario 4: Merge Two Networks Two networks are to be merged. The network administrators of both networks indicate this by modifying the goals in their respective networks. The Negotiators for the networks then analyze the requirements of the two networks to identify policy and goal conflicts (e.g., network 1 does not support internet radio downloads, but network 2 does). Network administrators may need to be involved to resolve these conflicts. When the conflicts have been resolved, the requirements can be updated and merged. The result is that there is now only one Designer, one Planner, and one Deployment level. The Designer constructs the new design, the Planner constructs an implementation schedule for putting it in place. Then the plan is Deployed.

Scenario 5: Peer Two Networks Two networks are to be connected (e.g., as peers) but not merged. The network administrators add a "peering" goal to their requirements. The Negotiators for the networks then analyze the requirements to identify policy and goal conflicts. When the conflicts have been resolved, then the Designers coordinate to construct designs for the two networks (e.g., by choosing the number and locations of peering points). The Planners coordinate to construct roll-out plans for the peering points. The Deployment levels negotiate on the exact timing of the peering.