idnits 2.17.1 draft-ietf-rsvp-policy-oops-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 58 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([Ext]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'Note 1' is mentioned on line 320, but not defined == Missing Reference: 'Note 2' is mentioned on line 324, but not defined == Missing Reference: 'Note 3' is mentioned on line 406, but not defined == Missing Reference: 'Note 4' is mentioned on line 501, but not defined == Missing Reference: 'Note 5' is mentioned on line 553, but not defined == Missing Reference: 'Note 6' is mentioned on line 600, but not defined == Missing Reference: 'Note 7' is mentioned on line 601, but not defined == Missing Reference: 'Note 8' is mentioned on line 647, but not defined == Missing Reference: 'Note 9' is mentioned on line 650, but not defined == Missing Reference: 'Note 10' is mentioned on line 746, but not defined == Missing Reference: 'Note 11' is mentioned on line 750, but not defined == Missing Reference: 'Note 12' is mentioned on line 799, but not defined == Missing Reference: 'Note 13' is mentioned on line 1044, but not defined == Unused Reference: 'Arch' is defined on line 1335, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-rsvp-md5-02 -- No information found for draft-ietf-RSVPSP - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RSVPSP' -- Unexpected draft version: The latest known version of draft-ietf-rsvp-policy-arch is -00, but you're referring to -01. (However, the state information for draft-ietf-RSVPSP is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. 'Arch' -- Unexpected draft version: The latest known version of draft-ietf-rsvp-policy-lpm is -00, but you're referring to -01. (However, the state information for draft-ietf-RSVPSP is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. 'LPM' == Outdated reference: A later version (-05) exists of draft-ietf-rsvp-policy-ext-02 -- Possible downref: Normative reference to a draft: ref. 'Ext' Summary: 10 errors (**), 0 flaws (~~), 19 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Shai Herzog 3 Expiration: Oct. 1997 Dimitrios Pendarakis 4 File: draft-ietf-rsvp-policy-oops-00.txt Raju Rajan 5 Roch Guerin 6 IBM T.J. Watson Research Center 7 Apr. 1997 9 Open Outsourcing Policy Service (OOPS) for RSVP 11 03/19/97 13 Status of Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Abstract 33 This document describes a protocol for exchanging policy information 34 and decisions between an RSVP-capable router (client) and a policy 35 server. The OOPS protocol supports a wide range of router 36 configurations and RSVP implementations, and is compatible with the 37 RSVP Extensions for Policy Control [Ext]. 39 Internet Draft OOPS: Policy Protocol for RSVP 41 Table of Contents 43 1 Overview 4 45 1.1 Representative OOPS Scenarios .......................... 4 47 2 Query-Response Protocol 6 49 2.1 Division of Labor between Client and Server ............ 6 51 2.1.1 Error Reporting ................................. 7 53 2.2 State Management ...................................... 8 55 2.2.1 Client State Information Cached at Server ........ 9 57 2.2.2 Server State Information Cached at Client ........ 9 59 2.2.3 State Change Notification ........................ 10 61 3 Client-Server Communications 10 63 3.1 Connection Establishment .............................. 10 65 3.1.1 Secure Communications ............................ 11 67 3.2 Reliable Communication ................................. 11 69 3.2.1 Sequence Numbers ................................ 12 71 3.2.2 Receiver initiated retransmit .................... 12 73 3.2.3 Keep-Alive Messages ............................. 12 75 3.2.4 Overhead ........................................ 13 77 3.3 Connection Termination ................................ 13 79 3.3.1 Explicit Termination ............................ 13 81 3.3.2 Implicit Termination ............................ 13 83 3.3.3 Post Termination ................................. 14 85 3.3.4 Switching to An Alternative Server .............. 14 87 4 OOPS Message Format 15 89 Internet Draft OOPS: Policy Protocol for RSVP 91 4.1 OOPS Operations ....................................... 16 93 4.1.1 Null-Notification (a.k.a Keep-Alive) ............. 17 95 4.1.2 Connection-Initiation-Query ..................... 17 97 4.1.3 Connection-Accept-Response ...................... 17 99 4.1.4 Connection-Reject-Response ...................... 18 101 4.1.5 Bye-Notification ................................ 18 103 4.1.6 Incoming-Policy-Query ........................... 18 105 4.1.7 Incoming-Policy-Response ........................ 19 107 4.1.8 Outgoing-Policy-Query ........................... 19 109 4.1.9 Outgoing-Policy-Response ........................ 19 111 4.1.10 Status-Query ................................... 20 113 4.1.11 Status-Response ................................ 20 115 4.1.12 Delete-State-Notification ...................... 21 117 4.1.13 Schedule-RSVP-Notification ..................... 21 119 4.1.14 Client-Status-Notification ..................... 22 121 4.1.15 Resend-Notification ............................ 22 123 4.1.16 Error-Notification ............................. 22 125 4.2 Fields format ......................................... 23 127 5 Acknowledgment 25 129 Internet Draft OOPS: Policy Protocol for RSVP 131 1. Overview 133 Open Outsourcing Policy Service (OOPS) is a protocol for exchanging 134 policy information and decisions between an RSVP-capable router 135 (client) and a policy server. As the name suggests, OOPS is an 136 outsourcing protocol which allows the partial or complete delegation 137 of the task of policy control from the local router to an external 138 server. Moreover, it is an open protocol in a sense that it does not 139 define or depend on particular policies; instead, it provides a 140 framework for adding, modifying and experimenting with new policies 141 in a modular, plug-n-play fashion. 143 The OOPS protocol was designed to be compatible with the RSVP 144 Extensions for Policy Control [Ext], both in the format of RSVP 145 objects, as well as the set of supported services. 147 The basic features of OOPS design are as follows: 149 Asymmetry between client and server 151 Adding policy support to RSVP may require substantial 152 modifications to platforms (e.g., routers) which may not have 153 the required implementation flexibility and/or processing power. 154 OOPS assumes that the server is more sophisticated than the 155 client, in terms of processing power and support for diverse 156 policies. 158 Support for a wide range of client implementation 160 The OOPS protocol supports a wide range of client 161 implementations. At one end of the spectrum, a "dumb" client 162 may delegate total responsibility to the server for all policy 163 decisions without even maintaining cached states. At the other 164 end, smart clients can perform most policy processing locally 165 and only address the server for a small number of policies and 166 only when they change (otherwise, cache can be used). 168 Minimal knowledge of RSVP's processing rules. 170 The server must be aware of the format of several RSVP objects 171 and basic RSVP message types. However, it is not required to 172 understand RSVP's processing rules (e.g., different reservation 173 styles). 175 Asynchronicity 177 Both client and server may asynchronously generate queries or 178 requests. 180 Internet Draft OOPS: Policy Protocol for RSVP 182 TCP for reliable communications 184 TCP is used as a reliable communication protocol between client 185 and server. 187 1.1 Representative OOPS Scenarios 189 Figure 1 depicts some representative scenarios for policy control 190 along an RSVP path, as envisioned in OOPS. Nodes A, B and C 191 belong to one administrative domain AD-1 (advised by policy server 192 PS-1), while D and E belong to AD-2 and AD-3, respectively. 194 AD-1 AD-2 AD-3 195 _______________/\___________ __/\__ __/\__ 196 { } { } { } 198 +------+ +------+ +------+ +------+ +------+ 199 +----+ | A | | B | | C | | D | | E | +----+ 200 | S1 |--| RSVP |---| RSVP |---| RSVP |---| RSVP |---| RSVP |--| R1 | 201 +----+ +------+ +------+ +------+ +------+ +------+ +----+ 202 | LPM | | LPM | | LPM | | LPM | 203 +------+ +------+ +------+ +------+ 204 \ / | 205 \ / +------+ 206 \ / |Policy| 207 \ / |Server| 208 \ / | PS-2 | 209 \ / +------+ 210 +------+ 211 |Policy| 212 |Server| 213 | PS-1 | 214 +------+ 216 Figure 1: Policy Control along an RSVP path 218 The scenario includes four typical node types: 220 (1) Policy incapable nodes: Node B. (2) Self-sufficient policy 221 node: Node D is self-sufficient since its local LPM satisfies its 222 entire policy needs. (It has no need for server advice.) (3) 223 "Dumb" policy nodes: Node E is an unsophisticated node that lacks 224 processing power, code support or caching capabilities, and needs 225 to rely on PS-2 for every policy processing operation. In this 226 case, the volume of traffic and delay requirements make it 228 Internet Draft OOPS: Policy Protocol for RSVP 230 imperative to connect PS-2 to node E by a direct link or a LAN. 231 (4) "Smart" policy nodes: Nodes A and C include sophisticated 232 LPMs, in that these nodes can process some policies, and have the 233 capacity to cache responses from PS-1. In this case, the contact 234 between the clients and server will be limited to occasional 235 updates, and PS-1 could be located somewhere in AD-1. 237 Consider the case where the receiver R1 sends a Resv message 238 upstream toward sender S1. Assuming that the reservation is 239 successful, the conceptual flow of policy objects is: 241 R1 -- E -- ELPM -- PS-2 -- ELPM -- E -- D -- DLPM -- D -- C -- CLPM 242 -- PS-1 -- CLPM -- C -- B -- A -- ALPM -- PS-1 -- ALPM -- A -- S1. 244 Of course, other OOPS messages may be exchanged between policy 245 servers and nodes before authorizing the reservation at individual 246 nodes. 248 2. Query-Response Protocol 250 OOPS is a transaction protocol, in which most communication is in the 251 form of queries from the client followed by responses from the 252 server. However, a small portion of the communication may also 253 consist of queries originating from the server, or of unidirectional 254 notifications from one entity to another. In this context, it is 255 important that messages be distinguished by a unique sequence number, 256 so that responses may identify the query to which they correspond. 258 This section discusses two fundamental concepts of the OOPS protocol: 259 (a) flexible division of labor between client and server. (b) 260 consistent management of client, server and RSVP state. 262 2.1 Division of Labor between Client and Server 264 The OOPS protocol allows for a flexible division of 265 responsibilities between server and client. Processing of policies 266 (policy elements within POLICY_DATA objects) can be performed by 267 the server, the client, or by both. The decision on which 268 policies are to be handled locally and which are to be sent to the 269 server is always made by the client based on information exchanged 270 during the connection establishment handshake (see Section 3.1). 272 Before the client forwards incoming POLICY_DATA objects to the 273 server (Incoming-Policy-Query) it removes or marks the policy 274 elements it wishes the server to ignore. (Marking is performed by 275 changing the policy element P-type to zero.) When forwarding 276 incoming policy objects, the client may also set header flags to 277 inform the server that message integrity and/or rsvp hop has been 279 Internet Draft OOPS: Policy Protocol for RSVP 281 already checked. 283 OOPS does not impose limitations on the number of servers 284 connected to the client; when appropriate, the client could divide 285 the work along policy lines between several servers, and be 286 responsible for combining their results. In the rest of this 287 document we describe the protocol for a single server-client pair. 289 When the client receives outgoing POLICY_DATA objects in response 290 to a previous query (Outgoing-Policy-Response) it is responsible 291 for merging the server response with the locally generated 292 outgoing POLICY_DATA object. Merging is performed by 293 concatenating the local and server policy elements and if 294 necessary, computing some of the POLICY_DATA object fields (e.g., 295 length, INTEGRITY, etc.) 297 When the client receive status results in response to a previous 298 query (Status-Policy-Response) it is responsible for merging the 299 results from the server with the local results. The following 300 rule applies for combining any number of policies, and 301 specifically, local and server policies: 303 o When responding to a status query (authorization check), 304 individual policy handlers may vote to ACCEPT, SNUB or VETO 305 the request. As their names suggest, a vote of accept 306 authorizes the request; a snub fails it, but remains 307 indifferent on its final outcome (i.e., other policies could 308 provide authorization); a veto vote excludes the possibility 309 of authorizing the request, even if other policy handlers 310 cast accept votes. 312 o The merge result provides an authorization if there is at 313 least one accept, and no vetoes. [Note 1] 314 (See [LPM]) for more details). 316 o The client and/or server should complete their policy 317 processing even if a veto was cast by some policy. [Note 2] 319 _________________________ 320 [Note 1] A veto has a stronger semantics than a snub, since it has the 321 power to forcefully reject a flow regardless of any accept decisions 322 made by others. 324 [Note 2] A wide range of policies may not care about the final status 325 results and should be activated regardless. For instance: a policy that 326 logs all policy queries. 328 Internet Draft OOPS: Policy Protocol for RSVP 330 o Protocol errors are always considered as snubs, and thus, 331 neutral. 333 It is recommended (although not required) that all local status 334 processing at the client be completed before querying the server. 335 This allows the server to immediately commit the transaction 336 rather than having to wait until the client is done. (See the 337 Client-Status-Notification operation.) 339 2.1.1 Error Reporting 341 Policy error reporting is policy specific; it is performed by 342 sending POLICY_DATA objects with specific error objects toward 343 the originator of the error. The rules governing error 344 reporting are described in [Ext]. 346 In this document, we discuss only error reporting between the 347 client and the server, which is intended to help the client 348 determine whether error reporting is required at all. 350 There are two types of possible errors; policy errors and 351 protocol errors. For the purpose of this protocol, policy 352 errors are considered as legitimate results (e.g., reject) and 353 not as errors. Protocol errors must be reported as such. 354 However, since they do not reveal any policy decisions they 355 should always be considered as snubs (and therefore neutral to 356 the overall policy decision). 358 When the client (or server) discovers a protocol error (syntax, 359 missing parameters, etc.), it is reported alongside and 360 orthogonal to the status results (accept, reject or veto). 362 Internet Draft OOPS: Policy Protocol for RSVP 364 2.2 State Management 366 In order for policy objects contained in RSVP messages to be 367 processed quickly and correctly, it is often required that the 368 results of past policy decisions be cached and maintained at the 369 LPM or the policy server. Maintenance of policy state must be 370 done in a manner that is consistent with the division of 371 responsibility for policy processing between client and server and 372 with RSVP's state management rules. [Note 3] 374 The most straightforward method for state maintenance is for the 375 LPM and the policy server to use the same soft-state mechanism as 376 the RSVP capable router. Unfortunately, this soft-state approach 377 has undesirable scaling properties since it requires the client to 378 contact the server on each refresh period (regardless of state 379 changes). 381 An alternative approach is to allow both client and server to use 382 hard-state mechanisms that could limit the client-server 383 communication to updates only. This alternative implies that the 384 client must be capable of recognizing objects that would result in 385 a change of policy state, as well as being able to translate 386 between the soft-state provided by RSVP and the hard-state 387 exchanged with the server. 389 Thus, we envision one end of the spectrum where a "dumb" client 390 would use a soft-state approach and simply pass all policy objects 391 to the server relying on it for all policy processing. The rate 392 of queries and lack of caching at the client implies the need for 393 a dedicated, close-by server (PS-2, in our example). As we move 394 towards the other extreme, clients become smarter, more capable of 395 caching, and dividing the work between themselves and the server. 396 Such clients could take advantage of the benefits of hard-state 397 management, and initiate queries only on actual state updates. 399 OOPS supports soft and hard state mechanisms seamlessly, as 400 described in this section. The client determines its desired type 401 of state management, and communicates it on an object-by-object 402 basis. A single client can use soft-state for some information, 403 and hard state for others. Furthermore, the OOPS protocol allows 404 clients to modify their caching strategies on the fly (without 405 _________________________ 406 [Note 3] During normal processing, state split between client and server 407 should remain consistent, and timeout at roughly the same time at RSVP, 408 the client, and the server. 410 Internet Draft OOPS: Policy Protocol for RSVP 412 having to renegotiate with the server). While the protocol does 413 not impose strategy limitations, a client implementation could 414 restrict itself to a more modest and simple combination of soft 415 and hard state. 417 There are two types of state information that is stored at the 418 client: (a) client state information that was forwarded to the 419 server (e.g., policy objects in incoming Path/Resv messages). (b) 420 server state which is cached at the client (e.g., policy results 421 computed by the server). The OOPS protocol addresses each of these 422 types of states: 424 2.2.1 Client State Information Cached at Server 426 The client indicates that it desires hard (or soft) state 427 management of client state information cached at the server by 428 setting (or resetting) the OOPS_HardState flag in objects sent 429 to the server. When the client chooses soft-state management 430 for a particular object, policy state for that object would age 431 and expire at the server according to the timeout specified in 432 the object. The client must, therefore, forward each policy 433 refresh (update or not) to the server, to keep the soft-state 434 at the server from becoming stale and expiring. On the other 435 hand, when the client indicates hard-state management, it 436 assumes responsibility for reliably informing the server on 437 every policy update. In this case, the state cached at the 438 server would not expire unless explicitly modified by the 439 client, or when the communication channel to the client breaks. 440 The client may refrain from forwarding to the server any policy 441 objects that are identical to objects previously sent to the 442 server. 444 The client may switch between hard and soft states on the fly 445 by modifying the OOPS_HardState flag while forwarding input to 446 the server. 448 2.2.2 Server State Information Cached at Client 450 The client indicates that it is capable of hard (or soft) state 451 management of server state information by setting (or 452 resetting) the OOPS_HardState flag in queries sent to the 453 server. Here, hard state management refers to the caching of 454 response results at the client. Soft state management means 455 that the client, being incapable of caching, would purge them 456 after usage (one-time, or disposable results). 458 A non-cached response has no strings attached, but the client 459 must issue a query each time that responses are needed. When 461 Internet Draft OOPS: Policy Protocol for RSVP 463 the server responds to a cached (hard-state) query, it assumes 464 responsibility to reliably inform the client about any changes 465 that may occur later to the original results of this query. 466 The client may rely on cached results as long as the there is 467 no change in RSVP's state (which includes incoming policy 468 objects), [Note 4] 469 and the communication channel with the server is intact. 471 The client may switch between hard and soft states on the fly 472 by issuing a new query with a modified flag. 474 2.2.3 State Change Notification 476 State change notification is done by resending the same type as 477 the original message but with the modified state instead. 479 Client notification example (incoming POLICY_DATA objects for 480 Resv-X): 482 Seq# Type Data 483 --- ---- ---- 484 Client ==> Server: 50 Notify:input Resv-X: PD-1 486 Time passes; the input POLICY_DATA object associated with 487 Resv-X changed to PD-2. 489 Client ==> Server: 90 Notify:input Resv-X: PD-2 491 Server notification example (status query for reservation 492 Resv-X): 494 Seq# Type Data 495 --- ---- ---- 496 Client ==> Server: 150 Query:status Resv-X 497 Server ==> Client: 151 Resp :status #150: accept 499 Time passes; the status of Resv-X changed to "reject". 500 _________________________ 501 [Note 4] A configurable option may allow the client to use cached 502 results even when some RSVP state changes. Clearly, there is a trade- 503 off between fast and accurate policy processing, however, given that the 504 server is up, and that authorization was already granted previously for 505 that RSVP flow, some may find it a reasonable policy approach. 507 Internet Draft OOPS: Policy Protocol for RSVP 509 Server ==> Client: 205 Resp :status #150: reject 511 3. Client-Server Communications 513 This section describes the fundamentals of client-server 514 communications: connection establishment, communication channel 515 management, and connection termination. 517 3.1 Connection Establishment 519 Connections are always initiated by clients. The client 520 establishes a TCP connection to its preferred policy server, and 521 then initiates the OOPS session through a two way handshake. 523 o Communication Initiation by the Client 525 The client sends a Connection-Initiation-Query to the server. 526 This message identifies the client to the server and provides 527 the basic characteristics of the client. 529 o Response by the Server 531 The server responds with a Connection-Accept-Response to 532 connect to the client. It may also respond with a 533 Connection-Reject-Response to refuse and disconnect from the 534 client. 536 After connection establishment both the client and server 537 know the set of policies that the client can send to the 538 server, and which one of them should handle default 539 (unrecognized) policies. The Keep-Alive period is determined 540 as the minimum between the two values declared in the 541 handshake messages. 543 3.1.1 Secure Communications 545 The integrity of the communication channel between client and 546 server is guaranteed by the use of shared-key message digest. 547 (e.g., keyed MD5). A client, wishing to establish secure 548 communications adds a "Cookie" to the Connection-Initiation- 549 Query. The server may respond with a reply Cookie or with an 550 Error-Description [Note 5] 552 _________________________ 553 [Note 5] The Error-Description provides reasons for rejecting the secure 554 communications request. 556 Internet Draft OOPS: Policy Protocol for RSVP 558 Shared keys may be obtained from local static configurations or 559 could be distributed dynamically. The exchange of cookies 560 provides the client and server with an opportunity for 561 establishing a temporary shared-key (e.g., from Kerberos) for 562 the connection length. 564 Once a shared key is available, each message sent by either 565 client or server includes an INTEGRITY object as described in 566 [Bak96]. The format and functionality of the INTEGRITY object 567 are identical to that of RSVP. The sender client or server 568 computes the message digest over the entire OOPS message; if 569 the receiver fails to verify the message, it response with an 570 error message. 572 The format of "cookies" is left for future versions of this 573 document. 575 3.2 Reliable Communication 577 We expect TCP to provide us with reliable, in-order delivery of 578 packets, as well as information on the liveliness of the 579 communication channel. Given that TCP is responsible for all the 580 time critical network operations, reliability errors are assumed 581 to be virtually nonexistent. However, to maintain application- 582 level reliability, OOPS uses a minimalistic reliability mechanism 583 using sequence numbers, selective retransmit and keep-alive 584 messages. This requires no retransmission timeouts, and has low 585 overhead. 587 3.2.1 Sequence Numbers 589 Each OOPS message, except a Resend-Notification, is uniquely 590 identified by a sequence number [Note 6] 591 (Mseq). These numbers do not imply any order of execution; 592 while the server receives messages in-order, it is free to 593 execute them in any reasonable order. [Note 7] 595 In addition, each message also carries the sequence number of 596 the last received message (Rseq). Both client and server begin 597 communication with Mseq = 0 (the handshake message), and number 598 consecutive messages in increasing order. 599 _________________________ 600 [Note 6] Not counting wraparounds 601 [Note 7] Execution order is implementation and policy specific; any 602 order that does not violate the policy specific requirements is assumed 603 to be reasonable. 605 Internet Draft OOPS: Policy Protocol for RSVP 607 A transmitted message with Mseq = m is considered to be 608 acknowledged if m <= Rseq (Rseq from the latest received 609 message). [Note 8] 611 The sender must be prepared to retransmit (as requested) any 612 message that has not been acknowledged yet. Missing, or out- 613 of-order messages are identified by a gap in sequence numbers 614 of received messages. 616 3.2.2 Receiver initiated retransmit 618 When the receiver (client or server) detects missing messages 619 it immediately sends an explicit Resend-Notification listing 620 these messages. The Resend-Notification has a sequence number 621 0. [Note 9] 623 Upon receiving the Resend-Notification, the sender must 624 retransmit all the requested messages before sending new ones. 626 3.2.3 Keep-Alive Messages 628 Many platforms provide system support for detecting broken TCP 629 connections. OOPS can utilize, but does not depend on such 630 mechanisms. Instead, it relies on Keep-Alive messages to 631 provide application-level communication-channel verification, 632 as a server may be in a dysfunctional state while its TCP 633 connection is still open and viable. 635 The client sends a Keep-Alive message to the server only after 636 the receiving channel has been idle for longer than the Keep- 637 Alive period. The server responds promptly with a Keep-Alive 638 ack. 640 3.2.4 Overhead 642 These reliability mechanisms were designed to be simple and 643 impose minimal overhead in a busy working environment. When 644 the client supports a large number of RSVP sessions and has 645 frequent message exchange with the server, it would not be 646 _________________________ 647 [Note 8] Mseq <= Rseq should take into account possible wrap-around of 648 sequence numbers. 650 [Note 9] Thus, Resend-Notification cannot participate in sequence number 651 reliability verification. A lost Resend-Notification cannot not be 652 detected, however, a new one is bound to be triggered sometime again. 654 Internet Draft OOPS: Policy Protocol for RSVP 656 sending Keep-Alive messages. Similarly, since TCP is used for 657 reliable communications, there is a virtually zero probability 658 that Resend-Notification messages would be required. The only 659 timer required is for the Keep-Alive period; the timer is reset 660 on each message arrival and a Keep-Alive message is initiated 661 only when it expires. 663 3.3 Connection Termination 665 This section describes how communication breakdown is handled. 667 3.3.1 Explicit Termination 669 The client (or server) may terminate the connection by sending 670 a Bye-Notification, and wait until either it receives an echoed 671 Bye-Notification or a Keep-Alive period had passed. In between, 672 it should ignore incoming messages (and not reset the Keep- 673 Alive timer). 675 At the opposite side, when a client (or server) receive a Bye- 676 Notification message, they should echo it, and close the 677 connection. 679 After an explicit termination, both client and server may 680 cleans up and purges the state related to the closed 681 connection. 683 3.3.2 Implicit Termination 685 The communication channel may be unexpectedly disconnected 686 because of a misbehaving client or server, network split, or 687 other reasons. Both client and server must be able to detect 688 such channel failures and act accordingly. 690 Consider the case where OOPS is used for quota enforcement. 691 The server may approve a reservation while debiting X/min from 692 a local account. If the OOPS communication channel breaks, it 693 is critical for the server to detect it and stop debiting this 694 account. 696 A communication channel is assumed to be disconnected when the 697 channel was idle (no message was received on it) for over two 698 Keep-Alive periods. 700 3.3.3 Post Termination 702 Soft-state has an inherent cleanup mechanism; when the channel 703 disconnects, the soft-state would age and eventually expire 705 Internet Draft OOPS: Policy Protocol for RSVP 707 based on the same mechanism and refresh-period used by RSVP. 709 When hard-state is used, cached state is assumed to be valid 710 unless explicitly modified. However, when the channel 711 disconnects such an explicit notification is not possible. 712 Purging all state immediately upon disconnection is not an 713 acceptable approach since it may cause a disruption of service 714 before an alternate server is contacted. OOPS uses the 715 following simple rule: 717 When the communication channel disconnects, the hard state 718 associated with it is assumed to be soft-state that was just 719 refreshed. 721 Naturally, when any RSVP state changes (e.g., routing changes, 722 policy input changes, etc.), cached results at the client 723 should not be used and must be purged. 725 3.3.4 Switching to An Alternative Server 727 We assume that the client is provided a list of policy servers 728 and site specific selection criteria. 730 A switch to an alternate server may be triggered by a voluntary 731 disconnection (i.e., Bye-Notification) or an unexpected break 732 in the communication channel. 734 During normal operations, the client may wish to switch to an 735 alternate server (for any reason). The client is advised to 736 first connect to the new server before sending a Bye- 737 Notification to the original one. If the communication channel 738 unexpectedly disconnects, the client should quickly attempt to 739 connect to an alternate server. 741 In both cases, after the connection to a new server [Note 10] 742 is established, the aging cached state from the old server 743 would be gradually replaced by responses from the new server. 744 [Note 11] 745 _________________________ 746 [Note 10] The term "new server" may be the same as the "previous 747 server"; it may happen that the connection encounters a problem and the 748 client chooses to disconnected and re-established the connection. 750 [Note 11] The client could speed-up replacement of cached state by 751 sending copies of cached input to the server and issuing repeated 752 queries, on connection establishment (instead of waiting until objects 753 arrive from RSVP). 755 Internet Draft OOPS: Policy Protocol for RSVP 757 As general guidelines, state replacement from a new server 758 should not cause a disruption of service that would not 759 otherwise occur (if a new server was not found). [Note 12] 761 4. OOPS Message Format 763 OOPS messages serve as a wrapper that may include one or more 764 protocol operations; this wrapper allows common operation (e.g., MD5 765 integrity, RSVP_HOPs, protocol version, etc.) to be verified and 766 performed in one-shot. 768 +---------------+---------------+---------------+---------------+ 769 | Vers | Flags | op-objs# | Reserved (0) | 770 +---------------+---------------+---------------+---------------+ 771 | Message Length | 772 +---------------+---------------+---------------+---------------+ 773 | Message Sequence Number | 774 +---------------+---------------+---------------+---------------+ 775 | Ack-ed Sequence Number | 776 +---------------+---------------+---------------+---------------+ 777 | INTEGRITY Object... (optional) | 778 +---------------+---------------+---------------+---------------+ 779 | List of operations | 780 +---------------+---------------+---------------+---------------+ 782 Any OOPS message is composed of the following fields: 784 Version: 8 bits 786 Protocol version number. The current version is 1. 788 Flags: 8 bits 790 0x01 H_Integrity_Checked Integrity already checked by client 791 0x01 H_Hops_Checked RSVP_HOPs already checked by client 793 op-objs#: 8 bits 795 Number of objects included in this message. 797 Message Length: 32 bits 798 _________________________ 799 [Note 12] Practically, this means that as long as there is no change in 800 RSVP messages, the client is advised to choose between cached and new 801 results in favor of authorizing the request. 803 Internet Draft OOPS: Policy Protocol for RSVP 805 The total length of this OOPS message in bytes. 807 Message Sequence Number: 32 bits 809 The sequence number of the message being sent. 811 Ack-ed Sequence Number: 32 bits 813 The sequence number of the last message received in-order from 814 the peer entity (client or server). 816 RSVP INTEGRITY Object (optional): variable length 818 This object is defined in [Bak96]. It provides a message digest 819 based on a shared key between the client and sender. The message 820 digest is calculated over the entire OOPS message. 822 List of OOPS operations: variable length 824 Described in the following section. 826 4.1 OOPS Operations 828 Each OOPS message may contain multiple OOPS operations each 829 encapsulating a different query, response or notification. For 830 example, multiple Incoming-Policy-Queries might be followed by a 831 Status-Query operation in the same message. Operations within an 832 OOPS message are sequentially numbered. 834 Individual OOPS operations have the following header: 836 +---------------+---------------+---------------+---------------+ 837 | Operation Type| Op. Subtype | Op. Seq# | Flags | 838 +---------------+---------------+---------------+---------------+ 839 | Length (bytes) | 840 +---------------+---------------+---------------+---------------+ 841 | | RSVP's Refresh Period | 842 +---------------+---------------+---------------+---------------+ 844 The operation header has the following fields: 846 operation Type: 8 bits 848 The type of OOPS operation. 850 Operation Subtype: 8 bits 852 Internet Draft OOPS: Policy Protocol for RSVP 854 This field can be used to indicate an attribute of the 855 operation type, such as its version; currently it is always 856 set to 1. 858 Operation Sequence Number: 8 bits 860 The operation sequence number within the message. 862 Flags: 8 bits 864 0x01 OOPS_HardState: Hard State (soft-state if not set (0) ) 865 0x02 OOPS_Shared : Resv shared among sources as filter specs 866 0x02 OOPS_FullList : Last in the set of status queries. 868 Length: 32 bits 870 Contains the total operation length in bytes. 872 RSVP's Refresh Period 874 The refresh-period RSVP associates with this object. 876 This remainder of this section describes the set of operations 877 that may appear in OOPS messages. Many data fields of these 878 operations are RSVP objects; they are typed in uppercase letters 879 and their format is defined in [RSVPSP]. The format of other 880 operations is listed in the following section. 882 4.1.1 Null-Notification (a.k.a Keep-Alive) 884 Operation Type = 0, sub-type = 0 886 ::= 888 This empty or null notification triggers no operation; thus, 889 can be used as as Keep-Alive signal to test the viability of 890 the communication channel between client and server (see 891 Section 3.2.3). 893 4.1.2 Connection-Initiation-Query 895 Operation Type = 1, sub-type = 1 897 ::= 898 899 901 Internet Draft OOPS: Policy Protocol for RSVP 903 904 905 907 The client sends this query to establish a connection with a 908 server. This message is sent following the establishment of a 909 transport connection (TCP). 911 4.1.3 Connection-Accept-Response 913 Operation Type = 2, sub-type = 1 915 ::= 916 917 918 920 The server sends this response to accept a client's connection 921 connection request. 923 4.1.4 Connection-Reject-Response 925 Operation Type = 3, sub-type = 1 927 ::= 928 930 The server sends this response to reject a client's connection 931 initiation. It specifies both reason code and text. 933 4.1.5 Bye-Notification 935 Operation Type = 4, sub-type = 1 937 ::= 939 This message is used by either client or server to terminate 940 the OOPS connection. (Section 3.3.1 includes a description of 941 explicit termination ) 943 4.1.6 Incoming-Policy-Query 945 Operation Type = 5, sub-type = 1 947 ::= 948 949 951 Internet Draft OOPS: Policy Protocol for RSVP 953 954 955 956 958 This operation is used to forward POLICY_DATA objects from the 959 client to the server. Selection between hard and soft state 960 management is reflected in the OOPS_HardState flag. The other 961 fields are copied from the PC_InPolicy() function called by 962 RSVP. (See [Ext]). 964 4.1.7 Incoming-Policy-Response 966 Operation Type = 6, sub-type = 1 968 ::= 969 970 972 Incoming-Policy-Response is used ONLY to report protocol errors 973 (e.g., syntax) found with incoming policy objects. (it is not 974 used in the normal operation of the protocol). 976 The links the response to the original 977 query. 979 4.1.8 Outgoing-Policy-Query 981 Operation Type = 7, sub-type = 1 983 ::= 984 985 986 987 988 990 This operation queries the server for a set of outgoing policy 991 objects for a set of RSVP_HOPs. The client can choose between 992 hard and soft state management through the OOPS_HardState flag. 993 When hard state is selected, the client caches copies of the 994 outgoing objects and assumes they remain valid unless 995 explicitly modified by the server. 997 4.1.9 Outgoing-Policy-Response 999 Operation Type = 8, sub-type = 1 1001 Internet Draft OOPS: Policy Protocol for RSVP 1003 ::= 1004 1005 1006 { 1007 1008 1009 } pair list 1011 The links the response to the original 1012 query. 1014 In the response, the server provides a list of triplets, one 1015 for each outgoing RSVP_HOP (For Path messages, only the LIH 1016 part is significant). Each triplet contains a list of policy 1017 objects for that hop and an error description. 1019 4.1.10 Status-Query 1021 Operation Type = 9, sub-type = 1 1023 ::= 1024 1025 1026 1027 1028 { } 1030 This operation queries the server for status results of a list 1031 of LIHs. The client can choose between hard and soft state 1032 management through the OOPS_HardState flag. When hard state is 1033 selected, the client caches the status results and assumes they 1034 remain valid unless explicitly modified by the server. 1036 In the upstream direction (e.g., Resv) status may need to be 1037 checked on multiple LIHs (all reservations for a flow). In such 1038 cases, status queries can be perform separately for each LIH, 1039 once for all LIHs, or anything in between. Flag OOPS_FullList 1040 must be set at the last of status query of the series. [Note 1041 13] 1043 _________________________ 1044 [Note 13] When policies are interdependent across LIHs (as when the cost 1045 is shared among downstream receivers), flag OOPS_FullList notifies the 1046 server that the list of reserved LIH is complete and that it can safely 1047 compute the status of these reservations. 1049 Internet Draft OOPS: Policy Protocol for RSVP 1051 4.1.11 Status-Response 1053 Operation Type = 10, sub-type = 1 1055 ::= 1056 1057 1058 { 1059 1060 1061 } pair list 1063 The links the response to the original 1064 query. 1066 In the response, the server provides a list of triplets, each 1067 of which contains an LIH, status, and any applicable error 1068 results. The set of LIHs is an attribute of the results and 1069 not of the query; the server is allowed to respond with a 1070 superset of LIHs specified in the original query, as in the 1071 following example: 1073 Seq# Type Data 1074 --- ---- ---- 1075 Client ==> Server: 150 Query:status Resv-X, LIH={2} 1076 Server ==> Client: 153 Resp :status #150:{2,rej} 1078 Two new reservations arrive, carrying new policy data objects: 1080 Client ==> Server: 160 Query:status Resv-X, LIH={4,7} 1081 Server ==> Client: 169 Resp :status #160:{2,acc;4,acc;7,rej} 1083 4.1.12 Delete-State-Notification 1085 Operation Type = 11, sub-type = 1 1087 ::= 1088 1089 1090 1091 1092 1094 This operation informs the sender about an immediate RSVP 1095 teardown of state caused by PATH_TEAR, RESV_TEAR, routes 1096 change, etc. As a result, the server should ignore the 1097 described state as if it was never received from the client. 1099 Internet Draft OOPS: Policy Protocol for RSVP 1101 Despite its name, this operation can be used to switch between 1102 blockaded and non-blockaded state. 1104 The semantics of this operation is described for PC_DelState() 1105 in [Ext]. 1107 4.1.13 Schedule-RSVP-Notification 1109 Operation Type = 12, sub-type = 1 1111 ::= 1112 1113 1114 1115 1117 The operation results in the generation of an outgoing RSVP 1118 message (Path, Resv, etc.) in the client's RSVP. RSVP should 1119 schedule the requested message to the specified RSVP_HOP. 1121 4.1.14 Client-Status-Notification 1123 Operation Type = 13, sub-type = 1 1125 ::= 1126 1127 1129 The Client notifies the server about the status results 1130 computed at the client (that may also include results from 1131 other servers, if policy computation is spread among several 1132 servers). 1134 The overall status of an RSVP flow is computed by merging the 1135 client's status report with the server's. The server should not 1136 commit a transaction (e.g., charge an account) before knowing 1137 its final status. The Client-Status-Results operation can be 1138 sent with the query, if the client computed its status prior to 1139 making the query. It can also be sent later, after the server 1140 sent its response to the status query. 1142 4.1.15 Resend-Notification 1144 Operation Type = 14, sub-type = 1 1146 ::= 1147 1148 list 1150 Internet Draft OOPS: Policy Protocol for RSVP 1152 Both client and server may issue a Resend-Messsage request when 1153 they detect missing or out-of-order messages. The Resend- 1154 Notification has message sequence number 0. The message 1155 explicitly lists the sequence numbers of all missing messages. 1156 Notice that since OOPS uses a reliable transmission protocol 1157 this list should never be long. (See Section 3.2). 1159 4.1.16 Error-Notification 1161 Operation Type = 6, sub-type = 1 1163 ::= 1164 1165 1167 Error-Notification can be used by either client or server to 1168 report errors associated with an entire message (as opposed to 1169 a specific operation). Error-Notification may be triggered by 1170 both syntax or substantive errors (e.g., failure to verify the 1171 integrity of a previous message). 1173 identified the message that triggered 1174 the error. 1176 Error-Notification is not acked. 1178 4.2 Fields format 1180 o 1182 +---------------+---------------+---------------+---------------+ 1183 | Version | RSVP-K | Flags | 0 | 1184 +---------------+---------------+---------------+---------------+ 1186 Ver: Currently, version 1. 1188 RSVP-K: The K value used by RSVP as a refresh-period 1189 multiplier. 1191 Flags: 1192 0x01 OOPS_CONNECT_DefaultC Client handles default policies. 1194 o 1196 +---------------+---------------+---------------+---------------+ 1197 | Max-Pkt-Size (in KBytes) | Keep-Alive period (in seconds)| 1198 +---------------+---------------+---------------+---------------+ 1200 Internet Draft OOPS: Policy Protocol for RSVP 1202 o 1204 +---------------+---------------+---------------+---------------+ 1205 | Length (total) | Class Code | 1206 +---------------+---------------+---------------+---------------+ 1207 | ASCII String ........ 0 Padded to multiples of 32 bits | 1208 +---------------+---------------+---------------+---------------+ 1210 o 1212 Client address, uses the same format as RSVP's FILTER_SPEC 1213 objects. 1215 From the combination of Client-ID and Class-Indicator the 1216 server can learn about the set of policies it is required to 1217 support for this particular client. 1219 o 1221 +---------------+---------------+---------------+---------------+ 1222 | Length (total) | Type | 0 | 1223 +---------------+---------------+---------------+---------------+ 1224 | Octet String ........ 0 Padded to multiples of 32 bits | 1225 +---------------+---------------+---------------+---------------+ 1227 Currently, no values are defined. 1229 o 1231 +---------------+---------------+---------------+---------------+ 1232 | Number (or pairs) | 0 | 1233 +---------------+---------------+---------------+---------------+ 1234 | From Policy 1 | To Policy 1 | 1235 +---------------+---------------+---------------+---------------+ 1236 +---------------+---------------+---------------+---------------+ 1237 | From Policy n | To Policy n | 1238 +---------------+---------------+---------------+---------------+ 1240 Each "From Policy m" and "To Policy m" pair represent a range 1241 of policies that the server is willing to support. 1243 o 1245 +---------------+---------------+---------------+---------------+ 1246 | Length (*) | Error-Type | Reason Code | 1247 +---------------+---------------+---------------+---------------+ 1248 | Error ASCII String .... 0 Padded to multiples of 32 bits | 1249 +---------------+---------------+---------------+---------------+ 1251 Internet Draft OOPS: Policy Protocol for RSVP 1253 (*) Length of the overall in 4 bytes 1254 increments (i.e., length value of X should be interpreted as 1255 X*4 bytes description and an (X-1)*4 bytes Error ASCII 1256 String. 1258 No errors are reported by setting the length to 1 (4 bytes) 1259 and setting the Error-Type to 0. 1261 Detailed Error-Types and Reason-Codes would be defined in 1262 future versions of this document. 1264 o 1266 +---------------+---------------+---------------+---------------+ 1267 | IntServ or Client-Specific Semantics | 1268 +---------------+---------------+---------------+---------------+ 1270 The server may use the to obtain IntServ and 1271 other low-level information about the reservation. 1273 The current version of this document does not define the 1274 semantics of this field. It may be a pointer into some router 1275 specific data structures (proprietary) or an index into mib 1276 records obtainable through SNMP. 1278 o (and internally, ) 1281 +---------------+---------------+---------------+---------------+ 1282 | | 1283 +---------------+---------------+---------------+---------------+ 1284 | Obj. Seq. Num.| 0 | 1285 +---------------+---------------+---------------+---------------+ 1287 o 1289 +---------------+---------------+---------------+---------------+ 1290 | | 1291 +---------------+---------------+---------------+---------------+ 1293 o 1295 +---------------+---------------+---------------+---------------+ 1296 | Results | 0 | 1297 +---------------+---------------+---------------+---------------+ 1299 Results may have one of the following values: 1301 Internet Draft OOPS: Policy Protocol for RSVP 1303 1 : Accept 1304 2 : Snub 1305 3 : Veto 1307 o 1309 +---------------+---------------+---------------+---------------+ 1310 | Mod-Type | 0 | 1311 +---------------+---------------+---------------+---------------+ 1313 Op-Type values: 1315 1 : Delete State 1316 2 : Block State 1317 3 : Unblock State 1319 5. Acknowledgment 1321 This document reflects feedback from many other RSVP collaborators. 1323 Internet Draft OOPS: Policy Protocol for RSVP 1325 References 1327 [Bak96] F. Baker. RSVP Cryptographic Authentication "Internet-Draft", 1328 draft-ietf-rsvp-md5-02.txt, 1996. 1330 [RSVPSP] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 1331 Resource ReSerVation Protocol (RSVP) Version 1 Functional 1332 Specification. "Internet-Draft", draft-ietf-RSVPSP-14.[ps,txt], 1333 Nov. 1996. 1335 [Arch] S. Herzog Accounting and Access Control Policies for Resource 1336 Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy- 1337 arch-01.[ps,txt], Nov. 1996. 1339 [LPM] S. Herzog Local Policy Modules (LPM): Policy Enforcement for 1340 Resource Reservation Protocols. "Internet-Draft", draft-ietf-rsvp- 1341 policy-lpm-01.[ps,txt], Nov. 1996. 1343 [Ext] S. Herzog RSVP Extensions for Policy Control. "Internet-Draft", 1344 draft-ietf-rsvp-policy-ext-02.[ps,txt], Apr. 1997. 1346 Authors' Address 1348 Shai Herzog Phone: (914) 784-6059 1349 Email: herzog@watson.ibm.com 1350 Dimitrios Pendarakis Phone: (914) 784-7536 1351 Email: dimitris@watson.ibm.com 1352 Raju Rajan Phone: (914) 784-7260 1353 Email: raju@watson.ibm.com 1354 Roch Guerin Phone: (914) 784-7038 1355 Email: guerin@watson.ibm.com 1357 IBM T. J. Watson Research Center 1358 P.O. Box 704 1359 Yorktown Heights, NY 10598