Policy definitions must be simple, understandable and verifiable. For example:
It is important both for what the network send the customer as well as what the customer send the network. Customers can using RSVP to signal the network what traffic to send toward them. Need complementary mechanism for they send into the network.
Current models are limited (mostly static): Set of peering rules agreed to, no charging or accounting, routing control to eliminate transit and closest exist is used as a standard practice.
Should policy be used to correct routing asymmetry? This is not a good idea for certain types of applications and this must be something that can be controlled (removed) as needed. This could affect asymmetries to affect RSVP flow paths, bandwidth differences (like a cable system) or capability differences (telco vs. Cable vs. Satellite).
May negotiate for rates which can be based on many factors:
What is the work going on?
RSVP has two messages
RSVP runs on IP using protocol 46 and is not a routing protocol. It passes transparently though routers that don't support it. The transaction (if successful) creates a soft state reservation for unicast or multicast sessions. It does not cause QoS to happen, but defines a request that the network can respond to as each hop can respond.
RSVP needs policy control and is a convenient signaling mechanism. RSVP can carry policy data to be processed by a "local policy module" to be defined.
The Policy Data can carry a lot of different information (including an integrity object).