U.S. patent application number 12/604793 was filed with the patent office on 2010-02-18 for methods, systems, and computer program products for managing access resources in an internet protocol network.
This patent application is currently assigned to AT&T Intellectual Property I, L.P., f/k/a Bellsouth Intellectual Property Corporation. Invention is credited to Neil Gilmartin.
Application Number | 20100039959 12/604793 |
Document ID | / |
Family ID | 38193613 |
Filed Date | 2010-02-18 |
United States Patent
Application |
20100039959 |
Kind Code |
A1 |
Gilmartin; Neil |
February 18, 2010 |
METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR MANAGING ACCESS
RESOURCES IN AN INTERNET PROTOCOL NETWORK
Abstract
Exemplary embodiments relate to managing access resources in a
network. Methods include receiving a request for network service,
the request including a required class of service; accessing a
storage device that specifies routers and bandwidth available on
the routers; selecting a router from the specified routers and a
port on the selected router to perform the requested service, the
selecting including verifying that the bandwidth available on the
selected router and port can perform the requested service, where
the bandwidth is divided into a plurality of capacity classes and
the bandwidth in each class can perform the requested service if
the capacity class corresponds to the required class of service;
transmitting instructions to a network configuration system to
initiate activation of the requested service on the selected router
and port; and updating the storage device to reflect the requested
service being activated on the selected router and port.
Inventors: |
Gilmartin; Neil; (Atlanta,
GA) |
Correspondence
Address: |
AT&T Legal Department - CC;Attn: Patent Docketing
Room 2A-207, One AT&T Way
Bedminster
NJ
07921
US
|
Assignee: |
AT&T Intellectual Property I,
L.P., f/k/a Bellsouth Intellectual Property Corporation
Wilmington
DE
|
Family ID: |
38193613 |
Appl. No.: |
12/604793 |
Filed: |
October 23, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11317055 |
Dec 22, 2005 |
7623548 |
|
|
12604793 |
|
|
|
|
Current U.S.
Class: |
370/254 ;
370/401; 370/431 |
Current CPC
Class: |
H04L 41/0896 20130101;
H04L 41/5054 20130101; H04L 41/509 20130101; H04L 47/15 20130101;
H04L 43/0852 20130101; H04L 43/087 20130101; H04L 41/5087 20130101;
H04L 41/082 20130101; H04L 47/822 20130101; H04L 43/00 20130101;
H04L 41/5093 20130101; H04L 41/5022 20130101; H04L 43/0829
20130101; H04L 47/70 20130101; H04L 47/805 20130101 |
Class at
Publication: |
370/254 ;
370/401; 370/431 |
International
Class: |
H04L 12/28 20060101
H04L012/28 |
Claims
1. A computer implemented method for managing access resources in a
network, the method comprising: receiving at a computer system a
request for network service, the request including a required class
of service; accessing at the computer system a storage device that
specifies routers and bandwidth available on the routers; selecting
at the computer system a router from the specified routers and a
port on the selected router to perform the requested service, the
selecting including verifying that the bandwidth available on the
selected router and port can perform the requested service, wherein
the bandwidth is divided into a plurality of capacity classes and
the bandwidth in each class can perform the requested service if
the capacity class corresponds to the required class of service;
transmitting at the computer system instructions to a network
configuration system to initiate activation of the requested
service on the selected router and port, the instructions
specifying a quality of service corresponding to the required class
of service; and updating at the computer system the storage device
to reflect the requested service being activated on the selected
router and port.
2. The method of claim 1, wherein the bandwidth is divided into
less than nine capacity classes.
3. The method of claim 1, wherein the required class of service is
entered into an operational support system (OSS) by a customer
service representative.
4. The method of claim 1, further comprising: for each of the
capacity classes, specifying configurable bandwidth utilization
thresholds, and transmitting an alarm when the bandwidth
utilization thresholds have been reached.
5. The method of claim 1, wherein the selecting further includes
verifying that one or more fixed resources can perform the
requested service.
6. The method of claim 1, wherein the requested network service is
an Internet protocol (IP) network service.
7. The method of claim 1, wherein the router is a provider edge
router.
8. The method of claim 1, wherein the requested network service is
a data service.
9. The method of claim 1, wherein the request for network service
is for one or more of adding a new service, modifying an existing
service and removing an existing service.
10. The method of claim 1, further comprising receiving a
notification when the requested service has been activated on the
selected router and port, wherein the updating is performed in
response to receiving the notification.
11. The method of claim 1, wherein the requested service is at
least one of direct Internet access and Internet protocol virtual
private network.
12. The method of claim 1, wherein the requested service is for
dedicated access.
13. The method of claim 1, wherein the requested service is for
non-dedicated access.
14. A system for managing access resources in a network, the system
comprising: an input device for receiving a request for network
service, the request including a required class of service; a
processor in communication with the input device including computer
instructions for facilitating: accessing a storage device that
specifies routers and bandwidth available on the routers; selecting
a router from the specified routers and a port on the selected
router to perform the requested service, wherein the selecting
includes verifying that the bandwidth available on the selected
router and port can perform the requested service, wherein the
bandwidth is divided into a plurality of capacity classes and the
bandwidth in each class can perform the requested service if the
capacity class corresponds to the required class of service; and
updating the storage device to reflect the requested service being
activated on the selected router and port; and an output device in
communication with the processor for transmitting instructions to a
network configuration system to initiate activation of the
requested service on the selected router and port, the instructions
specifying a quality of service corresponding to the required class
of service.
15. The system of claim 14, wherein the bandwidth is divided into
less than nine capacity classes.
16. The system of claim 14, wherein the router is a provider edge
router.
17. The system of claim 14, wherein the requested service is at
least one of direct Internet access and Internet protocol virtual
private network.
18. The system of claim 14, wherein the requested service is for
dedicated access.
19. The system of claim 14, wherein the requested service is for
non-dedicated access.
20. A computer program product for managing access resources in a
network, the computer program product comprising: a tangible
storage medium readable by a processing circuit and storing
instructions for execution by the processing circuit for
facilitating a method comprising: receiving a request for network
service, the request including a required class of service;
accessing a storage device that specifies routers and bandwidth
available on the routers; selecting a router from the specified
routers and a port on the selected router to perform the requested
service, the selecting includes verifying that the bandwidth
available on the selected router and port can perform the requested
service, wherein the bandwidth is divided into a plurality of
capacity classes and the bandwidth in each class can perform the
requested service if the capacity class corresponds to the class of
service; transmitting instructions to a network configuration
system to initiate activation of the requested service on the
selected router and port, the instructions specifying a quality of
service corresponding to the required class of service; and
updating at the computer system the storage device to reflect the
requested service being activated on the selected router and port.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 11/317,055 filed Dec. 22, 2005, the contents
of which are incorporated herein by reference in their
entirety.
BACKGROUND
[0002] Exemplary embodiments relate generally to Internet protocol
(IP) networks, and more particularly, to methods, systems and
computer program products for managing access resources in an IP
network.
[0003] IP networks with quality of service (QoS) have the
capability of handling traffic in a differentiated manner so that
the service providers (SPs) can offer different levels of QoS. This
means that the customer user is assured by the SP that from each
access site, the user can send information packets at specified
rates with certain bursting characteristics and delivery qualities
relating to latency, jitter, packet loss, etc.
[0004] One of the problems for the SP is to be able to clearly
define the services to be offered with their QoS characteristics
and present them in service order (SO) language defining the
services, packages and so on. This language must then be translated
into the parameters and values that can drive the logic and
controls of an operation support system (OSS) provisioning system.
The OSS provisioning system must be aware of the resources the SP
has available to provide these services, and be able to account for
these resources as customers grow, change or delete their services.
All of this data must be constantly updated to the network that
supports the service and provides the resources being managed.
[0005] As a customer transmits packets of data (containing for
e.g., data, voice, and video information) into the network, each
router must know exactly how to police the incoming traffic, how to
place packets into QoS queues, how to handle packets that are "out
of contract" (i.e., above contractually assured traffic limits),
how to route the packets, and how to assure that there is no
cross-talk between users (i.e., that no users can listen in on data
being transmitted for another customer.
[0006] Currently, managing the resources that provide access to an
IP network with QoS is largely a time consuming and manual process.
It would be desirable to be able to provide an automated method for
allocating resources to a customer service in an IP network with
QoS. In addition, it would be desirable to manage these resources
throughout the life of the service as it changes over time.
SUMMARY
[0007] An exemplary embodiment is a computer implemented method for
managing access resources in a network. The method includes:
receiving at a computer system a request for network service, the
request including a required class of service; accessing at the
computer system a storage device that specifies routers and
bandwidth available on the routers; selecting at the computer
system a router from the specified routers and a port on the
selected router to perform the requested service, the selecting
including verifying that the bandwidth available on the selected
router and port can perform the requested service, where the
bandwidth is divided into a plurality of capacity classes and the
bandwidth in each class can perform the requested service if the
capacity class corresponds to the required class of service;
transmitting at the computer system instructions to a network
configuration system to initiate activation of the requested
service on the selected router and port, the instructions
specifying a quality of service corresponding to the required class
of service; and updating at the computer system the storage device
to reflect the requested service being activated on the selected
router and port.
[0008] An additional exemplary embodiment is a system for managing
access resources in a network. The system includes an input device,
a processor, and an output device. The input device is for
receiving a request for network service, the request including a
required class of service. The processor is in communication with
the input device and includes computer instructions for
facilitating: accessing a storage device that specifies routers and
bandwidth available on the routers; selecting a router from the
specified routers and a port on the selected router to perform the
requested service, where the selecting includes verifying that the
bandwidth available on the selected router and port can perform the
requested service, wherein the bandwidth is divided into a
plurality of capacity classes and the bandwidth in each class can
perform the requested service if the capacity class corresponds to
the required class of service; and updating the storage device to
reflect the requested service being activated on the selected
router and port. The output device is in communication with the
processor and is for transmitting instructions to a network
configuration system to initiate activation of the requested
service on the selected router and port, the instructions
specifying a quality of service corresponding to the required class
of service.
[0009] A further exemplary embodiment is a computer program product
for managing access resources in a network. The computer program
product includes a tangible storage medium readable by a processing
circuit and storing instructions for execution by the processing
circuit for facilitating a method. The method includes: receiving a
request for network service, the request including a required class
of service; accessing a storage device that specifies routers and
bandwidth available on the routers; selecting a router from the
specified routers and a port on the selected router to perform the
requested service, the selecting includes verifying that the
bandwidth available on the selected router and port can perform the
requested service, where the bandwidth is divided into a plurality
of capacity classes and the bandwidth in each class can perform the
requested service if the capacity class corresponds to the class of
service; transmitting instructions to a network configuration
system to initiate activation of the requested service on the
selected router and port, the instructions specifying a quality of
service corresponding to the required class of service; and
updating at the computer system the storage device to reflect the
requested service being activated on the selected router and
port.
[0010] Other systems, methods, and/or computer program products
according to exemplary embodiments will be or become apparent to
one with skill in the art upon review of the following drawings and
detailed description. It is intended that all such additional
systems, methods, and/or computer program products be included
within this description, be within the scope of the present
invention, and be protected by the accompanying claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Referring now to the drawings wherein like elements are
numbered alike in the several FIGURES:
[0012] FIG. 1 is a block diagram of an exemplary network
environment with access resources that may be managed according to
exemplary embodiments;
[0013] FIG. 2 is an overview of a system and process for managing
access resources in an Internet Protocol (IP) network in accordance
with exemplary embodiments;
[0014] FIG. 3 is a block diagram of a system that may be utilized
to manage access resources in an IP network in exemplary
embodiments;
[0015] FIG. 4 is an exemplary embodiment of a process flow that may
be utilized to manage access resources in an IP network; and
[0016] FIG. 5 is a block diagram of an exemplary network
environment that includes a service provider managed facility that
has access routers that may be managed by exemplary
embodiments.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
[0017] Exemplary embodiments include a method for managing access
router resources in an Internet protocol (IP) network with quality
of service (QoS). The resources managed include variable resources
that vary depending on the number and types of equipment (e.g.,
bandwidth "BW") and fixed resources that are fixed by the type of
equipment. Examples of fixed resources include, but are not limited
to: the number of virtual private networks (VPNs), routing and
forwarding (VRF) tables, route targets (RTs), routings
distinguishers (RDs), policy maps, policers, access queues, IP
security (IPSec) sessions, and point to point protocol (PPP)
sessions a given router can provide.
[0018] Exemplary embodiments provide a very flexible,
parameter-driven process for defining the accounting for resources
as assignments in the network are designed to provide a customer
with an IP-based service (e.g. direct Internet access (DIA) and
IP/VPN access). Resources are allocated to the customer's service
and managed throughout the life of the services as it changes over
time and eventually is deleted from the network.
[0019] FIG. 1 is a block diagram of an exemplary network
environment that includes access resources that may be managed
according to exemplary embodiments. The network environment
includes two networks: a service provider network 102 and the
Internet 104. In addition, FIG. 1 depicts several sites being
connected (in a variety of manners) to the service provider network
102 or to the Internet 104. The example connections include, but
are not limited to, a private line connection, an asynchronous
transfer mode (ATM) connection, a frame relay connection, two
digital subscriber line (DSL) connections, two IPSec connections,
and a cable connection. In addition, the service provider network
102 and the Internet 104 are connected with each other, with a
firewall on the service provider network 102 side of the
connection. Using a network environment such as the one depicted in
FIG. 1, an authorized user from any of the sites will be able to
transfer data and/or voice to any of the other sites. In exemplary
embodiments the service provider is a telephone company with a
service provider network 102 that has been built on broadband
technology. This broadband technology is utilized as a base to
provide the newer voice services to customers.
[0020] FIG. 2 is an overview of a system and process for managing
access resources in an IP network that may be implemented by an
operational support system (OSS) in accordance with exemplary
embodiments. A service order (SO) (including a class of service
(COS)) is received from a customer. Next, a work order (WO) is
created from the service order and entered into the OSS by a
customer service representative 302 (shown in FIG. 3). In alternate
exemplary embodiments the WO is received electronically and/or
directly from the customer requesting the service. Exemplary
embodiments provide a mapping of the language of the WO to the
capacity accounting mechanisms used to define, tally, allocate and
manage the network's resources. The mechanism maintains awareness
of the amount of available resources, the resources required to
fulfill a given service request, the reservation of these
resources, and the maintenance and reporting of the resources.
Exemplary embodiments also facilitate the end of process of
initiating, changing and deleting services which entails the
mapping from the capacity mechanisms to the commands and codes
communicated with the network routers so they are configured
properly to provide the given services.
[0021] The COS language in the WO is mapped to the capacity classes
and the logic of the services to be provided. The services are
designed and resources allocated and accounted for. Then, the
network is configured with the designated resources to provide the
service at the QoS purchased.
[0022] Exemplary embodiments assume that a mechanism such as a
computer system (e.g., an OSS) is capable of maintaining an
inventory of the equipment utilized in IP networks, has the logic
to design IP services using this inventory, is programmed to
provide the processing described herein, can be programmed to map
COS language to the mechanisms of the method, and can communicate
configurations to an IP network.
[0023] IP packets are transmitted across an IP network making use
of a field in the header of the packet called the type of service
(TOS) bits. These bits allow for values from 0 to 7 and routers
examine these bits to determine the priority, queues, and methods
for handling the packets. Based on these eight possible values,
exemplary embodiments provide for users of the OSS to define up to
eight capacity classes. In exemplary embodiments, the users can
specify, for each class: the name of the class; a percentage of the
BW of a managed entity that will be allocated to this class; a
subscription factor that will allow over subscription or enforce
under subscription of the class; and major and minor thresholds
that will cause alerts to be issued when these thresholds have been
crossed.
[0024] Exemplary embodiments also provide for the pre-allocation of
the BW (i.e., prior to the above allocation to the classes) to
remove part of an entity's BW capacity from consideration, taking
into account one or more of the following: overhead factors since
the payload of a port or router is always lower than its
theoretical speed; a redundancy factor to set aside resources to
cover failure cases; and an unmanaged services factor since the OSS
may not manage off of the services that are fun across the network
it manages.
[0025] Exemplary embodiments assume that resources will be managed
at the provider edge routers (PEs) in service provider (SP) data
centers and therefore the above mechanism will be implemented for
these routers, certain ports on these routers, the data center as a
whole and other logical entities designated for special services.
This allows the OSS to make assignments related to WOs based on the
amount of traffic that customer is buying for this service. This
customer's traffic is then tallied with all other customers and the
totals are managed such that no customer can usurp the resources
planned for other customers and the network as a whole can be
managed to avoid hot spots, congestions, interference of some
customers by others and so on. The OSS will provide templates for
all the types of equipment used in the PEs of the SP (e.g., router,
card, port types) and these templates designate the amount of BW
and the numbers of fixed resources this type of equipment will
provide. The users define the topology of their network in the OSS
inventory for their areas of services. As equipment is defined, the
resources designated in the templates are tallied and allocated
into the BW capacity mechanism above and into the counters for
fixed resources at the appropriate levels. These then are the
"money in the bank" that can be used to provide services to end
user of the network services and debited from the available
resource counts as each service is designed by the OSS.
[0026] With the OSS set up, the topology of the network defined and
resources allocated into resource counters and capacity classes,
the OSS user defines the service to be provided to the OSS, mapping
the words defining the service and COS of the service to the
capacity classes and logic of the system design logic. For example,
if the end customer wants an IP connection from this point to that
point with a speed of 10 megabits/second and a COS level of "gold"
in this direction and 20 megabits/second in the other direction
with a COS level of "silver", all based on frame relay technology.
The frame relay PVCs and the IP connections across the network can
be configured such that the 10 Megabits of gold traffic are
scheduled into faster queues with higher reliability than the 20
Megabits of silver that are scheduled into a mix of lower speed
queues. This would be desirable if, for example, the traffic the
customer expects has more voice or video in the gold direction and
more data or email in the other.
[0027] FIG. 3 is a block diagram of a system that may be utilized
to manage access resources in an IP network in exemplary
embodiments. The system includes one or more user devices 302
through which requestors (e.g., a customer service representative)
at one or more geographic locations may contact the host system 304
to access the OSS described herein. In exemplary embodiments, the
host system 304 includes a processor to execute the OSS to perform
the functions described herein. The OSS may be implemented by
software and/or hardware components. The OSS system is in
communication with a network configuration system 310 for making
the actual changes to the network configuration based on
instructions from the OSS. In exemplary embodiments, the user
devices 302 are coupled to the host system 304 via a network 306.
Each user device 302 may be implemented using a general-purpose
computer executing a computer program for carrying out the
processes described herein. The user devices 302 may be personal
computers, lap top computers, personal digital assistants, cellular
telephones, host attached terminals, etc. with user interfaces for
communicating with the OSS. The user interfaces may be implemented
by interface screens, audio technology, voice recognition
technology, or any other technology to allow the user to
communicate with the OSS. If the user devices 302 are personal
computers (or include the required functionality), the processing
described herein may be shared by a user device 302 and the host
system 304 (e.g., by providing an applet to the user device 302) or
contained completely within one or more of the user devices
302.
[0028] The network 306 may be any type of known network including,
but not limited to, a wide area network (WAN), a local area network
(LAN), a global network (e.g. Internet), a virtual private network
(VPN), and an intranet. The network 306 may be implemented using a
wireless network or any kind of physical network implementation. A
user device 302 may be coupled to the host system 304 through
multiple networks (e.g., intranet and Internet) so that not all
user devices 302 are coupled to the host system 304 through the
same network. One or more of the user devices 302 and the host
system 304 may be connected to the network 306 in a wireless
fashion.
[0029] The storage device 308 may be implemented using a variety of
devices for storing electronic information. It is understood that
the storage device 308 may be implemented using memory contained in
the host system 304 or the user device 302 or it may be a separate
physical device. The storage device 308 is logically addressable as
a consolidated data source across a distributed environment that
includes a network 306. Information stored in the storage device
308 may be retrieved and manipulated via the host system 304. The
storage device 308 includes OSS data such as the access routers and
the resources available on these routers. The storage device 308
may also include other kinds of data such as system logs and user
access profiles. In exemplary embodiments, the host system 304
operates as a database server and coordinates access to application
data including data stored on storage device 308.
[0030] The host system 304 depicted in FIG. 1 may be implemented
using one or more servers operating in response to a computer
program stored in a storage medium accessible by the server. The
host system includes an input device for receiving The host system
304 may operate as a network server (e.g., a web server) to
communicate with the user device 302. The host system 304 handles
sending and receiving information to and from the user device 302
and can perform associated tasks. In addition, the host system 304
also communicates with the network resources to cause the requested
service to be added to the network. The host system 304 may also
include a firewall to prevent unauthorized access to the host
system 304 and enforce any limitations on authorized access. For
instance, an administrator may have access to the entire system and
have authority to modify portions of the system. A firewall may be
implemented using conventional hardware and/or software.
[0031] The host system 304 may also operate as an application
server. The host system 304 executes one or more computer programs
(e.g., via a processor on the host system 304) to implement the
OSS. Processing may be shared by the user device 302 and the host
system 304 by providing an application (e.g., java applet) to the
user device 302. Alternatively, the user device 302 may include a
stand-alone software application for performing a portion or all of
the processing described herein. As previously described, it is
understood that separate servers may be utilized to implement the
network server functions and the application server functions.
Alternatively, the network server, the firewall, and the
application server may be implemented by a single server executing
computer programs to perform the requisite functions. The input
device in the host system 304 may be implemented by a receiver for
receiving data (e.g., a request) over the network 306 or via the
user device 302. The output device in the host system 304 may be
implemented by a transmitter for transmitting data (instructions)
over the network 306 or to the user device 302. Alternatively, the
input device and/or output device may be implemented by reading
from and writing to a storage location on the host system 304
and/or the storage device 308.
[0032] FIG. 4 is an exemplary embodiment of a process flow that may
be utilized to manage access resources in an IP network. In
exemplary embodiments, the process flow is implemented by the OSS
described herein. At block 402, a request for IP network service is
received by the OSS. The request for service includes a required
class of service (COS). As described previously, the WO language in
the request for service is translated into capacity/QoS language
for use processing by the OSS. At block 404, the system (i.e., OSS)
accesses the storage device 308 that specifies routers and
resources available on the routers for the IP network. At block
406, the system selects a router to perform the requested service.
Part of the selecting verifies that the selected router has the
resources to perform the requested service. Examples of how the
router is selected are described below herein. At block 408, the
system causes the requested service to be activated on the selected
router. This may be performed by transmitting a command to a
network configuration system 310. At block 410, the storage device
is updated to reflect that the requested service has been activated
on the selected router.
[0033] FIG. 5 is a block diagram of an exemplary network
environment that includes a service provider managed facility
including access routers. FIG. 5 includes a service provider
managed facility 502 (SPMF) that includes several routers for
moving voice and data from one location to another. An SPMF is
commonly known in modern telecommunications as a data center. It is
the data communications equivalent of the older voice world central
office. The various router names in the picture (LNS, BER, ISR,
IRR, CER, HER) are not important per se but represent a variety or
routers of different size and providing different functions or
services. Customers may enter the SPMF 502 via the scenario
depicted in block 504. This includes a local area network (LAN) in
communication with a customer edge router (CE) which is in
communication with a FR or ATM network. The FR or ATM network is in
communication with three provider edge routers in the SPMF 502.
According to exemplary embodiments, each of these connections is
subdivided into eight smaller pipes that receive different
priorities of service. Alternatively, a customer may access the
SPMF 502 via the scenario depicted in block 506. Block 506 includes
a customer connected via a remote PC or a CE into a DSLAM which is
connected to the SPMF 502 via a BBG. According to exemplary
embodiments, block 506 represents a Digital Subscriber Line (DSL)
connection in which an ATM network carries the customer's data
between the customer's equipment and a central broadband gateway
(BBG) where the ATM traffic of many customer's is bundled together
in a high capacity IP connection for transport to the IP carrier's
network. The core of a service provider's IP network is the set of
very high capacity, long-haul IP connections that provide the IP
highways between geographically dispersed SPMFs. This is called the
`backbone`, depicted in FIG. 5 as the Service Provider Routed IP
Backbone (SPRIB). The SPRIB 508 is utilized to allow the customer
to talk to someone in another city via another SPMF. The IE2100 in
block 512 allows the SP to communicate with the customer's CE to
update and manage this equipment for the customer. In addition, the
customer (e.g., from box 504 and from box 506) may talk or transfer
data via the Internet 510.
[0034] The subsequent paragraphs provide more details about
exemplary embodiments that may be implemented and/or facilitated by
the OSS (also referred to as the "system"). Where existing
applications to perform required functions are available, the OSS
may invoke them to perform all or part of the functions described
herein. Where existing applications to perform required functions
are not available the computer code to perform the functions is
located in the OSS.
[0035] In exemplary embodiments, provisioning for DIA and IP VPN
includes: [0036] A. Receipt, verification and analysis of WOs.
[0037] B. Design and assign (D&A) of the services requested in
the WOs. D&A will include capacity and resource availability
management and other rules based logic for best management of PEs
and the access trunks to PEs. [0038] C. Assignment of inventory
objects with object creation, modification and deletion as
required, capacity and resource commitments to the database,
management of all associations and relations between inventoried
objects, and status management of all objects. [0039] D. WOs to be
provisioned include new orders, disconnect orders and "move, add
and change" (MAC) orders for DIA and IP VPN services. For dedicated
access, methods such as, but not limited to, frame relay (FR), ATM
and private lines are available. For non-dedicated access, methods
such as, but not limited to, IPsec, DSL site-to-site and remote
access are available. Various combinations of access to the network
are possible with the lowest access having the SP provide only the
port as access to the SP's network. In other cases the SP provides
the access port and the circuits from this port out to the
customer's site. The full package is for the SP to provide the
access port, the access circuit and the customer's CE (the router
at the Customer's locations, i.e., the Customer Premise Equipment
or CE. [0040] E. Provisioning for inward orders will assemble (not
committed to database yet) the physical, logical, and service
inventory objects for the connection from the customer to the FR or
ATM cloud or the customer end of the private line, and IPsec and
DSL site-to-site and remote access. Provisioning calls the D&A
processes (performed and/or facilitated by the OSS in exemplary
embodiments) to design accesses considering the service request,
access type, access speed, BW requirements, COS, and available
resources. For dedicated access, the best connection from the
FR/ATM cloud or PL into the service provider managed facility
(SPMF) to a PE is chosen. For non-dedicated access, the best
service module (SM) to serve this DSL or IPsec access is chosen.
(Service Modules may provide other services in the future). Note
that the term "best" is defined in later requirements but generally
refers to the connection on a preferred type of equipment,
respecting user defined priorities and fulfilling resource
requirements. [0041] G. Set up/remove Firewall connections. [0042]
H. Set up/remove Management PE/CE connections for managed sites of
a VPN. [0043] I. For DIA service, assure appropriate IP addresses
(from the customer or from the service provider for the local area
network (LAN) and from the service provider for the wide area
network (WAN) and generate packet filters and static routes. [0044]
J. For VPN service, select/create/modify appropriate VRFs, RTs, RD,
static routes, WAN, LAN, Loop Back, IPsec and DSL Remote pool IP
addresses and subnets. [0045] K. Create new objects as required:
customer location(s), IP pools and customer circuits. [0046] L.
Assure data sets for activations and other uses such as
communications with other Systems (e.g., Radius, CAFE, SOEG, WFM,
and so on). [0047] M. New and modified objects are handed back to
the provisioning processes that invoked this D&A. [0048] N.
Provisioning receives the results of the D&A process and reacts
to the success or fail of the D&A process. If the D&A
process is successful, provisioning commits all objects to the
database and signals this success with appropriate information to
the WO or calling process. If the D&A process failed,
provisioning will not commit changes to the database, will see to
rollback if any is required, and will message the calling process
and others as appropriate. Provisioning for outward orders consists
of clean up of deleted and/or cancelled objects. Provisioning for
outward orders is not invoked for the de-activation of the service
but only for the de-allocation of the service as a manual or
scheduled event some configurable time after the deactivation.
Everything is left intact for time with the service turned off via
deactivation of the service in the network. When the configurable
amount of time has elapsed, either by schedule or manual
invocation, D&A recalculates the resource counters to be
changed through release of the resources assigned to this service
and gives the results back to provisioning. [0049] O. Provisioning
receives the results of the D&A calculations. Provisioning then
commits the revised counters to the database; deletes all inventory
objects that do not persist outside of services; releases inventory
objects that do persist beyond being in service; and restores
resources to available. Provisioning for both inward and outward
orders produces the configuration information that is handed (e.g.,
transmitted) to an activation module for causing the indicated
updates to the network elements (NEs). This also includes updates
to the customer's customer edge router (CE) when that is typically
managed by the service provider as part of the service. MAC orders
are moves, adds and changes to existing services. These same
actions against current WOs are called correction passes.
[0050] A multi-protocol label switching (MPLS) VPN is based on an
Internet Engineering Task Force (IETF) specification, Request For
Comments (RFC) 2547bis. In this RFC, the basic MPLS protocol has
been enhanced to support VPN mechanisms. These mechanisms include
VPN routing and forwarding (VRF) table, route target (RT) and route
distinguisher (RD). VRFs, RDs, and RTs are supported in PE routers,
not in other network routers or CE routers.
[0051] VRF table. There can be one or more VRFs (also comparable to
a virtual router) per VPN that constitute a VPN. A VRF contains the
set of routes that are available to a set of sites that are part of
the VPN. If all sites in the VPN participate in only that VRF and
no other VRF, all PEs will contain routes such that all sites are
able to reach all other sites in the VPN. This topology is called a
`full mesh` topology. However, a VPN can have multiple VRFs defined
such that each site might be limited in the set of other sites it
can send messages to or receive messages from. This requires
creation of multiple VRFs for the VPN, configuring them on the PEs
supporting the VPN, and associating them appropriately with the
sub-interfaces of those PEs. A sub-interface interfaces with a
customer site interface. If two or more VPNs have a common physical
site, separate sub-interfaces must be created and IP address space
must be unique amongst these VPNs. For phase 1B, the System will
support full mesh VRFs such that there is only one VRF per VPN.
[0052] RT. Each VPN has import route targets and export route
targets (RT). These are different than IP routes/prefixes, however,
are closely related to IP routes. The import RT associated with a
VRF dictates which routes the VRF should import upon arrival of
Multi-Protocol internal Border Gateway Protocol (MP-iBGP) route
updates. Each IP VPN route that is injected into MP-iBGP is
associated with one or more export RTs indicating which VPNs the
route belongs to. The value of this attribute depends on the VPN
topology. For a full meshed (MP-iBGP between all PEs) topology,
there will be one export and one import RT both with the same
number/identification. Other topologies may need multiple different
RTs associated with a VRF. For this release, the System supports
only full-meshed topology.
[0053] RD. The RD makes any customer IP prefix that needs to be
shared between the PE VRFs, part of the same VPN, unique from other
VPNs across the MPLS backbone. The RD is unique per VPN. The System
supports RDs with a scope at the PE level, such that for a given
customer VPN, each VRF in a PE that participates in that VPN will
have a unique RD. The System shall maintain Type 1 RDs.
[0054] Resource Management.
[0055] This following paragraphs define the methods used by the OSS
to define control parameters in exemplary embodiments to provide a
flexible manner of defining the resources and the logic for dealing
with these resources that provisioning assigns and manages to
D&A services for customers. This will include QoS, BW, VRFs,
RTs, RDs, PE service Profiles, PE sessions for IPsec and DSL remote
service, and so on. BW and QoS are considered to be variable
resources since they vary in amount depending on the number and
size of ports in a PE. The others listed here are considered fixed
resources since a PE of a given type usually has limited numbers of
these resources irrespective of the amount of the PE that is
equipped.
[0056] The term "configurable" as used herein means that the object
defined as configurable is easily changed by the service provider,
at no added charge by the vendor, and is usually GUI-supported.
There will be cases, though, were the change could have such impact
that the service provider will choose to re-align documentation and
to do suitable testing for the change before implementation of the
change. These of course would be subject to charges according to
the effort required by the vendor.
[0057] Exemplary embodiments will manage BW during provisioning
actions in eight capacity classes. The number of these classes is
determined by the three TOS bits in IP packets (and 3 EXP bits in
MPLS packets) that allow the network to differentiate the type and
priority of packets. The QoS queues are the actual queues that the
service provider sets up in its IP network for handling packets of
different QoS characteristics in different manners to deliver the
QoS the customer has purchased. There will be a very configurable
method for mapping capacity classes to QoS Queues.
[0058] As used herein, the term COS (Class of Service) is
distinguished from QoS (Quality of Service). COS is a WO term that
defines what is the level of service that is to be provided for a
given site. QoS is a provisioning and network term that specifies
how the System will map this site's packets to queues in the
network that will provide the requested level of service.
[0059] QoS and BW capacity. QoS and BW capacity will be managed
during provisioning as follows. Access ports other than FR and ATM
ports have no capacity accounting at the port level. They are of
course checked for compatibility with the needs of the service
requested. PEs, aggregated ports and service modules have BW
capacity enforced by capacity class. SPMFs have BW capacity
reported by capacity class but not enforced. Note that for BW
capacity for DIA will be managed in the BW capacity mechanism as
one of the services/products that the service provider offers on
this IP network.
[0060] Defining the mechanism for BW capacity management. BW
capacity will be allocated into capacity classes that are defined
configurably as global, default parameters that can generally
receive local overrides for exceptional cases. BW assignments will
be controlled by these parameter definitions according to the
requirements describe herein and access ports will be configured to
police ingressing traffic to respect these same definitions. The
following are the general features of the overall mechanism used
for these purposes. The number of capacity classes is configurable
but is not likely to change any time soon. The usable BW capacity
of an entity will be determined by the physical or allocated BW
capacity of that entity minus a configurable percentage for
overhead and minus a configurable percentage for redundancy. Note
that with regard to overhead, most routers do not count headers
when managing traffic. Because of this, the real `payload` of
packets in a 100 Mg port can never really be 100 Mg. This
difference is called `overhead` and varies depending on the average
size of packets in a given technology.
[0061] Configurable parameters are provided to specify an overhead
factor per access type--PL, FR, ATM, IPSec site-to-site, IPsec
remote, DSL site-to-site, DSL remote and the general redundancy
factor. Each capacity class will be allocated a configurable
percentage of the BW capacity of the entity being managed ranging
from 0 to 100% of the usable BW capacity of that entity. For each
capacity class, there will be configurable parameters to define
including, but not limited to: a subscription factor (over or under
subscription); a minor alert threshold; and a major alert
threshold.
[0062] This set of defining and control parameters along with the
implied counters is an exemplary embodiment of a mechanism that
will govern BW capacity management in the system. As mentioned
above, these parameters are defined once for the entire system as
the global defaults across the SP IP network. However there is also
the possibility of defining overrides of any of these global
parameters for any given PE, SM or for any port that is managed
with this mechanism. Note that subscription factors will change the
system's view of the BW it has to deal with. If a given class can
be oversubscribed to say 400% and the usable BW in that class for a
given entity is 10 Mg, the system will consider that the entity has
40 Mg of BW. In all accounting and reporting, it will be the 40 Mg
that is available or assigned, and will reported as such.
[0063] Using the BW capacity mechanism. During D&A,
provisioning will use decision tables to determine the best PE,
card and port to service a given request. When a port is selected
to this level, the system will verify that the selected port has
the BW capacity in each of the impacted capacity classes (if it is
managed to that level or as a total BW if not managed to the
capacity class level) and that the PE as a whole has the available
capacity in its summary view of these queues. If the assignment
does not involve a port but rather a service module (SM), the
system checks for available capacity in the impacted queues of that
service module. If the capacity is not available at these levels,
the design process moves on in search of equipment that does have
the required capacity. If an assignment is made but a minor or
major alert threshold is crossed in doing so, the appropriate
alerts and messages are issued. These thresholds will be checked at
the port, PE, SM and BMF levels with each assignment. Reports are
available at all these levels that will indicate the current state
of fill and availability of BW as totals and as specific to each
capacity class.
[0064] Capacity audits are specified that check the consistency of
the system inventory of assigned services with the corresponding
counters at all levels in the system to report on any discrepancies
and to correct them according user's directions. These capacity
audits will also make required adjustments to counters when
parameters are changed that would cause the system to alter its
view of this data. For example, a bad load of software might have
caused the counters to be out of sync with the existing
assignments. Or the service provider might have changed the mapping
of a certain product to capacity classes. The audits could be use
as a migration mechanism to change the allocations across the
database. Of course there would be a further problem of effecting
these changes in the network, but that is a different
consideration. Projecting the balance between user access and
network capacity.
[0065] All PE ports that are in use (allocation status) will be
designated as: access (customer facing); trunk (core network
facing); and unmanaged (in use for services not managed by the
System). This designation will be part of inventory management of
infrastructure, provisioning and the inventory audits. Available
ports will be considered as Access ports by default unless
designated otherwise. The system will attempt to report on the
balance of BW capacity of access from customers and trunks to the
core for each PE and for the sum of all PEs in a BMF but will not
do any enforcement of this during provisioning.
[0066] The total current access BW for a given PE is calculated as
the sum of the following: assigned BW in ports used for private
line, ATM, and FR (capacity class for this BW is known from COS
mapping); the BW of ports in use that are designated as unmanaged
(capacity class for this BW is designated as unknown specifically
and therefore is assumed to be `shaped` in the same proportion as
the global queue BW definitions); the BW of all ports (for this PE)
allocated to service modules (whether in full use of not) (capacity
class for this BW is allocated according to the ratios of the
current queue counts for these service modules); and the percentage
of total trunk BW that is indicated as IPsec or DSL access by
parameters set for this PE in inventory (capacity class for this BW
is allocated according to the ratios of the current queue counts
for the service modules that include this PE). The total current
trunk BW for a PE is calculated as the sum of the BW of all ports
in use as trunk ports minus: the percentage of total trunk BW that
is indicated as IPsec or DSL access by parameters set for this PE
in inventory and the percentage of the total trunk BW used for
unmanaged services. This percentage is calculated as the amount of
unmanaged access divided by the total managed access BW in use on
the PE. BW is allocated according to the capacity class definitions
for this PE described below herein. Unless overridden locally for
this PE, these queue size definitions are the general default
definitions that are system-wide.
[0067] Based on these calculations, the system will able to give a
rough estimate of the access versus trunk BW capacity for each of
the PEs in the network as total BW and as BW broken down by
capacity class. All PEs in a SPMF can be summed up to the SPMF
level so that the actual access BW can be compared to the actual
trunk BW. Furthermore the actual trunk BW allocation by capacity
class can be compared to the desired capacity class allocations.
These will be the same if there are no overrides defined for any PE
in a given BMF. Note that the "usable BW" (uBW) of an entity is
defined as the BW of that entity after the redundancy, unmanaged
and overhead factors have been removed:
uBW=[BW*(100-Redundancy)*(100-Overhead)*(100-Unmanaged)].
[0068] Fixed Resources. Fixed resources are those that are
determined or fixed by the type of equipment that provides the
resource such as number of VRFs, RTs, RDs, IPsec sessions, PPP
sessions, and access queues (AQs). If a PE, card, port, or service
module has any limit on the number of these resources it can
support, this will be defined either as part of the template for
that equipment if it has such a template or as definition
parameters when the entity is defined in the inventory. If no limit
is specified at a given level, it inherits the limit from the next
level up for that equipment. For example, each PE type has a
limited number of VRFs it can handle. It is further possible that a
given card type and its ports have their own limits beyond this.
Say a given PE of type x can handle 1000 VRFs, a given card might
only handle 100 VRFs and each port might be limited to 3 VRFs. If
the port in this case had no specific limit, it would not be
tracked and only the 100 VRFs for the card would be tracked. These
limits are specified in this Inventory chapter of these
requirements as part of the specifications of these objects. The
configurable specification of these resources and their management
logic is specified below in these requirements. An example of
configurable parameters would be the minor and major alert
thresholds for VRFs in general.
[0069] In general, management of fixed resources is a
straightforward problem of counting them as they are assigned to
and released from services. A slight wrinkle comes in considering
service modules (SMs). When SMs are defined, the user will specify
a parameter that allocates a percentage of the fixed resources of
each PE represented in that SM to the SM. These resources are
deducted from the counts of the PE and considered in use as far as
the PE is concerned. They become available resources for the SM and
are accounted for there on a per PE basis. This is the downside of
SMs. Since the SMs select PEs on a per session basis, all PEs must
have the capability to handle any session. They therefore must have
the configurations to handle any service assigned to the SM and
this requires redundant use of these fixed resources, i.e., they
have to be allocated redundantly to every PE in the SM. Note that
if any ports from a PE are designated specifically as part of a SM
and have specific limits on any fixed resources, these limits will
be ignored by the system since it is the province of the SM to
select these ports real time.
Resource Management Requirements
BW Capacity
[0070] Note that network queues are not the same as access queues
(AQ) treated with the fixed Resources subsequently herein. Network
queues are aggregated queues in the network core--trunk ports and
trunks--and carry packets across the network. Access queues exist
in dedicated access ports, police ingress packets and generally are
allocated to a single VPN access at time. This latter condition can
be overridden in the case of some best effort services.
[0071] Capacity Classes and Network Queues. In exemplary
embodiments, the system shall provide a configurable number of
capacity classes (NbCCs, default=8) and a configurable number of
network queues (NbQs, default=4) that shall not exceed the number
of capacity classes. Each class shall be configurably associated
with exactly one queue. The numbers of classes and queues shall not
be overridden locally. Note that the term "BW" unqualified by any
modifiers and "theoretical BW" mean the base, physical bandwidth of
an entity prior to any consideration of overhead, redundancy, and
so on.
[0072] BW Capacity Accounting. The system shall keep an accounting
of BW assignments by capacity class (CC) for all: aggregated ports
(e.g., FR, ATM); PEs; service modules (global for the SM as a
whole, and local for each BMF in which it appears); and SPMFs. Lack
of available BW in requested classes at the port, PE or SM levels
shall cause the assignment to fail for that entity. Lack of BW at
the SPMF level shall not cause assignments to fail. Port BW shall
be determined by line speed unless restricted by committed
information rate (CIR), purchased partial speed or other
limitation. Port BW is counted as core trunk BW if assigned as a
trunk, counted assigned access BW if assigned to a dedicated access
or an SM, and available access BW if not assigned or partially
assigned (aggregation or limited by CIR, for example).
[0073] PE BW shall be determined by the ports assigned for use or
available for use. PE Core Trunk BW shall be the sum of the BW of
all trunk ports. PE available access BW shall be the sum of all
available port BW. PE access BW shall be the sum of port BW
assigned for access service. Allocation of Trunk BW and Available
BW shall be determined by the Capacity Class parameters (defined
below) that apply to this PE. Further PE considerations follow.
Each PE could have ports (trunk and/or access) that are designated
as "unmanaged." The BW of these ports is removed from consideration
in any other categories. Each PE shall have an "unmanaged access
parameter" and an "unmanaged trunk parameter." These parameters,
expressed as percentages, will remove from consideration the
specified proportion of the Trunk and Access BW of the PE's totals
in these categories. For any service module defined on a PE, a
percentage of the trunk BW may be allocated to that SM. In this
case the system shall consider this BW as trunk or access according
to the trunk/access ratio factor for that SM, assigned in the PE's
resource reports and the access portion as assignable for the
SM.
[0074] Trunk BW shall be the line speed of ports designated as
trunk ports. See the definition of the non-dedicated trunk to
access ratio parameter below. Service module BW shall be determined
from the BW of supporting PEs as defined as a percentage of that
PE's total trunk BW or from BW of specific ports defined as
supporting this SM. Of the BW allocated to the SM as a percentage
of a PE's trunk BW total, part shall be considered access available
for assignment and part shall be considered trunk BW. The ratio of
these parts to each other shall be configurably defined by the
trunk/access ratio factor for that SM (defaulted to 50/50). All BW
from specific ports in the SM is considered assignable access BW.
SM BW shall be accounted for each SPMF where it is present and as a
total of all these SPMFs presences. Only the total BW accounting
shall control assignments. The per SPMF accounting shall be used
for reporting and access versus trunk BW balance analysis. Note
that since the BW of an SM can be based on the trunk BW of PEs, the
theoretical BW of SMs shall be recalculated whenever the trunk BW
of a supporting PE is changed.
[0075] Trunk BW allocated from a PE to an SM shall be considered
"assigned" trunk BW for that PE in reports. Port BW allocated to an
SM is considered "Assigned" BW for that PE. BW shall not be
considered allocated to an SM until the equipment supporting the SM
has been successfully configured for that SM (and any pre-existing
services already serviced by that SM).
[0076] SPMF BW shall be determined from the PEs and SMs present in
that SPMF. SPMF BW accounting shall not control assignments. The
per SPMF accounting shall be used for reporting and access versus
trunk BW balance analysis.
[0077] Resource Redundancy for Service Modules. The system shall
assure redundancy of resources in SMs by making sure that if any PE
in a SM fails, the sum of available resources allocated to this SM
in other PEs is greater than or equal to the resources allocated to
the SM from the failed PE. An example formula follows: 1. assume
the failover/redundancy principle is that any PE can fail and the
other PEs in the SM can pick up the load from that PE; and 2.
assume that an SM can have any number of PEs and any number of
session contributions. If SumOthers=sum of all sessions of all PEs
except the largest, and SessLargest=the sessions of the largest
PE/contributor, then let the SessDiff=SumOthers-SessLargest and
therefore, the SumOthers-SessLargest>=0, or assumption 1 is
violated, and MaxSess=SessDiff+SessLargest. The MaxSess is the
number of allocatable sessions the SM has for servicing VPN Remote
services while assuring failover redundancy. This same principle
will work for each of the resources allocated to an SM.
[0078] BW Capacity Class Control Parameters. The system shall
provide a configurable parameter to define an overhead factor for
each access method--FR, ATM, PL, IPsec and DSL Remote and
Site-to-Site, and a generic overhead factor. The system shall use
the generic overhead factor in calculations unless another overhead
factor is known to apply in a specific case. For SMs whose type is
determined by the access method it supports, the overhead factor
shall be the average of the overhead factors of the access methods
it supports. For any port that is assigned and supports a
system-known set of access methods, its overhead factor shall be
the average of the overhead factors of the access methods it
supports. Since overhead factors can be overridden locally, some
local overhead factor will apply in specific cases. In all
requirements that follow, the term "Overhead factor" shall be
understood to mean the finally determined overhead percentage
resulting from the considerations and calculations of this present
requirement. The system shall also provide a redundancy factor and
an unmanaged services factor. When the system is calculating the
"usable BW" of an entity, these percentages of the physical BW
shall be removed from consideration before the BW of that entity is
allocated to the capacity classes as available for assignment. The
usable BW (entity)=theoretical BW (entity)*[100-(overhead
factor+redundancy factor+unmanaged svcs factor)] where the 3
factors shall not exceed 100.
[0079] Capacity Class (CC) Control Parameters. The system shall
provide a configurable number of capacity classes (NbCCs,
default=8) and a configurable number of network queues (NbQs,
default=4) that shall not exceed the number of capacity classes.
Each class shall be configurably associated with exactly one
queue.
[0080] Each CC shall have an allocation parameter (CCnVol %)
between 0 and 100% that shall determine the amount of usable BW of
an entity is allocated to this CC. The sum of these parameters
shall always equal 100. Each CC shall have a subscription parameter
(CCnSubsc %) between 0 and 1000% that shall determine the amount of
assignable BW that CC has based on its allocated BW. For this
parameter, 100% is full-subscription. Less than 100% is an
under-subscription constraint and over 100% is allowable
over-subscription. When this parameter is not 100%, the system
shall consider that total BW capacity of any entity in question is
now raised or lowered as indicated. (i.e., assignable BW may be
different from the physical BW.) Each CC shall have a major and a
minor threshold alert parameter that the System shall use for
notifications that an entity is approaching BW exhaustion.
[0081] Each CC shall also have an access queue allocation parameter
(CCnAQAlloc) that can have a value from -1 to 2 that shall
determine the allocation rate of access queues (AQs) in that class.
For this parameter, the value: -1 shall indicate that the AQ count
is kept but not controlled (no limit); 0 shall indicate there is no
AQ accounting defined for this class; 1 shall indicate there is 1
to 1, assured AQ accounting defined for this class; and 2 shall
indicate there is non-assured AQ accounting defined for this
class.
[0082] Capacity Class Queue Parameters. The system shall provide a
GUI-configurable queue marking (CCnMarking) parameter that shall
determine the mapping of TOS value (0-7 currently) that the network
shall use to determine the queue mapping and policing for packets
ascribed to this CC. The system shall provide a GUI-configurable
out of contract behavior (CCnOOCBehavior) parameter that shall
determine the behavior that the network shall use for packets
ascribed to this CC that exceed policed values for an assigned
queue (e.g., drop, forward, remark and forward). In exemplary
embodiments, these parameters shall not have local overrides.
[0083] Trunk BW--Trunk to Access Ratio. For non-dedicated services
(e.g., DSL and IPSec) access to the IP Network is provided by
trunks rather access circuits for customers. In order to make
projections of the balance in the traffic across PEs as divided
into the PE's customer access versus the PE's IP network access,
this non-dedicated service must be taken into account. The system
provides a non-dedicatedTrunktoAccessRatio parameter that specifies
the amount of trunk BW that is considered trunk BW (i.e., BW
between a PE and the IP core network) versus access (i.e., BW
between a PE and a customer). Since this only applied to trunks
that connect PEs to the core network, this parameter shall be
defaulted to 50% and this shall mean that 50% of the trunk BW of a
PE or SM is considered trunk BW and the rest is considered access
BW. This parameter shall have local override capability at the PE
and SM levels.
[0084] Capacity Control Parameters and Factors. All these
parameters and factors shall be GUI-configurable. All these
parameters and factors shall be defined once at a system wide,
general default level, and shall apply in all cases throughout the
system unless there is a locally defined override. Some service
providers may require that these general, default parameters and
factors be implemented as defaults, not as templates. This means
that they will not be embedded in local records and any changes
made to them will apply immediately throughout the system. No
migration of data is required to implement them, although capacity
audits may be required to true up accounting data to any new
definitions.
[0085] The system supports GUI-supported, exceptional,
configurable, local overrides for these parameters and factors
unless otherwise specified. These local overrides are permitted for
any port, PE or SM for which the system does BW accounting. When
such a local override is defined, the system shall apply this local
override instead of the corresponding general default
parameter/factor. Local overrides are not affected by changes made
to the corresponding general system defaults. When a local override
is deleted from an entity, the corresponding general default
parameter resumes its normal function for that entity. Local
overrides and subscriptions factors are taken into account for any
higher level entity affected by the setting or changing of these
parameters such that in PE accounting, the available and assigned
totals for the PE equals the sum of all access port accounting, not
counting SM allocations, having taken into account all parameter
settings including local overrides and subscription factors. In
similar fashion, BMF accounting must always represent the sum of
all access PEs in that SPMF. Capacity Audits will also assure these
rules.
[0086] Example: Port BW Calculation. Suppose there is a 100 Mg.
port with no local overrides and the general default settings are:
overhead=3%; redundancy=25%; and unmanaged=0%. The usable BW of
this port would be: 100 Mg*[100-(3+25+0)]=72 Mg. Suppose that CC3
is low latency gold with out of contract (OOC) behavior forward and
CC3Vol=20%. Suppose also that CC4 is low latency silver with OOC
behavior re-mark/forward and CC4Vol=20%; and that CC5 is CBW with
OOC behavior re-mark/forward and CC5Vol=30%. In addition,
subscription rates are 100% for CC3 and CC4, and 150% for CC5. The
assignable BW of this port in CC3 would be equal to 72 Mg*20%*100%,
or 14.4 Mg. For CC4 the assignable BW would be equal to 72
Mg*20%*100%=14.4 Mg. In CC5 the assignable BW would be 72 Mg*30% *
150%=32.4 Mg.
[0087] Example: SM BW Calculation. Suppose an IPsec SM is defined
and is allocated 25% of the trunk BW of PEx and 20% of the trunk BW
of PEy. If the total trunk BW of PEx=7 Gig and PEy=10 Gig, with
local overrides for CCnVol all set to 0 except CC9=100, and the
General Default settings are: IpsecOverhead=2.5%; redundancy=25%;
and unmanaged=0%. The theoretical BW of this SM would be: 7
Gig*25%+10 Gig*20%=3.75 Gig. The usable BW of this SM would be:
3.75 Gig*[100-(2.5+25+0)]=2,719 Mg. Since BW from PE trunk
allocations is split into both trunk and access (assume 50/50), the
access BW for this SM would be half of this or 1359 Mg. All of this
would allocated to CC9 and if the subscription rate for this CC is
400%, there would be 5,438 Mg of assignable BW in this SM.
[0088] D&A BW Capacity Management. D&A shall manage BW
capacity by calculating the impact on each capacity class for a
given provisioning action. This entails using the effective BW and
distributing it into class categories as defined by the capacity
class control parameters. This specifies the amount of BW to be
incremented or decremented in each capacity class for the object
being affected. If the BW allocation is decreased in any capacity
class, D&A calculates the new BW availability in that class for
this entity and all higher entities. If the BW allocation is
increased in any capacity class, D&A calculates availability of
the BW in that class for this entity and all higher entities. If
the BW is not available at the port, PE or SM global level, D&A
shall fail this operation. If the BW is available at the port, PE
and SM global level as applicable, the system sets up the counters
to reserve the changed BW at all levels affected by the change.
These counters shall be committed to the database by the calling
routine. If the BW is available but crosses a minor or major alert
threshold at any level, D&A shall generate the appropriate
messaging and notifications. In the case where assignment of a
service to a port uses part of the BW of that port and causes the
rest of the BW for that port to become unusable (e.g., fractional
service), the unusable portion of this BW is subtracted from or
added back to the available counts for all related objects. The
system shall return control to the calling routine.
[0089] Exemplary embodiments provide a flexible, parameter-driven
process for defining the accounting for resources as assignment in
a network are designed to provide a customer with an IP-based
service. Resources are allocated to the customer's service and
managed throughout the life of the service as it changes over
time.
[0090] As described above, embodiments may be in the form of
computer-implemented processes and apparatuses for practicing those
processes. In exemplary embodiments, the invention is embodied in
computer program code executed by one or more network elements.
Embodiments include computer program code containing instructions
embodied in tangible media, such as floppy diskettes, CD-ROMs, hard
drives, or any other computer-readable storage medium, wherein,
when the computer program code is loaded into and executed by a
computer, the computer becomes an apparatus for practicing the
invention. Embodiments include computer program code, for example,
whether stored in a storage medium, loaded into and/or executed by
a computer, or transmitted over some transmission medium, such as
over electrical wiring or cabling, through fiber optics, or via
electromagnetic radiation, wherein, when the computer program code
is loaded into and executed by a computer, the computer becomes an
apparatus for practicing the invention. When implemented on a
general-purpose microprocessor, the computer program code segments
configure the microprocessor to create specific logic circuits.
[0091] While the invention has been described with reference to
exemplary embodiments, it will be understood by those skilled in
the art that various changes may be made and equivalents may be
substituted for elements thereof without departing from the scope
of the invention. In addition, many modifications may be made to
adapt a particular situation or material to the teachings of the
invention without departing from the essential scope thereof.
Therefore, it is intended that the invention not be limited to the
particular embodiments disclosed for carrying out this invention,
but that the invention will include all embodiments falling within
the scope of the claims.
* * * * *