1 / 26

Chapter 9

Chapter 9. Network Management, MIBs, and MPLS Stephen B. Morris. 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. MIBS Again.

amela-frank
Télécharger la présentation

Chapter 9

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 Rudimentary NMS Software Components

  3. MIBS Again • 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 Rudimentary NMS Software Components

  4. MIBS Again Rudimentary NMS Software Components

  5. MIBS Again • 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 Rudimentary NMS Software Components

  6. MIBS Again • Default values avoid issues with languages such as Java which are slow to handle to handle exceptions create by null data • SNMP may be approaching a physical limit, due to scale of emerging NEs: • MIB design must incorporate this trend and 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 Rudimentary NMS Software Components

  7. MIBS Again • 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 VoIP traffic through the tunnel Rudimentary NMS Software Components

  8. MIBS Again Rudimentary NMS Software Components

  9. Intelligence in Network: Manufacturer • Present NMS generation exhibit similar problems of manufacturing systems automation and control in 1980s-1990s • 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 Rudimentary NMS Software Components

  10. Intelligence in Network: Manufacturer • 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 Rudimentary NMS Software Components

  11. Pushing FCAPS Into Network • 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 Rudimentary NMS Software Components

  12. Service-Level Network Components • 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 Rudimentary NMS Software Components

  13. Generic Objects Realized Using Software Abstraction • 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 Rudimentary NMS Software Components

  14. Generic Objects Realized Using Software Abstraction • 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 getLabelValue(), can be used for a number of label-based technologies (ATM, MPLS, FR, and Pseduo-Wires) versus getMPLSLabelValue() because it is specifically tied to MPLS • Key point is generic outer code • Technology gets specific only at well defined points in the code Rudimentary NMS Software Components

  15. Generic Objects Realized Using Software Abstraction Rudimentary NMS Software Components

  16. Need For End-to-End Security • 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 Rudimentary NMS Software Components

  17. Shrink-Wrapped Solutions or Consultancy Buy-in • 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: • 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 Rudimentary NMS Software Components

  18. Integration with OSS Layers: Northbound Interface (NBI) • 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: • 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 Rudimentary NMS Software Components

  19. Roles of QA, IT, and Developers • 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 Rudimentary NMS Software Components

  20. Thin Software Layers • Thin software layers in client, middleware, and server components of NMS are desirable: • 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 Rudimentary NMS Software Components

  21. Facilitating a Solution Mindset • Facilitate NMS products solutions mindset: • 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 Rudimentary NMS Software Components

  22. Summary • 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 Rudimentary NMS Software Components

  23. Summary • Benefits of NMS: • 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: • 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 Rudimentary NMS Software Components

  24. Summary • 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 • SNMPv3 provides security critical to successful network management Rudimentary NMS Software Components

  25. Supplemental Material • The following web page provides information about SNMPv3: • Specifications approved by Internet Engineering Steering Group (IESG) • Documentation • Implementations Rudimentary NMS Software Components

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

More Related