分享
 
 
 

RFC2751 - Signaled Preemption Priority Policy Element

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group S. Herzog

Request for Comments: 2751 IPHighway

Category: Standards Track January 2000

Signaled Preemption Priority Policy Element

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This document describes a preemption priority policy element for use

by signaled policy based admission protocols (sUCh as [RSVP] and

[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.

Table of Contents

1 Introduction .....................................................2

2 Scope and Applicability ..........................................3

3 Stateless Policy .................................................3

4 Policy Element Format ............................................4

5 Priority Merging Issues ..........................................5

5.1 Priority Merging Strategies ...................................6

5.1.1 Take priority of highest QoS .................................6

5.1.2 Take highest priority ........................................7

5.1.3 Force error on heterogeneous merge ...........................7

5.2 Modifying Priority Elements ...................................7

6 Error Processing .................................................8

7 IANA Considerations ..............................................8

8 Security Considerations ..........................................8

9 References .......................................................9

10 Author Information .............................................9

Appendix A: Example ...............................................10

A.1 Computing Merged Priority ....................................10

A.2 Translation (Compression) of Priority Elements ...............11

Full Copyright Statement ..........................................12

1 Introduction

Traditional Capacity based Admission Control (CAC) indiscriminately

admits new flows until capacity is exhausted (First Come First

Admitted). Policy based Admission Control (PAC) on the other hand

attempts to minimize the significance of order of arrival and use

policy based admission criteria instead.

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

node. Preemption Priority takes effect only when a set of flows

attempting admission through a node represents overbooking of

resources such that based on CAC some would have to be rejected.

Preemption priority criteria help the node select the most important

flows (highest priority) for admission, while rejecting the low

priority ones.

Network nodes which support preemption should consider priorities to

preempt some previously admitted low-priority flows in order to make

room for a newer, high-priority flow.

This document describes the format and applicability of the

preemption priority represented as a policy element in [RSVP-EXT].

2 Scope and Applicability

The Framework document for policy-based admission control [RAP]

describes the various components that participate in policy decision

making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI

elements is to be simple, stateless, and light-weight such that they

could be implemented internally within a node's LDP (Local Decision

Point).

Certain base assumptions are made in the usage model for

PREEMPTION_PRI elements:

- They are created by PDPs

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

PREEMPTION_PRI elements are processed by LDPs of nodes that do not

have a controlling PDP. LDPs may interpret these objects, forward

them as is, or perform local merging to forward an equivalent

merged PREEMPTION_PRI policy element. LDPs must follow the merging

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

well).

- They are enforced by PEPs

PREEMPTION_PRI elements interact with a node's traffic control

module (and capacity admission control) to enforce priorities, and

preempt previously admitted flows when the need arises.

3 Stateless Policy

Signaled Preemption Priority is stateless (does not require past

history or external information to be interpreted). Therefore, when

carried in COPS messages for the outsourcing of policy decisions,

these objects are included as COPS Stateless Policy Data Decision

objects (see [COSP, COPS-RSVP]).

4 Policy Element Format

The format of Policy Data objects is defined in [RSVP-EXT]. A single

Policy Data object may contain one or more policy elements, each

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

+------+------+-------------+-------------+-------------+

Length: 16 bits

Always 12. The overall length of the policy element, in bytes.

P-Type: 16 bits

PREEMPTION_PRI = 3

This value is registered with IANA, see Section 7.

Flags: 8 bits

Reserved (always 0).

Merge Strategy: 8 bit

1 Take priority of highest QoS: recommended

2 Take highest priority: aggressive

3 Force Error on heterogeneous merge

Reserved: 8 bits

Error code: 8 bits

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

Reserved: 8 bits

Always 0.

Preemption Priority: 16 bit (unsigned)

The priority of the new flow compared with the defending priority

of previously admitted flows. Higher values represent higher

Priority.

Defending Priority: 16 bits (unsigned)

Once a flow was admitted, the preemption priority becomes

irrelevant. Instead, its defending priority is used to compare

with the preemption priority of new flows.

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

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:

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

costs as a function of QoS and priority, F1 receives an "expensive"

priority without having to "pay" for it.

Denial of Service:

If F3 assumes Priority=Low, the merged flow could be preempted or

fail even though F2 presented high priority.

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).

Instability:

The combination of preemption priority, killer reservation and

blockade state [RSVP] may increase the instability of admitted flows

where a reservation may be preempted, reinstated, and preempted again

periodically.

5.1 Priority Merging Strategies

In merging situations LDPs may receive multiple preemption elements

and must compute the priority of the merged flow according to the

following rules:

a. Preemption priority and defending priority are merged and computed

separately, irrespective of each other.

b. Participating priority elements are selected.

All priority elements are examined according to their merging

strategy to decide whether they should participate in the merged

result (as specified bellow).

c. The highest priority of all participating priority elements is

computed.

The remainder of this section describes the different merging

strategies the can be specified in the PREEMPTION_PRI element.

5.1.1 Take priority of highest QoS

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).

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.

This is a recommended merging strategy.

5.1.2 Take highest priority

All PREEMPTION_PRI elements participate in the merged reservation.

This strategy disassociates priority and QoS level, and therefore is

highly subject to free-riders and its inverse image, denial of

service.

This is not a recommended method, but may be simpler to implement.

5.1.3 Force error on heterogeneous merge

A PREEMPTION_PRI element may participate in a merged reservation 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

is relatively rare and too complicated to deal with, thus it better

be prohibited.

This strategy lends itself to denial of service, when a single

receiver specifying a non-compatible QoS level may cause denial of

service for all other receivers of the merged reservation.

Note: The determination of heterogeneous flows applies to QoS level

only (FLOWSPEC values), and is a matter for local (LDP) definition.

Other types of heterogeneous reservations (e.g. conflicting

reservation styles) are handled by RSVP and are unrelated to this

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.

5.2 Modifying Priority Elements

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:

Merging is performed for each merging strategy separately.

There is no known algorithm to merge PREEMPTION_PRI element of

different merging strategies without loosing valuable information

that may affect OTHER nodes.

- For each merging strategy, the highest QoS of all participating

PREEMPTION_PRI elements is taken and is placed in an outgoing

PREEMPTION_PRI element of this merging strategy.

- 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

A PREEMPTION_PRI error object is sent back toward the appropriate

receivers when an error involving PREEMPTION_PRI elements occur.

PREEMPTION

When a previously admitted flow is preempted, a copy of the

preempting flow's PREEMPTION_PRI element is sent back toward the PDP

that originated the preempted PREEMPTION_PRI object. This PDP, having

information on both the preempting and the preempted priorities may

construct a higher priority PREEMPTION_PRI element in an effort to

re-instate the preempted flow.

Heterogeneity

When a flow F1 with Heterogeneous Error merging strategy set in its

PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI

element is sent back toward receivers with the Heterogeneity error

code set.

7 IANA Considerations

Following the policies outlined in [IANA-CONSIDERATIONS], Standard

RSVP Policy Elements (P-type values) are assigned by IETF Consensus

action as described in [RSVP-EXT].

P-Type PREEMPTION_PRI is assigned the value 3.

8 Security Considerations

The integrity of PREEMPTION_PRI is guaranteed, as any other policy

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).

9 References

[RSVP-EXT] Herzog, S., "RSVP Extensions for Policy

Control", RFC2750, January 2000.

[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S.,

Raja, R. and A. Sastry, "COPS usage for RSVP",

RFC2749, January 2000.

[RAP] Yavatkar, R., et al., "A Framework for Policy

Based Admission Control", RFC2753, January

2000.

[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S.,

Raja, R. and A. Sastry, "The COPS (Common Open

Policy Service) Protocol", RFC2748, January

2000.

[RSVP] Braden, R., ed., et al., "Resource ReSerVation

Protocol (RSVP) - Functional Specification",

RFC2205, September 1997.

[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for

Writing an IANA Considerations Section in

RFCs", BCP 26, RFC2434, October 1998.

10 Author Information

Shai Herzog

IPHighway, Inc.

55 New York Avenue

Framingham, MA 01701

Phone: (508) 620-1141

EMail: herzog@iphighway.com

Appendix A: Example

The following examples describe the computation of merged priority

elements as well as the translation (compression) of PREEMPTION_PRI

elements.

A.1 Computing Merged Priority

r1

/ QoS=Hi (Pr=3, St=Highest QoS)

/

s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP)

\ \ \ QoS=Low (Pr=7, St=Highest QoS)

r4 r3

QoS=Low (Pr=9, St=Error)

Example 1: Merging preemption priority elements

Example one describes a multicast scenario with one sender and four

receivers each with each own PREEMPTION_PRI element definition.

r1, r2 and r3 merge in B. The resulting priority is 4.

Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is not

contributing to the merged QoS) and the priority is the highest of

the PREEMPTION_PRI from r1 and r2.

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

other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to

r4 telling it that its PREEMPTION_PRI element encountered

heterogeneity.

A.2 Translation (Compression) of Priority Elements

Given this set of participating PREEMPTION_PRI elements, the

following compression can take place at the merging node:

From:

(Pr=3, St=Highest QoS)

(Pr=7, St=Highest QoS)

(Pr=4, St=Highest PP)

(Pr=9, St=Highest PP)

(Pr=6, St=Highest PP)

To:

(Pr=7, St=Highest QoS)

(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 RFCEditor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有