WO1995026090A1 - Distributed autonomous object architecture for network layer routing - Google Patents

Distributed autonomous object architecture for network layer routing Download PDF

Info

Publication number
WO1995026090A1
WO1995026090A1 PCT/US1995/003606 US9503606W WO9526090A1 WO 1995026090 A1 WO1995026090 A1 WO 1995026090A1 US 9503606 W US9503606 W US 9503606W WO 9526090 A1 WO9526090 A1 WO 9526090A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
routing
router
interface
protocol
Prior art date
Application number
PCT/US1995/003606
Other languages
French (fr)
Inventor
Kurt Dobbins
Kris Dobbins
Len Cormier
Kevin Yohe
William Haggerty
Paul Simoneau
Rich Soczewinski
Original Assignee
Cabletron Systems, Inc.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Cabletron Systems, Inc. filed Critical Cabletron Systems, Inc.
Priority to EP95914816A priority Critical patent/EP0752180A1/en
Priority to AU21914/95A priority patent/AU678109B2/en
Priority to JP7524807A priority patent/JPH09506752A/en
Publication of WO1995026090A1 publication Critical patent/WO1995026090A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • 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]
    • 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/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/42—Centralised routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/44—Distributed routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/52—Multiprotocol routers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/56—Routing software
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • 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/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H04L41/0856—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information by backing up or archiving configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Definitions

  • the present invention is directed to an apparatus and method for routing packets on a communications network, and more particularly to an object-oriented system which utilizes common protocol-independent base objects to instantiate protocol-specific objects and which distributes the critical function and system behavior into autonomous objects.
  • the system supports multiple network and routing protocols, is manageable, and readily scales to new platforms, architectures and media technologies.
  • Intelligent hubs are becoming widely deployed in networks to provide network connectivity to access devices. Hubs that provide access into the network allow the distribution of access policies and connectivity to occur close to the end system attachment.
  • network-level routers are being deployed on a large scale to connect together the distributed hubs.
  • this network service was provided by centralized router devices, as shown in Fig. 1A.
  • the centralized router's bandwidth and number of physical network interfaces become saturated, it is costly to add incremental distributed service.
  • router functions have been integrated into distributed hubs. As shown in Fig. IB, this essentially "pushes" routing functionality out to the point where users gain physical connectivity into the network. In addition, these distributed routers can allow greater network access into a centralized router by off-loading the routing functions (Fig. 1C) .
  • the routing functionality pushes out and is more widely deployed, it places a tremendous strain on the configuration and control of these distributed devices.
  • hubs provide for access by many LAN technologies
  • the router in a hub has to have support for a wide range of network connectivity in the same chassis.
  • thenumber of access ports can vary from one or two, to several hundred, since these ports provide the connectivity to end users of the network.
  • the architecture To be able to implement routing services in these distributed hub and network devices, the architecture must be extremely flexible, scaleable, and adaptive to different hub configurations and chassis, and be able to support a variety of present and future protocols. Also, the architecture needs to provide a high degree of manageability since the operation and control of routing in these distributed hubs will be substantially more difficult due to the sheer number of these devices in a network and due to the variation of technology integrated in the hub/router.
  • the present invention is an apparatus and method for routing information on a communications network which provides a high availability of service, remote management and monitoring, and interoperability.
  • the system has an open-ended architecture, which means it is open to changing technologies, both in the underlying media as well as in the protocol, and open to expanding the size of the network.
  • an object-oriented architecture which distributes the critical function and system behavior into autonomous router objects. All router objects have three types of imbedded functionality automatically built in, including:
  • the common protocol-independent functions of the object which may be a routing function (e.g., forwarding information base, FIB) or a system function (e.g., event or timer).
  • a routing function e.g., forwarding information base, FIB
  • a system function e.g., event or timer.
  • all forwarding engines have a forward method as well as a service method regardless of the particular protocol;
  • base resource object class which define the methods and data for configuration and control.
  • any object of the network interface class has network interface-configuration inside it automatically;
  • each object becomes autonomous, i.e., the services and data normally external to the object are embedded or accessible within the object itself.
  • some objects are distributed "across the network," i.e., as opposed to providing one central forwarding engine, in this invention a separate forwarding engine object is provided at each network interface.
  • All objects are connected through a router resource object, which instantiates all objects in an orderly fashion to allow binding and ordered start-up. Once the objects exist, they become autonomous in that each knows its own binding and object behavior defined in the base classes. The objects are also connected through a managed-object framework for management.
  • each object has:
  • Text e.g., ASCII
  • IP Internet Protocol for the TCP/IP protocol suite
  • the router may not implement all possible network protocols, it is possible to add additional protocols with a minimum of coding changes. In addition, the router is able to support a number of different routing protocols. Within the Internet community, the following are commonly used:
  • the router also supports a variety of communications media, and is able to interface the network protocols to the media drivers.
  • Fig. 1A is a schematic illustration of a network utilizing a centralized router
  • Fig. IB is a schematic illustration of a network utilizing distributed hub-routers
  • Fig. 1C is a schematic illustration of a network utilizing both a centralized router and distributed hub-routers
  • Fig. 2A is a schematic illustration of a network utilizing a plurality of distributed routers according to one embodiment of this invention
  • FIG. 2B is an illustration of a hub-router according to one embodiment of this invention.
  • Fig. 3 is a three-dimensional system architecture view of the router of this invention showing each functional subsystem on a separate "plane";
  • Fig. 3B is an alternative view of the system architecture as a "flat" system
  • Fig. 3C is a schematic illustration of a routing protocol object, for a distance-vector protocol such as RIP;
  • Fig. 3D is a schematic illustration of a "host" forwarding engine object
  • Fig. 3E is a schematic illustration of a "protocol" forwarding engine object
  • Fig. 4 is a flow diagram illustrating the service and forward methods of the distributed autonomous forwarding engines
  • Fig. 5 is a schematic illustration of the network layer and framing object component relationships
  • Fig. 6 is a flow diagram of a distributed routing event timer
  • Fig. 7 is a schematic illustration of the structure of the managed object framework
  • Fig. 8 is a schematic illustration of the structure of the managed object MIB tree
  • Fig. 9 is a flow diagram illustrating the storage of persistent objects in non-volatile memory
  • Fig. 10 is a schematic illustration of the basic management model
  • Fig. 11 is a general illustration of the common MIB template for routing services
  • Fig. 12 is a schematic illustration of the relationships between the base resource, resource table, and resource entry;
  • Fig. 13 is a schematic illustration of the base resource class hierarchy
  • Fig. 14 is an example of a base resource class hierarchy
  • Fig. 15 is a schematic illustration of the registration in tables at the service, component and interface levels of the base resource
  • Fig. 16 is a schematic illustration showing an example of instances of router services and instances of router components
  • Fig. 17 is a schematic illustration of the router resource hierarchy of services, components, and interfaces
  • Fig. 18 is a schematic illustration of the method of accessing an object with the prior art SNMP method; and Fig. 19 is a schematic illustration of the new method of accessing an object using the MIB navigator.
  • Fig. 2A shows one embodiment of a network utilizing the routing apparatus and methods of this invention.
  • the network 100 is illustrated schematically as four subnets 101, 102, 103, 104 each connected to one of four routers 105, 106, 107, 108, respectively.
  • Each subnet may comprise, for example, a plurality of LANs, each connected to a port of its associated multiport router.
  • the four routers are connected by links 109.
  • the routers are pushed outwardly in the network (as opposed to a central router backbone) and serve as network access points. This provides scaleability as the network can be easily expanded by adding another router and associated subnets.
  • Each router has an adaptive architecture so it can handle multiple protocols and is subject to remote management, so that the entire network can be managed "as a whole.”
  • Fig. 2B illustrates an intelligent hub-router 312 for use in the network of Fig. 2A.
  • the hub-router has a chassis 313 with a plurality of plug-in modules 314-321.
  • the hub accesses three separate subnets 322, 323, 324 on each of channels A, B and C, respectively. Each channel is equivalent to a network interface.
  • modules 314-315 provide access on channel A to first subnet 322
  • modules 316-318 provide access on channel B to second subnet 323
  • modules 318-320 provide access on channel C to third subnet 324.
  • the module 321 then provides access on channel D to the network backbone, i.e., the other routers in the network of Fig. 2A.
  • This invention utilizes "object-oriented programming” as defined in Grady Booch, "Object-Oriented Analysis And Design, With Applications,” Second Edition, Benjamin Cummins Publishing, 1994, which is hereby incorporated by reference in its entirety.
  • the data and operations are united into fundamental logical building blocks of classes and objects.
  • Object-oriented programming may be defined as a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are members of a hierarchy of classes united via inheritance relationships. See Booch, Chap. 2.
  • Well-known object-oriented languages include C++, SmallTalk, Object Pascal, CLOS, and Effifel. In the embodiment described herein, the C++ language is utilized.
  • router and “routing apparatus” are used broadly in this specification to include software and hardware that can forward packets at the network layer and can exchange network topology information used in a variety of exchange protocols.
  • network is used generally to include local area networks, wide-area networks, and several networks connected together by gateways (or routers), known as an internet.
  • Internetworking and communication systems are typically built around a set of discrete subsystems. While these discrete subsystems may be highly integrated, they operate as functionally separate parts. For example, process functions exist separately from configuration data and network management.
  • process functions exist separately from configuration data and network management.
  • each communication protocol stacks is supported, each exists as a completely different "vertical" stack, e.g., IP Stack, IPX Stack, DECnet Stack, with totally separate configuration, control, monitoring, network management, and protocol-specific behavior/functionality.
  • IP Stack IPX Stack
  • DECnet Stack e.g., IPX Stack, DECnet Stack
  • the distributed object architecture of the present invention defines all of the functional aspects to implement a generalized, common protocol-independent framework which is inherited by every protocol-specific object upon instantiation.
  • a Router Resource object instantiates all objects in an orderly fashion to allow binding and ordered start-up. Once the objects exist, they become autonomous in that each knows its own binding and object behavior defined in the base classes.
  • Fig. 3A is a three-dimensional view of the system architecture according to this invention showing the logical relationships between objects and wherein each functional subsystem is shown as a separate "plane.”
  • system architecture 200 includes four horizontally disposed planes: routing applications 201; host communications 202; forwarding 203; and network interfaces 204.
  • Objects that are "tiled” show that multiple instantiations can exist; for example, the forwarding and routing protocol objects 234 in plane 203 are instantiated for each individual protocol.
  • the rearwardly directed dashed arrows 206 show that additional instances can exist. Connections between the different planes are shown by dashed lines 205. These logical connections are through resource objects and a naming tree.
  • Fig. 3A also shows that all objects are connected through a vertical router resource objects plane 207. At the same time, all objects to be managed are connected through a vertical managed object plane 208.
  • the system architecture can alternatively be viewed in Fig. 3B as a "flat" system, wherein corresponding elements are identified with a prime designation.
  • managed objects 208' which include MIB objects 209', MIB tree 210', persistent objects 211', NVRAM managed objects 212', NVRAM 213', and MIB navigator 231'.
  • router resource objects 207' including router services 214', router components 215', router interfaces 216', router configuration 217', and events 218'.
  • Fig. 3B shows more clearly the connections between routing applications 201', host communications 202', forwarding services 203', and network interface services 204'.
  • a routing protocol object 219' is instantiated for each routing protocol, such as the RIP distance-vector protocol.
  • the routing protocol object 219' is further illustrated in Fig. 3C to include routing protocol thread object 220', which is connected to each of event object 221', routing table object 223', network interface object 224', and neighbor list object 225'.
  • the event object 221' is further connected to timer object 222' and socket object 226', the latter of which is connected via line 205' (see Fig. 3B) to sockets 227' in host communications 202'.
  • host communications 202' further includes SNMP agent 228', timers 229' and host communication stack 230', all connected to sockets 227'.
  • the host communication stack 230' is connected via a shared memory queue 236' to a host forwarding engine 232', which is described more fully in Fig. 3D.
  • the engine 232' includes forward and service object 235' which accesses the host memory via host message queue object 236' , which is shared between host communications 202' and forwarding services 203'.
  • the forward and service object 235' also accesses the network forwarding table object 233', also known as the forwarding information base (FIB) .
  • FIB forwarding information base
  • the forwarding information base 233' is connected to each of a plurality of "protocol" forwarding engines 234' which are further illustrated in Fig. 3E.
  • the protocol forwarding engine object 234' includes a forward and service object 239' connected to each of an access list object 240', a next-hop cache object 241', and a framing object 242'.
  • the framing object 242' is connected to each of address cache object 243' and network interface object 237'.
  • the next-hopcache object 241' is connected to the network forwarding table object 233', or FIB in Fig. 3B.
  • each network interface object 237' is connected below to a network media device driver 238' .
  • the architecture includes each of the following subsystems:
  • Managed Objects allow router objects to have embedded network management for remote configuration, monitoring, and control. This framework allows any data element or object to be given "management" visibility which includes a unique object identifier and name. In cases where the router object's value needs to be retained and restored through system resets and re-starts (power cycle), the framework allows the object to make itself persistent by saving and restoring itself (using the NVRAM file system). This functionality is transparent to the actual object.
  • Resource Objects provide for a common system template (boilerplate) regardless of the protocol-specific object. They also enforce a common MIB (managed information base) structure and content which makes every router application in the system look and be controlled the same. This is provided to protocol suites that may be fundamentally different.
  • Forwarding Objects provide a distributed forwarding architecture that scales to new network interfaces and media types. It provides a protocol-independant framework for switching network packets, as well as for delivering packets internally to the upper-layer protocol applications. Reframing between different media types is also provided since each object is bound to a particular network interface.
  • Routing Protocol Objects provide the ability to exchange network topology information and determine next-hop routes used for packet network forwarding. These objects will be further described in the following subsections.
  • each protocol always gets the packet and then decides if it was appropriate for the interface. It is a centralized model with the protocol layer being the funnel for all packets entering and exiting the system regardless of the interface the packet came in on. Also, because it is centralized, each layer must have knowledge about every specific interface. For example, all configured interface information such as MTU size, forwarding enabled/disabled state, configured network addresses and masks, data-link framing options, filter access lists, etc, must be accessed by each layer as it processes/forwards the packet.
  • This model puts overhead into each layer and is very limiting in supporting new interfaces, media, and protocols, as each layer must be modified. An example of overhead is that if a packet is received for a protocol that is not enabled, it is not dropped until it has been passed up to the correct protocol layer.
  • this invention utilizes distributed autonomous forwarding engines as shown in Fig. 4.
  • each interface 11, 14, 17 has a forwarding engine 12, 15, 18 sitting above it, and each forwarding engine knows how to receive and transmit packets on its own interface. Also, each engine only knows its own configuration information and only knows how to receive and transmit packets on the one interface it is associated with.
  • Each forwarding engine accesses a common forwarding table 20.
  • the interface objects 11, 14 of Fig. 4 are the same as network interface objects 237' in Figs. 3B and 3E, with FAS objects 12, 15 (Fig. 4) corresponding to objects 239' (Figs. 3B and 3E) .
  • the host interface object 17 (Fig. 4) corresponds to host message queue 236' (Figs. 3B and 3D), with host FAS object 18 (Fig. 4) corresponding to FAS object 235' (Fig. 3B) .
  • the forwarding table 20 (Fig. 4) corresponds to FIB 233' (Fig. 3B) .
  • the host In order to provide a consistent-forwarding model for packets destined for "local" delivery into the "host” CPU, the host is treated as an internal interface with a destination address. The delivery of host destination packets remains in band to the forwarding function.
  • the interface object 11 calls a service method in its bound forwarding engine object 12.
  • the service method removes the sublayer framing on the network packet and performs a validation and extraction of the destination network address from the network packet .
  • the service method then provides a next-hop determination by looking up the destination network address in a cache memory of active addresses to determine a destination forwarding engine object handle, and, if the destination network address is not located in cache memory, accessing a forward look-up table 20 for the best route to the destination network address, and then updating its cache.
  • the method then returns the destination forwarding engine object handle.
  • a service method is called in the destination forwarding engine object 15.
  • the service method validates the destination address, performs a look-up in an address cache to obtain a media specific address of the destination, and the service method then reframes the packet and transfers it to the destination interface 14.
  • the host FAS object 18 is called and the packet is transmitted out on the host interface 17.
  • each forwarding engine acts independently to process packets, yet they each unknowingly interact together to collectively provide a system-wide forwarding subsystem which is protocol independent, interface independent, and very scalable (supports 1 to n interfaces).
  • each forwarding engine of this invention is implemented using object-orientated methodology and are written in the language C++.
  • each forwarding engine has its own data portion 13, 16, 19 that is specific to itself, e.g., interface and media information, address resolution tables, configuration information, etc.
  • the method portion 12, 15, 18 of each engine is common and is shared by all similar engines.
  • each forwarding engine performs these same basic tasks regardless of protocol or media.
  • each protocol engine is derived from a common Base Class. This allows a generic and common interface to each engine regardless of protocol. Specifically, this Base Class defines the following virtual methods which are then overloaded by each protocol engine that is derived from this Base Class: service(packet_descriptor_pointer) forward_net_packet(packet_descriptor_pointer) forward_host_packet(packet_de ⁇ criptor_pointe )
  • the service function refers to the actual in-bound processing of a network layer packet which consists of the following:
  • the forward function refers to the actual out-bound processing of a network layer packet which consists of the following:
  • each protocol forwarding engine has a generic interface for packet servicing and forwarding, regardless of the specific protocol type. This is done on the service side by having each protocol FAS register a pointer to its base class with a packet dispatcher at the data link level for each interface it is instantiated on. This allows a packet dispatcher to invoke the overloaded virtual service method without having to know protocol FAS specifics, i.e.,
  • the service function for the specific protocol FAS on a particular interface is invoked only when network layer packets for that protocol are received on that interface.
  • Each protocol FAS registers itself with the forwarding table for that protocol. This is done by registering its network address and masks along with a pointer to its base class with the internal forwarding table. This table is used by the service method of each protocol FAS to determine which FAS should be invoked to forward the packet, i.e.,
  • FAS_ptr Forwarding Table_Lookup (Destination_Network_Addre ⁇ s) ; Fas_ptr->forward_net_packet (pkt_descr_ptr); This allows the service portion of the FAS that was instantiated on the interface the packet was received on, to forward the packet to the FAS which was instantiated on the interface the packet should be transmitted out on. This is effectively interface independent, as the binding is done, via the Forwarding Table Lookup dynamically, and is based upon each FAS that exists (1 to n) registering itself and the network it is instantiated on with the Forwarding Table.
  • Performance-sensitive code often employs caching to speed up performance.
  • hash codes are used to speed retrieval of the cached data.
  • the UNIX operating system for example, keeps a number of such caches internally.
  • Routers must make a forwarding decision for every packet received as to what interface and next hop gateway to forward to.
  • the decision is laborious because a number of competing route choices exist in the Forwarding Information Base (FIB), and the best route must be selected based on address match, metrics, quality of service, route type or class, network versus subnet granularity, etc.
  • FIB Forwarding Information Base
  • This invention comprises an object-oriented and feature-rich caching to provide a short-cut handling for later packets received with the same source and destination addresses.
  • a separate cache exists for each network interface by containing cache objects in each forwarding engine (see for example next-hop cache object 241' and address cache object 243' in Fig. 3E) .
  • This invention provides a base class ACache which is protocol independent. Addresses are kept as unsigned long integers. ACache does not support management set static entries; it is strictly dynamic. ACache supports:
  • ACache has its own thread context. An entry is set in the cache in an interrupt service context. If it reaches a high-level mark for cache size, the ACache set entry procedure hits an internal event to wake ACache back up in thread context. It then allocates more memory for the cache. Likewise when its aging timer expires, ACache wakes up in thread context in its aging procedure and may choose to shrink the cache at that time if a low-level mark is reached.
  • Flushing the whole cache is a fast way to keep caches current when certain external management events occur; the alternative is to walk caches on all interfaces to check if the external management affected entries are in that cache
  • Individual network protocols may provide a class derived from ACache to (1) add protocol specific data to an entry and (2) supply the protocol-specific lookup routines.
  • the IP derived class is IPACache.
  • the IP forwarding engine methods (1) validate packet addresses, (2) filter against an access list, and (3) retrieve the next hop from the FIB. These procedures are inherently slow, so the results of these procedures once obtained, such as address validity, are cached and corresponding procedures are provided in IPACache to lookup the same results quickly.
  • IPACache thus supports three cache lookup procedures:
  • Each of these procedures is passed the source and destination addresses from a packet, hashes them and looks up entries linked in the "bucket" for that hash code. It checks each linked entry to see if it matches exactly both the source and the destination. If it finds a match it returns the entry data for that function. For the Martian lookup the address validity, yes or no, is returned. For access control lookup (see access list object 240' in Fig. 3E) an additional protocol and port parameter must be matched and permission, permit or deny, is returned. For next hop a quality of service parameter must be matched and the next hop is returned.
  • each protocol includes in the forwarding part of its protocol-specific MIB a table of entries keyed by interface number. Some of the leaves in an entry are associated with this packet caching. Each interface maintains its own cache. Individual entries in a cache are not MIB visible; these leaves concern the cache as a whole: whether or not it is enabled, the maximum size it will be allowed to grow to, how many entries are currently in that cache, the number of cache hits since the cache was enabled the number of cache misses since the cache was enabled.
  • routing applications allow network management to filter packets based on destination address, or on the combination of destination and source addresses. It is desirable that each interface of the router be able to maintain a separate set of filter instances - an access list. Most vendors use a linear mechanism and since the list must be checked for each packet being forwarded, throughput slows down linearly as the list gets larger.
  • This invention provides a mechanism by which the forwarding of network packets is subject to access control set by network management .
  • FAC Formal Access
  • Each interface may associate with one and only one access list as identified by an ID in the entry. This association is done in the forwarding part of a protocol's MIB via an ID leaf and a control leaf to enable or disable filtering.
  • FAC is a base class for all protocols' access control including IP, IPX, DECnet, Appletalk and for filtering routing protocols such as RIP. Each individual protocol derives its access list class from FAC.
  • access control consists of a table of entries. An entry begins with four common leaves managed in FAC: ID, Sequence, Matches and Permission. The first two index the entry instance and are unique to that entry.
  • ID The ID is the identifier which groups entries into a particular list. All lists reside in the same single tree for that protocol.
  • Sequence The sequence number keys the order of entries in a given access list. When filtering a packet, the first matching entry exits the filter check and a packet may match multiple entries, so order is important.
  • Matches This is a read-only counter of the number of times the entry has been matched during a filter() call since the entry was created.
  • the fir ⁇ t three layer ⁇ of the OSI reference model depict the physical 47, data link 46, and network 45 layer ⁇ .
  • Multiprotocol routers utilize this layering model to switch network layer packets between different data link and physical layer combinations, thereby allowing network layer protocols to run over a variety of communications facilities.
  • Framing Object ⁇ are provided to pre ⁇ ent a common interface between ⁇ tandard data link and physical media configurations and network layer protocol components.
  • Fig. 5 depicts the network layer and framing object component relationships against the OSI layer model.
  • the Framing Object components consist of the Framing Object Resource class 50 and the specific Framing Objects 51.
  • the Framing Object Resource cla ⁇ s 50 as ⁇ ists the network layer in determining platform specific configuration information as it pertains to media and interfaces found on the ⁇ ystem, and in the allocation of specific Framing Objects 51 to be employed by the network layer protocols 52 to receive and transmit network layer protocol data units on each network interface.
  • Framing objects are instantiated for each type of framing a protocol framing engine supports and are bound to the interface object to which the forwarding engine is attached.
  • Framing Object ⁇ are realized by deriving data link and media specific Framing Objects from a base Framing Object clas ⁇ .
  • the ba ⁇ e Framing Object cla ⁇ s provides methods: to allow the network layer protocol to register to receive network layer packets matching framing and protocol identifier criteria; to transmit network layer protocol data units; and to obtain information about the associated data link and physical layer ⁇ .
  • Standard data link framing format ⁇ and protocol identifiers are realized through specific Framing Object ⁇ .
  • Data link framing and media detail ⁇ are embedded in the Framing Objects to relieve the network layer from this knowledge.
  • methods are provided by the Framing Objects to obtain data link framing and media information in a generic manner, for example, to return the length and value of a data link physical addre ⁇ , obtain the length of a data link header, or obtain the media MTU.
  • Framing Objects are requested from the Framing Object Resource class when the network layer protocol components are instantiated over system interfaces to service and forward network layer packets (see framing object 242' in forwarding engine 234' of Fig. 3E) .
  • the network layer protocol assumes nothing about the nature of the media associated with a system interface and requests Framing Object ⁇ for each of the framing format ⁇ that are supported by the protocol.
  • the Framing Object Resource class construct ⁇ and return ⁇ only valid framing format ⁇ as determined by the media associated with the requested interface. Framing Objects are bound to the interface and media drivers when they are constructed.
  • FIG. 5 shows how IP network layer protocol 52 supports framing standards for operation over ethernet 55 and token ring 54 media, via media drivers 53. From a framing point of view for these media, IP supports Ethernet Version 2 and 802.2 LLC with SNAP framing. When instantiated over an interface, the IP network layer will request Framing Objects for both of these framing standards. When instantiated over an ethernet interface two Framing Objects will be allocated: an Ethernet Version 2 Framing Object and an 802.2 LLC with SNAP Framing Object; when instantiated over a token ring interface, only an 802.2 LLC with SNAP Framing Object will be allocated. The ethernet
  • the network layer protocol can select and use any of the allocated Framing Objects to register to receive and transmit network layer packets.
  • Framing Object instances returned from the Framing Object Resource cla ⁇ s can be used by the network layer protocol to simultaneously support all valid framing formats for a specific media. Dynamic teaming of network stations and associated framing formats can be achieved.
  • the IP network layer protocol may be communicating with two IP stations on a directly connected ethernet segment using Ethernet Version 2 framing for one IP station and 802.2 LLC with SNAP framing for the other.
  • the Framing Object is retained in the ARP cache along with the MAC layer physical address to allow the IP network layer to map a framing format, as well as, a physical address to an IP station.
  • routing consist of multiple tasks or threads of control
  • applications are driven by events, and require a scheduling mechanism to distribute the processor effectively among the threads of control - i.e., to dynamically reschedule threads based on events asynchronous to the running thread such as the arrival of a packet on the network or the expiration of a timer.
  • a scheduling mechanism to distribute the processor effectively among the threads of control - i.e., to dynamically reschedule threads based on events asynchronous to the running thread such as the arrival of a packet on the network or the expiration of a timer.
  • This event-based re ⁇ cheduling of thread ⁇ i ⁇ provided by the operating ⁇ y ⁇ tem.
  • An event funnel which allows a- thread to wait on multiple events simultaneously in one place, greatly simplifies the architecture of the thread code.
  • Applications written over major operating sy ⁇ tem ⁇ ⁇ uch a ⁇ UNIX have ⁇ uch ⁇ upport, i.e., the ⁇ elect() ⁇ y ⁇ tem call in 4.3BSD UNIX or the poll() ⁇ ystem call in System V.
  • This invention provide ⁇ for an object-oriented event funnel by organizing the ab ⁇ traction of an event into a ba ⁇ e class RtrEvent.
  • Various event types ⁇ uch as packet arrival or timer expiration, may then be defined a ⁇ cla ⁇ es derived from RtrEvent. For example, packet arrival is modeled through a socket class derived from RtrEvent - ⁇ ee Fig. 6.
  • RtrEvent has a public procedure wait() which blocks the thread and a procedure hit() which flags the operating system to reschedule the associated thread. To wake up a thread blocked waiting on a given RtrEvent, that RtrEvent mu ⁇ t be hit by a different running thread or an interrupt service routine.
  • a raw RtrEvent can be used for IPC (InterProces ⁇ Communication).
  • Each RtrEvent is assigned a unique identifier when constructed and contains a void pointer to carry user data through the event.
  • a thread 35 may wait directly on a single RtrEvent or associate a set of RtrEvents with an event funnel and wait collectively. The funnel i ⁇ cla ⁇ RtrMultiWait.
  • RtrMultiWait 36 provides an add() procedure to add a RtrEvent to it and keeps the RtrEvents 37a-d on a linked list. It likewise provides a removeO to disas ⁇ ociate a RtrEvent.
  • a thread may in ⁇ tance a RtrMultiWait and wait in one place on multiple RtrEvent ⁇ .
  • the ⁇ e may be raw RtrEvents or derived objects in any combination.
  • RtrMultiWait itself contains its own event and has a mwait() procedure which blocks its thread on its event. When an as ⁇ ociated RtrEvent i ⁇ hit, that hit ⁇ the RtrMultiWait as well. When control resumes in the thread returning from the mwait() call, the hit RtrEvent is returned.
  • mwait() presents the highest priority RtrEvent.
  • the next mwait() call does not block but returns immediately with the next highest priority RtrEvent.
  • mwait() return ⁇ them in order of occurrence.
  • mwait() doe ⁇ not always return immediately even though it has one or more RtrEvents in a hit state. This is because it checks before returning with another clas ⁇ , RtrSlice, to a ⁇ ure the funnel's thread has not exceeded a configurable time quantum, defaulted for example to 0.4 seconds. If exceeded, RtrSlice returns control to the operating system scheduler to reschedule the thread. Without RtrSlice, the threads are not preempted and mu ⁇ t share the processor equitably among themselves. RtrSlice as ⁇ ists in this regard because it can be called freely without penalizing the calling thread. If the quantum has not been exceeded, RtrSlice does nothing but return. Since many threads are built around an mwait() call, a lot of the sharing problem is solved by thi ⁇ ⁇ ingle u ⁇ e of RtrSlice. B.5.2 RTimer
  • Thi ⁇ invention further provide ⁇ for efficient queuing of timers.
  • a timer is an important type of event and is embodied by RTimer, a clas ⁇ derived from RtrEvent.
  • Individual component ⁇ of the communication device may further derive component specific timers from RTimer.
  • the granularity of timers is, for example, 0.1 seconds.
  • RTimer's start() procedure inserts it on the timer queue with a given delay until expiration. When the time expires the timer queue sounds the alarm which means the RTimer's base cla ⁇ s RtrEvent hit() is called.
  • RTimer may be constructed as a one-shot timer or as a cyclic timer which i ⁇ rearmed automatically on the timer queue after its alarm is sounded. A parameter "count" keeps track of how many times have passed before the timer is re ⁇ tarted. The period of the cyclic timer may be different from the initial alarm time.
  • RTimerQ i ⁇ To tick timer ⁇ down efficiently and ⁇ ound their alarm ⁇ , cla ⁇ RTimerQ i ⁇ provided.
  • RTimers 38a, 38b are as ⁇ ociated with it when started.
  • the RTimerQ links the RTimers onto it in order of alarm time so that it only needs to look at the head of the queue to see if a timer has expired.
  • RTimerQ runs off a single operating system primitive which ticks in a clock interrupt service routine every 0.01 seconds, for example. It checks the head of the queue and if there i ⁇ work to do it hits its own event to reawaken in thread context and process the queue. Thus it hits the expired timers in a thread context (of very high priority), not in the time critical interrupt context.
  • Rtimer has a start() procedure to insert it into the RTimerQ queue as well as stop( ) to remove it.
  • RTimer also provides a startx( ) and stopx() to start and stop timers from interrupt service code. These routine ⁇ simply put the timers on a critical path linked list and hit the event associated with RTimerQ. When RTimerQ wakes up in thread context, it unhooks the critical path linked list and inserts each RTimer into the queue in alarm-time order.
  • Routing Protocol Objects provide the autonomous functionality required for topology exchange protocols to function. Topology exchange protocols discover adjacencies (neighbors), advertise network reachability, synchronize their databases, and perform best-path determination.
  • the base object classes provide a common set of services that are protocol-independent. Specific Routing Protocol derived classes automatically get the same behavior and control for any protocol.
  • the Routing Protocol Object framework embeds (or distributes) the required objects into the Routing Protocol Object itself. In this way, the Routing Protocol is self-sufficient in that it has its own configuration, and system service ⁇ , a ⁇ well a ⁇ it ⁇ object functionality (e.g., adverti ⁇ e route ⁇ , apply ⁇ plit-horizon, update FIB, etc.). Specifically, the embedded object ⁇ are ( ⁇ ee Fig. 3C) :
  • Routing Protocol Thread 220' - Thi ⁇ object give ⁇ proce ⁇ context under which to run the topology exchange functions.
  • Routing Table 223' This object gives an AVL-tree table for maintaining the network map. This table can grow arbitrarily in size.
  • Network Interface Table 224' This object provides protocol-specific configuration information for each attached network interface.
  • Event Object 221' - This provides its own event definition capabilities within the Routing Protocol
  • Routing Protocol threads rely on events for processing advertisements and maintaining the network maps.
  • Timer Object 222' This provide ⁇ it ⁇ own timer derived objects within the Routing Protocol Object. Common times are defined for periodic advertisement and link-state updates.
  • This Routing Protocol Object provides for distance-vector protocols; however, objects for supporting link-state protocols could similarly be provided.
  • Another aspect of this invention is the use of an object-oriented ⁇ y ⁇ tem of computer code for local and remote device management.
  • This system has the advantage of modular decompo ⁇ ition which simplifies the implementation of existing and future device management functionality. Specifically, it provides:
  • the ⁇ e include the encoding and decoding of management protocol packet ⁇ and the use of the types as Managed Object ⁇ themselves.
  • Class A logically grouped set of data and the function ⁇ that operate on them.
  • derivation Without changing a cla ⁇ , derivation adds and/or augments thi ⁇ cla ⁇ to perform additional or different functionality.
  • the original set of code may limit the ability or extent to which it may be augmented (see class).
  • Managed Object A piece or table of data in the Management Information Base.
  • MOF Managed Object Framework the underlying sy ⁇ tem of communications device management.
  • MIB Management Information Base a database of manageable information about a device. It is described in RFC 1156.
  • Object Identifier A series of number ⁇ which uniquely identifie ⁇ a piece or group of data in the Management Information Ba ⁇ e. Often abbreviated OID.
  • RFC Request For Comments a document of the Internet Engineering Taskforce (IETF) sy ⁇ tem of standards.
  • An RFC (request for comment) is a published document which can be obtained by contacting the RFC editor at USC/Information Sciences Institute, 4676 Admiral Chief Way, Marina Del Rey, California 90292-6695, USA.
  • FIG. 7 A graphical representation of the MOF is shown in Fig. 7.
  • the MOF 60 is broken down into five separate components:
  • Core Object ⁇ 61 including SMI Type Objects 63 and Table Objects 64 • Managed Object Ba ⁇ e Class 62 MIB Object 65
  • the MIB Object 65 provides the mapping of an Object Identifier (which uniquely identifies a piece of data in the Management Information Base) with a particular Managed Object. It then takes advantage of the Managed Object Ba ⁇ e Class standard interface to retrieve the actual data held in the Managed Object.
  • the Core Objects 61 represent a set of objects u ⁇ ed by the entire MOF. These include one object for each of the nine basic types defined in the SMI: INTEGER 67, OCTET STRING 68, NULL 69, OBJECT IDENTIFIER 70, IPAddres ⁇ 71, Counter 72, Gauge 73, TimeTicks 74, and Opaque 75. Each of these object ⁇ encompas ⁇ the functionality and valid states described in the SMI, a ⁇ well a ⁇ additional functionality u ⁇ eful to the code which u ⁇ e ⁇ these types.
  • Other Core Objects include Table Objects 64 for holding the data for Managed Object tables.
  • the Managed Object Base Cla ⁇ 62 provide ⁇ a ⁇ tandard method of acce ⁇ to specific Managed Objects 66. Any object which derive ⁇ from thi ⁇ ba ⁇ e cla ⁇ s need only customize a small amount of code to allow this ⁇ tandard acce ⁇ , which the MIB then take ⁇ advantage of in obtaining the object's data.
  • the Specific Managed Objects 66 are data types that are multiply derived from the Core Objects 61 and the Managed Object Base Class 62 to encompass the functionality of each.
  • an Integer Managed Object contains the integer functionality derived from the INTEGER Core Object 67, as well as the manageability derived from the Managed Object Base Class 62.
  • a designer simply needs to provide the value of the integer (or information on how to obtain the value) and a unique Object Identifier. This requires relatively little new code to accomplish.
  • the MIB Object 65 is then able to acces ⁇ the Managed Object in a standard way. Managed Object Tables are also created in thi ⁇ way. The following is an enumeration of the specific Managed Objects:
  • the MIB may be acce ⁇ sed in four ways: Get, Get-Next, Set, Set-Validate.
  • a Get operation require ⁇ a complete Object Identifier.
  • the MIB will map the Object Identifier to a Managed Object (if one exists with that Identifier) and call that object's Get command to retrieve the information.
  • An error is returned if the Managed Object with that identifier does not exist.
  • a Get-Next operation may take a non-exi ⁇ tent, complete, or partial Object Identifier and will map it to the next numerically highest complete Object Identifier that exists in the MIB. Again, the MIB will then call that object's Get command. An error will be returned if there is no Managed Object numerically higher than the one specified.
  • a Set or Set-Validation operation requires a complete Object Identifier, type and value. They will map the Identifier the same way a Get operation does.
  • the Managed Object will be set if it is "writable," the type i ⁇ correct and the value provided is valid for that Object.
  • the Set-Validation operation makes the same checks as the Set, but does not actually change the value of the Managed Object. An error i ⁇ returned if a Managed Object with that identifier doe ⁇ not exist, the type is incorrect, or the value is incorrect or out of range.
  • the MIB also provide ⁇ an authentication service.
  • An authorization information object is sent with each MIB access command.
  • the device's authentication manager i ⁇ ⁇ ent the Object Identifier along with the authentication information object.
  • the authentication manager i ⁇ application ⁇ pecific to allow any device to specify its method of authentication.
  • the Managed Object may be acces ⁇ ed by the Get command and, if the object i ⁇ writable, by the Set and Set-Validate command ⁇ .
  • the Managed Object may be acces ⁇ ed by the Get command and, if the object i ⁇ writable, by the Set and Set-Validate command ⁇ .
  • one mu ⁇ t specify if the object is read-only or read-write, the user must provide methods to check the type, to ' check the value, and to set the value of the object. This is the minimum of functionality one must provide for a Managed Object. Additional functionality includes specifying (on a Set command) that a new value should be stored in non-volatile memory and retrieved at the beginning of device execution. Thi ⁇ is specified upon return from a Set command.
  • the Managed Object Base Clas ⁇ When the Managed Object Base Clas ⁇ receive ⁇ a reque ⁇ t to store a value to non-volatile storage, it calls a device non-volatile memory manager with the Object Identifier, type and value (see Fig. 9 and section D.3 below). At the beginning of device execution, all Managed Object values are restored through calls to the MIB a ⁇ if Set command ⁇ were called for tho ⁇ e object ⁇ .
  • Managed Object Table ⁇ interact with the Core Table Object ⁇ to provide ordered sets of information.
  • Each value in each entry of the table may be considered the value of a managed object for a particular table index.
  • the index is extracted from the Object Identifier (in a manner specified in the specific Managed Object), the Core Table Object is asked to look up an entry with this key, and the value is extracted and returned from the entry.
  • the Set command work ⁇ the ⁇ ame way, except the entry index Managed Object Table ⁇ may al ⁇ o ⁇ pecify that they ⁇ hould be saved to non-volatile memory after a Set command.
  • contra ⁇ t to the non-tabular object ⁇ entire table entries are restored at the beginning of device execution using the Core Table Object' ⁇ add command,
  • a ⁇ econd type of Managed Object Table allow ⁇ table entrie ⁇ to be added and deleted. This is accomplished through the convention of specifying one indexed Managed Object as an entry control. Setting thi ⁇ entry control object to different value ⁇ allow ⁇ the entry to be added or removed from the Core Table Object.
  • the ⁇ aving of entrie ⁇ of this kind to non-volatile memory work ⁇ the same as the table object described above, with the addition of allowing entries to be removed from non-volatile memory when the entry is removed from the Core Table Object.
  • the MIB is structured as a tree 80 of MIB nodes 82-89, with each node repre ⁇ enting an identifier in the Object Identifier (OID) .
  • Managed Object ⁇ 84, 86, 89 are placed at the leaf node ⁇ . If one wishes to acces ⁇ the MIB to Get the Managed Object named by "OID A”, "OID A" would have to be ⁇ pecified exactly.
  • a Get-Next on "OID D" would al ⁇ o get the information for "OID A”, becau ⁇ e a Get-Next will return the next Managed Object leaf after the OID specified. If one does a Get-Next on the Managed Object named by "OID A”, the information would be returned from the Managed Object specified by "OID B,” and so on.
  • MIB asks the leaf Managed Object for its information, an acce ⁇ authentication is made. If the acces ⁇ for the operation is invalid, a Get, Set, or Set-Validate will return a non-existent OID error, while a Get-Next will move past a leaf Managed Object to the next in the tree.
  • the Managed Object Ba ⁇ e Cla ⁇ s provide ⁇ the following interface (in C++ code):
  • the GET, GETNEXT, SET, and SETVALIDATE are the functions repre ⁇ enting the acce ⁇ methods described above.
  • the mo_get function is called by the GET and GETNEXT access functions to return the information for a ⁇ pecific leaf in the MIB tree.
  • the get_in ⁇ tance functions validate ⁇ the Object Identifier for the GET and GETNEXT function ⁇ . If more than one MIB leaf i ⁇ repre ⁇ ented by thi ⁇ Managed Object, get in ⁇ tance will al ⁇ o update the Object Identifier to repre ⁇ ent the "next" leaf when called by GETNEXT.
  • the mo_ ⁇ et function is called by SET to store new information for a particular leaf and depending on the return value save new information to non-volatile storage.
  • the set_validate function is called by both SETVALIDATE and SET to validate the value's Object Identifier, type and value.
  • the get_ ⁇ tatu ⁇ i ⁇ called by both SETVALIDATE and SET to a ⁇ sure the Managed Object is not read-only.
  • Each specific Managed Object provides the routine ⁇ nece ⁇ ary for it ⁇ particular leaves and read-write status.
  • the SET will call a specific Managed Object's mo_set function and, depending on the return value, ⁇ ave it to non-volatile memory.
  • the SET function interact ⁇ with a system called the Persistent Object Manager.
  • a Persistent Object Manager 77 is created and interacts with a Non-Volatile Memory Manager 76 to build a table mapping Object Identifier ⁇ with "handle ⁇ " for retrieval and storage of Per ⁇ i ⁇ tent Objects.
  • Each specific Managed Object which is persistent is then created and calls the Persi ⁇ tent Object Manager to re ⁇ tore its values through the standard Managed Object Base Cla ⁇ .
  • the Managed Object SET function 78 will call the Persistent Object Manager 77 to store the value.
  • the Persi ⁇ tent Object Manager will u ⁇ e it ⁇ e ⁇ tabli ⁇ hed "handle" to update the non-volatile value. If an object ha ⁇ not been stored previously, the Persistent Object Manager 77 ask ⁇ the Non-Volatile Memory Manager 76 for a new handle (identified by the object' ⁇ Object Identifier).
  • the NVRAM File Sy ⁇ tem overlays a simple file sy ⁇ tem ⁇ tructure over the Non-Volatile Storage.
  • the file system allows tagging of blocks by object identifiers. This allow ⁇ every object to automatically fit into the file system hierachy since every object, by definition, has a different object identifier assigned out of the global MIB naming tree.
  • the MIBs provide the ability to configure, monitor, and control routing applications at both the system level and the network interface level.
  • the system level provides control at the device level where global parameters for the applications or services can be set.
  • the network interface level provides control where the applications or ⁇ ervices attach to the network. This is key for network specific parameters that may vary from network to network.
  • the MIBs use default parameters a ⁇ much as po ⁇ ible to allow the minimum amount of u ⁇ er configuration before the device is operational .
  • Routing Service ⁇ provide ⁇ the ability to "di ⁇ cover" which routing application ⁇ and component ⁇ are in a device. Since device ⁇ ⁇ upport a variety of network services and applications, it is e ⁇ sential for management applications and network users to be able to determine the particular capabilities of any device. Any device providing Routing Service ⁇ will contain an entry in its Chas ⁇ i ⁇ MIB showing the availability and version of the Routing Services. This is basically a "table of contents" for what applications are in the device, with only one entry for Routing Services. The entry specifie ⁇ a high-level router MIB ("ctRouter") used to control the entire Routing Service ⁇ regardle ⁇ of which routers are actually in the device.
  • ctRouter high-level router MIB
  • the ctRouter MIB provides the ability to determine the administrative and operational ⁇ tatu ⁇ (including uptime) for any router and component without having to u ⁇ e any of the individual router MIBs. However, for any specific protocol or configuration control, the individual router MIBs must be used.
  • Fig. 10 illustrates the basic management model, with chassis MIB 110 above the ctRouter MIB 111, and each of the individual routing protocol MIBs 112-115 below.
  • each MIB uses a common MIB template.
  • Each individual router MIB is defined with the same set of managed objects.
  • Thi ⁇ provide ⁇ a con ⁇ i ⁇ tent external view of each individual router application. Because of the common object model, some managed objects may not have any meaning or direct application in a particular router protocol configuration. In instance ⁇ where thi ⁇ occurs, the object is completely vi ⁇ ible and manageable, but ha ⁇ no effect on the operational behavior of the router or the particular protocol.
  • Fig. 11 illu ⁇ trate ⁇ the functional group ⁇ common to all of the individual router MIBs.
  • the "root” protocol defines the network protocol router that is being managed, e.g., IP.
  • MIB defines the ver ⁇ ion of the router MIB.
  • Component ⁇ define ⁇ the ⁇ et of component group ⁇ that comprise a router group, i.e. , :
  • Router Sy ⁇ tem Group - contains the object ⁇ that pertain to routing ⁇ ervice ⁇ at a global, device-wide level .
  • Forwarding Group - contain ⁇ the managed object ⁇ u ⁇ ed to setup and configure the network protocol's router ports for packet forwarding as well a ⁇ the aggregate and per interface IP packet forwarding counters.
  • Topology Group - contains the managed object ⁇ for the routing and service advertisements of the router.
  • the ⁇ e managed object ⁇ allow for routing agents and service agents to be controlled and monitored on a system wide as well as a router port basi ⁇ .
  • Di ⁇ tantVectored and LinkState are the types of topology groups defined.
  • Forwarding Information Base (FIB) Group - contains the managed objects for the forwarding table. This table i ⁇ built from entrie ⁇ in the network protocol's routing table(s) and reflects the routes that are considered the best routes for forwarding.
  • FIB Forwarding Information Base
  • End Systems Group - contain ⁇ the managed objects which control the Address Resolution Protocol (ARP) which maps host addresses to physical addresses for each router port.
  • ARP Address Resolution Protocol
  • Event Group - contains the managed object ⁇ pertaining to event logging.
  • the component MIB view varies depending on the actual component being managed.
  • Each part (branch) has a common management view a ⁇ shown in Table 1.
  • OperationalStatus(2) - shows the operational statu ⁇ of the component.
  • OperationalTime(4) indicate ⁇ the amount of time that the component ha ⁇ been in it ⁇ current operational state.
  • Common Sy ⁇ tem Aggregate Counter ⁇ show the total byte and packet count ⁇ on all router port ⁇ of packet ⁇ received, ⁇ ent, di ⁇ carded, and filtered. Some of the group ⁇ have additional counter ⁇ . All ⁇ y ⁇ tem counter ⁇ groups have the ability to enable/disable the counter ⁇ on all ports and to reset counters to zero.
  • OperationalStatus(3) show ⁇ the actual ⁇ tatu ⁇ of thi ⁇ component's interface.
  • 0perationalTime(4) - indicates the amount of time that this component's interface has been in the current operational state.
  • Objects in the Common Counters Interface Table show the total byte and packet counts on a router port of packets received, sent, discarded, and filtered. Some of the group ⁇ have additional counter ⁇ . All interface counter ⁇ group ⁇ have the ability per port to enable/di ⁇ able the counters and to reset counters to zero.
  • the common forwarding group MIB follow ⁇ the common component view with the exception of an Addre ⁇ Table ( ⁇ ee Table 2). If nece ⁇ ary, each protocol ⁇ pecifically define ⁇ an address table. For example, DECnet does not require configuring an address per port and so the addres ⁇ table group i ⁇ not pre ⁇ ent.
  • the Aggregate Counters and Counters Interface Table for the forwarding group follows the structure of the basic counters groups with the addition of host in/out, error, and number forwarded counters.
  • the Config Interface Table for the forwarding group follows the basic structure of all other interface tables with the following added leaves.
  • MTU(6) - determines size of packet to be sent.
  • FramingType(8) - Identifie ⁇ the type of framing to be used.
  • the Aggregate Counter ⁇ and Counter ⁇ Interface Table for the forwarding group follow ⁇ the ⁇ tructure of the ba ⁇ ic counter ⁇ group ⁇ with the addition of ho ⁇ t in/out, error, and number forwarded counter ⁇ .
  • the common topology group MIB follow ⁇ generally the common component view, as shown in Table 3.
  • Table 3 Topology Component Group(4)
  • the Sy ⁇ tem Config branch for the topology, Di ⁇ tantVectored group maintain ⁇ the common ⁇ y ⁇ tem config view with the following added leaves:
  • Thread Priority (7) - ⁇ pecifie ⁇ the run-time execution priority of this routing protocol agent.
  • Threshold (8) Specifies the number of RIP entrie ⁇ that can be held in the routing protocol ' ⁇ route table.
  • the Config Interface Table for the topology, Di ⁇ tant Vectored group follows the basic structure of the common config interface tables with the following added leaves. • Ver ⁇ ion (5) - Protocol revision level.
  • Advertisements (6) Periodic rate for sending routing Advertisement Updates.
  • the Counter ⁇ Interface Table for the topology group follow ⁇ the structure of the common counters group ⁇ with the addition of host in/out, error, and number forwarded counter ⁇ .
  • This section describes the consi ⁇ tent manner in which re ⁇ ources within the router services are managed.
  • the intention of the common resource model allows for easy implementation of routing protcols and provides a scalable and portable implementation of the routing services.
  • a BaseResource 116 is the most ba ⁇ ic component of a router resource. It is a base class object that has built-in management functions and state ⁇ .
  • the common MIB router template is a collection of BaseRe ⁇ ource components laid out in a consistent and formal manner.
  • a ResourceTable 117 i ⁇ a MIB manageable table of Ba ⁇ eRe ⁇ ource object ⁇ . Each Ba ⁇ eRe ⁇ ource object represents a service, component, or interface object. Almost all BaseResource ⁇ are registered into one of these tables for management purposes.
  • a RscEntry 118 defines an entry of the ResourceTable, e.g., handle or interface number, index, flags, admin status, BaseRe ⁇ ource pointer .
  • BaseResource is the fundamental building block of the common router object model. It is respon ⁇ ible for maintaining the ba ⁇ ic admini ⁇ trative and operational ⁇ tates of the component. Any Ba ⁇ eRe ⁇ ource component ⁇ that were instantiated by this component are handled appropriately if the ⁇ e ⁇ tates change. That is, if the administrative state change ⁇ from enabled to di ⁇ abled, the component will deactivate and all Ba ⁇ eRe ⁇ ource component ⁇ that were created by thi ⁇ resource are deactivated as well. This allow ⁇ management to be done at any level and trickle down to the lowe ⁇ t resource. Not all resources are manageable through a MIB. The actual manageability of this resource may be defined within the common MIB template. State changes can also occur from internal events or indirectly when a parent resource state has changed.
  • a Ba ⁇ eResource is a clas ⁇ object in which mo ⁇ t router component ⁇ are derived. It i ⁇ comprised of these attribute ⁇ , as illustrated in Fig. 13:
  • Root Clas ⁇ 119 A resource that has no parent and registers with no particular resource table. A starting point for the entire resource tree.
  • Service Cla ⁇ 120 A re ⁇ ource that provide ⁇ a system wide service like Host-Delivery or a network protocol like IP and IPX. These resource ⁇ regi ⁇ ter with a service resource table and are children to some root re ⁇ ource.
  • Network ⁇ ervices have a combined MIB template defined.
  • Component Cla ⁇ s 121 A resource that is a component of a service re ⁇ ource and registers into a component resource table. Most Component clas ⁇ re ⁇ ources within the router have a common MIB template defined.
  • Interface Cla ⁇ 122 A resource that is created on each interface that the device has. For each MIB-II interface defined in the router device, an interface resource exist ⁇ for thi ⁇ component. This resource registers into an interface resource table.
  • Fig. 14 An example of a BaseResource Hierarchy for IP and IPX protocols is illustrated in Fig. 14; the resource objects are numbered in a similar manner as in Fig. 13 with the suffix "a" for IP Resources, and "b" for IPX Resource ⁇ .
  • Thi ⁇ item reflects the current operational ⁇ tatu ⁇ of the resource. This is the result of a management change to admin ⁇ tatu ⁇ or some other internal event that may have occurred.
  • BaseResource components contain pointers to their parent resource and to their respective component table and interface table (if they have one). By using these pointers, resource ⁇ can retrieve u ⁇ eful information from the parent and sibling resources a ⁇ well a ⁇ control the interface re ⁇ ources from the interface resource table. Also maintained is the component handle number. As BaseRe ⁇ ource ⁇ instantiates other BaseResource ⁇ , thi ⁇ handle i ⁇ incremented and retrieved and as the children BaseResources register into their appropriate resource table, the parent's current handle number is used a ⁇ the handle id or component index.
  • Network Protocol Type is a routable protocol like IP, IPX, and DECnet. This type ha ⁇ a common MIB template defined.
  • Config Type addre ⁇ ing component resource consists of the protocol's network addre ⁇ s table or sy ⁇ tem wide network addre ⁇ s.
  • FIB Type - Thi ⁇ resource is a forwarding information base. Most network protocols have them and are used by the forwarding engine ⁇ to lookup the next hop interface of of a given network addre ⁇ . Routing protocol ⁇ u ⁇ e the FIB to depo ⁇ it their best next hop interface of a given network addres ⁇ . The ⁇ e addre ⁇ e ⁇ are learned dynamically through protocol ⁇ . There is no common MIB template for thi ⁇ type.
  • FAS Type - This resource is forwarding engine (service and forward).
  • a protocol creates a FAS object for each interface it is configured on.
  • a FAS receives a packet from an interface, validates its contents, then calls the FIB to resolve the next hop interface to send it out on.
  • FAS objects that are of clas ⁇ Interface are created and managed by a parent also of type FAS. This type has a common MIB template defined.
  • ARP Type - This is an ARP resource
  • ARP Addre ⁇ ing Resolution Protocol
  • Routing Protocol Type The routing protocol resource is a resource that runs in thread context. It takes on routing protocol attributes defined in the routing protocol, the di ⁇ tant vectored, and link state base cla ⁇ e ⁇ . They contain an interface table of routing protocol object ⁇ of the ⁇ ame type as well as a topology database, and counters.
  • the following information is useful for Root, Service, and Component cla ⁇ re ⁇ ource ⁇ .
  • the ⁇ e re ⁇ ource item ⁇ are needed when management need ⁇ to get thi ⁇ information for the common MIB template.
  • Resource Name A resource can Name its service or component.
  • BaseResource pointer Once a BaseResource pointer is located, all information described above is accessible for management through public methods.
  • the main acce ⁇ function ⁇ of a Ba ⁇ eRe ⁇ ource are called by the parent BaseRe ⁇ ource. These functions are:
  • a BaseResource is constructed with a MIB enterprise id, default admin status, cla ⁇ of resource, type of resource, and pointer to the it ⁇ parent Ba ⁇ eResource.
  • Activation Thi ⁇ i ⁇ called when a component's admin statu ⁇ i ⁇ a ⁇ enabled through management and al ⁇ o at ⁇ tartup time if the component i ⁇ defaulted to enabled.
  • the ⁇ tartup time activation allows the resource to perform resource activation after all other resource ⁇ have been created in the device.
  • the re ⁇ ource first allows its own activation, then it propagate ⁇ the activation to child Ba ⁇ eRe ⁇ ource ⁇ by performing a TableActivate on all re ⁇ ource table ⁇ that it contain ⁇ .
  • Deactivation Thi ⁇ i ⁇ called when a component's admin statu ⁇ is disabled through management or via some internal event. When deactivation occurs, the resource first allows its own deactivation, then it propagate ⁇ the deactivation to child Ba ⁇ eResources by performing a TableDeactivate on all resource tables that it contains.
  • Reconfiguration Thi ⁇ i ⁇ called when an internal re ⁇ ource event occurred within the root, ⁇ ervice or component level. When reconfiguration occurs, the re ⁇ ource fir ⁇ t allow ⁇ the re ⁇ ource to reconfigure, then it performs a reconfiguration on all resource that it contains.
  • Service Re ⁇ ource Table 123 i ⁇ a manageable, read-only table under the ctRouter-MIB.
  • a ⁇ ⁇ ervice BaseResource ⁇ 120 are created, they register their resource pointer and handle id with their proper service ResourceTable.
  • a ⁇ Component Ba ⁇ eResources 121 are created by their parent Service resource, they register their resource pointer, handle id, and component index with their proper component ResourceTable, and al ⁇ o with the interface Re ⁇ ourceTable.
  • Interface Re ⁇ ource Table 125 i ⁇ a manageable table under the Service's MIB. As interface BaseResource ⁇ 122 are created, they regi ⁇ ter their re ⁇ ource pointer and interface number into their parent' ⁇ component Interface ResourceTable. Service and Component ResourceTable ⁇ are table ⁇ that are created by the Root level Ba ⁇ eRe ⁇ ource. Interface Re ⁇ ource Tables are created by component resources when needed. F.9 Resource Table Description
  • the ResourceTable serves two purpose ⁇ : (1) it provide ⁇ an ordered list of BaseResource ⁇ of the same clas ⁇ es so that they can be initialized, activated, deactivated, reconfigured, and destroyed in a consi ⁇ tent manner; and (2) they are manageable either by the ctRouter-MIB for Component and Service type table ⁇ and by the network protocol MIB for interface tables.
  • Service Class - either a network protocol table or system service ⁇ table instanced by a handle id as ⁇ igned by a root level Ba ⁇ eResource.
  • Thi ⁇ instance is used as a handle for the protocol's component resources.
  • Thi ⁇ table i ⁇ defined a ⁇ a read-only MIB.
  • Component Class - a component resource table, under a service, instanced by the parent's service handle id and a component index.
  • the index i ⁇ the handle id of the component re ⁇ ource a ⁇ igned by the service resource.
  • Thi ⁇ table i ⁇ defined as a read-only MIB.
  • Interface Class - an interface table instanced by logical interface number as defined by MIB-II.
  • One RscEntry is created per interface and added to the table.
  • the table size equals the number of interfaces on the device.
  • This table is a MIB manageable and defined in the protocols service MIB. New entries to this cannot be added through the MIB.
  • the interface table entries can be extended to manage additional parameters that are specific to the type of resource.
  • the common MIB template defines those interface tables and their additional leaves.
  • network protocol services like IP, IPX and DECnet are created, they register their resource pointer and handle id into thi ⁇ table.
  • Router Component Resource Table 127 is a manageable, read-only table under the ctRouter-MIB.
  • a ⁇ Component Ba ⁇ eRe ⁇ ource ⁇ are created by their parent Service re ⁇ ource, they register their resource pointer, service handle id, and component handle id with the Router Component ResourceTable.
  • the router template define ⁇ a base framework for any router protocol. E ⁇ entially the router template i ⁇ compri ⁇ ed of a set of functional models that network protcols follow to implement their protocol. Each template define ⁇ a functional implementation and common MIB template as well. All templates illu ⁇ trated in Fig. 17 and described below are object-oriented C++ classes that are derived from BaseRe ⁇ ource.
  • ProtocolResource is a base cla ⁇ that define ⁇ the functional implementation of a network protocol.
  • Thi ⁇ Re ⁇ ource coordinates the creation of the component template classes in an orderly way and implements a System Admin MIB so that the network protocol can be managed. It also is a central point that can facilitate reconfiguration events.
  • Component Template Classes
  • Ba ⁇ e Config define ⁇ the functional implementation for configuring and accessing the network address per interface.
  • Interface Resource ⁇ is a ba ⁇ e clas ⁇ that defines the functional implementation of an interface object. Performance counters of packet ⁇ in/out and byte ⁇ in/out are maintained in this resource. Access to the interface number and certain interface states (like routing on/off) is accessed here.
  • This visual display mechanism allows a user to view and control the router resource tree (all router objects) with the semantics of a file system.
  • Object containers are treated as directories while individual object ⁇ are treated a ⁇ a file.
  • Thi ⁇ allows complete acce ⁇ s into the communication ⁇ y ⁇ tem without explicit knowledge of communication/networking component ⁇ . A user can start a root for example and peruse until the correct object (file) is provided. Note: thi ⁇ i ⁇ in ⁇ ide an embedded system with no file sy ⁇ tem.
  • the MIB Navigator ⁇ implifie ⁇ the manner in which a network administrator manages a networking device. It provides a line-oriented command line interface which allows the user to quickly browse a device's current configuration, as well as giving the user a more flexible and user-friendly interface to operate with. This interface provides a textual representation of the device's internal configuration database, allowing the user to be able to read or change the configuration of the device with little or no documentation.
  • the MIB Navigator provides its command line interface by operating a conceptual level above the Simple Network Management Protocol (SNMP) .
  • SNMP operates by passing requests to a device's internal database, the Management Information Base (MIB) .
  • MIB Management Information Base
  • the form of these requests are composed of queries to an object within that databa ⁇ e, by u ⁇ ing the object' ⁇ identifier (OID), which is unique to that object within the database.
  • OID object' ⁇ identifier
  • the ⁇ e OID's are composed of a string of numerals (i.e., 1.3.6.1.2.1.1.1.0), making them difficult to understand or work with from a user's standpoint.
  • the MIB Navigator simplifies the format of these reque ⁇ t ⁇ by providing a textual repre ⁇ entation to the ⁇ e OID' ⁇ , which are ea ⁇ ier for the u ⁇ er to dige ⁇ t than a string of numerals.
  • the MIB Navigator al ⁇ o place ⁇ a "file ⁇ y ⁇ tem" type of hierarchy over the MIB.
  • Thi ⁇ hierarchical interface allow ⁇ the device' ⁇ router object ⁇ to be peru ⁇ ed, ju ⁇ t a ⁇ a u ⁇ er would navigate around in a computer's file ⁇ y ⁇ tem.
  • the u ⁇ er i ⁇ now able to roam around the MIB, as if it were a computer file sy ⁇ tem, and check on piece ⁇ of data, and make changes where necessary without even being required to know the object's identifier.
  • the user can change his/her current location (a "directory” in a file system) or he/she can examine the contents of an object (a "file” in a file sy ⁇ tem) .
  • the u ⁇ er may acce ⁇ a de ⁇ ired object by using its textual description, instead of its numerical identifier.
  • the textual representation of objects within the MIB is achieved by storing text strings, along with other data, for each object within the device.
  • text strings When an object is accessed, its corresponding text string is substituted for it ⁇ numerical identifier, to provide a seamles ⁇ interface to the object.
  • the requirement that the u ⁇ er make use of the numerical identifier for an object in the MIB is removed, allowing that user to use the more informative and intuitive text strings instead.
  • Fig. 18 the prior SNMP methodology of accessing a piece of data via the device's configured name is shown.
  • the user To access this data, the user must make a reque ⁇ t of the MIB, and give the object's identifier (i.e., 1.3.6.1.2.1.1.1,0).

Abstract

An object-oriented architecture for network layer routing is provided which distributes function and system behavior into autonomous router objects. By distributing these functionalities into each object, the services and data normally external to the object are imbedded or accessible within the object itself. In another sense, some objects are distributed across the network; e.g., a separate forwarding engine is provided at each network interface. In a preferred embodiment, each object has: (1) common, protocol-independent functions that are shared by all objects of that class; (2) their own configuration information; (3) accessibility through a router resource object for instantiation and control; (4) automatic persistence in NVRAM; (5) remote management capabilities; and (6) text names for navigation of a resource tree as a file system. These capabilities are in every object regardless of the specific protocol or application. This ensures a common architecture among many different systems/router components, a common method of control internally, a consistent order of instantiation and a common functional behavior.

Description

DISTRIBUTED AUTONOMOUS OBJECT ARCHITECTURE FOR NETWORK LAYER ROUTING
Field of the Invention
The present invention is directed to an apparatus and method for routing packets on a communications network, and more particularly to an object-oriented system which utilizes common protocol-independent base objects to instantiate protocol-specific objects and which distributes the critical function and system behavior into autonomous objects. The system supports multiple network and routing protocols, is manageable, and readily scales to new platforms, architectures and media technologies.
Background of the Invention
Intelligent hubs are becoming widely deployed in networks to provide network connectivity to access devices. Hubs that provide access into the network allow the distribution of access policies and connectivity to occur close to the end system attachment.
At the same time, network-level routers are being deployed on a large scale to connect together the distributed hubs. In the past, this network service was provided by centralized router devices, as shown in Fig. 1A. However, as the centralized router's bandwidth and number of physical network interfaces become saturated, it is costly to add incremental distributed service. Once at capacity, it is necessary to add another centralized multi-port router even if the expansion only requires one new LAN to be attached - i.e., increments to the LAN access ports are done in large step functions.
To allow more scaleability, the router functions have been integrated into distributed hubs. As shown in Fig. IB, this essentially "pushes" routing functionality out to the point where users gain physical connectivity into the network. In addition, these distributed routers can allow greater network access into a centralized router by off-loading the routing functions (Fig. 1C) .
As the routing functionality pushes out and is more widely deployed, it places a tremendous strain on the configuration and control of these distributed devices. Also, because hubs provide for access by many LAN technologies, the router in a hub has to have support for a wide range of network connectivity in the same chassis. Furthermore, thenumber of access ports can vary from one or two, to several hundred, since these ports provide the connectivity to end users of the network.
To be able to implement routing services in these distributed hub and network devices, the architecture must be extremely flexible, scaleable, and adaptive to different hub configurations and chassis, and be able to support a variety of present and future protocols. Also, the architecture needs to provide a high degree of manageability since the operation and control of routing in these distributed hubs will be substantially more difficult due to the sheer number of these devices in a network and due to the variation of technology integrated in the hub/router.
Summary of the Invention
The present invention is an apparatus and method for routing information on a communications network which provides a high availability of service, remote management and monitoring, and interoperability. The system has an open-ended architecture, which means it is open to changing technologies, both in the underlying media as well as in the protocol, and open to expanding the size of the network.
In accordance with this invention an object-oriented architecture is provided which distributes the critical function and system behavior into autonomous router objects. All router objects have three types of imbedded functionality automatically built in, including:
1. The common protocol-independent functions of the object, which may be a routing function (e.g., forwarding information base, FIB) or a system function (e.g., event or timer). For example, all forwarding engines have a forward method as well as a service method regardless of the particular protocol;
2. The functions provided by a base resource object class which define the methods and data for configuration and control. For example, any object of the network interface class has network interface-configuration inside it automatically; and
3. The functions provided by the managed object class which define the methods and data for network management.
By distributing these functionalities into each object, each object becomes autonomous, i.e., the services and data normally external to the object are embedded or accessible within the object itself.
In another sense, some objects are distributed "across the network," i.e., as opposed to providing one central forwarding engine, in this invention a separate forwarding engine object is provided at each network interface.
All objects are connected through a router resource object, which instantiates all objects in an orderly fashion to allow binding and ordered start-up. Once the objects exist, they become autonomous in that each knows its own binding and object behavior defined in the base classes. The objects are also connected through a managed-object framework for management.
Thus, in a preferred embodiment, each object has:
1. Common, protocol-independent functions that are shared by all objects of that class;
2. Their own configuration information;
3. Accessibility through the router resource object for instantiation and control (enable, disable, etc. ) ;
4. Automatic persistence in NVRAM if required;
5. Remote management capability;
6. Text (e.g., ASCII) names for navigation of a resource tree as a file system.
These capabilities are in every object regardless of the specific protocol or application. This ensures a common architecture among many different system/router components, a common method of control internally, a consistent order of instantiation and a common functional behavior (even in different protocol suites which are, in networking semantics, completely unrelated) .
Because the router processes packets at -network level, it needs to understand and decode various network level packets. Some of the most prevalent network protocols are:
IP (Internet Protocol for the TCP/IP protocol suite)
Novell IPX
Xerox XNS
Banyan Vines IP
ISO CLNS
DECNET
AppleTalk
While the router may not implement all possible network protocols, it is possible to add additional protocols with a minimum of coding changes. In addition, the router is able to support a number of different routing protocols. Within the Internet community, the following are commonly used:
• RIP (Routing Information Protocol)
• OSPF (Open Shortest Path First)
• Dual IS-IS (Intermediate to Intermediate System) The router "also supports a variety of communications media, and is able to interface the network protocols to the media drivers.
Other aspects of the present invention will be more fully described in the following drawings and detailed description.
Brief Description of the Drawings
Fig. 1A is a schematic illustration of a network utilizing a centralized router;
Fig. IB is a schematic illustration of a network utilizing distributed hub-routers;
Fig. 1C is a schematic illustration of a network utilizing both a centralized router and distributed hub-routers;
Fig. 2A is a schematic illustration of a network utilizing a plurality of distributed routers according to one embodiment of this invention;
Fig. 2B is an illustration of a hub-router according to one embodiment of this invention;
Fig. 3 is a three-dimensional system architecture view of the router of this invention showing each functional subsystem on a separate "plane";
Fig. 3B is an alternative view of the system architecture as a "flat" system;
Fig. 3C is a schematic illustration of a routing protocol object, for a distance-vector protocol such as RIP;
Fig. 3D is a schematic illustration of a "host" forwarding engine object; Fig. 3E is a schematic illustration of a "protocol" forwarding engine object;
Fig. 4 is a flow diagram illustrating the service and forward methods of the distributed autonomous forwarding engines;
Fig. 5 is a schematic illustration of the network layer and framing object component relationships;
Fig. 6 is a flow diagram of a distributed routing event timer;
Fig. 7 is a schematic illustration of the structure of the managed object framework;
Fig. 8 is a schematic illustration of the structure of the managed object MIB tree;
Fig. 9 is a flow diagram illustrating the storage of persistent objects in non-volatile memory;
Fig. 10 is a schematic illustration of the basic management model;
Fig. 11 is a general illustration of the common MIB template for routing services;
Fig. 12 is a schematic illustration of the relationships between the base resource, resource table, and resource entry;
Fig. 13 is a schematic illustration of the base resource class hierarchy;
Fig. 14 is an example of a base resource class hierarchy;
Fig. 15 is a schematic illustration of the registration in tables at the service, component and interface levels of the base resource;
Fig. 16 is a schematic illustration showing an example of instances of router services and instances of router components;
Fig. 17 is a schematic illustration of the router resource hierarchy of services, components, and interfaces;
Fig. 18 is a schematic illustration of the method of accessing an object with the prior art SNMP method; and Fig. 19 is a schematic illustration of the new method of accessing an object using the MIB navigator.
Detailed Description
Fig. 2A shows one embodiment of a network utilizing the routing apparatus and methods of this invention. The network 100 is illustrated schematically as four subnets 101, 102, 103, 104 each connected to one of four routers 105, 106, 107, 108, respectively. Each subnet may comprise, for example, a plurality of LANs, each connected to a port of its associated multiport router. The four routers are connected by links 109. In this embodiment, the routers are pushed outwardly in the network (as opposed to a central router backbone) and serve as network access points. This provides scaleability as the network can be easily expanded by adding another router and associated subnets. Each router has an adaptive architecture so it can handle multiple protocols and is subject to remote management, so that the entire network can be managed "as a whole."
Fig. 2B illustrates an intelligent hub-router 312 for use in the network of Fig. 2A. The hub-router has a chassis 313 with a plurality of plug-in modules 314-321. The hub accesses three separate subnets 322, 323, 324 on each of channels A, B and C, respectively. Each channel is equivalent to a network interface. Thus, modules 314-315 provide access on channel A to first subnet 322; modules 316-318 provide access on channel B to second subnet 323; and modules 318-320 provide access on channel C to third subnet 324. The module 321 then provides access on channel D to the network backbone, i.e., the other routers in the network of Fig. 2A.
This invention utilizes "object-oriented programming" as defined in Grady Booch, "Object-Oriented Analysis And Design, With Applications," Second Edition, Benjamin Cummins Publishing, 1994, which is hereby incorporated by reference in its entirety. The data and operations are united into fundamental logical building blocks of classes and objects. Object-oriented programming may be defined as a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are members of a hierarchy of classes united via inheritance relationships. See Booch, Chap. 2. Well-known object-oriented languages include C++, SmallTalk, Object Pascal, CLOS, and Effifel. In the embodiment described herein, the C++ language is utilized.
The terms "router" and "routing apparatus" are used broadly in this specification to include software and hardware that can forward packets at the network layer and can exchange network topology information used in a variety of exchange protocols.
In this specification, "network" is used generally to include local area networks, wide-area networks, and several networks connected together by gateways (or routers), known as an internet.
The router of this invention will now be more particularly described in the following subsections:
A. Framework
B. Forwarding Engine
B.l Forward and Service
B.2 Cache
B.3 Access List
B.4 Framing
B.5 Event Funnel
C. Routing Protocols
D. Managed Objects
E. Common MIB Template
F. Common Base Router Resource
G. MIB Navigator A. FRAMEWORK
Internetworking and communication systems are typically built around a set of discrete subsystems. While these discrete subsystems may be be highly integrated, they operate as functionally separate parts. For example, process functions exist separately from configuration data and network management. In addition, when multiple communication protocol stacks are supported, each exists as a completely different "vertical" stack, e.g., IP Stack, IPX Stack, DECnet Stack, with totally separate configuration, control, monitoring, network management, and protocol-specific behavior/functionality. Think of each communication stack as an application which can exist independently of other stacks which may be inple ented.
The distributed object architecture of the present invention defines all of the functional aspects to implement a generalized, common protocol-independent framework which is inherited by every protocol-specific object upon instantiation. At system startup/initialization, a Router Resource object instantiates all objects in an orderly fashion to allow binding and ordered start-up. Once the objects exist, they become autonomous in that each knows its own binding and object behavior defined in the base classes.
Fig. 3A is a three-dimensional view of the system architecture according to this invention showing the logical relationships between objects and wherein each functional subsystem is shown as a separate "plane." Thus, system architecture 200 includes four horizontally disposed planes: routing applications 201; host communications 202; forwarding 203; and network interfaces 204. Objects that are "tiled" show that multiple instantiations can exist; for example, the forwarding and routing protocol objects 234 in plane 203 are instantiated for each individual protocol. The rearwardly directed dashed arrows 206 show that additional instances can exist. Connections between the different planes are shown by dashed lines 205. These logical connections are through resource objects and a naming tree.
Fig. 3A also shows that all objects are connected through a vertical router resource objects plane 207. At the same time, all objects to be managed are connected through a vertical managed object plane 208.
The system architecture can alternatively be viewed in Fig. 3B as a "flat" system, wherein corresponding elements are identified with a prime designation. Again, all manageable objects are connected to managed objects 208', which include MIB objects 209', MIB tree 210', persistent objects 211', NVRAM managed objects 212', NVRAM 213', and MIB navigator 231'. Similarly, all objects are connected to router resource objects 207', including router services 214', router components 215', router interfaces 216', router configuration 217', and events 218'.
Fig. 3B shows more clearly the connections between routing applications 201', host communications 202', forwarding services 203', and network interface services 204'. Starting from the top, a routing protocol object 219' is instantiated for each routing protocol, such as the RIP distance-vector protocol. The routing protocol object 219' is further illustrated in Fig. 3C to include routing protocol thread object 220', which is connected to each of event object 221', routing table object 223', network interface object 224', and neighbor list object 225'. The event object 221' is further connected to timer object 222' and socket object 226', the latter of which is connected via line 205' (see Fig. 3B) to sockets 227' in host communications 202'. Returning to Fig. 3B, host communications 202' further includes SNMP agent 228', timers 229' and host communication stack 230', all connected to sockets 227'.
The host communication stack 230' is connected via a shared memory queue 236' to a host forwarding engine 232', which is described more fully in Fig. 3D. The engine 232' includes forward and service object 235' which accesses the host memory via host message queue object 236' , which is shared between host communications 202' and forwarding services 203'. The forward and service object 235' also accesses the network forwarding table object 233', also known as the forwarding information base (FIB) .
Returning to Fig. 3B, the forwarding information base 233' is connected to each of a plurality of "protocol" forwarding engines 234' which are further illustrated in Fig. 3E. The protocol forwarding engine object 234' includes a forward and service object 239' connected to each of an access list object 240', a next-hop cache object 241', and a framing object 242'. The framing object 242' is connected to each of address cache object 243' and network interface object 237'. The next-hopcache object 241' is connected to the network forwarding table object 233', or FIB in Fig. 3B. Returning to Fig. 3B, each network interface object 237' is connected below to a network media device driver 238' .
In summary, the architecture includes each of the following subsystems:
1. Managed Objects allow router objects to have embedded network management for remote configuration, monitoring, and control. This framework allows any data element or object to be given "management" visibility which includes a unique object identifier and name. In cases where the router object's value needs to be retained and restored through system resets and re-starts (power cycle), the framework allows the object to make itself persistent by saving and restoring itself (using the NVRAM file system). This functionality is transparent to the actual object.
2. Resource Objects provide for a common system template (boilerplate) regardless of the protocol-specific object. They also enforce a common MIB (managed information base) structure and content which makes every router application in the system look and be controlled the same. This is provided to protocol suites that may be fundamentally different.
3. Forwarding Objects provide a distributed forwarding architecture that scales to new network interfaces and media types. It provides a protocol-independant framework for switching network packets, as well as for delivering packets internally to the upper-layer protocol applications. Reframing between different media types is also provided since each object is bound to a particular network interface.
4. Routing Protocol Objects provide the ability to exchange network topology information and determine next-hop routes used for packet network forwarding. These objects will be further described in the following subsections.
B. FORWARDING ENGINE
B.1 Forward and Service
Traditional communication architectures use a layered model with each layer providing a service of transmit and receive. Typically a packet enters a device on some network interface and gets handed to the protocol layer sitting above the interface. This protocol layer in turn processes the packet and hands it off to the next layer above. In the case of a router, the network layer would eventually process the packet, determine the interface it has to be forwarded on, and send the packet back down each layer until it is eventually transmitted out the forwarding interface.
In this prior model, each protocol always gets the packet and then decides if it was appropriate for the interface. It is a centralized model with the protocol layer being the funnel for all packets entering and exiting the system regardless of the interface the packet came in on. Also, because it is centralized, each layer must have knowledge about every specific interface. For example, all configured interface information such as MTU size, forwarding enabled/disabled state, configured network addresses and masks, data-link framing options, filter access lists, etc, must be accessed by each layer as it processes/forwards the packet. This model puts overhead into each layer and is very limiting in supporting new interfaces, media, and protocols, as each layer must be modified. An example of overhead is that if a packet is received for a protocol that is not enabled, it is not dropped until it has been passed up to the correct protocol layer.
In contrast, this invention utilizes distributed autonomous forwarding engines as shown in Fig. 4. Rather than having a single centralized forwarding engine, in the distributed model each interface 11, 14, 17 has a forwarding engine 12, 15, 18 sitting above it, and each forwarding engine knows how to receive and transmit packets on its own interface. Also, each engine only knows its own configuration information and only knows how to receive and transmit packets on the one interface it is associated with. Each forwarding engine accesses a common forwarding table 20.
NOTE: The interface objects 11, 14 of Fig. 4 are the same as network interface objects 237' in Figs. 3B and 3E, with FAS objects 12, 15 (Fig. 4) corresponding to objects 239' (Figs. 3B and 3E) . The host interface object 17 (Fig. 4) corresponds to host message queue 236' (Figs. 3B and 3D), with host FAS object 18 (Fig. 4) corresponding to FAS object 235' (Fig. 3B) . The forwarding table 20 (Fig. 4) corresponds to FIB 233' (Fig. 3B) .
In order to provide a consistent-forwarding model for packets destined for "local" delivery into the "host" CPU, the host is treated as an internal interface with a destination address. The delivery of host destination packets remains in band to the forwarding function.
The operation of the forwarding engine can now be described with regard to Fig. 4. In response to receipt of a data packet on interface object-1 (11), the interface object 11 calls a service method in its bound forwarding engine object 12. The service method removes the sublayer framing on the network packet and performs a validation and extraction of the destination network address from the network packet . The service method then provides a next-hop determination by looking up the destination network address in a cache memory of active addresses to determine a destination forwarding engine object handle, and, if the destination network address is not located in cache memory, accessing a forward look-up table 20 for the best route to the destination network address, and then updating its cache. The method then returns the destination forwarding engine object handle.
Assuming the destination is interface N, upon receipt of the destination forwarding engine object handle, a service method is called in the destination forwarding engine object 15. The service method validates the destination address, performs a look-up in an address cache to obtain a media specific address of the destination, and the service method then reframes the packet and transfers it to the destination interface 14.
Alternatively, if a local delivery into the host CPU is required, the host FAS object 18 is called and the packet is transmitted out on the host interface 17.
In this model, each forwarding engine acts independently to process packets, yet they each unknowingly interact together to collectively provide a system-wide forwarding subsystem which is protocol independent, interface independent, and very scalable (supports 1 to n interfaces).
The forwarding engines of this invention are implemented using object-orientated methodology and are written in the language C++. By having C++ objects, each forwarding engine has its own data portion 13, 16, 19 that is specific to itself, e.g., interface and media information, address resolution tables, configuration information, etc. However, the method portion 12, 15, 18 of each engine is common and is shared by all similar engines.
The specific goal of the each forwarding engine is to provide the reception, processing, and forwarding of network layer packets. At a very high level, all forwarding engines perform these same basic tasks regardless of protocol or media.
Because all engines perform the same basic tasks, each protocol engine is derived from a common Base Class. This allows a generic and common interface to each engine regardless of protocol. Specifically, this Base Class defines the following virtual methods which are then overloaded by each protocol engine that is derived from this Base Class: service(packet_descriptor_pointer) forward_net_packet(packet_descriptor_pointer) forward_host_packet(packet_deεcriptor_pointe )
The service function refers to the actual in-bound processing of a network layer packet which consists of the following:
• reception of the packet from the data link layer
• validation and error processing
• filter processing
• route lookup processing to determine the next hop
The forward function refers to the actual out-bound processing of a network layer packet which consists of the following:
• filter processing
• converting network layer address to physical address
• passing the packet to the data link layer of the outbound interface for transmission. By having protocol-specific Forwarding and Service (FAS) engines derived from a common base class, each protocol forwarding engine has a generic interface for packet servicing and forwarding, regardless of the specific protocol type. This is done on the service side by having each protocol FAS register a pointer to its base class with a packet dispatcher at the data link level for each interface it is instantiated on. This allows a packet dispatcher to invoke the overloaded virtual service method without having to know protocol FAS specifics, i.e.,
switch ( registration_table_lookup (protocol) )
{ case PROTOCOL_REGISTERED: registration_table[protocol] .FAS_ptr->service
(Pkt_deεcr_ptr) ; break; case PROTOCOL_NOT_REGISTERED: break; }
The service function for the specific protocol FAS on a particular interface is invoked only when network layer packets for that protocol are received on that interface.
The same concept holds true on the forwarding side. Each protocol FAS registers itself with the forwarding table for that protocol. This is done by registering its network address and masks along with a pointer to its base class with the internal forwarding table. This table is used by the service method of each protocol FAS to determine which FAS should be invoked to forward the packet, i.e.,
FAS_ptr = Forwarding Table_Lookup (Destination_Network_Addreεs) ; Fas_ptr->forward_net_packet (pkt_descr_ptr); This allows the service portion of the FAS that was instantiated on the interface the packet was received on, to forward the packet to the FAS which was instantiated on the interface the packet should be transmitted out on. This is effectively interface independent, as the binding is done, via the Forwarding Table Lookup dynamically, and is based upon each FAS that exists (1 to n) registering itself and the network it is instantiated on with the Forwarding Table.
B.2 CACHE
Performance-sensitive code often employs caching to speed up performance. Typically, hash codes are used to speed retrieval of the cached data. The UNIX operating system, for example, keeps a number of such caches internally.
Routers must make a forwarding decision for every packet received as to what interface and next hop gateway to forward to. The decision is laborious because a number of competing route choices exist in the Forwarding Information Base (FIB), and the best route must be selected based on address match, metrics, quality of service, route type or class, network versus subnet granularity, etc. Once the route decision is made, it is common in router applications to cache that choice to speed up the decision for later packets having the same destination. How this caching is implemented varies wildly but is typically kept of small fixed size and is feature poor.
This invention comprises an object-oriented and feature-rich caching to provide a short-cut handling for later packets received with the same source and destination addresses. A separate cache exists for each network interface by containing cache objects in each forwarding engine (see for example next-hop cache object 241' and address cache object 243' in Fig. 3E) . B.2.1 Base Class
This invention provides a base class ACache which is protocol independent. Addresses are kept as unsigned long integers. ACache does not support management set static entries; it is strictly dynamic. ACache supports:
• dynamic growth or shrinkage in the cache size
• aging our of cache entries to keep cache size down
• flushing entries when external management events occur
• setting dynamic entries keyed by hashing source/destination
ACache has its own thread context. An entry is set in the cache in an interrupt service context. If it reaches a high-level mark for cache size, the ACache set entry procedure hits an internal event to wake ACache back up in thread context. It then allocates more memory for the cache. Likewise when its aging timer expires, ACache wakes up in thread context in its aging procedure and may choose to shrink the cache at that time if a low-level mark is reached.
Flushing the whole cache is a fast way to keep caches current when certain external management events occur; the alternative is to walk caches on all interfaces to check if the external management affected entries are in that cache
Setting an entry is done by hashing the source and destination addresses into a one byte hash code and linking the entry into a "bucket" quickly accessible by that code. The entry itself has a generic base class as seen by ACache, but what is actually stored is a derived entry which may contain protocol-specific data. This allows each cache to function exactly the same regardless of specific protocol-derived classes. B.2.2 Protocol-Specific Derived Class
Individual network protocols may provide a class derived from ACache to (1) add protocol specific data to an entry and (2) supply the protocol-specific lookup routines. For example, the IP derived class is IPACache.
As part of forwarding packets, the IP forwarding engine methods (1) validate packet addresses, (2) filter against an access list, and (3) retrieve the next hop from the FIB. These procedures are inherently slow, so the results of these procedures once obtained, such as address validity, are cached and corresponding procedures are provided in IPACache to lookup the same results quickly.
IPACache thus supports three cache lookup procedures:
• Martian (invalid) addresses
• access control list filtering
• next hop.
Each of these procedures is passed the source and destination addresses from a packet, hashes them and looks up entries linked in the "bucket" for that hash code. It checks each linked entry to see if it matches exactly both the source and the destination. If it finds a match it returns the entry data for that function. For the Martian lookup the address validity, yes or no, is returned. For access control lookup (see access list object 240' in Fig. 3E) an additional protocol and port parameter must be matched and permission, permit or deny, is returned. For next hop a quality of service parameter must be matched and the next hop is returned.
These lookup procedures are called in the context of an interrupt service routine attempting to forward the packet; they are coded to be fast. However, the cache may be temporarily inactive - say it is being flushed in a thread context due to an external management event, such as the deletion of an access list entry. In this case, the cache lookup routine simply falls back on the original, slow procedure which made the decision when the entry was cached, effectively bypassing the cache.
B.2.3 Network Management Visibility
Through the use of a common base router resource class, each protocol includes in the forwarding part of its protocol-specific MIB a table of entries keyed by interface number. Some of the leaves in an entry are associated with this packet caching. Each interface maintains its own cache. Individual entries in a cache are not MIB visible; these leaves concern the cache as a whole: whether or not it is enabled, the maximum size it will be allowed to grow to, how many entries are currently in that cache, the number of cache hits since the cache was enabled the number of cache misses since the cache was enabled.
B.3 ACCESS LIST
In general, routing applications allow network management to filter packets based on destination address, or on the combination of destination and source addresses. It is desirable that each interface of the router be able to maintain a separate set of filter instances - an access list. Most vendors use a linear mechanism and since the list must be checked for each packet being forwarded, throughput slows down linearly as the list gets larger.
This invention provides a mechanism by which the forwarding of network packets is subject to access control set by network management .
To provide an object-oriented, powerful and very efficient access control mechanism, a base class FAC (Forwarding Access) was invented. For efficiency, FAC keeps access list entries as nodes in an AVL tree. A tree does not have a predefined size and may grow freely. Management routines are provided to allow network management to set entries and retrieve them in serial order. These routines are supported by iterator classes written to walk the AVL trees.
Efficiency is further maximized because within each access list, valid entries are also linked across the tree in their sequence order for fast scan during filtering. Each interface may associate with one and only one access list as identified by an ID in the entry. This association is done in the forwarding part of a protocol's MIB via an ID leaf and a control leaf to enable or disable filtering.
B.3.1 Base Class FAC
FAC is a base class for all protocols' access control including IP, IPX, DECnet, Appletalk and for filtering routing protocols such as RIP. Each individual protocol derives its access list class from FAC. In the protocol-specific MIBs, access control consists of a table of entries. An entry begins with four common leaves managed in FAC: ID, Sequence, Matches and Permission. The first two index the entry instance and are unique to that entry.
ID: The ID is the identifier which groups entries into a particular list. All lists reside in the same single tree for that protocol.
Sequence: The sequence number keys the order of entries in a given access list. When filtering a packet, the first matching entry exits the filter check and a packet may match multiple entries, so order is important.
Matches: This is a read-only counter of the number of times the entry has been matched during a filter() call since the entry was created.
Permission: This is enumerated and includes values:
• invalid (for management to remove an entry)
• permit (allow packet forwarding from source to destination) • deny (deny packet forwarding from source to destination)
• permit bi-directional (allow packet forwarding from either source to destination or destination to source)
• deny bi-directional (deny the packet forwarding from either source to destination or destination to εource)
B.3.2 Disassociation of list and interface
This allows the same list to be asεociated with multiple interfaceε (but not necessarily all interfaces) so that fewer accesε liεt entrieε need be created.
B.3.3 Wild Card Addressing
Although addressing is the protocol- specific part of the accesε liεt entry, all protocol FAC derived classes support some special case addreεε valueε which εtand for a range of addresseε. For example, in IP an addreεε iε paired with a maεk and O'ε in the mask are wild cards matching anything in the corresponding part of the address. Thus an address paired with a mask of all O's matches everything. This iε powerful - to filter out all packetε from any source destined to a server, set the access list entry with the server's destination address and mask of all l'ε, but use a source address and mask of O's.
B.3.4 Sequence keying
This provides ease of use in specifying what to filter. For example, to allow all packets through from one subnet and deny all packets from other subnets on the same network requires only two entrieε. Set the firεt entry to permit the good εubnet and the second entry to deny all subnets of that network by using a wild card for the subnet and host portion of the address. B.3.5 Bi-directional Permission
This also allows ease of εpecification - one entry to stop both request and replies between two end nodes (instead of having to specify two entrieε - one for the request from source to destination and one for the reply from destination back to source) .
B.3.6 Checking Access On Service
As Well As Forwarding Interface
Together with bi-directional permission, this allows ease of specification allowing the same entry to be defined for both interfaces (rather than one entry on one interface and εource and destination reversed for the other entry and interface) .
This also allows for discrimination based on interface, not just on addreεs - e.g., all εource A to deεtination B permitted on interface 1 but not on interface 2. This is not posεible if filtering iε only checked on the forwarding εide (unlesε interface is made part of an entry, which is more awkward to administrate) .
B.4 FRAMING
As εhown in Fig. 5, the firεt three layerε of the OSI reference model depict the physical 47, data link 46, and network 45 layerε. Multiprotocol routers utilize this layering model to switch network layer packets between different data link and physical layer combinations, thereby allowing network layer protocols to run over a variety of communications facilities.
In accordance with thiε invention, Framing Objectε are provided to preεent a common interface between εtandard data link and physical media configurations and network layer protocol components. Fig. 5 depicts the network layer and framing object component relationships against the OSI layer model. The Framing Object components consist of the Framing Object Resource class 50 and the specific Framing Objects 51. The Framing Object Resource claεs 50 asεists the network layer in determining platform specific configuration information as it pertains to media and interfaces found on the εystem, and in the allocation of specific Framing Objects 51 to be employed by the network layer protocols 52 to receive and transmit network layer protocol data units on each network interface. Framing objects are instantiated for each type of framing a protocol framing engine supports and are bound to the interface object to which the forwarding engine is attached.
Framing Objectε are realized by deriving data link and media specific Framing Objects from a base Framing Object clasε. The baεe Framing Object claεs provides methods: to allow the network layer protocol to register to receive network layer packets matching framing and protocol identifier criteria; to transmit network layer protocol data units; and to obtain information about the associated data link and physical layerε.
Standard data link framing formatε and protocol identifiers, as defined by the standards committees, such as IEEE, IETF, are realized through specific Framing Objectε. Data link framing and media detailε are embedded in the Framing Objects to relieve the network layer from this knowledge. Where required, methods are provided by the Framing Objects to obtain data link framing and media information in a generic manner, for example, to return the length and value of a data link physical addreεε, obtain the length of a data link header, or obtain the media MTU.
Framing Objects are requested from the Framing Object Resource class when the network layer protocol components are instantiated over system interfaces to service and forward network layer packets (see framing object 242' in forwarding engine 234' of Fig. 3E) . The network layer protocol assumes nothing about the nature of the media associated with a system interface and requests Framing Objectε for each of the framing formatε that are supported by the protocol. The Framing Object Resource class constructε and returnε only valid framing formatε as determined by the media associated with the requested interface. Framing Objects are bound to the interface and media drivers when they are constructed.
For example. Fig. 5 shows how IP network layer protocol 52 supports framing standards for operation over ethernet 55 and token ring 54 media, via media drivers 53. From a framing point of view for these media, IP supports Ethernet Version 2 and 802.2 LLC with SNAP framing. When instantiated over an interface, the IP network layer will request Framing Objects for both of these framing standards. When instantiated over an ethernet interface two Framing Objects will be allocated: an Ethernet Version 2 Framing Object and an 802.2 LLC with SNAP Framing Object; when instantiated over a token ring interface, only an 802.2 LLC with SNAP Framing Object will be allocated. The ethernet
802.2 LLC with SNAP Framing Object will be framed with the
802.3 MAC layer, while the token ring 802.2 LLC with SNAP Framing Object will be framed with the 802.5 MAC layer. Once returned, the network layer protocol can select and use any of the allocated Framing Objects to register to receive and transmit network layer packets.
Framing Object instances returned from the Framing Object Resource claεs can be used by the network layer protocol to simultaneously support all valid framing formats for a specific media. Dynamic teaming of network stations and associated framing formats can be achieved. For example, the IP network layer protocol may be communicating with two IP stations on a directly connected ethernet segment using Ethernet Version 2 framing for one IP station and 802.2 LLC with SNAP framing for the other. The Framing Object is retained in the ARP cache along with the MAC layer physical address to allow the IP network layer to map a framing format, as well as, a physical address to an IP station. B.5 EVENT FUNNEL
Applications such as routing consist of multiple tasks or threads of control, are driven by events, and require a scheduling mechanism to distribute the processor effectively among the threads of control - i.e., to dynamically reschedule threads based on events asynchronous to the running thread such as the arrival of a packet on the network or the expiration of a timer. Support for this event-based reεcheduling of threadε iε provided by the operating εyεtem.
Beyond this distribution across threads, an individual thread itself may need to divide its attention among the competing events which it εervices. An event funnel which allows a- thread to wait on multiple events simultaneously in one place, greatly simplifies the architecture of the thread code. Applications written over major operating syεtemε εuch aε UNIX have εuch εupport, i.e., the εelect() εyεtem call in 4.3BSD UNIX or the poll() εystem call in System V.
B.5.1 RtrEvent and RtrSlice
This invention provideε for an object-oriented event funnel by organizing the abεtraction of an event into a baεe class RtrEvent. Various event types εuch as packet arrival or timer expiration, may then be defined aε claεεes derived from RtrEvent. For example, packet arrival is modeled through a socket class derived from RtrEvent - εee Fig. 6.
RtrEvent has a public procedure wait() which blocks the thread and a procedure hit() which flags the operating system to reschedule the associated thread. To wake up a thread blocked waiting on a given RtrEvent, that RtrEvent muεt be hit by a different running thread or an interrupt service routine. A raw RtrEvent can be used for IPC (InterProcesε Communication). Each RtrEvent is assigned a unique identifier when constructed and contains a void pointer to carry user data through the event. A thread 35 may wait directly on a single RtrEvent or associate a set of RtrEvents with an event funnel and wait collectively. The funnel iε claεε RtrMultiWait. RtrMultiWait 36 provides an add() procedure to add a RtrEvent to it and keeps the RtrEvents 37a-d on a linked list. It likewise provides a removeO to disasεociate a RtrEvent.
A thread may inεtance a RtrMultiWait and wait in one place on multiple RtrEventε. Theεe may be raw RtrEvents or derived objects in any combination. RtrMultiWait itself contains its own event and has a mwait() procedure which blocks its thread on its event. When an asεociated RtrEvent iε hit, that hitε the RtrMultiWait as well. When control resumes in the thread returning from the mwait() call, the hit RtrEvent is returned.
If multiple events occur (multiple RtrEvents are hit) before the operating system scheduler runs the funnel ' ε thread, mwait() presents the highest priority RtrEvent. The next mwait() call does not block but returns immediately with the next highest priority RtrEvent. Within the same priority, mwait() returnε them in order of occurrence.
Actually mwait() doeε not always return immediately even though it has one or more RtrEvents in a hit state. This is because it checks before returning with another clasε, RtrSlice, to aεεure the funnel's thread has not exceeded a configurable time quantum, defaulted for example to 0.4 seconds. If exceeded, RtrSlice returns control to the operating system scheduler to reschedule the thread. Without RtrSlice, the threads are not preempted and muεt share the processor equitably among themselves. RtrSlice asεists in this regard because it can be called freely without penalizing the calling thread. If the quantum has not been exceeded, RtrSlice does nothing but return. Since many threads are built around an mwait() call, a lot of the sharing problem is solved by thiε εingle uεe of RtrSlice. B.5.2 RTimer
Thiε invention further provideε for efficient queuing of timers. A timer is an important type of event and is embodied by RTimer, a clasε derived from RtrEvent. Individual componentε of the communication device may further derive component specific timers from RTimer. The granularity of timers is, for example, 0.1 seconds.
RTimer's start() procedure inserts it on the timer queue with a given delay until expiration. When the time expires the timer queue sounds the alarm which means the RTimer's base claεs RtrEvent hit() is called. RTimer may be constructed as a one-shot timer or as a cyclic timer which iε rearmed automatically on the timer queue after its alarm is sounded. A parameter "count" keeps track of how many times have passed before the timer is reεtarted. The period of the cyclic timer may be different from the initial alarm time.
To tick timerε down efficiently and εound their alarmε, claεε RTimerQ iε provided. The embodiment εhown in Fig. 6 uses a single object, inεtance of RTimerQ 39. RTimers 38a, 38b are asεociated with it when started. The RTimerQ links the RTimers onto it in order of alarm time so that it only needs to look at the head of the queue to see if a timer has expired. RTimerQ runs off a single operating system primitive which ticks in a clock interrupt service routine every 0.01 seconds, for example. It checks the head of the queue and if there iε work to do it hits its own event to reawaken in thread context and process the queue. Thus it hits the expired timers in a thread context (of very high priority), not in the time critical interrupt context.
Rtimer has a start() procedure to insert it into the RTimerQ queue as well as stop( ) to remove it. For efficiency and because thread code in this embodiment is not reentrant, RTimer also provides a startx( ) and stopx() to start and stop timers from interrupt service code. These routineε simply put the timers on a critical path linked list and hit the event associated with RTimerQ. When RTimerQ wakes up in thread context, it unhooks the critical path linked list and inserts each RTimer into the queue in alarm-time order.
C. ROUTING PROTOCOLS
Routing Protocol Objects provide the autonomous functionality required for topology exchange protocols to function. Topology exchange protocols discover adjacencies (neighbors), advertise network reachability, synchronize their databases, and perform best-path determination. The base object classes provide a common set of services that are protocol-independent. Specific Routing Protocol derived classes automatically get the same behavior and control for any protocol. The Routing Protocol Object framework embeds (or distributes) the required objects into the Routing Protocol Object itself. In this way, the Routing Protocol is self-sufficient in that it has its own configuration, and system serviceε, aε well aε itε object functionality (e.g., advertiεe routeε, apply εplit-horizon, update FIB, etc.). Specifically, the embedded objectε are (εee Fig. 3C) :
Routing Protocol Thread 220' - Thiε object giveε proceεε context under which to run the topology exchange functions.
Routing Table 223' - This object gives an AVL-tree table for maintaining the network map. This table can grow arbitrarily in size.
Neighbor List (Adjacency) 225' - This object provides a means for discovering and maintaining router adjacencies. These adjacencies are the next-hop routers and share in the topology exchange.
Network Interface Table 224' - This object provides protocol-specific configuration information for each attached network interface.
Event Object 221' - This provides its own event definition capabilities within the Routing Protocol
Object. Routing Protocol threads rely on events for processing advertisements and maintaining the network maps.
Timer Object 222' - This provideε itε own timer derived objects within the Routing Protocol Object. Common times are defined for periodic advertisement and link-state updates.
This Routing Protocol Object provides for distance-vector protocols; however, objects for supporting link-state protocols could similarly be provided.
D. MANAGED OBJECTS
Another aspect of this invention is the use of an object-oriented εyεtem of computer code for local and remote device management. This system has the advantage of modular decompoεition which simplifies the implementation of existing and future device management functionality. Specifically, it provides:
• A standard interface for Managed Objects in the Management Information Baεe which requires little if any duplication of previously written code.
• A εtandard interface for Managed Object tableε which allow the user to implement SMI tables uεing εtandard table conventions without the added overhead of assuring those conventions are met.
• Proviεionε in the Managed Object interface to indicate an object will be non-volatile without having to write additional code to interface with non-volatile memory. Theεe are called "Persistent Objects. "
• A standard interface for the Management Information Base for object access by any management protocol or other entity including SNMP, SNMPv2, DMP, local device management, and other Managed Objects.
• A set of objects repreεenting the nine basic data types defined in the SMI, which in addition to encompassing the basic properties of these types, allow for a standard method of augmenting their basic properties for additional purposes. Theεe include the encoding and decoding of management protocol packetε and the use of the types as Managed Objectε themselves.
The following definitions will be used:
Base Class A clasε from which another claεε iε derived (see Clasε, Derivation) .
Class A logically grouped set of data and the functionε that operate on them.
Derivation Without changing a claεε, derivation adds and/or augments thiε claεε to perform additional or different functionality. The original set of code may limit the ability or extent to which it may be augmented (see class).
ISO International Standards
Organization.
Managed Object A piece or table of data in the Management Information Base.
MOF Managed Object Framework; the underlying syεtem of communications device management. MIB Management Information Base; a database of manageable information about a device. It is described in RFC 1156.
Object Identifier A series of numberε which uniquely identifieε a piece or group of data in the Management Information Baεe. Often abbreviated OID.
RFC Request For Comments; a document of the Internet Engineering Taskforce (IETF) syεtem of standards. An RFC (request for comment) is a published document which can be obtained by contacting the RFC editor at USC/Information Sciences Institute, 4676 Admiral Chief Way, Marina Del Rey, California 90292-6695, USA.
SMI Structure of Management
Information; a syεtem of information organization conventionε. It iε defined in RFC 1155.
A graphical representation of the MOF is shown in Fig. 7. The MOF 60 is broken down into five separate components:
• Core Objectε 61, including SMI Type Objects 63 and Table Objects 64 • Managed Object Baεe Class 62 MIB Object 65
• Specific Managed Objects 66
The MIB Object 65 provides the mapping of an Object Identifier (which uniquely identifies a piece of data in the Management Information Base) with a particular Managed Object. It then takes advantage of the Managed Object Baεe Class standard interface to retrieve the actual data held in the Managed Object.
The Core Objects 61 represent a set of objects uεed by the entire MOF. These include one object for each of the nine basic types defined in the SMI: INTEGER 67, OCTET STRING 68, NULL 69, OBJECT IDENTIFIER 70, IPAddresε 71, Counter 72, Gauge 73, TimeTicks 74, and Opaque 75. Each of these objectε encompasε the functionality and valid states described in the SMI, aε well aε additional functionality uεeful to the code which uεeε these types. Other Core Objects include Table Objects 64 for holding the data for Managed Object tables.
The Managed Object Base Claεε 62 provideε a εtandard method of acceεε to specific Managed Objects 66. Any object which deriveε from thiε baεe claεs need only customize a small amount of code to allow this εtandard acceεε, which the MIB then takeε advantage of in obtaining the object's data.
The Specific Managed Objects 66 are data types that are multiply derived from the Core Objects 61 and the Managed Object Base Class 62 to encompass the functionality of each. For instance, an Integer Managed Object contains the integer functionality derived from the INTEGER Core Object 67, as well as the manageability derived from the Managed Object Base Class 62. When a new Integer Managed Object is needed, a designer simply needs to provide the value of the integer (or information on how to obtain the value) and a unique Object Identifier. This requires relatively little new code to accomplish. The MIB Object 65 is then able to accesε the Managed Object in a standard way. Managed Object Tables are also created in thiε way. The following is an enumeration of the specific Managed Objects:
Name Derived From
Integer Managed Object Core INTEGER, Managed Object
Base Clasε
String Managed Object Core OCTET STRING, Managed
Object Baεe Claεε
OID Managed Object Core OBJECT IDENTIFIER,
Managed Object Base Clasε
Null Managed Object Core NULL, Managed Object Base
Clasε
IP Addresε Managed Object Core IP Address, Managed
Object Base Clasε
Counter Managed Object Core Counter, Managed Object
Baεe Claεε
Gauge Managed Object Core Gauge, Managed Object
Base Class
Time Ticks Managed Object Core Time Ticks, Managed
Object Base Clasε
Static Table Managed Core Static Table, Object Managed Object
Baεe Claεε
Dynamic Table Managed Core Dynamic Table, Object Managed Object
Baεe Class
' D. l MIB Accesε
The MIB may be acceεsed in four ways: Get, Get-Next, Set, Set-Validate. A Get operation requireε a complete Object Identifier. The MIB will map the Object Identifier to a Managed Object (if one exists with that Identifier) and call that object's Get command to retrieve the information. An error is returned if the Managed Object with that identifier does not exist. A Get-Next operation may take a non-exiεtent, complete, or partial Object Identifier and will map it to the next numerically highest complete Object Identifier that exists in the MIB. Again, the MIB will then call that object's Get command. An error will be returned if there is no Managed Object numerically higher than the one specified. A Set or Set-Validation operation requires a complete Object Identifier, type and value. They will map the Identifier the same way a Get operation does. In a Set operation, the Managed Object will be set if it is "writable," the type iε correct and the value provided is valid for that Object. The Set-Validation operation makes the same checks as the Set, but does not actually change the value of the Managed Object. An error iε returned if a Managed Object with that identifier doeε not exist, the type is incorrect, or the value is incorrect or out of range.
The MIB also provideε an authentication service. An authorization information object is sent with each MIB access command. Once the MIB has confirmed a Managed Object exists for a particular Object Identifier, the device's authentication manager iε εent the Object Identifier along with the authentication information object. The authentication manager iε application εpecific to allow any device to specify its method of authentication.
The Managed Object may be accesεed by the Get command and, if the object iε writable, by the Set and Set-Validate commandε. In implementing a specific Managed Object, one muεt specify if the object is read-only or read-write, the user must provide methods to check the type, to' check the value, and to set the value of the object. This is the minimum of functionality one must provide for a Managed Object. Additional functionality includes specifying (on a Set command) that a new value should be stored in non-volatile memory and retrieved at the beginning of device execution. Thiε is specified upon return from a Set command.
When the Managed Object Base Clasε receiveε a requeεt to store a value to non-volatile storage, it calls a device non-volatile memory manager with the Object Identifier, type and value (see Fig. 9 and section D.3 below). At the beginning of device execution, all Managed Object values are restored through calls to the MIB aε if Set commandε were called for thoεe objectε.
Managed Object Tableε interact with the Core Table Objectε to provide ordered sets of information. Each value in each entry of the table may be considered the value of a managed object for a particular table index. The index is extracted from the Object Identifier (in a manner specified in the specific Managed Object), the Core Table Object is asked to look up an entry with this key, and the value is extracted and returned from the entry. The Set command workε the εame way, except the entry index Managed Object Tableε may alεo εpecify that they εhould be saved to non-volatile memory after a Set command. In contraεt to the non-tabular objectε, entire table entries are restored at the beginning of device execution using the Core Table Object'ε add command,
A εecond type of Managed Object Table allowε table entrieε to be added and deleted. This is accomplished through the convention of specifying one indexed Managed Object as an entry control. Setting thiε entry control object to different valueε allowε the entry to be added or removed from the Core Table Object. The εaving of entrieε of this kind to non-volatile memory workε the same as the table object described above, with the addition of allowing entries to be removed from non-volatile memory when the entry is removed from the Core Table Object.
As may be surmiεed from the table of specific Managed Objects above, both static and dynamic tables are available in the Core Objects, depending on the memory model used. It is also useful to note that additional Core Objects may be added to provide additional functionality to both tabular and non-tabular Managed Objectε as necessary. As shown in Fig. 8, the MIB is structured as a tree 80 of MIB nodes 82-89, with each node repreεenting an identifier in the Object Identifier (OID) . Managed Objectε 84, 86, 89 are placed at the leaf nodeε. If one wishes to accesε the MIB to Get the Managed Object named by "OID A", "OID A" would have to be εpecified exactly. A Get-Next on "OID D" would alεo get the information for "OID A", becauεe a Get-Next will return the next Managed Object leaf after the OID specified. If one does a Get-Next on the Managed Object named by "OID A", the information would be returned from the Managed Object specified by "OID B," and so on. One should also note that before the MIB asks the leaf Managed Object for its information, an acceεε authentication is made. If the accesε for the operation is invalid, a Get, Set, or Set-Validate will return a non-existent OID error, while a Get-Next will move past a leaf Managed Object to the next in the tree.
D.2 Internalε
The Managed Object Baεe Claεs provideε the following interface (in C++ code):
Claεε ManagedObject {
//Functions used by MIB for common Managed
//Object access at leaf:
Get();
GETNEXTO;
SET();
SETVALIDATEO;
//Functions which specific Managed Objects //provide to the functions above to return its //specific information: mo_get(); get_instance( ) ; mo_set( ) ; set_validate() ; get_εtatuε();
};
The GET, GETNEXT, SET, and SETVALIDATE are the functions repreεenting the acceεε methods described above. The mo_get function is called by the GET and GETNEXT access functions to return the information for a εpecific leaf in the MIB tree. The get_inεtance functions validateε the Object Identifier for the GET and GETNEXT functionε. If more than one MIB leaf iε repreεented by thiε Managed Object, get inεtance will alεo update the Object Identifier to repreεent the "next" leaf when called by GETNEXT. The mo_εet function is called by SET to store new information for a particular leaf and depending on the return value save new information to non-volatile storage. The set_validate function is called by both SETVALIDATE and SET to validate the value's Object Identifier, type and value. The get_εtatuε iε called by both SETVALIDATE and SET to aεsure the Managed Object is not read-only. Each specific Managed Object provides the routineε neceεεary for itε particular leaves and read-write status. These five standard routines allow the implementation of specific Managed Objects to be flexible, while keeping operations common to all Managed Objects in the common GET, GETNEXT, SET, and SETVALIDATE routineε. A Managed Object may repreεent many leaveε of many typeε and valueε, while requiring only a few lineε of code for more simple Managed Objects. D.3 Persistence
As mentioned above, the SET will call a specific Managed Object's mo_set function and, depending on the return value, εave it to non-volatile memory. The SET function interactε with a system called the Persistent Object Manager.
As illustrated in Fig. 9, when a device begins operation a Persistent Object Manager 77 is created and interacts with a Non-Volatile Memory Manager 76 to build a table mapping Object Identifierε with "handleε" for retrieval and storage of Perεiεtent Objects. Each specific Managed Object which is persistent is then created and calls the Persiεtent Object Manager to reεtore its values through the standard Managed Object Base Claεε. When a Perεiεtent Object iε εet to a new value, the Managed Object SET function 78 will call the Persistent Object Manager 77 to store the value. If the object has been εtored previously, the Persiεtent Object Manager will uεe itε eεtabliεhed "handle" to update the non-volatile value. If an object haε not been stored previously, the Persistent Object Manager 77 askε the Non-Volatile Memory Manager 76 for a new handle (identified by the object'ε Object Identifier).
D. NVRAM File Syεtem
The NVRAM File Syεtem overlays a simple file syεtem εtructure over the Non-Volatile Storage. The file system allows tagging of blocks by object identifiers. This allowε every object to automatically fit into the file system hierachy since every object, by definition, has a different object identifier assigned out of the global MIB naming tree.
E. COMMON MIB TEMPLATE
The MIBs provide the ability to configure, monitor, and control routing applications at both the system level and the network interface level. The system level provides control at the device level where global parameters for the applications or services can be set. The network interface level provides control where the applications or εervices attach to the network. This is key for network specific parameters that may vary from network to network. The MIBs use default parameters aε much as poεεible to allow the minimum amount of uεer configuration before the device is operational .
E.l ctRouter-MIB
Routing Serviceε provideε the ability to "diεcover" which routing applicationε and componentε are in a device. Since deviceε εupport a variety of network services and applications, it is eεsential for management applications and network users to be able to determine the particular capabilities of any device. Any device providing Routing Serviceε will contain an entry in its Chasεiε MIB showing the availability and version of the Routing Services. This is basically a "table of contents" for what applications are in the device, with only one entry for Routing Services. The entry specifieε a high-level router MIB ("ctRouter") used to control the entire Routing Serviceε regardleεε of which routers are actually in the device. The ctRouter MIB provides the ability to determine the administrative and operational εtatuε (including uptime) for any router and component without having to uεe any of the individual router MIBs. However, for any specific protocol or configuration control, the individual router MIBs must be used.
Fig. 10 illustrates the basic management model, with chassis MIB 110 above the ctRouter MIB 111, and each of the individual routing protocol MIBs 112-115 below.
E.2 The Common MIB Template
In order to provide consistent management and control of any router application within Routing Services, each MIB uses a common MIB template. Each individual router MIB is defined with the same set of managed objects. Thiε provideε a conεiεtent external view of each individual router application. Because of the common object model, some managed objects may not have any meaning or direct application in a particular router protocol configuration. In instanceε where thiε occurs, the object is completely viεible and manageable, but haε no effect on the operational behavior of the router or the particular protocol.
Fig. 11 illuεtrateε the functional groupε common to all of the individual router MIBs. The "root" protocol defines the network protocol router that is being managed, e.g., IP. "MIB" defines the verεion of the router MIB. "Componentε" defineε the εet of component groupε that comprise a router group, i.e. , :
• Router Syεtem Group - contains the objectε that pertain to routing εerviceε at a global, device-wide level .
• Forwarding Group - containε the managed objectε uεed to setup and configure the network protocol's router ports for packet forwarding as well aε the aggregate and per interface IP packet forwarding counters.
• Topology Group - contains the managed objectε for the routing and service advertisements of the router. Theεe managed objectε allow for routing agents and service agents to be controlled and monitored on a system wide as well as a router port basiε. DiεtantVectored and LinkState are the types of topology groups defined.
• Forwarding Information Base (FIB) Group - contains the managed objects for the forwarding table. This table iε built from entrieε in the network protocol's routing table(s) and reflects the routes that are considered the best routes for forwarding.
• End Systems Group - containε the managed objects which control the Address Resolution Protocol (ARP) which maps host addresses to physical addresses for each router port.
• Accesε Control Group - containε the managed objectε that pertain to establishing Access Control Listε for the network protocol's traffic.
• Filters Group - containε managed objectε that pertain to the εetup and configuration of filters.
• Redirector Group - containε managed objects pertaining to the setup and configuration of specific redirection of the network protocol's traffic.
• Event Group - contains the managed objectε pertaining to event logging.
• Work-Group Group - containε managed objectε pertaining to work-group routing.
E.3 Component MIB Groups
Many of the component groups throughout the common MIB template share a similar structure. The component MIB view varies depending on the actual component being managed. Each part (branch) has a common management view aε shown in Table 1.
Table 1: Common Component MIB View Template
Component Group (a) System (1)
Config (1)
Aggregate Counters (2) Interfaces (2) Config (1)
Config Interface Table (1) Counters (2)
Counters Interface Table (1) Syεtem
Common Syεtem Config View
Objects in the Common System Configuration globally control the component.
• AdminStatus(l) - controls whether this component is enabled or diεabled.
• OperationalStatus(2) - shows the operational statuε of the component.
• AdminReset(3) - resetε the component.
• OperationalTime(4) - indicateε the amount of time that the component haε been in itε current operational state.
• Version(5) - displays the firmware version of this component.
Common System Aggregate Counterε
Common Syεtem Aggregate Counterε show the total byte and packet countε on all router portε of packetε received, εent, diεcarded, and filtered. Some of the groupε have additional counterε. All εyεtem counterε groups have the ability to enable/disable the counterε on all ports and to reset counters to zero.
Interfaces
Common Config Interface Tables
All interface configuration tables are initialized with default entries that match the number of MIB-II interfaces on the device. The beginning leaves of any interface table have the following form:
• Iflndex(l) - MIB-II interface or port number.
• AdminStatus(2)- controls whether the interface of thiε component iε enabled or diεabled.
• OperationalStatus(3) - showε the actual εtatuε of thiε component's interface. • 0perationalTime(4) - indicates the amount of time that this component's interface has been in the current operational state.
Some component groups have additional configuration leaves.
Common Counters Interface Tables
Objects in the Common Counters Interface Table show the total byte and packet counts on a router port of packets received, sent, discarded, and filtered. Some of the groupε have additional counterε. All interface counterε groupε have the ability per port to enable/diεable the counters and to reset counters to zero.
E.4 Common Forwarding Group MIB
The common forwarding group MIB followε the common component view with the exception of an Addreεε Table (εee Table 2). If neceεεary, each protocol εpecifically defineε an address table. For example, DECnet does not require configuring an address per port and so the addresε table group iε not preεent.
Table 2: The Forwarding Component Group
Syεtem (1)
Aggregate Counterε (1) Interfaceε (2)
Config (1)
Config Interface Table (1) Address Table (2) Counters (2)
Counters Interface Table (1) System
Aggregate Counters
The Aggregate Counters and Counters Interface Table for the forwarding group follows the structure of the basic counters groups with the addition of host in/out, error, and number forwarded counters.
Interfaces
Config Interface Table
The Config Interface Table for the forwarding group follows the basic structure of all other interface tables with the following added leaves.
Control(5) - Add/Delete entry.
MTU(6) - determines size of packet to be sent.
Forwarding(7) - Enable/Disable forwarding of packets
FramingType(8) - Identifieε the type of framing to be used.
Aclld(9) - Aεεignε the ACL List ID to be used.
AclStatus(lO) - Enable/Disable Accesε control.
CacheControl(11) - Enable/Disable Caching.
CacheEntries(12) - Current number of entries in the cache table.
CacheHitε(12) - Number of cache hitε.
CacheMisses(13) - Number of cache miεses.
Counters Interface Table
The Aggregate Counterε and Counterε Interface Table for the forwarding group followε the εtructure of the baεic counterε groupε with the addition of hoεt in/out, error, and number forwarded counterε.
E.5 Common Topology Group MIB
The common topology group MIB followε generally the common component view, as shown in Table 3. Table 3: Topology Component Group(4)
DistantVectored (1) or LinkState (2) System (1) Config (1)
Aggregate Counters (2) Interfaces (2) Config (1)
Config Interface Table (1) Counters (2)
Counters Interface Table (1)
Syεtem
Syεtem Config
The Syεtem Config branch for the topology, DiεtantVectored group maintainε the common εyεtem config view with the following added leaves:
• Stacksize (6) - controls the amount of stack required for the routing protocol agent.
• Thread Priority (7) - εpecifieε the run-time execution priority of this routing protocol agent.
• Threshold (8) - Specifies the number of RIP entrieε that can be held in the routing protocol 'ε route table.
• AgeOut (9) - Specifieε the time inactive routeε remaining in the routing table.
• HoldDown (10) - Specifieε the additional time to hold an inactive route in the route table.
Interface
Config Interface Table
The Config Interface Table for the topology, Diεtant Vectored group follows the basic structure of the common config interface tables with the following added leaves. • Verεion (5) - Protocol revision level.
• Advertisements (6) - Periodic rate for sending routing Advertisement Updates.
• FloodDelay (7) - Router discovery change delay.
• RequestDelay (8) - Delay time to send reεponεe after receiving requeεt.
• Priority (9) - Priority of protocol on thiε interface.
• HelloTimer (10) - Periodic rate for sending hello message.
• SplitHorizon (11) - Enable/Disable Split Horizon.
• PoisonReverεe (12) - Enable/Diεable Poison Reverse.
• Snooping (13) - Enable/Disable Snooping.
• Type (14) - Type of media acceεε.
• XmitCost (15) - Transmit Cost.
• Aclld (16) -Asεignε the ACL List ID to be used.
• AcIStatus(17) - Enable/Diεable Acceεε control.
Counterε Interface Table
The Counterε Interface Table for the topology group followε the structure of the common counters groupε with the addition of host in/out, error, and number forwarded counterε.
F. COMMON BASE ROUTER RESOURCE
This section describes the consiεtent manner in which reεources within the router services are managed. The intention of the common resource model allows for easy implementation of routing protcols and provides a scalable and portable implementation of the routing services.
In order to understand the common functional and MIB template for router services, a few basic concepts must be explained. These concepts are illustrated in Fig. 12. A BaseResource 116 is the most baεic component of a router resource. It is a base class object that has built-in management functions and stateε. The common MIB router template is a collection of BaseReεource components laid out in a consistent and formal manner. A ResourceTable 117 iε a MIB manageable table of BaεeReεource objectε. Each BaεeReεource object represents a service, component, or interface object. Almost all BaseResourceε are registered into one of these tables for management purposes. A RscEntry 118 defines an entry of the ResourceTable, e.g., handle or interface number, index, flags, admin status, BaseReεource pointer .
F.1 BaεeReεource Deεcription
BaseResource is the fundamental building block of the common router object model. It is responεible for maintaining the baεic adminiεtrative and operational εtates of the component. Any BaεeReεource componentε that were instantiated by this component are handled appropriately if theεe εtates change. That is, if the administrative state changeε from enabled to diεabled, the component will deactivate and all BaεeReεource componentε that were created by thiε resource are deactivated as well. This allowε management to be done at any level and trickle down to the loweεt resource. Not all resources are manageable through a MIB. The actual manageability of this resource may be defined within the common MIB template. State changes can also occur from internal events or indirectly when a parent resource state has changed.
A BaεeResource is a clasε object in which moεt router componentε are derived. It iε comprised of these attributeε, as illustrated in Fig. 13:
Claεs of Resource: Root Clasε 119 A resource that has no parent and registers with no particular resource table. A starting point for the entire resource tree. Service Claεε 120 A reεource that provideε a system wide service like Host-Delivery or a network protocol like IP and IPX. These resourceε regiεter with a service resource table and are children to some root reεource. Network εervices have a combined MIB template defined.
Component Claεs 121 A resource that is a component of a service reεource and registers into a component resource table. Most Component clasε reεources within the router have a common MIB template defined.
Interface Claεε 122 A resource that is created on each interface that the device has. For each MIB-II interface defined in the router device, an interface resource existε for thiε component. This resource registers into an interface resource table.
An example of a BaseResource Hierarchy for IP and IPX protocols is illustrated in Fig. 14; the resource objects are numbered in a similar manner as in Fig. 13 with the suffix "a" for IP Resources, and "b" for IPX Resourceε. F.2 BaseResource Functional States Administrative Status enum: (1) Other, (2) Enabled, (3) Diεabled
Thiε item iε initialized to some default statuε during conεtruction of reεource and if a MIB template exists, can be changed by management.
Operational Status enum: (1) Other, (2) Enabled, (3) Disabled, (4) Pending Enabled, (5) Pending Disabled, (6) Invalid
Config
Thiε item reflects the current operational εtatuε of the resource. This is the result of a management change to admin εtatuε or some other internal event that may have occurred.
F.3 State Changes
When a root class changeε εtate, it causes major ramifications. The underlying εervice, component, and interface resources muεt change as well. When an Interface clasε changes state, in most cases it only affects the interface object of that component. There are some caseε when a component or interface resource muεt cooperate with other reεources when the εtate changes. This iε handled through configuration eventε. When any BaεeReεource changeε εtate, the Operational-Time iε reεet for thiε resource.
F.4 BaseResource ResourceTable and
Parent Resource Pointers and Handleε
BaseResource components contain pointers to their parent resource and to their respective component table and interface table (if they have one). By using these pointers, resourceε can retrieve uεeful information from the parent and sibling resources aε well aε control the interface reεources from the interface resource table. Also maintained is the component handle number. As BaseReεourceε instantiates other BaseResourceε, thiε handle iε incremented and retrieved and as the children BaseResources register into their appropriate resource table, the parent's current handle number is used aε the handle id or component index.
F.5 Type of Reεource
• Null Type haε no particular identity and does not register in a table.
• Network Protocol Type is a routable protocol like IP, IPX, and DECnet. This type haε a common MIB template defined.
• Config Type addreεεing component resource, consists of the protocol's network addreεs table or syεtem wide network addreεs.
• FIB Type - Thiε resource is a forwarding information base. Most network protocols have them and are used by the forwarding engineε to lookup the next hop interface of of a given network addreεε. Routing protocolε uεe the FIB to depoεit their best next hop interface of a given network addresε. Theεe addreεεeε are learned dynamically through protocolε. There is no common MIB template for thiε type.
• FAS Type - This resource is forwarding engine (service and forward). A protocol creates a FAS object for each interface it is configured on. A FAS receives a packet from an interface, validates its contents, then calls the FIB to resolve the next hop interface to send it out on. FAS objects that are of clasε Interface are created and managed by a parent also of type FAS. This type has a common MIB template defined. • ARP Type - This is an ARP resource
(ARP = Addreεεing Resolution Protocol). This resource is of claεs Interface and Component reεource. ARP iε uεed to reεolve the physical interface addresε of a given network addreεε. Thiε type haε a common MIB template defined.
• Routing Protocol Type - The routing protocol resource is a resource that runs in thread context. It takes on routing protocol attributes defined in the routing protocol, the diεtant vectored, and link state base claεεeε. They contain an interface table of routing protocol objectε of the εame type as well as a topology database, and counters.
• System Wide Type - This resource is on a system wide level . They are BaseReεourceε becauεe they need to be activated and deactivated.
• Component Specific Type - Thiε reεource type iε uεed if BaεeReεource can not generalize well enough. This can be uεed until a εuitable general reεource type iε invented.
F.6 Other Resource Information
The following information is useful for Root, Service, and Component claεε reεourceε. Theεe reεource itemε are needed when management needε to get thiε information for the common MIB template.
• Operational Time - Maintains the time that the resource has been in its current operational status.
• Version Number - Current Version number of service or component clasε reεource.
• Resource Name - A resource can Name its service or component.
• Enterprise MIB Id - Object Identifier for this service or component class resource is paεεed aε a parameter at construction even if there is no MIB template defined. The reεource can then append additional ids where required.
• Naming Tree Identifier - Naming Tree Object Identifier for this service or component class resource.
F.7 Accesε Functionε
Once a BaseResource pointer is located, all information described above is accessible for management through public methods.
The main acceεε functionε of a BaεeReεource are called by the parent BaseReεource. These functions are:
• Construction: A BaseResource is constructed with a MIB enterprise id, default admin status, claεε of resource, type of resource, and pointer to the itε parent BaεeResource.
• Initialization: This is a startup function which allows post construction initialization to occur.
• Activation: Thiε iε called when a component's admin statuε iε aε enabled through management and alεo at εtartup time if the component iε defaulted to enabled. The εtartup time activation allows the resource to perform resource activation after all other resourceε have been created in the device. When activation occurs, the reεource first allows its own activation, then it propagateε the activation to child BaεeReεourceε by performing a TableActivate on all reεource tableε that it containε.
• Deactivation: Thiε iε called when a component's admin statuε is disabled through management or via some internal event. When deactivation occurs, the resource first allows its own deactivation, then it propagateε the deactivation to child BaεeResources by performing a TableDeactivate on all resource tables that it contains. • Reconfiguration: Thiε iε called when an internal reεource event occurred within the root, εervice or component level. When reconfiguration occurs, the reεource firεt allowε the reεource to reconfigure, then it performs a reconfiguration on all resource that it contains.
• Destruction: This is called when the resource object is destroyed during a reinitialization phase.
F.8 BaseResource - Reεource Table Relationεhip
The relationεhips between the various levelε of the BaεeReεource and the Resource Tableε are illuεtrated in Fig. 15.
Service Reεource Table 123 iε a manageable, read-only table under the ctRouter-MIB. Aε εervice BaseResourceε 120 are created, they register their resource pointer and handle id with their proper service ResourceTable.
Component Resource Table 124 iε a manageable, read-only table under the ctRouter-MIB. Aε Component BaεeResources 121 are created by their parent Service resource, they register their resource pointer, handle id, and component index with their proper component ResourceTable, and alεo with the interface ReεourceTable.
Interface Reεource Table 125 iε a manageable table under the Service's MIB. As interface BaseResourceε 122 are created, they regiεter their reεource pointer and interface number into their parent'ε component Interface ResourceTable. Service and Component ResourceTableε are tableε that are created by the Root level BaεeReεource. Interface Reεource Tables are created by component resources when needed. F.9 Resource Table Description
The ResourceTable serves two purposeε: (1) it provideε an ordered list of BaseResourceε of the same clasεes so that they can be initialized, activated, deactivated, reconfigured, and destroyed in a consiεtent manner; and (2) they are manageable either by the ctRouter-MIB for Component and Service type tableε and by the network protocol MIB for interface tables.
F.10 Clasε of Reεource Tables
Service Class - either a network protocol table or system serviceε table instanced by a handle id asεigned by a root level BaεeResource. Thiε instance is used as a handle for the protocol's component resources. Thiε table iε defined aε a read-only MIB.
Component Class - a component resource table, under a service, instanced by the parent's service handle id and a component index. The index iε the handle id of the component reεource aεεigned by the service resource. Thiε table iε defined as a read-only MIB.
Interface Class - an interface table instanced by logical interface number as defined by MIB-II. One RscEntry is created per interface and added to the table. The table size equals the number of interfaces on the device. This table is a MIB manageable and defined in the protocols service MIB. New entries to this cannot be added through the MIB. The interface table entries can be extended to manage additional parameters that are specific to the type of resource. The common MIB template defines those interface tables and their additional leaves.
F.11 ResourceTable Entry Definition
RscEntry - defineε a baεic entry of a ReεourceTable, e.g. ,
• handle or interface number
• index flagε • admin status
• BaseReεource pointer
If the table is an interface table, then additional fields are appended.
F.12 ctRouter High-Level MIB and Router Resource Component Relationshipε
The relationεhip between the ctRouter High-Level MIB and Router Reεource Componentε iε illuεtrated in Fig. 16.
Router Services Table 126 iε a read-only ResourceTable under the ctRouter MIB. As network protocol services like IP, IPX and DECnet are created, they register their resource pointer and handle id into thiε table.
Router Component Resource Table 127 is a manageable, read-only table under the ctRouter-MIB. Aε Component BaεeReεourceε are created by their parent Service reεource, they register their resource pointer, service handle id, and component handle id with the Router Component ResourceTable.
F.13 Router Templateε
The router template defineε a base framework for any router protocol. Eεεentially the router template iε compriεed of a set of functional models that network protcols follow to implement their protocol. Each template defineε a functional implementation and common MIB template as well. All templates illuεtrated in Fig. 17 and described below are object-oriented C++ classes that are derived from BaseReεource.
Network Protocol Template Class
ProtocolResource is a base claεε that defineε the functional implementation of a network protocol. Thiε Reεource coordinates the creation of the component template classes in an orderly way and implements a System Admin MIB so that the network protocol can be managed. It also is a central point that can facilitate reconfiguration events. Component Template Classes
Component Resourceε iε a baεe claεε that defineε the functional implementation of a component object. For example, Baεe Config defineε the functional implementation for configuring and accessing the network address per interface.
Interface Template Classes
Interface Resourceε is a baεe clasε that defines the functional implementation of an interface object. Performance counters of packetε in/out and byteε in/out are maintained in this resource. Access to the interface number and certain interface states (like routing on/off) is accessed here.
G. MIB Navigator
This visual display mechanism allows a user to view and control the router resource tree (all router objects) with the semantics of a file system. Object containers are treated as directories while individual objectε are treated aε a file. Thiε allows complete acceεs into the communication εyεtem without explicit knowledge of communication/networking componentε. A user can start a root for example and peruse until the correct object (file) is provided. Note: thiε iε inεide an embedded system with no file syεtem.
The MIB Navigator εimplifieε the manner in which a network administrator manages a networking device. It provides a line-oriented command line interface which allows the user to quickly browse a device's current configuration, as well as giving the user a more flexible and user-friendly interface to operate with. This interface provides a textual representation of the device's internal configuration database, allowing the user to be able to read or change the configuration of the device with little or no documentation.
The MIB Navigator provides its command line interface by operating a conceptual level above the Simple Network Management Protocol (SNMP) . SNMP operates by passing requests to a device's internal database, the Management Information Base (MIB) . The form of these requests are composed of queries to an object within that databaεe, by uεing the object'ε identifier (OID), which is unique to that object within the database. However, theεe OID's are composed of a string of numerals (i.e., 1.3.6.1.2.1.1.1.0), making them difficult to understand or work with from a user's standpoint.
The MIB Navigator simplifies the format of these requeεtε by providing a textual repreεentation to theεe OID'ε, which are eaεier for the uεer to digeεt than a string of numerals. Along with mapping ASCII nameε to objectε within the MIB, the MIB Navigator alεo placeε a "file εyεtem" type of hierarchy over the MIB. Thiε hierarchical interface allowε the device'ε router objectε to be peruεed, juεt aε a uεer would navigate around in a computer's file εyεtem. The uεer iε now able to roam around the MIB, as if it were a computer file syεtem, and check on pieceε of data, and make changes where necessary without even being required to know the object's identifier. The user can change his/her current location (a "directory" in a file system) or he/she can examine the contents of an object (a "file" in a file syεtem) . The uεer may acceεε a deεired object by using its textual description, instead of its numerical identifier.
The textual representation of objects within the MIB is achieved by storing text strings, along with other data, for each object within the device. When an object is accessed, its corresponding text string is substituted for itε numerical identifier, to provide a seamlesε interface to the object. The requirement that the uεer make use of the numerical identifier for an object in the MIB is removed, allowing that user to use the more informative and intuitive text strings instead.
In Fig. 18, the prior SNMP methodology of accessing a piece of data via the device's configured name is shown. To access this data, the user must make a requeεt of the MIB, and give the object's identifier (i.e., 1.3.6.1.2.1.1.1,0).

Claims

Suppoεe the uεer haε to make εeveral acceεses or changeε, similar to the above. The user is now required to know each object's identifier, each of which can have an identifier of immense length. This becomes a very tediouε task. In Fig. 19, the new methodology of accesεing the same piece of data is shown. To acceεε data, each object in the hierarchy iε uεed by itε textual name. Uεing the text string names for each object yields "get/iso/org .... ". Since "mib-2" iε a very common object to make use of, the user can change his/her current location to it, in order to shorten further acceεses. Having done so, the above acceεs is now shortened to "get system/εyεDescr. " While there have been shown and described εeveral embodiments of the present invention, it will be obvious to those skilled in the art that various changes and modifications may be made therein without departing from the scope of the invention as defined by the appending claimε. CLAIMS
1. A method of providing network routing εerviceε in a communicationε network including a plurality of interconnected multi-protocol routerε, wherein data and methodε for providing εuch εerviceε are united into fundamental logical building blocks of clasεeε and objectε, the method compriεing: initializing each router by instantiating a plurality of base objects common to a number of interconnectivity protocols and technologies; binding each of the baεe objectε to one or more protocolε or network interfaceε to provide protocol-εpecific bound objectε; and in reεponεe to arrival of a data packet at one of the routerε, calling one of the protocol εpecific bound objectε in order to service or forward the data packet.
2. An apparatus for providing network routing serviceε in a communicationε network including a plurality of interconnected multi-protocol routerε, the apparatus comprising: each router including a processor and memory with a program of instructions for providing serviceε including forwarding of network layer data packetε and exchange of network topology information, including an object-oriented program wherein data and methodε for providing εuch network routing εerviceε are united into fundamental logical building blockε of claεεeε and objectε, including: meanε for instantiating a plurality of base objects common to a number of interconnectivity protocolε and technologieε; means for binding each of the base objectε to one or more protocolε or network interfaceε to provide protocol-specific bound objects; and in reεponεe to arrival of a data packet at one of the routers, means for calling one of the protocol-specific bound objects in order to service or forward the data packet.
3. A network routing apparatus compriεing: a) proceεεing means; b) means for storing: a plurality of base objects common to a plurality of interconnectivity protocolε and technologieε; a plurality of protocol-εpecific objectε which extend the functionality of the baεe objectε to provide protocol-specific network layer routing serviceε; c) meanε for connecting the routing apparatuε to a communicationε network; and d) meanε for controlling the proceεεing and εtoring means wherein the proceεεing means instantiateε and runε the objectε to provide network routing services.
4. A distributed network routing system comprising: a network including a plurality of routing apparatuε distributed acrosε the network at network acceεε pointε; each routing apparatus providing network layer routing serviceε, the apparatus including an object- oriented program wherein data and operations are united into fundamental logical building blocks of claεεeε and objectε, and wherein the objects include base objectε which are common to a number of different interconnectivity protocolε and technologieε, and wherein a plurality of protocol-εpecific objects derived from the baεe objects provide protocol-specific network layer routing services.
5. In a routing apparatus for providing network layer routing serviceε, wherein a forwarding and service engine iε used to determine a next hop in a path from a source to a destination, the improvement compriεing: an object-oriented program wherein data and operationε are united into fundamental logical building blockε of claεεes and objectε; an interface object inεtantiated for each media device driver at each interface of the routing apparatuε; and a plurality of εeparate forwarding and εervice engine objectε inεtantiated, each bound to one of the interface objects.
6. The apparatus of claim 5, wherein the interface objectε include: a plurality of baεe interface objects for the registration and tranεmittal of network packetε; and a plurality of protocol-εpecific interface objectε derived from the baεe objectε and εpecific to a particular media device driver.
7. The system of claim 5, wherein the fowarding and service engine objects provide: a. interface to the network; b. unique framing of network packets to each subnet; c. processing packets for each network protocol, including encoding and decoding; d. forwarding packetε, including determination of the next hop; e. filtering packetε, including diεcarding packetε if a εervice iε unavailable or denied; f. utilizing a data cache of active next hopε; and g. addreεε reεolution at the last hop to map a network addresε to a media address.
8. In a method of providing network layer routing services, the improvement comprising: instantiating an interface object for each media device driver on each interface of a routing apparatuε; inεtantiating and binding a separate forwarding engine object to each separate interface object; in responεe to receipt of a data packet on a receiving interface of the routing apparatuε, the interface object for the receiving interface calling a service method in itε bound forwarding engine object; the service method removing the sublayer framing on the network packet; the service method performing validation and extraction of the destination network addresε from the network packet; the εervice method providing a next hop determination by looking up the deεtination network addreεs in a cache memory of active addreεεeε to determine a destination forwarding engine object handle, and, if the destination network addresε iε not located in cache memory, acceεεing a forwarding lookup table for the beεt route to the destination network addresε and updating the cache; and returning the deεtination forwarding engine object handle.
9. The method of claim 8, further compriεing: upon receipt of the deεtination forwarding engine object handle, calling a service method in the deεtination forwarding engine object, the service method validating the destination addresε; the service method looking up in an address cache to obtain a media specific addreεε of the destination; and the service method reframing the packet and transferring it to the destination interface.
10. A method of configuring and controlling services, components and interfaces of a routing apparatus comprising: instantiating a plurality of objectε for each εervice, component and interface of a routing apparatuε, the objectε being related by a claεε hierarchy εuch that each functionally similar service, component or interface is located at the εame level in a claεε hierarchy tree; and implementing an inεt uction to operate on all objectε at a εpecified level in the hierarchy tree.
11. The method of claim 10, wherein each object iε given a text name to facilitate a user's visual navigation of the claεε hierarchy tree.
12. In an aεynchronouε routing apparatuε wherein an event, such aε a timer, data arrival, or change in configuration causes an operation to begin, the improvement comprising: providing an object for each service, component and interface of a routing apparatuε; and including a timer within each object.
13. The apparatuε of claim 12, further compriεing: providing a meanε for terminating a process thread time slice after a predetermined period of time.
14. In a method of providing network routing services, the improvement comprising: providing an object-oriented syεtem for network routing services, wherein a plurality of router objects are inεtantiated and automatically embedded with:
1. common protocol-independent functions of the object, including routing and syεtem functions;
2. functions provided by a baεe resource object clasε which define methodε and data for configuration and control; and
3. functionε provided by a managed object class which define methodε and data for network management.
15. A system for providing network routing εerviceε, the improvement comprising: providing an object-oriented syεtem for network routing εerviceε, including a plurality of router objectε, each router object having:
1. a common protocol-independent functionality which iε shared by all objects of the same clasε;
2. configuration information εpecific to an aεsociated router interface;
3. accesεibility through a router reεource object for inεtantiation and control;
4. automatic perεistence;
5. remote management capability.
16. A system for providing network routing serviceε, the improvement comprising: providing an object-oriented program for network routing services, including a plurality of router objects, each router object having data and methods for managing itself.
17. The εyεtem of claim 16, wherein each object further includeε data and methodε for controlling and configuring itεelf .
18. The system of claim 16, wherein each object further includes data and methodε for automatic perεiεtence.
19. The εyεtem of claim 16, further including handleε for the mapping of object nameε.
20. A network for routing data from a source to a deεtination, the network compriεing: a plurality of diεtributed routerε providing acceεε pointε to end systemε and εupporting multiple routing protocols, each router having a plurality of network interfaces for connections to other routers and end systems; each router including a plurality of forwarding engines wherein one of the forwarding engineε is aεεociated with a different one of the network interfaces; each forwarding engine having a data portion specific to its asεociated interface and which includes configuration information only for that interface and a cache of next-hop addreεεeε; each forwarding engine having acceεε to a common forwarding table for next-hop addresses not within itε associated cache; and each forwarding engine having a method portion common to all interfaces.
21. The network of claim 20, wherein the data and method portionε of each forwarding engine compriεe a forwarding engine object bound to an aεsociated interface object.
22. The network of claim 20, wherein the method portion of each forwarding engine includeε meanε for in-bound proceεεing of a network layer data packet and meanε for out-bound processing of a network layer data packet.
23. The network of claim 20, further including means for registering a network layer protocol to receive and transmit network layer packets at a specific network interface.
24. The network of claim 20, further including a data packet dispatcher and means for registering each forwarding engine with the dispatcher .
25. The network of claim 20, further including means for regiεtering each forwarding engine with the forwarding table.
26. The network of claim 20, wherein each data portion includeε an acceεε list.
27. The network of claim 20, wherein each data portion includes framing information.
28. The network of claim 20, wherein the cache entrieε include framing information and a MAC layer phyεical addreεε.
29. The network of claim 20, wherein each router includeε a host CPU having an internal interface with a destination addreεε.
30. A network for routing data from a source to a destination, the network comprising: a plurality of distributed routers providing acceεs points to end syεtemε and εupporting multiple routing protocolε, each router having a plurality of network interfaceε for connections to other routerε and end εyεtemε; each router having a plurality of autonomous router objects including data and methods for routing, configuration and network management functions; and a base resource object clasε including protocol- independent baεe reεource objectε and meanε for inεtantiating the autonomouε objectε by binding of the autonomouε objectε to the base resource objects.
31. The network of claim 30, further including a baεe managed object clasε including protocol-independent baεe management objectε and meanε for inεtantiating managed objectε by binding to the base management objects.
32. The network of claim 30, wherein the autonomous router object includes a forwarding information base.
33. The network of claim 30, wherein the autonomous router object includes an event or timer.
34. The network of claim 30, further including a non-volatile memory for εtoring the objectε.
35. The network of claim 31, further including a network management syεtem for remote management capability of the managed objects.
36. The network of claim 30, wherein each router includes software and hardware for forwarding data packets at the network layer and exchanging network topology information.
37. The network of claim 30, wherein the autonomous router objects include routing applications, host communications, forwarding, and network interfaces.
38. The network of claim 37, wherein there are multiple instantiations of routing application objects for each individual protocol.
39. The network of claim 37, wherein there are multiple inεtantiationε of forwarding objectε for each individual protocol.
40. The network of claim 30, wherein the autonomous router objects are instantiated for each individual protocol.
41. The network of claim 30, wherein the base resource objects include at least one of: router serviceε, router componentε, router interfaceε, router configuration, and eventε.
42. The network of claim 30, wherein the base resource objects have a common managed information base (MIB) structure and content which enables common control of routing applications.
43. The network of claim 30, wherein the autonomouε router objectε include means to exchange network topology information and means to determine next-hop paths.
44. The network of claim 30, including means to allow a network layer protocol to register to receive network layer data packets matching framing and protocol identifier criteria.
45. The network of claim 30, including means for mapping a network layer address to a framing format, and means for mapping a physical layer addreεε to a network layer addreεε.
46. The network of claim 30, wherein the base resource objects include a router event base class which allows an application thread to wait on multiple events εimultaneouεly.
47. The network of claim 30, wherein the baεe reεource objectε include a cache baεe class.
48. The network of claim 30, wherein the base resource objects include an acceεε control baεe claεε.
PCT/US1995/003606 1994-03-22 1995-03-21 Distributed autonomous object architecture for network layer routing WO1995026090A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP95914816A EP0752180A1 (en) 1994-03-22 1995-03-21 Distributed autonomous object architecture for network layer routing
AU21914/95A AU678109B2 (en) 1994-03-22 1995-03-21 Distributed autonomous object architecture for network layer routing
JP7524807A JPH09506752A (en) 1994-03-22 1995-03-21 Distributed Autonomous Object Architecture for Network Layer Routing

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/216,541 1994-03-22
US08/216,541 US5509123A (en) 1994-03-22 1994-03-22 Distributed autonomous object architectures for network layer routing

Publications (1)

Publication Number Publication Date
WO1995026090A1 true WO1995026090A1 (en) 1995-09-28

Family

ID=22807456

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1995/003606 WO1995026090A1 (en) 1994-03-22 1995-03-21 Distributed autonomous object architecture for network layer routing

Country Status (5)

Country Link
US (2) US5509123A (en)
EP (1) EP0752180A1 (en)
JP (1) JPH09506752A (en)
AU (1) AU678109B2 (en)
WO (1) WO1995026090A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10708341B2 (en) 2013-05-21 2020-07-07 Convida Wireless, Llc Lightweight IoT information model

Families Citing this family (335)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742760A (en) * 1992-05-12 1998-04-21 Compaq Computer Corporation Network packet switch using shared memory for repeating and bridging packets at media rate
US5905723A (en) * 1993-06-23 1999-05-18 Cabletron Systems, Inc. System for achieving scalable router performance
US6047333A (en) * 1994-05-04 2000-04-04 National Semiconductor Corporation Node adapter including hardware arrangement for filtering broadcast data on network
US6633561B2 (en) 1994-05-05 2003-10-14 Sprint Communications Company, L.P. Method, system and apparatus for telecommunications control
US6430195B1 (en) 1994-05-05 2002-08-06 Sprint Communications Company L.P. Broadband telecommunications system interface
US5926482A (en) 1994-05-05 1999-07-20 Sprint Communications Co. L.P. Telecommunications apparatus, system, and method with an enhanced signal transfer point
US6172977B1 (en) 1994-05-05 2001-01-09 Sprint Communications Company, L. P. ATM direct access line system
US5991301A (en) 1994-05-05 1999-11-23 Sprint Communications Co. L.P. Broadband telecommunications system
US6023474A (en) 1996-11-22 2000-02-08 Sprint Communications C.O.L.P. Broadband telecommunications system interface
US6031840A (en) 1995-12-07 2000-02-29 Sprint Communications Co. L.P. Telecommunications system
US6181703B1 (en) 1995-09-08 2001-01-30 Sprint Communications Company L. P. System for managing telecommunications
US6314103B1 (en) 1994-05-05 2001-11-06 Sprint Communications Company, L.P. System and method for allocating bandwidth for a call
US5920562A (en) 1996-11-22 1999-07-06 Sprint Communications Co. L.P. Systems and methods for providing enhanced services for telecommunication call
JPH10500542A (en) 1994-05-05 1998-01-13 スプリント コミュニケーションズ カンパニー，エル．ピー． Method, system (system) and device for telecommunication control
US6564321B2 (en) * 1995-04-28 2003-05-13 Bobo Ii Charles R Systems and methods for storing, delivering, and managing messages
JP3326292B2 (en) * 1994-05-24 2002-09-17 株式会社東芝 Communication device and communication method thereof
US5903754A (en) * 1994-06-21 1999-05-11 Microsoft Corporation Dynamic layered protocol stack
DE59508793D1 (en) * 1994-08-31 2000-11-23 Siemens Ag Procedure for managing dynamic objects in an object-oriented programmed facility
JPH08223195A (en) * 1994-11-22 1996-08-30 At & T Corp Local area hub network allowing expansion of port number andmethod of expanding its port number
US5689645A (en) * 1994-12-01 1997-11-18 Hewlett-Packard Co. Persistence specification system and method for producing persistent and transient submaps in a management station for a data communication network
US5557748A (en) * 1995-02-03 1996-09-17 Intel Corporation Dynamic network configuration
WO1996025754A1 (en) * 1995-02-17 1996-08-22 Bell Communications Research, Inc. Methods and apparatus for implementing data networking system having object-oriented architecture
US5872928A (en) * 1995-02-24 1999-02-16 Cabletron Systems, Inc. Method and apparatus for defining and enforcing policies for configuration management in communications networks
EP0733972B1 (en) 1995-03-22 2003-07-09 Sun Microsystems, Inc. Method and apparatus for managing relationships among objects in a distributed object environment
US6640255B1 (en) * 1995-03-31 2003-10-28 Sun Microsystems, Inc. Method and apparatus for generation and installation of distributed objects on a distributed object system
EP0735472A3 (en) * 1995-03-31 2000-01-19 Sun Microsystems, Inc. Method and apparatus for conspiracy among objects
FR2734068B1 (en) * 1995-05-12 1997-06-20 Bull Sa METHOD FOR CONTROLLING THE EXECUTION OF A CONTROL SCENARIO
US6381639B1 (en) * 1995-05-25 2002-04-30 Aprisma Management Technologies, Inc. Policy management and conflict resolution in computer networks
US6112235A (en) * 1995-06-07 2000-08-29 Spofford; Jason J. Method and apparatus for remotely managing a network hardware device having an embedded server with a client computer across a network
US6393486B1 (en) 1995-06-23 2002-05-21 Cisco Technology, Inc. System and method using level three protocol information for network centric problem analysis and topology construction of actual or planned routed network
US6883034B1 (en) * 1995-06-23 2005-04-19 Cisco Technology, Inc. Method of resolving conflicts in access control lists in router by comparing elements in the lists based on subsumption relations
US5710908A (en) * 1995-06-27 1998-01-20 Canon Kabushiki Kaisha Adaptive network protocol independent interface
DE19523537C2 (en) * 1995-06-28 1998-09-03 Siemens Ag Method and arrangement for controlling performance features of a switching center
US6219718B1 (en) * 1995-06-30 2001-04-17 Canon Kabushiki Kaisha Apparatus for generating and transferring managed device description file
US6094525A (en) * 1995-07-06 2000-07-25 Novell, Inc. Network addressing arrangement for backward compatible routing of an expanded address space
US6249821B1 (en) * 1995-07-14 2001-06-19 Oki Data Americas, Inc. Network object frameworks
US6266708B1 (en) * 1995-07-21 2001-07-24 International Business Machines Corporation Object oriented application program development framework mechanism
US5699350A (en) * 1995-10-06 1997-12-16 Canon Kabushiki Kaisha Reconfiguration of protocol stacks and/or frame type assignments in a network interface device
JP3363292B2 (en) * 1995-10-12 2003-01-08 株式会社日立製作所 Database management system
CA2186795A1 (en) * 1995-11-17 1997-05-18 Cormac John Sreenan Resource management system for a broadband multipoint bridge
US5963554A (en) * 1995-12-26 1999-10-05 Samsung Electronics Co., Ltd. ATM switch device constructed from Banyan network and its installation method
KR100293921B1 (en) * 1995-12-26 2001-09-17 윤종용 Input port numbering method in 3-dimensionally constructed bayan network
US5754788A (en) * 1995-12-28 1998-05-19 Attachmate Corporation Method and system for reconfiguring a communications stack
AU2257097A (en) 1996-02-02 1997-08-22 Sprint Communications Company, L.P. Atm gateway system
US5870550A (en) * 1996-02-26 1999-02-09 Network Engineering Software Web server employing multi-homed, moldular framework
US8117298B1 (en) 1996-02-26 2012-02-14 Graphon Corporation Multi-homed web server
US5938733A (en) * 1996-03-08 1999-08-17 International Business Machines Corporation Object oriented representation of network requests in a client server model
US5809235A (en) * 1996-03-08 1998-09-15 International Business Machines Corporation Object oriented network event management framework
US6243667B1 (en) * 1996-05-28 2001-06-05 Cisco Systems, Inc. Network flow switching and flow data export
US5940393A (en) * 1996-05-28 1999-08-17 Sprint Communications Co. L.P. Telecommunications system with a connection processing system
US5913037A (en) * 1996-07-03 1999-06-15 Compaq Computer Corporation Dynamic management information base manager
US7342581B2 (en) 1996-07-18 2008-03-11 Computer Associates Think, Inc. Method and apparatus for displaying 3-D state indicators
US8621032B2 (en) * 1996-07-18 2013-12-31 Ca, Inc. Method and apparatus for intuitively administering networked computer systems
US5958012A (en) * 1996-07-18 1999-09-28 Computer Associates International, Inc. Network management system using virtual reality techniques to display and simulate navigation to network components
US7680879B2 (en) * 1996-07-18 2010-03-16 Computer Associates Think, Inc. Method and apparatus for maintaining data integrity across distributed computer systems
US5812857A (en) * 1996-08-28 1998-09-22 Extended Systems, Inc. Field configurable embedded computer system
GB9617907D0 (en) 1996-08-28 1996-10-09 British Telecomm Communications network
US6223214B1 (en) 1996-09-06 2001-04-24 Sensiview Corporation Computer implemented virtual sensor object and tangible medium utilizing same
US6078946A (en) * 1996-09-10 2000-06-20 First World Communications, Inc. System and method for management of connection oriented networks
US6510151B1 (en) 1996-09-19 2003-01-21 Enterasys Networks, Inc. Packet filtering in connection-based switching networks
JPH1098524A (en) * 1996-09-20 1998-04-14 Nippon Telegr & Teleph Corp <Ntt> Distributed network
US5748962A (en) * 1996-09-30 1998-05-05 Mci Communications Corporation Common channels for inter-application communications
US6128640A (en) * 1996-10-03 2000-10-03 Sun Microsystems, Inc. Method and apparatus for user-level support for multiple event synchronization
US5956487A (en) * 1996-10-25 1999-09-21 Hewlett-Packard Company Embedding web access mechanism in an appliance for user interface functions including a web server and web browser
US6115380A (en) 1996-11-22 2000-09-05 Sprint Communications Co., L.P. Broadband telecommunications system
CA2271926C (en) 1996-11-22 2005-10-11 Sprint Communications Company, L.P. System and method for transporting a call in a telecommunication network
US6014378A (en) 1996-11-22 2000-01-11 Sprint Communications Company, L.P. Telecommunications tandem system for circuit-based traffic
US6002689A (en) 1996-11-22 1999-12-14 Sprint Communications Co. L.P. System and method for interfacing a local communication device
US6275492B1 (en) * 1996-12-03 2001-08-14 Nortel Networks Limited Method and apparatus for routing data using router identification information
US6141325A (en) * 1996-12-18 2000-10-31 International Business Machines Corporation Paradigm for enabling interoperability between different subnetworks
US6839842B1 (en) * 1996-12-27 2005-01-04 Intel Corporation Method and apparatus for authenticating information
US5940376A (en) * 1997-01-29 1999-08-17 Cabletron Systems, Inc. Method and apparatus to establish a tap-point in a switched network using self-configuring switches having distributed configuration capabilities
US7580919B1 (en) 1997-03-10 2009-08-25 Sonicwall, Inc. Query interface to policy server
US6105027A (en) * 1997-03-10 2000-08-15 Internet Dynamics, Inc. Techniques for eliminating redundant access checking by access filters
US8914410B2 (en) 1999-02-16 2014-12-16 Sonicwall, Inc. Query interface to policy server
US7272625B1 (en) 1997-03-10 2007-09-18 Sonicwall, Inc. Generalized policy server
US7821926B2 (en) 1997-03-10 2010-10-26 Sonicwall, Inc. Generalized policy server
US6408336B1 (en) 1997-03-10 2002-06-18 David S. Schneider Distributed administration of access to information
US6532491B1 (en) 1997-03-24 2003-03-11 Novell, Inc. Processes and apparatuses for managing network devices
US6715147B1 (en) * 1997-03-31 2004-03-30 International Business Machines Corporation Method and system for interfacing a plurality of applications conforming to a standard
US6067299A (en) 1997-04-16 2000-05-23 Sprint Communications Company, L.P. Communications system for providing ATM connections and echo cancellation
US6137800A (en) 1997-05-09 2000-10-24 Sprint Communications Company, L. P. System and method for connecting a call
US6704327B1 (en) 1997-05-09 2004-03-09 Sprint Communications Company, L.P. System and method for connecting a call
US6178170B1 (en) 1997-05-13 2001-01-23 Sprint Communications Company, L. P. System and method for transporting a call
US6094672A (en) * 1997-05-19 2000-07-25 Novell, Inc. Method and system for time synchronization management
US6041042A (en) * 1997-05-27 2000-03-21 Cabletron Systems, Inc. Remote port mirroring system and method thereof
US6246680B1 (en) 1997-06-30 2001-06-12 Sun Microsystems, Inc. Highly integrated multi-layer switch element architecture
US6044418A (en) * 1997-06-30 2000-03-28 Sun Microsystems, Inc. Method and apparatus for dynamically resizing queues utilizing programmable partition pointers
US6094435A (en) * 1997-06-30 2000-07-25 Sun Microsystems, Inc. System and method for a quality of service in a multi-layer network element
US6119196A (en) * 1997-06-30 2000-09-12 Sun Microsystems, Inc. System having multiple arbitrating levels for arbitrating access to a shared memory by network ports operating at different data rates
US6088356A (en) * 1997-06-30 2000-07-11 Sun Microsystems, Inc. System and method for a multi-layer network element
US6115378A (en) * 1997-06-30 2000-09-05 Sun Microsystems, Inc. Multi-layer distributed network element
US6081522A (en) * 1997-06-30 2000-06-27 Sun Microsystems, Inc. System and method for a multi-layer network element
US6016310A (en) * 1997-06-30 2000-01-18 Sun Microsystems, Inc. Trunking support in a high performance network device
US6052738A (en) * 1997-06-30 2000-04-18 Sun Microsystems, Inc. Method and apparatus in a packet routing switch for controlling access at different data rates to a shared memory
US6081512A (en) * 1997-06-30 2000-06-27 Sun Microsystems, Inc. Spanning tree support in a high performance network device
US6049528A (en) * 1997-06-30 2000-04-11 Sun Microsystems, Inc. Trunking ethernet-compatible networks
US6044087A (en) * 1997-06-30 2000-03-28 Sun Microsystems, Inc. Interface for a highly integrated ethernet network element
US5938736A (en) * 1997-06-30 1999-08-17 Sun Microsystems, Inc. Search engine architecture for a high performance multi-layer switch element
US6021132A (en) * 1997-06-30 2000-02-01 Sun Microsystems, Inc. Shared memory management in a switched network element
US6128666A (en) * 1997-06-30 2000-10-03 Sun Microsystems, Inc. Distributed VLAN mechanism for packet field replacement in a multi-layered switched network element using a control field/signal for indicating modification of a packet with a database search engine
US7315893B2 (en) * 1997-07-15 2008-01-01 Computer Associates Think, Inc. Method and apparatus for filtering messages based on context
US20030023721A1 (en) * 1997-07-15 2003-01-30 Computer Associates Think, Inc. Method and apparatus for generating context-descriptive messages
US20030018771A1 (en) * 1997-07-15 2003-01-23 Computer Associates Think, Inc. Method and apparatus for generating and recognizing speech as a user interface element in systems and network management
US6304912B1 (en) 1997-07-24 2001-10-16 Fujitsu Limited Process and apparatus for speeding-up layer-2 and layer-3 routing, and for determining layer-2 reachability, through a plurality of subnetworks
US6345315B1 (en) 1997-08-13 2002-02-05 Sudhindra N. Mishra Method for platform and protocol independent communication between client-server pairs
JPH1165969A (en) * 1997-08-19 1999-03-09 Toshiba Corp Server equipment, communication connecting method and recording medium recording program for connecting communication
US6052724A (en) * 1997-09-02 2000-04-18 Novell Inc Method and system for managing a directory service
DE19740107A1 (en) * 1997-09-12 1999-03-18 Alsthom Cge Alcatel Method for transmitting data packets and network element suitable for carrying out the method
US6148410A (en) * 1997-09-15 2000-11-14 International Business Machines Corporation Fault tolerant recoverable TCP/IP connection router
JP3301359B2 (en) * 1997-09-30 2002-07-15 日本電気株式会社 List management system, method and storage medium
CA2217267A1 (en) * 1997-10-03 1999-04-03 Newbridge Networks Corporation Scalable, robust configuration of edge forwarders in a distributed router
US6134235A (en) 1997-10-08 2000-10-17 At&T Corp. Pots/packet bridge
US6938089B1 (en) * 1997-10-16 2005-08-30 Virtual Access Technology Limited Apparatus and method for controlling access to a service over a communications system
US5999978A (en) * 1997-10-31 1999-12-07 Sun Microsystems, Inc. Distributed system and method for controlling access to network resources and event notifications
US6370592B1 (en) * 1997-11-04 2002-04-09 Hewlett-Packard Company Network interface device which allows peripherals to utilize network transport services
US6393472B1 (en) 1997-12-10 2002-05-21 At&T Corp. Automatic aggregation of network management information in spatial, temporal and functional forms
US6700890B1 (en) 1997-12-22 2004-03-02 Cisco Technology, Inc. Method and apparatus for configuring permanent virtual connection (PVC) information stored on network devices in an ATM network logically configured with subnetworks
US6810040B1 (en) 1997-12-22 2004-10-26 Cisco Technology, Inc. Method and apparatus for configuring network devices
US6216173B1 (en) * 1998-02-03 2001-04-10 Redbox Technologies Limited Method and apparatus for content processing and routing
US6278714B1 (en) * 1998-02-06 2001-08-21 Sun Microsystems, Inc. Efficient hardware implementation of virtual circuit bunching
US6470019B1 (en) 1998-02-20 2002-10-22 Sprint Communications Company L.P. System and method for treating a call for call processing
US6563918B1 (en) 1998-02-20 2003-05-13 Sprint Communications Company, LP Telecommunications system architecture for connecting a call
US6483837B1 (en) 1998-02-20 2002-11-19 Sprint Communications Company L.P. System and method for connecting a call with an interworking system
US6330617B1 (en) 1998-02-27 2001-12-11 Sabre Inc System, method and computer program product for data conversion in a computer network
FR2775804B1 (en) * 1998-03-05 2000-04-14 Alsthom Cge Alcatel METHODS FOR STORING AND UNPACKING ATTRIBUTES OF AN OBJECT
US6330717B1 (en) * 1998-03-27 2001-12-11 Sony Corporation Of Japan Process and system for developing an application program for a distributed adaptive run-time platform
US6160871A (en) 1998-04-10 2000-12-12 Sprint Communications Company, L.P. Communications test system
US6847614B2 (en) * 1998-04-20 2005-01-25 Broadcom Corporation Apparatus and method for unilateral topology discovery in network management
US6519635B1 (en) * 1998-04-30 2003-02-11 Cisco Technology, Inc. SNMP master agent that translates messages to a sub-agent proprietary format using a translation table by the sub-agent
US6049834A (en) * 1998-05-08 2000-04-11 Cisco Technology, Inc. Layer 3 switch unicast protocol
US6317748B1 (en) * 1998-05-08 2001-11-13 Microsoft Corporation Management information to object mapping and correlator
US6260070B1 (en) * 1998-06-30 2001-07-10 Dhaval N. Shah System and method for determining a preferred mirrored service in a network by evaluating a border gateway protocol
US6446121B1 (en) 1998-05-26 2002-09-03 Cisco Technology, Inc. System and method for measuring round trip times in a network using a TCP packet
US6463442B1 (en) * 1998-06-30 2002-10-08 Microsoft Corporation Container independent data binding system
US6571286B2 (en) 1998-07-07 2003-05-27 International Business Machines Corporation Method and system for enhancing communications efficiency in data communications networks
US6286038B1 (en) * 1998-08-03 2001-09-04 Nortel Networks Limited Method and apparatus for remotely configuring a network device
EP0980166A1 (en) * 1998-08-06 2000-02-16 Siemens Aktiengesellschaft Active publishing
US6438100B1 (en) * 1998-08-07 2002-08-20 Alcatel Canada Inc. Method and apparatus for routing server redundancy in a network having carrier scale internetworking
US6697360B1 (en) * 1998-09-02 2004-02-24 Cisco Technology, Inc. Method and apparatus for auto-configuring layer three intermediate computer network devices
US6393026B1 (en) * 1998-09-17 2002-05-21 Nortel Networks Limited Data packet processing system and method for a router
US7339924B1 (en) * 1998-09-30 2008-03-04 Cisco Technology, Inc. Method and apparatus for providing ringing timeout disconnect supervision in remote telephone extensions using voice over packet-data-network systems (VOPS)
US6611531B1 (en) 1998-09-30 2003-08-26 Cisco Technology, Inc. Method and apparatus for routing integrated data, voice, and video traffic
US6256322B1 (en) 1998-10-02 2001-07-03 Canon Kabushiki Kaisha Bundling multiple network management packets
US6728267B1 (en) 1998-12-23 2004-04-27 Nortel Networks Limited Service capable network
US6298381B1 (en) 1998-10-20 2001-10-02 Cisco Technology, Inc. System and method for information retrieval regarding services
US6560196B1 (en) * 1998-11-19 2003-05-06 Cisco Technology, Inc. Method and apparatus for controlling the transmission of cells across a network
JP3228249B2 (en) * 1998-12-04 2001-11-12 日本電気株式会社 Router device
US6556547B1 (en) * 1998-12-15 2003-04-29 Nortel Networks Limited Method and apparatus providing for router redundancy of non internet protocols using the virtual router redundancy protocol
US6389449B1 (en) 1998-12-16 2002-05-14 Clearwater Networks, Inc. Interstream control and communications for multi-streaming digital processors
US7237093B1 (en) 1998-12-16 2007-06-26 Mips Technologies, Inc. Instruction fetching system in a multithreaded processor utilizing cache miss predictions to fetch instructions from multiple hardware streams
US7035997B1 (en) 1998-12-16 2006-04-25 Mips Technologies, Inc. Methods and apparatus for improving fetching and dispatch of instructions in multithreaded processors
US7020879B1 (en) 1998-12-16 2006-03-28 Mips Technologies, Inc. Interrupt and exception handling for multi-streaming digital processors
US7529907B2 (en) 1998-12-16 2009-05-05 Mips Technologies, Inc. Method and apparatus for improved computer load and store operations
US7257814B1 (en) 1998-12-16 2007-08-14 Mips Technologies, Inc. Method and apparatus for implementing atomicity of memory operations in dynamic multi-streaming processors
US6857123B1 (en) 1998-12-18 2005-02-15 International Business Machines Corporation Method and apparatus for a Meta Data Service in a data processing system
US6597701B1 (en) 1998-12-22 2003-07-22 Sprint Communications Company L.P. System and method for configuring a local service control point with a call processor in an architecture
JP2002534842A (en) * 1998-12-23 2002-10-15 ノキア・ワイヤレス・ルーターズ・インコーポレーテッド Unified routing scheme for ad hoc internetworking
US6411922B1 (en) * 1998-12-30 2002-06-25 Objective Systems Integrators, Inc. Problem modeling in resource optimization
US6487717B1 (en) 1999-01-15 2002-11-26 Cummins, Inc. System and method for transmission of application software to an embedded vehicle computer
US6724724B1 (en) 1999-01-21 2004-04-20 Cisco Technology, Inc. System and method for resolving an electronic address
US6850531B1 (en) 1999-02-23 2005-02-01 Alcatel Multi-service network switch
US6980515B1 (en) 1999-02-23 2005-12-27 Alcatel Multi-service network switch with quality of access
US7116679B1 (en) 1999-02-23 2006-10-03 Alcatel Multi-service network switch with a generic forwarding interface
EP1225729A3 (en) * 1999-02-23 2002-08-28 Alcatel Internetworking, Inc. Multi-service network switch with quality of access
CN100477623C (en) * 1999-02-23 2009-04-08 阿尔卡塔尔互联网运行公司 Multibusiness network exchanger having modulator demodulator management
US6674756B1 (en) 1999-02-23 2004-01-06 Alcatel Multi-service network switch with multiple virtual routers
US6789118B1 (en) 1999-02-23 2004-09-07 Alcatel Multi-service network switch with policy based routing
US6717913B1 (en) 1999-02-23 2004-04-06 Alcatel Multi-service network switch with modem pool management
US6560226B1 (en) 1999-02-25 2003-05-06 Sprint Communications Company, L.P. System and method for caching ported number information
US7079530B1 (en) 1999-02-25 2006-07-18 Sprint Communications Company L.P. System and method for caching toll free number information
US6957438B1 (en) 1999-03-26 2005-10-18 Nortel Networks Limited Network device application programming interface
CA2302131A1 (en) * 1999-03-26 2000-09-26 Nortel Networks Corporation Network device application programming interface
US6643705B1 (en) * 1999-03-29 2003-11-04 Microsoft Corporation Routing of electronic messages using a routing map and a stateful script engine
EP1041485A1 (en) * 1999-03-31 2000-10-04 Sony Service Center (Europe) N.V. Object with polymorphism
US6795860B1 (en) 1999-04-05 2004-09-21 Cisco Technology, Inc. System and method for selecting a service with dynamically changing information
US6453460B1 (en) * 1999-04-26 2002-09-17 Hewlett-Packard Company Computer system with single processing environment for executing multiple application programs
US6895088B1 (en) 1999-05-21 2005-05-17 Sprint Communications Company L.P. System and method for controlling a call processing system
US6754219B1 (en) 1999-06-04 2004-06-22 Nortel Networks Limited Modular routing system
US6741590B1 (en) * 1999-07-08 2004-05-25 Cisco Technology, Inc. Method and apparatus for managing a subtended communication network
US6385197B1 (en) * 1999-07-09 2002-05-07 Allied Telesyn International Corp. Virtual port trunking method and apparatus
US6990103B1 (en) * 1999-07-13 2006-01-24 Alcatel Canada Inc. Method and apparatus for providing distributed communication routing
US7068661B1 (en) * 1999-07-13 2006-06-27 Alcatel Canada Inc. Method and apparatus for providing control information in a system using distributed communication routing
US6751634B1 (en) * 1999-08-26 2004-06-15 Microsoft Corporation Method and system for detecting object inconsistency in a loosely consistent replicated directory service
US6772220B1 (en) 1999-09-29 2004-08-03 International Business Machines Corporation Next hop command level addressing and routing
US6654753B1 (en) 1999-09-29 2003-11-25 International Business Machines Corporation Combination associative and directed graph representation of command structures
US6529515B1 (en) * 1999-09-30 2003-03-04 Lucent Technologies, Inc. Method and apparatus for efficient network management using an active network mechanism
US6952703B1 (en) 1999-10-12 2005-10-04 Cisco Technology, Inc. Subsystem application notification method in a centralized router database
US6728723B1 (en) * 1999-10-12 2004-04-27 Cisco Technology, Inc. Method and system for verifying configuration transactions managed by a centralized database
US6704752B1 (en) * 1999-10-12 2004-03-09 Cisco Technology, Inc. Method and system for executing, tracking and restoring temporary router configuration change using a centralized database
US6836463B2 (en) 1999-10-15 2004-12-28 Nokia Corporation System for communicating labeled routing trees to establish preferred paths and source routes with local identifiers in wireless computer networks
US6963572B1 (en) * 1999-10-22 2005-11-08 Alcatel Canada Inc. Method and apparatus for segmentation and reassembly of data packets in a communication switch
US6816497B1 (en) 1999-11-05 2004-11-09 Sprint Communications Company, L.P. System and method for processing a call
US6910082B1 (en) * 1999-11-18 2005-06-21 International Business Machines Corporation Method, system and program products for reducing data movement within a computing environment by bypassing copying data between file system and non-file system buffers in a server
FR2801697B1 (en) * 1999-11-26 2002-01-25 Bull Sa METHOD OF ACCESSING VARIOUS PROTOCOLS TO OBJECTS OF A TREE REPRESENTATIVE OF AT LEAST ONE SYSTEM RESOURCE
US6950434B1 (en) * 1999-12-07 2005-09-27 Advanced Micro Devices, Inc. Arrangement for searching packet policies using multi-key hash searches in a network switch
US6711153B1 (en) * 1999-12-13 2004-03-23 Ascend Communications, Inc. Route lookup engine
US6857026B1 (en) * 1999-12-14 2005-02-15 Nortel Networks Limited Using alternate routes for fail-over in a communication network
US6704780B1 (en) 1999-12-21 2004-03-09 Cisco Technology Efficient representation of system network management object identifiers
US6826195B1 (en) * 1999-12-28 2004-11-30 Bigband Networks Bas, Inc. System and process for high-availability, direct, flexible and scalable switching of data packets in broadband networks
US6674743B1 (en) 1999-12-30 2004-01-06 3Com Corporation Method and apparatus for providing policy-based services for internal applications
US6539394B1 (en) * 2000-01-04 2003-03-25 International Business Machines Corporation Method and system for performing interval-based testing of filter rules
US7324514B1 (en) * 2000-01-14 2008-01-29 Cisco Technology, Inc. Implementing access control lists using a balanced hash table of access control list binary comparison trees
US6694304B1 (en) * 2000-02-17 2004-02-17 Cisco Technology System and method for retrieving network management table entries
US6859452B1 (en) * 2000-03-20 2005-02-22 At&T Corp. Configuration mapping in an atm-based wide area network
US6473763B1 (en) * 2000-03-31 2002-10-29 International Business Machines Corporation System, method and computer program for filtering multi-action rule set
US6850976B1 (en) * 2000-03-31 2005-02-01 Intel Corporation IP router with hierarchical user interface
US6529897B1 (en) * 2000-03-31 2003-03-04 International Business Machines Corporation Method and system for testing filter rules using caching and a tree structure
US7688727B1 (en) 2000-04-17 2010-03-30 Juniper Networks, Inc. Filtering and route lookup in a switching device
US6798777B1 (en) * 2000-04-17 2004-09-28 Juniper Networks, Inc. Filtering and route lookup in a switching device
US7215637B1 (en) 2000-04-17 2007-05-08 Juniper Networks, Inc. Systems and methods for processing packets
US7237138B2 (en) * 2000-05-05 2007-06-26 Computer Associates Think, Inc. Systems and methods for diagnosing faults in computer networks
US7500143B2 (en) * 2000-05-05 2009-03-03 Computer Associates Think, Inc. Systems and methods for managing and analyzing faults in computer networks
US7752024B2 (en) * 2000-05-05 2010-07-06 Computer Associates Think, Inc. Systems and methods for constructing multi-layer topological models of computer networks
AU2001261258A1 (en) * 2000-05-05 2001-11-20 Aprisma Management Technologies, Inc. Help desk systems and methods for use with communications networks
US6611526B1 (en) 2000-05-08 2003-08-26 Adc Broadband Access Systems, Inc. System having a meshed backplane and process for transferring data therethrough
US6853680B1 (en) 2000-05-10 2005-02-08 Bigband Networks Bas, Inc. System and process for embedded cable modem in a cable modem termination system to enable diagnostics and monitoring
EP1154601A1 (en) * 2000-05-12 2001-11-14 Nortel Networks Limited Modular routing system with Routing Application Programm Interface (API)
US7062642B1 (en) * 2000-05-20 2006-06-13 Ciena Corporation Policy based provisioning of network device resources
US7272836B1 (en) * 2000-05-31 2007-09-18 International Business Machines Corporation Method and apparatus for bridging service for standard object identifier based protocols
US6931444B2 (en) * 2000-06-12 2005-08-16 Amdocs (Israel) Ltd. System, method and computer program product for reading, correlating, processing, categorizing and aggregating events of any type
US7313608B1 (en) * 2000-06-21 2007-12-25 Nortel Networks Limited Method and apparatus for using documents written in a markup language to access and configure network elements
US6938095B2 (en) * 2000-06-28 2005-08-30 Pluris, Inc. Method and apparatus for establishing and sharing a virtual change notification list among a plurality of peer nodes
US20020064218A1 (en) * 2000-06-29 2002-05-30 Phonex Broadband Corporation Data link for multi protocol facility distributed communication hub
EP1311947B1 (en) 2000-07-14 2011-01-19 MIPS Technologies, Inc. Instruction fetch and dispatch in multithreaded system
US7388831B2 (en) * 2000-07-26 2008-06-17 Pluris, Inc. Method and apparatus for bond management according to hierarchy
US6553005B1 (en) * 2000-07-26 2003-04-22 Pluris, Inc. Method and apparatus for load apportionment among physical interfaces in data routers
US7464163B1 (en) * 2000-07-27 2008-12-09 International Business Machines Corporation Service provisioning via attribute-based subscription
US7310774B1 (en) * 2000-08-28 2007-12-18 Sanavigator, Inc. Method for displaying switch port information in a network topology display
US7272643B1 (en) 2000-09-13 2007-09-18 Fortinet, Inc. System and method for managing and provisioning virtual routers
DE10049619A1 (en) * 2000-10-05 2002-04-18 Alcatel Sa Process for the provision of services in a network management system with an open system architecture as well as a service object, requirement object and requirement manager for this
US20020147809A1 (en) * 2000-10-17 2002-10-10 Anders Vinberg Method and apparatus for selectively displaying layered network diagrams
US7003559B1 (en) 2000-10-23 2006-02-21 Hewlett-Packard Development Company, L.P. System and method for determining probable network paths between nodes in a network topology
JP3819231B2 (en) * 2000-11-14 2006-09-06 株式会社日立コミュニケーションテクノロジー Network management method and network management system
US7454484B1 (en) * 2000-11-16 2008-11-18 Nortel Networks Limited Method and apparatus for producing a multicast tree
EP1344350A1 (en) * 2000-11-29 2003-09-17 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for forwarding of telecommunications traffic
US6975628B2 (en) * 2000-12-22 2005-12-13 Intel Corporation Method for representing and controlling packet data flow through packet forwarding hardware
US20020124236A1 (en) * 2000-12-27 2002-09-05 Ruths Derek Augustus Samuel Method of manipulating a distributed system of computer-implemented objects
SE521697C2 (en) * 2001-01-25 2003-11-25 Xelerated Ab Devices and method for processing data in a logical pipeline
ITTO20010062A1 (en) * 2001-01-25 2002-07-25 Novamont Spa BINARY MIXTURES OF BIODEGRADABLE ALIPHATIC POLYESTERS AND PRODUCTS OBTAINED FROM THESE.
GB2372672B (en) * 2001-02-27 2003-04-30 3Com Corp Network management apparatus and method for processing events associated with device reboot
US8051212B2 (en) * 2001-04-11 2011-11-01 Mellanox Technologies Ltd. Network interface adapter with shared data send resources
US7230912B1 (en) * 2001-06-14 2007-06-12 Juniper Networks, Inc. Sampling to a next hop
US7043714B2 (en) * 2001-06-28 2006-05-09 International Business Machines Corporation Method, system, and program for using objects in data stores during execution of a workflow
US7100147B2 (en) * 2001-06-28 2006-08-29 International Business Machines Corporation Method, system, and program for generating a workflow
US7069536B2 (en) * 2001-06-28 2006-06-27 International Business Machines Corporation Method, system, and program for executing a workflow
US7031783B2 (en) * 2001-06-29 2006-04-18 Agilent Technologies, Inc. Virtualized generic equipment model data and control router for factory automation
US7047535B2 (en) 2001-07-30 2006-05-16 International Business Machines Corporation Method, system, and program for performing workflow related operations using an application programming interface
US7228547B2 (en) * 2001-07-30 2007-06-05 International Business Machines Corporation Method, system, and program for enabling access to a plurality of services
US7296056B2 (en) * 2001-07-30 2007-11-13 International Business Machines Corporation Method, system, and program for selecting one user to assign a work item in a workflow
US7698427B2 (en) 2001-07-30 2010-04-13 International Business Machines Corporation Method, system, and program for transferring data from an application engine
US20030046422A1 (en) * 2001-09-04 2003-03-06 Ravi Narayanan Object-oriented routing
US20030101252A1 (en) * 2001-10-05 2003-05-29 Globespan Virata Incorporated System and method for supporting SNMP managed networks
WO2003032554A2 (en) * 2001-10-05 2003-04-17 Bbnt Solutions Llc Near-non-blocking switch scheduler for three-stage banyan switches
US7403986B1 (en) 2001-10-18 2008-07-22 Network Equipment Technologies, Inc. Method for synchronizing circuit related objects between network management systems and network control processors
US7447197B2 (en) * 2001-10-18 2008-11-04 Qlogic, Corporation System and method of providing network node services
US7200144B2 (en) 2001-10-18 2007-04-03 Qlogic, Corp. Router and methods using network addresses for virtualization
ATE365412T1 (en) * 2001-12-19 2007-07-15 Alcatel Lucent METHOD FOR ROUTING INFORMATION DISTRIBUTION AND NETWORK ELEMENT
KR100428773B1 (en) * 2002-01-21 2004-04-28 삼성전자주식회사 Router System and Method for Duplication of Forwarding Engine Utilizing
US7054926B1 (en) * 2002-01-23 2006-05-30 Cisco Technology, Inc. Method and apparatus for managing network devices using a parsable string that conforms to a specified grammar
US7035266B2 (en) * 2002-02-26 2006-04-25 Fluke Corporation Network switch discovery method and apparatus
US20030229785A1 (en) * 2002-03-18 2003-12-11 Daseke Michael J. Dynamic hierarchies system and method for thin devices
US20030229726A1 (en) * 2002-03-18 2003-12-11 Daseke Michael J. Default device configuration system and method for thin devices
US8055728B2 (en) * 2002-04-25 2011-11-08 International Business Machines Corporation Remote control of selected target client computers in enterprise computer networks through global master hubs
JP2005524182A (en) * 2002-04-30 2005-08-11 ノキア コーポレイション Tree data exchange management method and apparatus
US7420929B1 (en) 2002-07-02 2008-09-02 Juniper Networks, Inc. Adaptive network flow analysis
US7836295B2 (en) * 2002-07-29 2010-11-16 International Business Machines Corporation Method and apparatus for improving the resilience of content distribution networks to distributed denial of service attacks
US7631106B2 (en) * 2002-08-15 2009-12-08 Mellanox Technologies Ltd. Prefetching of receive queue descriptors
US7254114B1 (en) * 2002-08-26 2007-08-07 Juniper Networks, Inc. Network router having integrated flow accounting and packet interception
US7251215B1 (en) 2002-08-26 2007-07-31 Juniper Networks, Inc. Adaptive network router
US7313100B1 (en) 2002-08-26 2007-12-25 Juniper Networks, Inc. Network device having accounting service card
US7219300B2 (en) * 2002-09-30 2007-05-15 Sanavigator, Inc. Method and system for generating a network monitoring display with animated utilization information
US7167922B2 (en) * 2002-10-18 2007-01-23 Nokia Corporation Method and apparatus for providing automatic ingress filtering
US7367052B1 (en) * 2002-12-04 2008-04-29 Cisco Technology, Inc. Access list key compression
US7308689B2 (en) * 2002-12-18 2007-12-11 International Business Machines Corporation Method, apparatus, and program for associating related heterogeneous events in an event handler
US7353321B2 (en) * 2003-01-13 2008-04-01 Sierra Logic Integrated-circuit implementation of a storage-shelf router and a path controller card for combined use in high-availability mass-storage-device shelves that may be incorporated within disk arrays
ATE492085T1 (en) * 2003-01-28 2011-01-15 Cellport Systems Inc A SYSTEM AND METHOD FOR CONTROLLING APPLICATIONS' ACCESS TO PROTECTED RESOURCES WITHIN A SECURE VEHICLE TELEMATICS SYSTEM
KR100918733B1 (en) * 2003-01-30 2009-09-24 삼성전자주식회사 Distributed router and method for dynamically managing forwarding information
US9032095B1 (en) 2004-01-06 2015-05-12 Juniper Networks, Inc. Routing device having multiple logical routers
US7690040B2 (en) 2004-03-10 2010-03-30 Enterasys Networks, Inc. Method for network traffic mirroring with data privacy
US7411957B2 (en) * 2004-03-26 2008-08-12 Cisco Technology, Inc. Hardware filtering support for denial-of-service attacks
US7346370B2 (en) * 2004-04-29 2008-03-18 Cellport Systems, Inc. Enabling interoperability between distributed devices using different communication link technologies
US7472177B2 (en) * 2004-06-23 2008-12-30 Nokia Inc. System and method for selecting of versions for SNMP communication
US7546635B1 (en) 2004-08-11 2009-06-09 Juniper Networks, Inc. Stateful firewall protection for control plane traffic within a network device
EP1782293A2 (en) * 2004-08-20 2007-05-09 Enterasys Networks, Inc. System, method and apparatus for traffic mirror setup, service and security in communication networks
US7205920B2 (en) * 2004-09-17 2007-04-17 Analog Devices, Inc. Continuous-time-sigma-delta DAC using chopper stabalization
WO2006091247A2 (en) * 2004-11-12 2006-08-31 Taser International, Inc. Systems and methods for electronic weaponry having audio and/or video recording capability
JP2006227696A (en) * 2005-02-15 2006-08-31 Toshiba Corp Method for wiring semiconductor integrated circuit and recording medium storing software for wiring
US7769859B1 (en) * 2005-04-15 2010-08-03 Cisco Technology, Inc. Controlling access to managed objects in networked devices
JP4855710B2 (en) * 2005-04-28 2012-01-18 株式会社東芝 Software plug-in method and application program
US7895308B2 (en) * 2005-05-11 2011-02-22 Tindall Steven J Messaging system configurator
US20060282502A1 (en) * 2005-06-10 2006-12-14 Koshak Richard L Method and system for translation of electronic data and software transport protocol with reusable components
CN100531045C (en) * 2005-07-15 2009-08-19 华为技术有限公司 Data management method and system based on simple network management protocol
US9055093B2 (en) * 2005-10-21 2015-06-09 Kevin R. Borders Method, system and computer program product for detecting at least one of security threats and undesirable computer files
US20070150593A1 (en) * 2005-12-28 2007-06-28 Telefonaktiebolaget Lm Ericsson (Publ) Network processor and reference counting method for pipelined processing of packets
US7904588B2 (en) * 2006-01-10 2011-03-08 Cisco Technology, Inc. Method and system for creating an overlay structure for management information bases
US7633944B1 (en) 2006-05-12 2009-12-15 Juniper Networks, Inc. Managing timeouts for dynamic flow capture and monitoring of packet flows
US7747737B1 (en) 2006-05-12 2010-06-29 Juniper Networks, Inc. Network device having service card for dynamic flow capture and monitoring of packet flows
US9003292B2 (en) * 2006-07-06 2015-04-07 LiveAction, Inc. System and method for network topology and flow visualization
US8218453B2 (en) * 2007-02-08 2012-07-10 Telefonaktiebolaget Lm Ericsson (Publ) Network router and method of configuring a network router
US20090006435A1 (en) * 2007-06-28 2009-01-01 Cisco Technology, Inc. Object identifier awareness for network device notifications
US8027293B2 (en) * 2007-07-16 2011-09-27 Cellport Systems, Inc. Communication channel selection and use
US7752300B2 (en) * 2007-11-19 2010-07-06 International Business Machines Corporation Automatically determining management information base modules for a device
US8339959B1 (en) 2008-05-20 2012-12-25 Juniper Networks, Inc. Streamlined packet forwarding using dynamic filters for routing and security in a shared forwarding plane
US8955107B2 (en) * 2008-09-12 2015-02-10 Juniper Networks, Inc. Hierarchical application of security services within a computer network
US8775651B2 (en) * 2008-12-12 2014-07-08 Raytheon Company System and method for dynamic adaptation service of an enterprise service bus over a communication platform
US7957400B2 (en) * 2009-03-26 2011-06-07 Terascale Supercomputing Inc. Hierarchical network topology
US7957385B2 (en) * 2009-03-26 2011-06-07 Terascale Supercomputing Inc. Method and apparatus for packet routing
US20100250784A1 (en) * 2009-03-26 2010-09-30 Terascale Supercomputing Inc. Addressing Scheme and Message Routing for a Networked Device
JP5383415B2 (en) * 2009-10-02 2014-01-08 キヤノン株式会社 COMMUNICATION DEVICE, COMMUNICATION DEVICE COMMUNICATION METHOD, AND PROGRAM
US8369345B1 (en) 2009-11-13 2013-02-05 Juniper Networks, Inc. Multi-router system having shared network interfaces
US8307030B1 (en) 2010-04-20 2012-11-06 Juniper Networks, Inc. Large-scale timer management
US8619773B2 (en) * 2010-07-29 2013-12-31 Cisco Technology, Inc. Service request packet including an exterior network protocol attribute
US8774010B2 (en) 2010-11-02 2014-07-08 Cisco Technology, Inc. System and method for providing proactive fault monitoring in a network environment
US8559341B2 (en) 2010-11-08 2013-10-15 Cisco Technology, Inc. System and method for providing a loop free topology in a network environment
US8982733B2 (en) 2011-03-04 2015-03-17 Cisco Technology, Inc. System and method for managing topology changes in a network environment
US8670326B1 (en) 2011-03-31 2014-03-11 Cisco Technology, Inc. System and method for probing multiple paths in a network environment
US8724517B1 (en) 2011-06-02 2014-05-13 Cisco Technology, Inc. System and method for managing network traffic disruption
US8830875B1 (en) 2011-06-15 2014-09-09 Cisco Technology, Inc. System and method for providing a loop free topology in a network environment
US8948174B2 (en) * 2011-06-29 2015-02-03 Juniper Networks, Inc. Variable-based forwarding path construction for packet processing within a network device
US9251535B1 (en) 2012-01-05 2016-02-02 Juniper Networks, Inc. Offload of data transfer statistics from a mobile access gateway
US8249230B1 (en) 2012-01-09 2012-08-21 EC Data Systems, Inc. Scalable and flexible internet fax architecture
US9971787B2 (en) * 2012-07-23 2018-05-15 Red Hat, Inc. Unified file and object data storage
US10511497B2 (en) 2012-10-04 2019-12-17 Fortinet, Inc. System and method for dynamic management of network device data
US9450846B1 (en) 2012-10-17 2016-09-20 Cisco Technology, Inc. System and method for tracking packets in a network environment
US9769034B2 (en) 2012-12-14 2017-09-19 Futurewei Technologies, Inc. Method and apparatus for policy based routing in information centric networking based home networks
CN103888359B (en) * 2012-12-21 2017-04-12 杭州华三通信技术有限公司 Route calculation method and network device
US8874626B2 (en) 2013-02-01 2014-10-28 Red Hat, Inc. Tracking files and directories related to unsuccessful change operations
US8983908B2 (en) 2013-02-15 2015-03-17 Red Hat, Inc. File link migration for decommisioning a storage server
US11016941B2 (en) 2014-02-28 2021-05-25 Red Hat, Inc. Delayed asynchronous file replication in a distributed file system
RU2580004C2 (en) * 2014-03-06 2016-04-10 Андрей Витальевич Михайлов Automatic firewall
US9986029B2 (en) 2014-03-19 2018-05-29 Red Hat, Inc. File replication using file content location identifiers
US10025808B2 (en) 2014-03-19 2018-07-17 Red Hat, Inc. Compacting change logs using file content location identifiers
US9965505B2 (en) 2014-03-19 2018-05-08 Red Hat, Inc. Identifying files in change logs using file content location identifiers
US10277778B2 (en) 2014-06-24 2019-04-30 Ec Data Systems Inc. Audit logging for a secure, scalable and flexible internet fax architecture

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0405829A2 (en) * 1989-06-30 1991-01-02 AT&T Corp. Object oriented software system architecture
EP0549504A2 (en) * 1991-10-09 1993-06-30 International Business Machines Corporation Process control for real time systems
US5251205A (en) * 1990-09-04 1993-10-05 Digital Equipment Corporation Multiple protocol routing

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4692918A (en) * 1984-12-17 1987-09-08 At&T Bell Laboratories Reliable local data network arrangement
US5418970A (en) * 1986-12-17 1995-05-23 Massachusetts Institute Of Technology Parallel processing system with processor array with processing elements addressing associated memories using host supplied address value and base register content
US5088032A (en) * 1988-01-29 1992-02-11 Cisco Systems, Inc. Method and apparatus for routing communications among computer networks
US5142622A (en) * 1989-01-31 1992-08-25 International Business Machines Corporation System for interconnecting applications across different networks of data processing systems by mapping protocols across different network domains
US5095480A (en) * 1989-06-16 1992-03-10 Fenner Peter R Message routing system for shared communication media networks
GB8927623D0 (en) * 1989-12-06 1990-02-07 Bicc Plc Repeaters for secure local area networks
CA2038458C (en) * 1990-03-19 1999-01-26 Susumu Tominaga Route regulating apparatus
US5301303A (en) * 1990-04-23 1994-04-05 Chipcom Corporation Communication system concentrator configurable to different access methods
US5226120A (en) * 1990-05-21 1993-07-06 Synoptics Communications, Inc. Apparatus and method of monitoring the status of a local area network
US5261044A (en) * 1990-09-17 1993-11-09 Cabletron Systems, Inc. Network management system using multifunction icons for information display
US5274631A (en) * 1991-03-11 1993-12-28 Kalpana, Inc. Computer network switching system
US5317568A (en) * 1991-04-11 1994-05-31 Galileo International Partnership Method and apparatus for managing and facilitating communications in a distributed hetergeneous network
US5224098A (en) * 1991-07-17 1993-06-29 International Business Machines Corporation Compensation for mismatched transport protocols in a data communications network
US5255368A (en) * 1991-08-19 1993-10-19 Hewlett-Packard Company Method for selecting data communications paths for routing messages between processors in a parallel processing computer system organized as a hypercube
DE69123149T2 (en) * 1991-09-03 1997-03-13 Hewlett Packard Co Message routing apparatus
US5313465A (en) * 1992-05-13 1994-05-17 Digital Equipment Corporation Method of merging networks across a common backbone network
JP2826416B2 (en) * 1992-06-05 1998-11-18 日本電気株式会社 Connection router between local area networks
US5499343A (en) * 1993-12-17 1996-03-12 Taligent, Inc. Object-oriented networking system with dynamically configurable communication links
US5485455A (en) * 1994-01-28 1996-01-16 Cabletron Systems, Inc. Network having secure fast packet switching and guaranteed quality of service

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0405829A2 (en) * 1989-06-30 1991-01-02 AT&T Corp. Object oriented software system architecture
US5251205A (en) * 1990-09-04 1993-10-05 Digital Equipment Corporation Multiple protocol routing
EP0549504A2 (en) * 1991-10-09 1993-06-30 International Business Machines Corporation Process control for real time systems

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10708341B2 (en) 2013-05-21 2020-07-07 Convida Wireless, Llc Lightweight IoT information model
US11159606B2 (en) 2013-05-21 2021-10-26 Convida Wireless, Llc Lightweight IoT information model
US11368522B2 (en) 2013-05-21 2022-06-21 Convida Wireless, Llc Lightweight IoT information model
US11677812B2 (en) 2013-05-21 2023-06-13 Convida Wireless, Llc Lightweight IoT information model

Also Published As

Publication number Publication date
US5509123A (en) 1996-04-16
JPH09506752A (en) 1997-06-30
AU2191495A (en) 1995-10-09
US5951649A (en) 1999-09-14
AU678109B2 (en) 1997-05-15
EP0752180A1 (en) 1997-01-08

Similar Documents

Publication Publication Date Title
AU678109B2 (en) Distributed autonomous object architecture for network layer routing
US5913037A (en) Dynamic management information base manager
AU681063B2 (en) Network having secure fast packet switching and guaranteed quality of service
US5850397A (en) Method for determining the topology of a mixed-media network
US5751971A (en) Internet protocol (IP) work group routing
US8054832B1 (en) Methods and apparatus for routing between virtual resources based on a routing location policy
US8190769B1 (en) Methods and apparatus for provisioning at a network device in response to a virtual resource migration notification
US20030074436A1 (en) Management information base object model
EP0926859A2 (en) Multiple virtual router
WO2005109773A2 (en) Remote management of communication devices
EP1479192B1 (en) Method and apparatus for managing configuration of a network
US20040136320A1 (en) Management of protocol information in pnni hierarchical networks
Cisco Configuring Source-Route Bridging
Cisco Virtual LANs
EP1518367B1 (en) Vlan inheritance
Cisco Catalyst 2820/1900 Enterprise Edition Software VLANS
Cisco Virtual LANs
Cisco Virtual LANs
Cisco Virtual LANs
Cisco Virtual LANs
Cisco Configuring Source-Route Bridging
Cisco Configuring Source-Route Bridging
Cisco Catalyst 2820/1900 Enterprise Edition Software VLANS
Cisco Release Notes for the 1600 Series for Cisco IOS Release 11.2P
Cisco Release Notes for the 1600 Series for Cisco IOS Release 11.2P

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1995914816

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1995914816

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1995914816

Country of ref document: EP