Application Layer Protocol and functionality

WHAT IS LDAP
LDAP IS LIGHT WEIGHT SUFFICIENT STRAIGHT FORWARD EASY TO IMPLEMENT AS AGAINST X.500 DAP WHICH IS HEAVY WEIGHT

LDAP
DIRECTORY BECAUSE DATA IS ORGANISED IN THE FORM OF TREE MUCH LIKE UNIX FILE SYSTEM USES SIMPLIFIED SET OF ENCODING RUNS DIRECTLY ABOVE TCP/IP USES STRING TO REPRESENT DATA

LDAP
LDAP SECURITY MODEL : DEFINES HOW INFORMATION CAN BE PROTECTED FROM UNAUTHORISED ACCESS

LDAP
LDAP API THERE ARE SEVERAL LDAP API APPLICATION PROGRAMMING INTERFACE OLDEST ONES WRITTEN IN C NOW A DAYS LDAP API S ARE AVAILABLE IN OTHER PROGRAMMING LANGUAGES LIKE PERL JAVA

HOW LDAP WORKS

LDAP DIRECTORY SERVICE IS BASED ON CLIENT SERVER MODEL LDAP IS A MESSAGE ORIENTED PROTOCOL CLIENT CONSTRUCTS AN LDAP MESSAGE CONTAINING A REQUEST AND SENDS IT TO THE SERVER

HOW LDAP WORKS

SERVER PROCESSES THE REQUEST AND SENDS IT BACK TO THE CLIENT IN THE FORM OF LDAP MESSAGE

LDAP BACKENDS
THE BASIC DAEMON PROCESS THAT RUNS ON THE LDAP SERVER CALLED SLAPD COMES WITH THREE DIFFERENT BACKEND DATABASES WE ASSUME THAT IN OUR CASE WE USE LDBM THE MOST USED ONE

HOW LDAP WORKS

LDAP DATABASE WORKS BY ADDING A COMPACT FOUR BYTE UNIQUE IDENTIFIER INDEX FILES ARE MAINTAINED FOR REFERRING TO DATA

LDAP PROTOCOL OPERATION

INTERROGATION OPERATION : SEARCH , COMPARE ADD DELETE OPERATOIN : ADD , DELETE , MODIFY , MODIFY DN AUTHENTICATION AND CONTROL OPERATION : BIND , UNBIND , ABANDON

LDAP INFORMATION MODEL

BASIC UNIT IS ENTRY ( A COLLECTION OF INFORMATION ABOUT AN OBJECT ) AN ENTRY IS COMPOSED OF A SET OF ATTRIIBUTES

Definition of MIME
MIME, stand for Multi-purpose Internet mail
Extensions, is a freely available specification that offers a way to interchange text in languages with different character sets, and multimedia e-mail among many different computer system that use Internet mail standards.

Introduction
MIME extends the format of Internet mail to allow nonUS-ASCII textual messages, non-textual messages, multipart message bodies, and non-US-ASCII information in message headers. MIME provides Internet mail users with functionality similar to that of MS-Mail for LAN-based internal mail. MS-Mail and MIME allow the attachment of files and other objects, as does MIME. Unfortunately, Microsofts method of handling these attachments is undertaken through a proprietary format and MS-Mail does not provide compliance with the MIME open standard.

Cont
Internet messages with MIME attachments send to MSMail will transfer the appropriate text portions of the message, but MS-Mail will generally forward the attachments as encoded text, which may then be saved to a file and decoded. Conversely, messages sent from MS-Mail with attachments to an Internet MIME mail system will transfer the text portions and send the attachments as encoding text, but use a different method of encoding from the used by MIME and without the information needed for processing the message attachment by the recipient. Email messages arriving at the National Library with MIME attachments are likely to be corrupted.

What exactly is MIME?

In 1992, a new standard was defined by an Internet engineering task force working group in RFC1521 & 1522 called MIME. MIME is an extension to the Internet mail standard, known as Simple Mail Transfer Protocol (SMTP) that allows mail messages containing different type of multimedia information to be sent across the network this includes, but is not limited to, word-processor documents, spreadsheets, programs, graphics, audio, and motion picture files, as well as links that enable users to retrieve information from remote databases from within a mail message.

Cont
MIME is a specification for enhancing the capabilities of standard Internet e-mail. It offers a simple standardized way to represent and encode a wide variety of media types of transmission via Internet mail. It is defines extensions to SMTP to support binary attachments of arbitrary format. The designers of MIME have learned a lot from the old SMTP protocol and its mailers. MIME is here to stay and it works.

Cont
When using the MIME standard, messages can contain the following types: Text message in US-ASCII Character set other than US-ASCII Multiple objects in a single messages Multimedia; Image, Audio, and Video messages Multi-front messages Messages of unlimited length Binary files

Cont
MIME is defined to be completely backwards compatible, yet flexible and open to extensions. Therefore, it builds on the older standard by defining additional fields for the mail message header, that describes new content types, and a distinct organization of the message body.

How MIME works?

The developers of MIME found a clever way to work around the limitation. It packages different data types into a 7-bit ASCII format. that way, all e-mail, regardless of the data it contains, appears as standard e-mail messages to the internets SMTP servers. The beauty of the solution lies in the fact that SMTP didnt have to change to handle such data.

Cont
Uses a new binary encoding scheme called BASE 64 New SMTP headers describe the attached document User agents read the header to figure out how to interpret the message

MIME Specific technical definition

New MIME headers The Content-type headers The Application-type headers The Content-transfer-Encoding The Content-ID &Content Description Multipart Message Non-ASCII text in mail messages

The Content-type Header

Content-type sub-type describes what format this part of the message is in Text Image Message Audio Application Video Multipart

The default type is simple ASCII text MIME-Version : 1.0 Content-type:text/plain;charset=US-ascii

The Content-type Applications

Subtypes: Postscript Octet-Stream-Unidentified binary data Many other will be added

The Content-transfer-Encoding
Base64 encoding algorithm is used to encode binary data in 7bit ASCII data Quoted-printable is for text-only messages A few others 7bit No encoding Case insensitive 8bit No encoding Binary No encoding X-token No encoding Example

Summary
MIME has been designed to avoid problems caused by additional restrictions imposed by some Internet mail transport mechanisms. The Multipart and Message content types allow mixing and hierarchical structuring of objects of different types in a single message. Further content types provide a mechanism for tagging messages or body parts as audio, image, or other kinds of data. Finally, a number of useful content types are defined for general use by consenting user agents, notably Text/Richtext, Message/Partial, and Message/External-Body.

POP
POP supports simple download-and-delete requirements for access to remote mailboxes (termed maildrop in the POP RFC's). Although most POP clients have an option to leave mail on server after download, e-mail clients using POP generally connect, retrieve all messages, store them on the user's PC as new messages, delete them from the server, and then disconnect. POP (POP1) is specified in RFC 918 (1984), POP2 by RFC 937 (1985). The original specification of POP3 is RFC 1081 (1988). Its current specification is RFC 1939, updated with an extension mechanism, RFC 2449 and an authentication mechanism in RFC 1734.

POP
Usually, mailboxes are kept on a dedicated machine. Computer with mailboxes runs POP server. User runs POP client on local computer. POP client can access and retrieve messages from mailbox. Requires authentication (password). Local computer uses SMTP for outgoing mail.

27

POP

28

POP and Dialup Access

POP useful for dialup connection.
Users computer not always connected. Can download all mail at once and read off-line.

An alternative to POP: IMAP (Interactive Mail Access Protocol):

Does not copy email to users PC - email always resides in the mail server. Useful when user uses several computers.

30

POP3
Stands for Post Office Protocol Version 3 RFC in 1993 POP3 is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. Usually, this means that the POP3 protocol is used to allow a workstation to retrieve mail that the server is holding for it.

POP3
Doesnt provide extensive mail operations on the server Normally mail is downloaded, then deleted Deletion doesnt really occur until QUIT Uses port 110

Minimal POP3 Commands

USER name users name PASS string users password QUIT quits, and updates the mailbox STAT status LIST [msg] lists the mail messages (#s only) RETR msg retrieves a mail message DELE msg deletes a message NOOP No operation RSET resets the mail to its original state

RMON
What is RMON?

RMON is the common abbreviation for Remote Monitoring, a system defined by the IETF that allows you to monitor the traffic of LANs or VLANs remotely.
RMON (Remote Network Monitoring) provides standard information that a network administrator can use to monitor, analyze, and troubleshoot a group of local area networks (LANs) from central location. Remote Monitoring (RMON) is an extension to the SNMP MIB, and includes two versions RMON and RMON 2. MIB - A Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network-management protocol such as SNMP. They are comprised of managed objects and are identified by object identifiers.

Goals of RMON
RMON, primary goal is to provide information relating to network errors and utilization. RMON data is gathered as part of ten different monitoring groups.

RMON
Offline Operation: There are sometimes conditions when a management station will not be in constant contact with its remote monitoring devices. Probes will perform diagnostics and to collect statistics continuously, even when communication with the management station may not be possible or efficient Proactive Monitoring : Continuously run diagnostics and log network performance and notify the management station of the failure and store historical statistical information about the failure.

RMON
Problem Detection and Reporting : The monitor can be configured to recognize conditions, most notably error conditions, and to continuously check for them. When one of these conditions occurs, the event may be logged, and management stations may be notified in a number of ways. Value Added Data : Highlighting those hosts on the network that generate the most traffic or errors, the probe can give the management station precisely the information it needs to solve a class of problems.

Version of RMON
RMON was originally developed to address the problem of managing LAN segments and remote sites from a Central Location. There are two versions of RMON, RMON 1 & RMON 2: RMON1It defines 10 MIB groups for basic monitoring. It allows network monitoring at MAC layer or below RMON1 was only capable of providing information up to the MAC level, RMON2This is an extension of RMON 1 that focuses on higher layers of traffic above the MAC layer It has an emphasis on IP traffic and application level traffic It allows network management applications to monitor packets on all network layers. RMON 2 is capable of monitoring traffic up to the application level.

Working of RMON
Working of the RMON Setup: FDDI Backbone network with a local Ethernet LAN, two remote LANS, one is a token ring LAN and the other an FDDI Lan. NMS is on the the local Ethernet LAN Monitoring Ethernet Local LAN is monitored by the Ethernet probe on the LAN. The FDDI backbone is monitored by an FDDI probe via the bridge and Ethernet LAN. Token Rink is monitored by the token ring probe The FDDI LAN is monitored by the built in probe on the router. Both the remote LANs communicate with the NMS via the routers, the WAN and the backbone network, Working RMON devices monitors the local network segment & does the necessary analyses and informs the NMS only when there are exceptions or NMS requests for some info. This reduces the traffic especially on the segment in which the NMS resides, as all the monitoring traffic would otherwise converge there. Alarm Group Set thresholds on a variety of items affecting network performance When the thresholds are crossed, events are reported. In general, the values of thresholds are determined according to past experience

Advantages of RMON
It improves your efficiency -Using RMON probes allows you to remain at one workstation and collect information from widely dispersed LAN segments or VLANs. This means that the time taken to reach a problem site, set up equipment, and begin collecting information is largely eliminated. It allows you to manage your network in a more proactive manner- If they are configured correctly, RMON probes deliver information before problems occur. This means that you can take action before they affect users. It reduces the load on the network and the management workstation Traditional network management involves a management workstation polling network devices at regular intervals to gather statistics and identify problems or trends. As network sizes and traffic levels grow, this approach places a strain on the management workstation and also generates large amounts of traffic. An RMON probe, however, autonomously looks at the network on behalf of the management workstation without affecting the characteristics and performance of the network. The probe reports by exception, which means that it only informs the management workstation when the network has entered an abnormal state. Increases Productivity for administrators. Permits monitoring on a more frequent basis and hence faster fault diagnosis. Needs no direct visibility by NMS; more reliable information

Disadvantages of RMON
The amount of information it provides is insufficient for network managers and administrators who need to solve complex problems, often at a distance. The mechanism employed for data retrieval to a central management console are slow and very bandwidth inefficient. RMON values are stored in 32 bit registers which limit the count value to 4,294,967,295. Although a seemingly large value, this is actually quite small. In a 100 Mbps fast Ethernet network running at just 10% loading, the counters will be reset to zero after just one hour of acitivity. Full RMON support in hardware typically requires dedicated RISC processor technology and this is achievable in sub -$1,000 routers, hubs etc.

SNTP-Simple Network Time Protocol

Simple Network Time Protocol (SNTP) is a timemaintenance application that you can use to synchronize hardware in a network. Simple Network Time Protocol (SNTP) is used to keep device clocks synchronized. By using timestamps that are kept synchronized, SNTP is useful for tracking processes and for interactions between systems. i5/OS SNTP is based on Request for Comments (RFC) 2030. You can view RFC 2030 by searching for the number with the RFC index search engine located on the RFC editor Web site.

SNTP Client
When Simple Network Time Protocol (SNTP) is configured as a client, the i5/OS operating system retrieves a time value from an external time source. You can specify from which sources (up to three) to retrieve the time value. This external time value is compared to the system time. If the system time value does not match the external time source, a time adjustment begins. The system time is adjusted until the required time value is reached. You can configure the i5/OS operating system as the SNTP client to poll a Network Time Protocol (NTP) or an SNTP server to find the time. The SNTP client updates the system clock. Most applications use the system clock as their time source. By updating the system clock, applications reflect the synchronized time obtained from the time server.

SNTP Server
When you configure the i5/OS operating system as an SNTP server, your system acts as a time server for other devices. Other SNTP clients check time by polling your SNTP server. If a clients time values do not match the SNTP server time, a time adjustment begins. The clients system time is adjusted until the required time value is reached. This is useful for maintaining time within a network.

What is Network Management?

Basic tasks that fall under this category are:
Configuration Management
Keeping track of device settings and how they function

Fault Management
Dealing with problems and emergencies in the network (router stops routing, server loses power, etc.)

Performance Management
How smoothly is the network running? Can it handle the workload it currently has?

Network Management must be...

The management interface must be...
Standardized Extendible Portable The management mechanism must be... Inexpensive Implemented as software only

Functional Areas of Network Management

Configuration Management - inventory, configuration, provisioning Fault Management - reactive and proactive network fault management Performance Management - # of packets dropped, timeouts, collisions, CRC errors Security Management - SNMP doesnt provide much here Accounting Management - cost management and chargeback assessment Asset Management - statistics of equipment, facility, and administration personnel

Planning Management - analysis of trends to help justify a network upgrade or

bandwidth increase

SNMP & Network Management History

1983 - TCP/IP replaces ARPANET at U.S. Dept. of Defense, effective birth of Internet First model for net management - HEMS - High-Level Entity Management System (RFCs 1021,1022,1024,1076) 1987 - ISO OSI proposes CMIP - Common Management Information Protocol, and CMOT (CMIP over TCP) for the actual network management protocol for use on the internet Nov. 1987 - SGMP - Simple Gateway Monitoring protocol (RFC 1028) 1989 - Marshall T. Rose heads up SNMP working group to create a common network management framework to be used by both SGMP and CMOT to allow for transition to CMOT Aug. 1989 - Internet-standard Network Management Framework defined (RFCs 1065, 1066, 1067) Apr. 1989 - SNMP promoted to recommended status as the de facto TCP/IP network management framework (RFC 1098) June 1989 - IAB committee decides to let SNMP and CMOT develop separately May 1990 - IAB promotes SNMP to a standard protocol with a recommended status (RFC 1157) Mar. 1991 - format of MIBs and traps defined (RFCs 1212, 1215) TCP/IP MIB definition revised to create SNMPv1 (RFC 1213)

Versions
Two major versions SNMPv1, SNMPv2
SNMPv1 is the recommended standard SNMPv2 has become split into:
SNMPv2u - SNMPv2 with user-based security
SNMPv2* - SNMPv2 with user-based security and additional features SNMPv2c - SNMPv2 without security

What is SNMP?
SNMP is a tool (protocol) that allows for remote and local management of items on the network including servers, workstations, routers, switches and other managed devices. Comprised of agents and managers
Agent - process running on each managed node collecting information about the device it is running on. Manager - process running on a management workstation that requests information about devices on the network.

Advantages of using SNMP

Standardized universally supported extendible portable allows distributed management access lightweight protocol

Client Pull & Server Push

SNMP is a client pull model
The management system (client) pulls data from the agent (server).

SNMP is a server push model

The agent (server) pushes out a trap message to a (client) management system

Ports & UDP

SNMP uses User Datagram Protocol (UDP) as the transport mechanism for SNMP messages

Ethernet Frame

IP Packet
UDP Datagram

SNMP Message

CRC

Like FTP, SNMP uses two well-known ports to operate:

UDP Port 161 - SNMP Messages

UDP Port 162 - SNMP Trap Messages

The Three Parts of SNMP

SNMP network management is based on three parts:
SNMP Protocol
Defines format of messages exchanged by management systems and agents. Specifies the Get, GetNext, Set, and Trap operations

Structure of Management Information (SMI)

Rules specifying the format used to define objects managed on the network that the SNMP protocol accesses

Management Information Base (MIB)

A map of the hierarchical order of all managed objects and how they are accessed

Nodes
Items in an SNMP Network are called nodes. There are different types of nodes. Managed nodes
Typically runs an agent process that services requests from a management node

Management nodes
Typically a workstation running some network management & monitoring software

Nodes that are not manageable by SNMP

A node may not support SNMP, but may be manageable by SNMP through a proxy agent running on another machine

Nodes can be both managed nodes and a management node at the same time (typically this
is the case, since you want to be able to manage the workstation that your management application is running on.)

Community Names
Community names are used to define where an SNMP message is destined for. They mirror the same concept as a Windows NT or Unix domain. Set up your agents to belong to certain communities. Set up your management applications to monitor and receive traps from certain community names.

SNMP Agents
Two basic designs of agents
Extendible Agents

Open, modular design allows for adaptations to new management data and operational requirements
Monolithic Agents

not extendible optimized for specific hardware platform and OS

this optimization results in less overhead (memory and system resources) and quicker execution

Proxy & Gateway Agents

Proxy & Gateway Agents extend the capabilities of SNMP by allowing it to:
Manage a device that cannot support an SNMP agent Manage a device that supports a non-SNMP management agent Allow a non-SNMP management system to access an SNMP agent Provide firewall-type security to other SNMP agents (UDP packet filtering) Translate between different formats of SNMP messages (v1 and v2) Consolidate multiple managed nodes into a single network address (also to provide a single trap destination)

Four Basic Operations

Get Retrieves the value of a MIB variable stored on the agent machine
(integer, string, or address of another MIB variable)

GetNext Retrieves the next value of the next lexical MIB variable Set Changes the value of a MIB variable Trap An unsolicited notification sent by an agent to a management application
(typically a notification of something unexpected, like an error)

Traps
Traps are unrequested event reports that are sent to a management system by an SNMP agent process

When a trappable event occurs, a trap message is generated by the agent and is sent to a trap destination (a specific, configured network address)
Many events can be configured to signal a trap, like a network cable fault, failing NIC or Hard Drive, a General Protection Fault, or a power supply failure Traps can also be throttled -- You can limit the number of traps sent per second from the agent Traps have a priority associated with them -- Critical, Major, Minor, Warning, Marginal, Informational, Normal, Unknown

Trap Receivers
Traps are received by a management application. Management applications can handle the trap in a few ways:

Poll the agent that sent the trap for more information about the event, and the status of the rest of the machine. Log the reception of the trap.

Completely ignore the trap.

Management applications can be set up to send off an e-mail, call a voice mail and leave a message, or send an alpha-numeric page to the network administrators pager that says:

Your PDC just Blue-Screened at 03:46AM. Have a nice day. :)

Languages of SNMP
Structure of Management Information (SMI) specifies the format used for defining managed objects that are accessed via the SNMP protocol Abstract Syntax Notation One (ASN.1) used to define the format of SNMP messages and managed objects (MIB modules) using an unambiguous data description format Basic Encoding Rules (BER) used to encode the SNMP messages into a format suitable for transmission across a network

SMIv1
Structure of Management Information SMIv1 is described in RFCs 1155, 1212, 1215 These RFCs describe: How MIB modules are defined with CCITT X.208 ASN.1 data description language The subset of the ASN.1 language that is used in MIBs

The addition of the APPLICATION data type to ASN.1, specifically for use with SNMP MIBs
All ASN.1 constructs are serialized using the CCITT X.209 BER for transmission across the wire definition of the high-level structure of the Internet branch (iso(1).org(3).dod(6).internet(1)) of the MIB naming tree the definition and description of an SNMP managed object

SMIv2
Structure of Management Information SMIv2 is described in RFCs 1442, 1443, 1444 These RFCs describe:

SMIv2 is a backward compatible update to SMIv1

The only exception is the Counter64 type defined by SMIv2 Counter64 cannot be created in SMIv2 RFC 2089 defines how bilingual (SMIv1 & SMIv2) agents handle the Counter64 data type IETF requires that new and revised RFCs specify MIB modules using SMIv2

ASN.1
Abstract Syntax Notation One ASN.1 is nothing more than a language definition. It is similar to C/C++ and other programming languages. Syntax examples:
-- two dashes is a comment -- The C equivalent is written in the comment MostSevereAlarm ::= INTEGER -- typedef MostSevereAlarm int;

circuitAlarms MostSevereAlarm ::= 3 -- MostSevereAlarm circuitAlarms = 3; MostSevereAlarm ::= INTEGER (1..5) -- specify a valid range ErrorCounts ::= SEQUENCE { circuitID OCTET STRING, INTEGER,

erroredSeconds

unavailableSeconds INTEGER } -- data structures are defined using the SEQUENCE keyword

BER
Basic Encoding Rules

The relationship between ASN.1 and BER parallels that of source code and machine code.

CCITT X.209 specifies the Basic Encoding Rules

All SNMP messages are converted / serialized from ASN.1 notation into smaller, binary data (BER)

SNMP Data Types

INTEGER -- signed 32-bit integer OCTET STRING OBJECT IDENTIFIER (OID) NULL -- not actually data type, but data value IpAddress -- OCTET STRING of size 4, in network byte order (B.E.) Counter -- unsigned 32-bit integer (rolls over) Gauge -- unsigned 32-bit integer (will top out and stay there) TimeTicks -- unsigned 32-bit integer (rolls over after 497 days)
Yellow items defined by ASN.1 Orange items defined by RFC 1155

Opaque -- used to create new data types not in SNMPv1

DateAndTime, DisplayString, MacAddress, PhysAddress, TimeInterval, TimeStamp, TruthValue, VariablePointer -- textual conventions used as types

Managed Objects & MIBs

Always defined and referenced within the context of a MIB A typical MIB variable definition: sysContact OBJECT-TYPE SYNTAX ACCESS STATUS DESCRIPTION -- OBJECT-TYPE is a macro

DisplayString (SIZE (0..255)) read-write mandatory -- or read-write, write-only, not-accessible -- or optional, deprecated, obsolete

Chris Francois
cfrancois@acm.org (360)650-0000 ::= { system 4 }

Basic Message Format

Message Length Message Version Community String PDU Header

Message Preamble

PDU Body

SNMP Protocol Data Unit

SNMP Message Formats

Message Length
Message Version Community String PDU Type PDU Length Request ID Error Status Error Index Length of Variable Bindings Length of First Binding OID of First Binding Type of First Binding Value of First Binding Length of Second Binding OID of Second Binding Type of Second Binding Value of Second Binding
SNMP Message Preamble

Message Length Message Version Community String PDU Type PDU Length Enterprises MIB OID Agent IP Address Standard Trap Type Specific Trap Type
Time Stamp

PDU Header

Length of Variable Bindings Length of First Binding OID of First Binding Type of First Binding Value of First Binding

PDU Body

Length of Second Binding

OID of Second Binding Type of Second Binding Value of Second Binding Additional Variable Bindings

Additional Variable Bindings

Commercial SNMP Applications

Here are some of the various SNMP Management products available today:
http://www.hp.com/go/openview/ http://www.tivoli.com/ http://www.novell.com/products/managewise/ http://www.sun.com/solstice/ http://www.microsoft.com/smsmgmt/ HP OpenView IBM NetView Novell ManageWise Sun MicroSystems Solstice Microsoft SMS Server

http://www.compaq.com/products/servers/management/ Compaq Insight Manger http://www.redpt.com/ http://www.empiretech.com/ ftp://ftp.cinco.com/users/cinco/demo/ http://www.netinst.com/html/snmp.html http://www.netinst.com/html/Observer.html Observer Gordians SNMP Agent Castle Rock Computing Advent Network Management SimpleAgent, SimpleTester SnmpQL - ODBC Compliant Empire Technologies Cinco Networks NetXray SNMP Collector (Win9X/NT)

http://www.gordian.com/products_technologies/snmp.html http://www.castlerock.com/ http://www.adventnet.com/ http://www.smplsft.com/

SNMP & Windows NT 5.0

Proposed features of the Windows NT5 SNMP Service

Full bilingual support for SNMPv1 and SNMPv2c ability to map SNMPv2c requests to SNMPv1 for processing by extension agents better synchronization of MIB variables a new extension agent framework (backward compatible with original
framework, but with MS add-ons)

code-generator for creation of extension agents

MIB-II, LAN Manager 2, IP Forwarding MIB (RFC 1354), and Host Resources MIB (RFC 1514) extension agents included All MIB modules included with SNMP install SMS 2.0 also has a Symantec PCAnywhere type of application integrated into it, allowing remote-but-local management as well

RFC Description

Published Current Status

Aug-88 Aug-88 Aug-88 Apr-89 May-90 May-90 May-90 May-90 Mar-91 Mar-91 Mar-91 Jul-92 Jul-92 Jul-92 Apr-93 Apr-93 Apr-93 Apr-93 Apr-93 Apr-93 Apr-93 Apr-93 Apr-93 Apr-93 Apr-93 Apr-93 Jan-96 Jan-96 Jan-96 Jan-96 Jan-96 Jan-96 Jan-96 Jan-96 Feb-96 Feb-96 Obsoleted by 1155 Obsoleted by 1156 Obsoleted by 1098 Obsoleted by 1157 Standard Historic Standard Obsoleted by 1213 Standard Standard Informational Proposed Standard Proposed Standard Proposed Standard Proposed Standard Obsoleted by 1902 Obsoleted by 1903 Obsoleted by 1904 Historic Historic Historic Obsoleted by 1905 Obsoleted by 1906 Obsoleted by 1907 Historic Obsoleted by 1908 Experimental Draft Standard Draft Standard Draft Standard Draft Standard Draft Standard Draft Standard Draft Standard Experimental Experimental

SNMP

RFCs

1065 1066 1067 1098 1155 1156 1157 1158 1212 1213 1215 1351 1352 1353 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910

SMIv1 SNMPv1 MIB SNMPv1 SNMPv1 SMIv1 SNMPv1 MIB SNMPv1 SNMPv1 MIB-II SNMPv1 MIB definitions SNMPv1 MIB-II SNMPv1 traps Secure SNMP administrative model Secure SNMP managed objects Secure SNMP security protocols Introduction to SNMPv2 SMIv2 Textual conventions for SNMPv2 Conformance statements for SNMPv2 SNMPv2 administrative model SNMPv2 security protocols SNMPv2 party MIB SNMPv2 protocol operations SNMPv2 transport mapping SNMPv2 MIB Manger-to-manger MIB Coexistence of SNMPv1 and SNMPv2 Community-Based SNMPv2 SMIv2 Textual conventions for SNMPv2 Conformance statements for SNMPv2 Protocol operations for SNMPv2 Transport mapping for SNMPv2 SNMPv2 MIB Coexistence of SNMPv1 and SNMPv2 Administrative infrastructure for SNMPv2 User-based security for SNMPv2

Light Weight Presentation Protocol

Lightweight Presentation Protocol (LPP) describes an approach for providing "stream-lined" support of OSI application services on top of TCP/IP-based network for some constrained environments. LPP was initially derived from a requirement to run the ISO Common Management Information Protocol (CMIP) in TCP/IPbased network. LPP is designed for a particular class of OSI applications, namely those entities whose application context contains only an Association Control Service Element (ACSE) and a Remote Operations Service Element (ROSE). In addition, a Directory Services Element (DSE) is assumed for use by the applicationentity, but only in a very limited sense. LPP is not applicable to entities whose application context is more extensive (e.g., contains a Reliable Transfer Service Element).

If one wants to implement ISO applications in a TCP/IP based network without constrains, the ITOT mechanisms (specified in RFC 2126) should be used

Protocol Structure - LPP: Lightweight Presentation Protocol The service provider is in one of the following states: IDLE, WAIT1, WAIT2, DATA, WAIT3, or WAIT4 The possible events are: PS-user P-CONNECT.REQUEST P-CONNECT.RESPONSE P-RELEASE.REQUEST P-RELEASE.RESPONSE P-DATA.REQUEST P-U-ABORT.REQUEST network TCP closed or errored(*) receive ConnectRequest PDU receive ConnectResponse PDU receive ReleaseRequest PDU receive ReleaseResponse PDU receive UserData(*) or CL-UserData(**) (*) tcp-based service only (**) udp-based service only

PDU receive user-initiated Abort PDU receive provider-initiated Abort PDU timer expires(**) The possible actions are: PS-user P-CONNECT.INDICATION P-CONNECT.CONFIRMATION P-RELEASE.INDICATION P-RELEASE.CONFIRMATION P-DATA.INDICATION P-U-ABORT.INDICATION P-P-ABORT.INDICATION network open TCP(*) close TCP(*) send ConnectRequest PDU send ConnectResponse PDU send ReleaseRequest PDU send ReleaseResponse PDU send UserData(*) or CL-UserData(**) PDU send user-initiated Abort PDU send provider-initiated Abort PDU set timer(**)