Network Management, Management Information Base (MIB)s and Multiprotocol Label Switching (MPLS)

1. Network Management, Management Information Base (MIB)s and Multiprotocol Label Switching (MPLS) Principles, Design and Implementation Stephen B. Morris Chapter 6 Network Management Software Components By Stanley Zurita Mohamed Abdallatif

2. NETWORK MANAGEMENTSOFTWARE COMPONENTS There are many possible solutions to NMS development - this chapter describes one possible structure • Server-side components • Network-receiving asynchronous • Network-receiving synchronous • Network-sending • Database access • Client-side components • Middleware components • Data presentation, such as XML • Northbound interface

3. Figure 1

4. Typical servers provide the following functions. • Servicing client user requests • Issuing provisioning operations, such as writing to agent MIBS(inserting table entries, updating/deleting existing objects) • Special-purpose listening operations, such as monitoring LSP operational state • Providing generic service, such as scheduling • Providing specific service, such as NE, firmware and configuration data-base back-up, restore, and distribution • Handling incoming notifications from network

5. Database forms the glue that ties together the major component • Clients • Middleware • Server • NE’s

6. Thin client tend not to use database directly and instead rely on the server to manage the database • Recording client-initiated operations, such as creating FR or ATM virtual circuits • Storing the detail of scheduled operations and associated result

7. Thin client can be based on standard Web browser, there can be many such clients, and where to carry out bulk of the processing is an important design decision. If the principal requirement for client software is fast execution, then as much as possible of the MIB and database access should be carried out by the client rather than the MIB. If the client software is required to be simple and intuitive to use, then it should be designed to be as generic as possible. Generic software hides complex network data as much as possible and presents simple visual object proving default values where appropriate.

8. This involves setting the MIB object values for • Bit rate • Parity • Number of data bits • Number of start bits • Number of stop bits, and so on

9. Fault Server The purpose of the Fault Server is to process NE notification. It faces into the network and seeks to maintain parity between the NMS picture of network faults and the real situation in the network. A Fault Server will generally provide the following features: • Listening for notifications • Determining the underlying problem (root-cause analysis) • Updating persistent repositories and any GUI visual indicators

10. Fault Server Database Tables • Node ID(the Key) • Description: A text string embedded in the notification explaining the fault • Origin: The originating NE(processor, card, fabric,etc..) for the fault • Status: active, cleared, acknowledged( the user knows about the fault but has not cleared it) • Color: Red for active, blue for acknowledged, green for clear

11. Topology Update • CORBA • J2EE • JAVA RMI • RPC • Database update

12. Configuration Server The purpose of the configuration server is to execute client-initiated directives made against NE’s. Like the Fault Server, it also faces into the network but operates in less open-ended way because it is not required to process asynchronous NE-originated notifications.

13. Let’s assume that a client user creates an LSP (label Switched Path) there are three types • Signaled • Best-effort • Unidirectional

15. Secure User • Security Setting; • No authentication and no encryption • Authentication and no encryption • Authentication and encryption

16. Trace Files • Software bugs • SNMP timeouts, such as a third-party NE that has a slightly slow (or heavily loaded) agent • Bad values in MIB operations, such as trying to write an illegal value to a MIB object

17. Generic Connection Table Update • ATM virtual connection (PVX and SPVX0 • MPLS LSP( signaled and unsignaled) • FR cross connections into an MPLS core • SONET path

18. Topology Update • Change the administrative status of a connection from up to down • Creating a new LSP • Deleting an existing LSP

19. Configuration Server Database Tables • Generic connection table: these contain data relevant to all connection types Keyes by index value or origination/ destination node IDs • Technology-specific connection tables: These contain data relevant to specific connection types, such as ATM PVX and LSPs • Operations log tables: These are for recording configuration change • Operations result log tables: These are recording all configuration change results

20. ACCOUNTING SERVER • Accounting and performance software share a number of similarities. The Accounting Server faces into the network and receives data record periodically generated by NEs. Often, the data records are emitted based on a preconfigured time. It is also possible for an accounting Server to poll MIBs for specific data ultimately, accounting data is concerned with billing users for network resources consumption.

21. Mediation • Mediation is the process of analyzing the raw data generated by NEs to produce standard format billing details for downstream use by third-party applications (from organizations such as ACE*COMM). It is not necessary to use standard formats if the billing application is proprietary. However, standard format have the merit of allowing different third-party application to be swapped in as required.

22. Aggregation • This is the process by which separate CDRs are combined. An example is an ATM PVC that spans a number of NEs • Number of IP packets transported (if the circuit is an LSP) • Number of cells transported per second (if the circuit is an ATM connection) • Number of cells dropped due to excessive input traffic • Average bandwidth used by the cell traffic • Number of SLA contract violations

23. Correlation • Correlation is the process of combining multiple units of aggregated data with the details of the ultimate bill recipient, that is, one customer. • Number of cells sent to or received from the SP network • Bandwidth used in transporting the data across the ATM link

24. Reports • Utilization of objects, such as LSPs • The average and peak numbers of IP packets transported by the LEP • The bandwidth consumed

25. Performance Server • The purpose of the Performance Server is to analyze network data in order to • Determine if problems exist prior to their affecting services • Maximize network utilization • Pre-empt the occurrence of congestion • Demonstrate compliance with agreed SLAs • Indicate when extra network investment is needed(capacity planning)

26. SLA Alert • It is very important for enterprises to avoid violating SLA terms because there may be financial penalties.SLA alert can be issued based on ongoing analysis of trends in an effort to pre-empt violations before they actually occur.

28. This SLA indicates that IP traffic from 10.81.1.45 port 444 will land in the SP network on a 10Mbps link destined for 10.81.2.89 port 445. The interpacket arrival time is specified to be no more than 1 millisecond with no packet arriving out of order. A tunneling technology such as MPLS or L2TP could be employed to achieve the latter.

29. Topology Update • When congestion is imminent on a given link • When a virtual circuit is being presented with excessive traffic-it may be necessary to add extra bandwidth to the circuit

30. Performance Server Database Tables • Nodes • Interface • Links • Virtual connections • Each table has separate columns for relevant performance • Number of incoming and outing packets, cells, and frames • Bandwidth in use • SLA status

31. Security Server • If there is one area of network management that has moved to the top of the operator’s, agenda, it is security, • Access application: SNMP, telnet, secure shell, Web, console( serial port) • Authentication ; Password, community string, Kerberos, user-based security Remote Access Dial-In User Service (RADIUS) • Privilege level: Super user, Read-only, and User • Permitted views: Specific objects and sources

32. Access Applications • Limited or no logging apart from that provided by the NE or CLI • Fairly open access to sensitive NE data • It may be error-prone, and help facilities may be quite limited

33. Some popular access applications are: • SNMP • Telnet • Secure Shell • Web

34. Authentication: Privilege Level • Read-only • User-level • Superuser • Read-only access allow only MIB get; user-level allows gets and some sets; superusers can get and set all appropriate

35. Permitted Views • Access control list • Permitted object views • An access control list contain the source IP addresses allowed to connect to an NE. Permitted object views specify a subset of MIB object accessible to a given NMS user

36. Discovery Server exist to keep up with the detail of the deployed NE’s Discovery keep track of: • Nodes • Interface and underlying stacks • Links • Virtual connection • Cross connections between different technologies • Routing protocols • Routing Tables • Signaling protocols • ICMP • SNMP • Standard and proprietary signaling protocols

37. NE Software Distribution • FTP/TFTP • Proprietary download mechanisms • Using an NMS

38. Distributing NE in step: • Preparing the NE for a new firmware load • Rerouting traffic around any nodes to which downloads are pending • Initiating the transfer • Handling rollback if the transfer fails • Verifying the transfer succeeded • Starting up the new NE software

39. Preparing the NE may involve • Bring the NE into a quiescent state • Closing down existing connections • Ensuring that no resource are in use on the NE • Determining the available FLASH and RAM free space • Taking a copy of the existing firmware

40. NE Configuration Database Backup and Restore • Some reason for backing up • New firmware build may upgrade the configuration, making rollback difficult • Disaster recovery • Creating Mirror network • Using a given configuration as a template

41. NMS should handle the complexities of: • Knowing where the appropriate configuration data flies are located • Handling the transfer via FTP, TFTP, and so on • Restart the NE’s or reloading the data files • Informing the operator when the operation is complete • Rerouting traffic around the nodes being restored

42. Middleware • Middleware is the part of an NMs that allow communication between the clients and servers, There is a broad range of software technology choices for achieving this, including RPC,JAVA,COBRA, J2EE, and Microsoft.Net

43. SUMMARY • The implementation of NMS software can take the form of sever .These are high perform software objects that can support interaction with both external clients and NEs, It is essential that server are resilient and designed so that they are unlikely to fail except in exceptional circumstances. They form the intermediate layer through which end users can securely communicate with NE’s.

44. The need for generic software components is growing with the increasing deployment of dense, multiservice NE’s Generic software attempts to abstract complex NE data as much as possible and present simple GUIs applicable across a broad range of devices. • On the client side, GUI views are often depicted as network topologies accompanied by fault listings, It is a major challenge for the NMS software to keep these views synchronized with the network. It is always hard to escape form legacy NE’s, and for this reason it is often necessary for server components to be SNMP multilingual, that is able to use any of SNMPv1/2c/3.