ASSIGNMENT

Table of Contents
Network management ............................................................................................................................ 2
Technologies ....................................................................................................................................... 2
Management information base .............................................................................................................. 2
Simple Network Management Protocol ................................................................................................. 3
Overview and basic concepts .......................................................................................................... 3
Protocol details................................................................................................................................ 4
Common Object Request Broker Architecture ....................................................................................... 6
COPS (Common Open Policy Service Protocol)....................................................................................... 8
Mobile IP ................................................................................................................................................. 8
Voice over IP ....................................................................................................................................... 9
Robust Header Compression .............................................................................................................. 9

Vasant Vohra
CSE-D
10315210183
Network management
Network management is the process of administering and managing computer networks.
Various services provided by this discipline include fault analysis, performance
management, provisioning of networks, maintaining the quality of service, and so on. Software
that enables network administrators to perform their functions is called network management
software.
Technologies
A small number of accessory methods exist to support network and network device
management. Network management allows individual IT professional to monitor over the
small network components within large network area.(EXTC VCET) Access methods include
the SNMP, command-line interface (CLI), custom XML, CMIP, Windows Management
Instrumentation (WMI), Transaction Language 1 (TL1), CORBA, NETCONF, and the Java
Management Extensions (JMX).
Schemas include the Structure of Management Information (SMI), WBEM, the Common
Information Model (CIM), and MTOSI amongst others

Management information base

A management information base (MIB) is a database used for managing the entities in
a communication network. Most often associated with the Simple Network Management
Protocol (SNMP), the term is also used more generically in contexts such as
in OSI/ISO Network management model. While intended to refer to the complete collection of
management information available on an entity, it is often used to refer to a particular subset,
more correctly referred to as MIB-module.
Objects in the MIB are defined using a subset of Abstract Syntax Notation One (ASN.1) called
"Structure of Management Information Version 2 (SMIv2)" RFC 2578. The software that
performs the parsing is a MIB compiler.
The database is hierarchical (tree-structured) and each entry is addressed through an object
identifier (OID). Internet documentation RFCs discuss MIBs, notably RFC 1155, "Structure
and Identification of Management Information for TCP/IP based internets", and its two
companions, RFC 1213, "Management Information Base for Network Management of
TCP/IP-based internets", and RFC 1157, "A Simple Network Management Protocol"
Simple Network Management Protocol
Simple Network Management Protocol (SNMP) is an Internet Standard protocol for
collecting and organizing information about managed devices on IP networks and for
modifying that information to change device behaviour. Devices that typically support SNMP
include cable modems, routers, switches, servers, workstations, printers, and more.
SNMP is widely used in network management for network monitoring. SNMP exposes
management data in the form of variables on the managed systems organized in a management
information base (MIB) which describe the system status and configuration. These variables
can then be remotely queried (and, in some circumstances, manipulated) by managing
applications.
Three significant versions of SNMP have been developed and deployed. SNMPv1 is the
original version of the protocol. More recent versions, SNMPv2c and SNMPv3, feature
improvements in performance, flexibility and security.
SNMP is a component of the Internet Protocol Suite as defined by the Internet Engineering
Task Force (IETF). It consists of a set of standards for network management, including
an application layer protocol, a database schema, and a set of data objects.
Overview and basic concepts
In typical uses of SNMP, one or more administrative computers called managers have the task
of monitoring or managing a group of hosts or devices on a computer network. Each managed
system executes a software component called an agent which reports information via SNMP
to the manager.
An SNMP-managed network consists of three key components:
Managed devices
Agent – software which runs on managed devices
Network management station (NMS) – software which runs on the manager
A managed device is a network node that implements an SNMP interface that allows
unidirectional (read-only) or bidirectional (read and write) access to node-specific information.
Managed devices exchange node-specific information with the NMSs. Sometimes called
network elements, the managed devices can be any type of device, including, but not limited
to, routers, access servers, switches, cable modems, bridges, hubs, IP telephones, IP video
cameras, computer hosts, and printers.
An agent is a network-management software module that resides on a managed device. An
agent has local knowledge of management information and translates that information to or
from an SNMP-specific form.
A network management station executes applications that monitor and control managed
devices. NMSs provide the bulk of the processing and memory resources required for network
management. One or more NMSs may exist on any managed network.
Protocol details
SNMP operates in the application layer of the Internet protocol suite. All SNMP messages are
transported via User Datagram Protocol (UDP). The SNMP agent receives requests on UDP
port 161. The manager may send requests from any available source port to port 161 in the
agent. The agent response is sent back to the source port on the manager. The manager receives
notifications (Traps and InformRequests) on port 162. The agent may generate notifications
from any available port. When used with Transport Layer Security or Datagram Transport
Layer Security, requests are received on port 10161 and notifications are sent to port 10162.[3]
SNMPv1 specifies five core protocol data units (PDUs). Two other
PDUs, GetBulkRequest and InformRequest were added in SNMPv2 and the Report PDU was
added in SNMPv3. All SNMP PDUs are constructed as follows:

IP UDP PDU- request- error- error- variable

version community
header header type id status index bindings

The seven SNMP PDU types as identified by the PDU-type field are as follows:
GetRequest
A manager-to-agent request to retrieve the value of a variable or list of variables. Desired
variables are specified in variable bindings (the value field is not used). Retrieval of the
specified variable values is to be done as an atomic operation by the agent. A Response with
current values is returned.
SetRequest
A manager-to-agent request to change the value of a variable or list of variables. Variable
bindings are specified in the body of the request. Changes to all specified variables are to be
made as an atomic operation by the agent. A Response with (current) new values for the
variables is returned.
GetNextRequest
A manager-to-agent request to discover available variables and their values. Returns
a Response with variable binding for the lexicographically next variable in the MIB. The entire
MIB of an agent can be walked by iterative application of GetNextRequest starting at OID 0.
Rows of a table can be read by specifying column OIDs in the variable bindings of the request.
GetBulkRequest
A manager-to-agent request for multiple iterations of GetNextRequest. An optimized version
of GetNextRequest. Returns a Response with multiple variable bindings walked from the
variable binding or bindings in the request. PDU specific non-repeaters and max-
repetitions fields are used to control response behavior. GetBulkRequest was introduced in
SNMPv2.
Response
Returns variable bindings and acknowledgement from agent to manager
for GetRequest, SetRequest, GetNextRequest, GetBulkRequest and InformRequest. Error
reporting is provided by error-status and error-index fields. Although it was used as a response
to both gets and sets, this PDU was called GetResponse in SNMPv1.
Trap
Asynchronous notification from agent to manager. While in other SNMP communication, the
manager actively requests information from the agent, these are PDUs that are sent from the
agent to the manager without being explicitly requested. SNMP traps enable an agent to notify
the management station of significant events by way of an unsolicited SNMP message. Trape
PDUs include current sysUpTime value, an OID identifying the type of trap and optional
variable bindings. Destination addressing for traps is determined in an application-specific
manner typically through trap configuration variables in the MIB. The format of the trap
message was changed in SNMPv2 and the PDU was renamed SNMPv2-Trap.
InformRequest
Acknowledged asynchronous notification. This PDU was introduced in SNMPv2 and was
originally defined as manager to manager communication. Later implementations have
loosened the original definition to allow agent to manager communications. Manager-to-
manager notifications were already possible in SNMPv1 (using a Trap), but as SNMP
commonly runs over UDP where delivery is not assured and dropped packets are not reported,
delivery of a Trap was not guaranteed. InformRequest fixes this by sending back an
acknowledgement on receipt.
Common Object Request Broker Architecture
The Common Object Request Broker Architecture (CORBA) is a standard defined by
the Object Management Group (OMG) designed to facilitate the communication of systems
that are deployed on diverse platforms. CORBA enables collaboration between systems on
different operating systems, programming languages, and computing hardware. CORBA uses
an object-oriented model although the systems that use the CORBA do not have to be object-
oriented. CORBA is an example of the distributed object paradigm.
Overview
CORBA enables communication between software written in different languages and running
on different computers. Implementation details from specific operating systems, programming
languages, and hardware platforms are all removed from the responsibility of developers who
use CORBA. CORBA normalizes the method-call semantics between application objects
residing either in the same address-space (application) or in remote address-spaces (same host,
or remote host on a network). Version 1.0 was released in October 1991.
CORBA uses an interface definition language (IDL) to specify the interfaces that objects
present to the outer world. CORBA then specifies a mapping from IDL to a specific
implementation language like C++ or Java. Standard mappings exist
for Ada, C, C++, C++11, COBOL, Java, Lisp, PL/I, Object
Pascal, Python, Ruby and Smalltalk. Non-standard mappings exist
for C#, Erlang, Perl, Tcl and Visual Basic implemented by object request brokers (ORBs)
written for those languages.
The CORBA specification dictates there shall be an ORB through which an application would
interact with other objects. This is how it is implemented in practice:
The application simply initializes the ORB, and accesses an internal Object Adapter, which
maintains things like reference counting, object (and reference) instantiation policies, and
object lifetime policies.
The Object Adapter is used to register instances of the generated code classes. Generated code
classes are the result of compiling the user IDL code, which translates the high-level interface
definition into an OS- and language-specific class base for use by the user application. This
step is necessary in order to enforce CORBA semantics and provide a clean user process for
interfacing with the CORBA infrastructure.
Some IDL mappings are more difficult to use than others. For example, due to the nature of
Java, the IDL-Java mapping is rather straightforward and makes usage of CORBA very simple
in a Java application. This is also true of the IDL to Python mapping. The C++ mapping
requires the programmer to learn datatypes that predate the C++ Standard Template
Library (STL). By contrast, the C++11 mapping is easier to use but requires heavy use of the
STL. Since the C language is not object-oriented, the IDL to C mapping requires a C
programmer to manually emulate object-oriented features.
In order to build a system that uses or implements a CORBA-based distributed object interface,
a developer must either obtain or write the IDL code that defines the object-oriented interface
to the logic the system will use or implement. Typically, an ORB implementation includes a
tool called an IDL compiler that translates the IDL interface into
the target language for use in that part of the system. A
traditional compiler then compiles the generated code to create
the linkable-object files for use in the application. This diagram
illustrates how the generated code is used within the CORBA
infrastructure:

Illustration of the auto generation of the infrastructure code from

an interface defined using the CORBA IDL
This figure illustrates the high-level paradigm for remote inter
process communications using CORBA. The CORBA specification further addresses data
typing, exceptions, network protocols, communication timeouts, etc. For example: Normally
the server side has the Portable Object Adapter (POA) that redirects calls either to the
local servants or (to balance the load) to the other servers. The CORBA specification (and thus
this figure) leaves various aspects of distributed system to the application to define including
object lifetimes (although reference counting semantics are available to applications),
redundancy/fail-over, memory management, dynamic load balancing, and application-oriented
models such as the separation between display/data/control semantics (e.g. see Model–view–
controller), etc.
In addition to providing users with a language and a platform-neutral remote procedure
call (RPC) specification, CORBA defines commonly needed services such as transactions and
security, events, time, and other domain-specific interface models.
COPS (Common Open Policy Service Protocol)

COPS (Common Open Policy Service Protocol) is a proposed standard protocol for
exchanging network policy information between a policy decision point (PDP) in a network
and policy enforcement points (PEPs) as part of overall Quality of Service (QoS) - the
allocation of network traffic resources according to desired priorities of service. The policy
decision point might be a network server controlled directly by the network administrator who
enters policy statements about which kinds of traffic (voice, bulk data, video, teleconferencing,
and so forth) should get the highest priority. The policy enforcement points might be routers
or layer 3 switches that implement the policy choices as traffic moves through the network.
Currently, COPS is designed for use with the Resource Reservation Protocol (RSVP), which
lets you allocate traffic priorities in advance for temporary high-bandwidth requirements (for
example, video broadcasts or multicasts). It is possible that COPS will be extended to be a
general policy communications protocol
In operation, RSVP makes two determinations when an RSVP request arrives at a router
or layer 3 switch. First, it determines whether there are enough resources to satisfy
the bandwidth reservation request. If there are, RSVP determines whether the user is authorized
to make the reservation. The first determination is known as the admission control decision;
the second is known as the policy control decision. COPS allows the router or layer 3 switch
to communicate with the policy decision point about whether the request for the bandwidth
reservation should be permitted. Without COPS, all resources would be reserved on a first
come-first served basis only, and one or more requesters could easily take all the bandwidth.
The current COPS protocol is specified in an Internet-Draft working document of the Internet
Engineering Task Force (IETF).

Mobile IP

The Mobile IP allows for location-independent routing of IP datagrams on the Internet. Each
mobile node is identified by its home address disregarding its current location in the Internet.
While away from its home network, a mobile node is associated with a care-of address which
identifies its current location and its home address is associated with the local endpoint of a
tunnel to its home agent. Mobile IP specifies how a mobile node registers with its home agent
and how the home agent routes datagrams to the mobile node through the tunnel.
Applications
Virtual private network
A virtual private network (VPN) extends a private network across a public network, and
enables users to send and receive data across shared or public networks as if their computing
devices were directly connected to the private network. Applications running across the VPN
may therefore benefit from the functionality, security, and management of the private network
A VPN is created by establishing a virtual point-to-point connection through
the use of dedicated connections, virtual tunneling protocols,
or traffic encryption. A VPN available from the public Internet
can provide some of the benefits of a wide area
network (WAN). From a user perspective, the resources available
within the private network can be accessed remotely.
Voice over IP

Voice over Internet Protocol (also voice over IP, VoIP or IP telephony) is a methodology
and group of technologies for the delivery of voice communications and multimediasessions
over Internet Protocol (IP) networks, such as the Internet. The terms Internet
telephony, broadband telephony, and broadband phone service specifically refer to the
provisioning of communications services (voice, fax, SMS, voice-messaging) over the public
Internet, rather than via the public switched telephone network (PSTN).

Robust Header Compression

Robust Header Compression (ROHC) is a standardized method to compress
the IP, UDP, UDP-Lite, RTP, and TCP headers of Internet packets.
Modes of operation
According to RFC 3095, the ROHC scheme has three modes of operation, as follows:
the Unidirectional mode (U-mode)
the Bidirectional Optimistic mode (O-mode)
the Bidirectional Reliable mode (R-mode)
Both the compressor and the decompressor start in U-mode. They may then transition to O-
mode if a usable return link is available, and the decompressor sends a positive
acknowledgement, with O-mode specified, to the compressor. The transition to R-mode is
achieved in the same way.
Unidirectional Mode (U-Mode)
In the Unidirectional mode of operation, packets are only sent in one direction: from
compressor to decompressor. This mode therefore makes ROHC usable over links where a
return path from decompressor to compressor is unavailable or undesirable. In order to handle
potential decompression errors, the compressor sends periodic refreshes of the stream context
to the decompressor.
Bidirectional Optimistic Mode (O-Mode)
The Bidirectional Optimistic mode is similar to the Unidirectional mode, except that a feedback
channel is used to send error recovery requests and (optionally) acknowledgments of
significant context updates from the decompressor to compressor. The O-mode aims to
maximize compression efficiency and aims for sparse usage of the feedback channel.
Bidirectional Reliable Mode (R-Mode)
The Bidirectional Reliable mode differs in many ways from the previous two modes. The most
important differences are a more intensive usage of the feedback channel, and a stricter logic
at both the compressor and the decompressor that prevents loss of context synchronization
between compressor and decompressor, except for very high residual bit error rates.