protocol_plugins.packetcable/src/main/java/org/pcmm/rcd/IPCMMPolicyServer.java

   1 /**
   2  @header@
   3  */
   4
   5 package org.pcmm.rcd;
   6
   7 import java.net.InetAddress;
   8
   9 import org.pcmm.objects.MMVersionInfo;
  10 import org.pcmm.state.IStateful;
  11
  12 /**
  13  * <i>PKT-SP-MM-I05-091029 PacketCableTM Specification</i>
  14  * <p>
  15  * As discussed in RFC 2753 [11], the policy management framework underlying
  16  * PacketCable Multimedia is based on the work of the IETF's Resource Allocation
  17  * Protocol (RAP) working group. Since the Policy Server is situated between the
  18  * Application Manager and the CMTS, it simultaneously plays a dual role as a
  19  * "proxy" for AM-initiated session requests and as a "sentry" for defining and
  20  * enforcing Resource Control Domain policy. As described in [11] and in keeping
  21  * with the PacketCable 1.x DQoS model, the Policy Server serves as Policy
  22  * Decision Point (PDP) in relation to the CMTS in that the Policy Server
  23  * implements MSO-defined authorization and resource-management procedures.
  24  * Conversely, the Policy Server assumes the role of Policy Enforcement Point
  25  * (PEP) in relation to the Application Manager as it proxies Gate Control
  26  * messages to and from the CMTS element. To revisit the interaction scenario,
  27  * the Application Manager issues policy requests to the Policy Server. The
  28  * Policy Server acting as a "sentry" for these requests, and applies a set of
  29  * policy rules that have been pre-provisioned by the MSO. Upon passing the
  30  * checks, the Policy Server then acts as a "proxy" with respect to the
  31  * Application Manager and the CMTS, forwarding the policy request and returning
  32  * any associated response. Each policy request transaction must be processed
  33  * individually. Policy decisions may be based on a number of factors, such as:
  34  * <ul>
  35  * <li>Parameters associated with the request and the status of available
  36  * resources</li>
  37  * <li>Identity of the particular client and associated profile information</li>
  38  * <li>Application parameters</li>
  39  * <li>Security considerations</li>
  40  * <li>Time-of-day</li>
  41  * </ul>
  42  * The primary functions of the Policy Server include:
  43  * <ul>
  44  * <li>A policy decision request mechanism, invoked by Application Managers</li>
  45  * <li>A policy decision request 'policing' mechanism, enforcing installed
  46  * Policy Rules</li>
  47  * <li>A policy decision delivery mechanism, used to install policy decisions on
  48  * the CMTS</li>
  49  * <li>A mechanism to allow for the proxying of QoS management messages to the
  50  * CMTS on behalf of the Application Manager</li>
  51  * <li>An event recording interface to a Record Keeping Server that is used to
  52  * log policy requests, which may in turn be correlated with network resource
  53  * usage records</li>·
  54  * </ul>
  55  * Since the Policy Server functions as a proxy between the AM and CMTS elements
  56  * (with complementary client and server interfaces) some MSOs may elect to
  57  * deploy multiple layers of Policy Servers and to delegate certain policy
  58  * decisions among these servers in order to satisfy requirements associated
  59  * with scalability and fault-tolerance.
  60  * </p>
  61  * <p>
  62  * <i>Stateful & Stateless Policy Servers</i> There are two basic classes of
  63  * Policy Servers – Stateful and Stateless. A Stateless Policy Server is a
  64  * slight misnomer since it does maintain enough state to map Application
  65  * Manager requests to the proper CMTS and maintain COPS session state, while a
  66  * pure Stateless Policy Server maintains no state on any of the media sessions.
  67  * Stateful Policy Servers come in several varieties – some participate in
  68  * admission control and thus monitor the QoS attributes of active media
  69  * sessions, some leave QoS and admission control to the CMTS but monitor
  70  * time-based or volume-based service requests from the Application Manager, and
  71  * some Policy Servers are somewhere between these extremes. The reason there is
  72  * a variety of Policy Server types is that there is a variety of environments
  73  * that operators are trying to support. For example, some operators may wish to
  74  * support PacketCable Multimedia over the same CMTSs that they use for
  75  * PacketCable telephony, and they may want a single CMS/Policy Server that has
  76  * a more global view of the network resources being used. On the other hand,
  77  * some operators may wish to run a PacketCable Multimedia- only environment, or
  78  * they may utilize simpler CMTS-driven mechanisms for partitioning PacketCable
  79  * Multimedia and telephony resources. These simpler configurations have more
  80  * modest requirements on the amount of state that a Policy Server maintains.
  81  * Policy Server state requirements can also be driven by the level of trust
  82  * between the Policy Server and Application Manager; a Stateful Policy Server
  83  * can more readily police Application Manager session control behavior than can
  84  * a Stateless Policy Server. So a Stateful Policy Server may be more
  85  * appropriate for operators supporting third party Application Managers. Other
  86  * operators may rely on economics to enforce their trust relationships with
  87  * Application Managers, or they may control the Application Managers
  88  * themselves. In such cases a Stateless Policy Server may be more appropriate.
  89  * Since it is impossible to categorize all the various components of media
  90  * session and network QoS state that a Policy Server is maintaining, the
  91  * protocol is designed to be independent of this complexity. A Stateful Policy
  92  * Server gleans PacketCable Multimedia media session information from the
  93  * Application Manager requests it proxies; any other information it requires is
  94  * gathered via mechanisms that are outside the scope of this specification. The
  95  * CMTS and the Application Manager make no distinction as to the type of Policy
  96  * Server to which they are connected, and the protocol is designed in such a
  97  * manner that the type of Policy Server is transparent to the end point. The
  98  * type of Policy Server is only of importance to the operator. Since some types
  99  * of Policy Servers attempt to assist with admission control and may have a
 100  * larger view of the network and its resources, additional state
 101  * synchronization issues may arise in design in a network which contains more
 102  * than one of these types of Policy Servers. It is the responsibility of the
 103  * operator to ensure that the efforts of these Policy Servers are not
 104  * undermined by a network that includes other autonomous Policy Servers.
 105  * </p>
 106  * <p>
 107  * <i>Modification of Requests and Responses by Policy Servers</i> Although
 108  * nominally a part of the Resource Control Domain, the Policy Server can be an
 109  * intermediary between the Service and the Resource Control Domains, in
 110  * addition to its normal role of implementing MSO-defined authorization and
 111  * resource management procedures. In either of these capacities it may modify
 112  * the incoming request before forwarding it to the CMTS. In acting as an
 113  * intermediary between the SCD and RCD, the Policy Server may translate fields
 114  * from formats or scales used in the SCD into formats or scales used in the
 115  * RCD. For example, the Policy Server may modify the "priority" of a request
 116  * coming from an Application Manager (especially important to do for an AM
 117  * outside of the MSO network) so that this priority field uses a consistent
 118  * scale throughout the operator's RCD. In its capacity as an intermediary, the
 119  * Policy Server may use bidirectional translation – in other words, it should
 120  * translate requests from the AM to the CMTS and "untranslate" the responses
 121  * from the CMTS to the AM. This capability can be supported by stateful policy
 122  * servers by remembering the original request, and it can be supported by
 123  * stateless Policy Servers if the translation function is invertible.
 124  * Modification of certain objects, specifically the Classifier and Traffic
 125  * Profile objects, may cause operational problems in the originating AM. As
 126  * such, these objects MUST NOT be modified by the policy server. Aside from
 127  * these exceptions, all other objects may be policed and modified at the PS's
 128  * discretion based on provisioned policy rules.
 129  * </p>
 130  *
 131  */
 132 public interface IPCMMPolicyServer extends IPCMMServer, IStateful {
 133
 134         /**
 135          * establishes COPS connection with the CMTS
 136          *
 137          * @param host
 138          *            : remote host name or ip address
 139          * @return connected socket.
 140          */
 141         IPSCMTSClient requestCMTSConnection(String host);
 142
 143         /**
 144          * establishes COPS connection with the CMTS
 145          *
 146          * @param host
 147          *            : remote ip address‚
 148          * @return connected socket.
 149          */
 150         IPSCMTSClient requestCMTSConnection(InetAddress host);
 151
 152         /**
 153          * <p>
 154          * In the PacketCable model, the CMTS (PEP) is the one that listens on the
 155          * assigned port 3918, and it is the Policy Server that MUST initiate the
 156          * TCP connection to the CMTS, thus we implement the IPCMMClient interface.
 157          * </p>
 158          */
 159         public static interface IPSCMTSClient extends IPCMMClient {
 160
 161                 /**
 162                  *
 163                  * @return Classifier Id.
 164                  */
 165                 short getClassifierId();
 166
 167                 /**
 168                  *
 169                  * @return the transaction Id.
 170                  */
 171                 short getTransactionId();
 172
 173                 /**
 174                  * Gate id transmitted by the CMTS to the PS.
 175                  *
 176                  * @return the Gate Id.
 177                  */
 178                 int getGateId();
 179
 180                 /**
 181                  * initiates a Gate-Set with the CMTS
 182                  *
 183                  * @return
 184                  */
 185                 boolean gateSet();
 186
 187                 /**
 188                  * initiates a Gate-Info with the CMTS
 189                  *
 190                  * @return
 191                  */
 192                 boolean gateInfo();
 193
 194                 /**
 195                  * initiates a Gate-Delete with the CMTS
 196                  *
 197                  * @return
 198                  */
 199                 boolean gateDelete();
 200
 201                 /**
 202                  * sends synch request
 203                  *
 204                  * @return
 205                  */
 206                 boolean gateSynchronize();
 207
 208                 /**
 209                  * Sets the value of the multi-media version info.
 210                  *
 211                  * @param MM
 212                  *            version info
 213                  */
 214                 void setVersionInfo(MMVersionInfo vInfo);
 215
 216                 /**
 217                  *
 218                  * @return MM version info
 219                  */
 220                 MMVersionInfo getVersionInfo();
 221         }
 222 }