Note: Descriptions are shown in the official language in which they were submitted.
CA 02345685 2001-03-28
WO 00/20981 PCT/US99122651
1
~~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.
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.
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
2
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.
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
3
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
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
4
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
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
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;
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
6
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;
CA 02345685 2001-03-28
WO 00120981 PCT/US99/22651
7
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,
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
8
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 {
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
9
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,
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
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 ) ,
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
11
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
CA 02345685 2001-03-28
WO 00/20981 PC'T/US99/22b51
12
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
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
13
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
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
24
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
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22G51
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.
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
16
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
CA 02345685 2001-03-28
WO 00/20981 PCT/US99/22651
17
- 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.
