idnits 2.17.1 draft-durham-pe-rstatus-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. 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.) -- The document date (June 25, 1999) is 9072 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RSVP' is mentioned on line 409, but not defined == Unused Reference: 'RAP' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'COPS' is defined on line 425, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP-EXT' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft David Durham 2 Expiration: December 1999 Intel 3 File: draft-durham-pe-rstatus-00.txt Shai Herzog 4 IPHighway 6 RSVP Reservation Status Policy Element for End-to-End Accounting 8 June 25, 1999 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document details an RSVP Policy Element that provides a 34 mechanism by which RSVP reservation establishment can be reliably 35 confirmed, end-to-end. This Policy Element provides a status update 36 with each PATH message refresh, useful for determining the lifetime 37 of a reservation end-to-end. Such a policy element will be useful 38 for accounting and billing applications that are interested in 39 reliably knowing when a reservation has been successfully 40 established end-to-end and when a reservation is finally removed. 42 Internet Draft Reservation Status Policy Element 25-Jun-99 44 Table of Contents 46 Abstract..............................................................1 47 Table of Contents.....................................................2 48 1 Introduction.......................................................3 49 2 Format of the Reservation Status Policy Element (RSPE).............4 50 2.1 Format of the RESV message's Request RSPE........................4 51 2.2 Format of the PATH message's RSPE................................4 52 3 A Simple Scenario..................................................7 53 4 PDP Usage Model....................................................8 54 5 Authoritative CPs..................................................9 55 6 Security Considerations............................................9 56 7 References........................................................10 57 8 Author Information................................................10 58 Internet Draft Reservation Status Policy Element 25-Jun-99 60 1 Introduction 62 In RSVP, the Reservation Confirmation (RESV Confirm) message is used 63 to provide a one-time indication that a reservation has been 64 successfully established between a destination and the source or 65 merge point. The problem with the RESV Confirm is that this message 66 is not reliable. It is sent once in reply to the original 67 Reservation (RESV) message sent by the destination. The network may 68 loose the RESV Confirm, and due to the fact it is not sent with 69 every refresh, the destination may never receive the indication. 70 Furthermore, the RESV Confirm only provides an indication that a 71 reservation was successfully received by the source or first merge 72 point. It does not provide an indication of reservation state 73 timeout or state preemption along the end-to-end reserved data path 74 (the equivalent of a Unconfirm Message). Finally, the RESV Confirm 75 message is sent by unicast directly from the source or merge point 76 to the destination that issued the CONF message. Thus, intermediate 77 hops, including their Policy Decision Points (PDP) or Bandwidth 78 Brokers (BB), will never receive the RESV Confirm indication. 80 For purposes of accounting and billing for end-to-end reservation 81 establishment, there needs to be a reliable mechanism to determine 82 when a reservation has been successfully installed along the data 83 path, and when such a reservation is lost to determine its duration. 84 To facilitate such a capability, this specification introduces new 85 Policy Data Element carried by PATH and RESV messages that can 86 provide end-to-end status information on the state of upstream 87 reservations. This policy element is the Reservation Status Policy 88 Element (RSPE). For better scalability, the RSPE exchange is 89 triggered on-demand by downstream entities, by placing an RSPE in 90 RESV messages. The reservation status is sent back with PATH 91 messages. 93 The RSPE assumes a network infrastructure whereby neighboring hops 94 or bordering networks have bilateral relationships (and can 95 authenticate each other). This creates a hop-by-hop or network-by- 96 network chain of security whereby a bordering network can present 97 its status information as well as the culmination of all status 98 information from all upstream networks along the data path. 100 The RSPE is generated by Confirmation Points (CP) for a network 101 along the data path. Every hop along the data path can be a CP, but 102 a CP will typically be a PDP that knows the status of its network as 103 well as any relevant upstream networks with which it has a bilateral 104 relationship. An authoritative CP sends the first PATH with RSPE in 105 it. This status is then passed onto downstream networks for which 106 the CP also has a bilateral relationship. Each CP updates the RSPE 107 according to its own status, and eventually the status of a 108 reservation end-to-end may be ascertained by the receiver of the 109 RSPE. 111 Internet Draft Reservation Status Policy Element 25-Jun-99 113 2 Format of the Reservation Status Policy Element (RSPE) 115 The Reservation Status Policy Element is carried in either PATH or 116 RESV messages depending on its subtype. It is used in RESV messages 117 to request reservation status information from upstream hops. It is 118 then used in PATH messages to provide the upstream status 119 information back to the downstream hops. 121 Policy Element Type Number = 10 123 2.1 Format of the RESV message's Request RSPE 125 The this PE is used to request the generation of Reservation Status 126 from upstream CPs. It is carried in RESV messages in the Policy Data 127 Object. As long as a destination (or intermediate hop) is interested 128 in a reservation's status, it should continue to provide the RSPE in 129 its RESV refreshes. 131 0 1 2 3 132 +--------------+--------------+--------------+--------------+ 133 | PE Length | PE-Type = RSPE | 134 +--------------+--------------+-----------------------------+ 135 | Sub-Type = 1 | Request Flags| //////////////////////// | 136 +--------------+--------------+-----------------------------+ 138 Note: //// implies field is all zeros. 140 Request Flags: 142 0x01 = Non-immediate Response 144 When the Non-Immediate Response is set, the Authoritative CP may 145 delay the response until a refresh PATH message is sent. This may 146 reduce the overhead of sending an immediate PATH update. 148 2.2 Format of the PATH message's RSPE 150 The RSPE is carried in the Policy Data object of a PATH message. It 151 is created by the source itself, or a PDP close to the data source 152 acting as a confirmation point. The RSPE is updated by each 153 downstream CP with which it comes into contact. 155 Internet Draft Reservation Status Policy Element 25-Jun-99 157 0 1 2 3 158 +--------------+--------------+--------------+--------------+ 159 | PE Length | PE-Type = RSPE | 160 +--------------+--------------+-----------------------------+ 161 | Sub-Type = 2 | Status Flags | //////////////////////// | 162 +--------------+--------------+-----------------------------+ 163 | End-to-End Resv Duration | 164 +--------------+--------------+-----------------------------+ 165 | CP Timestamp | 166 +-----------------------------+-----------------------------+ 167 | CP Addr Type | CP Addr Length | 168 +-----------------------------+-----------------------------+ 169 | CP Address | 170 +-----------------------------+-----------------------------+ 172 Status Flags: 174 The RSPE status flags describe the reservation status. 176 0x01 = Reservation Installed. 177 0x02 = Unconfirmed Segments. 179 If no reservation was yet received, the Reservation Installed 180 flag will NOT be set. If a reservation was received and was 181 successfully installed by the current CP and all upstream CPs 182 (if any) since the last refresh period, the Reservation 183 Installed flag will be set. If the reservation state was 184 removed at the CP, the Reservation Installed flag will NOT be 185 set. 187 The Unconfirmed Segments flag indicates that the status of 188 some parts of the data path cannot be ascertained. This may 189 be because an intermediate network does not participate in 190 the RSPE exchange, or that the RSPE was not included in PATH 191 messages from some upstream segments. 193 As RSPE's are passed via PATH messages CP-to-CP down the data 194 path, a downstream CP is also responsible for relaying the 195 cumulative RSPE status of its upstream CPs. The Reservation 196 Installed status flag may be updated by the downstream CP to 197 reflect its local reservation state. It can only be set by 198 the downstream CP, however, if the upstream CP had it set 199 already and the downstream CP has successfully installed a 200 corresponding reservation. If the Unconfirmed Segments status 201 flag was set in an upstream RSPE, all downstream nodes must 202 leave the flag set in their forwarded RSPEs. A CP will set 203 the Unconfirmed Segments flag if no RSPE was provided by any 204 upstream CP (and the current CP is not the source), or if the 205 RSPE was generated by an unknown upstream CP (based on the 206 RSPE's CP Address field). An upstream CP is unknown if it 208 Internet Draft Reservation Status Policy Element 25-Jun-99 210 does not match any administratively configured upstream CPs 211 in the current CP's database, or the received RSPE's CP 212 Address field doesn't match the PHOP's address. 214 End-to-End Reservation Duration. 216 This value is determined by taking the MINIMUM of the current 217 CP's reservation duration, and the upstream CP's End-to-End 218 Uninterrupted reservation duration (if the upstream hop 219 provided the RSPE in its PATH). 221 The current CP's reservation duration is the duration that 222 the reservation state has been installed at the current CP. 223 This period is specified in seconds, initially set to zero. 224 When a reservation state is in any way removed at the CP, 225 this period counter will stop (and maintain the last known 226 duration). If the reservation state is reinstalled, this 227 field will be reset to zero and begin counting seconds again. 229 CP Timestamp. 231 This field is zero until a reservation is successfully 232 installed end-to-end. This is the current time in seconds 233 that the CP last set its RSPE's status to Reservation 234 Installed. When a reservation is removed, the CP Timestamp 235 remains set to the last time a reservation was successfully 236 installed end-to-end. The time is defined in seconds since 237 midnight GMT 1/1/1970 (system clock time). 239 Confirmation Point (CP) Address Type. 241 Determines the type of the address used to identify the 242 confirmation point. The currently defined values are: 244 0x00 = No Address 245 0x01 = IPv4 Address 246 0x02 = IPv6 Address 247 0x03 = DNS Address 249 CP Address Length. 251 Length in bytes of the CP's address. For IPv4 addresses the 252 length must be 4 bytes. For IPv6 addresses the length must be 253 16 bytes. For DNS Addresses, the length must not exceed 255 254 bytes of ASCII characters including a NULL terminator. A DNS 255 address must be aligned to a 4 byte boundary using NULL 256 characters. 258 CP Address. 260 Internet Draft Reservation Status Policy Element 25-Jun-99 262 This is the IP address of the upstream confirmation point 263 that last updated the RSPE. 265 3 A Simple Scenario 267 This simple scenario assumes that all RSVP aware hops are CP's and 268 can interpret the RSPE object. The data source is assumed as an 269 Authoritative CP (since it can confirm that the RESV reached the 270 source and was installed). 272 First, a requester generates a RSPE Type-1, and places it in its 273 Outgoing RESV message. Intermediate CPs are expected to forward the 274 PE Type-1 upstream as-is. When the Authoritative CP (source) 275 receives a RESV message containing an RSPE Type-1, requesting 276 status, it is expected to respond by inserting an RSPE Type-2 with 277 the appropriate status information in an updated PATH message and 278 all its subsequent PATH refreshes. The Installed Reservation flag 279 should be set in the RSPE if the reservation was installed, 280 specifying that the path is reserved. 282 The timestamp provides the time the reservation was installed. Once 283 installed, the duration timer should be used to record the duration 284 that the reservation remains. This is the duration (in seconds) that 285 the reservation has been installed, uninterrupted. Uninterrupted 286 implies that the reservation was never removed in any way, 287 preempted, or timed-out. 289 It is not particularly valuable to simply know that the source has 290 installed a reservation. This is because intermediate nodes may have 291 since lost or preempted their reservation state. Also, there may be 292 no trust relationship between the administrative domain of the 293 source and that of the destination (multilateral relationships are 294 hard to maintain). Furthermore, for a multicast session, a 295 reservation state close to the source could be associated with any 296 number of possible destinations. While some destinations may have 297 successfully issued a reservation that was installed end-to-end, 298 reservations from other destinations for the same session may have 299 failed. Ideally, all the hops for a RESV message should be able to 300 participate in the reservation status exchanges. Each hop's RSPE 301 status will depend on the status contained in the PATH messages from 302 the previous upstream PHOP as well as the current hop's status. 303 Effectively, the RSPE can be manipulated hop-by-hop. 305 Subsequent hops will examine and modify the RSPE in PATH messages 306 from the previous hops before forwarding the RSPE on downstream. 307 Specifically, the upstream reservation status flags field is updated 308 with the status of the reservation state at the current hop. If the 309 CP Address specified in the RSPE of the PHOP is different from the 310 address of the PHOP specified in the PATH message, then the 312 Internet Draft Reservation Status Policy Element 25-Jun-99 314 Unconfirmed Segments flag should be set in the forwarded RSPE (as 315 one or more intermediate nodes did not participate in the RSPE 316 exchange). For the updated RSPE, the timestamp will describe the 317 time that Reservation Installed status flag was first set by the 318 current hop (and, thus, was set by the upstream hops as well). 319 Additionally, the current hop keeps a local duration counter for the 320 lifetime of the local reservation state. The current hop will 321 compare its local duration counter with the value of the End-to-End 322 Duration specified in the PHOP's RSPE. The minimum of these two 323 values is then passed in the forwarded PATH's RSPE. Finally, the 324 current hop will insert the HOP address corresponding to the 325 interface out which the PATH carrying the RSPE is forwarded. This is 326 then used by the subsequent NHOP to verify there are no unconfirmed 327 segments. 329 If a reservation state is lost anywhere along the data path, the 330 nodes where the reservation state is lost should stop their duration 331 counters and unset the Reservation Installed flag in the forwarded 332 RSPE. This frozen duration will continue to be supplied in future 333 PATH refreshes by the now unreserved node including the timestamp of 334 the last time the reservation was successfully installed end-to-end. 335 If a reservation state is reinstalled the Reservation Installed flag 336 can be set again, the timestamp updated to the current time, and the 337 local duration counter reset to zero and begin counting the duration 338 of this reservation state. Updates to RSPEs can wait for the next 339 scheduled PATH refresh so as not to generate a new PATH message with 340 each local state change. 342 4 PDP Usage Model 344 It is likely that the above procedure will be too expensive or 345 technically hard to achieve in all RSVP nodes. It would be more 346 realistic to assume that RSPE processing would be limited to PDP's 347 operating at the edges of networks. In this case, PDPs represent a 348 set of RSVP nodes in their controlled network. Although not 349 foolproof, PDP's can be used to verify the previous (upstream) CP's 350 status, and integrate this status with its own. As such, a chain of 351 trust can be setup whereby scalable verification of the end-to-end 352 establishment of reservations is possible on a domain-by-domain 353 basis. 355 In order to allow this model PDPs within a network must be 356 configured to be confirmation points for their domain. They will 357 have to know which nodes are within their domain. Furthermore, the 358 PDP will have to be configured with the addresses of all CPs in 359 other domains with which it has bilateral relationships. 361 If the source of the corresponding PATH message is within the PDP's 362 domain, it is considered an Authoritative CP. An Authoritative CP is 363 the only CP that may respond to an incoming RESV with RSPE Type-1, 365 Internet Draft Reservation Status Policy Element 25-Jun-99 367 with an outgoing PATH with RSPE Type-2. An authoritative CP provides 368 the status on behalf of the source. 370 The upstream and downstream procedure is the same as in the hop-by- 371 hop approach, but between PDPs rather than hop-by-hop. The only 372 difference is that the RSPE CP Address field is verified against the 373 configured addresses of neighboring PDP CPs (as opposed to just the 374 RSVP PHOP address). If a PATH contains a RSPE from an unknown PDP 375 (based on the CP Address), then the Unsupported Segments flag must 376 be set before the RSPE is forwarded downstream. The forwarded RSPE's 377 CP Address field must contain the IP Address of the PDP that 378 created/modified the RSPE. 380 5 Authoritative CPs 382 If the source is a CP, it is always an authoritative CP. However, if 383 the Source does not respond to RSPE, the PDP controlling the domain 384 in which the source is located should be configured as the 385 authoritative CP. If both the source and the PDP are authoritative 386 (or in any other case where multiple CPs are authoritative) the most 387 upstream one wins. When an Authoritative CP sees a RSPE Type-2 in 388 the Incoming PATH, it looses its authority and acts as a regular CP. 389 It may regain this authority when the RSPE Type-2 expires and a new 390 one wasn't received. 392 There may be cases, where there is no authoritative CP to respond, 393 for example, if the source doesn't recognize RSPEs, and no PDP was 394 configured as the source's authoritative CP. In this case, the 395 absence of an RSPE in subsequent PATH messages implies there are 396 unconfirmed segments. After one full timeout period has expired 397 someone needs to reply with an RSPE specifying the Unconfirmed 398 Segments status. This someone would be any CP that has seen one 399 timeout period since it first encountered an RSPE Type-1 object, 400 without seeing an RSPE Type-2 response in return. 402 RSPEs, and any other Policy Data object expire at the same time as 403 other RSVP state [RSVP] and, therefore, must be continuously 404 refreshed. 406 6 Security Considerations 408 The RSPE is protected by RSVP integrity and Policy Data Integrity 409 mechanisms [RSVP, RSVP-EXT]. There is an underlying assumption that 410 none of the intermediate CPs are malicious. CPs are either trusted 411 (intra-net) or bound by a set of bilateral agreements between 412 neighboring CPs such that sanctions may take place by one neighbor 413 is the other is falsifying RSPE contents. 415 Internet Draft Reservation Status Policy Element 25-Jun-99 417 7 References 419 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 420 Control",IETF , Jan., 1999. 422 [RSVP-EXT] Shai Herzog "RSVP Extensions for Policy Control" , April, 1999. 425 [COPS] Boyle, J., et al. "Common Open Policy Service (COPS)" , Feb., 1999. 428 [RSVP]Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) 429 Version 1 - Functional Specification", RFC 2205, September 430 1997. 432 8 Author Information 434 David Durham 435 Intel 436 2111 NE 25th Avenue 437 Hillsboro, OR 97124 438 503.264.6232 439 David_Durham@mail.intel.com 441 Shai Herzog 442 IPHighway Inc. 443 Parker Plaza, 16th Floor 444 400 Kelby St. 445 Fort-Lee, NJ 07024 446 201.585.0800 447 Herzog@iphighway.com