Transcript 9. Network Management Theory and Practice

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





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





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


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
Revised Spring 2006
Rudimentary NMS Software
Components
6
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
Revised Spring 2006
Rudimentary NMS Software
Components
7
MIBS Again
Revised Spring 2006
Rudimentary NMS Software
Components
8
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
Revised Spring 2006
Rudimentary NMS Software
Components
9
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
Revised Spring 2006
Rudimentary NMS Software
Components
10
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
Revised Spring 2006
Rudimentary NMS Software
Components
11
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
Revised Spring 2006
Rudimentary NMS Software
Components
12
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
Revised Spring 2006
Rudimentary NMS Software
Components
13
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 labelbased technologies (ATM, MPLS, FR, and PseduoWires) 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
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





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


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
Revised Spring 2006
Rudimentary NMS Software
Components
17
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
Revised Spring 2006
Rudimentary NMS Software
Components
18
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
Revised Spring 2006
Rudimentary NMS Software
Components
19
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
Revised Spring 2006
Rudimentary NMS Software
Components
20
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
Revised Spring 2006
Rudimentary NMS Software
Components
21
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
Revised Spring 2006
Rudimentary NMS Software
Components
22
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
Revised Spring 2006
Rudimentary NMS Software
Components
23
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
Revised Spring 2006
Rudimentary NMS Software
Components
24
Supplemental Material

The following web page provides information about
SNMPv3:



Specifications approved by Internet Engineering
Steering Group (IESG)
Documentation
Implementations
Revised Spring 2006
Rudimentary NMS Software
Components
25
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)
Revised Spring 2006
Rudimentary NMS Software
Components
26