draft-ietf-rap-signaled-priority-03.txt   rfc2751.txt 
Internet Draft Shai Herzog Network Working Group S. Herzog
Expiration: August 1999 IPHighway Request for Comments: 2751 IPHighway
File: draft-ietf-rap-signaled-priority-03.txt Category: Standards Track January 2000
Signaled Preemption Priority Policy Element Signaled Preemption Priority Policy Element
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 specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes a preemption priority policy element for use This document describes a preemption priority policy element for use
by signaled policy based admission protocols (such as [RSVP] and by signaled policy based admission protocols (such as [RSVP] and
[COPS]). [COPS]).
Preemption priority defines a relative importance (rank) within the
set of flows competing to be admitted into the network. Rather than
admitting flows by order of arrival (First Come First Admitted)
network nodes may consider priorities to preempt some previously
admitted low priority flows in order to make room for a newer, high-
priority flow.
Internet Draft Signaled Preemption Priority Policy 26-Feb-99 Preemption priority defines a relative importance (rank) within the
set of flows competing to be admitted into the network. Rather than
admitting flows by order of arrival (First Come First Admitted)
network nodes may consider priorities to preempt some previously
admitted low priority flows in order to make room for a newer, high-
priority flow.
Table of Contents Table of Contents
Abstract.............................................................1 1 Introduction .....................................................2
Table of Contents....................................................2 2 Scope and Applicability ..........................................3
1 Introduction.......................................................3 3 Stateless Policy .................................................3
2 Scope and Applicability............................................3 4 Policy Element Format ............................................4
3 Stateless Policy...................................................4 5 Priority Merging Issues ..........................................5
4 Policy Element Format..............................................4 5.1 Priority Merging Strategies ...................................6
5 Priority Merging Issues............................................6 5.1.1 Take priority of highest QoS .................................6
5.1 Priority Merging Strategies.....................................7 5.1.2 Take highest priority ........................................7
5.1.1 Take priority of highest QoS...................................7 5.1.3 Force error on heterogeneous merge ...........................7
5.1.2 Take highest priority..........................................7 5.2 Modifying Priority Elements ...................................7
5.1.3 Force error on heterogeneous merge.............................8 6 Error Processing .................................................8
5.2 Modifying Priority Elements.....................................8 7 IANA Considerations ..............................................8
6 Error Processing...................................................9 8 Security Considerations ..........................................8
7 IANA Considerations................................................9 9 References .......................................................9
8 Security Considerations............................................9 10 Author Information .............................................9
9 References........................................................10 Appendix A: Example ...............................................10
10 Author Information..............................................10 A.1 Computing Merged Priority ....................................10
Appendix A: Example.................................................11 A.2 Translation (Compression) of Priority Elements ...............11
A.1 Computing Merged Priority......................................11 Full Copyright Statement ..........................................12
A.2 Translation (Compression) of Priority Elements.................11
Internet Draft Signaled Preemption Priority Policy 26-Feb-99
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
policy based admission criteria instead. policy based admission criteria instead.
One of the more popular policy criteria is the rank of importance of One of the more popular policy criteria is the rank of importance of
a flow relative to the others competing for admission into a network a flow relative to the others competing for admission into a network
node. Preemption Priority takes effect only when a set of flows node. Preemption Priority takes effect only when a set of flows
attempting admission through a node represents overbooking of attempting admission through a node represents overbooking of
resources such that based on CAC some would have to be rejected. resources such that based on CAC some would have to be rejected.
Preemption priority criteria help the node select the most important Preemption priority criteria help the node select the most important
flows (highest priority) for admission, while rejecting the low flows (highest priority) for admission, while rejecting the low
priority ones. priority ones.
Network nodes which support preemption should consider priorities to Network nodes which support preemption should consider priorities to
preempt some previously admitted low-priority flows in order to make preempt some previously admitted low-priority flows in order to make
room for a newer, high-priority flow. room for a newer, high-priority flow.
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 node's 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
PREEMPTION_PRI elements:
- They are created by PDPs Certain base assumptions are made in the usage model for
PREEMPTION_PRI elements:
In a model where PDPs control PEPs at the periphery of the policy - They are created by PDPs
domain (e.g., in border routers), PDPs reduce sets of relevant
policy rules into a single priority criterion. This priority as
expressed in the PREEMPTION_PRI element can then be communicated
to downstream PEPs of the same policy domain, which have LDPs but
no controlling PDP.
Internet Draft Signaled Preemption Priority Policy 26-Feb-99 In a model where PDPs control PEPs at the periphery of the policy
domain (e.g., in border routers), PDPs reduce sets of relevant
policy rules into a single priority criterion. This priority as
expressed in the PREEMPTION_PRI element can then be communicated
to downstream PEPs of the same policy domain, which have LDPs but
no controlling PDP.
- They can be processed by LDPs - They can be processed by LDPs
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 node's 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]).
4 Policy Element Format 4 Policy Element Format
The format of Policy Data objects is defined in [RSVP-EXT]. A single The format of Policy Data objects is defined in [RSVP-EXT]. A single
Policy Data object may contain one or more policy elements, each Policy Data object may contain one or more policy elements, each
representing a different (and perhaps orthogonal) policy. representing a different (and perhaps orthogonal) policy.
The format of preemption priority policy element is as follows:
+-------------+-------------+-------------+-------------+
| Length (12) | P-Type = PREEMPTION_PRI |
+------+------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved(0) |
+------+------+-------------+-------------+-------------+
| Preemption Priority | Defending Priority |
+------+------+-------------+-------------+-------------+
Internet Draft Signaled Preemption Priority Policy 26-Feb-99
Length: 16 bits
Always 12. The overall length of the policy element, in bytes.
P-Type: 16 bits
PREEMPTION_PRI = 1
Flags: 8 bits
Reserved (always 0).
Merge Strategy: 8 bit
1 Take priority of highest QoS: recommended The format of preemption priority policy element is as follows:
2 Take highest priority: aggressive
3 Force Error on heterogeneous merge
Reserved: 8 bits +-------------+-------------+-------------+-------------+
| Length (12) | P-Type = PREEMPTION_PRI |
+------+------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved(0) |
+------+------+-------------+-------------+-------------+
| Preemption Priority | Defending Priority |
+------+------+-------------+-------------+-------------+
Error code: 8 bits Length: 16 bits
Always 12. The overall length of the policy element, in bytes.
0 NO_ERROR Value used for regular PREEMPTION_PRI elements P-Type: 16 bits
1 PREEMPTION This previously admitted flow was preempted PREEMPTION_PRI = 3
2 HETEROGENEOUS This element encountered heterogeneous merge
Reserved: 8 bits This value is registered with IANA, see Section 7.
Always 0. Flags: 8 bits
Reserved (always 0).
Preemption Priority: 16 bit (unsigned) Merge Strategy: 8 bit
1 Take priority of highest QoS: recommended
2 Take highest priority: aggressive
3 Force Error on heterogeneous merge
The priority of the new flow compared with the defending priority Reserved: 8 bits
of previously admitted flows. Higher values represent higher Error code: 8 bits
Priority. 0 NO_ERROR Value used for regular PREEMPTION_PRI elements
1 PREEMPTION This previously admitted flow was preempted
2 HETEROGENEOUS This element encountered heterogeneous merge
Defending Priority: 16 bits (unsigned) Reserved: 8 bits
Always 0.
Once a flow was admitted, the preemption priority becomes Preemption Priority: 16 bit (unsigned)
irrelevant. Instead, its defending priority is used to compare The priority of the new flow compared with the defending priority
with the preemption priority of new flows. of previously admitted flows. Higher values represent higher
Priority.
For any specific flow, its preemption priority must always be less Defending Priority: 16 bits (unsigned)
than or equal to the defending priority. A wide gap between Once a flow was admitted, the preemption priority becomes
preemption and defending priority provides added stability: irrelevant. Instead, its defending priority is used to compare
moderate preemption priority makes it harder for a flow to preempt with the preemption priority of new flows.
others, but once it succeeded, the higher defending priority makes
it easier for the flow to avoid preemption itself. This provides a
mechanism for balancing between order dependency and priority.
Internet Draft Signaled Preemption Priority Policy 26-Feb-99 For any specific flow, its preemption priority must always be less
than or equal to the defending priority. A wide gap between
preemption and defending priority provides added stability: moderate
preemption priority makes it harder for a flow to preempt others, but
once it succeeded, the higher defending priority makes it easier for
the flow to avoid preemption itself. This provides a mechanism for
balancing between order dependency and priority.
5 Priority Merging Issues 5 Priority Merging Issues
Consider the case where two RSVP reservations merge: Consider the case where two RSVP reservations merge:
F1: QoS=High, Priority=Low
F2: QoS=Low, Priority=High
F1+F2= F3: QoS=High, Priority=???
The merged reservation F3 should have QoS=Hi, but what Priority
should it assume? Several negative side-effects have been identified
that may affect such a merger:
Free-Riders: F1: QoS=High, Priority=Low
F2: QoS=Low, Priority=High
If F3 assumes Priority=High, then F1 got a free ride, assuming high F1+F2= F3: QoS=High, Priority=???
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"
priority without having to "pay" for it.
Denial of Service: The merged reservation F3 should have QoS=Hi, but what Priority
should it assume? Several negative side-effects have been identified
that may affect such a merger:
If F3 assumes Priority=Low, the merged flow could be preempted or Free-Riders:
fail even though F2 presented high priority.
Denial of service is virtually the inverse of the free-rider If F3 assumes Priority=High, then F1 got a free ride, assuming high
problem. When flows compete for resources, if one flow receives priority that was only intended to the low QoS F2. If one associates
undeserving high priority it may be able to preempt another costs as a function of QoS and priority, F1 receives an "expensive"
deserving flow (hence one free-rider turns out to be another's priority without having to "pay" for it.
denial of service).
Instability: Denial of Service:
The combination of preemption priority, killer reservation and If F3 assumes Priority=Low, the merged flow could be preempted or
blockade state [RSVP] may increase the instability of admitted flows fail even though F2 presented high priority.
where a reservation may be preempted, reinstated, and preempted
again periodically.
Internet Draft Signaled Preemption Priority Policy 26-Feb-99 Denial of service is virtually the inverse of the free-rider problem.
When flows compete for resources, if one flow receives undeserving
high priority it may be able to preempt another deserving flow (hence
one free-rider turns out to be another's denial of service).
.1 Priority Merging Strategies Instability:
In merging situations LDPs may receive multiple preemption elements The combination of preemption priority, killer reservation and
and must compute the priority of the merged flow according to the blockade state [RSVP] may increase the instability of admitted flows
following rules: where a reservation may be preempted, reinstated, and preempted again
periodically.
a. Preemption priority and defending priority are merged and 5.1 Priority Merging Strategies
computed separately, irrespective of each other.
b. Participating priority elements are selected. In merging situations LDPs may receive multiple preemption elements
and must compute the priority of the merged flow according to the
following rules:
All priority elements are examined according to their merging a. Preemption priority and defending priority are merged and computed
strategy to decide whether they should participate in the merged separately, irrespective of each other.
result (as specified bellow).
c. The highest priority of all participating priority elements is b. Participating priority elements are selected.
computed.
The remainder of this section describes the different merging All priority elements are examined according to their merging
strategies the can be specified in the PREEMPTION_PRI element. strategy to decide whether they should participate in the merged
result (as specified bellow).
1.1 Take priority of highest QoS c. The highest priority of all participating priority elements is
computed.
The PREEMPTION_PRI element would participate in the merged The remainder of this section describes the different merging
reservation only if it belongs to a flow that contributed to the strategies the can be specified in the PREEMPTION_PRI element.
merged QoS level (i.e., that its QoS requirement does not constitute
a subset another reservation.)
A simple way to determine whether a flow contributed to the merged
QoS result is to compute the merged QoS with and without it and to
compare the results (although this is clearly not the most efficient
method).
The reasoning for this approach is that the highest QoS flow is the 5.1.1 Take priority of highest QoS
one dominating the merged reservation and as such its priority
should dominate it as well. This approach is the most amiable to the
prevention of priority distortions such as free-riders and denial of
service.
This is a recommended merging strategy. The PREEMPTION_PRI element would participate in the merged
reservation only if it belongs to a flow that contributed to the
merged QoS level (i.e., that its QoS requirement does not constitute
a subset another reservation.) A simple way to determine whether a
flow contributed to the merged QoS result is to compute the merged
QoS with and without it and to compare the results (although this is
clearly not the most efficient method).
1.2 Take highest priority The reasoning for this approach is that the highest QoS flow is the
one dominating the merged reservation and as such its priority should
dominate it as well. This approach is the most amiable to the
prevention of priority distortions such as free-riders and denial of
service.
All PREEMPTION_PRI elements participate in the merged reservation. This is a recommended merging strategy.
This strategy disassociates priority and QoS level, and therefore is 5.1.2 Take highest priority
highly subject to free-riders and its inverse image, denial of
service.
This is not a recommended method, but may be simpler to implement. All PREEMPTION_PRI elements participate in the merged reservation.
Internet Draft Signaled Preemption Priority Policy 26-Feb-99 This strategy disassociates priority and QoS level, and therefore is
highly subject to free-riders and its inverse image, denial of
service.
1.3 Force error on heterogeneous merge This is not a recommended method, but may be simpler to implement.
A PREEMPTION_PRI element may participate in a merged reservation 5.1.3 Force error on heterogeneous merge
only if all other flows in the merged reservation have the same QoS
level (homogeneous flows).
The reasoning for this approach assumes that the heterogeneous case A PREEMPTION_PRI element may participate in a merged reservation only
is relatively rare and too complicated to deal with, thus it better if all other flows in the merged reservation have the same QoS level
be prohibited. (homogeneous flows).
This strategy lends itself to denial of service, when a single The reasoning for this approach assumes that the heterogeneous case
receiver specifying a non-compatible QoS level may cause denial of is relatively rare and too complicated to deal with, thus it better
service for all other receivers of the merged reservation. be prohibited.
Note: The determination of heterogeneous flows applies to QoS level This strategy lends itself to denial of service, when a single
only (FLOWSPEC values), and is a matter for local (LDP) definition. receiver specifying a non-compatible QoS level may cause denial of
Other types of heterogeneous reservations (e.g. conflicting service for all other receivers of the merged reservation.
reservation styles) are handled by RSVP and are unrelated to this
PREEMPTION_PRI element.
This is a recommended merging strategy when reservation homogeneity Note: The determination of heterogeneous flows applies to QoS level
is coordinated and enforced for the entire multicast tree. It is only (FLOWSPEC values), and is a matter for local (LDP) definition.
more restrictive than Section 5.1.1, but is easier to implement. Other types of heterogeneous reservations (e.g. conflicting
reservation styles) are handled by RSVP and are unrelated to this
PREEMPTION_PRI element.
.2 Modifying Priority Elements 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.
When POLICY_DATA objects are protected by integrity, LDPs should not 5.2 Modifying Priority Elements
attempt to modify them. They must be forwarded as-is or else their
security envelope would be invalidated. In other cases, LDPs may
modify and merge incoming PREEMPTION_PRI elements to reduce their
size and number according to the following rule:
- Merging is performed for each merging strategy separately. When POLICY_DATA objects are protected by integrity, LDPs should not
attempt to modify them. They must be forwarded as-is or else their
security envelope would be invalidated. In other cases, LDPs may
modify and merge incoming PREEMPTION_PRI elements to reduce their
size and number according to the following rule:
There is no known algorithm to merge PREEMPTION_PRI element of Merging is performed for each merging strategy separately.
different merging strategies without loosing valuable information
that may affect OTHER nodes.
- For each merging strategy, the highest QoS of all participating There is no known algorithm to merge PREEMPTION_PRI element of
PREEMPTION_PRI elements is taken and is placed in an outgoing different merging strategies without loosing valuable information
PREEMPTION_PRI element of this merging strategy. that may affect OTHER nodes.
This approach effectively compresses the number of forwarded - For each merging strategy, the highest QoS of all participating
PREEMPTION_PRI elements to at most to the number of different PREEMPTION_PRI elements is taken and is placed in an outgoing
merging strategies, regardless of the number of receivers (See the PREEMPTION_PRI element of this merging strategy.
example in Appendix A.2).
Internet Draft Signaled Preemption Priority Policy 26-Feb-99 - This approach effectively compresses the number of forwarded
PREEMPTION_PRI elements to at most to the number of different
merging strategies, regardless of the number of receivers (See the
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 flow's 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
having information on both the preempting and the preempted information on both the preempting and the preempted priorities may
priorities may construct a higher priority PREEMPTION_PRI element in construct a higher priority PREEMPTION_PRI element in an effort to
an effort to re-instate the preempted flow. 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 IANA Considerations 7 IANA Considerations
RSVP Policy Data object P-type values are assigned by IANA, as Following the policies outlined in [IANA-CONSIDERATIONS], Standard
described in [RSVP-EXT]. RSVP Policy Elements (P-type values) are assigned by IETF Consensus
action as described in [RSVP-EXT].
The values for inclusion in the other protocol data fields defined P-Type PREEMPTION_PRI is assigned the value 3.
in this memo are assigned by IETF Consensus action, as defined in
[IANA-CONSIDERATIONS]."
8 Security 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
considering that preemption priority aims to provide simple and
quick guidance to routers within a trusted zone or at least a single
zone (no zone boundaries are crossed).
Internet Draft Signaled Preemption Priority Policy 26-Feb-99 Further security mechanisms are not warranted, especially considering
that preemption priority aims to provide simple and quick guidance to
routers within a trusted zone or at least a single zone (no zone
boundaries are crossed).
9 References 9 References
[RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", [RSVP-EXT] Herzog, S., "RSVP Extensions for Policy
Internet-Draft, draft-ietf-rap-rsvp-ext-02.txt, Jan. 1999. Control", RFC 2750, January 2000.
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S.,
R., Sastry, A., "COPS usage for RSVP" Internet-Draft, draft- Raja, R. and A. Sastry, "COPS usage for RSVP",
ietf-rap-cops-rsvp-02.txt, Jan 1999. RFC 2749, January 2000.
[RAP] Yavatkar, R., et al., "A Framework for Policy Based [RAP] Yavatkar, R., et al., "A Framework for Policy
Admission Control",IETF <draft-ietf-rap-framework-02.txt>, Based Admission Control", RFC 2753, January
Jan., 1999. 2000.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S.,
Sastry, A., "The COPS (Common Open Policy Service) Protocol", Raja, R. and A. Sastry, "The COPS (Common Open
IETF <draft-ietf-rap-cops-05.txt>, Jan. 1999. Policy Service) Protocol", RFC 2748, January
2000.
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - [RSVP] Braden, R., ed., et al., "Resource ReSerVation
Functional Specification.", IETF RFC 2205, Proposed Standard, Protocol (RSVP) - Functional Specification",
Sep. 1997. RFC 2205, September 1997.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", RFC 2434, Writing an IANA Considerations Section in
October 1998. RFCs", BCP 26, RFC 2434, October 1998.
10 Author Information 10 Author Information
Shai Herzog, IPHighway Shai Herzog
Parker Plaza, Suite 1500 IPHighway, Inc.
400 Kelby St. 55 New York Avenue
Fort-Lee, NJ 07024 Framingham, MA 01701
(201) 585-0800
herzog@iphighway.com
Internet Draft Signaled Preemption Priority Policy 26-Feb-99 Phone: (508) 620-1141
EMail: herzog@iphighway.com
Appendix A: Example Appendix A: Example
The following examples describe the computation of merged priority The following examples describe the computation of merged priority
elements as well as the translation (compression) of PREEMPTION_PRI elements as well as the translation (compression) of PREEMPTION_PRI
elements. elements.
A.1 Computing Merged Priority A.1 Computing Merged Priority
r1 r1
/ QoS=Hi (Pr=3, St=Highest QoS) / QoS=Hi (Pr=3, St=Highest QoS)
/ /
s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP) s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP)
\ \ \ \
\ \ QoS=Low (Pr=7, St=Highest QoS) \ \ QoS=Low (Pr=7, St=Highest QoS)
r4 r3 r4 r3
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 doesn't participate (since r3 is Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is not
not contributing to the merged QoS) and the priority is the highest contributing to the merged QoS) and the priority is the highest of
of the PREEMPTION_PRI from r1 and r2. 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
doesn't 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:
(Pr=3, St=Highest QoS) (Pr=3, St=Highest QoS)
(Pr=7, St=Highest QoS) (Pr=7, St=Highest QoS)
(Pr=4, St=Highest PP) (Pr=4, St=Highest PP)
(Pr=9, St=Highest PP) (Pr=9, St=Highest PP)
(Pr=6, St=Highest PP) (Pr=6, St=Highest PP)
To: To:
(Pr=7, St=Highest QoS) (Pr=7, St=Highest QoS)
(Pr=9, St=Highest PP) (Pr=9, St=Highest PP)
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 99 change blocks. 
337 lines changed or deleted 298 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/