WO2001026286A1 - Management of a group of network elements through an intermediate element having a translation functionality - Google Patents

Management of a group of network elements through an intermediate element having a translation functionality Download PDF

Info

Publication number
WO2001026286A1
WO2001026286A1 PCT/US2000/018942 US0018942W WO0126286A1 WO 2001026286 A1 WO2001026286 A1 WO 2001026286A1 US 0018942 W US0018942 W US 0018942W WO 0126286 A1 WO0126286 A1 WO 0126286A1
Authority
WO
WIPO (PCT)
Prior art keywords
network element
recited
network
parent
data structure
Prior art date
Application number
PCT/US2000/018942
Other languages
French (fr)
Inventor
Rueiming Jamp
Daniel R. Palevich
Yu-Jen Hsiao
Howard P. Hui
Eddy Lem
Original Assignee
Anda Networks, 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 Anda Networks, Inc. filed Critical Anda Networks, Inc.
Priority to AU59299/00A priority Critical patent/AU5929900A/en
Publication of WO2001026286A1 publication Critical patent/WO2001026286A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0213Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0226Mapping or translating multiple network management protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • H04L41/044Network management architectures or arrangements comprising hierarchical management structures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0893Assignment of logical groups to network elements

Definitions

  • Figure 1 is a hierarchical representation of network elements within a multiple
  • SNMP Network Management Protocol
  • Commands to configure the head end network element are implemented in the head end, and the rest of the commands
  • alarm information from each child network element may be propagated up to the
  • a Network Operation Center may be any suitable network Operation Center (NOC).
  • NOC Network Operation Center
  • voice service commands may arrive at the head end in a TL1 format or CMIP based format, while data service commands arrive in an HTTP based,
  • each managed object may be represented by a unique object within the
  • the child identifier forming one column of the table.
  • managed object e.g., a particular column of a particular row. Since managed objects
  • the access concentrator may be any type of sub-networks.
  • the access concentrator may be any type of sub-networks.
  • the access concentrator may be any type of sub-networks.
  • the access concentrator may be any type of sub-networks.
  • the access concentrator may be any type of sub-networks.
  • NOC network operations center
  • the NOC may also receive requests for various services, for example

Abstract

Disclosed are mechanisms for managing a plurality of network elements (122, 120, 612b, 612a, 628a, 630, 612c, 608) through a designated network element (102, 104, 106, 112, 608, 630, 628b). A command is received into the designated network element, and at least a portion of the received command is translated into a translated command for implementation on another network element. The translated command is sent to the other network element for implementation. A data structure (302) is provided within a parent network element configured to represent managed objects of a plurality of children network elements. The parent network element and children network elements are part of a service group and are interconnected. The data structure includes a plurality of managed object representations of each managed object of the children network elements. Each managed object representation includes an attribute set representation of a corresponding attribute set of a selected managed object of the selected child network element.

Description

MANAGEMENT OF A GROUP OF NETWORK ELEMENTS THROUGH AN INTERMEDIATE ELEMENT HAVIN G A TRANSLATION FUNCTIONALITY
BACKGROUND OF THE INVENTION
The present invention relates generally to network systems. More specifically, the present invention relates to methods and apparatus for configuring, provisioning,
and managing network elements and services within an integrated communication network.
Communication service providers are increasingly attempting to efficiently provide a wide range of services to their customers. These services include voice services (e.g., telephone access, call-forwarding, conference-calling, etc.), as well as digital data services (e.g., file transfer, Internet access, e-mail, etc.). The wide range of services require a complex network of communications equipment.
Conventionally, service providers have managed multiple overlay structures. For example, one network is configured to carry frame relay services; another network is
configured to carry voice; and another network is configured for Internet services. At some point, some of the traffic from the different networks may be consolidated and transported long-distance via a single ATM backbone. However, in the access
portion of each network, much of the equipment may be separate for each kind of services. That is, voice may be provisioned over different switches and circuits than frame relay and Internet services.
Some providers (e.g., greenfield providers) are currently attempting to
integrate traffic all the way to the customer premises. Such a network configuration is referred to as an Integrated Communications Network (ICN). An ICN is generally defined as a data network that carries multiple services (including voice, frame relay,
and Internet services) all the way into customer premises.
As communication networks become more complex, service providers require
increasingly capable network management procedures. Management procedures generally include maintaining optimum levels of service to the customer, as well as
efficiency in the maintenance and usage of the equipment itself, and adding new
members to the network, as well as new services for current members. As networks
grow increasingly complex, both in the size of the network and the range of services
provided by the network, network management efficiency becomes increasingly
important.
Unfortunately, conventional management systems for provisioning and
managing services are inadequate. Currently, the tasks of provisioning and managing
services are costly and time-consuming. A service provider must hire a significant
number of technical staff to configure various network components. For instance,
when a customer wishes to subscribe to a particular service, the service provider's
employee typically travels to the customer's site and configures the customer's
hardware and may have to travel to various network components to configure them as
well. Likewise, when a fault is detected within a network path, the employee often
has to trouble shoot several different network components to find and repair the fault.
Additionally, it is currently not possible for customers to receive services on demand
since each network component has to be separately and manually configured within a
complex network. In view of the foregoing, there is a need for an improved mechanism for
managing and provisioning the services within a communications network.
SUMMARY OF THE INVENTION
Accordingly, the present invention provides an apparatus and method for
efficiently configuring, provisioning, and managing network elements and services
within a network. In one embodiment, a group of network elements are configured
such that they may be managed through a designated network element. The
designated network element is accessible by an administrator. For example, an
administrator may provision services on various network elements through the
designated network element. By way of another example, an administrator may
monitor currently active services on various network elements through the designated
network element.
In general terms, the network elements are configured such that provisioning
instructions and information automatically propagate from the designated network
element to other network elements within a group (e.g., when a service is created or
modified). Likewise, status and/or fault information for each network element
automatically propagates from each network element within the group to the
designated network element (e.g., when status information is requested by the
administrator or when a network element breaks down). In sum, the present invention
provides mechanisms for flow-through provisioning and maintenance of various
network elements within a communications network through a designated network
element. Flow-through provisioning lets an administrator send a series of
provisioning commands through a designated network element in order to turn a
customer's services on and off, modify such services, and obtain performance and
fault information. In one embodiment, a method for managing a plurality of network elements
through a designated network element is disclosed. A command is received into the
designated network element, and at least a portion of the received command is
translated into a translated command for implementation on another network element.
The translated command is sent to the other network element for implementation.
Specific embodiments of the present invention have several associated
advantages over conventional systems. Since a network element that is accessible by
an administrator (e.g. a network operations center) accepts provisioning commands
for other network elements, network management is significantly simplified. Since
the accessible network element translates the provisioning commands into commands
for the other network elements and sends the translated commands to the appropriate
other network elements for implementation, each network element does not have to
be manually configured for a particular service. Thus, the number of service trucks
and service staff may be significantly reduced. Additionally, a customer may request
and receive a service on demand without significant delay. Finally, since fault
information automatically flows to the accessible network element, each network
element does not have to be individually polled. This feature also results in
significant simplification of network maintenance and the reductions of manpower
and cost.
These and other features and advantages of the present invention will be
presented in more detail in the following specification of the invention and the accompanying figures which illustrate by way of example the principles of the
invention. BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be readily understood by the following detailed
description in conjunction with the accompanying drawings, wherein like reference
numerals designate like structural elements, and in which:
Figure 1 is a hierarchical representation of network elements within a multiple
service network in accordance with one embodiment of the present invention.
Figure 2 illustrates several examples of Simple Network Management
Protocol (SNMP) managed objects within a first and a second network element in
accordance with one embodiment of the present invention.
Figure 3 depicts a representation within a head end network element of the
managed objects of the network elements of Figure 2 in accordance with one
embodiment of the present invention.
Figure 4 is a diagrammatic representation of the TCP flow or connection for a
data packet.
Figure 5 lists several examples for translating parent references into
corresponding child references in accordance with one embodiment of the present
invention.
Figure 6 is diagrammatic representation of an Integrated Communication
Network (ICN) in accordance with one embodiment of the present invention. DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS
Reference will now be made in detail to a specific embodiment of the
invention. An example of this embodiment is illustrated in the accompanying
drawings. While the invention will be described in conjunction with this specific
embodiment, it will be understood that it is not intended to limit the invention to one
embodiment. On the contrary, it is intended to cover alternatives, modifications, and
equivalents as may be included within the spirit and scope of the invention as defined
by the appended claims. In the following description, numerous specific details are
set forth in order to provide a thorough understanding of the present invention. The
present invention may be practiced without some or all of these specific details. In
other instances, well known process operations have not been described in detail in
order not to unnecessarily obscure the present invention.
Figure 1 is a hierarchical representation of network elements within a multiple
service network 100 in accordance with one embodiment of the present invention.
The network elements may take any suitable form for communicating data or voice
within a communication network. Examples of network elements are PSTN class 5
circuit switches, frame relay switches, ATM switches, GR303 gateway, integrated
access devices (IAD), digital subscriber loop access multiplexors (DSLAM), etc. The
network elements may be interconnected by any suitable communication mechanisms.
By way of example, digital subscriber loop (DSL) and/or TI lines, DS-3 circuits may
be utilized. Alternatively, any suitable wireless, coaxial cable or optical fiber
transmission mechanism may be utilized to communicate data between network
elements. Network elements may be logically grouped by the type of service that they
provide. By way of example, a first group 120 may be utilized for data services,
while a second group 122 is utilized for voice communications services. As shown,
the first group 120 includes network elements 112, 104, 114, 116, and 118. The
second group 122 includes network elements 102, 104, 106, 108, and 110. Since
many network elements are typically capable of providing multiple services, there
may be overlap between groups. As shown, network element 104 belongs to both
group 120 and group 122.
Any suitable protocol may be used to communicate between any two network
elements. For example, a GR303 gateway for a public switched telephone network
(PSTN) may utilize the Common Management Information Protocol (CMIP), while other network elements for providing data services may utilize a Simple Network
Management Protocol (SNMP). The network element that is at the root of a
particular group is defined as the head end network element. As shown, group 120
includes head end network element 112, while group 122 includes head end element
102.
The present invention provides mechanisms for propagating provisioning and
managing commands through each network element within a particular group. At
least one network element is configured to receive a provisioning or managing
command from an administrator, translate at least a portion of the command for other
network elements, and send the translated command to the other network elements for
implementation. In one embodiment, provisioning or managing commands may be
received by the group's head end network element. Commands to configure the head end network element are implemented in the head end, and the rest of the commands
are translated and flowed downstream to the children network elements to be
implemented by the appropriate children network elements. Likewise, information
regarding a network element may be accessed via any of the network element's head
elements. (A network element will have more than one head end network element if
such network element belongs to more than one group). Said in another way,
provisioning or managing commands may be propagated down from a "parent" head
end network element to one or more "children" network elements, and status and/or
alarm information from each child network element may be propagated up to the
parent head end network element.
The designation of "head end network element" is arbitrary. Any network
element at the root of a branch of a bigger hierarchy is a head end network element of
that branch. As shown, network element 104 is the head end network element for the rest of hierarchy for both services (or groups) 120 and 122.
By way of a specific example, a Network Operation Center (NOC) may
provision one or more network elements for implementing a particular service
through the appropriate head end network element. In the example of Figure 1 , the
NOC may provision services for group 122 through head end network element 102
and for group 120 through head end network element 112. Additionally, the NOC
may obtain information about the status of any network element through a
corresponding head end network element. In the illustrated example, the NOC may
obtain status information regarding network element 104 through either head end network element 102 or 112. In sum, commands (e.g., provisioning, monitoring, or status requests) from the
administrator or NOC are also propagated by the head end network element to the
corresponding network element(s). The network element's response is propagated
back up the corresponding head end network element such that it may be
communicated to the NOC. Thus, the NOC merely looks at a head end network
element to obtain information about any network element or issue provisioning
commands. In one embodiment, attributes are stored in each child. These attributes
may take any suitable form. For example, the attributes may represent changeable
parameters of the corresponding network element, status or fault indicators, etc.
When the NOC accesses a particular attribute of a network element from the head
end, the head end sends a request to obtain the network element's attribute values (if
the attribute doesn't belong to the head end itself). The attribute value is in effect
propagated to the head end. The NOC may then obtain the attribute value from the
head end. Likewise, when the NOC writes to a particular attribute, the "write"
instruction is propagated to the appropriate network element.
In one embodiment, each head end network element is configured to
communicate provisioning or managing commands and receive status information to
and from each child network element through a common protocol. For example, the
commonly implemented Simple Network Management Protocol (SNMP) may be
utilized. However, since the commands for different services may be implemented in
a different format, the head end network element is preferably capable of translating
provisioning commands and status requests into the commonly used protocol (e.g.,
SNMP). For example, voice service commands may arrive at the head end in a TL1 format or CMIP based format, while data service commands arrive in an HTTP based,
CORBA based, or SNMP based format. Thus, the NOC may communicate with a
head end network element using any suitable format, and the head end translates the
NOC's commands into a format that is understandable by the head end's underlying
network elements before flowing the commands downstream. Of course, the head end may translate into any other suitable communication protocol, such as CMIP or
CORBA. Of course, the head end may only require a more straight forward
translation mechanisms if a single protocol such as SNMP is utilized by an
administrator or NOC.
Preferably, the child network elements utilize a common protocol that is also
utilized by the parent head end to represent various managed objects (MO) of the
children network elements. In the illustrated embodiment, each network element uses
the Open Provisioning Standard (OPS) extension of SNMP management information
base (MIB) to represent its managed objects. Each managed object of a network
element generally represents a particular type of service having one or more
configurable or readable attributes. In other words, a managed object may represent
any entity and/or function that is being managed. For example, an IAD network
element may include managed objects for various telephony, video, and/or data
services. The telephony services may include any suitable service that may be
provided to a telephony user, such as providing a new telephone number, call
forwarding, or three-way calling. The data services may include any type of data
service, such as the frame relay and Internet access services. A managed object may also represent configurable parameters of a particular
device, such as an IAD. Specific examples of this type of managed object include the
Ethernet port of an integrated access device (IAD), the TI or DSL trunk port, or an
access concentrator's DS-3 uplink. Several managed objects are defined within an
Internet Draft "Definitions of Managed Objects for Open Provisioning Standard in
Loop Access Environment" for The International Engineering Task Force in October
1999, which document is included within the U.S. Provisional Application No.
60/159,769. This Provisional Application is herein incorporated by reference in its
entirety.
Each managed object of a particular network element may have one or more
attributes. For example, an TI trunk object for an IAD may contain an attribute that
counts how many ATM cells have been sent upstream so far or tracks the total
bandwidth on the access line that the user is allowed to consume. Other attributes
may specify an IAD's IP address or define how many phone lines are enabled. In
short, the managed objects are mechanisms for tracking resources and the way they
are deployed. The network element may periodically update one or more of its own
managed object attributes. For example, traffic flow statistics for a particular IAD
may be constantly updated. By way of another example, a maximum allowable
bandwidth attribute may be monitored when a customer attempts to burst too high. In
sum, object attributes provide mechanisms for controlling various services (e.g., via
provisioning, monitoring, and fault detecting object attributes).
Figure 2 illustrates several examples of SNMP managed objects within a first
and a second network element in accordance with one embodiment of the present invention. The network elements are in the form of IADs. For illustration purposes
each LAD has two object classes, A and B. Each IAD includes a single instance of
class A, but includes multiple instances of class B. In this example, class A is a scalar
type object, and class B is a table type object. As shown, the class A object of both
IAD 202 and IAD 204 includes one instance. The Class B object of IAD 202 includes two instances, and the class B object of IAD 204 includes three instances.
Each object is identified by a unique sequence of digits called an SNMP
Object Identifier (SOID). Class A has SOLDs A.1.0, A.2.0, and A.3.0, while class B
has SOIDs B.1.1, B.1.2, B.1.3, and B.1.4. As shown, each class A instance has three
attribute values (having SOIDs A.1.0, A.2.0, and A.3.0). Each class B instance
includes an identifier (SOLD B.1.1), two attribute values (B.1.2 and B.1.3), and a
status indicator (B.1.4). The identifier is an index to a particular row of the class B
object. Class A objects may be identified by a particular attribute SOID.
Each managed object may represent any suitable service or service parameter.
As shown, class A represents a system related object. The class A object of the first
IAD has attributes equal to "10168" (indicating that the system has been up for 10168
seconds), "SF" (indicating that the location is San Francisco), and "Mighty"
(indicating that the name of the equipment is Mighty). The class A object of the
second IAD has attributes equal to "1588" (indicating that system has been up for
1588 seconds ), "SJ" (indicating that the location is San Jose), and "Supra" (indicating
that the name of the equipment is Supra). Class B represents an Analog Line Termination object. The first column is the
instance index, the second column is the generic signal function code value, the third
column is the robbed bit signal value, and the fourth column is a status indicator. The
first IAD 202 includes two instances for class B. For the first instance, the index at
SOID B.1.1 is set to "77"; the generic signal function code value at B.1.2 is set to
"GS" (where "GS", and "LS" indicating a Ground Start or Loop Start service
respectively); the robbed bit signal value at B.1.3 is set to "AB"; and the status
indicator at B.1.4 is set to "active." The second IAD 204 includes three instances for
class B having index values "16", "17", and "18." The generic signal function code
values at B.1.2 are set to "GS." The robbed bit signal values at B.1.3 are set to "AB",
"AB", and "ABCD" (indicating different signaling patterns), respectively. The status
indicators are set to "active", "inactive", and "Create-Wait" (indicating that this
instance is currently being created and about to become active), respectively.
The managed objects of each child network element are also represented
within the parent head end elements. That is, each head end includes a representation
of the managed objects of its various children network elements. Although each
managed object of the children network elements may be represented within a parent
network element, the managed objects themselves may be actually implemented
within the child network element. Any suitable mechanism may be utilized for
representing the managed objects of a head end network element's children. For example, each managed object may be represented by a unique object within the
corresponding head end network element. In one embodiment, all of the children network elements are numbered sequentially to get a unique index number for each
network element.
Alternatively, each managed object may be indexed by the corresponding
child's identity, as well as the child network element's level within the hierarchy. In
one embodiment, the network elements on each particular level are sequentially
numbered from 1 to X to obtain a first index number for each child at a particular
level, and the levels are sequentially numbered to obtain a second index number for
each level. One mechanism for representing managed objects is described below with
reference to Figures 3 through 5.
In the illustrated embodiment, a group of scalar objects at the child network
element is represented by an SNMP table at the parent network element, with the
child identifier forming one column of the table. In one example, the first column
within the parent object indexes the corresponding child network element, and the
remaining columns duplicate the columns (SOID values) from the corresponding
child object. For scalar objects, an extra status indicator column may be added to the
parent table to indicate the status of the particular row. A table object of a child
network element is represented by a corresponding parent table object, with the
additional of an index column as the child identifier. For each additional level within
the hierarchy, an extra column indicating the additional level is added to the parent
object (for both scalar and table type objects).
Figure 3 depicts a representation within a head end network element of the
managed objects within the network elements of Figure 2 in accordance with one embodiment of the present invention. As shown, there are two tables GA and GB.
Table GA represents scalar type managed objects, while table GB represents table
type managed objects. As shown for both the GA and GB tables, the SOID values for
each instance are duplicated, with the addition of an index value that corresponds to
the relevant child's identification. As shown, the first column (SOID GA.1.1 and
GB.1.1) of each class (A and B) indexes a child network element ("1" for the first
LAD 202 and "2" for the second IAD 204). Additionally, a status column (SOID
GA.1.5) is added to the GA table to indicate the status of the corresponding row.
In sum, an extra column within the parent network element may be utilized to
identify or index the corresponding child network element. The added parent index
may be used conjunction with the service identifier to index the particular object.
Particular managed object may then be managed through their respective indexes.
Within the SNMP protocol, multiple column indexes are typically used to index or
identify an object. As shown in Figure 4, for example, the TCP flow or connection
object 402 for a particular packet 400 is typically identified by four fields: a source LP
value, a destination IP value, a source port value, and a definition port value. That is, four columns are utilized to identify a TCP flow.
The managed objects of various network elements may then be managed
through the object representations within the head end network element. In the
illustrated SNMP embodiment, a particular attribute of an object is referenced by the
attribute's SOLD with the addition of the corresponding index. An attribute of a scalar
object is referenced by the SOLD of that attribute plus the additional index to the child
network element. In the first table of Figure 3, the first column, GA.1.1, is the index column. In the second table of Figure 3, column GB.1.1 and GB1.2, are the index
columns. As a general rule, an attribute of a particular row of a SNMP table is formed
by appending the column SOLD with the values in the index columns. In the example
of Figure 3, the second column attribute of the first row for table GA may be
referenced by GA 1.2.1 (where GA1.2 is the attribute column and the last digit of
GA.1.2.1 is the value of first row of the index column). Similarly, the same attribute
of the second row is referenced by GA.1.2.2. GA.1.2.1 and GA.1.2.2 of Figure 3
correspond to A.1.0 of IAD1 and A.1.0 of IAD 2 of Figure 2, respectively. The attributes of a table type object may be referenced in the parent table by the attribute
SOLD, the additional child index created for the parent's table, and the index row from
the child's table. In the example of Figure 3, the first attribute is located at the third
column, GB1.3, of the GB table in Figure 3. The first attribute of the third row is
referenced by SOLD GB.1.3.2.16, where GB1.3 is the attribute column, 2 is the value
of the third row of first index column, and 16 is the value of the third row of the
second index column. Comparing the table GB of Figure 3 and table B of Figure 2,
the first index column, GB1.1, of table GB is created by the parent. The second index
column, GB1.2, is the index column of table B of Figure 2. GB 1.3.2.16 corresponds
to B.1.2.16 of IAD 2. If other indexes are used within the parent to index particular
levels within the network hierarchy, these additional indexes would also be utilized to
access an attribute.
SNMP includes commands for accessing managed objects. For example,
commands are provided for setting attributes of each managed object, as well as for
creating managed objects. Several command types are described further in the (1) Internet Engineering Task Force (IETF) Request for Comments (RFC) 1157 entitled "
A Simple Network Management Protocol (SNMP)," May 1990, and (2) IETF RFC
1905 entitled "Protocol Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", January 1996, which documents are incorporated herein by
reference in its entirety. By way of example, SNMP includes "SET" and "GET"
commands to operate on managed objects. The SET command is used to create a new
row (instance) of a table type object or to set attribute values of a particular managed
object or instance. The GET command is used to retrieve attribute values of a
managed object (e.g., a particular column of a particular row). Since managed objects
of children network elements are represented within each parent network element, an
administrator may access the parent representation. The SET or GET command is
issued with a reference to an attribute of a particular object (and a write value for the
SET command). The parent then translates the administrator's command and
associated reference into a command and reference for accessing the coπesponding
child's managed object.
When an access command and associated reference is sent to a parent network
element, the reference corresponds to a particular column and row of a particular
object within the parent network element. For an SNMP reference, the attribute SOLD
is listed first and then the indexes. For example, the reference "GA.1.2.1" refers to
the second column (SOLD GA.1.2) of the first row; the reference "GA.1.2.2" refers to
the second column of row 2. For the objects of the parent that represent table objects
within the child, more than one index is utilized: one or more child indexes to
reference the child network element and one or more indexes from the child table itself. For example, the reference "GB.1.2.2.17" refers to the second column (SOID
GB.1.2) of the fourth row (index equal to 2 and 17) of the class B object of the parent
302 of Figure 3.
Figure 5 lists several examples for translating parent references into
corresponding child references in accordance with one embodiment of the present
invention. As shown, the parent reference "GA.1.2.1" is translated into the child
reference "A.1.0" of the first IAD. The parent reference "GB.1.2.1.77" is translated
into the child reference "B.1.1.77" of the first IAD. After a parent reference is
translated into a corresponding child reference for a particular child network element,
the command and translated reference may be sent to the particular child network
element for implementation. By way of example, a GET command and the translated
reference is sent to the appropriate child network element to obtain a particular
attribute value of an instance. The child network element produces the requested
attribute value and sends it to the parent network element to be obtained by the
requesting administrator. Likewise, a SET command and translated child reference is
propagated to the appropriate child network element to configure a corresponding
attribute value of the child network element.
The present invention may be implemented within any suitable network
having any suitable number and type of network elements. For example, the
provisioning and management mechanisms may be applied to a dedicated Internet
network, a dedicated frame relay network, or a dedicated voice network. However,
the mechanisms of the present invention are especially advantageous within an
Integrated Communications Network (ICN). Figure 6 is diagrammatic representation of an ICN network 600 in accordance with one embodiment of the present invention. The network 600 includes a number of sub-networks in the form of a loop access data
network 604, a backbone data network 602, and a public switched telephone network
(PSTN)603. Preferably, data is transfeπed to and from sub-networks 602-604 via an
access concentrator 608.
The access concentrator 608 may take any suitable form for communicating
data between various types of sub-networks. For example, the access concentrator
may take the form of a UAP-2000 available from ANDA Networks of Santa Clara,
California. Alternatively, the access concentrator may take the form of a digital
subscriber loop access multiplexor (DSLAM). In this embodiment, the access concentrator 608 is capable of aggregating data from multiple circuits (e.g., TI, DSL,
and DS-3 circuits), switching the data traffic to the backbone network 602, and
handing off voice data to a class 5 switch on the PSTN 603. The PSTN's class 5
switch provides the circuit switch functions, as well as services such as call waiting
and call forwarding.
Any suitable interface device may be utilized for communicating between
each sub-network and the access concentrator 608. As shown, a GR303 switch 630 is
utilized to communicate with PSTN network 603 and ATM switches 628a and 628b
are used to communicate with data networks with 604 and 602, respectively. The
access concentrator 608 may also be configured as a GR303 Gateway to provide voice
circuit concentration so that only active telephone calls occupy circuits connected to
the GR303 switch 630. As shown, the access concentrator 608 communicates with one or more users
through their respective integrated access devices (IADs). An IAD generally is
configurable to provide bundled voice and data services to a particular customer. For
example, an IAD may convert analog voice signals of connecting telephone sets to
digital and transport the digital signal to the GR303 Gateway of the concentrator 608. Communication between the access concentrator 608 and an IAD may take place
directly (e.g., LAD 612a) or indirectly through a loop access data network (e.g., LAD
612c via data network 604). Data may be routed serially through any number of IADs
or through a single IAD. The access concentrator 608 terminates the access lines
from hundreds of customer IADs. The lines may include any suitable number and
type of lines, such as DSL and TI lines.
Any number and type of communication devices may be coupled with each
LAD - including a PBX, Ethernet hubs or switches. For example, various telephones
and networking equipment may be plugged into an LAD. As shown, a computer 618
and telephone 620 are coupled with IAD 612a, and computer 614 and telephone 616
are coupled with IAD 612c. The IAD serves to shunt a user's LP traffic to the Internet
or to an IP -based virtual private network, act as a multiplexer, and balance load on the
access line. The IAD may also encapsulate all traffic (e.g., LP, frame relay, and voice)
into a common protocol, such as ATM cells.
Upon receiving traffic from an LAD, the access concentrator 608 separates
voice from data traffic. Voice traffic is depacketized and converted to circuit and
handed off to the GR303 switch 630 on the PSTN 603, while data traffic is routed to the carrier's backbone network 602, and then to the Internet or managed LP/ frame
relay net.
An Integrated Communications Network has several associated advantages.
For example, an integrated network means CLECs (carrier local exchange centers),
for example, or interexchange carriers (LXCs) can offer bundled service packages for
a relatively low capital expenditure. Since customers are supplied over a single data
infrastructure, the costs associated with managing multiple overlay networks is
eliminated.
In the illustrated embodiment, the various elements of network 600 may be
controlled through a network operations center (NOC) 606 or any other suitable
administration mechanism. The NOC may be configured in any suitable manner. As
shown, the NOC 606 includes a server 624 and user platform 626. For the network
600 of Figure 6, the NOC 606 monitors and configures specific network elements
through the access concentrator 608 or GR303 switch. For example, the NOC sends
CMLP provisioning commands to the PSTN 603 through GR303 switch 630 and
sends SNMP provisioning commands to various IADs through access concentrator
608. The NOC 606 may also monitor various states of specific network elements,
such as the IADs. The NOC may also receive requests for various services, for
example, through a user's computer 622.
The present invention provides mechanisms for managing multiple objects
through head end network elements. In the example of Figure 6, the head end for
voice services is the GR303 switch 630. All provisioning commands for voice services from the NOC 606 may arrive at the GR303 switch 630. For example,
provisioning commands may include adding a new telephone line for a new customer
with a set of services, such as call forwarding. Commands to configure the GR303
switch 630 are implemented there (e.g., providing a new telephone number with call forwarding), but the remaining commands are flowed downstream to other children
network elements. For example, provisioning commands for the GR303 gateway
(e.g., configuring a new subscriber circuit) are implemented within the access
concentrator 608, and commands for a particular IAD (e.g., attaching the circuit to a
telephone set) are implemented within such LAD.
Flow-through provisioning represents a significant improvement over
conventional provisioning techniques. Each network element that is to be configured
for a particular service does not have to be provisioned separately. For example, the
GR303 switch, access concentrator, and LAD do not have to be configured separately
to add a new telephone number. Instead, the NOC simply sends provisioning
commands to a single head end element. Consequently, the number of truck rolls are
reduced and, accordingly, network management is significantly simplified.
Although the foregoing invention has been described in some detail for
purposes of clarity of understanding, it will be apparent that certain changes and
modifications may be practiced within the scope of the appended claims. It should be
noted that there are many alternative ways of implementing both the process and
apparatus of the present invention. Accordingly, the present embodiments are to be
considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

CLAIMSWHAT IS CLAIMED IS:
1. A method for managing a plurality of network elements through a
designated network element, the method comprising:
receiving a command into the designated network element;
translating at least a portion of the received command into a translated command for implementation on another network element; and
sending the translated command to the other network element for
implementation.
2. A method as recited in claim 1, wherein the translated command has an Simple Network Management Protocol format (SNMP).
3. A method as recited in claims 1 or 2, wherein the received command is
formatted to access a representation of a managed object of the other network element
and the translating is accomplished by changing the received command into a format
for accessing the managed object of the other network element.
4. A method as recited in claim 3, wherein the managed object provisions
a particular service set selected from a group consisting of a set of data services, a set
of telephony services, and a set of video services.
5. A method as recited in any of claims 1-4, wherein the received command is formatted to access a row of a table object within the designated network
element.
6. A method as recited in claim 5, wherein the translated command is
formatted to reference a managed object of the other network element, the managed
object corresponding to the row of the table object within the designated network
element.
7. A method as recited in any of claims 1-6, wherein the received
command is to create a managed object within the other network element.
8. A method as recited in any of claims 1-6, wherein the received command is to configure a managed object within the other network element.
9. A method as recited in any of claims 1-6, wherein the received
command is to monitor a managed object within the other network element.
10. A method as recited in any of claims 1-9, wherein the designated
network element forms the head end element of a group of children network elements,
the other network element being a child network element, wherein the translated
command is sent downstream to the other network element.
11. A method as recited in any of claims 1-10, further comprising: receiving a response to the translated command from the other network
element, the response; and
making the response available so that the response may be read.
12. A method as recited in claim 11, wherein the response from the other
network element indicates a status of an service parameter.
13. A parent network element for facilitating a management procedure for
a plurality of children network elements, the network element comprising: a memory; and
a processor coupled to the memory,
wherein at least one of the memory and the processor are adapted to provide:
receiving a command into the parent network element;
translating at least a portion of the received command into a translated
command for implementation on a selected one of the children network
element; and
sending the translated command to the selected child network element for implementation.
14. A parent network element as recited in claim 13, wherein the parent
network element is selected from a group consisting of a PSTN class 5 switch and an
access concentrator.
15. A parent network element as recited in claims 13 or 14, wherein the
selected child network element is selected from a group consisting of a PSTN class 5
switch, an access concentrator, a frame relay switch, an ATM switch, a GR303
Gateway, an integrated access device, and a digital subscriber loop access
multiplexor.
16. A parent network element as recited in any of claims 13-15, wherein
the processor is further configured to communicate with a network administrator.
17. A parent network element as recited in any of claims 13-16, wherein
the administrator is a network operations center.
18. A parent network element as recited in any of claims 13-17, wherein
the parent network element forms a head end network element of two or more children network elements that provide a particular type of service.
19. A parent network element as recited in claim 18, wherein the particular
type of service is selected from a group consisting of a data service, a telephony service, and a video service.
20. A parent network element as recited in claim 18, wherein the parent
network element is the head end network element of two or more children network
elements that provide a second type of service
21. A parent network element as recited in any of claims 13-20, wherein
the processor is further configured to translate the received command from a first
protocol to a second protocol.
22. A parent network element as recited in any of claims 13-21, wherein
the second protocol is an Simple Network Management Protocol.
23. A parent network element as recited in any of claims 13-22, wherein
the parent network element and the children network elements are part of an
Integrated Communication Network.
24. A computer readable medium containing programming instructions for
managing a plurality of network elements through a designated network element, the computer readable medium comprising:
computer code for receiving a command into the designated network element; computer code for translating at least a portion of the received command into
a translated command for implementation on another network element; and
computer code for sending the translated command to the other network
element for implementation.
25. A data structure within a designated network element for managing a
plurality of parameters within other network elements, the data structure comprising:
a plurality of parameter representations of associated parameters within the
other network elements; and a reference associated with each parameter representation, the reference identifying which other network element is associated with the each parameter
representation.
26. A data structure as recited in claim 25, wherein the other network
elements are arranged hierarchically below the designated network element and each reference includes a first index to a selected one of the other network elements within
a particular level of hierarchy and a second index indicating the particular level of
hierarchy.
27. A data structure as recited in claims 25 or 26, wherein the reference
uniquely identifies the reference's associated other network element.
28. A data structure as recited in any of claims 25-27, wherein at least one of the parameter representations is configurable to thereby configure the corresponding parameter of the selected other network element.
29. A data structure as recited in any of claims 25-28 wherein at least one of the parameter representations is readable to thereby read the corresponding
parameter.
30. A data structure as recited in any of claims 25-29 wherein at least one
parameter includes a single attribute.
31. A data structure as recited in any of claims 25-30 wherein at least one of the parameter representations includes at least one status indicator.
32. A data structure as recited in any of claims 25-31 wherein at least one
of the parameter representations includes at least one fault indicator.
33. A data structure as recited in any of claims 25-33 wherein at least one of the parameter representations coπesponds to a network service.
34. A data structure as recited in claim 33, wherein the network service is
configurable by writing to the at least one parameter representation.
35. A data structure as recited in claims 33 or 34, wherein the network service is monitorable by reading the at least one parameter representation.
36. A data structure as recited in any of claims 25-33, wherein at least one
of the parameter representations corresponds to a data network service and at least
another of the parameter representations corresponds to a telephony network service.
37. A data structure within a parent network element configured to
represent managed objects of a plurality of children network elements, the parent
network element and children network elements being part of a service group and
being interconnected, the data structure comprising:
a plurality of managed object representations of each managed object of the children network elements,
wherein each managed object representation includes an attribute set
representation of a corresponding attribute set of a selected managed object of the
selected child network element.
38. A data structure as recited in claim 37, wherein the managed objects
are formatted to comply with a Simple Network Management Protocol.
39. A data structure as recited in claims 37 or 38, wherein the managed
objects are separated into different object classes.
40. A data structure as recited in claim 39, wherein the class types include
a scalar type and a table type.
41. A data structure as recited in claim 40, wherein the managed object representations that coπespond to scalar type managed objects are grouped into a first table and the managed object rep representations that coπespond to scalar type managed objects are grouped into a second table, wherein each row within both of the first and second tables coπesponds to a selected managed object.
42. A data structure as recited in claim 41, wherein both the first and second tables include a plurality of columns that coπespond to the attribute sets of the
managed object.
43. A data structure as recited in claim 42, wherein the second table also
includes an index column for identifying which child network element coπesponds to
each row.
44. A data structure as recited in claim 43, wherein the index uniquely identifies the child network element.
45. A data structure as recited in claim 43, wherein the index uniquely
identifies the child network element at a particular hierarchical level and the second
table also includes a third index to identify that particular hierarchical level.
46. A designated parent network element for facilitating a management
procedure for a plurality of children network elements, the children network elements
branching down from the parent network element to a plurality of subscribers, the
designated parent network element and a first set of children network elements being configured to implement a first set of services, the designated parent network element
and a second set of children network elements being configured to implement a second set of services, the designated parent network element comprising:
a memory; and a processor coupled to the memory, wherein at least one of the memory and the processor are adapted to provide:
receiving a command into the parent network element; translating at least a portion of the received command into a translated command for implementation on a selected one of the children network element; and
sending the translated command towards the selected network element.
47. A designated parent network element as recited in claim 46 wherein the translated command is sent to a lower child network element, which is configured to forward the translated command towards the selected network element such that
the translated command propagates down to the selected child network element for implementation.
48. A designated parent network element as recited in claims 46 or 47,
wherein the designated parent network element also forms part of a branch below a
second parent network element.
49. A designated parent network element wherein the first set of services differs from the second set of services, and wherein the memory and processor are
further adapted to translate a plurality of commands for both the first and second set
of services.
PCT/US2000/018942 1999-10-01 2000-07-11 Management of a group of network elements through an intermediate element having a translation functionality WO2001026286A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU59299/00A AU5929900A (en) 1999-10-01 2000-07-11 Management of a group of network elements through an intermediate element havinga translation functionality

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US15700199P 1999-10-01 1999-10-01
US60/157,001 1999-10-01
US15976999P 1999-10-15 1999-10-15
US60/159,769 1999-10-15
US51874500A 2000-03-03 2000-03-03
US09/518,745 2000-03-03

Publications (1)

Publication Number Publication Date
WO2001026286A1 true WO2001026286A1 (en) 2001-04-12

Family

ID=27387949

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/018942 WO2001026286A1 (en) 1999-10-01 2000-07-11 Management of a group of network elements through an intermediate element having a translation functionality

Country Status (2)

Country Link
AU (1) AU5929900A (en)
WO (1) WO2001026286A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003030564A1 (en) * 2001-09-28 2003-04-10 Siemens Aktiengesellschaft Method for providing services in communications systems, communications system and computer programme
WO2003096621A1 (en) * 2002-05-10 2003-11-20 International Business Machines Corporation Network attached storage snmp single system image
FR2851709A1 (en) * 2002-12-31 2004-08-27 Activia Networks Synchronization resource providing system for communication network, has unit classifying different services in different categories of resources, and unit attributing resources to one service based on category(ies) corresponding to service
EP1551129A2 (en) * 2002-07-18 2005-07-06 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Generic interface for subscription management
WO2010105923A1 (en) * 2009-03-17 2010-09-23 Alcatel Lucent Method and system for remote management of applications hosted on a device, and server for use in such a system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5561769A (en) * 1994-05-10 1996-10-01 Lucent Technologies Inc. Method and apparatus for executing a distributed algorithm or service on a simple network management protocol based computer network
US5764955A (en) * 1995-10-19 1998-06-09 Oasys Group, Inc. Gateway for using legacy telecommunications network element equipment with a common management information protocol

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5561769A (en) * 1994-05-10 1996-10-01 Lucent Technologies Inc. Method and apparatus for executing a distributed algorithm or service on a simple network management protocol based computer network
US5764955A (en) * 1995-10-19 1998-06-09 Oasys Group, Inc. Gateway for using legacy telecommunications network element equipment with a common management information protocol

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GOLDEN J L: "MOTIVATIONS FOR EARLY TR-303 AND IMPLEMENTATION PROCESS", ANNUAL REVIEW OF COMMUNICATIONS, 1994, XP000543233 *
HANAKI M ET AL: "COOPERATIVE ATM-LAN/WAN END-TO-END MANAGEMENT USING CNM INTERFACE", GLOBAL TELECOMMUNICATIONS CONFERENCE (GLOBECOM),US,NEW YORK, IEEE, 3 November 1997 (1997-11-03), pages 1455 - 1460, XP000737767, ISBN: 0-7803-4199-6 *
KELLER A: "TOOL-BASED IMPLEMENTATION OF A Q-ADAPTER FUNCTION FOR THE SEAMLESS INTEGRATION OF SNMP-MANAGED DEVICES IN TMN", IEEE NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM,US,NEW YORK, NY: IEEE, vol. CONF. 10, 15 February 1998 (1998-02-15), pages 400 - 411, XP000799511, ISBN: 0-7803-4352-2 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003030564A1 (en) * 2001-09-28 2003-04-10 Siemens Aktiengesellschaft Method for providing services in communications systems, communications system and computer programme
WO2003096621A1 (en) * 2002-05-10 2003-11-20 International Business Machines Corporation Network attached storage snmp single system image
KR100791429B1 (en) * 2002-05-10 2008-01-07 인터내셔널 비지네스 머신즈 코포레이션 Network attached storage snmp single system image
US7451199B2 (en) 2002-05-10 2008-11-11 International Business Machines Corporation Network attached storage SNMP single system image
US8260899B2 (en) 2002-05-10 2012-09-04 International Business Machines Corporation Network attached storage SNMP single system image
EP1551129A2 (en) * 2002-07-18 2005-07-06 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Generic interface for subscription management
EP1551129A3 (en) * 2002-07-18 2005-07-20 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Generic interface for subscription management
FR2851709A1 (en) * 2002-12-31 2004-08-27 Activia Networks Synchronization resource providing system for communication network, has unit classifying different services in different categories of resources, and unit attributing resources to one service based on category(ies) corresponding to service
WO2010105923A1 (en) * 2009-03-17 2010-09-23 Alcatel Lucent Method and system for remote management of applications hosted on a device, and server for use in such a system

Also Published As

Publication number Publication date
AU5929900A (en) 2001-05-10

Similar Documents

Publication Publication Date Title
US6101538A (en) Generic managed object model for LAN domain
US8611363B2 (en) Logical port system and method
US8184625B2 (en) GPON management system
US8402120B1 (en) System and method for locating and configuring network device
US20020122547A1 (en) Method and apparatus for telephony route selection
SE502999C2 (en) telecommunication systems
EP2056573B1 (en) Integrated cut-in system and method and integrated cut-in module
US20020029298A1 (en) Arrangement, a system and a method relating to management communication
US20070121664A1 (en) Method and system for double data rate transmission
US20050125457A1 (en) Integrated element management system for end-to-end network management in next generation network, and network management method thereof
US5959985A (en) Multi-network architecture
US20070121619A1 (en) Communications distribution system
JP4995387B2 (en) Communications system
WO2001026286A1 (en) Management of a group of network elements through an intermediate element having a translation functionality
CN101227412B (en) Apparatus and method for message conversion
US7283546B2 (en) System supporting the dynamic migration of telecommunication subscribers between call services providers
US6973095B1 (en) Remote circuit provisioning
CN103166772B (en) A kind of method of the facilities and administration equipment with multiplex roles
US20070121628A1 (en) System and method for source specific multicast
WO2005018174A1 (en) Multiple services provisioning in a packet forwarding device with logical ports
Cisco Overview of Cisco Media Gateway Controller Node Manager
McGuire et al. Application of control plane technology to dynamic configuration management
CN111386677B (en) Access network with remote access server
CN100525189C (en) Method for control of communications from an edge device of an access network, edge device and network management module for performing said method
EP1263165B1 (en) Communication between an application and a network element

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

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

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP