INTERNET-DRAFT Internet Engineering Task Force Sunil Mahajan INTERNET DRAFT Hughes Software Systems Feburary 2, 1999 Expires August 2, 1999 RPCP Resource Pool Control Protocol Sunil Mahajan Version 0.1 draft Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are drafts documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html ABSTRACT RPCP is a generic interface protocol between two entities, where one entity acting as Resource Pool (RP) and other being the Resource Pool Controller (RPC). The RP entity in turn may be acting as RPC for other RPs in a hierarchical manner. The resource being defined can be any hardware/software, physical/virtual resource. In today's telecommunication world, the intelligence is being moved away from the hardware (the embedded platform) or the switching fabric to a more generic computing resource (high-end servers). These computing resources controls the call logic, service logic and the network signalling part. This implies that there is a need for an open interface protocol by which call agents or signalling agents can control this rather dumb hardware Mahajan [Page 1] INTERNET-DRAFT Resource Pool Control Protocol August 1999 as resource pools. This helps in easy and smooth integration of these entities even if they come from different vendors. The Interworking and Gateway market is a very big market today. The network architecture proposed for these solutions carries the intelligence away from the resource pools (also called media gateways) to call agents or pool controllers (also called media gateway controllers). With such network architectures the need for such a protocol is more prominent. There are many other needs and use of such a protocol which will be discussed in detail in this white paper. This paper does not try to define the complete protocol, however the basic definition and the protocol architecture will be defined. The document first describes the application of Resource Pool Control protocol, followed by requirements from this Protocol and then defines the Protocol Architecture with basic protocol definition. The annexure of the document gives few examples on RPCP usage. 1.0 APPLICATION OF RESOURCE CONTROL PROTOCOL There are many applications for a resource control protocol, but all of them will not be discussed over here. However a few of the representative needs are detailed below. 1.1 Signalling and Call Agents separation from switching fabric As new switching architecture or network components are moving intelligence away from the hardware (embedded platforms) to more generic computing resources (high-end computers). Different vendors can produce these two components, with an open interface defined between them. The call agents/signalling agents controls the hardware resource pools through such a control protocol or interface. Each vendor is defining its own interface to control the hardware resources or to communicate signalling information, from the controlling entity (call agents/signalling agents) to resource pool. It will require efforts on the controlling entity part to comply with number of such interfaces. However if an open and flexible protocol definition exists and being used by both the sides, the integration of switching fabric and call intelligence will be an easy task. 1.2 Gateway Architecture Most of the gateways today have a distributed architecture with intelligence moved away from the resources required for the application/service, to the call-agents/signalling-agents and an Mahajan [Page 2] INTERNET-DRAFT Resource Pool Control Protocol August 1999 interface protocol being defined between these two entities by the vendor himself. One of the examples for such architecture is voice over packet network gateways. These gateway supports SCN interface on one side and packet network interface on the other side. The architecture suggested for such gateways requires the resource pool (voice processing, voice packetization, echo cancellation etc) being concentrated on one entity called the media gateway and the intelligence for call handling and resource control being located on other entity called media gateway controller. The media gateway controller can control multiple of such media gateways depending on the processing and interface capacity of the controller. However to the external world i.e. the PSTN network and the packet network the gateway appears as a single entity providing the interworking/gateway functions. Therefore for such architecture there is a need for an interface protocol by which media gateway controller can control multiple media gateways. As of today there exists few such protocol which defines the interface for such communication. The major drawback of these protocols is a bias towards the voice over packet gateways and the protocol is not generic to cater to all the gateway/interworking function requirements. 1.3 Resource Sharing Toady's telecom network architecture is moving towards resource sharing concept, instead of each application/service to own the resources required. One of the example is the Intelligent Peripheral (IP) component in AIN (Advanced Intelligent Networks). IP provides the voice resources required for any call-related application, to any of the SSP/SCP (Service and Switching Point/ Service Control Point) in the network. This can access these components. The logic for moving such a resource to a separate component in network to allow sharing of resources and easy definition of service logic. Similar to this there are many other services which requires sharing of resources like, Interactive Voice Response (IVR) applications, call centres, conference bridges etc. If the service logic resides somewhere else and the service resources concentrated on a separate entity, it requires an interface protocol for communication or for resource control. 1.4 Rapid Introduction of new Services In case of traditional telecommunication network, any new service development requires changes throughout the network for the service logic to be supported at each and every node in the network, since the service logic is embedded into each and every node. The current AIN network architecture moves the service logic away from service node and is being controlled by a few service controls points in the network. As the demand for new service in the market is high, the same reasoning applies to other network domains as well, which Mahajan [Page 3] INTERNET-DRAFT Resource Pool Control Protocol August 1999 requires the service logic to be easily adaptable/introduced in the network by changing the logic (or putting a new service) at a few nodes in the network. Therefore for a fast and easy service introduction in the market the service development may require parallel development by many. This requires the interface to be defined every time a new service is developed. If no standard interface exists, a new local interface is used every time a new service is defined. 1.5 Hierarchical Networks Most of the toady's telecommunication networks have hierarchical network configuration. This sometime requires different protocols at different levels. The need for different protocol for network management, signalling control, node management or even for service management, if the network node has a different perspective view of the nodes below it in the hierarchy or for the nodes it is controlling. However, if each node in the network views the other node that it is controlling or managing, as resource pool and the interface between them is the resource control protocol, the interface at all levels is uniform. This definition can be extended even to lower levels of communication, like signalling protocol layers talking to hardware which is implemented as RP and protocol control entity as RPC. Another example can be the voice application (media control applications) controlling the media control provided by hardware or firmware, if media acts as RP and control application as RPC. If this protocol provide uniform interface at all levels, then each entity in the network needs to define the resources it hold and the capability of each such resource. The resource control entity needs to use this interface to control these resources to provide the desired service in the network. 2.0 REQUIREMENTS FROM RESOURCE CONTROL PROTOCOL The requirements from Resource Control Protocol are listed below - Interface protocol definition to be simple and generic. - Definition needs to be standardised. - Definition of protocol to be defined as binary protocol not text based (Being an application level protocol it may use ASN definition for protocol constructs). - Protocol needs to support resource advertising. - Protocol to support resource capabilities advertising. - Protocol to support controller redundancy. Mahajan [Page 4] INTERNET-DRAFT Resource Pool Control Protocol August 1999 - Protocol to support service/logic/script execution by resource pool, the service/script logic to be derived from resource capability. - Protocol to support failure management of resources and entities. - Protocol definition can be extended to support management (configuration/ statistics/alarms) interface. - Protocol to support any resource control, where the resource can be a hardware resource, software resource or even the algorithms. Examples of resources are bearer trunks in network, SS7 node advertising SS7 signalling as resource and capability as enable/ disable signalling. - Protocol definition to support the hierarchical resource configuration, which means that the resource pool may in turn be controlling other resources by same protocol and the same definition is applicable at all the interfaces. - Protocol definition should be extendable to support any generic protocol embedded in it. - Protocol to be superset of any popular gateway control protocol like MGCP, i.e. any capability/function supported by MGCP to be there in this protocol as well. - Initial definition of protocol to provide support for international network signalling protocols like SS7 etc. and later definitions may provide support for other protocols. However the definition of protocol to be generic to support any interface, but first definition to give representative cases/ examples for such protocols or network configurations. 3.0 DEFINITIONS - Resource Resource, is the entity in the resource pool which along with the resource capabilities can be used by Resource Pool Controller either independently or in combination with other resource entities to execute a service. Resource can be any hardware, software, physical or virtual resource. Example of hardware resources are bearer trunks, interface cards etc. Examples of software resources are signalling software, voice processing software etc. Examples of physical resources are hardware resources, circuits, subscriber lines etc. Examples of virtual resources are the resources controlled by any Resource Pool Controller but being advertised by it as holding them as resources. Mahajan [Page 5] INTERNET-DRAFT Resource Pool Control Protocol August 1999 - Resource Pool RP, is the logical collection of resources of similar kind or different kinds with the capability to interface with RPC, advertise and execute the resource capabilities on command from RPC. - Resource Capability RC, is the detection, generation or execution capability of the resources defined above. Examples of RC are detection of line signals on line interface, tone generation or detection capability. Resource capability is always specified along with the resource identification. - Resource Capability Category Capability category determines whether the capability is of detection, generation, and execution or combination type. - RPC Resource Pool Controller, is the entity, which controls the resource pool entity through interface protocol RPCP. However the service logic or the control logic is supported by the RPC. - RPCP Resource Pool Control Protocol, is a generic interface protocol between two entities, where one entity acting as Resource Pool (RP) and other being the Resource Pool Controller (RPC), however the RP entity may in turn be acting as RPC for other RPs in a hierarchical manner. - Control Interface Control interface is the interface between RP and RPC. 4.0 PROTOCOL ARCHITECTURE This section describes the protocol architecture and few of the constructs needed to define protocol. Each of these constructs will have definition of the protocol elements required for it. However this paper does not try to define the complete protocol. 4.1 Network Architecture This protocol is an interface protocol between RP and RPC. The connection at the logical level or protocol interaction level is assumed to be of tree type as shown in following picture. Mahajan [Page 6] INTERNET-DRAFT Resource Pool Control Protocol August 1999 ------------ | | | RPC |<---------- ----> | | | | ------------ | | ^ | | | | | | | RPCP - - - - - - - - - - - - - - - - - - - - - - - - - | | | | | | V V V ------------ ----------- --------- | | | | | | | RP | | RP/RPC | | RP/RPC | | | | | | | ------------ ----------- --------- ^ ^ | | RPCP - - - - - - - - - - - - - - - - - - | | V V --------- --------- | | | | | RP | | RP | | | | | --------- --------- Figure 1 RPCP Network Architecture One RPC can be connected to many RPs whereas each RP can get connected to only one RPC. This definition however is applicable at logical level or the protocol interaction level. Single physical entity may host more than one RP, whereas each RP may be interfacing with different RPC for resource control. Each of this RPs may then be treated as separate RPs at logical level. Mahajan [Page 7] INTERNET-DRAFT Resource Pool Control Protocol August 1999 ----------- --------- | | | | | RPC | | RPC | | | | | ----------- --------- ^ ^ | | RPCP - - - - - - - - - - - - - / - - - - | / | --------------- | | V V --------- | | | RP/RP | | | --------- Figure 2 Physical Interface between RP and RPC ----------- --------- | | | | | RPC | | RPC | | | | | ----------- --------- ^ ^ | | RPCP - - - - - - - - - - - - - - - - - - | | | | | | V V --------- --------- | | | | | RP | | RP | | | | | --------- --------- Figure 3 Logical level interface between RP and RPC 5.0 RPCP PROTOCOL DEFINITION RPCP protocol is an application level protocol. The protocol definition today does not define the lower layers required for the transport of protocol element/constructs between RP and RPC. However the lower layer support or the communication channel type required are listed below. Mahajan [Page 8] INTERNET-DRAFT Resource Pool Control Protocol August 1999 - Non Real-Time Reliable Communication Channel. Examples are TCP connections on ethernet, SCCP connections in SS7 networks etc. This channel is needed for protocol construct, which do not have reliability defined with protocol. However unreliable channel can be used instead with reliability being handled by protocol. - Non Real-Time Unreliable Communication Channel. Examples are UDP connection on ethernet, high- speed, local bus communication etc. This channel is used for protocol constructs which have reliability defined with protocol. However reliable channel can be used instead if one available. - Real-Time Unreliable Communication Channel. Examples are RTP, RTCP channels as defined by IETF RFCs, high speed local bus communication, circuit switched communication etc. This channel is mostly used for bearer data communication, which requires some real time data transfer. Each of the protocol constructs defined in later sections will specify along with the definition, the type of lower layer channel required. 5.1 Basic Protocol Definition RPCP protocol supports three basic categories of protocol constructs - Service Execution constructs - Node/Protocol Management constructs - Transparent mode support Service execution related constructs support resource and capability advertising by RP to RPC and service execution logic construct by RPC to RP. The results or updates are sent in either direction. Initially each RP when it comes up, after local initialisation it advertises its resource and resource capability to RPC (if required). Once the resources and its capabilities are known to RPC, it can send service or control logic to RP for service execution. The events, results or errors of service execution are returned by RP to RPC. Any execution update or premature termination of execution is sent from RPC to RP. -------- --------- | | Resource/Capacity Update | | | RP |----------------------------------------> | RPC | | | | | -------- --------- Mahajan [Page 9] Internet Draft Resource Pool Control Protocol August 1999 -------- --------- | | Service Execution Logic | | | RP |<-----------------------------------------| RPC | | | | | -------- --------- -------- --------- | | Result/Event/Error Report | | | RP |----------------------------------------> | RPC | | | | | -------- --------- -------- --------- | | logic Update/Termination | | | RP |<-----------------------------------------| RPC | | | | | -------- --------- Figure 4 Service execution constructs Node or Protocol management constructs supports the configuration download, statistics alarm reporting, protocol status and node management constructs. The direction of flow is either direction, i.e. updates from RP to RPC and requests from RPC to RPs. -------- --------- | | Stats/Alarms Request | | | RP |<-----------------------------------------| RPC | | | | | -------- --------- -------- --------- | | Stats/Alarms Reports | | | RP |----------------------------------------> | RPC | | | | | -------- --------- -------- --------- | | Configuration Update | | | RP |<-----------------------------------------| RPC | | | | | -------- --------- Figure 5 Node, Protocol Management constructs Transparent mode constructs support two basic categories, protocol data transfer and real time data transfer. Protocol data transfer Mahajan [Page 10] INTERNET-DRAFT Resource Pool Control Protocol August 1999 constructs are used to support any network protocol transparently. Real-time data transfer is used to have real-time bearer or signalling data transfer. -------- --------- | | Protocol Data Transfer | | | RP |<-----------------------------------------| RPC | | | | | -------- --------- -------- --------- | | Protocol Data Transfer | | | RP |----------------------------------------> | RPC | | | | | -------- --------- -------- --------- | | Real-Time Data Transfer | | | RP |<-----------------------------------------| RPC | | | | | -------- --------- -------- --------- | | Real-Time Data Transfer | | | RP |----------------------------------------> | RPC | | | | | -------- --------- Figure 6 Transparent Mode data transfer 6.0 INITIAL CONFIGURATION AT RP AND RPC The initial configuration of RP and RPC is either done through some local Node Management Station or Remotely downloaded. 6.1 Configuration at RP: - RPC Identity/address - Redundant RPC Identity/address - Resource Database - Resource Capability Database - Service Logic Database(may be null) Mahajan [Page 11] INTERNET-DRAFT Resource Pool Control Protocol August 1999 6.2 Configuration at RPC: - RP's Identities/addresses - RP's Resource Configuration(may be null) - RP's Capability Database(may be null) - Service Logic Database 7.0 PROTOCOL CONSTRUCTS/ELEMENTS This section defines protocol constructs related to service execution with brief description along with the basic elements for each construct, direction of information flow and type of lower layer support. 1. Res_Cap_Update_req Direction: RP to RPC Channel Required: Non Real-Time unreliable channel. Elements: Update_id, Data_size, Duplicate_id Description: This protocol construct is used by RP, when it comes up or at any configuration change, to send a request to RPC for resource and capability advertising. The update_id is the resource and capability database id. It is used by RPC to check if no updates are required. Data size is used to give RPC an estimate of total volume of resource and capability database size. Duplicate_id is used, if RP is exact duplicate of some other RP in terms of resource and capability database (this is managed by local management entity). This construct is repeated, if no acknowledgement is received after the configurable protocol timer expires. 2. Res_Cap_Update_ack Direction: RPC to RP Channel Required: Non Real-Time unreliable channel. Elements: Update_mode, Delay Description: This protocol construct is used by RPC to respond to RP's request for update. The Update mode returned by RPC tells RP whether to send the update, delay sending update or there is no need for the update. RPC based on the duplicate_id, data_size and the update_id decides whether to take the update now, delay it or no need for update (as it has the most recent update). The delay parameter is used when RPC tells RP to reattempt the request and specify the delay amount, in seconds. Mahajan [Page 12] INTERNET-DRAFT Resource Pool Control Protocol August 1999 3. Res_Advertize Direction: RP to RPC Channel Required: Non Real-Time Reliable channel. Elements: Resource_id Structure Description: This protocol construct is used by RP to update RPC with the resources available at RP in case the RPC update is not the recent one. The Resource id structure describes each resource with its id. This construct is used to advertise only those resources, which needs to be controlled by RPC. 4. Cap_Advertize Direction: RP to RPC Channel Required: Non Real-Time Reliable channel. Elements: Capability_id Structure Description: This protocol construct is used by RP to update RPC with the resources capabilities available at RP in case the RPC update is not the recent one. The Capability id structure describes each resource capability along with the capability category. 5. End_Advertize Direction: RP to RPC Channel Required: Non Real-Time Reliable channel. Elements: Record count Description: This protocol construct is used by RP to tell RPC the end of advertising, and sends a record count parameter. Record count parameter is used by RPC to compare the records received with that sent by RP. 6. Execute_Logic Direction: RPC to RP Channel Required: Non Real-Time Unreliable channel. Elements: Update, logic_id, Update_frequency, Execution logic Description: This protocol construct is used by RPC to either update the RPs logic database or to request RP to execute the service logic. If update flag is set to update and execute, RP updates the database with execution logic and then executes it. However if it says either executes or Update, the service logic is executed and not updated in database or Updated and not executed. The execution logic defines the service logic including the resources and using simple constructs based on the resource capability and its category. Where category as defined before can be detection, execution, generation or combination of these. The service logic constructs include simple constructs like if, then, else or loops like while, for etc. Update Frequency is used by RPC to tell RP the frequency with which to update the status of execution. It can be in terms of time or execution Mahajan [Page 13] INTERNET-DRAFT Resource Pool Control Protocol August 1999 steps etc. Example use of update_frequency are to report statistics periodically, report alarms or update the status of execution logic to RPC after each execution step. 7. Logic_Update Direction: RPC to RP Channel Required: Non Real-Time Unreliable channel. Elements: logic_id, Update_type, Execution_logic, Update_frequency Description: This protocol construct is used by RPC to either update the RP's current execution or terminate it. The termination can be either graceful or abrupt, which will be defined by this parameter. If logic is updated, RP either starts re-executing the logic as specified by Execution_logic parameter or adds to the current executing logic. 8. Result_Report Direction: RP to RPC Channel Required: Non Real-Time reliable channel. Elements: Logic_id, Result Structure Description: This protocol construct is used by RP to update the status of execution to RPC, as specified in Execute_logic by Update_frequency. 9. Event_Report Direction: RP to RPC Channel Required: Non Real-Time reliable channel. Elements: logic_id, Event Structure Description: This protocol construct is used by RP to update the events, as reported by detection resources, to RPC. 10. Error_Report Direction: RP to RPC Channel Required: Non Real-Time reliable channel. Elements: logic_id, Error Structure Description: This protocol construct is used by RP to report any error during execution of service logic for logic_id . 8.0 CONCLUSION RPCP can provide a uniform interface protocol between different network entities(signalling controllers, call agents, network management centres etc.) if each of such entity defines the resources and capabilities and identifies the resource controllers. Differnet vendors can produce Resource pools and Pool Controllers if the interface agreed upon is standard, flexible and open. Mahajan [Page 14] INTERNET-DRAFT Resource Pool Control Protocol August 1999 9.0 ACKNOWLEDGEMENTS The author would like to acknowledge all of those who contributed for helpful review, suggestions and comments. 10.0 REFERENCES Media Gateway Control Protocol(MGCP), IETF Internet Draft Bay Networks SS7-Internet Access Signalling Protocol, IETF Internet Draft ITU-T Q Series Recommendation Q.121x, Intelligent Networks Interface Recommendation for Intelligent Network CS-1 ITU-T Q Series Recommendation Q.122x, Intelligent Networks Interface Recommendation for Intelligent Network CS-2 ITU-T Q Series Recommendation Q.76x, SS7 ISDN User Part of Signalling System No. 7 ITU-T H Series Recommendation H.323, Visual Telephone Systems and Equipment for Local Area Networks which provides a Non-Guaranteed Quality of Service ITU-T H Series Recommendation H.225, Call Signalling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems ITU-T H Series Recommendation H.245, Line Transmission of Non-Telephone Signals Schulzrinne H., Casner S., Frederick R. and Jacobson, RTP: A Transport Protocol for Real-Time Applications”, RFC 1889, January 1996 Schulzrinne H., “RTP Profile for Audio and Video Conferences with Minimal Control, RFC 1890, January 1996 A.1 ANNEXURE-I Example of Protocol Use This section gives two examples, each using RPCP to achieve the service execution. These two examples are linked and the RPC of first becomes RP for the second example. Mahajan [Page 15] INTERNET-DRAFT Resource Pool Control Protocol August 1999 A.1.1 Example1 The section on need for RPCP describes the new architecture for telecom components with intelligence being moved away from switching fabric. The first example is based on such architecture. In this example RP is the switching fabric and RPC is the signalling and call agent. -------- ------------ | | Real-Time Data Transfer | | | RP(SW |-------------------------------------> | RPC(Sig & | | Fabric)| | Call Agnt) | -------- ------------ The configuration of resource and its capability may be known to RPC but if not, these are exchanged through protocol message between two. Following resources and capabilities are assumed Resources: Bearer Circuits/Signalling Circuits/Switching Hardware or Firmware/Echo Cancellation Firmware Capabilities: Bearer Circuits can be switched/Echo Cancellation can be applied to any Bearer circuit/Signalling Data can be extracted from Signalling Circuits and passed to RPC. -------- ------------ | | Service Logic Execution | | | RP(SW |<------------------------------------| RPC(Sig & | | Fabric)| | Call Agnt) | -------- ------------ RPC sending a logic execution message to RP for signalling circuits to be switched and data to be extracted. -------- ------------ | | Protocol Data | | | RP(SW |--------------------------------------> | RPC(Sig & | | Fabric)| | Call Agnt) | -------- ------------ All SS7 signalling traffic will be send to RPC by RP using the real-time communication channel(it can be any connection type between RP and RPC, a local high-speed bus, high-speed ethernet etc.). RPC executing the SS7 Protocol, if required to use bearer Mahajan [Page 16] INTERNET-DRAFT Resource Pool Control Protocol August 1999 circuits or apply echo cancellation on these circuits, will issue such command by another service execute logic to RP. The switching of bearer circuits is controlled by RPC using execute service logic command to RP. -------- Switch Circuit execute ------------ | | Service Logic | | | RP(SW |<-------------------------------------| RPC(Sig & | | Fabric)| | Call Agnt) | -------- ------------ -------- ------------ | | Apply Echo Cancellation to Circuit | | | RP(SW |<--------------------------------------| RPC(Sig & | | Fabric)| | Call Agnt) | -------- ------------ For any error, like hardware failure for signalling channels, it will be reported to RPC using error report. -------- ------------ | | Error Report | | | RP(SW |------------------------------------> | RPC(Sig & | | Fabric)| | Call Agnt) | -------- ------------ A.1.2 Example2 In this example we will consider the RPC described above as the RP for a network management station, which is acting as RPC. -------- ------------ | | Res_Cap_Update | | | RP(SS7 |------------------------------------> | RPC(NW Mgnt| | Switch)| | Station) | -------- ------------ Resources: SS7 Signalling. Capabilities: Enable/Disable SS7 Signalling, Reporting Signalling Statistics, Reporting Alarms, Generating Call Records etc. Mahajan [Page 17] INTERNET-DRAFT Resource Pool Control Protocol August 1999 RPC may initially download the configuration data to RP, if required. -------- ------------ | | Configuration Data | | | RP(SS7 |<-------------------------------------| RPC(NW Mgnt| | Switch)| | Station) | -------- ------------ RPC will send an execute logic command to enable the SS7 signalling on RP and send the logic to update execution results by setting the frequency of update for statistics, alarms and call records. -------- Service Execution Logic ------------ | | with Update Frequency | | | RP(SS7 |<-------------------------------------| RPC(NW Mgnt| | Switch)| | Station) | -------- ------------ The RP will send updates to RPC for statistics with the frequency specified and send any alarms as events to RPC, generate Call records and update RPC at the frequency specified. -------- ------------ | | Event Reoprting for Alarms | | | RP(SS7 |------------------------------------> | RPC(NW Mgnt| | Switch)| | Station) | -------- ------------ -------- ------------ | | Stats Reporting at Frequency Specified | | | RP(SS7 |--------------------------------------> | RPC(NW Mgnt| | Switch)| | Station) | -------- ------------ In this example SS7 node (RP) in turn be using RPCP to control the switching fabric to achieve the SS7 signalling capability. This shows the hierarchical application of RPCP protocol. Mahajan [Page 18] INTERNET-DRAFT Resource Pool Control Protocol August 1999 A.2 ANNEXURE-II A.2.1 Next Step Next step is to ? Complete RPCP protocol definition ? Performance study of protocol for various applications ? Real example of use of RPCP in network ? Define application specific extensions to RPCP ? Comparison of application specific extensions of RPCP with existing similar protocols A.3 CONTACT INFORMATION Sunil Mahajan Technical Leader smahajan@hss.hns.com Protocol Development Lab Hughes Software Systems Plot# 31, Sector-18 Electronic City, Gurgaon Harayana - 122015 INDIA Tel# +91-124-346666 Fax# +91-124-342415 Mahajan [Page 19]