management of large management of large networks
play

Management of Large Management of Large Networks New Frontiers in - PowerPoint PPT Presentation

Management of Large Management of Large Networks New Frontiers in Computing San Jose State University A August 14, 2010 t 14 2010 P Pradeep Kathail d K th il CTO, NSSTG, Cisco pkathail@cisco.com pkathail@cisco.com 1 Agenda Agenda


  1. Management of Large Management of Large Networks New Frontiers in Computing San Jose State University A August 14, 2010 t 14 2010 P Pradeep Kathail d K th il CTO, NSSTG, Cisco pkathail@cisco.com pkathail@cisco.com 1

  2. Agenda Agenda  Reasons for Network Growth  Concepts  New Paradigm  Q & A  Q & A 2

  3. Reasons for Network Growth 3

  4. Unified Computing Compute Virtualization Network Platform Platform Platform Integrated architecture simplifies set up improves business Integrated architecture simplifies set-up, improves business metrics, and enables dynamic provisioning 4

  5. Power Management Smart Grid Smart Grid Energy Energy Information Information Distributed Generation Sources Industrial Customer Power Generation Federated Data Centers Commercial Customer Transmission (Utility) Distribution (Local Utility) Network Network Control Control Residential Customer Center Center 5

  6. Smart Objects Healthcare An endless number of applications Defense Energy Saving (I2E) Predictive maintenance Improve Productivity Agricultural New Knowledge g Intelligent Building Intelligent Building Smart Cities High-Confidence Transport and assets tracking Industrial Automation Heal th Smart Home Smart Grid 6

  7. Other Observations…. Other Observations….  Network Management tasks more complex  Business critical application increasing depend on net  High dependency  Higher availability requirements  Short reaction times  Continuous cost pressure 7

  8. 8 Concepts

  9. Important Concepts p p  Hierarchical Data -- Hierarchical – -- Data-Driven– -- Idempotent – -- Efficiency -- -- Bulkable – -- Lenient –  Bulkable Strict ordering, strict resource validation are Natural : XML is a tree Configure bunch of things in one shot. Very few verbs: “Policy defines what reality should look like  Idempotent Should not waste space difficult things to deal with and devices converge”  Lenient  Lenient  Find  Find Ability to manipulate on multiple subtrees in Unit of description (e g configuration) is a Unit of description (e.g. configuration) is a Ability to manipulate on multiple subtrees in Should not require a supercomputer to  By class(s) self-contained XML document a single operation Precision of interactions implies complexity  Data-Driven process  Subtree(s) Scope and heavy coupling Need to assume best default behaviors.  Transactional Transactional Any object on the tree is a sub-tree root Any object on the tree is a sub tree root Mutation or retrieval of completely Mutation or retrieval of completely + Filtering + Filtering Should not be verbose Forgive redundant calls unrelated parts of the data tree  Asynchronous Execution  Config Configuration and retrieval are Should not require multiple interactions to  Efficiency  Single Subtree Results in less cross-system interactions manipulation of sub-trees p g y achieve simple things hi i l thi  Many subtrees Simple object naming/identification Lean is always good in computing 9

  10. 10 New Paradigm

  11. Basic Principles p  No top-down management Triggers gg P li Policy Policy Resolution repository  Management == extension of control plane plane resolution policy  Management by end-point-resolved policy policies and rules • Treat generalized requirements as triggers • Treat generalized requirements as triggers • Configuration necessary to fulfill a policy requirement is resolved as policy Relay trigger agent • Policies are self resolved and fully Policies are self resolved and fully actions rendered locally • Requirements on other end-points are relayed as requirement triggers  Conceptually recursive end-point (device) 11

  12. Conceptual Policy Model Resource Policies Match Capabilities Capabilities Requirements Requirements Provider Result Network Policies 12

  13. Policy Abstraction Definition Layer rendering rules Policy definition is performed via Abstract act architecture and implementation abstra P li Policy independent abstract sets of policies. Architecture There are no dependencies on (implementation Rules agnostic) connectivity, vendors, models etc. Implementation Implementation Constraints Rendering Layer Abstract policies are translated or Deployable “rendered” into Deployable Policies. cific Translation Deployable policies are automatically Deployable policies are automatically Policies Policies Template Template spec T Template l t generated from Abstract Policies with (implementation implementation specific knowledge concrete world specific, (s.a. devices, resources, topology.) templates) and engineering “rendering” rules. Topology uration Activation Layer Concrete Resources Concrete ed Deployable Policies are resolved and deploye M d l/C Model/Co configu Model/Co applied to specific resources nfig. resulting in very device and instance nfig. Devices specific configuration. 13

  14. 14 In the end …

  15. Summary … y  Network are becoming mission critical and integral part N t k b i i i iti l d i t l t of business and day-to-day life  Networks are becoming large with new physical and  Networks are becoming large with new physical and virtual devices  Changes require short reaction times g q  Network Management need to become more distributed  Network Management need to become more distributed with common policy and triggers  Devices interpret and enforce policy and rules p p y 15

  16. 16 Q & A Q &

Recommend


More recommend