SNMPv1 (cont’d) & SNMPv2 (II) * * Mani Subramanian “Network Management: Principles and practice”, Addison-Wesley, 2000.

SNMP Network Management  SNMP Protocol Specs  SNMP Operations  GetRequest-PDU  GetNextRequest-PDU  SetRequest-PDU  GetResponse-PDU  Trap-PDU  Polling Frequency and limitations of SNMP v1  SNMPv2

Communication Model

 Communicate mgnt information between network mgnt stations and managed elements  Goals: o Management functions maintained by agents are kept simple o Protocol flexibility (addition of new aspects of operation and management) o Transparency (should not be affected by the architecture of particular hosts and gateways)  Operation: 5 messages o get-request, get-next request, set-request o get-response, trap  SNMP messages are exchanged using UDP (connection less) transport protocol

Communication Model SNMP Manager Application Get-Response Get-Request GetNext-Request Set-Request Trap SNMP Manager UDP IP DLC PHY SNMP Agent Application Get-Response Trap SNMP Agent SNMP agent UDP IP DLC PHY Physical Medium Manage- ment Data Get-Request GetNext-Request Set-Request Network or Internet Application Manages objects SNMP messages

Message Format  Protocol entities support application entities  Communication between remote peer processes Message consists of : o Version identifier o Community name  Protocol Data Unit  Message encapsulated in UDP datagrams and transmitted  Loss of message  time out! versioncommunitydata r Like FTP, SNMP uses two well- known ports to operate: m UDP Port SNMP Messages m UDP Port SNMP Trap Messages m Size of SNMP message: 1472 bytes

3 different versions: SNMPv1, SNMPv2, SNMPv3 Message Format  SNMP message format is defined using ASN.1, encoded for transmission over UDP using BER Message ::= SEQUENCE { version INTEGER {version-1(0)}, community OCTET STRING, data PDUs } versioncommunitydata

Message Format-Set/Get PDU versioncommunitydata Message ::= SEQUENCE { version INTEGER {version-1(0)}, community OCTET STRING, data PDUs } PDUs::= CHOICE { get-request [0] IMPLICIT PDU, get-next-request [1] IMPLICIT PDU, get-response [2] IMPLICIT PDU, set-request [3] IMPLICIT PDU, trap [4] IMPLICIT Trap-PDU }

Message Format-Set/Get PDU request- id error- status variable-bindings error- index PDU- type PDU ::= SEQUENCE { request-id INTEGER, error-status INTEGER { noError (0), tooBig (1), noSuchName(2), badValue (3), readOnly (4), genErr (5) }, error-index INTEGER, variable-bindings VarBindList } request-id : track a message and indicate loss of a message (e.g., timeout, etc.) error-status : indicate the occurrence of error error-index : indicate the occurrence of error (position in the list of variables) variable-bindings : grouping of number of operations in a single message: e.g., one request to get all values and one response listing all values

Message Format-variable bindings namevalue var-bind 1 namevalue var-bind 2 namevalue var-bind n... VarBindList ::= SEQUENCE OF VarBind VarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } ObjectName ::= OBJECT IDENTIFIER ObjectSyntax ::= CHOICE { simple SimpleSyntax, application-wide ApplicationSyntax }

Message Format-variable bindings SimpleSyntax ::= CHOICE { number INTEGER, string OCTET STRING, object OBJECT IDENTIFIER, empty NULL } ApplicationSyntax::= CHOICE { address NetworkAddress, counter Counter, gauge Gauge, ticks TimeTicks, arbitrary Opaque } NetworkAddress::= CHOICE { internet IpAddress }

Message Format-Trap PDU Trap-PDU ::= SEQUENCE { enterprise OBJECT IDENTIFIER, agent-addr NetworkAddress, generic-trap INTEGER { coldStart (0), warmStart (1), linkDown (2), linkUp (3), authenticationFailure(4), egpNeighborLoss (5), enterpriseSpecific (6) }, specific-trap INTEGER, time-stamp TimeTicks, variable-bindings VarBindList } Entreprise Agent Address variable-bindings Generic Trap Type PDU- type Specific Trap Type Time Stamp -Pertain to the system generating the trap ( sysObjectID ) -IP address of the objetc Elapsed time since last re-initialization Specific code to identify the trap cause…

SNMP Network Management  SNMP Protocol Specs  SNMP Operations  GetRequest-PDU  GetNextRequest-PDU  SetRequest-PDU  GetResponse-PDU  Trap-PDU  Polling Frequency and limitations of SNMP v1  SNMPv2

SNMP Operations An SNMP entity performs the following to transmit a PDU  Construct a PDU using ASN.1  Pass PDU to Authentication Service (AS) along with s-d transport addresses and community name oAS returns a PDU that is encrypted (if encryption is supported)  The Protocol entity then constructs an SNMP message by adding the version field and the community name to the PDU  Message is encoded using BER and it is passed to the transport service An SNMP entity performs the following upon reception of an SNMP message  Basic syntax check, message is discarded in case of error  Verifies the version number-- message discarded if there is mismatch oAuthentication (if supported): if message does not authenticate, generate trap and discard message.  Finally, using the community name, the access policy is selected and PDU is processed

GetRequest PDU  Sender includes the following fields:  PDU Type  request-id  Variable-bindings  A list of object instances whose values are requested  SNMP dictates that a scalar object is identified by its OBJECT-IDENTIFIER concatenated with 0  e.g., sysDescr.0 : distinguishes between the object type and an instance of the object sysServices (7) sysLocation (6) sysDescr (1) system (mib-2 1) sysObjectId (2) sysUpTime (3)sysName (5) sysContact (4)

GetRequest PDU GetRequest (sysDescr.0)GetResponse (sysDescr.0= "SunOS" )GetRequest (sysObjectID.0)GetResponse ( sysObjectID.0=enterprises )GetRequest (sysUpTime.0) GetResponse (sysUpTime.0= ) GetRequest (sysContact.0) GetResponse (sysContact.0=" ") GetRequest (sysName.0) GetResponse (sysName.0="noc1 ") GetRequest (sysLocation.0) GetResponse (sysLocation.0=" ") GetRequest (sysServices.0) GetResponse (sysServices.0=72) Manager Process Agent Process.0 indicates that the scalar value should be retrieved (scalar objects only) The manager could have used only one message to obtain the values of all objects under system group: using “variable binding list”

GetRequest PDU  Get Request is atomic  Either all values (of all variables provided in the binding list) retrieved or none  error message is generated if at least one of the variables could not be found/returned; error-status :  noSuchName  tooBig  genErr  error-index: indicate the problem object (i.e., variable in binding list that caused the problem)  With SNMP, only leaf objects in the MIB can be retrieved  e.g. it is not possible to retrieve an entire row of a table by simply accessing the Entry Object (e.g., ipRouteEntry)   the management stations has to include each object instance (in the row) in the binding list oBy including the complete object identifier and respecting the rule of indexing!

GetRequest PDU  GetRequest (ipRouteDest , ipRouteMetric , ipRouteNextHop ) ipRouteDest ipRouteMetric1 ipRouteNextHop Index of table

GetNextRequest PDU  PDU format:  same as GetReqest  Difference:  each variable in the binding list refers to an object instance next in the lexicographic order  GetNextRequest (sysDescr.0)  return the value of the object instance of sysObjectId  Advantages:  Allows a network manager to discover a MIB structure dynamically  Efficient way for searching through tables whose entries are unknown sysServices (7) sysLocation (6) sysDescr (1) system (mib-2 1) sysObjectId (2) sysUpTime (3)sysName (5) sysContact (4)

Error message: no object next to sysServices GetNextRequest PDU GetRequest (sysDescr.0)GetResponse (sysDescr.0= "SunOS" ) GetNextRequest (sysDescr.0) GetResponse ( sysObjectID.0=enterprises ) Get-Next-Request Operation for System Group Manager Process Agent Process GetNextRequest (sysObjectID.0) GetResponse (sysUpTime.0= ) GetNextRequest (sysUpTime.0) GetResponse (sysContact.0=" ") GetNextRequest (sysContact.0) GetResponse (sysName.0="noc1 ") GetNextRequest (sysName.0) GetResponse (sysLocation.0=" ") GetNextRequest (sysLocation.0) GetResponse (sysServices.0=72) GetNextRequest (sysServices.0) GetResponse (noSuchName)

Generalized Case TZAB 1.1 E  A sample MIB that contains both scalar values and aggregate objects  Retrieving scalar as well aggregate objects using get- request and get-next-request

Generalized Case T.E.1.1T.E.2.1T.E.3.1 T.E.1.2T.E.2.2T.E.3.2 E T Z A B GetRequest ( A ) GetResponse ( A ) GetRequest ( B ) GetResponse ( B ) GetRequest (T.E.1.1) GetResponse ( T.E.1.1 ) GetRequest (T.E.1.2) GetResponse ( T.E.1.2 ) GetRequest (T.E.2.1) GetResponse ( T.E.2.1 ) GetRequest (T.E.2.2) GetResponse ( T.E.2.2 ) GetRequest (T.E.3.1 ) GetResponse ( T.E.3.1 ) GetRequest (T.E.3.2 ) GetResponse ( T.E.3.2 ) GetRequest (Z ) GetResponse ( Z ) Manager Process Agent Process

Generalized Case T.E.1.1T.E.2.1T.E.3.1 T.E.1.2T.E.2.2T.E.3.2 E T Z A B Observations: 1)- we need to know all the elements in the MIB, including the # of columns and rows in a table 2)- a MIB is traversed from top to bottom (i.e., from left to right in the tree structure) 3)- data in tables is retrieved by traversing all instances of a columnar object NOTES: 1)- dynamic table: # rows may not be known to manager  A request to T.E.1.3 results in error message 3)- GetNextRequest could avoid this! 4)- A convention is required for the definition of the next object in a MIB  SNMP uses lexicographic convention

Lexicographic Convention Procedure for ordering  Start with leftmost digit as first position  Before increasing the order in the first position, select the lowest digit in the second position  Continue the process till the lowest digit in the last position is captured  Increase the order in the last position until all the digits in the last position are captured  Move back to the last but one position and repeat the process  Continue advancing to the first position until all the numbers are ordered  Tree structure for the above process

Lexicographic Ordring- example startend MIB example of lexicographic ordering

T.E.1.1 is next object to scalar B GetNextRequest PDU T.E.1.1T.E.2.1T.E.3.1 T.E.1.2T.E.2.2T.E.3.2 E T Z A B GetRequest ( A ) GetResponse ( A ) GetNextRequest ( A ) GetResponse ( B ) GetNextRequest ( B ) GetResponse ( T.E.1.1 ) GetNextRequest (T.E.1.1 ) GetResponse ( T.E.1.2 ) GetNextRequest (T.E.1.2 ) GetResponse ( T.E.2.1 ) GetNextRequest (T.E.2.1 ) GetResponse ( T.E.2.2 ) GetNextRequest (T.E.2.2 ) GetResponse ( T.E.3.1 ) GetNextRequest (T.E.3.1 ) GetResponse ( T.E.3.2 ) GetNextRequest (T.E.3.2 ) GetResponse ( Z ) GetNextRequest ( Z ) GetResponse ( noSuchName ) Manager Process Agent Process

GetNextRequest PDU GetRequest ( A ) GetResponse ( A ) GetNextRequest ( A ) GetResponse ( B ) GetNextRequest ( B ) GetResponse ( T.E.1.1 ) GetNextRequest (T.E.1.1 ) GetResponse ( T.E.1.2 ) GetNextRequest (T.E.1.2 ) GetResponse ( T.E.2.1 ) GetNextRequest (T.E.2.1 ) GetResponse ( T.E.2.2 ) GetNextRequest (T.E.2.2 ) GetResponse ( T.E.3.1 ) GetNextRequest (T.E.3.1 ) GetResponse ( T.E.3.2 ) GetNextRequest (T.E.3.2 ) GetResponse ( Z ) GetNextRequest ( Z ) GetResponse ( noSuchName ) Manager Process Agent Process Advantages of Get-Next- Request 1)- no need to know the object ID of the next entity to retrieve its value 2)- issues with dynamic table resolved 3)- allows NMS to discover the structure of a MIB view dynamically 4)- provides an efficient mechanism for searching a table whose entries are unknown

Lexicographic Ordring- example ipRouteDest ipRouteMetric1 ipRouteNextHop ipRouteTable ipRouteEntry = x ipRouteDest x.1 ipRouteMetric1 x.3 ipRouteNextHop x.7 ipRouteDest x ipRouteDest x ipRouteDest x ipRouteMetric x ipRouteMetric x ipRouteMetric x ipRouteNextHop x ipRouteNextHop x ipRouteNextHop x Index of table

Accessing Table Values Retrieving the entire table w/out knowing its contents or number of rows: GetNextRequest (ipRouteDest, ipRouteMetric1, ipRouteNextHop)  The agent will respond with the values from the first row GetResponse ((ipRouteDest = ), (ipRouteMetric = 3), (ipRouteNextHop = ))  The MS stores this info and retrieves the second row ipRouteDest ipRouteMetric1 ipRouteNextHop

Accessing Table Values GetNextRequest (ipRouteDest , ipRouteMetric , ipRouteNextHop ) GetResponse ((ipRouteDest = ), (ipRouteMetric = 5), (ipRouteNextHop = )) GetNextRequest (ipRouteDest , ipRouteMetric , ipRouteNextHop ) GetResponse ((ipRouteDest = ), (ipRouteMetric = 5), (ipRouteNextHop = )) ipRouteDest ipRouteMetric1 ipRouteNextHop

Accessing Table Values What happens next!, When does the MS stop? GetNextRequest (ipRouteDest , ipRouteMetric , ipRouteNextHop ) GetResponse ((ipRouteMetric = 3), (ipRouteNextHop = ), (ipNetToMediaIfIndex.1.3 = 1)) ipRouteDest ipRouteMetric1 ipRouteNextHop Object names in the list in the response does not match those in the request  MS knows it has reached the end of the table

SetRequest-PDU  Write a value rather than reading a variable  The operation is atomic: o either all variables in binding list are updated or none Procedure receive-SetRequest: begin if object not available for set then issue getresponse (noSuchName, index) else if inconsistent object value then issue getresponse (badValue, index) else if generated PDU too big then issue getresponse (tooBig) else if value not settable for some other reason then issue getresponse (genErr, index) else issue getresponse (variable bindings) end;

SetRequest-PDU-example Updating the value of ipRouteMetric1 metric of the first row: SetRequest (ipRouteMetric = 9) GetResponse (ipRouteMetric = 9) Adding a row to the table -- a MS issues a command: SetRequest ((ipRouteDest = ), (ipRouteMetric = 9), (ipRouteNextHop = )) ipRouteDest ipRouteMetric1 ipRouteNextHop Index of the new object instance in the table But this is currently unknown for the agent!

Three ways for the agent to handle the request: 1)- reject the operation with error-status = noSuchName 2)- recognize the operation (as creation of a new row) and check whether the operation can be accepted (i.e., all values are correct, no syntax error, etc..) 2.1)- if NO, then return error-status = badValue 2.2)- if YES, then new row is created and GetResponse ((ipRouteDest = ), (ipRouteMetric = 9), (ipRouteNextHop = )) If only this argument is passed, then the agent may accept or not; if it accepts to create the row, then the other objects are assigned default values SetRequest-PDU-example Adding a row to the table -- a MS issues a command: SetRequest ((ipRouteDest = ), (ipRouteMetric = 9), (ipRouteNextHop = ))

SetRequest-PDU-example Row Deletion: SetRequest (ipRouteMetric = invalid) GetResponse (ipRouteMetric = invalid) Some other tables may/may not allow any operation to be done on its columnar objects – check RFCs for more details Performing an action: SNMP can read and set values of objects. SNMP can also issue commands to perform certain actions: example, a device may have a flag “reBoot”, if it is set by the manager, then the device will reboot.

SNMP Group snmp (mib-2 11) snmpInPkts(1) snmpOutPkts (2) snmpInBadVersions (3) snmpInCommunityNames (4) snmpInBadCommunityUses (5) snmpInASNParseErrors (6) -- not used (7) snmpInTooBigs (8) snmpInNoSuchNames (9) snmpInBadValues (10) snmpInReadOnlys (11) snmpEnableAuthenTraps (30) snmpOutTraps (29) snmpOutGetResponses (28) snmpOutSetRequests (27) snmpOutGetNexts (26) snmpOutGetRequests (25) snmpOutGenErrs (24) -- not used (23) snmpOutBadValues (22) snmpOutNoSuchNames (21) snmpOutTooBigs (20) snmpInGenErrs (12) snmpInTotalReqVars (13) snmpInTotalSetVars (14) snmpInGetRequests (15) snmpInTraps (19) snmpInGetResponses (18) snmpInSetRequests (17) snmpInGetNexts (16)

SNMP Network Management  SNMP Protocol Specs  SNMP Operations  GetRequest-PDU  GetNextRequest-PDU  SetRequest-PDU  GetResponse-PDU  Trap-PDU  Polling Frequency and limitations of SNMP v1  SNMPv2

 Few traps exist in the standard! o Thus most of the management information is gathered by means of polls (GetRequest, GetNextRequest)  If polling is done un-frequently o A MS may have outdated view of the network (e.g., congestion might happen and the NM may not be alerted)  If polling is done frequently o The control messages overhead will be high and degrade the performance  Polling frequency requires some policy definition o e.g., size of the network (i.e., #agents a MS can handle) Polling Frequency

 Assumption: assume the MS can handle only one agent at a time (i.e., when polling an agent, a MS does no other work until it is done)  A poll may involve a single get/response transaction or multiple such transactions  The maximum number of agents a MS can handle, considering that it is engaged full time in polling is: N  (T/  ) N: number of agents T: desired polling interval  : average time required to perform a single poll Polling Frequency T  Agent 1 Agent 2 Agent 1 Agent N

 depends on multiple factors: o Processing time to generate a request at the MS o Network delay from MS to agent o Processing time at the agent to interpret the received message o Processing time at the agent to generate response o Network delay from agent to manager o Processing time at the manager to interpret the message o Number of request/response transactions to obtain all desired info. Example o Devices on a LAN; each device is to be polled every 15 minutes o Processing times = 50ms; o Network delay = 1ms (no network congestion) N  (15  60/  ) = 4,500 Where  = = 202 ms Polling Frequency

 In WAN, network delays are significantly large (order of 0.5s) o Data rates on WANs are less than LANs o Distances are greater (delays are higher, e.g. 0.5 seconds) o Delays introduced by bridges and routers N  (15  60/  ) = 750 Where  = (4  0.05) + (2  0.5)  Summary: 4 critical parameters o # agents o Processing time of a message o Network delays o Polling interval Polling Frequency

 SNMP may not be suitable for the mgmt of truly large networks because of the performance limitations of polling  SNMP is not well suited for retrieving large volumes of data, such as an entire routing table  SNMP traps are unacknowledged & may not be delivered  SNMP provides only trivial authentication o i.e. it is suitable for monitoring rather than control  SNMP does not support explicit actions o i.e., an action is taken by changing a parameter or setting an object value (indirectly)  SNMP does not support manager-to-manager communications r Many of these problems are addressed in SNMPv2! Some Limitations of SNMPv1

SNMP Network Management  SNMP Protocol Specs  SNMP Operations  GetRequest-PDU  GetNextRequest-PDU  SetRequest-PDU  GetResponse-PDU  Trap-PDU  Polling Frequency and limitations of SNMP v1  SNMPv2

 Bulk data transfer  Request and receive bulk data using the get-bulk message  Manager-to-manager message  Enhances interoperability and allows for managing large distributed networks  Enhancements to SMI: SMIv2  Module definitions: MODULE-IDENTITY macro  Object definitions: OBJECT-TYPE macro (same as before)  Trap definitions: NOTIFICATION-TYPE macro  Textual conventions: define new data types  Conformance statements  Help customers compare features of various products  Keeps vendors open to their product’s compatibility with SNMP Major Changes

 Row creation and deletion in table  A table can also be expanded by augmenting another table  MIB enhancements  Two new subgroups: security and snmpV2  Transport mappings  UDP remains the preferred transport protocol; however, other protocols can also be used with SNMPv2  Security features, originally to be in SNMPv2 moved to SNMPv3  SNMPv2 is community-based administrative framework Major Changes SNMPv2 mgmt (2) directory (1) experimental (3) private (4) Internet { } security (5) snmpv2 (6) SNMPv2 Internet Group

SNMPv2 System Architecture

 inform-request  manager-to-manager message  The receiving manager responds with a response message  Enhances interoperability  get-bulk-request  transfer of large data, e.g. retrieval of table data  Report  not used  SNMPv2-trap  Similar to trap messages in SNMPv1 Additional Messages

SMIv2- Modules Definitions  Defines and describe semantics of an information module (info. related to network management)  added to provide administrative information regarding the informational module and the revision history  MODULE-IDENTITY macro defines the module definitions

SMIv2- Object Definitions r OBJECT IDENTIFIER, OBJECT-IDENTITY, OBJECT-TYPE m OBJECT IDENTIFIER defines the administrative identification of a node in the MIB m OBJECT-IDENTITY macro (defines info. about OID) assigns an object identifier to a class of managed objects in the MIB (e.g., defining a class of routers!) The object itself is not managed m OBJECT-TYPE macro defines the type of a managed object (e.g., a specific router type) Focuses on the details of implementation m NOTE: OBJECT-IDENTITY is high level description OBJECT-TYPE details description needed for implementation

Object Definitions, example NOTE: A specific instance of routerIsi123 could be identified by its IP address

Table Definition  Static Tables o Tables completely controlled by the agent. Access is read-only, and read-write o These are useful when the number of rows corresponds to a fixed attribute (e.g., # physical interfaces) or a quantity controlled only by agent  Dynamic Table o Allows row creation/deletion by a manager o Access includes also read, write and create privileges o A table can be initialized with no rows and expanded as needed  SNMPv2: Augmentation of a table (dependent table) o Adds additional columns to an existing table (base table) o Number of rows is not affected o INDEX of the second table is the same as the first table o One to one correspondence between rows of two tables

Augmentation of Tables T1.E1.C1.1 table1 (T1) table1Entry (E1) T1.E1.C2.1T1.E1.C3.1 T1.E1.C1.2 T1.E1.C2.2T1.E1.C3.2 T1.E1.C1.3 T1.E1.C2.3T1.E1.C3.3 T1.E1.C1.4 T1.E1.C2.4T.E1.C3.4 table 2 (T2) table2Entry (E2) T2.E2.C4.1T2.E2.C5.1 T2.E2.C4.2T2.E2.C5.2 T2.E2.C4.3T2.E2.C5.3 T2.E2.C4.4T2.E2.C5.4 Index: First columnar object in Table 1 Conceptual rows: 1. T1.E1.C T1.E1.C T1.E1.C T1.E1.C1.4 Table 1 Table 2 Base tableAugmented table Example Columnar object:T2.E2.C4 Index: T1.E1.C1.2 Value: T2.E2.C4.2

Augmentation of Tables --Conceptual row extension A clause used to increase the number of columns in a table w/out rewriting the table definition  The resulting table is therefore treated the same way as if it was defined in a single table definition Example: a vendor can easily specify vendor-specific objects as extensions to standard MIB table. It should be easier for applications to access these objects than if they were defined as new, separate table

Row Creation  A new feature in SMIv2  2 methods  Create a row and make it active (or available)  Create a row and make it available at a later time   definition of the status of a row Used by manager for row creation/deletion Used by agent to send responses to a manager

Row Creation 2 states for RowStatus: createAndGo, createAndWait Row to be created/deleted entry1 status.1 table1 index.1data.1 status.2 status.3 index.2 index.3 data.2 data.3

Create and Go  Manager initiates a SetRequest-PDU to create a new row  status = 4, i.e., create and go  Agent interacts with the management entity and successfully create an instance; subsequently a response is transmitted to the manager  status = 1, indicates that the row is active SetRequest ( status.3 = 4, index.3 = 3, data.3 = DefData ) Response ( status.3 = 1, index.3 = 3, data.3 = DefData ) Manager Process Agent Process Managed Entity Create Instance Instance Created

Create and Wait Manager Process Agent Process SetRequest ( status.3 = 5, index.3 = 3 ) Create and wait, no default data specified Response ( status.3 = 3, index.3 = 3 ) Agent responds with “notReady” (no default value) GetRequest ( data.3 ) Get the data for the row Response ( data.3 = noSuchInstance) Data value is missing SetRequest ( data.3 = DefData ) Value of data is sent Response ( status.3 = 2 data.3 = DefData ) Agent responds with notInServcie SetRequest ( status.3 = 1 ) Manager requests to activate the row Response ( status.3 = 1 ) Row activated

Row Deletion SetRequest ( status.3 = 6 ) Response ( status.3 = 6 ) Manager Process Agent Process Managed Entity Delete Instance Instance Deleted

Textual Conventions r Enables defining new data types r Makes semantics of data types consistent and human readable r Creates new data types using existing ones and applies restrictions to them r An important textual convention in SNMPv2, RowStatus creates and deletes rows SNMPv1 SNMPv2 A string of up to 255 characters (refer to table 6.2 for more rules)

Textual Conventions-Macro TEXTUAL-CONVENTION MACRO ::= BEGIN TYPE NOTATION ::= DisplayPart "STATUS" Status "DESCRIPTION" Text ReferPart "SYNTAX" Syntax VALUE NOTATION ::= value(VALUE Syntax) DisplayPart ::= "DISPLAY-HINT" Text | empty Status ::= "current" | "deprecated" | "obsolete“ ReferPart ::= "REFERENCE" Text | empty ……………………….. END Example: Hundredths ::= TEXTUAL-CONVENTION DISPLAY-HINT “d-2”... SYNTAX INTEGER ( ) suggests that a Hundredths value of 1234 be rendered as "12.34"

Textual Conventions- example RowStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The RowStatus textual convention is used to manage the …” SYNTAX INTEGER { -- the following two values are states: -- these values may be read or written active(1), notInService(2), -- the following value is a state: -- this value may be read, but not written notReady(3), -- the following three values are -- actions: these values may be written, -- but are never read createAndGo(4), createAndWait(5), destroy(6) }

SNMPv2 Protocol  Overall, 8 messages with almost common message format to improve the efficiency and performance  Significant improvement is that trap message has the same format SNMPv2 PDU PDU Type RequestID Error Status Error Index VarBind 1 name VarBind 1 value... VarBind n name VarBind n value Indicate the type of PDU (e.g., Request-PDY, etc) Indicate the status of the error (e.g., noError, tooBig, etc.) identifies the first variable binding in the variable-binding list that caused the error NOTE: SNMPv1 operations (e.g., GET-REQUEST) are atomic: either all values are returned or none! In SNMPv2: a binding list (with corresponding values) is prepared even if one variable cannot be returned  an (error-status), (error-index) are returned in the case of anomaly.

SNMPv2 Protocol Error index is set to “0” if there is no error; otherwise, it identifies the first variable binding in the variable binding list that caused the error

SNMPv2 Protocol  GetBulkRequest enables the retrieval of data in bulk  Uses the same selection principle as GetNexRequest (i.e., next object instance)  Retrieval of multiple rows of data from table (constrained by the max. message size)  Error status field replaced by Non-repeaters  Non-repeaters indicates the number of non repetitive (scalar) field values requested  Error index field replaced by Max repetitions  Max repetitions designates the maximum number of table rows requested to be returned in the response message  NOTE 1: value depends on the size of the SNMP message and buffer size in implementation  NOTE 2: no one to one relationship between the VarBindList of request and response messages SNMPv2 GetBulkRequest PDU PDU Type RequestID Non- Repeaters Max Repetitions VarBind 1 name VarBind 1 value... VarBind n name VarBind n value

GetBulkRequest-PDU Operation TZAB 1.1 E T.E.1.1T.E.2.1T.E.3.1 T.E.1.2T.E.2.2T.E.3.2 E T Z A B T.E.1.3T.E.2.3T.E.3.3 T.E.1.4T.E.2.4T.E.3.4

GetBulkRequest-PDU Operation GetRequest ( A,B ) GetNextRequest (T.E.1,T.E.2,T.E.3) GetResponse (T.E.1.1,T.E.2.1,T.E.3.1) GetNextRequest (T.E.1.1,T.E.2.1,T.E.3.1) GetResponse (T.E.1.2,T.E.2.2,T.E.3.2) GetResponse (T.E.1.3,T.E.2.3,T.E.3.3) GetNextRequest (T.E.1.3,T.E.2.3,T.E.3.3) GetResponse (T.E.1.4,T.E.2.4,T.E.3.4) GetResponse (T.E.2.1,T.E.3.1,Z) Manager Process Agent Process GetResponse (A,B) GetNextRequest (T.E.1.4,T.E.2.4,T.E.3.4) GetNextRequest (T.E.1.2,T.E.2.2,T.E.3.2)

GetBulkRequest-PDU Operation T.E.1.1T.E.2.1T.E.3.1 T.E.1.2T.E.2.2T.E.3.2 E T Z A B T.E.1.3T.E.2.3T.E.3.3 T.E.1.4T.E.2.4T.E.3.4 GetBulkRequest ( 2,3, A,B,T.E.1, T.E.2, T.E.3 ) Response ( A, B, T.E.1.1, T.E.2.1, T.E.3.1 T.E.1.2, T.E.2.2, T.E.3.2 T.E.1.3, T.E.2.3, T.E.3.3 ) GetBulkRequest ( 0,3, T.E.1.3, T.E.2.3, T.E.3.3 ) Response ( T.E.1.4, T.E.2.4, T.E.3.4, Z, "endOfMibView") Manager Process Agent Process 2 non repetitive objects (A, B) 3 repetitive instances Of the columnar object T.E.1, T.E.2, T.E.3 3 more rows Z is next in the lexicographic order

GetBulkRequest-PDU Operation

SNMPv2 Trap PDU  Addition of NOTIFICATION-TYPE macro  Positions 1 and 2 in VarBindList are sysUpTime and snmpTrapOID  Inform-Request behaves as trap in that the message goes from one manager to another unsolicited o The receiving manager sends response to the sending manager PDU Type RequestID Error Status Error Index VarBind1 sysUpTime VarBind1 value VarBind2 snmpTrapOID VarBind 2 value...

SNMPv2- Decentralized management MIB SNMPv2 agent MIB SNMPv2 agent MIB SNMPv2 agent MIB SNMPv2 Manager/agent MIB SNMPv2 Manager/agent MIB Management Applications SNMPv2 manager Management server Element manager Agent SNMPv2 Configuration

Compatibility with SNMPv1  SNMPv2 MIB is not backward compatible with SNMPv1  Compatibility with SNMPv1  2 evolution paths: o Bilingual Manager o Proxy Server  Bilingual Manager expensive in resource and operation SNMPv1 Agents Bilingual Manager SNMPv1 Interpreter SNMPv2 Interpreter Agent Profile SNMPv2 Agents SNMP Bilingual Manager Both interpreters are required!

SNMP Proxy Server SNMPv1 Agents SNMPv2 Manager Proxy Server SNMPv2 Agents Pass-Through SNMPv2 ManagerSNMPv1 Agent GetNextRequest GetRequest Pass-Through SetRequest Set: 1. non-repeaters = 0 2. max-repetitions = 0 GetBulkRequest Pass-Through Exception: For 'tooBig' error, contents of variable-bindings field removed. Response Prepend VarBind: 1. sysUpTime.0 2. snmpTrapOID.0 SNMPv2-Trap GetRequest GetResponse GetNextRequest SetRequest GetNextRequest Trap SNMP v2-v1 Proxy Server