| ![]() | |||||||||
6/21/96
3ROLF?&RQWURO
LQLQ
5693
Shai Herzog
USC/
Information Sciences Institute
ftp://ftp.isi.edu/rsvp/draft-ietf-rsvp-policy-XXXX-00.{ps,txt}
XXXX = {arch, lpm, ext}
6/21/96
'RFXPHQW?%UHDNXS
? Motivation
? Break into simpler, cleaner basic components
? Allow parallel efforts by WG
? Documents
? Models/Architecture (-arch-)
? High level policy modeling and examples
? Mechanism/LPM (-lpm-)
? Recommended mechanism
? Provides overview, services description, internal formats
design and processing rules
? RSVP extensions (-ext-)
? Policy components visible to RSVP
? Interface/processing rules
? I-D May merge with the RSVP spec in the future
6/21/96
0RGHOV???$UFKLWHFWXUH
6/21/96
3ROLF?$GPLVVLRQ?&RQWURO
AccountingAccess Control
Policy
Charging FeedbackA ccess
6/21/96
0RGHOVAE?%DVLF?3ULQFLSOHV
? Described in March & Dec. meetings...
? Bilateral agreements
? Between neighboring service providers/consumers
? Motivated by scaling consideration
? Policies are controlled/configured locally
? Could be based on
? Bilateral agreements
? Reservation related Information (credentials etc...)
? Local policies
6/21/96
0HFKDQLVPAE?/30
6/21/96
0HFKDQLVPAE?/30
LPM: common layer
RSVP
Status
Support In / Out
Handler
Handler
1 Handler
2 Handler
3 Handler
4
POLICY_DATA
6/21/96
/RFDO?3ROLF?0RGXOHV?ff/30fi
? Separate Box from RSVP
? Separate internal state
? Linked through handles
? Hooks to RSVP
? POLICY_DATA objects
? Piggy-backed on RSVP msgs
? Define the set of LPM services
? Model: ?Policy based? adm. control
? Policy configuration
? Handlers are the basic building
blocks of policies. Ex:
? Handler1: How much ?
? Handler2: Who is debited ?
? LPM implements policies by dynamically binding handlers
Handler0 Handler2 Handler3 Handler4Handler1
5693
&RPPRQ?/DHU
LPM header
LPM header
RSVP msg
Incoming
RSVP
message
6/21/96
*HQHULF?/30?VHUYLFHV
? lpm_open() Link RSVP to LPM state through fh?s (flow handles)
? lpm_close() Releases an fh and purges its LPM state
? lpm_in() Syntactic processing of incoming POLICY_DATA obj.
? lpm_out() Assemble outgoing POLICY_DATA objects
? lpm_status() Verify the status of a reservation
Optional: debiting for reservations
? lpm_prune() Purge LPM state on a specific ?branch?
? lpm_config() Initialize the LPM policy from local configuration files
6/21/96
3ROLF?$WWULEXWHV
? Format
? Specific formats
? Scoped (local) and unscoped policies
? WG effort
? We expect people to tell us what they need/want
? Where should policies be listed?
? Appendix to LPM document
? Appendix to architecture document
? Fourth document
Length
Ptype Specific format
PType
6/21/96
5693?([WHQVLRQV
6/21/96
3ROLF?2EMHFWV?ff5HVY?PVJfi
Default
handling
Cloud/
Integrity
POLICY_DATA object
Policy_Element Policy_Element
Policy_
Attribute
Policy_
Attribute
Policy_
Attribute
Integrity
Filter_
Spec
list
POLICY_DATA object
Policy_Element
Policy_
Attribute
Filter_
Spec
list POLICY_DATA object
Policy_Element
Policy_
Attribute
Policy_
Attribute
Integrity
Filter_
Spec
list
POLICY_DATA
object Policy_Element
Policy_
Attribute Policy_
Attribute
Integrity
Filter_
Speclist
6/21/96
6HPDQWLF?)UDJPHQWDWLRQ
? Policies are additive in nature
? Fragment to POLICY_ELEMENT level
? State maintenance:
? Individual timers for POLICY_ELEMENTs
? LPM implementation issue
? Example
[H, F, S1, S2, S3, Pe1, I2, Pe2, Pe3]
fi [H, F, S1, S2, Pe1, I2, Pe2, Pe3]
[H, F, S3, Pe1, I2, Pe2, Pe3]
fi [H, F, S1, S2, Pe1, Pe3]
[H, F, S1, S2, I2, Pe2]
[H, F, S3, Pe1, Pe3]
[H, F, S3, I2, Pe2]
6/21/96
1HZ?5693?PHVVDJHAE?5HVY?5HSRUW
ATM
A
CB
Path (multicast)
Report (unicast)
Report Request
bit set
6/21/96
5HVY?5HSRUW?0HVVDJH
? Positive E-2-E policy response
? E.g.: Cost share of a receiver
? Forwarding
? Periodic or triggered refresh
? Unicast, Hop-by-hop, downstream, along reserved
branches
? Optional: Request bit
? Delivered only to branches with bit set
? Refreshes stop when bit is unset
? Free ride...
? E-2-E ack: additional ack bit per incoming interface
6/21/96
(?>=?(?$FNV?RYHU?5HVY?5HSRUW
ATM
GF
Req
Ack
ATM
A
CB
Req
Ack
Ack
Req
Ack
ATM
ED
6/21/96
3ROLF?&RQWURO?,QWHUIDFH?IRU?5693
? Separate POLICY from RSVP
? Do not pass FILTER_SPEC objects (use handles)
? RSVP identifies its ?flows? to policy module
? Policy module shouldn?t know about resv. styles
? RSVP associates source to receiver objects
? Do not store POLICY_DATA objects in RSVP
? Leave local policy processing out of RSVP (e.g. merging)
? Support for state maintenance/synchronization
? Status checks
? Periodic or event driven
? For POLICY_DATA arriving in any message type
? Error processing
6/21/96
$FWLRQ?,WHPV
? Agree on RSVPs extensions:
? Policy objects
? Default handling
? Semantic fragmentation
? Resv Report message (also ack?).
? RSVP/policy interface principles
? Immediate Future Work
? RSVP/policy interface: detailed design
? LPM mechanisms: processing rules
? Hear about policies / other models from the WG
? Where (document) should policy attributes be defined