A. Receipt, verification and analysis of WOs.
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.
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.
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.
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.
G. Set up/remove Firewall connections.
H. Set up/remove Management PE/CE connections for managed sites of a VPN.
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.
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.
K. Create new objects as required: customer location(s), IP pools and customer circuits.
L. Assure data sets for activations and other uses such as communications with other Systems (e.g., Radius, CAFE, SOEG, WFM, and so on).
M. New and modified objects are handed back to the provisioning processes that invoked this D&A.
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.
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.

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.

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.

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.

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 maintainType 1 RDs.

Resource Management.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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)].

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.

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 RequirementsBW Capacity

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.

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.

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).

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.

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.

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).

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.

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, orassumption 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.