U.S. patent application number 13/620305 was filed with the patent office on 2013-07-04 for generating metrics for networked devices.
The applicant listed for this patent is NORMAN ARI HIRSCHMAN, JOHN W. PIERCE, ERIC M. WALL. Invention is credited to NORMAN ARI HIRSCHMAN, JOHN W. PIERCE, ERIC M. WALL.
Application Number | 20130173785 13/620305 |
Document ID | / |
Family ID | 27668233 |
Filed Date | 2013-07-04 |
United States Patent
Application |
20130173785 |
Kind Code |
A1 |
HIRSCHMAN; NORMAN ARI ; et
al. |
July 4, 2013 |
Generating Metrics for Networked Devices
Abstract
Groups of network devices may be identified automatically based
on interface tags associated with network device interfaces such
that network devices within a group are automatically identified,
periodically or otherwise, based on an association of one or more
common interface tags between the group and the network device
interface.
Inventors: |
HIRSCHMAN; NORMAN ARI;
(Chevy Chase, MD) ; WALL; ERIC M.; (Reston,
VA) ; PIERCE; JOHN W.; (Washington, DC) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
HIRSCHMAN; NORMAN ARI
WALL; ERIC M.
PIERCE; JOHN W. |
Chevy Chase
Reston
Washington |
MD
VA
DC |
US
US
US |
|
|
Family ID: |
27668233 |
Appl. No.: |
13/620305 |
Filed: |
September 14, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12792111 |
Jun 2, 2010 |
8331257 |
|
|
13620305 |
|
|
|
|
12271208 |
Nov 14, 2008 |
7739370 |
|
|
12792111 |
|
|
|
|
11604393 |
Nov 27, 2006 |
7461145 |
|
|
12271208 |
|
|
|
|
10184071 |
Jun 28, 2002 |
7143158 |
|
|
11604393 |
|
|
|
|
60356124 |
Feb 14, 2002 |
|
|
|
Current U.S.
Class: |
709/224 |
Current CPC
Class: |
H04L 41/12 20130101;
H04L 43/0876 20130101 |
Class at
Publication: |
709/224 |
International
Class: |
H04L 12/26 20060101
H04L012/26 |
Claims
1. A method for generating network traffic metrics for a group of
network devices, comprising: causing association of tags with
interfaces representing network devices that belong to multiple,
different groups of network devices, each tag identifying at least
one of the multiple, different groups of network devices;
identifying a particular tag that corresponds to and enables
monitoring of a particular group of network devices included in the
multiple, different groups of network devices; identifying, from
among the interfaces associated with the tags, a subset of the
interfaces that were associated with the particular tag that
corresponds to and enables monitoring of the particular group of
network devices; accessing network traffic metrics measured for
each interface included in the identified subset of the interfaces
that were associated with the particular tag; aggregating the
accessed network traffic metrics to determine collective network
traffic metrics for the particular group of network devices; and
storing data representing the collective network traffic metrics
determined for the particular group of network devices based on the
aggregation of the accessed network traffic metrics.
2. The method of claim 1, wherein accessing network traffic metrics
measured for each interface included in the identified subset of
the interfaces that were associated with the particular tag
comprises accessing usage data describing usage of an external
resource measured for each interface included in the identified
subset of the interfaces that were associated with the particular
tag.
3. The method of claim 1, wherein accessing network traffic metrics
measured for each interface included in the identified subset of
the interfaces that were associated with the particular tag
comprises gathering statistics for communication with an entity for
each interface included in the identified subset of the interfaces
that were associated with the particular tag.
4. The method of claim 1, wherein causing association of tags with
interfaces representing network devices that belong to multiple,
different groups of network devices comprises causing association
of tags with network communication ports that represent a lowest
level of network connectivity for the network devices.
5. The method of claim 1, wherein causing association of tags with
interfaces representing network devices that belong to multiple,
different groups of network devices comprises storing a tag in a
network device interface field designed for other purposes and
including a tag identifier in the network device interface field to
distinguish the tag from other data in the network device interface
field.
6. The method of claim 1, wherein causing association of tags with
interfaces representing network devices that belong to multiple,
different groups of network devices comprises causing association
of multiple, different tags with a single interface representing a
network device and apportioning network traffic through the single
interface among the multiple, different tags associated with the
single interface.
7. The method of claim 6, wherein apportioning network traffic
through the single interface among the multiple, different tags
associated with the single interface comprises using multipliers
corresponding to the multiple, different tags to apportion the
network traffic through the single interface among the multiple,
different tags associated with the single interface.
8. The method of claim 1, wherein causing association of tags with
interfaces representing network devices that belong to multiple,
different groups of network devices comprises reformatting a tag
associated with an interface of a network device prior to storage
of the tag.
9. The method of claim 8, wherein identifying, from among the
interfaces associated with the tags, the subset of the interfaces
that were associated with the particular tag that corresponds to
and enables monitoring of the particular group of network devices
comprises reformatting the particular tag in a query used to
identify the subset of the interfaces that were associated with the
particular tag that corresponds to and enables monitoring of the
particular group of network devices.
10. The method of claim 1, wherein causing association of tags with
interfaces representing network devices that belong to multiple,
different groups of network devices comprises maintaining a history
file that tracks timing data describing addition of tags to
interfaces and removal of tags from interfaces.
11. A system including at least one processor configured to perform
operation comprising: causing association of tags with interfaces
representing network devices that belong to multiple, different
groups of network devices, each tag identifying at least one of the
multiple, different groups of network devices; identifying a
particular tag that corresponds to and enables monitoring of a
particular group of network devices included in the multiple,
different groups of network devices; identifying, from among the
interfaces associated with the tags, a subset of the interfaces
that were associated with the particular tag that corresponds to
and enables monitoring of the particular group of network devices;
accessing network traffic metrics measured for each interface
included in the identified subset of the interfaces that were
associated with the particular tag; aggregating the accessed
network traffic metrics to determine collective network traffic
metrics for the particular group of network devices; and storing
data representing the collective network traffic metrics determined
for the particular group of network devices based on the
aggregation of the accessed network traffic metrics.
12. The system of claim 11, wherein accessing network traffic
metrics measured for each interface included in the identified
subset of the interfaces that were associated with the particular
tag comprises accessing usage data describing usage of an external
resource measured for each interface included in the identified
subset of the interfaces that were associated with the particular
tag.
13. The system of claim 11, wherein accessing network traffic
metrics measured for each interface included in the identified
subset of the interfaces that were associated with the particular
tag comprises gathering statistics for communication with an entity
for each interface included in the identified subset of the
interfaces that were associated with the particular tag.
14. The system of claim 11, wherein causing association of tags
with interfaces representing network devices that belong to
multiple, different groups of network devices comprises causing
association of tags with network communication ports that represent
a lowest level of network connectivity for the network devices.
15. The system of claim 11, wherein causing association of tags
with interfaces representing network devices that belong to
multiple, different groups of network devices comprises storing a
tag in a network device interface field designed for other purposes
and including a tag identifier in the network device interface
field to distinguish the tag from other data in the network device
interface field.
16. The system of claim 11, wherein causing association of tags
with interfaces representing network devices that belong to
multiple, different groups of network devices comprises causing
association of multiple, different tags with a single interface
representing a network device and apportioning network traffic
through the single interface among the multiple, different tags
associated with the single interface.
17. The system of claim 16, wherein apportioning network traffic
through the single interface among the multiple, different tags
associated with the single interface comprises using multipliers
corresponding to the multiple, different tags to apportion the
network traffic through the single interface among the multiple,
different tags associated with the single interface.
18. The system of claim 11, wherein causing association of tags
with interfaces representing network devices that belong to
multiple, different groups of network devices comprises
reformatting a tag associated with an interface of a network device
prior to storage of the tag.
19. The system of claim 18, wherein identifying, from among the
interfaces associated with the tags, the subset of the interfaces
that were associated with the particular tag that corresponds to
and enables monitoring of the particular group of network devices
comprises reformatting the particular tag in a query used to
identify the subset of the interfaces that were associated with the
particular tag that corresponds to and enables monitoring of the
particular group of network devices.
20. The system of claim 11, wherein causing association of tags
with interfaces representing network devices that belong to
multiple, different groups of network devices comprises maintaining
a history file that tracks timing data describing addition of tags
to interfaces and removal of tags from interfaces.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application is a continuation of U.S.
application Ser. No. 12/792,111, filed Jun. 2, 2010, which is a
continuation of U.S. application Ser. No. 12/271,208, filed Nov.
14, 2008, which is now issued as U.S. Pat. No. 7,739,370, which is
a continuation of U.S. application Ser. No. 11/604,393, filed Nov.
27, 2006, which is now issued as U.S. Pat. No. 7,461,145, which is
a continuation of U.S. application Ser. No. 10/184,071, filed Jun.
28, 2002, which is now issued as U.S. Pat. No. 7,143,158, which
claims the benefit of and priority to U.S. provisional application
No. 60/356,124, filed Feb. 14, 2002. Each of the aforementioned
patent(s) and application(s) are hereby incorporated by reference
in their entirety.
TECHNICAL FIELD
[0002] This invention relates to automating the aggregation of
metrics for multiple network devices.
BACKGROUND OF THE INVENTION
[0003] LAN administrators and network engineers sometimes need to
obtain metrics for devices in their network, particularly with
respect to network traffic input and output by one or more network
devices. If obtainable, these performance metrics serve several
purposes. For example, they may be useful in evaluating internal
network performance and distribution of network traffic, enabling
reconfiguration and optimization of network resources. They also
may be useful in monitoring traffic communicated between the
network devices and external devices or services, enabling
evaluation of (1) internal network resource utilization and (2)
external resource and service utilization by network devices.
[0004] In various applications, such as those described above, it
often is desirable to obtain performance metrics for a collection
or group of network devices, which may or may not be physically
proximate or otherwise grouped. For instance, to determine external
device/service utilization by internal network devices, it may be
necessary to obtain aggregate metrics for the logical grouping of
network devices interfacing with and utilizing an external
device/service. Similarly, to determine network resource
utilization by an external device/service, it may be necessary to
obtain aggregate metrics for network devices used to make available
the network resource.
[0005] Independent lists may be manually established and maintained
to enable grouping of devices or interfaces from which data is
sought. However, because these lists are manually maintained, they
often become incomplete or outdated.
SUMMARY
[0006] Groups of network devices may instead be identified
automatically based on electronic interface tags associated with
network device interfaces such that network devices within a group
are automatically identified, periodically or otherwise, based on
an association of one or more common interface tags between the
group and the network device interface.
[0007] The details of one or more implementations are set forth in
the accompanying drawings and the description below. Other features
will be apparent from the description and drawings, and from the
claims.
DESCRIPTION OF DRAWINGS
[0008] FIG. 1 is a flow chart of a process for automatically
aggregating metrics for more than one network device.
[0009] FIG. 2A is a flow chart of a process for identifying network
resources available for aggregation.
[0010] FIG. 2B illustrates an example of an interface tag editor
that can be used to create and edit interface tag definitions.
[0011] FIG. 3A is a flow chart of a process for automating the
aggregation of metrics from identified network resources.
[0012] FIG. 3B illustrates a group editor that may be used to
create and maintain a group definitions table that relates group
names to their defining tags.
[0013] FIG. 3C is a flow chart of a process for automatically
aggregating metrics from network device interfaces having
identified tags associated therewith.
[0014] FIGS. 3D and 3E illustrate history files that are useful for
tracking temporal changes in the association of interfaces to
groups.
[0015] FIG. 4A is a report showing metrics for network devices that
belong to the group "peering-CW."
[0016] FIGS. 4B and 4C illustrate a graphical representation of the
data shown by FIG. 4A.
[0017] FIGS. 5A-5C illustrate billing and other financial and
statistical reports.
[0018] FIGS. 6A and 6B are block diagrams of a communications
system for implementing techniques described with respect to FIGS.
1-5C.
[0019] Like reference symbols in the various drawings indicate like
elements.
DETAILED DESCRIPTION
[0020] Aggregation of metrics for network resources requires
organization of network devices/resources. For example, to
aggregate network traffic metrics for all network devices utilizing
an external resource, it may be necessary to (1) identify the
network devices utilizing the external resource, and (2) measure
traffic metrics at those devices attributable to usage of the
external resource. More specific examples follow. If an online
service provider (OSP) is charged by its peers (e.g., Sprint) based
on the traffic routed from the OSP to the peer, it is helpful to
identify all OSP network devices routing traffic to the peer and to
measure the traffic metrics at those identified OSP network devices
that represent communications sent to the peer. Similarly, a group
of network devices may be identified based on tags associated with
interfaces therefore, and the "health" or error status of those
devices can be collectively monitored. Where the group represents
devices enabling all communications with another entity, the tags
can be used to gather and monitor statistics for communication with
the entity.
[0021] Referring to FIG. 1, the process for automatically
aggregating metrics for more than one network device may include
identifying network resources for aggregation purposes (110),
automating the aggregation of metrics from the identified resources
(120), and generating an output such as a report or strategic
decision based on the aggregated results (130).
[0022] Referring to FIG. 2A, network resources available for
aggregation may be identified (110) by generating or accessing one
or more interface tags for use (210) and by associating appropriate
interface tags with network device interfaces (220).
[0023] FIG. 2B illustrates an example of a interface tag editor
that can be used to create and edit interface tag definitions
(210). Using such a table, a list of available interface tags and
their related descriptions may be maintained as a resource to be
referenced when seeking to associate consistent interface tags with
network device interfaces.
[0024] Tags typically are associated with interfaces (220) for
network devices that represent communication points with other
network devices. For instance, rather than associating a tag with a
router that uses several blades to support connectivity to various
devices, or even associating a tag with an interface for a router
blade that uses several ports to support connectivity to various
devices, tags tend to be associated with the lowest-level of
network connectivity, the ports in this example. Below are examples
of different line cards available for Cisco routers, each having at
least one port that contains a tagable interface:
[0025]
http://www.cisco.com/univercd/cc/td/doc/pcat/qoc48.sub.--11.htm,
[0026]
http://www.cisco.com/univercd/cc/td/doc/pcat/oc12.sub.--12.htm,
[0027]
http://www.cisco.com/univercd/cc/td/doc/pcat/gget.sub.--13.htm,
[0028]
http://www.cisco.com/univercd/cc/td/doc/pcat/gget.sub.--11.htm,
and
[0029]
http://www.cisco.com/univercd/cc/td/doc/pcat/oc3stml1.htm.
[0030] As will be better understood when groupings are discussed
with respect to step 120, by associating tags with network device
interfaces representing a low (e.g., perhaps the lowest level) of
connectivity, tags associated with a particular network device may
be modified using the interface accessed by technicians charged
with configuring or reconfiguring that network device, increasing
the likelihood that network configuration changes will be
documented in a meaningful and timely manner.
[0031] A dedicated field may be provided in a network device
interface for storage of tags. Alternatively, tags may be stored by
network device interface fields designed for other purposes, and
may supplant, replace or supplement data in those fields (e.g.,
notes or title). When supplementing other data, a tag identifier
(e.g., "T") or protocol (e.g., "T=tag name") may be used to
distinguish the tag from the other data in the field.
[0032] Below are examples of several instances of tags inserted
into and supplementing data within the if Descr interface
description SNMP (Simple Network Management Protocol) variable
field, which is a variable field under the SNMP that is contained
within the network interface to allow users to input any type of
field (e.g., a notes field). In these examples, the tag is
distinguished from other data within the title field using a tag
identifier ("T") and a tag identifying protocol ("(T=tag
name)").
TABLE-US-00001 ifDescr field. Device Name & Interface The tag
is the part marked as (T = . . . ) pop1-sun.atdn.net, POS0/3,
pop1-sun-P0-3-CandW (204.172.156.68/ 30 CandW:1538408) (T = pCW)
pop2-dal.atdn.net, POS2/0, pop2-dal-p2-0-C&W (204.172.138.128/
30 CW:1495797) (T = pCW) pop2-nye.atdn.net, POS3/0,
pop2-nye-P3-0-CandW (202.24.207.216/ 30 CW:1497391) (T = pCW)
pop2-loh.atdn.net, POS7/0, pop2-loh-P7-0-CandW (199.811.180/ 30
CW:p20484a) (T = pCWDIAL) pop3-vie.atdn.net, POS0/0,
pop3-vie-P0-0-CandW (202.24.238.88/ 30 CW:1509667) (T = pCW)
pop4-vie.atdn.net, POS7/0, pop4-vie-P7-0-CW (204.173.155.128/ 30
SIGMA:jk1001, CW:1475509) (T = pCW)
[0033] As demonstrated by the above examples, tags are distinct
from information ordinarily provided on the network device
interface in that they typically are generic as to device
attributes such as IP address and title. Generally, a single tag is
associated with each network device interface since each interface
typically communicates with an identifiable category of network
device for purposes of tagging. However, to the extent that a
network device communicates with more than one other category of
network device (e.g., peer Sprint in the above example) for
purposes of tagging, multiple tags may be associated with the
interface for that network device, and traffic through that network
device may or may not be apportioned among the different tags
associated therewith. For instance, refined searching may be
enabled by associating multiple tags to one or more particular
interfaces.
[0034] Furthermore, an associated multiplier may be associated with
each tag of an interface having multiple associated tags to reflect
or appropriately apportion traffic attributable to each tag.
Similarly, to the extent that data from one device interface is
needed by several reports, the interface tag may be associated with
each of those reports by referencing its groups, as will be
understood more clearly with references to the description of step
120.
[0035] To preserve memory while enabling recognizable string names
to be used for tags, tag names may be reformatted prior to storage.
For instance, a tag name having a space may be reformatted to
remove this space prior to storage. In this manner, when subsequent
searches are performed for the tag name, the query tag should also
be modified to remove spaces.
[0036] Referring to FIG. 3A, the aggregation and metrics from the
identified network resources may be automated (120) by identifying
one or more tags for aggregation (310) and aggregating the metrics
from the network device interfaces having identical tags associated
therewith (320).
[0037] Tags may be identified for aggregation (310) in response to
user input. For instance, a user may be provided an interface
through which selections of tags may be made manually.
Alternatively, a selected list or all of the tags may be
pre-identified for automatic processing. In any event, tags may be
used to define groups of network device interfaces and thus network
devices. Furthermore, one or more tags may themselves be grouped.
For instance, FIG. 3B illustrates a group editor that may be used
to create and maintain a group definitions table that relates group
names to their defining tags. Various levels of access may be
provided to such a table (e.g., viewing versus modifying).
[0038] Referring to FIG. 3C, the metrics from network device
interfaces having identified tags associated therewith may be
automatically aggregated (320) by generating metrics for each of
the network devices having a tag specified by a group of interest
(320A) and compiling metrics for the group of network devices
and/or individual network devices within the aggregated group
(320B).
[0039] The aggregation of metrics for network devices typically
accounts for the particular period of time that a network device
includes the tag of interest. For instance, during the process of
FIG. 3C, metrics are generated for each of the network devices
during the period of time in which those devices had an identified
tag associated therewith (320A). Thus, the metrics compiled for any
particular group of aggregated network devices may reflect
activities of those individual devices during only the time period
for which the individual devices have interface tags defined by the
group.
[0040] To enable accurate reporting of temporal associations
between tags and interfaces, and hence between network devices and
groups, timing information may be maintained regarding the
tag/interface relationship. Specifically, in one implementation, a
"history" file is maintained at a server to enable tracking of the
addition/removal of tags to/from interfaces, or of interfaces
to/from groups based on changes in the association of tags to
interfaces, or the association of tags to interfaces, or the
association of tags to groups. This history file may be populated
through manual investigations, routine/periodic investigations
(e.g., hourly, daily, etc.), or event-triggered investigations
(e.g., based on the occurrence of change) of network device
interface status. Hence, changes in interface tags that occur
between reports may be detected, recorded and accounted for.
[0041] FIGS. 3D and 3E illustrate history files that are useful for
tracking temporal changes in the association of interfaces to
groups. In FIG. 3D, device interfaces within a group are listed
with information reflecting the first and last temporal association
with the group, and in FIG. 3E, the "+" and "-" symbols are used to
represent the addition to or removal of an interface from a group
at a recorded date (UNIX code, e.g., 986928634=041 02001-1850
GMT/04102001-1450 LOCAL). But other history files also may be
useful, such as a history file showing temporal changes in the
association of tags with interfaces, from which group changes could
be extrapolated. In addition, periodic investigations may be
avoided by storing historical information regarding tag changes at
the interface itself, and merely uploading or otherwise accessing
such information when aggregating metrics for network devices.
[0042] Thus, a report may be generated (130) to reflect metrics for
each network device having an interface tag specified by a
particular group of interest. FIG. 4A shows metrics for network
devices that belong to the group "peering-CW", and includes summary
information for this group in its first two lines. This report is
generated with reference to recorded historical timing information,
e.g., see FIG. 3D. As such, metrics for interfaces within the
report are sometimes omitted, reflecting that this group's tag was
not associated with the particular interface during certain periods
covered by the report. For instance, the FIG. 4A report contains
data corresponding to the FIG. 3D historical timing data in that
the metrics for pop1-ash.atdn.net, POS13/0 are omitted from the
report until that interface was tagged on Tuesday the 5.sup.th
(410), and the metrics for pop1-ntc.atdn.net, POS0/0 are omitted
from the report after that interface was no longer associated with
the group tag on Thursday the 7.sup.th (420).
[0043] FIGS. 4B and 4C illustrate a graphical representation of the
data shown by FIG. 4A and therefore also may be used to identify
the present or absence of a network device within the group over a
period of time. See reference numerals 430 and 440 corresponding to
the addition of pop1-ash.atdn.net, POS13/0 InBps on Tuesday the
5.sup.th.
[0044] And, as illustrated by FIGS. 5A-5C, billing and other
financial and statistical reports may be generated based on the
metrics of groups, to enable strategic decision-making and record
keeping.
[0045] For illustrative purposes, FIGS. 6A and 6B describe a
communications system for implementing techniques described with
respect to FIGS. 1-5C. For brevity, several elements in the figures
described below are represented as monolithic entities. However, as
would be understood by one skilled in the art, these elements each
may include numerous interconnected computers and components
designed to perform a set of specified operations and/or dedicated
to a particular geographical region.
[0046] Referring to FIG. 6A, a communications system 600 is capable
of delivering and exchanging data between a client system 605 and a
host system 610 through a communications link 615. The client
system 605 typically includes one or more client devices 620 and/or
client controllers 625, and the host system 610 typically includes
one or more host devices 635 and/or host controllers 640. For
example, the client system 605 or the host system 610 may include
one or more general-purpose computers (e.g., personal computers),
one or more special-purpose computers (e.g., devices specifically
programmed to communicate with each other and/or the client system
605 or the host system 610), or a combination of one or more
general-purpose computers and one or more special-purpose
computers. The client system 605 and the host system 610 may be
arranged to operate within or in concert with one or more other
systems, such as, for example, one or more LANs ("Local Area
Networks") and/or one or more WANs ("Wide Area Networks"). The
client device 620 (or the host device 635) is generally capable of
executing instructions under the command of a client controller 625
(or a host controller 640). The client device 620 (or the host
device 635) is connected to the client controller 625 (or the host
controller 640) by a wired or wireless data pathway 630 or 645
capable of delivering data.
[0047] The client device 620, the client controller 625, the host
device 635, and the host controller 640 each typically include one
or more hardware components and/or software components. An example
of a client device 620 or a host device 635 is a general-purpose
computer (e.g., a personal computer) capable of responding to and
executing instructions in a defined manner. Other examples include
a special-purpose computer, a workstation, a server, a device, a
component, other physical or virtual equipment or some combination
thereof capable of responding to and executing instructions.
[0048] An example of client controller 625 or a host controller 640
is a software application loaded on the client device 620 or the
host device 635 for commanding and directing communications enabled
by the client device 620 or the host device 635. Other examples
include a program, a piece of code, an instruction, a device, a
computer, a computer system, or a combination thereof, for
independently or collectively instructing the client device 620 or
the host device 635 to interact and operate as described. The
client controller 625 and the host controller 640 may be embodied
permanently or temporarily in any type of machine, component,
physical or virtual equipment, storage medium, or propagated signal
capable of providing instructions to the client device 620 or the
host device 635.
[0049] The communications link 615 typically includes a delivery
network 660 making a direct or indirect communication between the
client system 605 and the host system 610, irrespective of physical
separation. Examples of a delivery network 660 include the
Internet, the World Wide Web, WANs, LANs, analog or digital wired
and wireless telephone networks (e.g., PSTN, ISDN, and xDSL),
radio, television, cable, satellite, and/or any other delivery
mechanism for carrying data. The communications link 615 may
include communication pathways 650, 655 that enable communications
through the one or more delivery networks 660 described above. Each
of the communication pathways 650, 655 may include, for example, a
wired, wireless, cable or satellite communication pathway.
[0050] FIG. 6B illustrates a communication system 600 including a
client system 605 communicating with a host system 610 through a
communications link 615. Client system 605 typically includes one
or more client devices 620 and one or more client controllers 625
for controlling the client devices 620. Host system 610 typically
includes one or more host devices 635 and one or more host
controllers 640 for controlling the host devices 635. The
communications link 615 may include communication pathways 650, 655
enabling communications through the one or more delivery networks
660.
[0051] Examples of each element within the communication system of
FIG. 6B are broadly described above with respect to FIG. 6A. In
particular, the host system 610 and the communications link 615 of
FIG. 6B typically have attributes comparable to those described
with respect to the host system 610 and the communications link 615
of FIG. 6A, respectively. Likewise, the client system 605 of FIG.
6B typically has attributes comparable to, and may illustrate one
possible embodiment of, the client system 605 of FIG. 6.
[0052] The client device 620 typically includes a general purpose
computer 670 having an internal or external storage 672 for storing
data and programs such as an operating system 674 (e.g., DOS,
Windows.RTM., Windows.RTM. 95, Windows.RTM. 98, Windows.RTM. 2000,
Windows.RTM. NT, Windows.RTM. Millennium Edition, Windows.RTM. XP,
OS/2, UNIX and Linux) and one or more application programs.
Examples of application programs include authoring applications 676
(e.g., word processing, database programs, spreadsheet programs,
presentation programs, and graphics programs) capable of generating
documents or other electronic content; client applications 678
(e.g., AOL client, CompuServe client, AIM client, AOL TV client,
and ISP client) capable of communicating with other computer users,
accessing various computer resources, and viewing, creating, or
otherwise manipulating electronic content; and browser applications
680 (e.g., Netscape's Navigator and Microsoft's Internet Explorer)
capable of rendering standard Internet content.
[0053] The general-purpose computer 670 also includes a central
processing unit 682 (CPU) for executing instructions in response to
commands from the client controller 625. In one implementation, the
client controller 625 includes one or more of the application
programs installed on the internal or external storage 672 of the
general-purpose computer 670. In another implementation, the client
controller 625 includes application programs externally stored in
and executed by one or more device(s) external to the
general-purpose computer 670.
[0054] The general-purpose computer typically will include a
communication device 684 for sending and receiving data. One
example of the communication device 684 is a modem. Other examples
include a transceiver, a set-top box, a communication card, a
satellite dish, an antenna, or another network adapter capable of
transmitting and receiving data over the communications link 615
through a wired or wireless data pathway 650. The general-purpose
computer 670 also may include a TV ("television") tuner 686 for
receiving television programming in the form of broadcast,
satellite, and/or cable TV signals. As a result, the client device
620 can selectively and/or simultaneously display network content
received by communications device 684 and television programming
content received by the TV tuner 686.
[0055] The general-purpose computer 670 typically will include an
input/output interface 688 to enable a wired or wireless connection
to various peripheral devices 690. Examples of peripheral devices
690 include, but are not limited to, a mouse 691, a mobile phone
692, a personal digital assistant 693 (PDA), a keyboard 694, a
display monitor 695 with or without a touch screen input, and/or a
TV remote control 696 for receiving information from and rendering
information to subscribers. Other examples may include voice
recognition and synthesis devices.
[0056] Although FIG. 6B illustrates devices such as a mobile
telephone 692, a PDA 693, and a TV remote control 696 as being
peripheral with respect to the general-purpose computer 670, in
another implementation, such devices may themselves include the
functionality of the general-purpose computer 670 and operate as
the client device 620. For example, the mobile phone 692 or the PDA
693 may include computing and networking capabilities, and may
function as a client device 620 by accessing the delivery network
660 and communicating with the host system 610. Furthermore, the
client system 605 may include one, some, all, or none of the
components and devices described above.
[0057] As described above, interface tags can be used to group
network device interfaces and hence as a means for enabling
monitoring of aggregated statistics for a group of network devices
having one or more shared attributes. As such, interface tags may
be used as a substitute for, or in combination with, one or more
network device or network device interface attributes, examples of
attributes for a network device including speed, communication
interface type (e.g., POS, serial ethernet, fast ethernet, ATM),
device manufacturer type, router type, interface name, description,
packet size, Interface IP, Network name, Network Mask, and/or
location.
[0058] A number of implementations have been described.
Nevertheless, it will be understood that various modifications may
be made. Accordingly, other implementations are within the scope of
the following claims.
* * * * *
References