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:
[email protected].
The list is maintained by Majordomo server, please send a message to
[email protected] 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
