idnits 2.17.1 draft-ietf-sip-resource-priority-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1617. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 391 has weird spacing: '... amdr o ...' == Line 392 has weird spacing: '... amdr o ...' == Line 393 has weird spacing: '... amdr o ...' == Line 397 has weird spacing: '... amdr o ...' == Line 398 has weird spacing: '... amdr o ...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2005) is 6855 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'XXXX' is mentioned on line 1410, but not defined == Unused Reference: 'RFC3324' is defined on line 1536, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-sipping-reason-header-for-preemption-02 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-02) exists of draft-ietf-sipping-trait-authz-01 -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: January 14, 2006 J. Polk 5 Cisco 6 July 13, 2005 8 Communications Resource Priority for the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sip-resource-priority-10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 14, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document defines two new SIP header fields for communicating 44 resource priority, namely "Resource-Priority" and "Accept-Resource- 45 Priority". The "Resource-Priority" header field can influence the 46 behavior of SIP user agents, such as telephone gateways and IP 47 telephones, and SIP proxies. It does not directly influence the 48 forwarding behavior of IP routers. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3. The Resource-Priority and Accept-Resource-Priority SIP 55 Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1 The 'Resource-Priority' Header Field . . . . . . . . . . . 7 57 3.2 The 'Accept-Resource-Priority' Header Field . . . . . . . 9 58 3.3 Usage of the 'Resource-Priority' and 59 'Accept-Resource-Priority' Header Fields . . . . . . . . . 9 60 3.4 The 'resource-priority' Option Tag . . . . . . . . . . . . 10 61 4. Behavior of SIP Elements that Receive Prioritized Requests . . 10 62 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 63 4.2 General Rules . . . . . . . . . . . . . . . . . . . . . . 10 64 4.3 Usage of Require Header with Resource-Priority . . . . . . 11 65 4.4 OPTIONS Request with Resource-Priority . . . . . . . . . . 11 66 4.5 Approaches for Preferential Treatment of Requests . . . . 11 67 4.5.1 Preemption . . . . . . . . . . . . . . . . . . . . . . 12 68 4.5.2 Priority Queueing . . . . . . . . . . . . . . . . . . 12 69 4.6 Error Conditions . . . . . . . . . . . . . . . . . . . . . 13 70 4.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . 13 71 4.6.2 No Known Namespace or Priority Value . . . . . . . . . 13 72 4.6.3 Authentication Failure . . . . . . . . . . . . . . . . 14 73 4.6.4 Authorization Failure . . . . . . . . . . . . . . . . 14 74 4.6.5 Insufficient Resources . . . . . . . . . . . . . . . . 14 75 4.6.6 Busy . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.7 Element-Specific Behaviors . . . . . . . . . . . . . . . . 15 77 4.7.1 User Agent Client Behavior . . . . . . . . . . . . . . 15 78 4.7.2 User Agent Server Behavior . . . . . . . . . . . . . . 16 79 4.7.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . 16 80 5. Third-Party Authentication . . . . . . . . . . . . . . . . . . 17 81 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18 82 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 7.1 Simple Call . . . . . . . . . . . . . . . . . . . . . . . 18 84 7.2 Receiver Does Not Understand Namespace . . . . . . . . . . 19 85 8. Handling Multiple Concurrent Namespaces . . . . . . . . . . . 21 86 8.1 General Rules . . . . . . . . . . . . . . . . . . . . . . 21 87 8.2 Examples of Valid Orderings . . . . . . . . . . . . . . . 22 88 8.3 Examples of Invalid Orderings . . . . . . . . . . . . . . 22 89 9. Registering Namespaces . . . . . . . . . . . . . . . . . . . . 23 90 10. Namespace Definitions . . . . . . . . . . . . . . . . . . . 24 91 10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 24 92 10.2 The "DSN" Namespace . . . . . . . . . . . . . . . . . . . 24 93 10.3 The "DRSN" Namespace . . . . . . . . . . . . . . . . . . . 25 94 10.4 The "Q735" Namespace . . . . . . . . . . . . . . . . . . . 25 95 10.5 The "ETS" Namespace . . . . . . . . . . . . . . . . . . . 26 96 10.6 The "WPS" Namespace . . . . . . . . . . . . . . . . . . . 26 97 11. Security Considerations . . . . . . . . . . . . . . . . . . 27 98 11.1 General Remarks . . . . . . . . . . . . . . . . . . . . . 27 99 11.2 Authentication and Authorization . . . . . . . . . . . . . 27 100 11.3 Confidentiality and Integrity . . . . . . . . . . . . . . 28 101 11.4 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 29 102 11.5 Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29 103 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 104 12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 29 105 12.2 IANA Registration of 'Resource-Priority' and 106 'Accept-Resource-Priority' Header Fields . . . . . . . . . 30 107 12.3 IANA Registration for Option Tag resource-priority . . . . 30 108 12.4 IANA Registration for Response Code 417 . . . . . . . . . 30 109 12.5 IANA Resource-Priority Namespace Registration . . . . . . 31 110 12.6 IANA Priority-Value Registrations . . . . . . . . . . . . 31 111 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32 112 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 113 14.1 Normative References . . . . . . . . . . . . . . . . . . . 32 114 14.2 Informative References . . . . . . . . . . . . . . . . . . 33 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35 116 Intellectual Property and Copyright Statements . . . . . . . . 36 118 1. Introduction 120 During emergencies, communications resources including telephone 121 circuits, IP bandwidth and gateways between the circuit-switched and 122 IP networks may become congested. Congestion can occur due to heavy 123 usage, loss of resources caused by the natural or man-made disaster 124 and attacks on the network during man-made emergencies. This 125 congestion may make it difficult for persons charged with emergency 126 assistance, recovery or law enforcement to coordinate their efforts. 127 As IP networks become part of converged or hybrid networks along with 128 public and private circuit-switched (telephone) networks, it becomes 129 necessary to ensure that these networks can assist during such 130 emergencies. 132 Also, users may want to interrupt their lower-priority communications 133 activities and dedicate their end system resources to the high- 134 priority communications attempt if a high-priority communications 135 request arrives at their end system. 137 There are many IP-based services that can assist during emergencies. 138 This memo only covers real-time communications applications involving 139 the Session Initiation Protocol (SIP) [RFC3261], including voice- 140 over-IP, multimedia conferencing, instant messaging and presence. 142 SIP applications may involve at least five different resources that 143 may become scarce and congested during emergencies. These resources 144 include gateway resources, circuit-switched network resources, IP 145 network resources, receiving end system resources and SIP proxy 146 resources. IP network resources are beyond the scope of SIP 147 signaling and are therefore not considered here. 149 Even if the resources at the SIP element itself are not scarce, a SIP 150 gateway may mark outgoing calls with an indication of priority, e.g., 151 in an ISUP IAM message originated by the gateway. 153 In order to improve emergency response, it may become necessary to 154 prioritize access to SIP-signaled resources during periods of 155 emergency-induced resource scarcity. We call this "resource 156 prioritization". The mechanism itself may well be in place at all 157 times, but only materially affect call handling during times of 158 resource scarcity. 160 Currently, SIP does not include a mechanism that allows a request 161 originator to indicate to a SIP element that it wishes the request to 162 invoke such resource prioritization. To address this need, this 163 document adds a SIP protocol element that labels certain SIP 164 requests. 166 This document defines (Section 3) two new SIP header field for 167 communications resource priority, called 'Resource-Priority' and 168 'Accept-Resource-Priority'. The 'Resource-Priority' header field MAY 169 be used by SIP user agents, including General Switched Telephone 170 Network (GSTN) gateways and terminals, and SIP proxy servers to 171 influence their treatment of SIP requests, including the priority 172 afforded to GSTN calls. For GSTN gateways, the behavior translates 173 into analogous schemes in the GSTN, for example the ITU 174 Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both 175 the GSTN-to-IP and IP-to-GSTN directions. ITU Recommendation I.255.3 176 [I.255.3] is another example. 178 A SIP request with a 'Resource-Priority' indication can be treated 179 differently in these situations: 181 1. The request can be given elevated priority for access to GSTN 182 gateway resources such as trunk circuits. 183 2. The request can interrupt lower-priority requests at a user 184 terminal, such as an IP phone. 185 3. The request can carry information from one multi-level priority 186 domain in the telephone network, e.g., using the facilities of 187 Q.735.3 [Q.735.3], to another, without the SIP proxies themselves 188 inspecting or modifying the header field. 189 4. In SIP proxies and back-to-back user agents, requests of higher 190 priorities may displace existing signaling requests or bypass 191 GSTN gateway capacity limits in effect for lower priorities. 193 This header field is related to, but differs in semantics from, the 194 'Priority' header field ([RFC3261], Section 20.26). The 'Priority' 195 header field describes the importance that the SIP request should 196 have to the receiving human or its agent. For example, that header 197 may be factored into decisions about call routing to mobile devices 198 and assistants and call acceptance when the call destination is busy. 199 The 'Priority' header field does not affect the usage of GSTN gateway 200 or proxy resources, for example. In addition, any User Agent Client 201 (UAC) can assert any 'Priority' value, while usage of 'Resource- 202 Priority' header field values is subject to authorization. 204 While the 'Resource-Priority' header field does not directly 205 influence the forwarding behavior of IP routers or the use of 206 communications resources such as packet forwarding priority, 207 procedures for using this header field to cause such influence may be 208 defined in other documents. 210 Existing implementations of RFC 3261 that do not participate in the 211 resource priority mechanism follow the normal rules of RFC 3261, 212 Section 8.2.2: "If a UAS does not understand a header field in a 213 request (that is, the header field is not defined in this 214 specification or in any supported extension), the server MUST ignore 215 that header field and continue processing the message." Thus, the 216 use of this mechanism is wholly invisible to existing implementations 217 unless the request includes the Require header field with the 218 resource-priority option tag. 220 The mechanism described here can be used for emergency preparedness 221 in emergency telecommunications systems, but is only a small part of 222 an emergency preparedness network and is not restricted to such use. 224 The mechanism aims to satisfy the requirements in [RFC3487]. It is 225 structured so that it works in all SIP and Real-Time Transport 226 Protocol (RTP) [RFC3550] transparent networks defined in [RFC3487]. 227 In such networks, all network elements and SIP proxies let valid SIP 228 requests pass through unchanged. This is important since it is 229 likely that this mechanism will often be deployed in networks where 230 the edge networks are unaware of the resource priority mechanism and 231 provide no special privileges to such requests. The request then 232 reaches a GSTN gateway or set of SIP elements that are aware of the 233 mechanism. 235 For conciseness, we refer to SIP proxies and user agents (UAs) that 236 act on the 'Resource-Priority' header field as RP actors. 238 It is likely to be common that the same SIP element will handle 239 requests that bear the 'Resource-Priority' header fields and those 240 that do not. 242 Government entities and standardization bodies have developed several 243 different priority schemes for their networks. Users would like to 244 be able to obtain authorized priority handling in several of these 245 networks, without changing SIP clients. Also, a single call may 246 traverse SIP elements that are run by different administrations and 247 subject to different priority mechanisms. Since there is no global 248 ordering among those priorities, we allow each request to contain 249 more than one priority value drawn from these different priority 250 lists, called a namespace in this document. Typically, each SIP 251 element only supports one such namespace, but we discuss what happens 252 if an element needs to support multiple namespaces in Section 8. 254 Since gaining prioritized access to resources offers opportunities to 255 deny service to others, it is expected that all such prioritized 256 calls are subject to authentication and authorization, using standard 257 SIP security mechanisms (Section 11). 259 The remainder of this document is structured as follows. After 260 defining terminology in Section 2, we define the syntax for the two 261 new SIP header fields in Section 3 and then describe protocol 262 behavior in Section 4. The two principal mechanisms for 263 differentiated treatment of SIP requests, namely preemption and 264 queuing, are described in Section 4.5. Error conditions are covered 265 in Section 4.6. Section 4.7.1 through Section 4.7.3 detail the 266 behavior of specific SIP elements. Third-party authentication is 267 briefly summarized in Section 5. Section 6 describes how this 268 feature affects existing systems that do not support it. 270 Since calls may traverse multiple administrative domains with 271 different namespaces or multiple elements with the same namespace, it 272 is strongly suggested that all such domains and elements apply the 273 same algorithms for the same namespace as otherwise the end-to-end 274 experience of privileged users may be compromised. 276 Section 9 enumerates the information that namespace registrations 277 need to provide. Section 8 discusses what happens if a request 278 contains multiple namespaces or an element can handle more than one 279 namespace. Section 10 defines the properties of five namespaces that 280 are registered through this document. Protocol examples are given in 281 Section 7. Security issues are considered in Section 11, but this 282 document does not define new security mechanisms. Section 12 283 discusses IANA considerations and registers parameters related to 284 this document. 286 2. Terminology 288 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 289 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 290 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 291 [RFC2119] and indicate requirement levels for compliant 292 implementations. 294 3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields 296 This section defines the 'Resource-Priority' and 'Accept-Resource- 297 Priority' SIP header field syntax. Behavior is described in 298 Section 4. 300 3.1 The 'Resource-Priority' Header Field 302 The 'Resource-Priority' request header field marks a SIP request as 303 desiring prioritized access to resources, as described in the 304 introduction. 306 There is no protocol requirement that all requests within a SIP 307 dialog or session use the 'Resource-Priority' header field. Local 308 administrative policy MAY mandate the inclusion of the 'Resource- 309 Priority' header field in all requests. Implementations of this 310 specification MUST allow inclusion to be either by explicit user 311 request or automatically for all requests. 313 The syntax of the 'Resource-Priority' header field is described 314 below. The "token-nodot" production is copied from [RFC3265]. 316 Resource-Priority = "Resource-Priority" HCOLON 317 r-value *(COMMA r-value) 318 r-value = namespace "." r-priority 319 namespace = token-nodot 320 r-priority = token-nodot 321 token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" 322 / "_" / "+" / "`" / "'" / "~" ) 324 An example 'Resource-Priority' header field is shown below: 326 Resource-Priority: dsn.flash 328 The 'r-value' parameter in the 'Resource-Priority' header field 329 indicates the resource priority desired by the request originator. 330 Each resource value (r-value) is formatted as 'namespace' '.' 331 'priority value'. The value is drawn from the namespace identified 332 by the 'namespace' token. Namespaces and priorities are case- 333 insensitive ASCII tokens that do not contain periods. Thus, 334 "dsn.flash" and "DSN.Flash", for example, are equivalent. Each 335 namespace has at least one priority value. Namespaces and priority 336 values within each namespace MUST be registered with IANA 337 (Section 12). Initial namespace registrations are described in 338 Section 12.5. 340 Since a request may traverse multiple administrative domains with 341 multiple different namespaces, it is necessary to be able to 342 enumerate several different namespaces within the same message. 343 However, a particular namespace MUST NOT appear more than once in the 344 same SIP message. These may be expressed equivalently as either 345 comma-separated lists within a single header field, as multiple 346 header fields or some combination. The ordering of 'r-values' within 347 the header field has no significance. Thus, for example, the 348 following three header snippets are equivalent: 350 Resource-Priority: dsn.flash, wps.3 352 Resource-Priority: wps.3, dsn.flash 354 Resource-Priority: wps.3 355 Resource-Priority: dsn.flash 357 3.2 The 'Accept-Resource-Priority' Header Field 359 The 'Accept-Resource-Priority' response header field enumerates the 360 resource values (r-values) a SIP user agent server is willing to 361 process. (This does not imply that a call with such values will find 362 sufficient resources and succeed.) The syntax of the 'Accept- 363 Resource-Priority' header field is as follows: 365 Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON 366 [r-value *(COMMA r-value)] 368 An example is given below: 370 Accept-Resource-Priority: dsn.flash-override, 371 dsn.flash, dsn.immediate, dsn.priority, dsn.routine 373 Some administrative domains MAY choose to disable the use of the 374 'Accept-Resource-Priority' header as revealing too much information 375 about that domain in responses. However, this behavior is NOT 376 RECOMMENDED, as this header field aids in troubleshooting. 378 3.3 Usage of the 'Resource-Priority' and 'Accept-Resource-Priority' 379 Header Fields 381 The following table extends the values in Table 2 of RFC3261 382 [RFC3261]. (The PRACK method, labeled as PRA, is defined in 383 [RFC3262], the SUBSCRIBE (labeled SUB) and NOTIFY (labeled NOT) 384 methods in [RFC3265], the UPDATE (UPD) method in [RFC3311], the 385 MESSAGE (MSG) method in [RFC3428], the REFER (REF) method in 386 [RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB) 387 method is in [RFC3903].) 389 Header field where proxy INV ACK CAN BYE REG OPT PRA 390 ---------------------------------------------------------------- 391 Resource-Priority R amdr o o o o o o o 392 Accept-Resource-Priority 200 amdr o - o o o o o 393 Accept-Resource-Priority 417 amdr o - o o o o o 395 Header field where proxy SUB NOT UPD MSG REF INF PUB 396 ---------------------------------------------------------------- 397 Resource-Priority R amdr o o o o o o o 398 Accept-Resource-Priority 200 amdr o o o o o o o 399 Accept-Resource-Priority 417 amdr o o o o o o o 401 Other request methods MAY define their own handling rules; unless 402 otherwise specified, recipients MAY ignore these header fields. 404 3.4 The 'resource-priority' Option Tag 406 This document also defines the "resource-priority" option tag. The 407 behavior is described in Section 4.3. and the IANA registration is in 408 Section 12.3. 410 4. Behavior of SIP Elements that Receive Prioritized Requests 412 4.1 Introduction 414 All SIP user agents and proxy servers that support this specification 415 share certain common behavior, which we describe below in 416 Section 4.2. The behavior when encountering a 'resource-priority' 417 option tag in a 'Require' header field is describe in Section 4.3. 418 Section 4.4 describes the treatment of OPTIONS requests. The two 419 fundamental resource contention resolution mechanisms, preemption and 420 queueing, are described in Section 4.5. Section 4.6 explains what 421 happens when requests fail. Behavior specific to user agent clients, 422 servers and proxy servers are covered in Section 4.7. 424 4.2 General Rules 426 The 'Resource-Priority' header field is potentially applicable to all 427 SIP request messages. At a minimum, implementations of the following 428 request types MUST support the Resource-Priority header to be in 429 compliance with this specification: 431 o INVITE [RFC3261] 432 o ACK [RFC3261] 433 o PRACK [RFC3262] 434 o UPDATE [RFC3311] 435 o REFER [RFC3515] 437 Implementations SHOULD support the 'Resource-Priority' header field 438 in the following request types: 440 o MESSAGE [RFC3428] 441 o SUBSCRIBE [RFC3265] 442 o NOTIFY [RFC3265] 444 Note that this does not imply that all implementations have to 445 support all requests methods listed. 447 If a SIP element receives the 'Resource-Priority' header field in a 448 request other than those listed above, the header MAY be ignored, 449 according to the rules of [RFC3261]. 451 In short, an RP actor performs the following steps when receiving a 452 prioritized request. Error behavior is described in Section 4.6. 454 1. If the RP actor recognizes none of the name spaces, treat the 455 request as if it had no 'Resource-Priority' header field. 456 2. Ascertain that the request is authorized according to local 457 policy to use the priority levels indicated. If the request is 458 not authorized, reject it. Examples of authorization policies 459 are discussed in Security Considerations (Section 11). 460 3. If the request is authorized and resources are available (no 461 congestion), serve the request as usual. If the request is 462 authorized, but resources are not available (congestion), either 463 preempt other current sessions or insert the request into a 464 priority queue, as described in Section 4.5. 466 4.3 Usage of Require Header with Resource-Priority 468 Following standard SIP behavior, if a SIP request contains the 469 'Require' header field with the 'resource-priority' option tag, a SIP 470 user agent MUST respond with a 420 (Bad Extension) if it does not 471 support the SIP extensions described in this document. It then lists 472 "resource-priority" in the 'Unsupported' header field included in the 473 response. 475 The use of the 'resource-priority' option tag in 'Proxy-Require' 476 header field is NOT RECOMMENDED. 478 4.4 OPTIONS Request with Resource-Priority 480 An OPTIONS request can be used to determine if an element supports 481 the mechanism. A compliant implementation MUST return a 'Accept- 482 Resource-Priority' header field in OPTIONS responses enumerating all 483 valid resource values. An RP actor MAY be configured not to return 484 such values or only return them to authorized requestors. 486 Following standard SIP behavior, OPTIONS responses MUST include the 487 'Supported' header field that includes the 'resource-priority' option 488 tag. 490 According to RFC 3261, Section 11, proxies that receive a request 491 with a 'Max-Forwards' header field value of zero MAY answer the 492 OPTIONS request, allowing a UAC to discover the capabilities of both 493 proxy and user agent servers. 495 4.5 Approaches for Preferential Treatment of Requests 497 SIP elements may use the resource priority mechanism to modify a 498 variety of behavior such as routing requests, authentication 499 requirements, override of network capacity controls or logging. The 500 resource priority mechanism may influence the treatment of the 501 request itself, the marking of outbound PSTN calls at a gateway or of 502 the session created by the request. (Here, we use the terms session 503 and call interchangeably in this document, both implying a continuous 504 data stream between two or more parties. Sessions are established by 505 SIP dialogs.) 507 Below, we define two common algorithms, namely preemption and 508 priority queueing. Preemption applies only to sessions created by 509 SIP requests, while both sessions and request handling can be subject 510 to priority queueing. Both algorithms can sometimes be combined in 511 the same element, although none of the namespaces described in this 512 document do this. Algorithms can be defined for each namespace or, 513 in some cases, can be specific to an administrative domain. Other 514 behavior, such as request routing or network management controls, is 515 not defined by this specification. 517 Naturally, only SIP elements that understand this mechanism and the 518 namespace and resource value perform these algorithms. Section 4.6.2 519 discusses what happens if an RP actor does not understand priority 520 values contained in a request. 522 4.5.1 Preemption 524 An RP actor following a preemption policy may disrupt an existing 525 session to make room for a higher-priority incoming session. Since 526 sessions may require different amounts of bandwidth or number of 527 circuits, a single higher priority session may displace more than one 528 lower-priority session. Unless otherwise noted, requests do not 529 preempt other requests of equal priority. As noted above, the 530 processing of SIP requests itself is not preempted. Thus, since 531 proxies do not manage sessions, they do not perform preemption. 533 [I-D.ietf-sipping-reason-header-for-preemption] contains more details 534 and examples of this behavior. 536 UAS behavior for preemption is discussed in Section 4.7.2. 538 4.5.2 Priority Queueing 540 In a priority queueing policy, requests that find no available 541 resources are queued to the queue assigned to the priority value. 542 Unless otherwise specified, requests are queued in first-come, first- 543 served order. Each priority value may have its own queue or several 544 priority values may share a single queue. If a resource becomes 545 available, the RP actor selects the request from the highest-priority 546 non-empty queue according to the queue service policy. For first- 547 come, first-served policies, the request from that queue that has 548 been waiting the longest is served. Each queue can hold a finite 549 number of pending requests. If the per-priority-value queue for a 550 newly arriving request is full, the request is rejected immediately. 551 In addition, a priority queueing policy MAY impose a waiting time 552 limit for each priority class, where requests that exceed a specified 553 waiting time are ejected from the queue and a failure response is 554 returned to the requestor. 556 Finally, an RP actor MAY impose a global queue size limit summed 557 across all queues and drop waiting lower-priority requests. This 558 does not imply preemption since the session has not been established 559 yet. 561 4.6 Error Conditions 563 4.6.1 Introduction 565 In this section, we describe the error behavior that is shared among 566 multiple types of RP actors, including various instances of UAS such 567 as trunk gateways, line gateways and IP phones, and proxies. 569 A request containing a resource priority indication can fail for four 570 reasons: the RP actor does not understand the priority value 571 (Section 4.6.2), the requestor is not authenticated (Section 4.6.3), 572 an authenticated requestor is not authorized to make such a request 573 (Section 4.6.4) or there are insufficient resources for an authorized 574 request (Section 4.6.5). We treat these error cases in the order 575 that they typically arise in the processing of requests with 576 Resource-Priority headers. However, this order is not mandated. For 577 example, an RP actor that knows that a particular resource value 578 cannot be served or queued MAY, as a matter of local policy, forego 579 authorization since it would only add processing load without 580 changing the outcome. 582 4.6.2 No Known Namespace or Priority Value 584 If an RP actor does not understand any of the resource values in the 585 request, the treatment depends on the presence of the 'Require' 586 'resource-priority' option tag: 588 1. Without the option tag, the RP actor treats the request as if it 589 contained no 'Resource-Priority' header field and processes it 590 with default priority. Resource values that are not understood 591 MUST NOT be modified or deleted. 592 2. With the option tag, it MUST reject the request with a 417 593 (Unknown Resource-Priority) response code. 595 Making case (1) the default is necessary since otherwise there would 596 be no way to successfully complete any calls in the case where a 597 proxy on the way to the UAS shares no common namespaces with the UAC, 598 but the UAC and UAS do have such a namespace in common. 600 In general, as noted, a SIP request can contain more than one 601 'Resource-Priority' header field. This is necessary if a request 602 needs to traverse different administrative domains, each with their 603 own set of valid resource values. For example, the ETS namespace 604 might be enabled for United States government networks that also 605 support the DSN and/or DRSN namespaces for most individuals in those 606 domains. 608 A 417 (Unknown Resource-Priority) response MAY, according to local 609 policy, include an 'Accept-Resource-Priority' header field 610 enumerating the acceptable resource values. 612 4.6.3 Authentication Failure 614 If the request is not authenticated, a 401 (Unauthorized) or 407 615 (Proxy Authentication Required) response is returned to allow the 616 requestor to insert appropriate credentials. 618 4.6.4 Authorization Failure 620 If the RP actor receives an authenticated request with a namespace 621 and priority value it recognizes, but the originator is not 622 authorized for that level of service, the element MUST return a 403 623 (Forbidden) response. 625 4.6.5 Insufficient Resources 627 Insufficient resource conditions can occur on proxy servers and user 628 agent servers, typically trunk gateways, if an RP actor receives an 629 authorized request, has insufficient resources and the request 630 neither preempts another session nor is queued. A request can fail 631 either because the RP actor has insufficient processing capacity to 632 handle the SIP request or insufficient bandwidth or trunk capacity to 633 establish the requested session for session-creating SIP requests. 635 If the request fails since the RP actor cannot handle the signaling 636 load, the RP actor responds with 503 (Service Unavailable). 638 If there is not enough bandwidth or an insufficient number of trunks, 639 a 488 (Not Acceptable Here) response indicates that the RP actor is 640 rejecting the request for reasons of media path availability, such as 641 insufficient gateway resources. In that case, [RFC3261] advises that 642 a 488 response SHOULD include a 'Warning' header field with a reason 643 for the rejection, with warning code 370 (Insufficient Bandwidth) 644 typical. 646 For systems implementing queueing, if the request is queued, the UAS 647 will return 408 (Request Timeout) if the request exceeds the maximum 648 configured waiting time in queue. 650 4.6.6 Busy 652 Resource contention also occurs when a call request arrives at a UAS 653 that is unable to accept another call, either because the UAS has 654 just one line presence or has active calls on all line presences. If 655 the call request indicates an equal or lower priority value compared 656 to all active calls present on the UAS, the UAS returns a 486 (Busy 657 here) response. 659 If the request is queued instead, the UAS will return 408 (Request 660 Timeout) if the request exceeds the maximum configured waiting time 661 in the device queue. 663 If a proxy gets 486 (Busy Here) responses on all branches, it can 664 then return a 600 (Busy Everywhere) response to the caller. 666 4.7 Element-Specific Behaviors 668 4.7.1 User Agent Client Behavior 670 SIP UACs supporting this specification MUST be able to generate the 671 'Resource-Priority' header field for requests that require elevated 672 resource access priority. As stated previously, the UAC SHOULD be 673 able to generate more than one resource value in a single SIP 674 request. 676 Upon receiving a 417 (Unknown Resource-Priority) response, the UAC 677 MAY attempt a subsequent request with the same or different resource 678 value. If available, it SHOULD choose authorized resource values 679 from the set of values returned in the 'Accept-Resource-Priority' 680 header field. 682 4.7.1.1 User Agent Client Behavior with a Preemption Algorithm 684 A UAC that requests a priority value that may cause preemption MUST 685 understand a Reason header field in the BYE request explaining why 686 the session was terminated, as discussed in [I-D.ietf-sipping-reason- 687 header-for-preemption]. 689 4.7.1.2 User Agent Client Behavior with a Queueing Policy 691 By standard SIP protocol rules, a UAC MUST be prepared to receive a 692 182 (Queued) response from an RP actor that is currently at capacity, 693 but has put the original request into a queue. A UAC MAY indicate 694 this queued status to the user by some audio or visual indication to 695 prevent the user from interpreting the call as having failed. 697 4.7.2 User Agent Server Behavior 699 The precise effect of the 'Resource-Priority' indication depends on 700 the type of UAS, the namespace and local policy. 702 4.7.2.1 User Agent Servers and Preemption Algorithm 704 A UAS compliant with this specification MUST terminate a session 705 established with a valid namespace and lower priority value in favor 706 of a new session set-up with a valid namespace and higher relative 707 priority-value, unless local policy has some form of call-waiting 708 capability enabled. If a session is terminated, the BYE method is 709 used with a 'Reason' header field indicating why and where the 710 preemption took place. 712 Implementors have a number of choices in how to implement preemption 713 at IP phones with multiple line presences, i.e., with devices that 714 can handle multiple simultaneous sessions. Naturally, if that device 715 has exhausted the number of simultaneous sessions, one of the 716 sessions needs to be replaced. If the device has spare sessions, an 717 implementation MAY choose to alert the callee to the arrival of a 718 higher-priority call. Details may also be set by local or namespace 719 policy. 721 [I-D.ietf-sipping-reason-header-for-preemption] provides additional 722 information in the case of purposeful or administrative termination 723 of a session by including the Reason header in the BYE message that 724 states why the BYE was sent (in this case, a preemption event). The 725 mechanisms in that document allow to indicate where the termination 726 occurred ('at the UA', 'in the network', 'at a IP/PSTN gateway'), and 727 includes call flow examples of each reason. 729 4.7.2.2 User Agent Servers and Queue-based Policy 731 A UAS compliant with this specification SHOULD generate a 182 732 (Queued) response if that element's resources are busy, until it is 733 able to handle the request and provide a final response. The 734 frequency of such provisional messages is governed by [RFC3261]. 736 4.7.3 Proxy Behavior 738 SIP proxies MAY ignore the 'Resource-Priority' header field. SIP 739 proxies MAY reject any unauthenticated request bearing that header 740 field. 742 When the 'Require' header field is included in a message, it ensures 743 that in parallel forking, only branches that support the resource- 744 priority mechanism succeed. 746 If S/MIME encapsulation is used according to Section 23 of RFC 3261, 747 special considerations apply. As tabulated in Section 3.3, the 748 'Resource-Priority' header field can be modified by proxies and thus 749 is exempted by the integrity checking described in Section 23.4.1.1 750 of RFC 3261. Since it may need to be inspected or modified by 751 proxies, the header field MUST also be placed in the "outer" message 752 if the UAC would like proxy servers to be able to act on the header 753 information. Similar considerations apply if parts of the message 754 are integrity-protected or encrypted as described in [RFC3420]. 756 If S/MIME is not used or if the 'Resource-Priority' header field is 757 in the "outer" header, SIP proxies MAY downgrade or upgrade the 758 'Resource-Priority' of a request or insert a new 'Resource-Priority' 759 header if allowed by local policy. 761 If a stateful proxy has authorized a particular resource priority 762 level and if it offers differentiated treatment to responses 763 containing resource priority levels, the proxy SHOULD ignore any 764 higher value contained in responses, to prevent colluding user agents 765 from artificially raising the priority level. 767 A SIP proxy MAY use the 'Resource-Priority' indication in its routing 768 decisions, e.g., to retarget to a SIP node or SIP URI that is 769 reserved for a particular resource priority. 771 There are no special considerations for proxies when forking requests 772 containing a resource priority indication. 774 Otherwise, the proxy behavior is the same as for user agent servers 775 described in Section 4.7.2. 777 5. Third-Party Authentication 779 In some cases, the RP actor may not be able to authenticate the 780 requestor or determine whether an authenticated user is authorized to 781 make such a request. In these circumstances, the SIP entity may 782 avail itself of general SIP mechanisms that are not specific to this 783 application. The authenticated identity management mechanism 784 [RFC3893] allows a third party to verify the identity of the 785 requestor and certify this towards an RP actor. In networks with 786 mutual trust, the SIP asserted identity mechanism [RFC3325] can help 787 the RP actor determine the identity of the requestor. 789 6. Backwards Compatibility 791 The resource priority mechanism described in this document is fully 792 backwards compatible with SIP systems following [RFC3261]. Systems 793 that do not understand the mechanism can only deliver standard, not 794 elevated, service priority. User agent servers and proxies can 795 ignore any 'Resource-Priority' header field just like any other 796 unknown header field and then treat the request like any other 797 request. Naturally, the request may still succeed. 799 7. Examples 801 The SDP message body and the BYE and ACK exchanges are the same as in 802 RFC 3665 [RFC3665] and omitted for brevity. 804 7.1 Simple Call 806 User A User B 807 | | 808 | INVITE F1 | 809 |----------------------->| 810 | 180 Ringing F2 | 811 |<-----------------------| 812 | | 813 | 200 OK F3 | 814 |<-----------------------| 815 | ACK F4 | 816 |----------------------->| 817 | Both Way RTP Media | 818 |<======================>| 819 | | 821 In this scenario, User A completes a call to User B directly. The 822 call from A to B is marked with a resource priority indication. 824 F1 INVITE User A -> User B 826 INVITE sip:UserB@biloxi.example.com SIP/2.0 827 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 828 Max-Forwards: 70 829 From: BigGuy ;tag=9fxced76sl 830 To: LittleGuy 831 Call-ID: 3848276298220188511@atlanta.example.com 832 CSeq: 1 INVITE 833 Resource-Priority: dsn.flash 834 Contact: 835 Content-Type: application/sdp 836 Content-Length: ... 838 ... 840 F2 180 Ringing User B -> User A 842 SIP/2.0 180 Ringing 843 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 844 ;received=192.0.2.101 845 From: BigGuy ;tag=9fxced76sl 846 To: LittleGuy ;tag=8321234356 847 Call-ID: 3848276298220188511@atlanta.example.com 848 CSeq: 1 INVITE 849 Contact: 850 Content-Length: 0 852 F3 200 OK User B -> User A 854 SIP/2.0 200 OK 855 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 856 ;received=192.0.2.101 857 From: BigGuy ;tag=9fxced76sl 858 To: LittleGuy ;tag=8321234356 859 Call-ID: 3848276298220188511@atlanta.example.com 860 CSeq: 1 INVITE 861 Contact: 862 Content-Type: application/sdp 863 Content-Length: ... 865 ... 867 7.2 Receiver Does Not Understand Namespace 869 In this example, the receiving UA does not understand the "dsn" 870 namespace and thus returns a 417 (Unknown Resource-Priority) status 871 code. We omit the message details for messages F5 through F7 since 872 they are essentially the same as in the first example. 874 User A User B 875 | | 876 | INVITE F1 | 877 |----------------------->| 878 | 417 R-P failed F2 | 879 |<-----------------------| 880 | ACK F3 | 881 |----------------------->| 882 | | 883 | INVITE F4 | 884 |----------------------->| 885 | 180 Ringing F5 | 886 |<-----------------------| 887 | 200 OK F6 | 888 |<-----------------------| 889 | ACK F7 | 890 |----------------------->| 891 | | 892 | Both Way RTP Media | 893 |<======================>| 895 F1 INVITE User A -> User B 897 INVITE sip:UserB@biloxi.example.com SIP/2.0 898 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 899 Max-Forwards: 70 900 From: BigGuy ;tag=9fxced76sl 901 To: LittleGuy 902 Call-ID: 3848276298220188511@atlanta.example.com 903 CSeq: 1 INVITE 904 Require: resource-priority 905 Resource-Priority: dsn.flash 906 Contact: 908 Content-Type: application/sdp 909 Content-Length: ... 911 ... 913 F2 417 Resource-Priority failed User B -> User A 915 SIP/2.0 417 Unknown Resource-Priority 916 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 917 ;received=192.0.2.101 918 From: BigGuy ;tag=9fxced76sl 919 To: LittleGuy ;tag=8321234356 920 Call-ID: 3848276298220188511@atlanta.example.com 921 CSeq: 1 INVITE 922 Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4 923 Contact: 924 Content-Type: application/sdp 925 Content-Length: 0 927 F3 ACK User A -> User B 929 ACK sip:UserB@biloxi.example.com SIP/2.0 930 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 931 Max-Forwards: 70 932 From: BigGuy ;tag=9fxced76sl 933 To: LittleGuy ;tag=8321234356 934 Call-ID: 3848276298220188511@atlanta.example.com 935 CSeq: 1 ACK 936 Content-Length: 0 938 F4 INVITE User A -> User B 940 INVITE sip:UserB@biloxi.example.com SIP/2.0 941 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 942 Max-Forwards: 70 943 From: BigGuy ;tag=9fxced76sl 944 To: LittleGuy 945 Call-ID: 3848276298220188511@atlanta.example.com 946 CSeq: 2 INVITE 947 Require: resource-priority 948 Resource-Priority: q735.3 949 Contact: 951 Content-Type: application/sdp 952 Content-Length: ... 953 ... 955 8. Handling Multiple Concurrent Namespaces 957 8.1 General Rules 959 A single SIP request MAY contain resource values from multiple 960 namespaces. As noted earlier, an RP actor disregards all namespaces 961 it does not recognize. This specification only addresses the case 962 where an RP actor then selects one of the remainining resource values 963 for processing, usually choosing the one with the highest relative 964 priority. 966 If an RP actor understands multiple namespaces, it MUST create a 967 local total ordering across all resource values from these 968 namespaces, maintaining the relative ordering within each namespace. 969 It is RECOMMENDED that the same ordering is used across an 970 administrative domain. However, there is no requirement that such 971 ordering be the same across all administrative domains. 973 8.2 Examples of Valid Orderings 975 Below are a set of examples of an RP actor that supports two 976 namespaces, foo and bar. Foo's priority-values are 3 (highest), then 977 2 and then 1 (lowest), and bar's priority-values are C (highest), 978 then B and then A (lowest). 980 Below are five lists of acceptable priority orders the SIP element 981 may use: 983 Foo.3 Foo.3 Bar.C (highest priority) 984 Foo.2 Bar.C Foo.3 985 Foo.1 or Foo.2 or Foo.2 986 Bar.C Bar.B Foo.1 987 Bar.B Foo.1 Bar.B 988 Bar.A Bar.A Bar.A (lowest priority) 990 Bar.C (highest priority) 991 Foo.3 Bar.B (both treated with equal priority (FIFO)) 992 or Foo.2 Bar.A (both treated with equal priority (FIFO)) 993 Foo.1 (lowest priority) 995 Bar.C (highest priority) 996 Foo.3 997 or Foo.2 998 Foo.1 (lowest priority) 1000 In the last example above, Bar.A and Bar.B are ignored. 1002 8.3 Examples of Invalid Orderings 1004 Based on the priority order of the namespaces above, the following 1005 combinations are examples of orderings that are NOT acceptable and 1006 MUST NOT be configurable: 1008 Example 1 Example 2 Example 3 1009 --------- --------- --------- 1010 Foo.3 Foo.3 Bar.C 1011 Foo.2 Bar.A Foo.1 1012 Foo.1 or Foo.2 or Foo.3 1013 Bar.C Bar.B Foo.2 1014 Bar.A Foo.1 Bar.A 1015 Bar.B Bar.C Bar.B 1017 Example 4 1018 --------- 1019 Bar.C 1020 Foo.1 Bar.B 1021 or Foo.3 Bar.A 1022 Foo.2 1024 These examples are invalid since the following global orderings are 1025 not consistent with the namespace-internal order: 1026 o In Example 1, Bar.A is ordered higher than Bar.B; 1027 o In Example 2, Bar.A is ordered higher than Bar.B and Bar.C; 1028 o In Example 3, Foo.1 is ordered higher than Foo.2 and Foo.3; 1029 o In Example 4, Foo.1 is ordered higher than Foo.3 and Foo.2; 1031 9. Registering Namespaces 1033 Organizations considering the use of the Resource-Priority header 1034 field should investigate if an existing combination of namespace and 1035 priority-values meets their needs. For example, emergency first 1036 responders around the world are discussing utilizing this mechanism 1037 for preferential treatment in future networks. There should not be a 1038 unique namespace for different jurisdictions. This will greatly 1039 increase interoperability and reduce development time, and probably 1040 reduce future confusion if there is ever a need to map one namespace 1041 to another in an interworking function. 1043 Below, we describe the steps necessary to register a new namespace. 1045 A new namespace MUST be defined in a Standards Track RFC, following 1046 the 'Standards Action' policy in [RFC2434] and MUST include the 1047 following facets: 1049 o It must define the namespace label, a unique namespace label 1050 within the IANA registry for the SIP Resource-Priority header 1051 field. 1052 o It must enumerate the priority levels, i.e., 'r-priority' values, 1053 the namespace is using. Note that only finite lists are 1054 permissible, not (e.g.,) unconstrained integers or tokens. 1056 o The priority algorithm (Section 4.5), identifying whether the 1057 namespace is to be used with priority queueing ("queue") or 1058 preemption ("preemption"); if queueing is used, the namespace MAY 1059 indicate whether normal-priority requests are queued. If there is 1060 a new "intended algorithm" other than preemption or priority 1061 queueing, the algorithm must be described, taking into account all 1062 RP actors (UAC, UAS, proxies). 1063 o A namespace may either reference an existing list of priority 1064 values or define a new finite list of priority values in relative 1065 priority order for IANA registration within the sip-parameters 1066 Resource-Priority priority-values registry. New priority-values 1067 SHOULD NOT be added to a previously IANA-registered list 1068 associated with a particular namespace, as this may cause 1069 interoperability problems. Unless otherwise specified, it is 1070 assumed that all priority value confer higher priority than 1071 requests without a priority value. 1072 o Any new SIP response codes unique to this new namespace need to be 1073 explained and registered. 1074 o The reference document must specify and describe any new Warning 1075 header field warn-codes (RFC 3261, Section 27.2). 1076 o The document needs to specify a new row for the following table 1077 that summarize the features of the namespace and are included into 1078 IANA Resource-Priority Namespace registration: 1080 Intended New New resp. 1081 Namespace Levels algorithm warn-code code Reference 1082 --------- ------ ---------------- --------- -------- --------- 1083