Dynamic Resource and Admission Control logically resides between the transport network layer and the application / session layer. From its control plane position it controls the use of network resources on behalf of applications to provide QoS guarantees. At session initiation it receives a service request upon which it makes admission control decisions to accept or deny the session. If necessary, as determined by network architecture and application requirements, resource control then goes on to enforce a policy in the transport network as a consequence.

To meet the requirements of dynamic Resource and Admission Control (dRAC), there are a number of key architectural requirements which must be met:

• Scale: dRAC can be deployed in small single service networks solving specific service contention issues. Alternatively they can be deployed into tier 1 multi-service networks with millions of subscriber. Any solution must be capable of meeting these two scenarios and of course migrating and evolving from a small to very large deployment
• Integration: dRAC must be capable of integrating quickly and seamlessly with many application types such as IPTV middleware, IMS CSCFs, Session Border Controller Border Gateway Functions
• Resilience: dRAC exists in the control plane between application and transport. It must be able to function under normal, exceptional load, and failure conditions.
• Abstraction: allowing the applications to be entirely independent of the underlying transport infrastructure. This means that new services can then be launched quickly as they change nothing about the transport layer other than potentially the capacity that they use.

Operax Resource Controllers

For telecommunications networks Operax offers a portfolio of Resource Controllers to meet the demands of dynamic Resource and Admission Control. Operax Resource Controller 3300 provides solutions for single service networks with specific resource contention issues either in access or aggregation with a full upgrade path available to Operax Resource Controller 5500. Resource Controller 5500 is a complete multi-service product for access and aggregation networks with the ability to scale from small to full scale Tier 1 deployments. Operax Resource Controller 5700 provides guaranteed QoS across core IP MPLS networks.

In military networks Operax provides mission-proven COTS (Commercial Off The Shelf) solutions for guaranteeing end-to-end communication in systems for military communications networks designed on the principles of Network Centric Warfare (NCW), Network Centric Operations (NCO), Network Enabled Capability (NEC), and Network Based Defense.

Operax Product Architecture

The Operax product set is composed of two key components as shown below:

Operax Service Policy Manager (SP-Man): Providing a single point of contact for applications, service policy control, resource mediation, Overload Control, and media gateway control. It is the SP-Man which decides which IQ-Mans need to be contacted to decide if resource exists for each request from the application.

• SP-Man provides a single point of contact to the application / session layer and then routes the reservation requests to the right instance(s) of IQ-Man. With this approach applications can be completely independent of the underlying topology and technology of the transport layer. This can significantly improve the speed of deployment of new services. This property is also essential when there is an administrative split between network provider and service/application provider. Resources for any IP flow or tunnel (encrypted or not) may be requested.

• IQ-Man implements resource and policy-based admission control. Its generic implementation ensures multi-service and multi-technology operation. The resource map in IQ-Man implements a representation of the network topology and resource policies. The level of detail may vary from a completely accurate map of the real network to a more abstract representation where only the critical bandwidth contention points are represented. It also contains information about attached subscribers, ongoing sessions and their bandwidth consumption. The resource map can model any network topology, including for example layer 2 Ethernet with VLANS, ATM with VC/VP, MPLS and Routed IP topologies. This provides full flexibility and alleviates the need to hard-wire admission control in the network architecture.

Scale: The architecture of the Operax Resource Controller provides ultimate flexibility in scale. For initial deployments, one SP-Man and one IQ-Man can be deployed with IQ-Man managing one or many access/aggregation networks. For larger networks, the resource Controller can be deployed as a distributed system for which the two main functions of SP-Man and IQ-Man can be physically located on separate hardware, organized in two tiers. This is an indispensable design property allowing the system to scale massively.

The tiered design of the Operax Resource Controller allows the SP-Man tier to route reservation requests from application functions (AFs) to the correct IQ-Man instance responsible of the requested resources. Multiple SP-Mans may also be deployed to further increase scale with individual services married to an SP-Man instance or sets of subscribers for load sharing purposes.

Integration: The flexibility to interoperating with any type of AF is essential for a Resource Controller. It allows an operator to deploy dynamic Resource and Admission Control for any early service (i.e. without restrictions based on the Application Function supporting particular protocols).This flexibility also allows the system to evolve covering other services that may not be considered or even known at early phases of deploying the Operax Resource Controller.

SP-Man interfaces with AFs using its northbound Resource and Policy Control (RaPC) API and the DIAMETER and XML/SOAP protocols built on this API. While the DIAMETER protocol application provides standards interfaces, the XML/SOAP protocol can easily be adapted to interoperate with various AFs such as different brands of IPTV middleware, pre IMS SIP servers, etc. If an AF supports neither DIAMETER nor XML/SOAP, another integration module can be built directly on the RaPC API.

Resilience: Operax Resource Controller implements 2N resilience (i.e. 1+1 local resilience within chassis and between chassis). Session data is asynchronously replicated between internal databases of active and backup SP-Man and IQ-Man instances for optimal capacity. Transfer logs and check pointing is used to reduce the risk for data loss due to asynchronous database writing.
Abstraction: Operax SP-Man acts as a single-point of contact to Application Functions. The Application Functions that want to make use of the transport network resources don’t have to explicitly know where the actual network resources are located. Providing a single point of contact Operax SP-Man effectively hides the underlying network topology from the AFs requesting services from Operax SP-Man.