RFC 2753

A Framework for Policy-based Admission Control

📅 published January 2000, from ietf

Network Working Group Request for Comments 2753 🎀

Title: A Framework for Policy-based Admission Control ✨

Authors: R. Yavatkar (Intel), D. Pendarakis (IBM), and R. Guerin (U. Of Pennsylvania) 👯‍♀️

Category: Informational 📚

Date: January 2000 📅

The header doesn't list any Obsoletes or Updates entries, so this doc doesn't replace or change any earlier RFC. 🌸

Status of this Memo 🧾

okay so this memo is just for information 💅 It's not an Internet standard of any kind, and it can be shared as widely as you like 🦋

Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒

1. Introduction ✨

bestie, let's set the scene 🧚 The IETF working groups Integrated Services (called "int-serv") and RSVP [1] came up with extensions to the IP architecture and the best-effort service model. The point is that apps or end users can ask an internetwork for a specific quality (or level) of service, on top of the normal IP best-effort service 🚀 Then the Differentiated Services Working Group started working on mechanisms for aggregate QoS services too, which is giving teamwork 🤝

The int-serv model needs QoS requirements to be signaled explicitly from the end points, and it needs admission and traffic control at Integrated Services routers 🔥 The proposed standards are [RFC 2205] for RSVP, which is a new reservation setup protocol, and [RFC 2211, RFC 2212] for Integrated Services, which defines the new services 💜 Under int-serv, some flows get preferential treatment over others. The admission control part only looks at the requester's reservation request and the capacity that's available when deciding whether to accept a QoS request 👑

Here's the tea though 🫖 int-serv doesn't cover one important piece of admission control. Network managers and service providers need to be able to monitor, control, and enforce how network resources and services get used, based on policies. Those policies can come from things like the identity of users and applications, traffic and bandwidth needs, security considerations, and time-of-day/week 😭 diff-serv has the same problem: it also needs policies based on things like customer identity, ingress points, and so on 💀

This document is all about a framework for policy-based control over admission control decisions 🎀 It focuses on RSVP as the example QoS signaling mechanism, but the framework is meant to work for other QoS contexts too 🌈 The authors' argument is that policy-based control has to work across the different kinds and qualities of services offered on the same network, so the goal is to support those extensions whenever it's possible ✨

Here's the roadmap 🗺️

  • Section 2 has the definitions.
  • Section 3 covers the requirements and goals for the mechanisms that control and enforce access to better QoS.
  • Section 4 outlines the architectural elements of the framework and describes what each component is expected to do.
  • Section 5 talks about example policies, possible scenarios, and the policy support those scenarios need.
  • Section 6 sets out the requirements for a client-server protocol between a policy server (PDP) and its client (PEP), and checks how well some existing protocols fit that job 🦋

2. Terminology 📖

okay, here's the glossary you'll want to keep handy 💖

  • Administrative Domain: A group of networks under the same administrative control, bundled together for administrative purposes 🏠
  • Network Element or Node: Routers, switches, and hubs are all examples of network nodes 🖥️ They're the places where resource allocation decisions get made and enforced. An RSVP router that gives part of a link's capacity (or buffers) to a particular flow, and makes sure only admitted flows can use their reserved resources, is a network element we care about here 🚦

In this document, router, network element, and network node are used interchangeably, but they should all be read as references to a network element 🫶

  • QoS Signaling Protocol: A signaling protocol that carries an admission control request for a resource, such as RSVP 📡
  • Policy: The combination of rules and services, where the rules define the criteria for resource access and usage 📜
  • Policy control: Applying rules to decide whether access to a particular resource should be granted 🔐
  • Policy Object: Holds policy-related info, such as policy elements, and gets carried in a request or response about a resource allocation decision 📦
  • Policy Element: A piece of a policy object. It holds a single unit of information needed to evaluate policy rules 🧩 One policy element might carry a user or application identification, while another might carry user credentials or credit card information. The policy elements are expected to be independent of which QoS signaling protocol is in use 💅
  • Policy Decision Point (PDP): The point where policy decisions are made 🧠
  • Policy Enforcement Point (PEP): The point where those policy decisions actually get enforced 👮‍♀️
  • Policy Ignorant Node (PIN): A network element that doesn't explicitly support policy control using the mechanisms defined in this document 🙈
  • Resource: Something of value in a network infrastructure that rules or policy criteria are applied to before access is granted. Examples include the buffers in a router and the bandwidth on an interface 🍓
  • Service Provider: Controls the network infrastructure and may be responsible for charging and accounting for services 💰
  • Soft State Model: Soft state is a form of the stateful model where installed state times out at a PEP or PDP. It's an automatic way to erase state when there are communication or network element failures 🧹 For example, RSVP uses the soft state model to install reservation state at network elements along the path of a data flow 🌊
  • Installed State: A new and unique request made from a PEP to a PDP that must be explicitly deleted 🗑️
  • Trusted Node: A node that sits within the boundaries of an administrative domain (AD) and is trusted, meaning admission control requests from that node don't necessarily need a PDP decision 👑

3. Policy-based Admission Control: Goals and Requirements ✨

okay so this section is where we talk about what the policy-based admission control stuff is supposed to achieve 🎯 like, the goals and the must-haves. let's get into it bestie 💅

  • Policies vs Mechanisms: 🧠 the framework doesn't talk about any specific policy behavior, and it doesn't require any specific policies. it just lays out the architectural pieces and mechanisms needed so that a wide variety of possible policies can actually get carried out. it's giving "build the stage, let others pick the show" 🎭
  • RSVP-specific: 🎀 the mechanisms have to meet the policy-based control requirements for bandwidth reservation using RSVP as the signaling protocol. BUT (and this is a big but) the goal is also to let this framework work for admission control involving other kinds of resources and QoS services (for example, Diff-Serv) 🌈 as long as we don't stray from our central goal. main character energy, but make it make sense 💖
  • Support for preemption: 🔥 the mechanisms must support preemption. preemption means being able to remove a state that's already installed so you can accept a brand new admission control request. so for RSVP, that means being able to kick out one or more reservations that are already installed to make room for a new resource reservation request. the queen of making space 👑
  • Support for many styles of policies: 🦋 the mechanisms must support lots of policies and policy configurations, including bi-lateral and multi-lateral service agreements, plus policies based on relative priority. generally speaking, figuring out and configuring which policies are viable is the service provider's job 🫶
  • Provision for Monitoring and Accounting Information: 📊 the mechanisms must support monitoring policy state and resource usage, and must provide access information. specifically, they must include ways to provide usage and access information that can be used for accounting and billing purposes. money talks 💸
  • Fault tolerance and recovery: 🛟 the mechanisms built on this framework must include provisions for fault tolerance and for recovering from failures. the failure cases called out are things like PDP failures, and communication disruptions (including network partitions, and the later merging back together) that cut a PDP off from its associated PEPs. the "what if everything goes wrong" section, and honestly it's very important 😭
  • Support for Policy-Ignorant Nodes (PINs): 🙈 the mechanisms in this document should not be mandatory for every node in a network. policy-based admission control could be enforced at just a subset of nodes, like the boundary nodes within an administrative domain. those policy-capable nodes would act as trusted nodes from the point of view of the policy-ignorant nodes in that domain. not everyone needs to be in on the tea 🍵
  • Scalability: 📈 scalability is one of the biggest requirements for the mechanisms designed for policy control. the mechanisms must scale at least as well as RSVP does, in terms of handling multiple flows and multiple network nodes in a flow's path. scalability has to be considered when specifying default behavior for merging policy data objects, and merging must not result in duplicate policy elements or objects 🙅‍♀️ there are a few sensitive spots for policy control over RSVP:
    • first, not every policy-aware node in an infrastructure should be expected to contact a remote PDP. that would cause potentially long delays in verifying requests, since they'd have to travel up hop by hop 🐢
    • second, RSVP can set up resource reservations for multicast flows, which means the policy control model must be able to handle the special requirements of large multicast flows 📡
    • so, overall, the policy control architecture must scale at least as well as RSVP based on factors like the size of RSVP messages, the time the network needs to service an RSVP request, the local processing time per node, and the local memory consumed per node 🧮
  • Security and denial of service considerations: 🚨 the policy control architecture must be secure in two main ways. first, the mechanisms proposed under the framework must minimize theft and denial of service threats. second, it must be ensured that entities involved in policy control (like PEPs and PDPs) can verify each other's identity and establish the necessary trust before communicating. no trust, no chat 🔐

4. Architectural Elements 🧩

okay now the building blocks! 🧱 the two main architectural elements for policy control are the PEP (Policy Enforcement Point) and the PDP (Policy Decision Point). the figure below shows a simple setup with these two. the PEP is a component sitting at a network node, while the PDP is a remote entity that may live on a policy server. 🖥️

the PEP is the part that always runs on the policy-aware node. it's the spot where policy decisions actually get enforced, but the decisions themselves are mostly made at the PDP. 👀 the PDP can also lean on extra mechanisms and protocols for extra stuff, like user authentication, accounting, policy information storage, and so on. for example, the PDP is likely to use an LDAP-based directory service for storing and retrieving policy information[6]. this document doesn't dig into those extra mechanisms and protocols or how they get used, so don't come for me about it 🙅‍♀️

here's how the conversation goes between the components. it starts with the PEP. the PEP receives a notification or a message that needs a policy decision. then it formulates a request for that decision and sends it to the PDP ✉️ the request can carry one or more policy elements (packed into one or more policy objects), along with the admission control info from the original message or event that triggered the request, like a flowspec or the amount of bandwidth requested. the PDP sends back the policy decision, and then the PEP enforces it by accepting or denying the request ✅❌

the PDP can also send extra info back to the PEP, including one or more policy elements. that info doesn't have to be tied to an admission control decision. instead, it can be used to build an error message or an outgoing/forwarded message. 💌

 ________________         Policy server
|                |        ______
|  Network Node  |        |     |------------->
|    _____       |        |     |   May use LDAP,SNMP,.. for accessing
|   |     |      |        |     |  policy database, authentication,etc.
|   | PEP |<-----|------->| PDP |------------->
|   |_____|      |        |_____|
|                |

✨ that's the whole picture for part two, bestie! the PEP does the enforcing, the PDP does the deciding, and they chat about it through policy objects 💜

________________

Okay so that's Figure 1 🎀, the basic setup with the main policy control architecture pieces! PDP may use additional mechanisms and protocols for accounting, authentication, policy storage, etc. 💅

The PDP might optionally contact other external servers 🌸, like for accessing configuration, user authentication, and accounting and billing databases. Protocols defined for network management (SNMP) or directory access (LDAP) might be used for this chat. Each implementation might do the access and protocols a little differently, but some of these interactions will have network-wide implications and could mess with how different devices work together. 🙈

Of particular importance is the "language" used to specify the policies the PDP implements 📜. There could be a LOT of policies at one network node, and they're complicated, with lots of fields used to reach a decision and a wide range of decisions. 😭 Also, several policies could easily apply to the same request profile. For example, a policy might say how requests from a general user group (like employees of a company) get treated, and also how requests from specific members of that group (like managers of the company) get treated. So the "managers" user profile falls under two policies, one general and one more specific. ✨

To handle all that complexity and keep policies coherent and consistent across the whole network, the policy specification language should ensure an unambiguous mapping of a request profile to a policy action. It should also let you specify the order in which policy rules get applied and/or the priority of each one. Some of these issues are addressed in [6]. 🧚

In some cases, the simple setup in Figure 1 might not be enough, because it might be necessary to apply local policies (like policies in access control lists) on top of the policies applied at the remote PDP. Also, the PDP can be co-located with the PEP on the same network node. Figure 2 shows the possible configurations. 🦋

The configurations in Figures 1 and 2 show how flexible the division of labor is! 🌈 On one hand, a centralized policy server could handle policy decisions for multiple network nodes in an administrative domain, implementing policies of a wide scope that are common across the AD. On the other hand, policies that depend on information and conditions local to a particular router, and that are more dynamic, might be better implemented locally, at the router. 👑

 ________________                        ____________________
|                |                      |                    |
|  Network Node  |  Policy Server       |    Network Node    |
|    _____       |      _____           |  _____      _____  |
|   |     |      |     |     |          | |     |    |     | |
|   | PEP |<-----|---->| PDP |          | | PEP |<-->| PDP | |
|   |_____|      |     |_____|          | |_____|    |_____| |
|    ^           |                      |                    |
|    |    _____  |                      |____________________|
|    \-->|     | |
|        | LPDP| |
|        |_____| |
|                |
|________________|

Figure 2: Two other possible configurations of policy control architecture components. The configuration on the left shows a local decision point at a network node, and the configuration on the right shows PEP and PDP co-located at the same node. 💖

If it's available, the PEP will first use the LPDP to reach a local decision. ✨ That partial decision and the original policy request then get sent to the PDP, which renders a final decision (possibly overriding the LPDP). It must be noted that the PDP acts as the final authority for the decision returned to the PEP, and the PEP must enforce the decision rendered by the PDP. 👑 Finally, if a shared state has been established for the request and response between the PEP and PDP, it's the PEP's responsibility to notify the PDP that the original request is no longer in use. 🫶

Unless otherwise specified, we'll assume the configuration on the left in Figure 2 for the rest of this document. 🍓

Under this policy control model, the PEP module at a network node must use the following steps to reach a policy decision: 💅

  1. When a local event or message invokes the PEP for a policy decision, the PEP creates a request that includes information from the message (or local state) describing the admission control request. The request also includes appropriate policy elements, as described below. 🌸
  2. The PEP may consult a local configuration database to identify a set of policy elements (called set A) that are to be evaluated locally. The local configuration specifies the types of policy elements that are evaluated locally. The PEP passes the request with set A to the Local Decision point (LPDP) and collects the result of the LPDP (called "partial result" and referred to as D(A)). 🦋
  3. The PEP then passes the request with ALL the policy elements and D(A) to the PDP. The PDP applies policies based on all the policy elements and the request, and reaches a decision (let's call it D(Q)). It then combines its result with the partial result D(A) using a combination operation to reach a final decision. 🧚
  4. The PDP returns the final policy decision (obtained from the combination operation) to the PEP. 💜

Note that in the above model, the PEP MUST contact the PDP even if no (or NULL) policy objects are received in the admission control request. ⭐ This requirement helps ensure that a request can't bypass policy control by leaving out policy elements in a reservation request. 🙈 However, "short circuit" processing is permitted, i.e., if the result of D(A) above is "no", there's no need to keep doing policy processing at the PDP. Still, the PDP must be informed of the failure of local policy processing. The same goes for when policy processing succeeds but admission control (at the resource management level, due to unavailable capacity) fails. Again, the PDP has to be informed of the failure. 😭

It must also be noted that the PDP may, at any time, send an asynchronous notification to the PEP to change an earlier decision or to generate a policy error/warning message. 🔥

4.1. Example of a RSVP Router 🦋

In the case of an RSVP router, Figure 3 shows how a PEP interacts with other int-serv components inside the router. 💖 For this discussion, we represent all the components of RSVP-related processing by a single RSVP module, but a more detailed discussion of the exact interaction and interfaces between RSVP and the PEP is in a separate document [3]. 🌈

     ______________________________
    |                              |
    |           Router             |
    |  ________           _____    |            _____
    | |        |         |     |   |           |     |
    | |  RSVP  |<------->| PEP |<--|---------->| PDP |
    | |________|         |_____|   |           |_____|
    |      ^                       |
    |      |      Traffic control  |
    |      |      _____________    |
    |      \---->|  _________  |   |
    |            | |capacity | |   |
    |            | | ADM CTL | |   |
    |            | |_________| |   |
  --|----------->|  ____ ____  |   |
    |   Data     | | PC | PS | |   |
    |            | |____|____| |   |
    |            |_____________|   |
    |                              |
    |______________________________|

Figure 3: Relationship between PEP and other int-serv components within an RSVP router. PC -- Packet Classifier, PS -- Packet Scheduler 🧚

When an RSVP message arrives at the router (or an RSVP-related event requires a policy decision), the RSVP module is expected to hand the request (corresponding to the event or message) off to its PEP module. ✨ The PEP will use the PDP (and LPDP) to get the policy decision and communicate it back to the RSVP module. 👑

4.2. Additional functionality at the PDP 💅

Typically, the PDP returns the final policy decision based on an admission control request and the associated policy elements. 🌸 However, it should be possible for the PDP to sometimes ask the PEP (or the admission control module at the network element where the PEP resides) to generate policy-related error messages. For example, in the case of RSVP, the PDP may accept a request and allow a reservation to be installed and forwarded to a previous hop, but at the same time it may want to generate a warning/error message to a downstream node (NHOP) about conditions like "your request may have to be torn down in 10 mins, etc." 😭 Basically, we need the ability to create policy-related errors and/or warnings and propagate them using the native QoS signaling protocol (such as RSVP). 🫶 Such a policy error returned by the PDP must also be able to specify whether the reservation request should still be accepted, installed, and forwarded to allow continued normal RSVP processing. 🔥 In particular, when a PDP sends back an error, it specifies that:

  1. the message that generated the admission control request should be processed further as usual, but an error message (or warning) should be sent in the other direction and include the policy objects supplied in that error message
  2. or, an error is returned, but the RSVP message should not be forwarded as usual. 💀

4.3. Interactions between PEP, LPDP, and PDP at an RSVP router 🧚

All the details of RSVP message processing and the associated interactions between the different elements at an RSVP router (PEP, LPDP) and the PDP are in separate documents [3,8]. Here are a few salient points related to the framework: 🌈

  • LPDP is optional and may be used for making decisions based on policy elements handled locally. The LPDP, in turn, may have to go to external entities (such as a directory server or an authentication server, etc.) to make its decisions. 🎀
  • PDP is stateful and may make decisions even if no policy objects are received (e.g., make decisions based on information such as flowspecs and session object in the RSVP messages). The PDP may consult other PDPs, but discussion of inter-PDP communication and coordination is outside the scope of this document. 💜
  • PDP sends asynchronous notifications to PEP whenever necessary to change earlier decisions, generate errors, etc. ⭐
  • PDP exports the information useful for usage monitoring and accounting purposes. An example of a useful mechanism for this purpose is a MIB or a relational database. However, this document does not specify any particular mechanism for this purpose, and discussion of such mechanisms is out of the scope of this document. 🍓

4.4. Placement of Policy Elements in a Network

Okay bestie, splitting the work between an LPDP and a PDP is what makes staged deployment possible 💖. Routers with all kinds of different policy smarts can still talk to policy servers, no drama ✨. Figure 4 shows a little squad of nodes spread across three administrative domains (ADs) 🌸. Each AD could be a different service provider here. Nodes A, B and C are in AD-1 and get advice from PDP PS-1. D lives in AD-2 and E lives in AD-3, and E talks to PDP PS-2 🦋. Generally, you'd expect at least one PDP per administrative domain 💅.

Policy-capable nodes come in every flavor 🍓. Take E, which is super low-key: it has no LPDP, so it leans on an external PDP for every single policy processing operation 🥺. Then there's D, the self-sufficient queen 👑, which packs both an LPDP and a PDP right there in the router 💅.

                        AD-1                    AD-2         AD-3
      ________________/\_______________     __/\___      __/\___
     {                                 }   {       }    {       }
             A           B            C            D            E
        +-------+  +-----+    +-------+    +-------+    +-------+
        | RSVP  |  | RSVP|    | RSVP  |    | RSVP  |    | RSVP  |
+----+  |-------|  |-----|    |-------|    |-------|    |-------|
| S1 |--| P | L |--|     |----| P | L |----| P | P |----|   P   | +----+
+----+  | E | D |  +-----+    | E | D |    | E | D |    |   E   |-| R1 |
        | P | P |             | P | P |    | P | P |    |   P   | +----+
        +-------+             +-------+    +-------+    +-------+
           ^                        ^                           ^
           |                        |                           |
           |                        |                           |
           |                        |                       +-------+
           |                        |                       | PDP   |
           |         +------+       |                       |-------|
           +-------->| PDP  |<------+                       |       |
                     |------|                               +-------+
                     |      |                                  PS-2
                     +------+
                       PS-1

Figure 4: Placement of Policy Elements in an internet 🧚

5. Example Policies, Scenarios, and Policy Support

Okay so here we get into examples of the policies and scenarios that the policy control framework should be able to support ✨. In some cases we also sketch possible approaches for hitting those goals, plus a list of open issues that still need sorting out 🔥.

5.1. Admission control policies based on factors such as Time-of-Day, User Identity, or credentials.

Policy control needs to be able to express and enforce rules with temporal dependencies ⏰. For example, a group of users might only get to make reservations at certain levels during off-peak hours 🌙. The policy control also needs to handle identity or credentials of the users asking for a service or resource 🔐. Like, an RSVP reservation request could be denied or accepted based on the credentials or identity it carries 🙈.

5.2. Bilateral agreements between service providers

Until recently, usage agreements between service providers for traffic crossing their boundaries were pretty simple 🥱. Two ISPs might agree to accept all traffic from each other, often without any accounting or billing for the "foreign" traffic they carry 🤷‍♀️. But with QoS mechanisms based on Integrated and Differentiated Services, traffic differentiation and quality of service guarantees are getting phased into the Internet 🌈. Once ISPs start selling customers different grades of service and can tell apart different sources of traffic, they'll also want ways to charge each other for traffic (and reservations) transiting their networks 💸. Another incentive is the potential asymmetry in the customer base that different providers will have: ISPs focused on corporate traffic will likely see much higher demand for reserved services than ISPs serving the consumer market 💼. Without sophisticated accounting schemes for inter-ISP traffic, costs could get allocated inefficiently between service providers 😭.

Bilateral agreements could fall into two broad categories: local or global 🧩. Due to the complexity of the problem, only the former is expected to be deployed at first 🐣. In these, providers that manage a network cloud or administrative domain contract with their closest point of contact (neighbor) to set ground rules and arrangements for access control and accounting 🤝. These contracts are mostly local and don't rely on global agreements, so a policy node only keeps information about its neighboring nodes 🫶. Looking at Figure 4, this model means provider AD-1 has arrangements with AD-2, but not with AD-3, for usage of each other's network 🗺️. Provider AD-2, in turn, has agreements in place with AD-3, and so on 🔁. So when forwarding a reservation request to AD-2, provider AD-2 will charge AD-1 for use of all resources beyond AD-1's network 💅. This information comes from recursively applying the bilateral agreements at every boundary between (neighboring) providers, until the recipient of the reservation request is reached 🎯.

To make this work under the policy control architecture, boundary nodes have to add an appropriate policy object to the RSVP message before forwarding it to a neighboring provider's network 🎀. This policy object carries things like the identity of the provider that generated them and the equivalent of an account number where charges can pile up 🧾. Since agreements only hold among neighboring nodes, policy objects have to get rewritten as RSVP messages cross the boundaries of administrative domains or provider's networks 🔄.

5.3. Priority based admission control policies

In lots of settings, it's useful to tell reservations apart based on some level of "importance" 👑. For example, this helps stop the first reservation to be granted some resources from hogging them for an indefinite period of time 😤. It can also let emergency calls go through even during periods of congestion 🚨. This kind of functionality can be supported by attaching priorities to reservation requests and sending that priority information along with the other policy information 🧃.

In its basic form, the priority of a reservation directly decides its rights to the resources it asks for 💖. Say priorities are expressed as integers from 0 to 32, with 32 being the highest priority. A reservation of priority, say, 10 will always be accepted if the resources held by lower priority reservations are enough to cover its requirements ✨. In other words, if a node doesn't have enough free resources (bandwidth, buffers, etc.) to fit a priority 10 request, it will try to free them up by preempting existing lower priority reservations 🌸.

Getting priorities to work properly has a few requirements 📝. First, traffic control in the router needs to be priority-aware, meaning it classifies existing reservations by priority so it can figure out how many and which ones to preempt when a higher priority request comes in 🧠. Second, preemption has to happen consistently at different nodes, so you don't get transient instabilities 🌀. Third, and possibly the most important, merging of priorities needs to be carefully architected, with its impact clearly understood as part of the associated policy definition 🔍.

Of those three, merging priority information is the trickiest and deserves extra discussion 😵‍💫. It's complicated because the merging has to happen on top of merging the reservation information itself 🫠. When the reservation (FLOWSPEC) information is identical (homogeneous reservations), merging only has to consider priority, and the simple rule of keeping the highest priority is a fine answer 🥰. But with heterogeneous reservations, the two-dimensional nature of the (FLOWSPEC, priority) pair makes ordering, and therefore merging, hard 🌀. How the different cases of RSVP priority objects get handled is described in [7] 📚.

5.4. Pre-paid calling card or Tokens 💳✨

Okay bestie, pre-paid calling cards are having a whole moment in the phone world, and the Internet could totally do the same thing 💅. Users buy "tokens" and then cash them in later for network services. When a user makes a reservation request, say an RSVP RESV message, they include the token's unique identification number inside a policy object. Policy-capable routers process that object and decrement the token's value, which is the number of units of service left on it 🎟️.

Referring to Figure 4, suppose receiver R1 in the administrative domain AD3 wants to request a reservation for a service that starts in AD1 🌸. R1 generates a policy data object of type PD(prc, CID), where "prc" stands for pre-paid card and CID is the card identification number. This object rides along with the other policy objects in the RESV message. Node E receives it, forwards it to its PEP, PEP_E, and PEP_E checks in with PDP PS-3 🧚. PS-3 either keeps a database of pre-paid card numbers locally or has remote access to one. If there's enough remaining credit on CID, the PDP accepts the reservation and the policy object goes back to PEP_E. Two issues have to be sorted out here 👀:

  • What is the scope of these charges?
  • When are charges (in the form of decrementing the remaining credit) first applied?

The first question depends on the bilateral agreement model in place 🤝. If provider AD-3 has agreements with both AD-2 and AD-1, it can charge for the cost of the whole reservation up to sender S1. In that case PS-2 removes the PD(prc,CID) object from the outgoing RESV message.

On the other hand, if AD-3 has no bilateral agreements in place, it simply charges CID for the cost of the reservation inside AD-3 and then forwards PD(prc,CID) in the outgoing RESV message. Later PDPs in other administrative domains charge CID for their own reservations 💸. Since multiple entities are both reading (remaining credit) and writing (decrementing credit) to the same database, some coordination and concurrency control might be needed 🔒. The issues of where these credit card (or similar) databases live, and how they are managed and coordinated, are outside the scope of this document 🙅‍♀️.

Another problem in this scenario is figuring out when the credit runs out. The PDPs should contact the database periodically to submit a charge against CID. If the remaining credit hits zero, there must be a mechanism to detect that and to cause revocation or termination of the privileges that were granted based on the credit 🚨.

As for when charging should start, ideally that should happen only after the reservation request has succeeded ✅. For local charges, the router could communicate that to the PDP.

5.5. Sender Specified Restrictions on Receiver Reservations 📮

Being able to put restrictions on reservations is a big deal for future network apps 🔥. The restrictions could be based on receiver identity, number of receivers, or reservation cost. Picture an app where the sender pays for the service the receivers get. The sender might be totally fine covering the cost of a reservation, as long as it meets certain criteria. For example, it comes from a receiver on an access control list (ACL) and stays under a cost limit 💰. (Notice that this could allow formation of "closed" multicast groups 👀✨.)

In the policy based admission control framework, the sender could generate the right policy objects, carried in a PATH message, which install state in the routers along the path to the receivers 🛤️. When accepting reservations, the routers would have to compare the RESV requests against that installed state.

There are a bunch of different solutions that could be built for this scenario, but a precise description of any one solution is beyond the scope of this document 🙈.

6. Interaction Between the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP) 🤝🌈

When you're using an external PDP, you need a communication protocol between the PEP and the PDP 📡. So that different vendors' networking elements and (external) policy servers can work together, this protocol should be standardized 💜.

6.1. PEP to PDP Protocol Requirements 📋

This section lays out a set of general requirements for the communication protocol between the PEP and an external PDP 💅.

  • Reliability: Policy control information is sensitive, so it needs reliable operation 🔐. If policy queries or responses get lost and nobody notices, network control can end up inconsistent, and that is clearly unacceptable for things like billing and accounting 😱. One option for reliability is to reuse TCP as the transport protocol.
  • Small delays: Policy decisions for QoS signaling protocols have pretty strict timing needs ⏱️. The PEP to PDP protocol should add only a small amount of delay on top of the response delay the PEP already experiences for its queries to the PDP.
  • Ability to carry opaque objects: The protocol should allow delivery of self-identifying, opaque objects of variable length 🧳. Examples are RSVP messages, RSVP policy objects, and other objects that might be defined as new policies come along. The protocol should not have to change every time a new object needs to be exchanged 🙌.
  • Support for PEP-initiated, two-way Transactions: The protocol must allow two-way transactions (request-response exchanges) between a PEP and a PDP 🔁. Specifically, PEPs must be able to initiate requests for a policy decision, renegotiation of a previously made policy decision, and exchange of policy information. This ties pretty closely to meeting the requirements of RSVP-specific, policy-based admission control 🎀. RSVP signaling events like the arrival of RESV refresh messages, state timeout, and merging of reservations mean that a PEP (such as an RSVP router) must be able to request a policy decision from the PDP at any time. Similarly, the PEP must be able to report monitoring information and policy state changes to the PDP at any time 📣.
  • Support for asynchronous notification: This is required so that both the policy server and the client can notify each other about an asynchronous change in state, meaning a change that isn't triggered by a signaling message 🔔. For example, the server would need to notify the client if a reservation has to be terminated because a user's credentials or account balance expired 💸. Likewise, the client has to tell the server about a reservation rejection caused by admission control failure 🙅‍♀️.
  • Handling of multicast groups: The protocol should provision for handling policy decisions related to multicast groups 📻.
  • QoS Specification: The protocol should allow precise specification of the level of service requirements in the PEP requests forwarded to the PDP 🎯.

7. Security Considerations 🔐😭

The communication tunnel between policy clients and policy servers should be secured with an IPSEC [4] channel 🛡️. It is advisable that this tunnel uses both the AH (Authentication Header) and ESP (Encapsulating Security Payload) protocols, so it provides confidentiality, data origin authentication, integrity, and replay prevention. Yes, all four of those matter, so don't skip it 💀.

In the case of the RSVP signaling mechanism, RSVP MD5 [2] message authentication can be used to secure communications between network elements 🧁.

8. References 📚

[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[2] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.

[3] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.

[4] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.

[5] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.

[6] Rajan, R., et al., "Schema for Differentiated Services and Integrated Services in Networks", Work in Progress.

[7] Herzog, S., "RSVP Preemption Priority Policy", Work in Progress.

[8] Herzog, S., "COPS Usage for RSVP", RFC 2749, January 2000.

9. Acknowledgements 🫶

This is a result of an ongoing discussion among many members of the RAP group, including Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, Shai Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry. Y'all are iconic 👑.

10. Authors' Addresses 💌

Raj Yavatkar
Intel Corporation
2111 N.E. 25th Avenue,
Hillsboro, OR 97124
USA

Phone: +1 503-264-9077
EMail: raj.yavatkar@intel.com
Dimitrios Pendarakis
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights
NY 10598

Phone: +1 914-784-7536
EMail: dimitris@watson.ibm.com
Roch Guerin
University of Pennsylvania
Dept. of Electrical Engineering
200 South 33rd Street
Philadelphia, PA  19104

Phone: +1 215 898-9351
EMail: guerin@ee.upenn.edu

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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 💖.

📦 where this page comes from