draft-ietf-rap-signaled-priority-02.txt   draft-ietf-rap-signaled-priority-03.txt 
Internet Draft Shai Herzog Internet Draft Shai Herzog
Expiration: August 1999 IPHighway Expiration: August 1999 IPHighway
File: draft-ietf-rap-signaled-priority-02.txt File: draft-ietf-rap-signaled-priority-03.txt
Signaled Preemption Priority Policy Element Signaled Preemption Priority Policy Element
February 13, 1999 February 26, 1999
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
2 Scope and Applicability............................................3 2 Scope and Applicability............................................3
3 Stateless Policy...................................................4 3 Stateless Policy...................................................4
4 Policy Element Format..............................................4 4 Policy Element Format..............................................4
5 Priority Merging Issues............................................6 5 Priority Merging Issues............................................6
5.1 Priority Merging Strategies.....................................7 5.1 Priority Merging Strategies.....................................7
5.1.1 Take priority of highest QoS...................................7 5.1.1 Take priority of highest QoS...................................7
5.1.2 Take highest priority..........................................7 5.1.2 Take highest priority..........................................7
5.1.3 Force error on heterogeneous merge.............................8 5.1.3 Force error on heterogeneous merge.............................8
5.2 Modifying Priority Elements.....................................8 5.2 Modifying Priority Elements.....................................8
6 Error Processing...................................................9 6 Error Processing...................................................9
7 Security Considerations............................................9 7 IANA Considerations................................................9
8 References........................................................10 8 Security Considerations............................................9
9 Author Information................................................10 9 References........................................................10
10 Author Information..............................................10
Appendix A: Example.................................................11 Appendix A: Example.................................................11
A.1 Computing Merged Priority......................................11 A.1 Computing Merged Priority......................................11
A.2 Translation (Compression) of Priority Elements.................11 A.2 Translation (Compression) of Priority Elements.................11
1 Introduction 1 Introduction
Traditional Capacity based Admission Control (CAC) indiscriminately Traditional Capacity based Admission Control (CAC) indiscriminately
admits new flows until capacity is exhausted (First Come First admits new flows until capacity is exhausted (First Come First
Admitted). Policy based Admission Control (PAC) on the other hand Admitted). Policy based Admission Control (PAC) on the other hand
attempts to minimize the significance of order of arrival and use attempts to minimize the significance of order of arrival and use
skipping to change at page 3, line 35 skipping to change at page 3, line 35
This document describes the format and applicability of the This document describes the format and applicability of the
preemption priority represented as a policy element in [RSVP-EXT]. preemption priority represented as a policy element in [RSVP-EXT].
2 Scope and Applicability 2 Scope and Applicability
The Framework document for policy-based admission control [RAP] The Framework document for policy-based admission control [RAP]
describes the various components that participate in policy decision describes the various components that participate in policy decision
making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI
elements is to be simple, stateless, and light-weight such that they elements is to be simple, stateless, and light-weight such that they
could be implemented internally within a nodes LDP (Local Decision could be implemented internally within a node's LDP (Local Decision
Point). Point).
Certain base assumptions are made in the usage model for Certain base assumptions are made in the usage model for
PREEMPTION_PRI elements: PREEMPTION_PRI elements:
- They are created by PDPs - They are created by PDPs
In a model where PDPs control PEPs at the periphery of the policy In a model where PDPs control PEPs at the periphery of the policy
domain (e.g., in border routers), PDPs reduce sets of relevant domain (e.g., in border routers), PDPs reduce sets of relevant
policy rules into a single priority criterion. This priority as policy rules into a single priority criterion. This priority as
skipping to change at page 4, line 17 skipping to change at page 4, line 17
PREEMPTION_PRI elements are processed by LDPs of nodes that do not PREEMPTION_PRI elements are processed by LDPs of nodes that do not
have a controlling PDP. LDPs may interpret these objects, forward have a controlling PDP. LDPs may interpret these objects, forward
them as is, or perform local merging to forward an equivalent them as is, or perform local merging to forward an equivalent
merged PREEMPTION_PRI policy element. LDPs must follow the merging merged PREEMPTION_PRI policy element. LDPs must follow the merging
strategy that was encoded by PDPs in the PREEMPTION_PRI objects. strategy that was encoded by PDPs in the PREEMPTION_PRI objects.
(Clearly, a PDP, being a superset of LDP, may act as an LDP as (Clearly, a PDP, being a superset of LDP, may act as an LDP as
well). well).
- They are enforced by PEPs - They are enforced by PEPs
PREEMPTION_PRI elements interact with a nodes traffic control PREEMPTION_PRI elements interact with a node's traffic control
module (and capacity admission control) to enforce priorities, and module (and capacity admission control) to enforce priorities, and
preempt previously admitted flows when the need arises. preempt previously admitted flows when the need arises.
3 Stateless Policy 3 Stateless Policy
Signaled Preemption Priority is stateless (does not require past Signaled Preemption Priority is stateless (does not require past
history or external information to be interpreted). Therefore, when history or external information to be interpreted). Therefore, when
carried in COPS messages for the outsourcing of policy decisions, carried in COPS messages for the outsourcing of policy decisions,
these objects are included as COPS Stateless Policy Data Decision these objects are included as COPS Stateless Policy Data Decision
objects (see [COSP, COPS-RSVP]). objects (see [COSP, COPS-RSVP]).
skipping to change at page 5, line 11 skipping to change at page 5, line 11
+------+------+-------------+-------------+-------------+ +------+------+-------------+-------------+-------------+
| Preemption Priority | Defending Priority | | Preemption Priority | Defending Priority |
+------+------+-------------+-------------+-------------+ +------+------+-------------+-------------+-------------+
Length: 16 bits Length: 16 bits
Always 12. The overall length of the policy element, in bytes. Always 12. The overall length of the policy element, in bytes.
P-Type: 16 bits P-Type: 16 bits
PREEMPTION_PRI = 1 PREEMPTION_PRI = 1
The preemption priority policy element number was assigned by IANA
as defined in [RSVP-EXT].
Flags: 8 bits Flags: 8 bits
Reserved (always 0). Reserved (always 0).
Merge Strategy: 8 bit Merge Strategy: 8 bit
1 Take priority of highest QoS: recommended 1 Take priority of highest QoS: recommended
2 Take highest priority: aggressive 2 Take highest priority: aggressive
3 Force Error on heterogeneous merge 3 Force Error on heterogeneous merge
skipping to change at page 6, line 24 skipping to change at page 6, line 22
F1+F2= F3: QoS=High, Priority=??? F1+F2= F3: QoS=High, Priority=???
The merged reservation F3 should have QoS=Hi, but what Priority The merged reservation F3 should have QoS=Hi, but what Priority
should it assume? Several negative side-effects have been identified should it assume? Several negative side-effects have been identified
that may affect such a merger: that may affect such a merger:
Free-Riders: Free-Riders:
If F3 assumes Priority=High, then F1 got a free ride, assuming high If F3 assumes Priority=High, then F1 got a free ride, assuming high
priority that was only intended to the low QoS F2. If one associates priority that was only intended to the low QoS F2. If one associates
costs as a function of QoS and priority, F1 receives an “expensive” costs as a function of QoS and priority, F1 receives an "expensive"
priority without having to “pay” for it. priority without having to "pay" for it.
Denial of Service: Denial of Service:
If F3 assumes Priority=Low, the merged flow could be preempted or If F3 assumes Priority=Low, the merged flow could be preempted or
fail even though F2 presented high priority. fail even though F2 presented high priority.
Denial of service is virtually the inverse of the free-rider Denial of service is virtually the inverse of the free-rider
problem. When flows compete for resources, if one flow receives problem. When flows compete for resources, if one flow receives
undeserving high priority it may be able to preempt another undeserving high priority it may be able to preempt another
deserving flow (hence one free-rider turns out to be anothers deserving flow (hence one free-rider turns out to be another's
denial of service). denial of service).
Instability: Instability:
The combination of preemption priority, killer reservation and The combination of preemption priority, killer reservation and
blockade state [RSVP] may increase the instability of admitted flows blockade state [RSVP] may increase the instability of admitted flows
where a reservation may be preempted, reinstated, and preempted where a reservation may be preempted, reinstated, and preempted
again periodically. again periodically.
.1 Priority Merging Strategies .1 Priority Merging Strategies
skipping to change at page 8, line 25 skipping to change at page 8, line 25
This strategy lends itself to denial of service, when a single This strategy lends itself to denial of service, when a single
receiver specifying a non-compatible QoS level may cause denial of receiver specifying a non-compatible QoS level may cause denial of
service for all other receivers of the merged reservation. service for all other receivers of the merged reservation.
Note: The determination of heterogeneous flows applies to QoS level Note: The determination of heterogeneous flows applies to QoS level
only (FLOWSPEC values), and is a matter for local (LDP) definition. only (FLOWSPEC values), and is a matter for local (LDP) definition.
Other types of heterogeneous reservations (e.g. conflicting Other types of heterogeneous reservations (e.g. conflicting
reservation styles) are handled by RSVP and are unrelated to this reservation styles) are handled by RSVP and are unrelated to this
PREEMPTION_PRI element. PREEMPTION_PRI element.
This is a recommended merging strategy when reservation homogeneity
is coordinated and enforced for the entire multicast tree. It is
more restrictive than Section 5.1.1, but is easier to implement.
.2 Modifying Priority Elements .2 Modifying Priority Elements
When POLICY_DATA objects are protected by integrity, LDPs should not When POLICY_DATA objects are protected by integrity, LDPs should not
attempt to modify them. They must be forwarded as-is or else their attempt to modify them. They must be forwarded as-is or else their
security envelope would be invalidated. In other cases, LDPs may security envelope would be invalidated. In other cases, LDPs may
modify and merge incoming PREEMPTION_PRI elements to reduce their modify and merge incoming PREEMPTION_PRI elements to reduce their
size and number according to the following rule: size and number according to the following rule:
- Merging is performed for each merging strategy separately. - Merging is performed for each merging strategy separately.
skipping to change at page 9, line 13 skipping to change at page 9, line 13
example in Appendix A.2). example in Appendix A.2).
6 Error Processing 6 Error Processing
A PREEMPTION_PRI error object is sent back toward the appropriate A PREEMPTION_PRI error object is sent back toward the appropriate
receivers when an error involving PREEMPTION_PRI elements occur. receivers when an error involving PREEMPTION_PRI elements occur.
PREEMPTION PREEMPTION
When a previously admitted flow is preempted, a copy of the When a previously admitted flow is preempted, a copy of the
preempting flows PREEMPTION_PRI element is sent back toward the PDP preempting flow's PREEMPTION_PRI element is sent back toward the PDP
that originated the preempted PREEMPTION_PRI object. This PDP, that originated the preempted PREEMPTION_PRI object. This PDP,
having information on both the preempting and the preempted having information on both the preempting and the preempted
priorities may construct a higher priority PREEMPTION_PRI element in priorities may construct a higher priority PREEMPTION_PRI element in
an effort to re-instate the preempted flow. an effort to re-instate the preempted flow.
Heterogeneity Heterogeneity
When a flow F1 with Heterogeneous Error merging strategy set in its When a flow F1 with Heterogeneous Error merging strategy set in its
PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI
element is sent back toward receivers with the Heterogeneity error element is sent back toward receivers with the Heterogeneity error
code set. code set.
7 Security Considerations 7 IANA Considerations
RSVP Policy Data object P-type values are assigned by IANA, as
described in [RSVP-EXT].
The values for inclusion in the other protocol data fields defined
in this memo are assigned by IETF Consensus action, as defined in
[IANA-CONSIDERATIONS]."
8 Security Considerations
The integrity of PREEMPTION_PRI is guaranteed, as any other policy The integrity of PREEMPTION_PRI is guaranteed, as any other policy
element, by the encapsulation into a Policy Data object [RSVP-EXT]. element, by the encapsulation into a Policy Data object [RSVP-EXT].
Further security mechanisms are not warranted, especially Further security mechanisms are not warranted, especially
considering that preemption priority aims to provide simple and considering that preemption priority aims to provide simple and
quick guidance to routers within a trusted zone or at least a single quick guidance to routers within a trusted zone or at least a single
zone (no zone boundaries are crossed). zone (no zone boundaries are crossed).
8 References 9 References
[RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control",
Internet-Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999. Internet-Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999.
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n
R., Sastry, A., “COPS usage for RSVP” Internet-Draft, draft- R., Sastry, A., "COPS usage for RSVP" Internet-Draft, draft-
ietf-rap-cops-rsvp-02.txt, Jan 1999. ietf-rap-cops-rsvp-02.txt, Jan 1999.
[RAP] Yavatkar, R., et al., "A Framework for Policy Based [RAP] Yavatkar, R., et al., "A Framework for Policy Based
Admission Control",IETF <draft-ietf-rap-framework-02.txt>, Admission Control",IETF <draft-ietf-rap-framework-02.txt>,
Jan., 1999. Jan., 1999.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R.,
Sastry, A., "The COPS (Common Open Policy Service) Protocol", Sastry, A., "The COPS (Common Open Policy Service) Protocol",
IETF <draft-ietf-rap-cops-05.txt>, Jan. 1999. IETF <draft-ietf-rap-cops-05.txt>, Jan. 1999.
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205, Proposed Standard, Functional Specification.", IETF RFC 2205, Proposed Standard,
Sep. 1997. Sep. 1997.
9 Author Information [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", RFC 2434,
October 1998.
10 Author Information
Shai Herzog, IPHighway Shai Herzog, IPHighway
Parker Plaza, Suite 1500 Parker Plaza, Suite 1500
400 Kelby St. 400 Kelby St.
Fort-Lee, NJ 07024 Fort-Lee, NJ 07024
(201) 585-0800 (201) 585-0800
herzog@iphighway.com herzog@iphighway.com
Appendix A: Example Appendix A: Example
skipping to change at page 11, line 30 skipping to change at page 11, line 30
QoS=Low (Pr=9, St=Error) QoS=Low (Pr=9, St=Error)
Example 1: Merging preemption priority elements Example 1: Merging preemption priority elements
Example one describes a multicast scenario with one sender and four Example one describes a multicast scenario with one sender and four
receivers each with each own PREEMPTION_PRI element definition. receivers each with each own PREEMPTION_PRI element definition.
r1, r2 and r3 merge in B. The resulting priority is 4. r1, r2 and r3 merge in B. The resulting priority is 4.
Reason: The PREEMPTION_PRI of r3 doesnt participate (since r3 is Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is
not contributing to the merged QoS) and the priority is the highest not contributing to the merged QoS) and the priority is the highest
of the PREEMPTION_PRI from r1 and r2. of the PREEMPTION_PRI from r1 and r2.
r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4
doesnt participate because its own QoS=Low is incompatible with the doesn't participate because its own QoS=Low is incompatible with the
other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to
r4 telling it that its PREEMPTION_PRI element encountered r4 telling it that its PREEMPTION_PRI element encountered
heterogeneity. heterogeneity.
A.2 Translation (Compression) of Priority Elements A.2 Translation (Compression) of Priority Elements
Given this set of participating PREEMPTION_PRI elements, the Given this set of participating PREEMPTION_PRI elements, the
following compression can take place at the merging node: following compression can take place at the merging node:
From: From:
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/