Editor's note: These minutes have not been edited. San Jose IETF Meeting Proceedings Transport Service Area IPC BOF Minutes of the Internet Policy Control (IPC) discussion and RSVP Policy BOF Reported by: Shai Herzog/IBM T.J. Watson Research Center Agenda - Monday 12/9/96 Session: Min. o BOF Introduction and Overview 5 o PART I (RSVP Extensions) - RSVP Extensions for P.C. 25 - Extensions Discussion 10 o PART II (IPC) - Some service providers’ Perspective on IPC 25 Laura Cunningham (MCI) Tim O’Malley (BBN Planet) - Open-Ended Discussion 20 o Future agendas and conclusion (S. Herzog) 5 o Administrative issues: Mailing list: ipc@watson.ibm.com. The list is maintained by Majordomo server, please send a message to majordomo@watson.ibm.com with the line "subscribe ipc" in it. Due to the holidays, this list is not fully operational. Sending email to ipc or ipc-request would not currently work, but you can subscribe and unsubscribe to the list. FTP Site : TBD Home Page: TBD o BOF Introduction and Overview. Shai Herzog stated the motivation and goals for the BOF at this IETF: New integrated services protocols (like RSVP) provide service differentiation for traffic of different user groups. This family of protocols depend on mechanisms for controlling and enforcing usage policies, especially when users are allowed select their desired QoS. The term "Policy" has many meanings and much potential range, from administrative restrictions (on access, QoS, etc.) up to sophisticated accounting and pricing strategies. There is a wide consensus that policy control is a high priority item for RSVP, however, some of the higher level issues regarding models, architecture and specific policies are considered outside the scope of the IETF; they investigate unresolved research issues and touch on business models. The IPC was a one-time BOF with two main goals: (1) Provide a prompt solution for extending RSVP to support policy control. The purpose of these extensions is to ensure inter- operability in multi-vendor environments while providing an initial vehicle for experimentation and development of internet policies. This work would be developed within the RSVP WG. (2) Establish a coherent IPC model, architecture, and a set of common, globally adequate policies. This track would be carried out by an IPC RG, in close coordination with the RSVP WG. o PART I (RSVP Extensions) Shai Herzog presented the latest version of the RSVP extension draft: The proliferation of infrastructure and scalability considerations lean toward distributed policy control that is based on bilateral agreements between neighbors. Policies are controlled and configured locally, however, it is important to have inter-operability both between equipment made by different vendors and between administrative domains (service providers). This inter-operability depend on standardization of the following components: - Format of Policy Data Objects o Built from objects for flexibility and future extendibility. o Internal Policy Elements are opaque to RSVP and are known only to the P.C. module. (*) It was suggested to examine ways to prevent FilterSpec duplication (both in the RSVP message and the P.D. object). - Functional interface between RSVP and P.C. modules Shai described the interface proposed in the rsvp extension I-D. (*) It was agreed that the interface should include the following requirements: ((1) RSVP should not act on a control message before policy processing is complete (2) RSVP should not block while waiting for a policy decision (3) There should be a way for a change in policy to be communicated to RSVP instantaneously (not waiting for the next refresh period). - Router/Policy Server interface (*) The RSVP/IntServ MIB defines hooks for policy. Is that a sufficient and the appropriate mechanism? (*) The BOF voted for standardizing this interface. However, it may require initial work carried out by the IPC RG. - Common semantics/processing rules Security, errors, default handling, fragmentation, etc. (*) The RSVP WG voted to delay fragmentation handling until it is proven that P.D. objects are indeed a problem for RSVP. The fragmentation solution detailed in the draft is to be put on hold. The BOF reached consensus for finalizing the set of RSVP extensions before the next IETF. A new draft should be prepared incorporating the BOF feedback, and distributed to the mailing list. o PART II (IPC) The second half of the BOF, included presentations of some service providers’ Perspective on IPC: Laura Cunningham (MCI): Policy in today's backbone networks is typically statically configured based on an individual customer's requirements. It mainly consists of routing policy to control information flow. It is very important with the volume of backbone traffic and load on backbone routers, that whatever policy be simple to explain, implement, and operate. An ISP has two main types of customers with different requirements. End customers typically purchase service based on a per port basis. They may indicate different treatment for different flows, but from a near-term ISP perspective the aggregate of smaller flows would be policed to a higher-level, static usage profile. For other ISPs, a set of peering rules would be agreed to, with access and transit controlled through routing. For either type of customer, it is important that policy allow control both for what the network sends the customer as well as what the customer sends the network. RSVP offers a clear mechanism for the former, a complementary mechanism is needed for the latter. In the longer term, there is an interest in more extensive and dynamic policy mechanisms to control such things as quality of service, resource access, and path selection. A policy object within RSVP could be used for negotiating such issues, and the dynamic mechanism would greatly expand customer control. As the basis for establishing policy, bilateral agreements between peers offer the most straightforward option, but this may not be sufficient in cases where credentials or policy requires information to be passed across more than one network. There are many open issues with determining how such policy mechanisms would be used. Customer concerns with control, information privacy, and communication cost stability must be considered, and alternate approaches for accomplishing similar objectives through routing are possible. Tim O’Malley (BBN Planet): Policy data objects contain tokens that may identify payment sources. They can represent a particular a finite amount of QoS, (analogous to prepaid phonecards), but can also represent a customer account (analogous to standard (credit) phone cards). These tokens must enable RSVP to support several basic forms of agreements: neighbor to neighbor (between ISPs), wholesaler and retailer, Customer to ISP, and none (cash based transactions). Several billing paradigms must be supported, sender pays, receiver pays, multicast cost sharing between receivers and multicast unit- cost. ISPs control access to their network resources. Based on customer agreements and account status, they may decide to honor the QoS request, Deny it or terminate an already admitted (active) flow. An ISP may wish to restrict specific parameters of the QoS request (maximum BW, etc.). We must not forget that (1) There is a relationship between policy and routing, for example, a user may provide a token for particular ISP X, should we route its packets accordingly? (2) We should be careful in trusting spoofable fields like the source IP address in policy decisions, and (3) we must make sure that we won't have to re-do our policy decisions on every reservation refresh. IPC, Open-Ended Discussion (summary, Q&A style): Q: Do we believe in a need for more than a single policy, which is provide service for the highest bidder ? Wouldn't that cause users with lower buying power to be denied service? A: There is a consensus that there is a need for several basic policies some that involve service for payments (either through auction or other pricing schemes), but others that provide administrative access control, advanced reservations, etc. Selling service for the higher bidder is yet another possible option. It is suggested that in a free economic system, there would always be markets tailored to the needs of all of customers. However, this issue has more to do with economic models than networking. Q: What about policies for non-reserved traffic? IPSs are worried about non-QoS traffic control perhaps even more! A: RSVP is merely a first step, where the signaling protocol is (relatively) well defined, and the benefits of having an initial experimental vehicle are clear and immediate. However, the RG should revisit this question as one of its first agenda items. Q: The Ext document describes extensions to RSVP for a specific session, however, it does not describe the long term, non session specific policy distribution protocol. This is a missing component. A: Yes. The Ext document assumes that long-term policies are already in place when a new session is initiated. The way by which these long-term were set is a local issue: it could have been set by local configuration (language), through SNMP, or even in a policy server protocol (between policy servers). Clearly, this component is required to make policy work, however, it is not specifically related to RSVP and its extensions. This is an agenda item for the RG. o Near-future agenda - Establish mailing list, web site, etc. - Finalize the RSVP Extensions I-D, incorporating BOF and email feedback. We shoot for submitting it for last call at the next IETF RSVP WG meeting. - Propose a charter for the IRTF RG: As a first cut, we need to discuss the following issues: o The definition and scope of what we are interested in exploring as "policy". What are the goals of policy control? o Identify a list of policy issues that should be explored in the RG, from simple to unresolved research issues. o Prioritize this list of policy issues. o Identify work that is currently carried out or proposed by individual interested parties to ensure inter-operability and consistency. The discussion should probably be carried out over the mailing list. We need to hear the view, priorities, and proposals from the different parties like actual consumers, service providers, vendors, system administrators, and researchers. - Begin working through the list of policy issues according to the priority set by the on-line discussions. Shai