Chapter 9 Network Management MIBs and MPLS Stephen

Chapter 9 Network Management, MIBs, and MPLS Stephen B. Morris Revised Spring 2006 Rudimentary NMS Software Components 1

Network Management Theory and Practice Purpose of this chapter is to draw together the main threads running through the book and revisit some of them, now that the foundation chapters are completed Revised Spring 2006 Rudimentary NMS Software Components 2

MIBS Again n n MIB can be used to store rules and actions Policies consist of conditions (or rules) and actions taken when conditions are met Intercolumn dependency an important area of MIB design Where value of column X provides context for column Y, or vice versa Figure 9 -1, an example where a tunnel instance is a backup for a primary tunnel Revised Spring 2006 Rudimentary NMS Software Components 3

MIBS Again Revised Spring 2006 Rudimentary NMS Software Components 4

MIBS Again n n Two tunnels can be configured to share same set of resources (e. g. , bandwidth or duplicate resource) Dependencies contribute to MIB complexity Clear rules, best way to implement intercolumn dependencies NMS should not use agents to infer relationships MIB objects default values decrease SNMP-handling software complexity in an NMS Revised Spring 2006 Rudimentary NMS Software Components 5

MIBS Again n n Default values avoid issues with languages such as Java which are slow to handle exceptions create by null data SNMP may be approaching a physical limit, due to scale of emerging NEs: n n n MIB design must incorporate this trend allow for possible techniques such as compression Larger PDUs could be used because each field could be compressed Downside, more complicated PDU handling and slower NE response due to compressed overhead Revised Spring 2006 Rudimentary NMS Software Components 6

MIBS Again n n Moving individual packet-handling decisions outside of the NMS increases IP packet high speed MPLS FEC-To-NHLFE (FTN) Management Information Base, another important MPLS MIB providing a framework for moving decisions outside the NMS Forward Equivalence Class (FEC) a group of IP packets forwarded with same traffic-handling treatment Figure 9 -2, illustrates two IP traffic streams feeding into an MPLS LER (Edge Router 1) Objective, push the SMTP traffic through LSP and Vo. IP traffic through the tunnel Revised Spring 2006 Rudimentary NMS Software Components 7

MIBS Again Revised Spring 2006 Rudimentary NMS Software Components 8

Intelligence in Network: Manufacturer n n Present NMS generation exhibit similar problems of manufacturing systems automation and control in 1980 s -1990 s Need for distributed intelligence was compelling, local intelligence put great strain on centralized management and control systems One solution, use local intelligence in network controllers (similar to SNMP agents) Using local sensors and low-cost processing power wherever needed rather than in a central location Revised Spring 2006 Rudimentary NMS Software Components 9

Intelligence in Network: Manufacturer n n n These distribute controllers only reported serious problems to a central supervisory management system This freed the central management system to perform more complex calculations, such as scheduling production runs and reporting on scrap NMS probably will need more agent intelligence Path Based Mesh Network (PBMN) provides basis for this by allowing NEs take some control responsibility FTN MIB provides an SNMP-based example of policy usage Revised Spring 2006 Rudimentary NMS Software Components 10

Pushing FCAPS Into Network n n FTN MIB provides an SNMP-based example of policy usage Other types of decision-making can be pushed into network such as billing and accounting Usage-based billing allows for improved SP margins and network resource use Riverstone Lightweight Flow Accounting Protocol (LFAP) is an effort to provide more accurate billing and accounting in the NEs Revised Spring 2006 Rudimentary NMS Software Components 11

Service-Level Network Components n n n Aggregate objects combine base-level components to create some type of higher level service Managing complex services remains one of biggest problems faced by industry New MIBs may be needed to represent these aggregate objects, realizing them may require new signaling protocols Revised Spring 2006 Rudimentary NMS Software Components 12

Generic Objects Realized Using Software Abstraction n n Increasing deployed technology mix in enterprise networks places growing burden on NMS Software components used to realize NMS must become increasingly abstract Needs to occur at all software levels, with technology specifics cleanly separated in their own layers When application code needs access to NEs via SNMP, all calls should be made to separate code Business logic should not mix with network device technology access code Revised Spring 2006 Rudimentary NMS Software Components 13

Generic Objects Realized Using Software Abstraction n n Figure 9 -3 provides an idea of demarcation All code written to access specific technology should be generic as possible For example: better to name a class method get. Label. Value(), can be used for a number of labelbased technologies (ATM, MPLS, FR, and Pseduo. Wires) versus get. MPLSLabel. Value() because it is specifically tied to MPLS Key point is generic outer code Technology gets specific only at well defined points in the code Revised Spring 2006 Rudimentary NMS Software Components 14

Generic Objects Realized Using Software Abstraction Revised Spring 2006 Rudimentary NMS Software Components 15

Need For End-to-End Security n n n international terrorist threat has altered managements awareness and priority Disaster recovery planning and service survivability now an integral part every network planning Need End-to-End security at every network level Should employ authentication and encryption when connecting to an NE EMS Should use Authentication and encryption to avoid little or no clear text exchange between an NMS and EMS, OSS and NMS, and so on Revised Spring 2006 Rudimentary NMS Software Components 16

Shrink-Wrapped Solutions or Consultancy Buy-in n n NMS products (and NEs) increasingly homogeneous, often offering base-level features, fault and performance management Better deployment model results if NMS products are well-designed with characteristics such as: n n High-quality (standard) MIBs Generic software components such as GUIs allowing management of generic connections rather than technology specific objects Flow-through provisioning with thin software layers Adherence to standard NBIs Revised Spring 2006 Rudimentary NMS Software Components 17

Integration with OSS Layers: Northbound Interface (NBI) n n n Communication between OSS and NMS crucial to successful management of large SP networks OSS needs to communicate with NMS in same way as NMS needs to communicate with EMS Two ways of implementing an NBI layer: n n Put software in OSS layer Pus software in NMS Ideal arrangement, NMS and OSS use same code NBI layer investment (Figure 9 -4) worthwhile, ease of OSS integration Revised Spring 2006 Rudimentary NMS Software Components 18

Roles of QA, IT, and Developers n n Close cooperation needed in vendor organizations to deliver NMS products Developers should delegate NE administration to IT and involve QA in every step of the development process QA assures quality rather than just carrying out software integration testing Developers become true knowledge workers—delegating NE administration to the IT and partnering with QA to ensure solution development Revised Spring 2006 Rudimentary NMS Software Components 19

Thin Software Layers n Thin software layers in client, middleware, and server components of NMS are desirable: n n n Has small number of lines of code Is simple – no excessively complex code Is fast and easy to modify, maintain, and test Spread complexity over adjacent layers as in network protocol layers (Figure 9 -3) Strikes balance between form and function – code size and complexity minimized while overall function optimized. Default database values and flow through provisioning minimize code size Revised Spring 2006 Rudimentary NMS Software Components 20

Facilitating a Solution Mindset n Facilitate NMS products solutions mindset: n n n Engineers should focus on products not just projects Take ownership of large product areas (e. g. , one or more FCAP areas) Adopt strategic interest beyond current software release cycle Product engineers focus on many small, well defined pieces of work Product engineers generally produce best solutions Revised Spring 2006 Rudimentary NMS Software Components 21

Summary n n n MIBs is central role in network management and major theme of book Standard MIBs should be used whenever possible Network management technology solutions a challenge for software developers MIBs accommodate pushing more intelligence into NEs (e. g. , FTN MIB) Increased NE sophistication will improve network scalability Revised Spring 2006 Rudimentary NMS Software Components 22

Summary n Benefits of NMS: n n Provide overall network perspective Provide centralized management Possible to proactively manage the network using policies Adding new NE to an SP network can cost in excess of $20 million, most likely due to: n n NMS changes required for new hardware and associated NMS modules Interoperability problems with existing devices Firmware bugs in new devices Integrating management for NEs into existing OSS workflows and business practices Revised Spring 2006 Rudimentary NMS Software Components 23

Summary n n Similar cost apply to large enterprise networks, many technologies implemented long before standards established SNMP standard is widely deployed NMS and NE developers use standard tools such as UML and SDL in conjunction with standard programming languages to create increasingly open systems SNMPv 3 provides security critical to successful network management Revised Spring 2006 Rudimentary NMS Software Components 24

Supplemental Material n The following web page provides information about SNMPv 3: n n n Specifications approved by Internet Engineering Steering Group (IESG) Documentation Implementations Revised Spring 2006 Rudimentary NMS Software Components 25

Supplemental Material n SNMP Alternatives: n n n Common Management Information Protocol (CMIP) Common Management Information Services (CMIS) OSF Distributed Management Environment (DME) Hierarchical Network Management System (HNMS) Hyper. Media Management Schema (HMMS) n n Hyper. Media Management Protocol (HMMP) Hyper. Media Management Architecture (HMMA) Revised Spring 2006 Rudimentary NMS Software Components 26