idnits 2.17.1 draft-ietf-rsvp-policy-oops-01.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-18) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 60 lines 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 78 instances of too long lines in the document, the longest one being 13 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 814: '...%% TOO EARLY: WE SHOULD PUT IT IN THE ...' 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 2' is mentioned on line 291, but not defined == Missing Reference: 'Note 3' is mentioned on line 295, but not defined == Missing Reference: 'Note 1' is mentioned on line 287, but not defined == Missing Reference: 'Note 4' is mentioned on line 336, but not defined == Missing Reference: 'Note 5' is mentioned on line 340, but not defined == Missing Reference: 'Note 6' is mentioned on line 383, but not defined == Missing Reference: 'Note 7' is mentioned on line 386, but not defined == Missing Reference: 'Note 8' is mentioned on line 482, but not defined == Missing Reference: 'Note 9' is mentioned on line 518, but not defined == Missing Reference: 'Note 10' is mentioned on line 567, but not defined == Missing Reference: 'PD1' is mentioned on line 615, but not defined == Missing Reference: 'PD2' is mentioned on line 615, but not defined == Missing Reference: 'Resv' is mentioned on line 617, but not defined == Missing Reference: 'PD3' is mentioned on line 621, but not defined == Missing Reference: 'ResvErr' is mentioned on line 628, but not defined == Missing Reference: 'PD1-E' is mentioned on line 627, but not defined == Missing Reference: 'Note 11' is mentioned on line 655, but not defined == Missing Reference: 'Note 12' is mentioned on line 745, but not defined == Missing Reference: 'Note 13' is mentioned on line 750, but not defined == Missing Reference: 'Note 14' is mentioned on line 794, but not defined == Missing Reference: 'Note 15' is mentioned on line 798, but not defined == Missing Reference: 'Note 16' is mentioned on line 839, but not defined == Missing Reference: 'Note 17' is mentioned on line 843, but not defined == Missing Reference: 'Note 18' is mentioned on line 1148, but not defined == Missing Reference: 'Note 21' is mentioned on line 1568, but not defined == Unused Reference: 'Arch' is defined on line 1307, but no explicit reference was found in the text == Unused Reference: 'LPM' is defined on line 1311, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) == 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'Note 19' -- Possible downref: Non-RFC (?) normative reference: ref. 'Note 20' Summary: 13 errors (**), 0 flaws (~~), 31 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Shai Herzog 3 Expiration: Oct. 1997 IPHighway 4 File: draft-ietf-rsvp-policy-oops-01.txt 5 Dimitrios Pendarakis 6 Raju Rajan 7 Roch Guerin 8 IBM T.J. Watson Research Center 10 Open Outsourcing Policy Service (OOPS) for RSVP 12 07/30/97 14 Status of Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 32 Abstract 34 This document describes a protocol for exchanging policy information 35 and decisions between an RSVP-capable router (client) and a policy 36 server. The OOPS protocol supports a wide range of router 37 configurations and RSVP implementations, and is compatible with the 38 RSVP Extensions for Policy Control [Ext]. 40 1. Overview Reservation protocols function by discriminating between 41 users by providing some users with better service at the expense of 42 others. The utility of reservation protocols is sharply degraded in 43 the absence of mechanisms for restricting access to higher service 44 categories and enforcing network and bandwidth usage criteria. In 45 this document, we refer to such mechanisms as "policy control". This 46 term is quite broad; it ranges from simple access control to 47 sophisticated accounting and debiting mechanisms. 49 The policy control component may reside fully within the router (as 50 an add-on module to RSVP). However, it is often advantageous for 51 routers to outsource some of their policy decision making to external 52 entities. Open Outsourcing Policy Service (OOPS) is a protocol for 53 exchanging policy information and decisions between Local Policy 54 Modules (LPMs) located within RSVP-capable routers and one or more 55 external policy servers. OOPS is an open protocol in a sense that it 56 does not define or depend on particular policies; instead, it 57 provides a framework for adding, modifying and experimenting with new 58 policies in a modular, plug-n-play fashion. Moreover, the OOPS 59 protocol supports both partial and complete delegation of policy 60 control. 62 The OOPS protocol was designed to be compatible with the RSVP 63 Extensions for Policy Control [Ext], both in the format of RSVP 64 objects, as well as the set of supported services. 66 The basic features of OOPS are as follows: 68 Asymmetry between client and server 70 Adding policy support to RSVP may require substantial 71 modifications to platforms (e.g., routers) which may not have 72 the required implementation flexibility and/or processing power. 73 OOPS assumes that the server is more sophisticated than the 74 client, in terms of processing power and support for diverse 75 policies. 77 Support for a wide range of client implementation 79 The OOPS protocol supports a wide range of client 80 implementations. At one end of the spectrum, a "dumb" client 81 may delegate total responsibility to the server for all policy 82 decisions without even maintaining cached states. At the other 83 end, smart clients can perform most policy processing locally 84 and only address the server for a small number of sub-policy 85 elements and only when things change (otherwise, cache can be 86 used). 88 Support for different policy interfaces 90 The OOPS protocol allows clients and servers to negotiate the 91 nature and sophistication of their interaction. For instance, 92 responses from the server to the client may be restricted to 93 allow the server to merely accept, deny or remain neutral on 94 reservation requests, while a more sophisticated implementation 95 may allow the server to respond with preemption priorities or 96 other characteristics of the reservation. The negotiation 97 handshake is simple, and may always fall back onto the lowest 98 level of interaction that must always be supported. 100 Minimal knowledge of RSVP's processing rules. 102 The server must be aware of the format of several RSVP objects 103 and basic RSVP message types. However, it is not required to 104 understand RSVP's processing rules (e.g., different reservation 105 styles). Moreover, OOPS functionality is not tied to that of 106 RSVP, and OOPS may be extended to be used by other, non-RSVP, 107 connection setup protocols. 109 Asynchronicity 111 Both client and server may asynchronously generate queries or 112 requests. 114 TCP for reliable communications 116 TCP is used as a reliable communication protocol between client 117 and server. 119 1.1 Glossary 121 Policy 123 Comprehensive set of rules for controlling some aspects of 124 the network. 126 Sub-policies 128 Modular building blocks out of which comprehensive policies 129 are compiled. 131 POLICY_DESC 133 Data representation of policy information (e.g., POLICY_DATA 134 objects in RSVP). 136 Sub-policy element 138 Data representation of sub-policy information, as 139 encapsulated in POLICY_DESC objects. 141 1.2 Representative OOPS Scenarios 143 Figure 1 depicts some representative scenarios for policy control 144 along an RSVP path, as envisioned in OOPS. Nodes A, B and C 145 belong to one administrative domain AD-1 (advised by policy server 146 PS-1), while D and E belong to AD-2 and AD-3, respectively. 148 AD-1 AD-2 AD-3 149 _______________/\___________ __/\__ __/\__ 150 { } { } { } 152 +------+ +------+ +------+ +------+ +------+ 153 +----+ | A | | B | | C | | D | | E | +----+ 154 | S1 |--| RSVP |---| RSVP |---| RSVP |---| RSVP |---| RSVP |--| R1 | 155 +----+ +------+ +------+ +------+ +------+ +------+ +----+ 156 | LPM | | LPM | | LPM | | LPM | 157 +------+ +------+ +------+ +------+ 158 \ / | 159 \ / +------+ 160 \ / |Policy| 161 \ / |Server| 162 \ / | PS-2 | 163 \ / +------+ 164 +------+ 165 |Policy| 166 |Server| 167 | PS-1 | 168 +------+ 170 Figure 1: Policy Control along an RSVP path 172 Policy objects are carried in RSVP messages along the path 173 consisting of four typical node types: 175 (1) Policy incapable nodes: Node B. (2) Self-sufficient policy 176 node: Node D does not need to outsource policy tasks to external 177 servers since its LPM satisfies its entire policy needs. (3) 178 "Dumb" policy nodes: Node E is an unsophisticated node that lacks 179 processing power, code support or caching capabilities, and needs 180 to rely on PS-2 for every policy processing operation. In this 181 case, the volume of traffic and delay requirements make it 182 imperative to connect Node E to PS-2 a direct link or a LAN. (4) 183 "Smart" policy nodes: Nodes A and C include sophisticated LPMs, 184 in that these nodes can process some sub-policy elements, and have 185 the capacity to cache responses from PS-1. In this case, the 186 contact between the clients and server would be limited to 187 occasional updates, and PS-1 could be located somewhere in AD-1. 189 Consider the case where the receiver R1 sends a Resv message 190 upstream toward sender S1. Assuming that the reservation is 191 successful, the conceptual flow of policy objects is: 193 R1 -- E -- ELPM -- PS-2 -- ELPM -- E -- D -- DLPM -- D -- C -- CLPM 194 -- PS-1 -- CLPM -- C -- B -- A -- ALPM -- PS-1 -- ALPM -- A -- S1. 196 Of course, other OOPS messages may be exchanged between policy 197 servers and nodes before authorizing the reservation at individual 198 nodes. 200 The functioning of the policy module at a policy aware router is 201 presented through the following conceptual diagram. 203 +---------+ +----------+ 204 | RSVP | | Policy | 205 | Module | | Server | 206 +---------+ OOPS | | 207 | LPM |---------| | 208 +- - - - -+ +----------+ 209 |PSM| |PSM| |PSM| |PSM| 210 |___| |___| |___| |___| 212 Figure 2: Local Policy Modules and Policy Server communications 214 The policy server and the local policy module provide support for 215 a number of sub-policy elements, each embodied by a policy sub- 216 module (PSM). The policy object forwarded by RSVP may contain a 217 number of elements, each identified by a number, and hence 218 destined to the sub-module that enforces that sub-policy element's 219 number. For instance, some of these sub-objects may deal with 220 authentication, others with security, accounting and so on. The 221 LPM is aware of the sub-modules it is capable of processing 222 locally; After the handshake comes to know the set of sub-policies 223 that are supported by the server. Processing of policy sub-objects 224 can be split between the LPM and the policy server, and responses 225 may be merged back before returning a unified response to RSVP. 227 2. OOPS Protocol: Basic Features 229 OOPS is a transaction protocol, in which most communication is in the 230 form of queries from the client followed by responses from the 231 server. However, a small portion of the communication may also 232 consist of queries originating from the server, or of unidirectional 233 notifications from one entity to another. In this context, it is 234 important that messages be distinguished by a unique association, so 235 that responses may identify the query to which they correspond. 237 This section discusses four fundamental concepts of the OOPS 238 protocol: (a) query/response mechanism, (b) flexible division of 239 labor between client and server, and (c) consistent management of 240 client, server and RSVP state. 242 2.1 Query/Response mechanism 244 Each OOPS message is uniquely identified by a sequence number; 245 Both client and server begin communication with Mseq = 0 (the 246 handshake message), and number consecutive messages in increasing 247 order. These sequence numbers do not imply the order of execution; 248 while the server receives messages in-order, it is free to execute 249 them in any reasonable order. 251 These sequence numbers are mainly used by the Error-Notification 252 operation as a means to identify the message that is associated 253 with the reported error. [Note 2] 255 2.1.1 Associating Queries and Responses 257 Queries and responses carry a Q_ASSOC object which relates 258 newly received responses to their original query operations. 259 The contents of this object is client-specific and therefore 260 opaque to the server; it is set by the client for each query 261 and is echoed back as-is by the server. The client must store 262 enough information in the Q_ASSOC object to enable its own 263 unique identification of the original query. 265 2.2 Division of Labor between Client and Server 267 The OOPS protocol allows for a flexible division of 268 responsibilities between server and client. First, the client must 269 be able to decide how to distribute the processing and second, it 270 must be able to merge the distributed responses into one unified 271 result. 273 2.2.1 Distributed Processing 275 Processing of sub-policies (sub-policy elements within 276 POLICY_DESC objects) can be performed by the server, the 277 client, or by both. The decision on which sub-policies are to 278 be handled locally and which are to be sent to the server is 279 always made by the client based on information exchanged during 280 the connection establishment handshake (see Section 3.1). 282 The client may remove sub-policy elements which are not to be 283 processed by the server. In this case, the client is solely 284 responsible for checking the integrity of the incoming policy 285 object; [Note 3] 286 _________________________ 287 [Note 1] Execution order is implementation and policy specific; any 288 order that does not violate the policy specific requirements is assumed 289 to be reasonable. 291 [Note 2] Senders must be informed about the receiver's failure to 292 process their messages. This is especially critical given that OOPS 293 relies on TCP's reliability and lacks additional reliability mechanisms. 295 [Note 3] If any portion of the POLICY_DESC object is modified, the 296 digest integrity verification at the server is bound to fail. 298 the client must also set the OP-Code header flag to inform the 299 server to that fact. 301 During connection establishment, the server may request to have 302 oversight over the clients local decisions; in this case, the 303 client should forward incoming policy objects in their 304 entirety, and consult the server for all RSVP flows, regardless 305 of whether they include POLICY_DATA objects. This oversight is 306 transparent to the client and is therefore post factum. [Note 307 4] 309 OOPS does not impose limitations on the number of servers 310 connected to the client; when appropriate, the client could 311 divide the work along policy lines between several servers, and 312 be responsible for combining their results. In the rest of this 313 document we describe the protocol for a single server-client 314 pair. 316 2.2.2 Unification of Distributed Responses 318 Division of labor between client and server is only possible to 319 the extent that the client has the capability to unify or merge 320 results; the client must be able to merge the results of 321 queries arriving from servers with its own local results, to 322 produce a single unified response to the underlying protocol 323 (e.g., RSVP). 325 Results unification is straight-forward for outgoing 326 POLICY_DESC object; since sub-policy elements are independent, 327 their unification is performed by concatenating all local and 328 server elements and packing them in POLICY_DESC objects. [Note 329 5] 331 Unification is more complex for status queries, since the 332 various responses must truly be merged to produce a single 333 status result. OOPS defines one basic (default) status 334 response interface (object and unification rules). 335 _________________________ 336 [Note 4] The client should not wait for an oversight decision; if the 337 server overrides a local decision, it may notify the client sometime 338 later, even after the local client authorized the RSVP operation. 340 [Note 5] An oversight sub-policy element would override the locally 341 generated element, if the two are of the same type. 343 However, given that OOPS is an extensible framework, it allows 344 the the client and server to negotiate a more sophisticated 345 interface (see Section 3.1). Additional response interfaces 346 could be described in separate documents which should define 347 the response object format and unification rules. [Note 6] 349 2.2.3 Default Status Response 351 The default status response object is of the C-Type 1. C-Type 352 1 objects may contain two values: a policy admission decision 353 (PAD) and a preemption priority value (PP). It is reasonable 354 to assume that some clients would not be able to utilize the 355 flow preemption priority information; such clients are free to 356 ignore this value and assume that all flows are created equal. 357 (have priority 0). 359 PADs may have one of three values: ACCEPT, SNUB, and VETO. 360 ACCEPT authorizes the query, SNUB signifies neutrality (neither 361 accept nor reject). A VETO from the server or LPM has a 362 stronger semantics than a snub, since it has the power to 363 forcefully reject a flow regardless of any accept decisions 364 made by the other. 366 The rules for unification of PAD values A and B are straight- 367 forward: 369 +----------------------+---------------------+ 370 | A+B | IF... | 371 +----------------------+---------------------+ 372 | SNUB | A=SNUB and B=SNUB | 373 | VETO | A=VETO or B=VETO | 374 | ACCEPT (+PP value) | Otherwise | 375 +----------------------+---------------------+ 377 A unified result of ACCEPT provides approval for the status 378 query; both SNUB and VETO signal the rejection of the query. 380 Note that a client and/or server should complete their policy 381 processing even if a veto was cast by some policy. [Note 7] 382 _________________________ 383 [Note 6] A separate template document and a list of more sophisticated 384 responses should be prepared. 386 [Note 7] A wide range of sub-policies may not care about the final 387 status results and should be activated regardless. For instance: a 388 policy that logs all policy queries. 390 An ACCEPT response is accompanied by a PP value between 0..255. 391 Lower values describe higher priorities (priority 1 is the 392 highest). The value 0 is reserved for "N/A"; this value is 393 used when preemption priority is not applicable. 395 The unification of PP values A and B attempts to provide the 396 highest priority (lowest value) which is supported by an ACCEPT 397 decision. The value 0 has no effect on the unified priority: 399 +----------------------+---------------------+ 400 | A+B | IF... | 401 +----------------------+---------------------+ 402 | MIN(A,B) | A!=0 and B!=0 | 403 | A | B=0 | 404 | B | A=0 | 405 | 0 (n/a) | A=0 and B=0 | 406 +----------------------+---------------------+ 408 2.3 State Management 410 In order for policy objects contained in RSVP messages to be 411 processed quickly and correctly, it is often required that the 412 results of past policy decisions be cached and maintained at the 413 LPM or the policy server. During normal operations, the state 414 maintained in the client and in the server must remain consistent, 415 and must timeout at roughly the identical times in RSVP, the 416 client, and the server. 418 The most straightforward method for state maintenance is for the 419 LPM and the policy server to use the same soft-state mechanism as 420 the RSVP capable router. Unfortunately, this soft-state approach 421 has undesirable scaling properties since it requires the client to 422 contact the server on each refresh period (regardless of state 423 changes). 425 An alternative approach is to allow both client and server to use 426 hard-state mechanisms that could limit the client-server 427 communication to state updates only. To support the hard-state 428 mode, the client must be able to distinguish between repeats 429 (refreshes) and updates; it must also be able to translate the 430 soft-state that is provided by RSVP into the hard-state exchanged 431 with the server. 433 Thus, we envision one end of the spectrum where a "dumb" client 434 would use a soft-state approach and simply pass all policy objects 435 to the server relying on it for all policy processing. The rate 436 of queries and lack of caching at the client implies the need for 437 a dedicated, close-by server (PS-2, in our example). As we move 438 towards the other extreme, clients become smarter, split the work 439 between themselves and the server, utilize caching capabilities. 440 Such clients could take advantage of the benefits of hard-state 441 management, and initiate queries only on actual state updates. 443 OOPS supports soft and hard state mechanisms seamlessly, as 444 described in this section. The client determines its desired type 445 of state management, and communicates it on an object-by-object 446 basis. A single client can use soft-state for some information, 447 and hard state for others. Furthermore, the OOPS protocol allows 448 clients to modify their caching strategies on the fly (without 449 having to renegotiate with the server). While the protocol does 450 not impose strategy limitations, a client implementation could 451 restrict itself to a more modest and simple combination of soft 452 and hard state. 454 There are two types of state information that is stored at the 455 client: (a) client state information that was forwarded to the 456 server (e.g., policy objects in incoming Path/Resv messages). (b) 457 server state which is cached at the client (e.g., policy results 458 computed by the server). The OOPS protocol addresses each of these 459 types of states separately: 461 2.3.1 Client State Information Cached at the Server 463 The client indicates its choice of state management approach by 464 setting (or resetting) the OOPS_HardState flag in objects sent 465 to the server. When the client chooses soft-state management, 466 policy state for that specific object ages and expires at the 467 server according to the specified timeout (refresh-period * K). 468 Therefore, the state cached at the server is kept alive by 469 constant refreshing (the client must forward ALL incoming RSVP 470 messages, whether or not they represent refreshes or updates). 471 On the other hand, when indicating a choice of hard-state 472 management, the client assumes responsibility for reliably 473 informing the server on every policy update. In this case, the 474 state cached at the server would not expire unless explicitly 475 modified by the client, or when the communication channel to 476 the client breaks. [Note 8] 477 The client may refrain from forwarding to the server any 478 repeat policy objects (which represent no updated information). 480 The client may switch between hard and soft states on the fly 481 _________________________ 482 [Note 8] Clearly the channel breaks when either the client or server 483 become disfunctional or die. 485 by modifying the OOPS_HardState flag while forwarding input to 486 the server. 488 2.3.2 Server State Information Cached at the Client 490 The client indicate its state management capabilities by 491 setting (or resetting) the OOPS_HardState flag in queries sent 492 to the server. A choice of soft-state indicates that the client 493 is incapable of caching, and it purges the server responses 494 after usage (one-time, or disposable results). Clearly, without 495 caching, the client must issue a new query each time that 496 responses are needed. 498 When the server responds to a cached (hard-state) query, it 499 assumes responsibility to reliably inform the client about any 500 changes that may occur later with the original response to this 501 query. The client may rely on cached results as long as there 502 is no change in RSVP's state (which includes incoming policy 503 objects), [Note 9] 504 and the communication channel with the server is intact. 506 The client may switch between hard and soft states on the fly 507 by issuing a new query with a modified flag. 509 2.3.3 State Change Notification 511 State change notification is done by resending the same type as 512 the original message but with the modified state instead. 514 Client notification example (incoming POLICY_DESC objects for 515 Resv-X): 517 _________________________ 518 [Note 9] A configurable option may allow the client to use cached 519 results even when some RSVP state changes. There is a clear trade-off 520 here between fast and accurate policy processing, however, given that 521 the server is up, and that authorization was already granted previously 522 for that RSVP flow, some may find it a reasonable policy approach. 524 TYPE DATA 525 ---- ---- 526 CLIENT ==> SERVER: NOTIFY:INPUT RESV-X: PD-1 528 Time passes; the input POLICY_DESC object associated with 529 Resv-X changed to PD-2. 531 CLIENT ==> SERVER: NOTIFY:INPUT RESV-X: PD-2 533 Server notification example (status query for reservation 534 Resv-X): 536 TYPE DATA 537 ---- ---- 538 CLIENT ==> SERVER: QUERY:STATUS Q_ASSOC=ID1, RESV-X 539 SERVER ==> CLIENT: RESP :STATUS Q_ASSOC=ID1, ACCEPT 541 Time passes; the status of Resv-X changed to "reject". 543 SERVER ==> CLIENT: RESP :STATUS Q_ASSOC=ID1, REJECT 545 2.3.4 State Re-synchronization 547 Both client and server may re-synchronize their respective 548 states at any time during the connection. The reset initiator 549 sends a Bye-Notification with a RESET code, and the receiver 550 responds with a Bye-Notification with the same code. After 551 this exchange, all cached state becomes soft, and a new logical 552 connection is reestablished (beginning with Connection- 553 Initiation-Query,...). New/hard state gradually replaces 554 old/soft state as described in Section 2.3.4. 556 2.4 Error Handling 558 We distinguish between two types of possible errors; policy errors 559 and protocol errors. 561 2.4.1 Protocol Errors 563 Protocol errors (e.g., missing or bad parameters) do not reveal 564 either positive or negative policy decisions and are therefore 565 neutral (represented as SNUBs). [Note 10] 566 _________________________ 567 [Note 10] This neutrality allows, when appropriate, other valid sub- 568 policy elements to support an accept decision. 570 It is recommended (although not required) that all local status 571 processing at the client be completed before querying the 572 server. This allows the server to immediately commit the 573 transaction rather than having to wait until the client is 574 done. (See the Client-Status-Notification Op-Code.) 576 Some OOPS protocol errors may only affect the OOPS protocol 577 processing or simply be logged. Other errors may escalate to 578 become policy errors (e.g., a bad POLICY_DESC is reported as a 579 policy error). 581 2.4.2 Policy Errors 583 Policy errors are reported in a sub-policy element specific 584 format. These elements are encapsulated in POLICY_DESC objects 585 and are forwarded toward the originator (cause) of the error. 586 In most cases, a negative Status-Response initiates an 587 automatic error response (e.g., RSVP ResvErr or PathErr), 588 however, OOPS allows reporting of other error situations by 589 scheduling an explicit error message (using the Protocol- 590 Message-Notification op-code). (See [Ext] for more about the 591 rules governing error reporting). 593 Consider a scenario where two receivers R1 and R2 listen to a 594 multicast transmission from S1. A reservation sent by R1 is 595 propagated upstream until it reaches node A, where it 596 encounters a policy rejection. 598 R1------------+ 599 B--------------A----------- S1 600 / \ | 601 R2------------+ \ | 602 \ | 603 PS1 PS2 605 Figure 3: An Error Reporting Scenario 607 The following table describes a subset of the relevant 608 signaling which begins with reservation initiation by R1 and R2 609 and ends by R1 receiving the appropriate error response. 611 From/To Message Comments 612 ________________________________________________________________________________ 613 R1->B Resv [PD1] 614 R2->B Resv [PD2] 615 B->PS1 OOPS-Incoming-Policy-Query[PD1,PD2] ;B queries PS1 616 OOPS-Status-Query? 617 OOPS-Outgoing-Policy-Query? [Resv] 618 PS1->B OOPS-Status-Response: ACCEPT 619 OOPS-Outgoing-Policy-Response[PD3] 620 B->A Resv [PD3] ;B forwards the Resv to A 621 A->PS2 OOPS-Incoming-Policy-Query[PD3] ;A queries PS2 622 OOPS-Status-Query? 623 PS2->A OOPS-Status-Response: SNUB (reject) ;PS2 reject the reservation 624 A->PS2 OOPS-Outgoing-Policy-Query? [ResvErr] ;PS2 provides error PD 625 PS2->A OOPS-Outgoing-Policy-Response [PD1-E] 626 A->B ResvErr [PD1-E] ;A sends back ResvErr to B 627 B->PS1 OOPS-Incoming-Policy-Query[PD1-E] 628 OOPS-Outgoing-Policy-Query? [ResvErr] ;PS1 builds error PD 629 PS1->B OOPS-Outgoing-Policy-Response[PD1-E'],R1 ; (directed to R1 only) 630 B->R1 ResvErr [PD1-E'] ;B sends back ResvErr to R1 631 ________________________________________________________________________________ 633 Figure 4: Error Reporting Signaling 635 All error information is carried in POLICY_DESC objects (as 636 sub-policy elements). OOPS server may read and modify this 637 information along the ResvErr path; it may also direct the 638 error responses only to the relevant branches of the reserved 639 tree (in this scenario, the error is associated with R1 but not 640 with R2). 642 3. Client-Server Connection 644 The following section describes the fundamentals of client-server 645 connection: establishment, channel, and termination. 647 3.1 Connection Establishment 649 OOPS uses a well known port number (OOPS = 3288) for incoming 650 connection requests. Usually, the client would attempt to 651 establish a TCP connection to its preferred policy server, 652 however, both client and server listen to the OOPS port. [Note 11] 654 _________________________ 655 [Note 11] New (or recovering) policy servers are allowed to notify 656 clients on their existence by issuing a TCP connection request to the 657 client's OOPS port number. 659 Regardless of who initiated the TCP connection, once the 660 connection is in place, the OOPS logical connection establishment 661 is always initiated by the client and is performed through a two 662 way handshake. 664 o Communication Initiation by the Client 666 The client sends a Connection-Initiation-Query to the server. 667 This message identifies the client to the server and provides 668 the basic characteristics of the client as well as a list of 669 policy responses that are acceptable to the client. This list 670 is in decreasing order of acceptability, and terminates with 671 the default element. 673 o Response by the Server 675 The server responds with a Connection-Accept-Response to 676 connect to the client. It may also respond with a 677 Connection-Reject-Response to refuse and disconnect from the 678 client. 680 After connection establishment both the client and server 681 know the set of sub-policies that the client can send to the 682 server, which one of them should handle default 683 (unrecognized) sub-policies, as well as the format of status 684 responses from server to client. They also establish the 685 Channel-Hold period which is determined as the minimum 686 between the two values declared in the handshake messages, 687 but must be at least 3 seconds. 689 3.1.1 Reliable Communication 691 We expect TCP to provide us with reliable, in-order delivery of 692 packets. Given that TCP is responsible for all the time 693 critical network operations, reliability errors are assumed to 694 be virtually nonexistent. 696 3.1.2 Secure Communications 698 OOPS relies on standard protocols for security of client-server 699 communications. An emerging standard protocol IPSEC [IPSEC] is 700 the mechanism of choice for ensuring either integrity or 701 secrecy. The use of IPSEC and/or other security protocols is 702 transparent to OOPS. 704 3.2 Connection Termination 706 This section describes the handling of communication breakdown. 708 3.2.1 Implicit Termination 710 The communication channel may be unexpectedly disconnected 711 because of a misbehaving client or server, network split, or 712 for other reasons. Both client and server must be able to 713 detect such channel failures and act accordingly. Consider the 714 case where OOPS is used for quota enforcement. The server may 715 approve a reservation while debiting X/min from a local 716 account. If the OOPS communication channel breaks, it is 717 critical for the server to detect the break and stop debiting 718 this account. 720 The OOPS protocol relies on Keep-Alive messages to provide 721 application-level communication-channel verification. [Note 12] 723 Implicitly, the communications channel is assumed to be 724 disconnected after it has been idle (no message was received on 725 it) for more than a Channel-Hold period (see Section 3.1). 726 Keep-Alive messages are sent by both client and server as 727 needed [Note 13] 728 to ensure the liveness of the connection (to prevent a 729 Channel-Hold timeout). Keep-Alive messages are not 730 acknowledged. 732 3.2.2 Explicit Termination 734 The client (or server) may terminate the connection by sending 735 a Bye-Notification, and wait until either it receives an echoed 736 Bye-Notification or the Channel-Hold period had passed. In 737 between, it should ignore incoming messages (and not reset the 738 Channel-Hold timer). 740 At the opposite side, when a client (or server) receive a Bye- 741 Notification message, it should echo it, and close the 742 connection. 744 _________________________ 745 [Note 12] OOPS implementations may utilize system dependent mechanisms 746 for detecting broken TCP connections, but does not rely on them. This is 747 especially important since a server may be in a dysfunctional state 748 while its TCP connection is still open and viable. 750 [Note 13] When the intermediate period in between two OOPS messages 751 approaches the Channel-Hold time. 753 3.2.3 Post Termination 755 Soft-state has an inherent cleanup mechanism; when the channel 756 disconnects, the soft-state begins to age until it eventually 757 expires (using the same mechanism and refresh-period * K used 758 by RSVP). 760 In contrast, hard-state is assumed to be valid unless 761 explicitly modified. However, when the channel disconnects such 762 an explicit notification is not possible. Clearly, purging all 763 state immediately upon disconnection is not an acceptable 764 approach since should cause disruption of service and would not 765 allow enough time to contact an alternate server. OOPS uses 766 the following simple rule: 768 When the communication channel disconnects, all hard state 769 associated with it is assumed to be soft-state that had been 770 refreshed recently. 772 3.2.4 Switching to An Alternative Server 774 We assume that as part of their local configuration, clients 775 obtain a list of policy servers and site specific selection 776 criteria. This list can be the basis for server switching 777 decisions. 779 A switch to an alternate server may be triggered by a voluntary 780 disconnection (i.e., Bye-Notification) or an unexpected break 781 in the communication channel. During normal operations, the 782 client may wish to switch to an alternate server (for any 783 reason). The client is advised to first connect to the new 784 server before sending a Bye-Notification to the original one. 785 If the communication channel unexpectedly disconnects, the 786 client should quickly attempt to connect to an alternate 787 server. 789 In both cases, after the connection to a new server [Note 14] 790 is established, the aging cached state from the old server 791 would be gradually replaced by responses from the new server. 792 [Note 15] 793 _________________________ 794 [Note 14] The term "new server" may be the same as the "previous 795 server"; it may happen that the connection encounters a problem and the 796 client chooses to disconnected and re-established the connection. 798 [Note 15] The client could speed-up replacement of cached state by 799 sending copies of cached input to the server and issuing repeated 800 queries, on connection establishment (instead of waiting until objects 801 As general guidelines, state replacement from a new server 802 should not cause a disruption of service that would not 803 otherwise occur (if a new server was not found). [Note 16] 805 After switching to an alternate server, the client may 806 periodically poll its old (preferred) server by attempting a 807 TCP connection to its OOPS port. Similarly, a new (or recovered 808 server) may notify clients about its liveness by attempting to 809 connect to their OOPS port. In the latter case, clients may 810 disconnect the TCP connection or respond with a Connection- 811 Initiation-Query as if the client initiated the connection in 812 the first place. [Note 17] 814 %% TOO EARLY: WE SHOULD PUT IT IN THE NEXT VERSION (02) 815 %% ---------------------------------------------------- 816 %%The client may choose to use both the main and the alternate 817 servers 818 %%in tandem. In this case, the client would send inputs and 819 updates to 820 %%both servers, but will make status and outgoing-policy 821 queries only 822 %%to the main server. Given that both servers have the same 823 state image, 824 %%a switch between them could be fast without causing 825 disruption of 826 %%service. 828 4. OOPS Message Format 830 OOPS messages serve as a wrapper that may include one or more Op- 831 Codes; the message wrapper allows common operation (e.g., MD5 832 integrity, HOP_DESCs, protocol version, etc.) to be performed and 833 verified in one-shot. All OOPS messages are composed of the following 834 fields: 836 _________________________ 837 arrive from RSVP). 839 [Note 16] Practically, this means that as long as there is no change in 840 RSVP messages, the client is advised to choose between cached and new 841 results in favor of authorizing the request. 843 [Note 17] Future version of this document may include the use of 844 multicast to advertise the liveness of servers. 846 +---------------+---------------+---------------+---------------+ 847 | Ver | #Op-Codes | Flags | ////// | 848 +---------------+---------------+---------------+---------------+ 849 | Message Length | 850 +---------------+---------------+---------------+---------------+ 851 | Message Sequence Number | 852 +---------------+---------------+---------------+---------------+ 853 | OOPS_MSG_AUTH (Optional) | 854 +---------------+---------------+---------------+---------------+ 855 | List of Op-Codes... | 856 +---------------+---------------+---------------+---------------+ 858 Version: 8 bits 860 Protocol version number. The current version is 1. 862 Flags: 8 bits 864 0x01 H_Integrity_Checked POLICY_DESC Integrity already checked by client 865 0x02 H_Hops_Checked Prev/Next HOPs already checked by client 867 #Op-Codes: 8 bits 869 Number of Op-Codes included in this message. 871 Message Length: 32 bits 873 The total length of this OOPS message in bytes. 875 Message Sequence Number: 32 bits 877 The sequence number of the message being sent. 879 OOPS_MSG_AUTH (optional): variable length 881 This Message Authenticator provides integrity verification based 882 on a shared-keyed message digest. The message digest is 883 calculated over the entire OOPS message. 885 There is only one object format currently defined is identical 886 to the RSVP INTEGRITY object (defined in [Bak96]). 888 List of OOPS operation codes (Op-Codes): variable length 890 Described in the following section. 892 4.1 OOPS Operation Codes (Op-Codes) 894 Each OOPS message may contain multiple OOPS operations each 895 encapsulating a different query, response or notification. For 896 example, multiple Incoming-Policy-Queries might be followed by a 897 Status-Query operation in the same message. 899 Individual OOPS Op-Codes have the following header: 901 +---------------+---------------+---------------+---------------+ 902 | Operation Code| Op. Subtype | Flags | ////// | 903 +---------------+---------------+---------------+---------------+ 904 | Length (bytes) | 905 +---------------+---------------+---------------+---------------+ 906 | Refresh Period | 907 +---------------+---------------+---------------+---------------+ 909 The operation header has the following fields: 911 operation Code: 8 bits 913 The type of OOPS operation. 915 Operation Subtype: 8 bits 917 This field can be used to indicate an attribute of the Op- 918 Code, such as its version; currently it is always set to 1. 920 Flags: 8 bits 922 0x01 OOPS_HardState: Hard State (soft-state if not set (0) ) 923 0x02 OOPS_Shared : Resv shared among sources as filter specs 924 0x02 OOPS_FullList : Last in the set of status queries. 926 Length: 32 bits 928 Contains the total operation length in bytes (including 929 header). 931 Refresh Period 933 The refresh-period associates with this object (e.g., RSVP's 934 refresh period). 936 The remainder of this section describes the set of operations that 937 may appear in OOPS messages and their object format. OOPS does 938 not bind itself to a particular protocol (i.e., RSVP) and is built 939 around objects that may belong to different (other) protocols. The 940 current draft is based on the assumption that RSVP would be one 941 (the first) of these protocols and thus, the draft provides the 942 appropriate RSVP objects format. 944 4.1.1 Null-Notification (a.k.a Keep-Alive) 946 Operation Type = 0, sub-type = 1 948 ::= 950 This empty or null notification triggers no operation; thus, 951 can be used as as Keep-Alive signal to test the viability of 952 the communication channel between client and server (see 953 Section 3.2.1). 955 4.1.2 Connection-Initiation-Query 957 Operation Type = 1, sub-type = 1 959 ::= 960 961 962 963 964 966 The client sends this query to establish a connection with a 967 server. This message is sent following the establishment of a 968 transport connection (TCP). 970 o CONNECT_DESC 972 Description of connection parameters. 974 o CLASS_ID 976 The client's class provides an implicit description of the 977 client's capabilities and requirements; the CLASS_ID is an 978 index into the class list maintained by the server; it is 979 used in conjunction with the CLIENT_ID.) 981 o CLIENT_ID 983 The network address of the client. From the combination 984 of CLIENT_ID and CLASS_ID the server can learn about the 985 set of sub-policies it is required to support for this 986 particular client; it can also learn which of these sub- 987 policies are optional and which are mandatory. 989 o RESP_INT 991 A list of possible response interfaces. 993 o COOKIE 995 4.1.3 Connection-Accept-Response 997 Operation Type = 2, sub-type = 1 999 ::= 1000 1001 1002 1003 1005 The server sends this response to accept a client's connection 1006 connection request. 1008 o CONNECT_DESC 1010 o PLIST 1012 Each "From Policy m" and "To Policy m" pair represent a 1013 range of sub-policies that the server is willing to 1014 support. 1016 o RESP_INT 1018 The chosen (agreed upon) status response interface. 1020 o COOKIE 1022 4.1.4 Connection-Reject-Response 1024 Operation Type = 3, sub-type = 1 1026 ::= 1027 1029 The server sends this response to reject a client's connection 1030 initiation. It specifies both reason code and text. 1032 4.1.5 Bye-Notification 1034 Operation Type = 4, sub-type = 1 1036 ::= 1037 1038 [] 1040 This message is used by either client or server to terminate 1041 the OOPS connection. 1043 o BYE_DESC 1045 (Section 3.2.2 includes a description of explicit termination 1046 using Bye-Notification) 1048 4.1.6 Incoming-Policy-Query 1050 Operation Type = 5, sub-type = 1 1052 ::= 1053 1054 1055 1056 1057 1058 [] 1059 1061 This operation is used to forward POLICY_DESC objects from the 1062 client to the server. Selection between hard and soft state 1063 management is reflected in the OOPS_HardState flag. The other 1064 fields are copied from the PC_InPolicy() function called by 1065 RSVP. (See [Ext]). 1067 4.1.7 Incoming-Policy-Response 1069 Operation Type = 6, sub-type = 1 1071 ::= 1072 1073 1075 Incoming-Policy-Response is used ONLY to report protocol errors 1076 (e.g., syntax) found with incoming policy objects. (it is not 1077 used in the normal operation of the protocol). 1079 4.1.8 Outgoing-Policy-Query 1081 Operation Type = 7, sub-type = 1 1083 ::= 1084 1085 1086 1087 1088 1090 This operation queries the server for a set of outgoing policy 1091 objects for a set of HOP_DESCs. The client can choose between 1092 hard and soft state management through the OOPS_HardState flag. 1093 When hard state is selected, the client caches copies of the 1094 outgoing objects and assumes they remain valid unless 1095 explicitly modified by the server. 1097 4.1.9 Outgoing-Policy-Response 1099 Operation Type = 8, sub-type = 1 1100 ::= 1101 1102 { 1103 or 1104 } pairs list 1106 The links the response to the original query. 1108 In the response, the server provides a list of triplets, one 1109 for each outgoing HOP_DESC (For Path messages, only the LIH 1110 part is significant). Each triplet contains a list of policy 1111 objects for that hop and an error description. 1113 The OOPS server can block an outgoing RSVP message by replacing 1114 the outgoing POLICY_DESC list for a particular HOP_DESC with an 1115 with an appropriate value. 1117 The ability to block outgoing RSVP control messages is 1118 especially useful when policy is enforcement is performed at 1119 border nodes of a network; RSVP control messages that are 1120 allowed through are capable of installing state at internal 1121 nodes without being subject to further policy control. 1123 4.1.10 Status-Query 1125 Operation Type = 9, sub-type = 1 1127 ::= 1128 1129 1130 1131 1132 { 1133 1134 } triplets list 1136 This operation queries the server for status results of a list 1137 of LIHs. The client can choose between hard and soft state 1138 management through the OOPS_HardState flag. When hard state is 1139 selected, the client caches the status results and assumes they 1140 remain valid unless explicitly modified by the server. 1142 In the upstream direction (e.g., Resv) status may need to be 1143 checked on multiple LIHs (all reservations for a flow). In such 1144 cases, status queries can be perform separately for each LIH, 1145 once for all LIHs, or anything in between. Flag OOPS_FullList 1146 must be set at the last of status query of the series. [Note 18] 1147 _________________________ 1148 [Note 18] When sub-policies are interdependent across LIHs (as when the 1149 cost is shared among downstream receivers), flag OOPS_FullList notifies 1150 the server that the list of reserved LIH is complete and that it can 1151 safely compute the status of these reservations. 1153 4.1.11 Status-Response 1155 Operation Type = 10, sub-type = 1 1157 ::= 1158 1159 { 1160 1161 [] 1162 } triplet list 1164 The links the response to the original query. 1166 In the response, the server provides a list of triplets, each 1167 of which contains an LIH, status, and any applicable error 1168 results. The set of LIHs is an attribute of the results and 1169 not of the query; the server is allowed to respond with a 1170 superset of LIHs specified in the original query, as in the 1171 following example: 1173 SEQ# TYPE DATA 1174 --- ---- ---- 1175 Client ==> Server: 150 Query:status Q_ASSOC=ID2, Resv-X, LIH={2} 1176 Server ==> Client: 153 Resp :status Q_ASSOC=ID2, {2,rej} 1178 Two new reservations arrive, carrying new policy data objects: 1180 Client ==> Server: 160 Query:status Q_ASSOC=ID3, Resv-X, LIH={4,7} 1181 Server ==> Client: 169 Resp :status Q_ASSOC=ID3, {2,acc;4,acc;7,rej} 1183 4.1.12 Delete-State-Notification 1185 Operation Type = 11, sub-type = 1 1187 ::= 1188 1189 1190 [] 1191 [] 1192 [] 1193 [] 1195 o STATE_OP_DESC 1197 This object describes the type of requested operation (see 1198 Appendix A). 1200 This operation informs the sender about an immediate RSVP 1201 teardown of state caused by PATH_TEAR, RESV_TEAR, routes 1202 change, etc. As a result, the server should ignore the 1203 described state as if it was never received from the client. 1205 Despite its name, this operation can be used to switch between 1206 blockaded and non-blockaded state. 1208 The semantics of this operation is described for PC_DelState() 1209 in [Ext]. 1211 Error description is used to provide the server with a reason 1212 for the delete (for logging purposes). 1214 4.1.13 Protocol-Message-Notification 1216 Operation Type = 12, sub-type = 1 1218 ::= 1219 1220 1221 1222 1224 The operation results in the generation of an outgoing protocol 1225 message (e.g., RSVP's Path, Resv). The client should schedule 1226 the requested message to the specified HOP_DESC. 1228 4.1.14 Client-Status-Notification 1230 Operation Type = 13, sub-type = 1 1232 ::= 1233 1234 1236 The Client notifies the server about the status results 1237 computed at the client (that may also include results from 1238 other servers, if policy computation is spread among several 1239 servers). 1241 The overall status of an RSVP flow is computed by merging the 1242 client's status report with the server's. The server should not 1243 commit a transaction (e.g., charge an account) before knowing 1244 its final status. The Client-Status-Results operation can be 1245 sent with the query, if the client computed its status prior to 1246 making the query. It can also be sent later, after the server 1247 sent its response to the status query. 1249 4.1.15 Error-Notification 1251 Operation Type = 14, sub-type = 1 1253 ::= 1254 1255 1257 Message-Error-Notification can be used by either client or 1258 server to report errors associated with an entire message (as 1259 opposed to a specific operation). Error-Notification may be 1260 triggered by both syntax or substantive errors (e.g., failure 1261 to verify the integrity of the message). 1263 identified the message that triggered 1264 the error. It uses identical format to the one used by the OOPS 1265 message header. 1267 Message-Error-Notification is not acked. 1269 5. Acknowledgment 1271 This document reflects feedback from Paul Amsden, Fred Baker, Lou 1272 Berger, Bob Braden, Ron Cohen, Deborah Estrin, Steve Jackowski, Tim 1273 O'Malley, Claudio Topolcic, Raj Yavatkar, and many other IPC and RSVP 1274 collaborators, 1276 6. Authors' Address 1278 Shai Herzog Phone: (917) 318-7938 1279 IP"Highway" Email: herzog@iphighway.com 1281 Dimitrios Pendarakis Phone: (914) 784-7536 1282 Email: dimitris@watson.ibm.com 1283 Raju Rajan Phone: (914) 784-7260 1284 Email: raju@watson.ibm.com 1285 Roch Guerin Phone: (914) 784-7038 1286 Email: guerin@watson.ibm.com 1288 IBM T. J. Watson Research Center 1289 P.O. Box 704 1290 Yorktown Heights, NY 10598 1292 7. References 1294 References 1296 [IPSEC] R. Atkinson, Security Architecture for the Internet Protocol, 1297 "RFC1825", Aug. 1997. 1299 [Bak96] F. Baker. RSVP Cryptographic Authentication "Internet-Draft", 1300 draft-ietf-rsvp-md5-02.txt, 1996. 1302 [RSVPSP] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 1303 Resource ReSerVation Protocol (RSVP) Version 1 Functional 1304 Specification. "Internet-Draft", draft-ietf-RSVPSP-14.[ps,txt], 1305 Nov. 1996. 1307 [Arch] S. Herzog Accounting and Access Control Policies for Resource 1308 Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy- 1309 arch-01.[ps,txt], Nov. 1996. 1311 [LPM] S. Herzog Local Policy Modules (LPM): Policy Enforcement for 1312 Resource Reservation Protocols. "Internet-Draft", draft-ietf-rsvp- 1313 policy-lpm-01.[ps,txt], Nov. 1996. 1315 [Ext] S. Herzog RSVP Extensions for Policy Control. "Internet-Draft", 1316 draft-ietf-rsvp-policy-ext-02.[ps,txt], Apr. 1997. 1318 A Appendix: OOPS Objects 1320 This section describes objects that are used within OOPS OP-Codes. All 1321 objects have a common header: 1323 +---------------+---------------+---------------+---------------+ 1324 | Length | Class | C-Type | 1325 +---------------+---------------+---------------+---------------+ 1327 Length describes the length of the entire object, in bytes. Class 1328 describes the type of object and C-Type describes the a class sub-type. 1330 o CLASS_ID class 1332 - Class = 1, C-Type = 1 1334 +---------------+---------------+---------------+---------------+ 1335 | ASCII String ........ 0 Padded to multiples of 32 bits | 1336 +---------------+---------------+---------------+---------------+ 1338 o CLIENT_ID class 1340 - Class = 2, C-Type = 1 1342 A Network Address. 1344 +---------------+---------------+---------------+---------------+ 1345 | IPv4 Address | 1346 +---------------+---------------+---------------+---------------+ 1348 - Class = 2, C-Type = 2 1350 +---------------+---------------+---------------+---------------+ 1351 | IPv6 Address | 1352 | | 1353 | | 1354 | | 1355 +---------------+---------------+---------------+---------------+ 1357 From the combination of Client-ID and Class-Indicator the server 1358 can learn about the set of sub-policies it is required to support 1359 for this particular client; it can also learn which of these sub- 1360 policies are optional and which are mandatory. 1362 o RESP_INT class 1364 - Class = 3, C-Type = 1 1366 +---------------+---------------+---------------+---------------+ 1367 | Most-Prefered |..... | | | 1368 +---------------+---------------+---------------+---------------+ 1369 | | Least-Pref. |...0 Padded to 32 bit multiples| 1370 +---------------+---------------+---------------+---------------+ 1372 o COOKIE class 1374 - Class = 4, C-Type = 1 1376 Currently, no values are defined. 1378 o PLIST class 1380 - Class = 5, C-Type = 1 1382 +---------------+---------------+---------------+---------------+ 1383 | Number (or pairs) | ////// | 1384 +---------------+---------------+---------------+---------------+ 1385 | From Policy 1 | To Policy 1 | 1386 +---------------+---------------+---------------+---------------+ 1387 +---------------+---------------+---------------+---------------+ 1388 | From Policy n | To Policy n | 1389 +---------------+---------------+---------------+---------------+ 1391 Each "From Policy m" and "To Policy m" pair represent a range of 1392 sub-policies that the server is willing to support. 1394 o ERR_DESC class 1396 - Class = 6, C-Type = 1 1398 +---------------+---------------+---------------+---------------+ 1399 | Error-Code | ////// | Reason Code | 1400 +---------------+---------------+---------------+---------------+ 1401 | Error ASCII String .... 0 Padded to multiples of 32 bits | 1402 +---------------+---------------+---------------+---------------+ 1404 Detailed Error-Code and Reason-Codes would be defined in future 1405 versions of this document. 1407 o Q_ASSOC class 1409 - Class = 7, C-Type = 1 1411 +---------------+---------------+---------------+---------------+ 1412 | Client-Specific Semantics | 1413 // (Variable Length) // 1414 | | 1415 +---------------+---------------+---------------+---------------+ 1417 The client-specific contents of this object is opaque to the 1418 server; it is set by the client for a query and is echoed by 1419 the server as-is. The client must store enough information 1420 there that will enable it to uniquely identify the original 1421 query when the response arrive. This must at least include a 1422 counter to identify the version of the latest query. [Note 19] 1424 _________________________ 1425 [Note 19] A simple association could be the combination of a pointer to 1426 an internal client (router) control-block that describes the query, and 1427 a query version counter. 1429 o PROT_MSG_TYPE class 1431 - Class = 8, C-Type = 1 1433 +---------------+---------------+---------------+---------------+ 1434 | RSVP MSG TYPE | 1435 +---------------+---------------+---------------+---------------+ 1437 Values specified in [RSVPSP]. 1439 o DST_DESC class 1441 - Class = 9, C-Type = 1 1443 The RSVP SESSION object as defined in [RSVPSP]. 1445 o SRC_DESC class 1447 - Class = 10, C-Type = 1 1449 The RSVP FILTER_SPEC object as defined in [RSVPSP]. 1451 o HOP_DESC class 1453 - Class = 11, C-Type = 1 1455 The RSVP_HOP object as defined in [RSVPSP]. 1457 o ADV_DESC class 1459 - Class = 12, C-Type = 1 1461 The RSVP ADSPEC object as defined in [RSVPSP]. 1463 o QOS_DESC class 1465 - Class = 13, C-Type = 1 1467 The RSVP FLOWDESC object as defined in [RSVPSP]. 1469 o POLICY_DESC class 1471 - Class = 14, C-Type = 1 1473 The RSVP POLICY_DATA object as defined in [Ext] and [RSVPSP]. 1475 o OOPS_MSG_AUTH class 1477 - Class = 15, C-Type = 1 1479 The RSVP INTEGRITY object as defined in [RSVPSP] and [Bak96]. 1481 o STATUS_DESC class 1482 - Class = 16, C-Type = 1 1484 +---------------+---------------+---------------+---------------+ 1485 | Results | Priority | ////// | 1486 +---------------+---------------+---------------+---------------+ 1488 Results may have one of the following values: 1490 1 : Accept 1491 2 : Snub 1492 3 : Veto 1494 Priority ranges between 1..255 (see 2.2.3). 1496 o CONNECT_DESC class 1498 - Class = 17, C-Type = 1 1500 This object describes the OOPS connection parameters; in the 1501 Connection-Accept-Response, the refresh-multiplier is an echo 1502 of the value received with the Connection-Initiation-Query. 1504 +---------------+---------------+---------------+---------------+ 1505 | Version | Flags | Refresh-Mult. | ////// | 1506 +---------------+---------------+---------------+---------------+ 1507 | Max-Msg-Size (in KBytes) | Channel-Hold period (in sec.) | 1508 +---------------+---------------+---------------+---------------+ 1510 Ver: 8 bits 1512 Currently, version 1. 1514 Flags: 1516 0x01 OOPS_CONNECT_DefaultC Client handles default sub-policies. 1518 Refresh-Mult.: 1520 The refresh-period multiplier (e.g., RSVP's K value). 1522 Max-Msg-Size: Upper limit on the length of an OOPS message 1524 Channel-Hold period: Implicit disconnection timeout 1526 o BYE_DESC class 1528 - Class = 18, C-Type = 1 1530 BYE_DESC provides details about the Bye-Notification request. 1532 +---------------+---------------+---------------+---------------+ 1533 | Bye-Flags | ////// | BYE_DELAY (seconds) | 1534 +---------------+---------------+---------------+---------------+ 1536 Bye-Flags: 1537 0x01 An echo (response) to a received Bye-Notification 1539 The BYE_DELAY could provide both sides with some time delay to 1540 be better prepared to a pending bye. [Note 20] 1541 The delay value is determined by the originator of the bye- 1542 notification, and is echoed in the bye response. The delay 1543 effect should be as if the Bye-Notification was sent BYE_DELAY 1544 seconds later with a delay timer value of 0. 1546 o STATE_OP_DESC class 1548 - Class = 19, C-Type = 1 1550 _________________________ 1551 [Note 20] Similar to the delayed shutdown command known in Unix. 1553 +---------------+---------------+---------------+---------------+ 1554 | Op-Type | ////// | 1555 +---------------+---------------+---------------+---------------+ 1557 Op-Type values: 1559 1 : Delete State 1560 2 : Block State 1561 3 : Unblock State 1563 B Appendix: Error Codes 1565 This appendix describes an initial list of error codes available in 1566 OOPS, as well as the set of Reason Codes for each error code. (Reason 1567 Code of 0 must be used when Reason Codes are not applicable). This list 1568 should evolve and not be considered conclusive. [Note 21] 1570 o Code = 1, Connection Management 1572 1: Connection Reject: Server does not support client version. 1573 2: Bye: Reset due to routine state re-synchronization 1574 3: Bye: Reset due to connection problems (Bad message formats) 1576 o Code = 2, Protocol problems 1578 1: Syntax: Bad OOPS message 1579 2: Syntax: Bad OOPS Op-Code 1580 3: Syntax: Bad POLICY_DESC format 1582 o Code = 3, Policy Decisions 1584 1: Don't forward: refrain from forwarding an outgoing message. 1585 2: Policy Reject: cancel protocol operation (Reservation, path, etc.) 1587 o Code = 4, State Management 1589 1: Delete State: Reservation Canceled 1590 2: Delete State: route change 1591 3: Delete State: State Timeout 1592 4: Blockade State 1593 5: Unblock State