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.