Internet Draft L-N. Hamer Expires April 2002 K. Chan File: draft-hamer-rap-cops-umts-go-00.txt H. Syed Nortel Networks H. Shieh AT&T Wireless R. Zwart AT&T November 12, 2001 COPS-PR for outsourcing in UMTS: UMTS Go PIB Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 draft 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''. To view the current status of any Internet-Draft, please check the ''1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract This document describes usage directives for supporting COPS outsourcing policy services in the UMTS environment. Through the use of the UMTS Go PIB, defined in this document, COPS-PR is used for outsourcing over the Go interface. Disclaimer This document is to be considered work in progress. Although, the 3GPP CN3 WG has ratified the use of COPS-PR over the Go interface, the level of detail in this document as not been formally approved yet. Its purpose is to inform the IETF of the direction 3GPP has taken for the UMTS Go interface. A revised version of this document will be published once it is approved by 3GPP. [Page 1] COPS-PR for outsourcing in UMTS November 2001 1. Glossary PRC Provisioning Class. A type of policy data. PRI Provisioning Instance. An instance of a PRC. PIB Policy Information Base. The database of policy information. PDP Policy Decision Point. See [RAP-FRAMEWORK]. PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. PRID Provisioning Instance Identifier. Uniquely identifies an instance of a PRC. PCF Policy Control Function UE User Equipment GGSN Gateway GPRS Support Node SGSN Serving GPRS Support Node PDP context Packet Data Protocol context 2. Introduction COPS has been developed as a protocol for use between a policy server/PDP and a network device/PEP, as described in [COPS]. In addition, COPS for Provisioning extensions has been developed as described in [COPS-PR] with [SPPI] describing a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined provisioning classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). One way to provision policy is by means of the COPS protocol [COPS] with the extensions for provisioning [COPS-PR]. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security. The technology used in [COPS-PR], [SPPI], [FRWRK-PIB], and [DS-PIB] can be applied to Policy Control of UMTS network devices. This document describes the usage of [COPS-PR] technology applied to the Go interface as indicated in [UMTS-Go][UMTS-QoS]. 2.1 Rationale for using COPS-PR for outsourcing in UMTS Two options were studied for policy control over the Go interface: 1- Creating object extension for UMTS, in the same way COPS-RSVP was defined. 2- Using COPS-PR for outsourcing with a UMTS PIB. Option 2 was chosen for many reasons. Here are the highlights: -Provisioning functionality has generally been thought of as static, but within the context of COPS-PR, the degree of dynamic/static is up to the user of the technology. The events handled by COPS-PR can Hamer, et al. [Page 2] COPS-PR for outsourcing in UMTS November 2001 be very dynamic to very static. The degree of dynamic-ness is in itself a policy, and can be controlled with COPS-PR with flexibility in both event detection/reporting frequency and granularity. -Separation of Protocol and Policy Control Information. COPS-PR takes the approach of defining a stable, reusable, more widely applicable protocol. With the applicability addressed by the Policy Control Information carried by the COPS-PR protocol. -By designing a PIB (Policy Information Base) by and for 3GPP, no change is needed to the COPS-PR protocol itself. This is a good way of building on existing technology without having to revisit the protocol every time new information needs to be carried by the protocol. This also provides a faster way to deployment without going through another cycle of standardization for the protocol. This provides more flexibility and a standard way for the implementations to add value by extending the standardized Policy Control Information. -The notion of Out-Sourcing and Provisioning really depends on the Events being handled by the network device and how much of the event handling is done at the network device. With COPS-PR, the definition of the Events is defined by the PIB (Policy Information Base) and can be changed even within the same COPS session state (the event handling is itself policy controlled). This allows the handling of different signaling protocols very easily. -Capability of both the network device and policy server is negotiated between the network device and policy server. This allows dynamic adjustments between the network device and policy server, and allows flexibility in implementation and deployment of different standard features as needed. -Levels of outsourcing details can be as coarse (aggregated) or fine (per micro-flow) as necessary and can be adjusted dynamically when needed. -Re-using parts of well-defined PIBs ensures a prompt definition of the Go interface and favors a more general solution that can be scaled to multiple environments. Hamer, et al. [Page 3] COPS-PR for outsourcing in UMTS November 2001 3. Definition of terms Figure 1 introduces the policy control model for UMTS. This is only an overview and does not cover all the details. For more details, please consult [UMTS-QoS][UMTS-IM][UMTS-ARCH]. +---+ | | +-------------------+--------+ | I | | P-CSCF | PCF | | n | | | (PDP) | | t | | | | <------->| e | | | | | r | | | | | - | +-------------------+---|----+ | c | | | o | | | n | | | n | -|- Go inter- | e | | face | c | | | t | | | i | +------------+ +----|--------+ | n | +----------+ | | | | | | g | | UE | | SGSN | |GGSN| | | | | | | | |+---|------+ | | N | |+--------+| | | ||PEP | | | e | ||SIP User|| |+----------+| |+----------+ |<---->| t | ||Agent || || UMTS BS || |+----------+ | | w | |+--------+| || Manager || ||UMTS BS M | | | o | ||UMTS BS ||<---->|+----------+|<-->|+----------+ | | r | ||Manager || +------------+ +-------------+ | k | |+--------+| | | +----------+ +---+ Figure 1: Policy control model for UMTS UE - User Equipment: The UE is the UMTS term for a device used by a subscriber to access network services. The UE includes a client for requesting network services (e.g. through SIP) and a client for requesting network resources (e.g. through PDP context establishment). In this document, the term 'terminal' is used to mean the same as UE. SGSN - Serving GPRS Support Node: The SGSN performs the necessary functions in order to handle the packet transmission to and from the UE. PEP - Policy Enforcement Point: The PEP is a logical entity that enforces policy decisions made by the PCF. GGSN - Gateway GPRS Support Node: The GGSN is a network element connecting the UE to the external network. The GGSN contains a PEP Hamer, et al. [Page 4] COPS-PR for outsourcing in UMTS November 2001 to enforce policies. It also contains a UMTS BS Manager for handling resource reservation requests from the UE (e.g. through PDP context signaling). PCF - Policy Control Function (aka, PDP): The PCF is a logical policy decision element which uses standard IP mechanisms to implement policy in the IP media layer. The PCF makes decisions in regard to network based IP policy using policy rules, and communicates these decisions to the PEP in the GGSN. The term PCF was chosen over PDP (Policy Decision point) in this document to avoid confusion with PDP context messages. UMTS BS Manager: The UMTS Bearer Service Manager handles resource reservation requests from the UE. P-CSCF - Proxy Call Session Control Function: The P-CSCF is a network element providing session management services (e.g. telephony call control). Go interface - Interface between the GGSN (PEP) and PCF (PDP). Hamer, et al. [Page 5] COPS-PR for outsourcing in UMTS November 2001 4. General UMTS and Go Interface Concepts 4.1. UMTS IP Multimedia Subsystem The IP Multimedia Subsystem (IMS) utilizes the UMTS Packet Switched (PS) domain to transport multimedia signaling and media traffic. The PS domain provides the IP network connection to the UE. The IMS comprises the core network elements for provision of multimedia services. This includes the collection of signaling and media related network elements as defined in [UMTS-Arch]. IP multimedia services are based on an IETF defined session control capability. In order to achieve access independence and to maintain a smooth interoperation with wireline terminals across the Internet, the IMS is intended to be conformant to IETF 'Internet standards'. For IMS session control, the SIP protocol [IETF-SIP] has been selected. 4.2. Session authorization framework The UMTS architecture has to satisfy requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. Therefore, policies may be enforced during session set up, e.g. to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting user. Similarly, when a terminal requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the requested resources lie within the bounds of the allowed resource profile established and the available 'budget' for the requesting terminal. In order to prevent fraud and to ensure accurate billing, UMTS defines a mechanism that allows for verification that the resources being used to provide a requested QoS are in-line with the media streams requested (and authorized) for the session. This linkage is provided through the use of an "authorization token". We briefly describe this mechanism below. The details of the procedures can be found in [UMTS-IM][UMTS-QoS]. Session authorization mechanism 1. The UE issues a session set-up request (i.e. SIP INVITE) to the P-CSCF indicating, among other things, the media streams to be used in the session. As part of this step, the terminal may authenticate itself to the P-CSCF. 2. The P-CSCF forwards the SIP INVITE to other CSCF functions in the network. These functions are not further described here. However, the result of this will be that the P-CSCF receives a provisional SIP response from the other endpoint of the call. This will typically be a SIP 183 response message, also containing the relevant media information pertaining to the other half of the media Hamer, et al. [Page 6] COPS-PR for outsourcing in UMTS November 2001 to be used. Based on this information, the P-CSCF sends to the PCF the necessary information to authorize the request. 3. Based on the information received, containing information elements like bandwidth required, IP end points addresses and ports, the PCF authorizes the session and sends a decision to the P-CSCF. Included in this response is an "authorization token" that can subsequently be used by the PCF to identify the session and the media it has authorized. 4. The P-CSCF sends a response to the UE (e.g. by forwarding the SIP 183) indicating that session set-up is progressing. Included in this response is a description of the negotiated media along with the token from the PCF. 5. The UE issues a request (e.g. PDP context activation) to reserve the resources necessary to provide the required QoS for the media stream. Included in this request is the token from the PCF provided via the P-CSCF and flow identifier(s) that identifies the flow(s) on the PDP Context. 6. The GGSN receives the reservation request and sends a policy decision request (e.g. COPS REQ) to the PCF in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token and the flow identifier(s) provided by the UE. The PCF uses this token and flow identifier(s) to correlate the request for resources with the media authorization previously provided to the P-CSCF. 7. The PCF sends a decision (e.g. COPS DEC) to the GGSN. 8. The GGSN sends a response to the UE (e.g. PDP context activation response) indicating that resource reservation is complete. 4.3. Go Interface The mechanism described in section 4.2, will allow for service based policy control over the interface between the GGSN and PCF. This interface is known in UMTS as the Go interface. At initialization, the PEP will inform the PCF of its capabilities. In return, the PCF will respond by provisioning the PEP what types of events require the trigger of policy outsourcing. When such an event occurs, the PEP will trigger a COPS REQ and send it to the PCF. The main difference with other admission control frameworks [RAP-FRAMEWORK] is that the session information is already stored in the PCF prior to receiving the COPS request. Therefore, the COPS REQ does not need to encapsulate all of the information contained in the bearer request-signaling message. The COPS REQ must contain a token and flow Ids referencing the Hamer, et al. [Page 7] COPS-PR for outsourcing in UMTS November 2001 previously installed session state and may also contain the parameters of the QoS request. On receipt of the COPS Request, the PCF uses the token, containing a unique session identifier, to retrieve the session information and take an informed decision. The PCF can then push down a decision using standard COPS-PR schematics. Over the Go interface, information can be exchanged to support the following functions in the GGSN: - Control of Diffserv inter-working, - Control of 'gating' function in GGSN, - UMTS media authorization, - QoS charging related function. The control of Diffserv interworking can be achieved using COPS-PR and importing the necessary data structures from the diffserv PIB. The control of gating, UMTS media authorization and QoS charging can be achieved using standards COPS-PR and by importing the necessary data structures from the framework PIB with minor extensions to be included in the UMTS Go PIB, detailed in section 7 & 8. 5. COPS-PR Usage for UMTS Go Interface 5.1 General Description The Go Interface uses COPS-PR [COPS-PR] schematics and the UMTS Go PIB. COPS-PR was initially designed for provisioning purposes only but this document proposes a usage of COPS-PR for outsourcing purposes. For COPS-PR to handle the Outsourcing Model it is required to add a new UMTS Go PIB with objects to: -Describe the Triggering Event Handling. This needs to include objects for the Functionality Capability description and provisioning. -Describe the Outsourcing Event. -Describe the Decision for the Outsourced Event. -Describe the Termination of the Outsourced Event. -Describe the resource used for the Outsourced Event. Hamer, et al. [Page 8] COPS-PR for outsourcing in UMTS November 2001 5.2 UMTS-specific Information in COPS-PR 5.2.1 Common Header, Client Type Client-type is UMTS Go(Client type number to be assigned through IANA) 5.2.2 Context Object C-Num = 2, C-Type = 1 0 1 2 3 +--------------+--------------+--------------+--------------+ | R-Type | M-Type | +--------------+--------------+--------------+--------------+ R-Type (Request Type Flag) 0x02 = Resource-Allocation request 0x08 = Configuration request M-Type (Message Type) 0x01 = Create PDP Context (with the token) 0x02 = update PDP Context (with the token) 5.2.3 Client Specific Information (ClientSI) for outsourcing Operation The Token and flow identifier(s) received in the incoming message at the UMTS PEP is encapsulated inside the Client Specific Information object of the COPS request message sent from the PEP to the PCF. The parameters describing the requested QoS may also be contained inside the Client SI object. The following is detailed in section 8, under 'TBD'. 5.3 General Operations 5.3.1. Reporting of Device Capabilities and Device Limitations This functionality is already supported by COPS-PR. This sectionÆs purpose is to detail its usage in the UMTS environment. The configuration request message serves as a request from the PEP to the PCF for provisioning policy data that the PCF may have for the PEP. The configuration request message should include provisioning client information to provide the PCF with client- specific configuration or capability information about the PEP. Hamer, et al. [Page 9] COPS-PR for outsourcing in UMTS November 2001 In a UMTS environment, the information provided by the PEP should include client capabilities and default policy configuration (e.g., default role combinations) information as well as incarnation data on existing policy. The client capabilities can be described by what type of bearer signaling is supported (e.g. PDP context signaling). This information from the client assists the server in deciding what types of policy the PEP can install and enforce. The PCF responds to the configuration request with an initial UMTS policy Provisioning DEC message, described in 5.3.2. 5.3.2. Initial UMTS Policy Provisioning This functionality is already supported by COPS-PR. This section purpose is to detail its usage in the UMTS environment. The DEC message is sent from the PCF to the PEP in response to the REQ message received from the PEP. The Client Handle MUST be the same Handle that was received in the corresponding REQ message. The DEC message is sent as an immediate response to a configuration request with the solicited message flag set in the COPS message header. In a UMTS environment, the PCF will provision the PEPÆs bearer signaling triggering capability. Basically, the PCF will inform the PEP what types of events (e.g. receipt of a PDP context message) require the trigger of policy outsourcing. 5.3.3 COPS-PR Outsourcing Operation The following sections describe all of the UMTS Policy Events. A Policy event triggers the appropriate COPS messages to be sent over the Go interface. 5.3.3.1. UMTS Service Request UMTS Service Requests are triggered by the PEP receiving resource allocation bearer plane signaling messages. The following messages trigger a UMTS Service Request: Create PDP Context Request with a token Update PDP Context Request with a token This service request is used when the PEP is about to commit local resources to a particular PDP context. The PEP includes in the UMTS service Request the token and flow identifiers it received from the PDP context message. The PCF can then use this token and flow identifiers to correlate this media request to a previously installed state in its database relating to this service request. Hamer, et al. [Page 10] COPS-PR for outsourcing in UMTS November 2001 5.3.3.2 Outsourced UMTS Decision A Subsequent DEC message is sent from the PCF to the PEP in response to the REQ message received from the PEP. The Client Handle MUST be the same Handle that was received in the corresponding REQ message. The DEC message is sent as an immediate response to an outsourcing request with the solicited message flag set in the COPS message header. Subsequent DEC messages may also be sent at any time after the original DEC message to supply the PEP with additional/updated policy information without the solicited message flag set in the COPS message header (as they are unsolicited decisions). This can be trigerred by the P-CSCF notification of a SIP event (e.g. Commit, Revoke). 5.3.3.3 UMTS Service Usage Reporting The UMTS Service Usage Reporting is identical to the COPS-PR report message. The RPT message is sent from the PEP to the PCF to report accounting information associated with the policy control, or to notify the PCF of changes in the PEP (Report-Type = 'Accounting'). RPT is also used as a mechanism to inform the PCF about the action taken at the PEP in response to a DEC message. The RPT message may contain PEP information such as accounting parameters or errors/warnings related to a decision. The data format for this information is defined in the context of the policy information base (see section 8). 5.3.3.4 UMTS Service Usage Termination UMTS Service Terminations are triggered by the PEP receiving teardown bearer plane signaling messages. The following messages trigger a UMTS Service Usage Termination: Delete PDP Context Request with a token This service usage termination is used when the PEP releases local resources to a particular PDP context. This can be the result of the receipt of a delete PDP context request or any other event forcing the PEP to release committed resources (e.g. network failure). If the entire resources associated with a particular installed state are to be released: the Termination message is the same format as a DRQ. This information will then be used by the PCF to initiate the appropriate housekeeping actions (e.g. the PCF terminates the entire session associated with that specific client handle). Hamer, et al. [Page 11] COPS-PR for outsourcing in UMTS November 2001 If only a subset of resources associated with a particular installed state are to be released: the Termination message is the same format as a REQ. The REQ will contain the token and flow Ids to be released. The PCF terminates only the specified flows and keeps alive all other flows associated with that particular client handle. 6. Relationship between UMTSÆs COPS-PR Usage and other COPS-PR Usages COPS-PR for the UMTS Go interface is used for outsourcing policy over the Go interface. This usage of COPS-PR could be coupled with other COPS-PR usages. This flexibility is allowed since all COPS-PR usages use the same protocol with PRCs defined in their respective PIB. For example, [FEEDBACK] defines the policy usage feedback framework PIB that specifies the policy classes common for COPS feedback reports. This feedback PIB could be used in conjunction with the UMTS Go PIB to provide a more complete solution. There are no restrictions on the usage of the UMTS Go PIB with other defined PIBs. This decision is left to the user/operator of the network. 6.1 Re-use of PRCs from other PIBs It is intended that the UMTS Go PIB will reuse as much of existing standard technology as possible by importing some PRCs from existing PIBS. Following is a list of the PRCs that would be useful for the Go interface: From the Framework PIB [Frwrk-PIB]: The Base Filter class PRC. The IP Filter PRC. These two PRCs will enable the PCF to push down filters to the PEP. A filter defines fields that a packet has to match to be considered as part of a particular data flow. Wildcards may be specified for those fields that are not relevant. From the DiffServ PIB [DS-PIB]: Classifier Element PRCs :The classifier and classifier element tables determine how traffic is sorted out. They identify separable classes of traffic, by reference to appropriate filters, which may select anything from an individual micro-flow to aggregates identified by DSCP. Meter PRCs : The generic meter PRC is used as a base for all more specific forms of meter. This enables the use of any sort of Hamer, et al. [Page 12] COPS-PR for outsourcing in UMTS November 2001 specific meter table that one might wish to design, standard or proprietary. Token bucket parameter PRC: A specific type of meter. This defines the authorized envelope for a particular flow. DSCP Mark Action PRC: This Action is applied to traffic in order to mark it with a Diffserv Codepoint (DSCP) value. Algorithmic Dropper PRC: Action to take on out-of-profile packets from a flow not respecting the bounds of its authorized envelope. 7. Summary of the UMTS PIB The UMTS PIB comprises of the following groups: 1. UMTS Capability and Limitation Group The Capability section of this PIB contains PRCs describing the functionalities of the PEP. This is accomplished by indicating which PRCs are used by the PEP and the limitations of the attributes supported in each PRC. The organization of the capability section follows the functional sections of this PIB, it contains PRCs for: - Event Handling Capability, this indicates the Events the PEP can handle. - Event Handler Capability, this indicates the detail capability of each of the Event Handlers supported. - Event PRCs supported. This indicates the PRCs used to describe the events themselves, including the decisions that the PEP will accept from the PCF. The Capability Group contains the following kinds of PRCs: Device Capability Table Description of Capability PRCs - Defines the capabilities of the PEP in terms of PRCs. This group consists of PRCs to indicate to the PDP the types of UMTS functionality supported on the PEP in terms of the PRCs that the PCF can install in order to configure these interfaces to affect the desired policy. Device Limitations Table Description of Limitation PRCs - Defines the limitations of the PEP. For example, set the maximum number of flows that one PDP context can support. Hamer, et al. [Page 13] COPS-PR for outsourcing in UMTS November 2001 Device Error Handling Capability Table Description of Error Handling PRCs - Defines the error handling capabilities of the PEP to the PCF. 2. Event Handler Provisioning Group This group contains the PRCs that are used for provisioning the Event Handlers. There should be a set of PRCs for each type of event signaling protocol or method. For example this document contains the PRCs for provisioning the PDP Context handler. Types of event may include signaling protocols, or other events that will trigger an outsourcing request from the PEP to the PCF. 3. UMTS Event Group This group contains the PRCs that describe the outsourcing policy events. There should be a set of PRCs for each type of event being handled. Currently this PIB contains the following PRCs for describing PDP Context events: Service request Table Description of Service request PRC - Defines the service request from the PEP to the PCF. Outsourced policy Table Description of Outsourced policy PRCs - Defines the policy decisions supplied by the PCF to the PEP. Service Usage Reporting Table Description of the service usage reporting PRCs - Defines the reports sent from the PEP to the PCF. Service usage termination Table Description of the service usage termination PRCs - Defines the termination indications from the PEP to the PCF. 8. The UMTS PIB module Note: This section is incomplete. Currently, only a few PRCs are defined for informational purposes. As the 3GPP CN3 WG defines and agrees upon what new PRCs are needed, this section will be updated. UMTS-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, Integer32, MODULE-IDENTITY, MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP Hamer, et al. [Page 14] COPS-PR for outsourcing in UMTS November 2001 FROM COPS-PR-SPPI InstanceId, Prid FROM COPS-PR-SPPI-TC RoleCombination, PrcIdentifier FROM FRAMEWORK-ROLE-PIB InetAddress, InetAddressType FROM INET-ADDRESS-MIB TruthValue, PhysAddress FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB; uMTSPib MODULE-IDENTITY SUBJECT-CATEGORIES { umts } LAST-UPDATED "200111010800Z" ORGANIZATION "IETF RAP WG" CONTACT-INFO "Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 8175 Email: khchan@nortelnetworks.com Louis-Nicolas Hamer Nortel Networks 100 Constellation Crescent Ottawa, Ontario Canada, K2G 6J8 Phone: +1 613 768 3409 Email: nhamer@nortelnetworks.com" DESCRIPTION "A PIB module containing the set of provisioning classes that are required for support of policies for UMTS subject-categories." ::= { tbd } -- -- The root OID for PRCs in the UMTS PIB -- uMTSCapabilityClasses OBJECT IDENTIFIER ::= { uMTSPib 1 } uMTSEventPolicyClasses OBJECT IDENTIFIER ::= { uMTSPib 2 } uMTSEventClasses OBJECT IDENTIFIER ::= { uMTSPib 3 } uMTSConformance OBJECT IDENTIFIER ::= { uMTSPib 4 } -- -- Capability and Limitation Policy Rule Classes -- -- -- UMTS Capability Base Table Hamer, et al. [Page 15] COPS-PR for outsourcing in UMTS November 2001 -- uMTSBaseCapsTable OBJECT-TYPE SYNTAX SEQUENCE OF UMTSBaseCapsEntry PIB-ACCESS notify STATUS current DESCRIPTION "" ::= { uMTSCapabilityClasses 1 } uMTSBaseCapsEntry OBJECT-TYPE SYNTAX UMTSBaseCapsEntry STATUS current DESCRIPTION "An instance of the uMTSBaseCaps class that identifies a specific PRC and associated attributes as supported by the device." PIB-INDEX { uMTSBaseCapsPrid } UNIQUENESS { uMTSBaseCaps } ::= { uMTSBaseCapsTable 1 } UMTSBaseCapsEntry ::= SEQUENCE { uMTSBaseCapsPrid InstanceId, uMTSBaseCapsX Unsigned32 } uMTSBaseCapsPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the uMTSBaseCaps class." ::= { uMTSBaseCapsEntry 1 } uMTSBaseCapsX OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "" ::= { uMTSBaseCapsEntry 2 } Hamer, et al. [Page 16] COPS-PR for outsourcing in UMTS November 2001 -- -- Component Limitations Table -- -- This table supports the ability to export information -- detailing provisioning class/attribute implementation limitations -- to the policy management system. Hamer, et al. [Page 17] COPS-PR for outsourcing in UMTS November 2001 -- -- UMTS Event Policy Classes -- -- -- UMTS Event Policy Base Table -- uMTSBaseEventPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF UMTSBaseEventPolicyEntry PIB-ACCESS notify STATUS current DESCRIPTION "" ::= { uMTSEventPolicyClasses 1 } uMTSBaseEventPolicyEntry OBJECT-TYPE SYNTAX UMTSBaseEventPolicyEntry STATUS current DESCRIPTION "An instance of the uMTSBaseCaps class that identifies a specific PRC and associated attributes as supported by the device." PIB-INDEX { uMTSBaseEventPolicyPrid } UNIQUENESS { uMTSBaseEventPolicyPrc } ::= { uMTSBaseEventPolicyTable 1 } UMTSBaseEventPolicyEntry ::= SEQUENCE { uMTSBaseEventPolicyPrid InstanceId, uMTSBaseEventPolicyIfName SnmpAdminString, uMTSBaseEventPolicyRoles RoleCombination } uMTSBaseEventPolicyPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the uMTSBaseCaps class." ::= { uMTSBaseEventPolicyEntry 1 } uMTSBaseEventPolicyIfName OBJECT-TYPE SYNTAX SnmpAdminString STATUS current DESCRIPTION Hamer, et al. [Page 18] COPS-PR for outsourcing in UMTS November 2001 "The interface capability set to which this event handler provisioning entry applies. The interface capability name specified by this attribute must exist in the frwkIfCapSetTable (of the Framework PIB) prior to association with an instance of this class." ::= { uMTSBaseEventPolicyEntry 2 } uMTSBaseEventPolicyRoles OBJECT-TYPE SYNTAX RoleCombination STATUS current DESCRIPTION "The interfaces to which this entry applies, specified in terms of roles. There must exist an entry in the frwkIfCapSetRoleComboTable (of the Framework PIB) specifying this role combination, together with the interface capability set specified by uMTSBaseEventPolicyIfName, prior to association with an instance of this class." ::= { uMTSBaseEventPolicyEntry 3 } -- -- UMTS PDP Context Event Handler Provisioning Table -- uMTSPdpContextPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF UMTSPdpContextPolicyEntry PIB-ACCESS notify STATUS current DESCRIPTION "" ::= { uMTSEventPolicyClasses 2 } uMTSPdpContextPolicyEntry OBJECT-TYPE SYNTAX UMTSPdpContextPolicyEntry STATUS current DESCRIPTION "An instance of the uMTSBaseCaps class that identifies a specific PRC and associated attributes as supported by the device." EXTENDS { uMTBaseEventPolicyEntry } UNIQUENESS { uMTSPdpContextPolicyEnable, uMTSPdpContextPolicyFlowIds } ::= { uMTSPdpContextPolicyTable 1 } UMTSPdpContextPolicyEntry ::= SEQUENCE { Hamer, et al. [Page 19] COPS-PR for outsourcing in UMTS November 2001 uMTSPdpContextPolicyEnable Integer32, uMTSPdpContextPolicyFlowIds Unsigned32 } uMTSPdpContextPolicyEnable OBJECT-TYPE SYNTAX Integer32 { disable(1), enable(2) } STATUS current DESCRIPTION "Controls the usage of UMTS PDP Context Events to trigger requests to PCF on the go interface." DEFVAL { disable } ::= { uMTSPdpContextPolicyEntry 1 } uMTSPdpContextPolicyFlowIds OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "Indication of the maximum number of FlowIds a Token can be associated with The value of zero indicates policy control does not impose any limit. The limitation is based on GGSN capabilities." DEFVAL { 0 } ::= { uMTSPdpContextPolicyEntry 2 } -- -- RSVP Event Handler Provisioning Table -- Hamer, et al. [Page 20] COPS-PR for outsourcing in UMTS November 2001 -- -- UMTS Event Classes -- -- -- UMTS PDP Context Event Table -- uMTSPdpContextEventTable OBJECT-TYPE SYNTAX SEQUENCE OF UMTSPdpContextEventEntry PIB-ACCESS notify STATUS current DESCRIPTION "" ::= { uMTSEventClasses 1 } uMTSPdpContextEventEntry OBJECT-TYPE SYNTAX UMTSPdpContextEventEntry STATUS current DESCRIPTION "" PIB-INDEX { uMTSPdpContextEventPrid } UNIQUENESS { uMTSPdpContextEventToken } ::= { uMTSPdpContextEventTable 1 } UMTSPdpContextEventEntry ::= SEQUENCE { uMTSPdpContextEventPrid InstanceId, uMTSPdpContextEventToken OctetString, uMTSPdpContextEventFlowIds Prid } uMTSPdpContextEventPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the uMTSPdpContextEvent class." ::= { uMTSPdpContextEventEntry 1 } uMTSPdpContextEventToken OBJECT-TYPE SYNTAX OctetString STATUS current DESCRIPTION "The token associated with this PDP Context event." ::= { uMTSPdpContextEventEntry 2 } Hamer, et al. [Page 21] COPS-PR for outsourcing in UMTS November 2001 uMTSPdpContextEventFlowIds OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION "References the FlowIds associated with the Token indicated in this PDP Context event. This is the anchor of a list of uMTSPdpContextFlowIdEntry Instances. A value of zeroDotZero indicates an empty list." DEFVAL { zeroDotZero } ::= { uMTSPdpContextEventEntry 3 } -- -- UMTS PDP Context FlowID Table -- uMTSPdpContextFlowIdTable OBJECT-TYPE SYNTAX SEQUENCE OF UMTSPdpContextFlowIdEntry PIB-ACCESS notify STATUS current DESCRIPTION "" ::= { uMTSEventClasses 2 } uMTSPdpContextFlowIdEntry OBJECT-TYPE SYNTAX UMTSPdpContextFlowIdEntry STATUS current DESCRIPTION "" PIB-INDEX { uMTSPdpContextFlowIdPrid } UNIQUENESS { uMTPdpContextFlowIdX } ::= { uMTSPdpContextFlowIdTable 1 } UMTSPdpContextFlowIdEntry ::= SEQUENCE { uMTSPdpContextFlowIdPrid InstanceId, uMTSPdpContextFlowIdId OctetString, uMTSPdpContextFlowIdNext Prid } uMTSPdpContextFlowIdPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the uMTSPdpContextFlowId class." ::= { uMTSPdpContextFlowIdEntry 1 } Hamer, et al. [Page 22] COPS-PR for outsourcing in UMTS November 2001 uMTSPdpContextFlowIdId OBJECT-TYPE SYNTAX OctetString STATUS current DESCRIPTION "The FlowId itself." ::= { uMTSPdpContextFlowIdEntry 2 } uMTSPdpContextFlowIdsNext OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION "References the next FlowId in the list associated with the same Token of a PDP Context event. This points to a list of uMTSPdpContextFlowIdEntry Instances. A value of zeroDotZero indicates end of the list." DEFVAL { zeroDotZero } ::= { uMTSPdpContextFlowIdEntry 3 } Hamer, et al. [Page 23] COPS-PR for outsourcing in UMTS November 2001 -- -- Conformance Section -- uMTSCompliances OBJECT IDENTIFIER ::= { uMTSConformance 1 } uMTSGroups OBJECT IDENTIFIER ::= { uMTSConformance 2 } END Hamer, et al. [Page 24] COPS-PR for outsourcing in UMTS November 2001 9. IANA considerations This document follows the same rules as the base COPS protocol [COPS]. 10. Security Considerations It is clear that this PIB is used for configuration using [COPS-PR], and anything that can be configured can be misconfigured, with potentially disastrous effect. At this writing, no security holes have been identified beyond those that the COPS base protocol and COPS-PR protocol security have already addressed. The security mechanisms as described in [COPS], provide the necessary protection against security threats. However, even if the network itself is secure, there is no control as to who on the secure network is allowed to 'Install/Notify' (read/change/create/delete) the PRIs in this PIB. It is then a customer/user responsibility to ensure that the PEP/PCF giving access to an instance of this PIB, is properly configured to give access to the PRIs only to those principals (users) that have legitimate rights to indeed 'Install' or 'Notify' (change/create/ delete) them. 11. Author Information and Acknowledgments Louis-Nicolas Hamer Nortel Networks 100 Constellation Cr. Ottawa, Ontario CANADA K2G 6J8 Phone: +1 613 768 3409 Email: nhamer@nortelnetworks.com Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 8175 Email: khchan@nortelnetworks.com Hamid Mahmood Syed Nortel Networks 100 Constellation Cr. Ottawa, Ontario CANADA K2G 6J8 Phone: +1 613 763 6553 Email: hmsyed@nortelnetworks.com Hamer, et al. [Page 25] COPS-PR for outsourcing in UMTS November 2001 Hugh Shieh AT&T Wireless 7277 164th Ave NE Redmond, WA Phone: +1 425 580 6898 Email: hugh.shieh@attws.com Romeo Zwart AT&T Laarderhoogtweg 25 1101 EB Amsterdam, NL Email: Romeo.Zwart@ICOE.ATT.COM We would like to thank the following people for their very useful help in the creation of this concept and document: Celine Bonnel, & Bill Gage (Nortel Networks), Muhammad Jaseemuddin (Ryerson U.), Nigel Holland & Alexandre Harmand (BT). 12. References [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748, January 2000. [COPS-PR] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for Policy Provisioning," RFC 3084, March, 2001. [IETF-SIP] M. Handley, H. Schulzrinne, E. Schooler, and J.Rosenberg, "SIP: session initiation protocol," RFC 2543, Mar. 1999. [UMTS-QoS] 3GPP TS 23.207: 'End-to-End QoS Concept and Architecture', Release 5, ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23207-510.zip [UMTS-Go] 3GPP TS 29.207: 'Policy control over Go interface', Release 5, ftp://ftp.3gpp.org/Spec/Latest_drafts/29207-020.zip [UMTS-IM] 3GPP TS 23.228: 'IP Multimedia (IM) Subsystem - Stage 2', Release 5, ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23228-520.zip [UMTS-Arch] 3GPP TS 23.002: 'Network Architecture', Release 5, ftp://ftp.3gpp.org/Specs/latest/Rel-5/23_series/23002-540.zip Hamer, et al. [Page 26] COPS-PR for outsourcing in UMTS November 2001 [SPPI] K. McCloghrie, et.al., "Structure of Policy Provisioning Information," RFC 3159, August 2001. [RAP-FRAMEWORK] R. Yavatkar, D. Pendarakis, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [Frwrk-PIB] M. Fine, et al., 'Framework Policy Information Base', draft- ietf-rap-frameworkpib-06.txt, November 2001, Work in progress. [DS-PIB] M. Fine,et al., 'Differentiated Services Quality of Service Policy Information Base', draft-ietf-diffserv-pib-05.txt, November 2001, Work in progress. [FEEDBACK] D. Rawlins, et al., 'Framework of COPS-PR Policy Information Base for Policy Usage Feedback', draft-ietf-rap-feedback-fr- pib-00.txt, July 2001, Work in progress. 13. Full Copyright Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Hamer, et al. [Page 27] COPS-PR for outsourcing in UMTS November 2001 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Table of Contents Status of this Memo...............................................1 Abstract..........................................................1 Disclaimer........................................................1 1. Glossary.......................................................2 2. Introduction...................................................2 2.1 Rationale for using COPS-PR for outsourcing in UMTS...........2 3. Definition of terms............................................4 4. General UMTS and Go Interface Concepts.........................6 4.1. UMTS IP Multimedia Subsystem.................................6 4.2. Session authorization framework..............................6 4.3. Go Interface.................................................7 5. COPS-PR Usage for UMTS Go Interface............................8 5.1 General Description...........................................8 5.2 UMTS-specific Information in COPS-PR..........................9 5.2.1 Common Header, Client Type..................................9 5.2.2 Context Object..............................................9 5.2.3 Client Specific Information (ClientSI) for outsourcing Operation.........................................................9 5.3 General Operations............................................9 5.3.1. Reporting of Device Capabilities and Device Limitations....9 5.3.2. Initial UMTS Policy Provisioning..........................10 5.3.3 COPS-PR Outsourcing Operation..............................10 5.3.3.1. UMTS Service Request....................................10 5.3.3.2 Outsourced UMTS Decision.................................11 5.3.3.3 UMTS Service Usage Reporting.............................11 5.3.3.4 UMTS Service Usage Termination...........................11 6. Relationship between UMTSÆs COPS-PR Usage and other COPS-PR Usages...........................................................12 6.1 Re-use of PRCs from other PIBs...............................12 7. Summary of the UMTS PIB.......................................13 8. The UMTS PIB module...........................................14 9. IANA considerations...........................................25 10. Security Considerations......................................25 11. Author Information and Acknowledgments.......................25 12. References...................................................26 13. Full Copyright...............................................27 Hamer, et al. [Page 28]