The Simple Times is an openly-available publication devoted to the promotion of the Simple Network Management Protocol. In each issue, The Simple Times presents: a refereed technical article, an industry comment, and several featured columns. In addition, some issues include brief announcements, summaries of recent publications, and an activities calendar. For information on submissions, see the end of this issue.
The Simple Times is openly-available. You are free to copy, distribute, or cite its contents; however, any use must credit both the contributor and The Simple Times. (Note that any trademarks appearing herein are the property of their respective owners.) Further, this publication is distributed on an "as is" basis, without warranty. Neither the publisher nor any contributor shall have any liability to any person or entity with respect to any liability, loss, or damage caused or alleged to be caused, directly or indirectly, by the information contained in The Simple Times.
The Simple Times is available via both electronic mail and hard copy. For information on subscriptions, see the end of this issue.
In this issue: Service Management Architecture
This article presents the Service Management Architecture, an architectural framework for defining MIB modules for Customer Network Management (CNM) of network services over shared networks. Network providers offer a myriad of network services, such as X.25, SMDS, Frame Relay, and ATM. Some of these provide connection-oriented service, while others provide connectionless service. CNM services are becoming an important extension of these transport services to provide customers with a management window into their portion of the shared network. This article focuses on an SNMP-based architectural framework for CNM of connection-oriented network services.
The purpose of this work is to identify the notion of a Service MIB module, and to define an architectural framework for its definition that will permit easy extensibility and interoperability across various network services. In order to explore and understand how Service and Device management differ, consider the fundamental differences in network management functionality between a network service provider and a service customer:
+----------------------------------------+
| |
| +-+ +-+ |
| |o|--------------------|o|-\ |
| +-+ +-+ \ |
| \----\/----------------/ \ |
+-----+ | +-+ +-+ |
| NMS |------|--------|o| |o| |
+-----+ | +-+ +-+ |
| /----/\----------------\/---/ |
| +-+ +-+ |
| |o| |o| |
| +-+ +-+ |
| \-------\/------------/\--------\ |
| +-+ +-+ |
| |o| |o| |
| +-+ +-+ |
| |
+----------------------------------------+
Service Provider
+----------------------------------------+
| |
| +-------+ |------o |
| | Proxy |---| / \ | | +-----+
| | Agent | / \ | |---| NMS |
| +-------+ / \ | | +-----+
| o------/-------\------o------------|
| \ / \ / | |
| \ / \ / | |
| \/ \/ | |
| o o |
| |
+----------------------------------------+
Service Customer
Note that these fundamental differences apply both to public networks and to private networks. In the private network case, the ``service provider'' is the network administrator and the ``service customer'' is the network user.
First, service providers are responsible for managing the entire shared network as a whole, while service customers only view and manage their individual portions of the shared service. Because they have a restricted view of the network, customers are unable to perform certain network management functions in the shared environment. For example, a customer which sets routes for optimized throughput of its own traffic may disrupt another customer's traffic. Only the service provider, with a complete view of the entire network, is in a position to determine routes that allow provisioned access to network resources for all customers.
A second fundamental difference in management functionality is that service providers manage the network internals directly, while customers manage their portion of the shared network indirectly. The service provider is responsible for the overall operation of the shared network, so any management control offered to customers must first be approved (perhaps manually) by the service provider before the control request takes effect in the network.
Finally, while service providers see a physical view of the network, customers see a logical view. This logical view includes the customer's configuration of service access points (logical ports) and the virtual connections that run between these logical ports. The customer does not see the individual network switches along the paths of its virtual connections -- setting up physical routes is a responsibility of the service provider.
These fundamental differences in network management functionality suggest that there is a wholly different philosophy between Service Management and Device Management. A Device MIB module allows for hands-on management of a physical entity. A Service MIB module provides to customers a logical view of the customer's portion of a shared network service by modeling the service, not the underlying implementation or devices. Much work has been done and experience gained in writing Device MIB modules for hands-on management of physical devices, but defining Service MIB modules is a relatively new area and requires the development of a new architectural framework.
+----------------------------------------+
| |
| |
| |
| +--------------------------------+ |
| | | |
| | | |
| | | |
| | +----------------------+ | |
| | | | | |
| | | Switch Management | | |
| | | | | |
| | +----------------------+ | |
| | | |
| | Internal Provider | |
| | Network/Service Management | |
| +--------------------------------+ |
| |
| External Customer Management |
| |
+----------------------------------------+
The Service Management Architecture models a service network as a single entity or logical device. Even though a customer may have physical connections to multiple switches within the network, these connections are presented to the customer as individual interfaces on the single logical device. To provide this logical view of the network, a service provider supports a Proxy Agent that consolidates the views from the collection of network switches into a single view. The Proxy Agent does this by mapping the switches' physical views into the single logical view. So to satisfy an SNMP request, the Proxy Agent first maps the logical view back to the physical view, then queries the corresponding switches for the requested information.
There exist two views of virtual connections within the Service Management Architecture: service-provider views and customer end-to-end views. Service-provider views consist of single-segment virtual connections established through a single service provider's network. This view is presented by the service provider's Proxy Agent as a logical configuration of service access points (logical ports), access channels, and virtual connections.
Customer end-to-end views consist of multi-segment end-to-end virtual connections that span across multiple service providers' networks. This view is presented by the customer's Network Management Station (NMS) as a concatenation of individual service-provider segments. It is the responsibility of the NMS to consolidate the individual service-provider views to form the customer end-to-end view. Since an adequate definition of the customer end-to-end view requires much more discussion and experience, the remainder of this article focuses on the single service-provider view.
For consolidated management of diverse network services, the Service Management Architecture presents a single generic view of network configuration. This generic view includes configuration information for all logical ports, access channels, and virtual connections, regardless of network service or underlying datalink protocol. The MIB tables ifTable and ifStackTable contain the generic configuration information for logical ports and access channels, while the newly-proposed cnTable contains the generic configuration information for virtual connections.
For consistent management of diverse network services, the Service Management Architecture provides consistency guidelines for the design of CNM MIB modules specific to a given network service or datalink protocol. These consistency guidelines include:
(VC flow and VC endpoint tables are defined below).
Note the hierarchical relationship between the protocol-generic tables (ifTable, ifStackTable, and cnTable) and protocol-specific tables (for X.25, Frame Relay, and ATM), as diagramed:
+-----------------------------+
| ifTable / ifStack / cnTable |
+-----------------------------+
/ | \
/ | \
/ | \
+---------------+ +---------------+ +---------------+
| X.25 specific | | FR specific | | ATM specific |
+---------------+ +---------------+ +---------------+
Consider a typical Frame Relay interface stack, with a Frame Relay port layered above a DS1 access channel. This interface stack is represented by two entries in the ifTable, one for the physical access channel (DS1) and one for the Frame Relay logical port. The ifStackTable gives the layering relationship between these two ifTable entries. Of course, there may be other layers involved; e.g., a Frame Relay service may run over an ATM service, which itself runs over a physical layer. This interface stack would be represented by three ifTable entries.
The ifTable contains entries for logical ports of various service protocols (e.g., Frame Relay logical ports and ATM logical ports). Each of these service protocols is described in a protocol-specific MIB module that contains a logical port table, which is indexed by the ifIndex of the associated ports. The ifSpecific variable of a logical port's ifTable entry points to the associated protocol-specific logical port table. That table, in turn, may contain pointers to other protocol-specific tables, such as a link management table. An example table relationship for a Frame Relay logical port might be:
ifTable FR Logical FR Link
+-----------------+ Port Table Mgmt Table
| ifIndex = 50 |
+-----------------+ +----------------+ +--------------+
| ... | +->| portIndex = 50 | +->| lmIndex = 50 |
+-----------------+ | +----------------+ | +--------------+
| ifType = FR svc | | | ... | | | |
+-----------------+ | +----------------+ | | |
| ... | | | lmSpecific ----+ | ... |
+-----------------+ | +----------------+ | |
| ifSpecific -----+ | ... | | |
+-----------------+ +----------------+ +--------------+
+------------------------------------+
| |
| ingress egress |
ingress | +-------+ +-------+ | egress
-> - - - - - - - | |----------| | - - - - - - ->
| +-------+ +-------+ |
| |
+------------------------------------+
VC Flow Table
+------------------------------------+
| |
| endpoint |
ingress -> | +-------+ +-------+ |
- - - - - - - | |----------| | - - - - - - -
<- egress | +-------+ +-------+ |
| |
+------------------------------------+
VC Endpoint Table
Entries in VC endpoint tables represent connections as seen from a single endpoint. These entries are indexed by a single endpoint of the connection, with an entry's MIB variables referring to the ingress and egress at that endpoint. Note again that point-to-point virtual connections are represented by two entries in a VC endpoint table, one entry for each endpoint. The consistency guidelines of the Service Management Architecture recommend using VC endpoint tables for the real-time virtual connection performance statistics.
VC flow tables and VC endpoint tables extend naturally to handle point-to-multipoint and multipoint-to-multipoint connections as well. For example, consider a full-duplex point-to-multipoint connection from point A to points B, C, and D. This virtual connection consists of 6 unidirectional flows, so a VC flow table will have 6 entries. Likewise, this connection has 4 endpoints, so a VC endpoint table will have 4 entries.
Within the Service Management Architecture, the MIB table structure for virtual connections is similar to the structure for logical ports. All virtual connections, regardless of protocol type, are placed in the protocol-generic cnTable, with each entry in cnTable containing a pointer to the associated entry in a protocol-specific virtual connection table. Note that this pointer points to an actual entry in the protocol-specific table, not just the top of the table. This is necessary because the protocol-specific VC table may be indexed differently than the protocol-generic cnTable.
The cnTable is modeled as a VC flow table and, as such, is indexed by both the ingress and egress endpoints of a virtual connection flow. These connection endpoints must be identified generically, because the cnTable contains entries for virtual connections of various datalink protocols. Thus, each connection endpoint is identified by a tuple (logical port ifIndex, VC id), where the VC id is a logical identifier unique to the associated logical port. This VC id is assigned by the service provider as it sees fit. The service provider may map the VC id directly to the addressing scheme used in the underlying protocol (e.g., DLCI for Frame Relay), but this is not necessary. The cnTable is therefore indexed on these four fields: ingress ifIndex, ingress VC id, egress ifIndex, and egress VC id.
The cnTable contains an OID that points to associated entries in protocol-specific VC tables. To allow for management of interworking service objects, the reverse references must also be in place, i.e., references from the protocol-specific VC tables to entries in the cnTable. These backward references may be either OIDs or indexes into cnTable. Consider the table relationship between the cnTable and a protocol-specific VC table:
cnTable protocol-specific
+-----------------+ VC table
| cnIngressIfIndex|
+-----------------+ +-------------------+
| cnIngressVcId | +->| protocol-specific |
+-----------------+ | | VC table indexes |
| cnEgressIfIndex | | +-------------------+
+-----------------+ | | |
| cnEgressVcId | | | ... |
+-----------------+ | | |
| ... | | +-------------------+
+-----------------+ | | cnTable |
| cnSpecific -----+ | back reference |
+-----------------+ +-------------------+
Of the various views for managing a network, the Service Management Architecture focuses on external customer management at the outer level. A service network is modeled as a single entity or logical device by a Proxy Agent supported by the service provider. This Proxy Agent consolidates the views from the many switches in the network into a single logical view for the service customer.
The Service Management Architecture presents two views of virtual connections: service-provider views and customer end-to-end views. Service-provider views consist of single-segment virtual connections established through a single service provider's network, while customer end-to-end views consist of multi-segment end-to-end virtual connections that span across multiple service providers' networks. The Service Management Architecture focuses mainly on the service provider view, postponing the details of the customer end-to-end view for future work.
The Service Management Architecture provides a consolidated and consistent management framework for customer network management. By presenting a generic view of network configuration using ifTable, ifStackTable, and cnTable, the Service Management Architecture consolidates diverse network services into a single view; and, by providing consistency guidelines, the Service Management Architecture permits consistent management at the protocol-specific level of these diverse network services. The result is an architectural framework that permits easy extensibility and interoperability across various network services.
Due to external events (the INTEROP Europe conference and the next IETF meeting), this is a short issue. So, once again, I have an excuse for ``no comment''.
In this issue: A Network Management Perspective on the age-old Token Ring vs. Ethernet Debate
Ever since token ring was introduced, there have been debates between token ring proponents and fans of ethernet. Owing largely to the culture clash between these two groups, these debates have been long on religion and short on reality and experience. This article will attempt to be different by taking a network management perspective as well as dealing with the changing technology scene. In particular it will not focus on the relative architectural merits of these two technologies, but rather will focus on the characteristics of real products and experiences of real networks.
We will compare ethernet implemented with SNMP-managed 10baseT hubs and token ring implemented with passive hubs (MAUs) because these are the technologies most often used for these networks. Both support a star-shaped wiring scheme and provide similar bandwidth. However, 10baseT ethernet has the advantage in cost, reliability, and network management.
Type Adapter Hub Total ================== ======= === ===== Low End 10baseT 60 80 140 Low End token ring 285 55 340 High End 10baseT 120 125 245 High End token ring 600 75 675This shows that token ring is about twice as expensive as ethernet. A similar price differential exists for other network equipment such as bridges and routers.
Analogies can be drawn between the design principles that have contributed to the success of SNMP, and the relative successfulness of token ring and ethernet. For example, token ring has shifted the complexity from the centralized hub to the many network adapters. This increases the total cost of the system because there are many more end nodes than hubs. 10BaseT has extremely simple and cheap interfaces and a more complex hub, not unlike SNMP's simple agents and more complex management stations. Further, ethernet as a whole is much simpler than token ring, making it cheaper, more reliable, and easier to understand.
Token ring has an advantage when running at very high utilization rates. A token ring can run at 100 percent utilization and continue to provide fair access to all stations, while it isn't prudent to run an ethernet at greater than 50% average 0% load. On the other hand, while token ring may work better in the worst case, good network managers never experience the worst case.
Both 10baseT and token ring advertise the capability to isolate low-level errors by shutting off or routing around the bad link. Token ring hubs have electrical relays that are used to automatically disconnect faulty lines from the hub and to route the ring around the disconnected line. It is important to note some limitations of this fault isolation scheme. First, these relays are not present on the hub-to-hub links (Ring-In and Ring-Out on the MAU), so cable breaks between hubs will take down the ring. Second, these relays often don't disconnect faulty lines as they are supposed to, especially with marginal cable or connector problems or when a video card is plugged into the token ring (a common occurrence!). Third, since these relays are mechanical devices, they sometimes stick in their normal state, unable to route the ring around a host when it powers off or reboots. This makes it necessary for token ring network managers to carry around a small tool that momentarily zaps a stuck relay and unsticks it, restoring the network to operation.
150 feet
+----Node A---------------Node B----+
| |
| |
150 feet | | 150 feet
| |
| |
+----Node D---------------Node C----+
150 feet
150 feet
+----Node A---------------Node B----+
| |
| |
| |
| +--------+ +--------+ |
| | | | | |
+--+ Node D +-----------+ Node C +--+
450 feet
This results in a 450 foot link between Host B and Host A, which is not what the network manager expected and might put the ring in a marginal or non-functioning state. This might keep server backups from running at night after many users have powered down their PCs. It is noteworthy that a similar problem is possible with the optical bypass mechanism on FDDI rings. One advantage of token ring that particularly helps in this situation is that it is better suited to running over longer distances than ethernet. When ethernet is run over long distances (more than several hundred feet), collision rates increase, often necessitating the installation of bridges or routers.
A common tool for solving low-layer network problems is the protocol analyzer. A protocol analyzer is often used to view packets with errors, but due to a lack of capabilities in most token ring chipsets most token ring analyzers can't display those packets. The network manager can only count the number of such errors that occurred. On an ethernet network, these bad packets can be captured and examined to determine their type and length, for example.
Dear Dr. SNMP,
Why is the ability to reset a managed device NOT a standard MIB-II object? It seems to me that the ability to reset a managed device is a very basic and necessary network management control function.
-- Absolutely, Positively from Memphis
Dear Absolutely, Positively,
Down on the farm (in the Bible belt), we have a saying:
``If the blind lead the blind, both shall fall into the ditch.''The simple answer is that when MIB-I and MIB-II were written, we didn't see the the need for this. Of course now it seems so clear that even Helen Keller could have seen this need, and we should have. However, we didn't, and it just did not become a part of MIB-I or MIB-II.
Nevertheless, it isn't too late for a MIB variable to become a part of the standard MIB, even if it is too late for it to be a part of MIB-II. Extending the MIB is easy to do, and extensions can become de jure and de facto standards when there is strong agreement about the need. This is one of the best aspects of the Internet-standard Management Framework based on the SNMP and SNMPv2.
In the meantime, many network administrators are using Uninterruptible Power Supply (UPS) technology, not only to provide uninterrupted power, but also to provide this reset capability. A smart UPS which can be monitored and controlled via the SNMP can be used to toggle the power off and then back on, resetting the device.
Of course, Dr. SNMP will understand if you personally might not want to spend your company's money on UPS technology since your trucks are of a different color.
The performance improvements of SNMPv2's ``awesome'' get-bulk PDU are well known. Less known is that the introduction of the operator requires remarkably few changes to an SNMPv1 agent. In this article, we'll examine these few changes.
Thus, through using get-bulk, a manager can retrieve in one request as many variables, e.g., from the rows of a large table, as will fit in a maximum-sized response without knowing the names (i.e., the instance identifiers) of the particular variables it wants to retrieve. When max-repetitions has a value of one, get-bulk operates identically to get-next, with the exception that get-bulk never returns a tooBig error; if a get-next would return tooBig, get-bulk will return less than a whole repetition.
First, after the first repetition, the variable name, which is supplied to the method-routines for finding the next variable, is derived not from the variable-bindings in the request, but from the result of a previous repetition. In particular, for each repeated variable, the variable name supplied on the j-th repetition is the variable name obtained from the (j-1)-th repetition of that variable. Thus, an implementation need only keep a copy of the last variable name obtained from each repeated variable and point to it on second and subsequent repetitions.
Second, the protocol engine code must terminate the processing of repetitions (in the middle of a repetition if necessary) if and when the (ASN.1 encoded) size of the response approaches its maximum value. This termination does not need to occur on the exact number of variables for which one more variable would exceed the maximum size; RFC 1448 specifically allows an approximation in this respect, i.e., it allows the response to contain some (small number of) variables less than would create a maximum-sized PDU. However, termination is not allowed to occur at some fixed number of variables.
To achieve this, an implementation must calculate the size of the ASN.1 encoding (of the name and value) of each variable as the repetitions proceed, and accumulate these sizes. Because the approximation is allowed, the maximum size of the overhead (of the message wrapper and PDU header which will later be needed for the response PDU) can be calculated, rather than precisely calculating the actual size in advance. Indeed, a precise calculation in advance of the size of the overhead may not be possible (e.g., because the size of the clock values in an authenticated response can vary). Thus, as the repetitions proceed, the maximum size of the overhead plus the accumulated size of the variable encodings is compared to the maximum size of the response, and if the next variable would cause the response to be too big, then the repetitions are terminated without including that variable.
In the past month, the IEEE 802.3 Repeater MIB has been updated and published as a Draft Standard -- the second rung on the standards ladder. A new version of the FDDI MIB has been published. The old version was based on ANSI FDDI SMT 6.2, whereas the new version is based on ANSI FDDI SMT 7.3. The new version enters the standards track at the first rung, Proposed Standard, since it is a completely new set of objects, even though there is much similarity to the previous version. The Host resources MIB was also published. There has been much interest in getting it completed since the working group was formed 18 months ago. It should be a welcome addition in the expansion of manageable devices since it is the first explicitly directed toward PCs and workstations (i.e., end-systems), instead of routers and bridges (i.e., intermediate-systems). The Token Ring RMON MIB, published as a Proposed Standard, adds support for this media type to the RMON framework. The MAU MIB, also published as a Proposed Standard, completes the document set that defines management for 802.3 devices. And finally, the Source Routing Bridge MIB objects from the original Bridge MIB, RFC 1286, have been published as a separate document after a few cleanups.
This is an irregularly published RFC containing the status of all standards for the Internet community. (Currently, the most recent source for the status of RFCs is the file 1rfc_index.txt stored in directory iesg on host cnri.reston.va.us).
RFC 1503 - Algorithms for Automating Administration in SNMPv2 Managers (Informational)
An experimental approach is presented in this document to minimize the amount of information that is required for a user to specify when invoking a management station application in order for SNMPv2 communications to be established and maintained. The document specifies the implementation model, configuration assumptions, operational details, and how to determine and use maintenance knowledge.
RFC 1512 - FDDI Interface Type (SMT 7.3) MIB (Proposed standard)
This defines managed objects for interfaces using FDDI based on ANSI FDDI SMT 7.3. This document is a companion to RFC 1285 which is based on ANSI FDDI SMT 6.2. The SMT group has an object which is the number of SMTs in a device and a table that fully describes each SMT. Next, the MAC group has information on MACs in the device. The optional enhanced MAC counters group has additional MAC counters. The PATH group consists of two tables and a scalar object. The tables list the paths and how they are configured. Finally, the PORT group contains objects which describe the characteristics of all ports.
RFC 1513 - Token Ring Extensions to the RMON MIB (Proposed standard)
The RMON MIB, RFC 1271, defines a framework for remote monitoring by a network probe and those necessary objects specific for IEEE 802.3 (ethernet) networks. This MIB defines those comparable objects for IEEE 802.5 (token ring), and objects for additional monitoring functions used only for token ring. Those objects used to fill out the media specific framework of the RMON MIB include the MAC layer frame statistics table and associated history table, and the logical link layer frame statistics table and associated history table. The additional objects include those based on stations in a ring, and those for monitoring source routing frames.
RFC 1514 - Host Resources MIB (Proposed standard)
This MIB defines a framework and base set of objects independent of hardware and software for managing primarily end-node (host computers) on a network. The first group, System, augments the system group from MIB-II. The Storage group describes the storage areas such as file systems, primary memory (RAM), and swap space. The next group has several tables used to describe devices such as processors, network interfaces, printers, disk drives, etc., on a host system. Executing software is described by the next group. Associated with the table of executing software is an optional table of memory and processor consumption for each executing program. The last group contains objects that describe the locally installed software on the host.
RFC 1515 - IEEE 802.3 Medium Access Unit (MAU) MIB (Proposed standard)
This MIB defines the objects used in managing IEEE 802.3 Medium Attachment Units (MAUs). There are three classes of MAUs identified by this MIB. Each has a group of objects defining its characteristics. The classes are repeaters, interfaces, and broadband DTEs.
RFC 1516 - IEEE 802.3 Repeater MIB (Draft standard)
This is an updated version of RFC 1368. Several descriptions were updated for clarity. The behavior for object rptrAddrTrackLastSource was incompletely defined, and instead of updating the description, a new object, rptrAddrTrackNewLastSrcAddress, was created to replace it.
RFC 1525 - Source Routing Bridge MIB (Proposed standard)
The source routing bridge MIB objects under the dot1dSr branch from the original bridge MIB, RFC 1286, were removed to create this separate MIB module. The definitions were updated to track the changes in the IEEE 802.5M SRT Addendum to the IEEE 802.1D Standard for MAC Bridges. The MIB contains two tables: the port table, describes each port on a source routing bridge; and, the port-pair table, contains the bridge number and state for each port pair.
Even with the beacon there are still challenges. The SNMPv2 rules for the Structure of Management Information (SMI) has some really nice features that would be desirable to use. However, at the INTEROP August 1993 Conference and Exhibition in San Francisco, there were few companies making commitments for shipping SNMPv2 end-user products! Some companies were visibly upset when asked about future SNMPv2 products instead of current SNMPv1 products.
A standards organization has to be careful that it keeps its constituency happy. The transition to SNMPv2 needs to make sure it doesn't outpace it's users. The primary authors were quite careful in planning the transition. Some of the proponents for adding creation and deletion operations to SNMPv2 didn't consider the transition consequences of these additions. So, it may be a jerky ride of speeding up, and slowing down while transitioning. More direction lights are needed, such as additional MIB compilers and tools, as well as mangement station vendors smoothing the path. This column will blow the horn when the first MIB is transitioned to SNMPv2.
In the next issue, we'll give you an update on the state of the transition and the IETF standards process which is again being updated.
SNMPv2 Framework (Proposed Standards):
Full Standards:
Draft Standards:
Proposed Standards:
Experimental:
Informational:
Historical:
input-packet-rate =
(delta(ifInUcastPkts,t1,
ifInUcastPkts,t0)
+ delta(ifInNUcastPkts,t1,
ifInNUcastPkts,t0))
/ (t1 - t0)
output-packet-rate =
(delta(ifOutUcastPkts,t1,
ifOutUcastPkts,t0)
+ delta(ifOutNUcastPkts,t1,
ifOutNUcastPkts,t0))
/ (t1 - t0)
broadcast-rate =
(delta(ifInNUcastPkts,t1,
ifInNUcastPkts,t0)
+ delta(ifOutNUcastPkts,t1,
ifOutNUcastPkts,t0))
/ (t1 - t0)
traffic-rate =
(delta(ifUcastPkts,t1,
ifInUcastPkts,t0)
+ delta(ifOutUcastPkts,t1,
ifOutUcastPkts,t0))
/ (t1 - t0)
November 1-5, Houston, TX
For information: +1 703 620 8990
The Simple Times also solicits terse announcements of products and services, publications, and events. These contributions are reviewed only to the extent required to ensure commonly-accepted publication norms.
Submissions are accepted only via e-mail, and must be formatted in HTML version 1.0. Each submission must include the author's full name, title, affiliation, postal and electronic mail addresses, telephone, and fax numbers. Note that by initiating this process, the submitting party agrees to place the contribution into the public domain.
In addition, The Simple Times has numerous hard copy distribution outlets. Contact your favorite SNMP vendor and see if they carry it. If not, contact the publisher and ask for a list.