CA2345685A1 - Network management information processing - Google Patents
Network management information processing Download PDFInfo
- Publication number
- CA2345685A1 CA2345685A1 CA002345685A CA2345685A CA2345685A1 CA 2345685 A1 CA2345685 A1 CA 2345685A1 CA 002345685 A CA002345685 A CA 002345685A CA 2345685 A CA2345685 A CA 2345685A CA 2345685 A1 CA2345685 A1 CA 2345685A1
- Authority
- CA
- Canada
- Prior art keywords
- rows
- data unit
- protocol data
- read
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
Abstract
A method for supplying data from a table in a device responsive to network management protocol commands includes receiving a Protocol Data Unit (PDU) designated as a table block access request (TBAR), identifying the PDU as a TBAR, obtaining an Object Identifier (OI) of a table to be read from the PDU, obtaining an index to a row to be read from the table from the PDU, determining the number of rows to be read based on information obtained from the PDU, looking up information in the table based on the OI and the index, composing a response PDU containing information read from the table for multiple rows based on the number of rows to be read, and outputting a response packet (RP). Optionally, OIs are only included in the RP if requested, and abbreviated OIs are included in the RP. Network devices implementing the method are also provided.
Description
~~T~10RK MANAO~1T INP'ORD~ATION ~~OOESSING
BACKGROUND OF THE INVENTION
1. Field of the Invention The present inventic>n relates to the processing of information for network management. More particularly, but not exclusively, the present invention relates to the processing of information contained in tables for controlling a network.
BACKGROUND OF THE INVENTION
1. Field of the Invention The present inventic>n relates to the processing of information for network management. More particularly, but not exclusively, the present invention relates to the processing of information contained in tables for controlling a network.
2. State of the Art In a distributed network such as the Internet, it is necessary to store various parameters, including routing information, at distributed points across the network and to extract that information for overall management of the network.
Since different devices in a network may be made by different manufacturers and be of different types, it is desirable for communication of this information to be substantially device independent.
The Simple Network Management Protocol (SNMP) together with associated Management Information Base (MIB) structures have been designed to achieve device-independent management of a network and are widely used across the Internet. Basic details of SNMP may be found in any of a number of texts on the subject, an example of which is The Simple Book (An Introduction to Management of TCP/IP-based internets) by Marshall T. Rose published by Prentice-Hall 1991, the entire disclosure of which is incorporated herein x>y reference.
SUMMARY CiF THE INVENTION
The invention is particularly concerned with the manipulation of data in tables such as a Management Information Base (MIB). Details of the structure of a MIB may be found in chapter 4, pages 91-130 of The Simple Book, referenced above.
Entries within a MIB are associated with Object Identifiers (OIDs) which may be lengthy strings. The invention is particularly concerned with access to tables (such as a MIB) using network management protocols such as the Simple Network Management Protocol (SNM:P), a discussion of which may be found in chapter 5, pages 131-:186, of The Simple Book.
In order to extract information from a table such as a MIB, SNMP defines Protocol Data Units (PDUs) for exchanging messages and commands and provides a "Get" command and a "Get Next"
command which allow information to be retrieved and a table to be traversed effectively. The "Get Next" operator is described on pages 140-142 of the Simple book. Whilst the "Get Next"
operator is a powerful tool for traversing a table, it can be inefficient if blocks of data are to be accessed.
Version 2 of the Sinnple Network Management Protocol provides a "Get Bulk" operator which effectively performs repeated "Get Next" operations. This can lead to significant improvements in efficiency compared to multiple "Get Next" operations. This can result in a significant saving of Protocol Data Units (PDUs) which must be exchanged and also in the total number of bytes which must flow across the network.
However, pursuant to the invention, it has been appreciated that more efficient access to large tables may yet be possible, preferably in a manner n.ot incompatible with existing SNMP
architecture. Studies pursuant to the present invention have revealed that a significant amount of the data transferred may comprise Object Identifiers (OIDs). Pursuant to the invention, it has been appreciated that complete OIDs do not necessarily need to be transmitted i.n every case. It has also been found, pursuant to the invention, that certain operations such as the extraction of a relatively small portion of a relatively large table may be inefficient: even when using the "Get Bulk"
operation.
Since different devices in a network may be made by different manufacturers and be of different types, it is desirable for communication of this information to be substantially device independent.
The Simple Network Management Protocol (SNMP) together with associated Management Information Base (MIB) structures have been designed to achieve device-independent management of a network and are widely used across the Internet. Basic details of SNMP may be found in any of a number of texts on the subject, an example of which is The Simple Book (An Introduction to Management of TCP/IP-based internets) by Marshall T. Rose published by Prentice-Hall 1991, the entire disclosure of which is incorporated herein x>y reference.
SUMMARY CiF THE INVENTION
The invention is particularly concerned with the manipulation of data in tables such as a Management Information Base (MIB). Details of the structure of a MIB may be found in chapter 4, pages 91-130 of The Simple Book, referenced above.
Entries within a MIB are associated with Object Identifiers (OIDs) which may be lengthy strings. The invention is particularly concerned with access to tables (such as a MIB) using network management protocols such as the Simple Network Management Protocol (SNM:P), a discussion of which may be found in chapter 5, pages 131-:186, of The Simple Book.
In order to extract information from a table such as a MIB, SNMP defines Protocol Data Units (PDUs) for exchanging messages and commands and provides a "Get" command and a "Get Next"
command which allow information to be retrieved and a table to be traversed effectively. The "Get Next" operator is described on pages 140-142 of the Simple book. Whilst the "Get Next"
operator is a powerful tool for traversing a table, it can be inefficient if blocks of data are to be accessed.
Version 2 of the Sinnple Network Management Protocol provides a "Get Bulk" operator which effectively performs repeated "Get Next" operations. This can lead to significant improvements in efficiency compared to multiple "Get Next" operations. This can result in a significant saving of Protocol Data Units (PDUs) which must be exchanged and also in the total number of bytes which must flow across the network.
However, pursuant to the invention, it has been appreciated that more efficient access to large tables may yet be possible, preferably in a manner n.ot incompatible with existing SNMP
architecture. Studies pursuant to the present invention have revealed that a significant amount of the data transferred may comprise Object Identifiers (OIDs). Pursuant to the invention, it has been appreciated that complete OIDs do not necessarily need to be transmitted i.n every case. It has also been found, pursuant to the invention, that certain operations such as the extraction of a relatively small portion of a relatively large table may be inefficient: even when using the "Get Bulk"
operation.
It is an aim of the invention to provide methods of extracting data from tab7les which are compatible with existing network management protocol (such as SNMP) interactions, but which may provide improved efficiency.
According to a first aspect, the invention provides a method of supplying data from a table in a device which is responsive to network management protocol, commands preferably Simple Network Management Protocol commands. The method preferably comprises eight steps:
receiving a Protocol Data Unit designated as a table block access request;
identifying the Protocol Data Unit as a table block access request;
obtaining an Object Identifier of a table to be read from the Protocol Data Unit;
obtaining an index t:a a row to be read from the table from the Protocol Data Unit;
determining the numx>er of rows to be read based on information obtained from the Protocol Data Unit;
looking up information in the table based on the Object Identifier and the index to the row to be read;
composing a response Protocol Data Unit containing information read from the table for a plurality of rows based on the number of rows to be read;
outputting the response packet.
By providing an Object Identifier for the table and an index to a row (preferably the start row), lengthy Object Identifiers need not be communicated for every row or every table entry.
Furthermore, the method :may allow immediate access to a given block of rows, for example in the middle of the table, even when the Object Identifiers of those rows are not known.
It will be appreciai~ed that the Simple Network Management Protocol is reviewed and updated from time to time and modifications are proposed. In this specification, which term includes the claims, references to Simple Network Management Protocol includes derivatives and modifications of the protocol current at the time of filing (whether including enhanced, reduced or alternative functionality); indeed, a modified version of the basic protocol incorporating table access as defined herein is intended to be encompassed by the term.
Devices which are respon:~ive to a subset or derivative of SNMP
commands are intended to be encompassed by the invention.
Another advantage is that the Object Identifiers of the rows and objects within the table need not be communicated in the response packet; preferably Object Identifiers are only communicated in the response packet if specifically requested.
Preferably, if Object Identifiers for the rows are requested, a single Object Identifier, preferably abbreviated, is communicated for each rove, It is well-known that Object Identifiers are hierarchical, the Object Identifier of an item within a table comprising the Object Identifier of the table with suffixes dependent on the row and column within the table.
By "abbreviated" is meant sufficient identification information from the suffixes, optionally pre-pended with a further portion of the complete Object Identifier or a dummy prefix, but not including the entire Object Identifier.
Preferably, information representative of the number of rows actually included in the response packet is included in the response packet, at least when the number of rows supplied differs from the number of rows requested. This may facilitate determination by the requestor of the amount of information supplied and composition of a subsequent request for remaining information.
Preferably, the method includes selecting one or more columns from which data :is to be included based on column identifier information within the received Protocol Data Unit.
This may allow data to b~e selectively extracted from multiple columns and multiple rows within a single operation. Most preferably, the column identifier information is in the form of index information. This avoids the need to communicate the Object Identifier to each column, and allows specified columns to be accessed even when the Object Identifiers are not known.
In a second aspect, the invention provides a method, in a network management device which issues and accepts network management protocol, preferably Simple Network Management Protocol, Protocol Data 'Units, of obtaining data from a table in a remote device, preferably arranged to perform a method as defined above. The method preferably comprises six steps:
determining an Objects Identifier of a table in the remote device to be accessed;
determining an index to the start of a block of rows from which data within the table is required;
determining the number of rows to be accessed;
composing a Protocol Data Unit designated as a table block access request and including information representative of on or more of said determining steps;
outputting the Protocol Data Unit to the remote device; and obtaining said data from a response Protocol Data Unit received from the remote device.
Preferably, the method further comprises determining whether the received Protocol Data Unit contains all the information requested and, if not, composing a further request for information.
The method may further comprise supplying the information to a management application.
In a third aspect, the invention provides a network device comprising:
means for respondin<~ to Protocol Data Units received containing network management protocol, preferably Simple Network Management Protocol, commands;
means for identifying a received Protocol Data Unit designated as a table block access request;
means for indexing a portion of a stored table based on an Object Identifier and an index to a row to be read from the table from the Protocol Data Unit;
means for determining the number of rows to be read based on information obtained from the Protocol Data Unit;
means for looking up information in the table based on the Object Identifier and the index to the row to be read; and means for composing a response Protocol Data Unit containing information read from the table for a plurality of rows based on the number of rows to be read.
According to a fouri~h aspect, the invention provides a Protocol Data Unit comprising:
an identifier signifying that the Protocol Data Unit is a table block access request;
an Object Identifier of a table to be accessed;
an index to a row within the table to be accessed; and information identif~Ting the number of rows to be accessed.
The Protocol Data Unit preferably further comprises information identifying the number of columns in the table to be accessed and an identifier for each column.
It will be appreciated that the invention can be applied regardless of the information contained within the table to the access.and provide a technical improvement in terms of more efficient data transfer and simplified access to large tables.
An embodiment of the invention will now be described, by way of example, with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 is a graph i:Llustrating a comparison between the amount of data to be transferred when access a large table according to conventional methods and according to an embodiment of the invention;
Fig. 2 is a graph illustrating a comparison between the amount of Protocol Data Units to be transferred when access a large table according to conventional methods and according to an embodiment of the invE~ntion;
Fig. 3 is a graph illustrating a comparison between the amount of time taken for table retrieval when access a large table according to conventional methods and according to an embodiment of the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
An embodiment for use in an SNMP-compatible network device having a plurality of MIB tables stored therein will now be described. Details of conventional MIB tables and SNMP
commands, together with details of Abstract Syntax Notation One (ASN.1) and Basic Encoding Rules (BER) encoding are assumed to be well-known and will not be described in detail; reference should be made to The Simple Book, together with references 40-53 in the bibliography thereon, or to any of the relevant standards, all of which are incorporated herein by reference.
By way of backgrounds summary information, basic formats of an SNMP message, a generic PDU, a request PDU, a Get PDU and a Get Next PDU will be set out, in ASN.1 syntax.
Firstly, a basic message format:--- top-level message Message :.
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0) ?.
conununity -- community name OCTET STRING, data -- e.g., PDUs if trivial ANY -- authentication is being used l Next, the format of a Protocol Data Unit:--- protocol data units PDUs :.
CHOICE {
get.-request GetRequest-PDU, get:-next-request GetNextRequest-PDU, get:-response GetResponse-PDU, set:-request SetRequest-PDU, trap Trap-PDU
-- the individual PDUs and commonly used -- data types will be defined later END
The basic format of a request PDU will now be set out:--- request/response information RequestID :.
Ir~TTEGER
ErrorStatus :.
INTEGER {
noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4) genErr(5) ErrorIndex: : .
INTEGER
-- variabl.e bindings VarBind SEQUENCE {
name ObjectName, value ObjectSyntax VarBindLis;t :.
SEQUENCE OF
VarBind The format of a standard "Get" PDU is:-GetRequest:-PDU :.
[0]
IMPLICIT SEQUENCE {
request-id RequestID, error-status -- always 0 ErrorStatus, error-index -- always 0 ErrorIndex, variable-bindings VarBindList ]
The format of a "Get Nexl~" PDU is : -GetNextRequest-PDU :.
[1]
IMl?LICIT SEQUENCE {
request-id RequestID, error-status -- always 0 ErrorStatus, error-index -- always 0 ErrorIndex, variable-bindings VarBindList Further details of the components of the entities defined above and other background information may be found by reference to RFC 1157 or other standard texts.
According to this en:~bodiment, we propose a modified PDU
which we designate a Get Table Row message. This is defined below using the ASN.1 syntax:-GetTableRow-PDU :.
SEQUENCE {
request-id INTEGER, error-status INTEGER {
noError(0), tooBi.g(1), noSuchName(2), badValue(3), readOnly ( ~1 ) , genErr(5) ?.
error-index INTEGER, snmpp-version INTEGER {
versi~onl (1) -- First implementation table-name OBJECT-INDRNTIFIER, -- OID of the table being retrieved start-index INTEGER, -- starting row index for retrieval max-rows -- maximum no. of rows to be retrieved INTEGER, -- -1 indicates "get all rows"
table-size INTEGER, -- No. of rows in table instances-included INTEGER {
no(0), -- Row instances not encoded yes(1) -- Row instances are encoded }.
column-total INTEGER, -- No. of columns to be retrieved columns INTEGER, -- column id for first column column2 INTEGER, -- column id for second column columnN
INTEGER, -- column id for Nth column variable-bindings varBindList VarBind :.
SEQUENCE
{
row-instances OBJECT-IDENTIFIER, -- optional instance OID for row value objectSyntax -- value for this row/column entry This command is intended allow a management application to to retrieve a table without having to issue arbitrary rows from repeated GetNext commands to to the correct rows. For get optimum ty, it is found to be highly efficiency and flexibili WO 00/20981 PC'T/US99/22b51 desirable that the command can access arbitrary columns, and not just complete rows.
An explanation of the fields in a GetTableRows request PDU as would be sent from a management application follows:-- request-id The unique request :id for this PDU
- snmpp-version Indicates the revision level of the SNMPP PDU (should always be set to 1).
- table-name The OBJECT IDENTIFIER representing the table to be retrieved. For example, the interfaces table in rfc1213 would 'have a table name of 1.3.6.1.2.1.2.2 - start-index Identifies the first row index to be retrieved from the table. This represents essentially the row number in that table (starting 0). So, to start retrieving from the first row, start-index would be set to 0. To retrieve from the 25th row, start-index would be set to 24, etc.
- max-rows Represents the maximum number of rows to be retrieved (if possible). If all rows from the start-index to end of table are required, this should be set to -1.
- column-total Represents the total number of columns to be retrieved from the table (the column ids are encoded immediately after this object in the PDU).
- column-id A column id is encoded for each of the columns requested. So, for example, if five columns had been requested, then five consecutive INTEGERS would be encoded representing the respective column ids. The id represents the conceptual column number for that table (starting 1). So, for example, consider the ifTable of rfc1213, the column-id for ifOperStatus would be 8, since this is the eighth conceptual column in the table.
The request PDU will contain an empty varbind list (since all the information above is sufficient to identify what we are requesting).
Note: All the other objects exist in the request PDU, but will have their default values set.
To implement this embodiment, the (modified) SNMP
agent of the network device must process an incoming GetTableRows request and package the response message to send back to the requ~estor. The agent should attempt to include all the requested rows into the response PDU, but due to the restrictions of message size, this may not be possible. In these cases, it should send back as many rows as it can, updating the associated fields to identify precisely the rows it. has returned (this is so that the requestor can send another GetTableRows request message amended to retrieve the remaining rows).
A GetTableRows response PDU should be sent to the management application with the following fields set:-- request-id The unique request id for this PDU.
- snmpp-version Indicates the revision level of the SNMPP PDU (should always be set to 1) - table-name The OBJECT IDENTIFIER representing the table to be retrieved. For example, the interfaces table in rfc1213 would have a table name of 1.3.6.1.2.1.2.2.
This must match the request PDU.
- start-index Identifies the first row index to be retrieved from the table. Thi:> represents essentially the row number in that table (:starting 0). So, to start retrieving from the first row, start-index would be set to 0. To retrieve from t:he 25th row, start-index would be set to 24, etc. This must match the request PDU.
- max-rows This will be set to the actual number of rows included in this respon~~e PDU.
- table-size Stores the actual size of the table requested (i.e.
how many rows exist in the table at that point in time).
- instances-included set to no(0) if' the row instances have not been encoded in the varbinds representing the first column requested, otherwise set to yes(1) if they have.
- column-total Represents the total number of columns retrieved from the table (the column ids are encoded immediately after this object in the PDU). This must match the request PDU.
- column-id A column id is encoded for each of the columns requested. So, for example, then five consecutive INTEGERS would be encoded representing the respective column ids. Th.e id represents the conceptual column number for that table (starting 1). So, for example, consider the ifTable of rfc1213, the column-id for ifOperStatus would be 8, since this is the eighth conceptual column in the table. Each of these column-ids must match the request PDU.
- varbind list A list of varbinds must be encoded which represent the data contained in the rows returned. The order of the varbind list is on a per-row basis. So, for example, if five columns had been requested, the first five varbinds would constitute the values for the first row returned, where varbindl represents the data for columnl, varbind2 contains the data for column2 and so on. In most cases, the name of the varbind is not encoded (see t:he later section on varbind encoding).
The SNMPP GetT,ableRows message is encoded with a message type of OxA1~, which corresponds to:-ASN CONTEXT 1 ASN CONSTRUCTOR 1 OXf A variable binding list returned in a GetTableRows response message will contain each of the values within the table encoded as usual varbind objects. The varbind list must always contain enough variables encoded in the varbind list will be multiples of column-total.
The variable banding for each element in a row will be encoded in order of column-ids requested. The object-name of a varbind will only be encoded if the following two criteria are met:-1. The instances-included variable is set to yes(1) 2. The varbi:nd being encoded represents the first column-id of a row.
If the object name is encoded, it will represent the instance oid identii~ying that row (starting with 0.0, because the first two subids must each be encoded in a single octet accord_Lng to SNMP) .
This is best eacplained by example, so consider the ifTable and the TableRows request message has requested two columns, namely ifAdminStatus (1.3.6.1.2.1.2.2.1.7) and ifOperStatus (1.3.5..1.2.1.2.2.1.8).
The column-ids will be encoded as two INTEGERs, namely 7 and 8.
Supposing the response message was returning 3 rows (for ifIndex 1,2 and 3). The varbind list will be encoded as follows:-varbind Object Name Value ( roar-Instance ) 1 0Ø1 up(1) 2 Not Encoded up(1) 3 0Ø2 up(1) 4 Not Encoded down(2) 0Ø3 testing (3) 6 Not Encoded Down(2) The above varbinds would represent the following three rows in the i~Table:-ifladex ~.fA~mia8tatus ifOperstatus 1 up(1) up(1) 2 up(2) down(2) 3 ties t ing ( 3 ) down ( 2 ) The following pseudo-code outlines the basic steps to be performed to imp7_ement the embodiment ( some of which will co-exist with other steps which are part of a conventional SNMP agent) .
- Receive PDU
[Other SNMP procese;ing]
- Check whether PDi:r designated "GetTableRows"
- If not so designated, skip to Continued Processing - If so designated:-- Obtain OID of table to be read from table-name - Obtain index to first row to read from start-index - Obtain number of rows to read from max-rows - Obtain indices to columns to be read columnl..N
- Check whether encoded row ids requested in instances-included - Look up information in specified table using indices - Compose re~~ponse packet including:-* Infox-mation read from table in varbinds * Number of rows actually read in max-rows * Row i_ds if specified in varbinds for first column - Output response packet [Continued Processing]
It will be appreciated that the ordering of information is not critical and can be changed, as can all labels used both for entities with the PDU and the PDU
designation (the label GetTableRows being used here as a suitable label to designate a table block access request).
The information contained in the PDU may be replaced by other combinations of information which achieve the same function (for example, the last row may be supplied in place of the first row, and the indexing performed in reverse). Not all functions need be included.
Each feature described above may be provided independently, unless otherwise stated.
According to a first aspect, the invention provides a method of supplying data from a table in a device which is responsive to network management protocol, commands preferably Simple Network Management Protocol commands. The method preferably comprises eight steps:
receiving a Protocol Data Unit designated as a table block access request;
identifying the Protocol Data Unit as a table block access request;
obtaining an Object Identifier of a table to be read from the Protocol Data Unit;
obtaining an index t:a a row to be read from the table from the Protocol Data Unit;
determining the numx>er of rows to be read based on information obtained from the Protocol Data Unit;
looking up information in the table based on the Object Identifier and the index to the row to be read;
composing a response Protocol Data Unit containing information read from the table for a plurality of rows based on the number of rows to be read;
outputting the response packet.
By providing an Object Identifier for the table and an index to a row (preferably the start row), lengthy Object Identifiers need not be communicated for every row or every table entry.
Furthermore, the method :may allow immediate access to a given block of rows, for example in the middle of the table, even when the Object Identifiers of those rows are not known.
It will be appreciai~ed that the Simple Network Management Protocol is reviewed and updated from time to time and modifications are proposed. In this specification, which term includes the claims, references to Simple Network Management Protocol includes derivatives and modifications of the protocol current at the time of filing (whether including enhanced, reduced or alternative functionality); indeed, a modified version of the basic protocol incorporating table access as defined herein is intended to be encompassed by the term.
Devices which are respon:~ive to a subset or derivative of SNMP
commands are intended to be encompassed by the invention.
Another advantage is that the Object Identifiers of the rows and objects within the table need not be communicated in the response packet; preferably Object Identifiers are only communicated in the response packet if specifically requested.
Preferably, if Object Identifiers for the rows are requested, a single Object Identifier, preferably abbreviated, is communicated for each rove, It is well-known that Object Identifiers are hierarchical, the Object Identifier of an item within a table comprising the Object Identifier of the table with suffixes dependent on the row and column within the table.
By "abbreviated" is meant sufficient identification information from the suffixes, optionally pre-pended with a further portion of the complete Object Identifier or a dummy prefix, but not including the entire Object Identifier.
Preferably, information representative of the number of rows actually included in the response packet is included in the response packet, at least when the number of rows supplied differs from the number of rows requested. This may facilitate determination by the requestor of the amount of information supplied and composition of a subsequent request for remaining information.
Preferably, the method includes selecting one or more columns from which data :is to be included based on column identifier information within the received Protocol Data Unit.
This may allow data to b~e selectively extracted from multiple columns and multiple rows within a single operation. Most preferably, the column identifier information is in the form of index information. This avoids the need to communicate the Object Identifier to each column, and allows specified columns to be accessed even when the Object Identifiers are not known.
In a second aspect, the invention provides a method, in a network management device which issues and accepts network management protocol, preferably Simple Network Management Protocol, Protocol Data 'Units, of obtaining data from a table in a remote device, preferably arranged to perform a method as defined above. The method preferably comprises six steps:
determining an Objects Identifier of a table in the remote device to be accessed;
determining an index to the start of a block of rows from which data within the table is required;
determining the number of rows to be accessed;
composing a Protocol Data Unit designated as a table block access request and including information representative of on or more of said determining steps;
outputting the Protocol Data Unit to the remote device; and obtaining said data from a response Protocol Data Unit received from the remote device.
Preferably, the method further comprises determining whether the received Protocol Data Unit contains all the information requested and, if not, composing a further request for information.
The method may further comprise supplying the information to a management application.
In a third aspect, the invention provides a network device comprising:
means for respondin<~ to Protocol Data Units received containing network management protocol, preferably Simple Network Management Protocol, commands;
means for identifying a received Protocol Data Unit designated as a table block access request;
means for indexing a portion of a stored table based on an Object Identifier and an index to a row to be read from the table from the Protocol Data Unit;
means for determining the number of rows to be read based on information obtained from the Protocol Data Unit;
means for looking up information in the table based on the Object Identifier and the index to the row to be read; and means for composing a response Protocol Data Unit containing information read from the table for a plurality of rows based on the number of rows to be read.
According to a fouri~h aspect, the invention provides a Protocol Data Unit comprising:
an identifier signifying that the Protocol Data Unit is a table block access request;
an Object Identifier of a table to be accessed;
an index to a row within the table to be accessed; and information identif~Ting the number of rows to be accessed.
The Protocol Data Unit preferably further comprises information identifying the number of columns in the table to be accessed and an identifier for each column.
It will be appreciated that the invention can be applied regardless of the information contained within the table to the access.and provide a technical improvement in terms of more efficient data transfer and simplified access to large tables.
An embodiment of the invention will now be described, by way of example, with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 is a graph i:Llustrating a comparison between the amount of data to be transferred when access a large table according to conventional methods and according to an embodiment of the invention;
Fig. 2 is a graph illustrating a comparison between the amount of Protocol Data Units to be transferred when access a large table according to conventional methods and according to an embodiment of the invE~ntion;
Fig. 3 is a graph illustrating a comparison between the amount of time taken for table retrieval when access a large table according to conventional methods and according to an embodiment of the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
An embodiment for use in an SNMP-compatible network device having a plurality of MIB tables stored therein will now be described. Details of conventional MIB tables and SNMP
commands, together with details of Abstract Syntax Notation One (ASN.1) and Basic Encoding Rules (BER) encoding are assumed to be well-known and will not be described in detail; reference should be made to The Simple Book, together with references 40-53 in the bibliography thereon, or to any of the relevant standards, all of which are incorporated herein by reference.
By way of backgrounds summary information, basic formats of an SNMP message, a generic PDU, a request PDU, a Get PDU and a Get Next PDU will be set out, in ASN.1 syntax.
Firstly, a basic message format:--- top-level message Message :.
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0) ?.
conununity -- community name OCTET STRING, data -- e.g., PDUs if trivial ANY -- authentication is being used l Next, the format of a Protocol Data Unit:--- protocol data units PDUs :.
CHOICE {
get.-request GetRequest-PDU, get:-next-request GetNextRequest-PDU, get:-response GetResponse-PDU, set:-request SetRequest-PDU, trap Trap-PDU
-- the individual PDUs and commonly used -- data types will be defined later END
The basic format of a request PDU will now be set out:--- request/response information RequestID :.
Ir~TTEGER
ErrorStatus :.
INTEGER {
noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4) genErr(5) ErrorIndex: : .
INTEGER
-- variabl.e bindings VarBind SEQUENCE {
name ObjectName, value ObjectSyntax VarBindLis;t :.
SEQUENCE OF
VarBind The format of a standard "Get" PDU is:-GetRequest:-PDU :.
[0]
IMPLICIT SEQUENCE {
request-id RequestID, error-status -- always 0 ErrorStatus, error-index -- always 0 ErrorIndex, variable-bindings VarBindList ]
The format of a "Get Nexl~" PDU is : -GetNextRequest-PDU :.
[1]
IMl?LICIT SEQUENCE {
request-id RequestID, error-status -- always 0 ErrorStatus, error-index -- always 0 ErrorIndex, variable-bindings VarBindList Further details of the components of the entities defined above and other background information may be found by reference to RFC 1157 or other standard texts.
According to this en:~bodiment, we propose a modified PDU
which we designate a Get Table Row message. This is defined below using the ASN.1 syntax:-GetTableRow-PDU :.
SEQUENCE {
request-id INTEGER, error-status INTEGER {
noError(0), tooBi.g(1), noSuchName(2), badValue(3), readOnly ( ~1 ) , genErr(5) ?.
error-index INTEGER, snmpp-version INTEGER {
versi~onl (1) -- First implementation table-name OBJECT-INDRNTIFIER, -- OID of the table being retrieved start-index INTEGER, -- starting row index for retrieval max-rows -- maximum no. of rows to be retrieved INTEGER, -- -1 indicates "get all rows"
table-size INTEGER, -- No. of rows in table instances-included INTEGER {
no(0), -- Row instances not encoded yes(1) -- Row instances are encoded }.
column-total INTEGER, -- No. of columns to be retrieved columns INTEGER, -- column id for first column column2 INTEGER, -- column id for second column columnN
INTEGER, -- column id for Nth column variable-bindings varBindList VarBind :.
SEQUENCE
{
row-instances OBJECT-IDENTIFIER, -- optional instance OID for row value objectSyntax -- value for this row/column entry This command is intended allow a management application to to retrieve a table without having to issue arbitrary rows from repeated GetNext commands to to the correct rows. For get optimum ty, it is found to be highly efficiency and flexibili WO 00/20981 PC'T/US99/22b51 desirable that the command can access arbitrary columns, and not just complete rows.
An explanation of the fields in a GetTableRows request PDU as would be sent from a management application follows:-- request-id The unique request :id for this PDU
- snmpp-version Indicates the revision level of the SNMPP PDU (should always be set to 1).
- table-name The OBJECT IDENTIFIER representing the table to be retrieved. For example, the interfaces table in rfc1213 would 'have a table name of 1.3.6.1.2.1.2.2 - start-index Identifies the first row index to be retrieved from the table. This represents essentially the row number in that table (starting 0). So, to start retrieving from the first row, start-index would be set to 0. To retrieve from the 25th row, start-index would be set to 24, etc.
- max-rows Represents the maximum number of rows to be retrieved (if possible). If all rows from the start-index to end of table are required, this should be set to -1.
- column-total Represents the total number of columns to be retrieved from the table (the column ids are encoded immediately after this object in the PDU).
- column-id A column id is encoded for each of the columns requested. So, for example, if five columns had been requested, then five consecutive INTEGERS would be encoded representing the respective column ids. The id represents the conceptual column number for that table (starting 1). So, for example, consider the ifTable of rfc1213, the column-id for ifOperStatus would be 8, since this is the eighth conceptual column in the table.
The request PDU will contain an empty varbind list (since all the information above is sufficient to identify what we are requesting).
Note: All the other objects exist in the request PDU, but will have their default values set.
To implement this embodiment, the (modified) SNMP
agent of the network device must process an incoming GetTableRows request and package the response message to send back to the requ~estor. The agent should attempt to include all the requested rows into the response PDU, but due to the restrictions of message size, this may not be possible. In these cases, it should send back as many rows as it can, updating the associated fields to identify precisely the rows it. has returned (this is so that the requestor can send another GetTableRows request message amended to retrieve the remaining rows).
A GetTableRows response PDU should be sent to the management application with the following fields set:-- request-id The unique request id for this PDU.
- snmpp-version Indicates the revision level of the SNMPP PDU (should always be set to 1) - table-name The OBJECT IDENTIFIER representing the table to be retrieved. For example, the interfaces table in rfc1213 would have a table name of 1.3.6.1.2.1.2.2.
This must match the request PDU.
- start-index Identifies the first row index to be retrieved from the table. Thi:> represents essentially the row number in that table (:starting 0). So, to start retrieving from the first row, start-index would be set to 0. To retrieve from t:he 25th row, start-index would be set to 24, etc. This must match the request PDU.
- max-rows This will be set to the actual number of rows included in this respon~~e PDU.
- table-size Stores the actual size of the table requested (i.e.
how many rows exist in the table at that point in time).
- instances-included set to no(0) if' the row instances have not been encoded in the varbinds representing the first column requested, otherwise set to yes(1) if they have.
- column-total Represents the total number of columns retrieved from the table (the column ids are encoded immediately after this object in the PDU). This must match the request PDU.
- column-id A column id is encoded for each of the columns requested. So, for example, then five consecutive INTEGERS would be encoded representing the respective column ids. Th.e id represents the conceptual column number for that table (starting 1). So, for example, consider the ifTable of rfc1213, the column-id for ifOperStatus would be 8, since this is the eighth conceptual column in the table. Each of these column-ids must match the request PDU.
- varbind list A list of varbinds must be encoded which represent the data contained in the rows returned. The order of the varbind list is on a per-row basis. So, for example, if five columns had been requested, the first five varbinds would constitute the values for the first row returned, where varbindl represents the data for columnl, varbind2 contains the data for column2 and so on. In most cases, the name of the varbind is not encoded (see t:he later section on varbind encoding).
The SNMPP GetT,ableRows message is encoded with a message type of OxA1~, which corresponds to:-ASN CONTEXT 1 ASN CONSTRUCTOR 1 OXf A variable binding list returned in a GetTableRows response message will contain each of the values within the table encoded as usual varbind objects. The varbind list must always contain enough variables encoded in the varbind list will be multiples of column-total.
The variable banding for each element in a row will be encoded in order of column-ids requested. The object-name of a varbind will only be encoded if the following two criteria are met:-1. The instances-included variable is set to yes(1) 2. The varbi:nd being encoded represents the first column-id of a row.
If the object name is encoded, it will represent the instance oid identii~ying that row (starting with 0.0, because the first two subids must each be encoded in a single octet accord_Lng to SNMP) .
This is best eacplained by example, so consider the ifTable and the TableRows request message has requested two columns, namely ifAdminStatus (1.3.6.1.2.1.2.2.1.7) and ifOperStatus (1.3.5..1.2.1.2.2.1.8).
The column-ids will be encoded as two INTEGERs, namely 7 and 8.
Supposing the response message was returning 3 rows (for ifIndex 1,2 and 3). The varbind list will be encoded as follows:-varbind Object Name Value ( roar-Instance ) 1 0Ø1 up(1) 2 Not Encoded up(1) 3 0Ø2 up(1) 4 Not Encoded down(2) 0Ø3 testing (3) 6 Not Encoded Down(2) The above varbinds would represent the following three rows in the i~Table:-ifladex ~.fA~mia8tatus ifOperstatus 1 up(1) up(1) 2 up(2) down(2) 3 ties t ing ( 3 ) down ( 2 ) The following pseudo-code outlines the basic steps to be performed to imp7_ement the embodiment ( some of which will co-exist with other steps which are part of a conventional SNMP agent) .
- Receive PDU
[Other SNMP procese;ing]
- Check whether PDi:r designated "GetTableRows"
- If not so designated, skip to Continued Processing - If so designated:-- Obtain OID of table to be read from table-name - Obtain index to first row to read from start-index - Obtain number of rows to read from max-rows - Obtain indices to columns to be read columnl..N
- Check whether encoded row ids requested in instances-included - Look up information in specified table using indices - Compose re~~ponse packet including:-* Infox-mation read from table in varbinds * Number of rows actually read in max-rows * Row i_ds if specified in varbinds for first column - Output response packet [Continued Processing]
It will be appreciated that the ordering of information is not critical and can be changed, as can all labels used both for entities with the PDU and the PDU
designation (the label GetTableRows being used here as a suitable label to designate a table block access request).
The information contained in the PDU may be replaced by other combinations of information which achieve the same function (for example, the last row may be supplied in place of the first row, and the indexing performed in reverse). Not all functions need be included.
Each feature described above may be provided independently, unless otherwise stated.
Claims (15)
1. A method of supplying data from a table in a device which is responsive to network management protocol commands, the method comprising receiving a Protocol Data Unit designated as a table block access request;
identifying the Protocol Data Unit as a table block access request;
obtaining an Object Identifier of a table to be read from the Protocol Data Unit;
obtaining an index to a row to be read from the table from the Protocol Data Unit;
determining the number of rows to be read based on information obtained from the Protocol Data Unit;
looking up information in the table based on the Object Identifier and the index to the row to be read;
composing a response Protocol Data Unit containing information read from the table for a plurality of rows based on the number of rows to be read;
outputting the response packet.
identifying the Protocol Data Unit as a table block access request;
obtaining an Object Identifier of a table to be read from the Protocol Data Unit;
obtaining an index to a row to be read from the table from the Protocol Data Unit;
determining the number of rows to be read based on information obtained from the Protocol Data Unit;
looking up information in the table based on the Object Identifier and the index to the row to be read;
composing a response Protocol Data Unit containing information read from the table for a plurality of rows based on the number of rows to be read;
outputting the response packet.
2. A method according to Claim 1, wherein Object Identifiers are only included in the response packet if requested.
3. A method according to Claim 1 or Claim 2, wherein if Object Identifiers for the rows are to be included in the response packet, a single Object Identifier is included for each row.
4. A method according to Claim 2 or Claim 3 wherein abbreviated Object Identifiers are included in the response packet.
5. A method according to any preceding claim wherein information representative of the number of rows actually included in the response packet is included in the response packet, at least when the number of rows supplied differs from the number of rows requested.
6. A method according to any preceding claim including selecting one or more columns from which data is to be included based on column identifier information within the received Protocol Data Unit.
7. A method according to Claim 6, wherein the column identifier information is in the form of index information.
8. A method, in a network management device which issues and accepts network management protocol Protocol Data Units, of obtaining data from a table in a remote device, preferably arranged to perform a method according to any preceding claim, this method comprising:
determining:- (a) an Object Identifier of a table in the remote device to be accessed;
(b) an index to the start of a block of rows from which data within the table is required;
(c) the number of rows to be accessed;
composing a Protocol Data Unit designated as a table block access request and including information representative of said determining;
outputting the Protocol Data Unit to the remote device; and obtaining said data from a response Protocol Data Unit received from the remote device.
determining:- (a) an Object Identifier of a table in the remote device to be accessed;
(b) an index to the start of a block of rows from which data within the table is required;
(c) the number of rows to be accessed;
composing a Protocol Data Unit designated as a table block access request and including information representative of said determining;
outputting the Protocol Data Unit to the remote device; and obtaining said data from a response Protocol Data Unit received from the remote device.
9. A method according to Claim 8 further comprising determining whether the received Protocol Data Unit contains all the data requested and, if not, composing a further request for data.
10. A method according to Claim 8 or Claim 9 further comprising supplying the data to a management application.
11. A method according to any preceding claim, wherein the network management protocol is Simple Network Management Protocol, or a derivative or modification thereof.
12. A network device comprising:
means for responding to Protocol Data Units received containing network management protocol commands;
means for identifying a received Protocol Data Unit designated as a table block access request;
means for indexing a portion of a stored table based on (a) an Object Identifier and (b) an index to a row to be read from the table, obtained from the Protocol Data Unit;
means for determining the number of rows to be read based on information obtained from the Protocol Data Unit;
means for looking up information in the table based on the Object Identifier and the index to the row to be read;
means for composing a response Protocol Data Unit containing information read from the table for a plurality of rows based on they number of rows to be read.
means for responding to Protocol Data Units received containing network management protocol commands;
means for identifying a received Protocol Data Unit designated as a table block access request;
means for indexing a portion of a stored table based on (a) an Object Identifier and (b) an index to a row to be read from the table, obtained from the Protocol Data Unit;
means for determining the number of rows to be read based on information obtained from the Protocol Data Unit;
means for looking up information in the table based on the Object Identifier and the index to the row to be read;
means for composing a response Protocol Data Unit containing information read from the table for a plurality of rows based on they number of rows to be read.
13. A device according to Claim 12, wherein the network management protocol is Simple Network Management Protocol, or a derivative or modification thereof.
14. A Protocol Data Unit comprising:
an identifier signifying that the Protocol Data Unit is a table block access request;
an Object Identifier of a table to be accessed;
an index to a row within the table to be accessed;
information identifying the number of rows to be accessed.
an identifier signifying that the Protocol Data Unit is a table block access request;
an Object Identifier of a table to be accessed;
an index to a row within the table to be accessed;
information identifying the number of rows to be accessed.
15. A Protocol Data Unit according to Claim 22 further comprising information identifying the number of columns in the table to be accessed and an identifier for each column.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9821524.7 | 1998-10-02 | ||
| GB9821524A GB2344262A (en) | 1998-10-02 | 1998-10-02 | Retrieval of network management information |
| PCT/US1999/022651 WO2000020981A1 (en) | 1998-10-02 | 1999-09-29 | Network management information processing |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2345685A1 true CA2345685A1 (en) | 2000-04-13 |
Family
ID=10839907
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002345685A Abandoned CA2345685A1 (en) | 1998-10-02 | 1999-09-29 | Network management information processing |
Country Status (3)
| Country | Link |
|---|---|
| CA (1) | CA2345685A1 (en) |
| GB (1) | GB2344262A (en) |
| WO (1) | WO2000020981A1 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2364467A (en) * | 2000-07-05 | 2002-01-23 | Motorola Inc | Implementation of transactions in a communications network comprising SNMP agents |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69413289T2 (en) * | 1993-03-22 | 1999-06-02 | Ibm | Procedure for reducing the "SNMP" instrumentation message flow |
| US5802309A (en) * | 1996-06-12 | 1998-09-01 | 3Com Corporation | Method for encoding SNMP summary objects |
| US5812668A (en) * | 1996-06-17 | 1998-09-22 | Verifone, Inc. | System, method and article of manufacture for verifying the operation of a remote transaction clearance system utilizing a multichannel, extensible, flexible architecture |
-
1998
- 1998-10-02 GB GB9821524A patent/GB2344262A/en not_active Withdrawn
-
1999
- 1999-09-29 WO PCT/US1999/022651 patent/WO2000020981A1/en active Application Filing
- 1999-09-29 CA CA002345685A patent/CA2345685A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| WO2000020981A8 (en) | 2000-07-20 |
| WO2000020981A1 (en) | 2000-04-13 |
| GB2344262A (en) | 2000-05-31 |
| GB9821524D0 (en) | 1998-11-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8572127B2 (en) | Structure based storage, query, update and transfer of tree-based documents | |
| US7403940B2 (en) | Optimal storage and retrieval of XML data | |
| KR100716167B1 (en) | Network management system and method | |
| US8145674B2 (en) | Structure based storage, query, update and transfer of tree-based documents | |
| US20030018688A1 (en) | Method and apparatus to facilitate accessing data in network management protocol tables | |
| US6888847B2 (en) | Packet transfer method and apparatus | |
| US20030120758A1 (en) | XML conditioning for new devices attached to the network | |
| US20100030846A1 (en) | Method of synchronization between a mobile equipment unit and a smart card | |
| US9736044B2 (en) | Adaptive centralized collection of performance management data using a metamodel | |
| US6694304B1 (en) | System and method for retrieving network management table entries | |
| CA2345685A1 (en) | Network management information processing | |
| CN101179444B (en) | Configuration take-effective method, configuration system and configuration gateway | |
| CN108270599B (en) | Data analysis processing method and system based on SNMP (simple network management protocol) | |
| US9100267B2 (en) | Network management method, a system and a device | |
| US6754213B2 (en) | Flexible and high-speed network packet classifying method | |
| US7447767B2 (en) | System for use in a communications network management system for automatic management of network plant | |
| JP4581259B2 (en) | Embedded electronic device, embedded electronic device, and management method of embedded electronic device | |
| Bierman et al. | Remote Network Monitoring MIB Protocol Identifier Reference Extensions | |
| US7155511B1 (en) | Method for encoding an interface index in a SNMP format | |
| WO2002060164A1 (en) | Method and system for maintaining configuration data | |
| Malkin et al. | RFC1389: RIP Version 2 MIB Extensions | |
| US20050065915A1 (en) | Method and system to add protocol support for network traffic tools | |
| Bierman et al. | RFC3395: Remote Network Monitoring MIB Protocol Identifier Reference Extensions | |
| Stewart | Definitions of Managed Objects for Parallel-printer-like Hardware Devices | |
| CN117812161A (en) | Communication method and system for adapting different medical devices, electronic device and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |