R-1. The BPC Framework MUST support policies that are associated with the following session types: access, L2, subscriber, and application sessions.

MUST

C

L2 policies are not supported in SAPC.

R-2. The BPC Framework MUST support interaction with session establishment.

MUST

C

SAPC interacts with session establishment in Gx scenarios.

R-3. The BPC Framework MUST support Policy Change requests from Applications after session establishment.

MUST

C

Changes in policies defined per subscriber and service can be done using a REST interface.

R-4. The BPC Framework MUST support policies that apply to individual sessions.

MUST

C

Considering that one subscriber session has only one individual session.

R-5. The BPC Framework MUST support policy evaluation that is triggered by a change in state of a session.

MUST

C

R-6. The BPC Framework MUST support policies that apply to aggregates of subscriber sessions sharing logical interfaces, and/or layer 2 interfaces, and/or a physical access e.g. DSL loop.

MUST

C

Subscribers sharing the same logical interfaces are behind the same RG. And they are managed as a single L3 IP session.

R-7. The BPC Framework MUST support policies that apply to logical interface/layer 2 interface based on individual subscriber session policies when multiple subscriber sessions share a logical interface, and/or layer 2 interfaces, and/or a physical access e.g. DSL loop.

MUST

C

Layer 2 policies can be enforced with just a single Gx response with a policy id. The PEP is the responsible for doing the actual control.

R-8. The BPC Framework MUST support the application of policies to L2 access sessions.

MUST

C

See comment on R-7.

R-9. The BPC Framework MUST support the application of policies to subscriber sessions.

MUST

C

R-10. The BPC Framework MUST support ASP/NSP application requests for policy changes and resources from the network, without any knowledge of network topology and network state.

MUST

NC

No ASP/NSP application requests are supported.

R-11. The BPC Framework MUST support ASP/NSP applications querying the status of policy changes and resource requests without any knowledge of network topology and network state.

MUST

NC

No ASP/NSP application requests are supported.

R-12. The BPC Framework MUST allow secure and controlled access by NSPs and ASPs to the Policy Control infrastructure

MUST

NC

No ASP/NSP application requests are supported.

R-13. The BPC Framework MUST support policies for traffic associated with a specific A10-NSP interface and the associated backhaul tunnel.

MUST

NC

No ASP/NSP application requests are supported.

R-14. The BPC Framework MUST support policies that control traffic flows.

MUST

C

R-15. The BPC Framework MUST support network capacity admission control.

MUST

NA

Admission control is not provided by SAPC. It is the PEP responsibility.

R-16. The BPC Framework MUST support pre-emption of existing reservations based on a priority scheme.

MUST

NA

Admission control is not provided by SAPC. It is the PEP responsibility.

R-17. The BPC Framework MUST support business authorization of application requests (time of day, group membership, etc.)

MUST

C

Changes in policies defined per subscriber and service can be done using a REST interface.

R-18. The BPC Framework MUST support activation of another policy as a condition of a first policy (e.g. in order to authorize a particular media flow, some charging policy must be activated). This is also known as nested policies.

MUST

NA

Admission control is not provided by SAPC. It is the PEP responsibility.

R-19. The BPC Framework MUST support combining the following information when making admission control decisions for a new session:

• application requirements (e.g. bandwidth, QoS, etc.)

• available bandwidth for the subscriber based on the subscribers subscription

• current bandwidth usage

• network topology

• the available network capacity

MUST

NA

Admission control is not provided by SAPC. It is the PEP responsibility.

R-20. The BPC Framework MUST support a reservation model based on a provisioned, static view of the topology and bandwidth.

MUST

NA

Admission control is not provided by SAPC. It is the PEP responsibility.

R-21. The BPC Framework MUST support a reservation model based on a dynamically learned view of the topology and bandwidth.

MUST

NA

Admission control is not provided by SAPC. It is the PEP responsibility.

R-22. The BPC Framework MUST support bandwidth reservations in networks which have alternate traffic delivery paths (multipath).

MUST

NA

Admission control is not provided by SAPC. It is the PEP responsibility.

R-23. The BPC Framework MUST support automatic re-establishment of bandwidth reservations impacted by network failure.

MUST

NA

Admission control is not provided by SAPC. It is the PEP responsibility.

R-24. The BPC Framework MUST supports any application type requesting policy changes and/or resources from the network.

MUST

C

Changes in policies defined per subscriber and service can be done using a REST interface.

R-25. The BPC Framework MUST be able to consider the status of available network resources.

MUST

NA

Admission control information is not available SAPC.

R-26. The BPC Framework MUST support taking network events into account (e.g. events from Network elements).

MUST

C

R-27. The BPC Framework MUST support time of day and duration based policies and policy changes

MUST

C

R-28. The BPC Framework MUST support policies that control bandwidth allocation in TR-059[2], TR-101[5] and WT-145[23] based access network resources.

MUST

PC

Varying bandwidth rates are provided for subscribers, per IP session and per service.

RG is not supported as Policy Enforcement point.

R-29. The BPC Framework MUST support policies that control QoS in TR-059[2], TR-101[5] and WT-145[23] based access networks.

MUST

PC

QoS Control is provided for subscribers, per IP-CAN session and per service.

RG is not supported as Policy Enforcement point.

R-30. The BPC Framework MUST support the use of IPv6 for communication between the various policy related network elements.

MUST

C

R-31. The BPC Framework MUST support the use of the IPv6 header fields for the purposes of flow identification and policy enforcement.

MUST

C

R-32. The BPC Framework MUST support the use of IPv6 address management and allocation in the policy related nodes

MUST

C

R-33. The BPC Framework MUST support policies that control response to any type of network intrusion event.

MUST

PC

Supported the redirection or filtering of subscriber traffic.

R-34. The BPC Framework MUST allow control over multicast replication for individual multicast groups.

NR

R-35. The BPC Framework MUST support controlling routing policies for individual access sessions.

MUST

C

Routing policies are supported per subscriber session.

R-36. The BPC Framework MUST support logging of all transactions for the purposes of troubleshooting and security.

MUST

PC

Only logged transactions related to errors, warnings, and atypical situations.

R-37. The BPC Framework MUST support the generation of Accounting information for the purposes of billing and non-repudiation

NR

R-38. The BPC Framework MUST support the exchange of RADIUS and Diameter accounting messages with the AAA Server or network elements like the BNG.

MUST

NC

R-39. The BPC Framework MUST support the use of AAA RADIUS and Diameter attributes in the accounting messages for policy decisions.

MUST

NC

R-40. The BPC Framework MUST support the use of the charging models defined in TR-058[1], TR-102[6] and TR-144[8].

MUST

C

R-41. The BPC Framework MUST support the use of charging models for the use cases in Section 5.4

MUST

C

R-42. The BPC Framework MUST support the identification of charging rules for the various charging models.

MUST

C

Supported by Gx interface.

R-43. The BPC Framework MUST support interaction between DPI detection and enforcement functions.

NR

R-44. The BPC Framework MUST support the use of L4-7 classifiers in defining traffic policy.

MUST

C

R-45. The BPC Framework MUST support architectures in which the PDP functionality can be centralized, or distributed in various physical and nodal locations.

MUST

C

R-46. The BPC Framework MUST support a centralized PDP functionality which sends policy enforcement commands to multiple Policy Enforcement Points.

MUST

C

R-47. The PDPs MUST be able to interact to support end-to-end control for the purposes scaling and or spanning different network administration boundaries.

MUST

NC

R-48. The BPC Framework MUST support multiple PDPs, where each PDP is responsible for making policy decisions for a predefined network domain (geographical, administrative wholesale, or retail).

MUST

C

R-49. The BPC Framework MUST support multiple PDPs, where each PDP is responsible for making policy decisions for different PEP types or PEP functions.

MUST

C

R-50. The BPC Framework MUST support the acceptance or rejection of requested policy changes.

MUST

C

R-51. The BPC Framework MUST support a single policy request being able to configure multiple individual sessions.

MUST

C

An RG in bridge mode, is handling a single IP session. This IP session manages several subscribers sessions. So SAPC, managing one single IP session, is managing several subscriber sessions

R-52. The BPC Framework MUST support a mechanism for communicating policy requests and decisions that is secure against spoofing, hijacking and DoS attacks.

MUST

C

Any user passwords are sent encrypted, to eliminate the possibility that someone snooping on an unsecured network could determine a user's password.

R-53. The PDP logical entity SHOULD be able to interact with an Application Server to allow dynamic real-time changes of policy for both upstream and downstream traffic, e.g. a QoS change.

SHOULD

C

Changes in policies defined per subscriber and service can be done using a REST interface.

R-54. The PDP MUST be able to communicate with the NMS/OSS, AAA Server, AF, Repository and other PDP(s) to facilitate making policy decisions.

MUST

PC

AAA is not supported.

R-55. The BPC Framework MUST support policy enforcement for both downstream and upstream traffic.

MUST

C

R-56. The PEP logical entity MUST be able to enforce policy for unicast and multicast traffic.

NR

R-57. The PEP MUST be able to apply policy on Access Sessions, L2 Sessions, Subscriber Sessions and Traffic rule session.

NR

R-58. The PEP MUST be able to receive policy information from the PDP over the R interface.

NR

R-59. The PEP MUST be able to request policies from the PDP over the R interface.

NR

R-60. The PEP MUST be able to be directed to receive/activate/modify/delete policies from the NMS/OSS over M/Q interface

NR

R-61. The PEP MUST be able to be directed to receive/activate/modify/delete policies from AAA Server over the B interface.

NR

R-62. A PDP MUST be able to connect with another PDP(s) over the I interface. Examples of where this might be required include the case where multiple domains are involved, or when functionality is delegated from one PDP to another.

MUST

NC

R-63. The PDP MUST be able to make policy decisions for Access Sessions, L2 Sessions, Subscriber Sessions and Traffic Rule session.

MUST

C

R-64. The PDP MUST be able to provide policy decisions for multiple PEPs.

MUST

C

R-65. The PDP SHOULD be able to retrieve subscriber information from a Repository or AAA Server function.

SHOULD

C

R-66. The PDP SHOULD be able to install/activate/deactivate/modify/remove Policies in the PEP, and allow dynamic changes of policy for both upstream and downstream traffic.

SHOULD

C

R-67. The ACF MUST be able to make admission decisions based upon network resources and business policies.

MUST

NC

Admission control is not supported.

R-68. The PDP MUST be able to add policy rules in the PEP via the R interface.

MUST

C

R-69. The PDP MUST be able to modify policy rules in the PEP via the R interface.

MUST

C

R-70. The PDP MUST be able to remove policy rules in the PEP via the R interface.

MUST

C

R-71. The PDP MUST be able to activate policy rules in the PEP via the R interface.

MUST

C

R-72. The PDP MUST be able to deactivate policy rules in the PEP via the R interface.

MUST

C

R-73. The PEP MUST be able to respond to policy rules received from the PDP via the R interface indicating the result of the request.

MUST

C

R-74. The PEP MUST be able to request policy rules from the PDP via the R interface.

MUST

C

R-75. The communication between the PDP and the PEP MUST be reliable.

MUST

C

R-76. The PDP MUST be able to respond to a policy request from the PEP via the R reference point accepting or rejecting the request.

MUST

C

Only supported with Gx interface.

R-77. The protocol design for the R interface MUST support the exchange of Vendor-Specific Information.

MUST

C

R-78. The PDP SHOULD be able to submit the following message parameters to the PEP:

- Policy rule-set upon Subscriber session establishment

- Policy rule update during Subscriber session, upon session event and on termination

- Request for notification of specific events

SHOULD

C

Policy rule update on termination is not supported.

R-79. PDP decisions MUST be able to be based on:

Information obtained from the AF via the E/G interfaces (e.g. the session, media and subscriber related information).

Information obtained from the PEP via the R interface (e.g. bearer attributes, request type and subscriber related information).

Information obtained from the AAA Server via the A interface

Information obtained from another PDP via the I interface.

Information obtained from the repository via the C interface (e.g. subscriber and service related data)

MUST

PC

Communication with another PDP is not supported.

Information obtained from the AAA Server is not supported.

PDP ID

SHOULD

C

Session ID

SHOULD

C

Supported Access session ID.

IP Address

SHOULD

C

Policy Rule Request

SHOULD

C

Policy lifetime

SHOULD

C

Policy Rule Response

SHOULD

C

QoS Parameter

SHOULD

C

Policy Rule ID

SHOULD

C

Policy Rule Group ID

SHOULD

C

Policy Rule Precedence

SHOULD

C

Traffic actions

SHOULD

C

Application action

SHOULD

C

As example HTTP-Redirect.

Traffic flow filter ( IP 5-tuple)

SHOULD

C

Multicast ACL

SHOULD

NC

Quota

SHOULD

C

Charging Mode

SHOULD

C

Rating-Group

SHOULD

C

Charging-Correlation ID

SHOULD

C

Policy Rule

SHOULD

C

Policy Rule parameters

SHOULD

C

Vendor-Id

SHOULD

NC

Event Trigger

SHOULD

C

Default-Access Profile

SHOULD

C

Logical access ID

SHOULD

NC

Physical Access ID

SHOULD

NC

Globally Unique IP address

SHOULD

C

Subscriber ID

SHOULD

NC

HdrIpVersion

SHOULD

C

HdrSrcAddress

SHOULD

C

HdrSrcAddressEndOfRange

SHOULD

C

HdrSrcMask

SHOULD

C

HdrDestAddress

SHOULD

C

HdrDestAddressEndOfRange

SHOULD

C

HdrDestMask

SHOULD

C

HdrProtocolID

SHOULD

C

HdrSrcPortStart

SHOULD

C

HdrSrcPortEnd

SHOULD

C

HdrDestPortStart

SHOULD

C

HdrDestPortEnd

SHOULD

C

HdrDSCP

SHOULD

C

HdrFlowLabel

SHOULD

C

QoSInformation

SHOULD

C

QoS Information Identifier

SHOULD

C

8021 Source MAC address

SHOULD

NC

8021 Destination MAC Address

SHOULD

NC

8021 Protocol ID

SHOULD

NC

8021 Priority Value

SHOULD

NC

8021 VLAN ID

SHOULD

NC

Vendor-Id

SHOULD

C

Can be used to decide the policies for the subscriber.

Firmware revision

SHOULD

C

Can be used to decide the policies for the subscriber.

Policy Rule ID

SHOULD

C

Subscriber ID

SHOULD

C

Can be used to decide the policies for the subscriber.

IP Address

SHOULD

C

Can be used to decide the policies for the subscriber.

Application / Traffic signature

SHOULD

C

Traffic flow filter ( IP 5-tuple)

SHOULD

C

Application/ traffic signature /session ID

SHOULD

C

Policy Rule Request

SHOULD

C

Policy Rule Response

SHOULD

C

Termination-Cause

SHOULD

C

Policy lifetime

SHOULD

NC

QoS Parameters

SHOULD

C

Session modification trigger

SHOULD

C

Default-Access Profile

SHOULD

NC

Interface name

SHOULD

C

MAC Address

SHOULD

C

If the MAC Address is the content of the Subscription-Id value in Gx interface.

Access Loop Characteristics

SHOULD

NC

Access Session ID

SHOULD

C

L2 Session ID

SHOULD

C

Subscriber Session Id

SHOULD

C

Service Session Id

SHOULD

C

Application Session Id

SHOULD

C