idnits 2.17.1 draft-montessoro-rebook-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 22, 2012) is 4326 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 section? 'RFC2205' on line 698 looks like a reference -- Missing reference section? 'RFC5348' on line 702 looks like a reference -- Missing reference section? 'RFC2113' on line 695 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Montessoro 3 Internet-Draft R. Bernardini 4 Expires: December 24, 2012 UniUD 5 June 22, 2012 7 REBOOK: a Network Resource Booking Algorithm 8 draft-montessoro-rebook-00 10 Abstract 12 This document describes REBOOK, a resource reservation algorithm for 13 deterministic and fast dynamic resource allocation and release. 14 Based on a stateful approach, it handles faults and network errors, 15 and recovers from route changes and unexpected flows shutdown. The 16 distributed scheme used to store flows information have guaranteed 17 constant complexity. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 24, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. REBOOK Description . . . . . . . . . . . . . . . . . . . . . . 6 67 2.1. Message transport and format . . . . . . . . . . . . . . . 6 68 2.2. Node behaviour . . . . . . . . . . . . . . . . . . . . . . 7 69 2.2.1. Start-up . . . . . . . . . . . . . . . . . . . . . . . 7 70 2.2.2. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . 8 71 2.2.3. Data transmission . . . . . . . . . . . . . . . . . . 9 72 2.2.4. Reservation update . . . . . . . . . . . . . . . . . . 9 73 2.2.5. Path change . . . . . . . . . . . . . . . . . . . . . 9 74 2.2.6. Shutdown . . . . . . . . . . . . . . . . . . . . . . . 10 75 2.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 2.4. Router behaviour . . . . . . . . . . . . . . . . . . . . . 11 77 2.4.1. On reception of a RESV request . . . . . . . . . . . . 11 78 2.4.2. On reception of a data packet with the reference 79 field . . . . . . . . . . . . . . . . . . . . . . . . 12 80 2.4.3. On reception of a KPALV request . . . . . . . . . . . 12 81 2.4.4. On reception of a UP_RESV request . . . . . . . . . . 13 82 2.4.5. On reception of a RL_RESV request . . . . . . . . . . 13 83 2.4.6. Checking packet validity . . . . . . . . . . . . . . . 13 84 3. Using the IP Router Alert field . . . . . . . . . . . . . . . 14 85 4. Session Timeout . . . . . . . . . . . . . . . . . . . . . . . 14 86 5. What is a resource? . . . . . . . . . . . . . . . . . . . . . 15 87 6. Security consideration . . . . . . . . . . . . . . . . . . . . 15 88 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 8.1. References . . . . . . . . . . . . . . . . . . . . . . . . 15 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 A large number of applications prefer UDP as a transport protocol. 96 Among others, teleconferencing, streaming applications, real-time 97 communications, and networked multiplayer games; more generally, 98 applications whose information value and perceived quality strictly 99 relies on network delay, and also multi-cast services. Dynamics of 100 network load can impact negatively on multimedia applications; 101 however, UDP doesn't offer any native congestion control mechanism 102 and therefore it cannot guarantee Quality of Service (QoS). In 103 addition, congestion is often caused by these applications' high 104 bandwidth requirements. 106 On the other side, TCP provides a congestion control mechanism based 107 on message loss only, without any explicit knowledge about the 108 traffic load in intermediate network nodes along the communication 109 path. Therefore, both UDP and TCP sources need to be enhanced with a 110 congestion control algorithm not only aimed at reducing loss rate and 111 improving bandwidth utilization, but also at improving fairness 112 towards competing connections while satisfying related QoS 113 requirements. UDP flows should become TCP-friendly whereas UDP and 114 TCP flows should both become aware of network load in order to adjust 115 their transmission rate before losing packets. 117 In the last years, several methods have been introduced for QoS 118 control mechanisms, mainly based on adapting the sender's 119 transmission rate in accordance with the network congestion state 120 (see Sect. 2), but typically with such approaches no QoS guarantees 121 can be made effectively. The proposed algorithm, that we call 122 REBOOK, allows a control protocol to prevent congestion by reserving 123 enough resources for supporting a dynamically changing QoS level in 124 advance, therefore it would be the most straightforward approach to 125 manage the problem. 127 It must be outlined that REBOOK is not dependent on TCP/IP protocols, 128 as it can be used in any other packet switching network. Obviously, 129 in the following the Internet and the TCP/IP protocol suite will be 130 used as reference environment for its description. 132 REBOOK requires a hosting protocol to carry the algorithm's messages. 133 They can be handled by a dedicated signalling protocol, like RSVP 134 [RFC2205] or a new ad hoc protocol, or it can be embedded in a data 135 transport protocol, like TCP using the options field. 137 REBOOK is designed to handle virtually every transport-layer 138 connection or application-layer flows, not necessarily in real-time 139 or QoS only. In principle, except for very short flows the network 140 may benefit from the preventive declaration (and the consequent 141 resource booking) of the amount of traffic that each connection is 142 going to generate: if the application knows the amount of granted 143 resources in advance, it can modulate the data transmission rate to 144 prevent packet loss. 146 REBOOK implementation will bring to a sender-oriented protocol, 147 unlike RSVP which is receiver oriented. The node initiating a 148 connection is responsible for resource reservation request, based on 149 the amount and type of data to be transmitted, application 150 constraints and, possibly, SLA (Service Level Agreement) parameters. 151 While the connection is active the amount of granted resources may be 152 reduced to allow the activation of new flows in an almost-congested 153 network or may be increased if switching nodes become less loaded. 154 These events are acknowledged by the sender that will consequently 155 adapt its transmission rate. RSVP is receiver-oriented mainly 156 because it is designed to support single-cast and multi-cast flows as 157 well. 159 REBOOK does not rely on any special network feature: it works even if 160 only part of the network is REBOOK-aware as the resource reservation 161 is effective even if part of a flow traverses unaware routers. There 162 are no special requirements to routing, which can be asymmetrical 163 (transmitting and receiving flows can follow different paths), 164 except, obviously, its stability: in normal conditions data packets 165 and control messages must follow the same route for the duration of 166 the connection. Anyhow, if unexpected events occur, REBOOK 167 identifies route changes and recovers from errors and faults in the 168 network. 170 REBOOK does not rely on special hardware in routers either. Its 171 status storage scheme allows direct access to table entries without 172 any hardware look-up feature, simply using conventional memory 173 architecture. This makes its implementation faster and cheaper than 174 today's typical solutions provided by hardware hashing. Finally, 175 REBOOK does not require any improvement in the switching fabric. No 176 additional memory for queues and buffers nor different packet 177 handling. On the contrary, the router architecture will drive the 178 resource granting phase, depending on available resources left after 179 previous reservations. 181 It is worth observing that REBOOK is not another virtual circuit 182 technique; it is an add-on to conventional routers to improve 183 performance and features. For example, it does not require any 184 interaction with the routing protocols; it can work along routes 185 traversing several Autonomous Systems and routers using different 186 routing protocols; it does not require to be supported by all the 187 routers along the path nor for the supporting routers to be 188 contiguous; it does need neither hierarchy nor partitioning. In 189 respect of existing virtual circuit techniques, the novelty consists 190 in making each router autonomous in handling its REBOOK data 191 structures and the effects that routing dynamics have on them, 192 without any routing-aware signalling protocol. All these features 193 overcome most of the difficulties that limit a wide deployment of 194 MPLS or ATM, for example. Moreover, in case of routing instability 195 or faults, REBOOK can fail in enhancing router performance, but 196 packets are still forwarded in a best-effort, lookup-driven mode. 198 REBOOK is scalable since its computational cost is constant, 199 regardless of the number of active flows, yielding a solution to per- 200 flow resource reservation and packet handling, without the need of 201 aggregations. Moreover, it is intrinsically secure since each router 202 uses only the information generated in a previous phase by itself, 203 allowing any form of fast and secure symmetrical cryptography without 204 the need of a key exchange. 206 REBOOK is based on a distributed linked data structure in the sense 207 that it makes use of pointers to memory locations or indexes to table 208 entries containing information stored in the routers that are very 209 likely to be accessed in the future. Unlike conventional linked data 210 structures, pointers are not stored within the router they address, 211 but in the end nodes, in the packets, and in adjacent routers. When 212 a packet is received by a router, the pointer to the table entry to 213 be used for its processing is found in the packet itself and look-up 214 procedures are avoided. To keep the pointers consistent in a dynamic 215 environment, where route changes may send packets to routers 216 different than the ones the pointers refer to, a specific integrity 217 check is adopted. It makes REBOOK completely autonomous in 218 identifying faults, errors and route changes. The overhead 219 introduced by this integrity check is a critical issue. Thanks to 220 careful design of the distributed linked data structure, experimental 221 data demonstrate that this overhead is overcome by the speedup 222 provided by the look-up-free access to table entries. 224 REBOOK is a soft state algorithm. Reservations no longer refreshed 225 by keep-alive messages (due to errors, route changes or end node 226 faults) are removed by a low priority table cleanup task active in 227 the routers. This is the only part of the algorithm whose cost is 228 linear in the number of active flows, instead of constant. However, 229 the experimental results in [rebook] report 100 ms CPU time to handle 230 a 10,000,000 flows RR table, and in current implementation this 231 procedure is activated every 15 s. Thanks to this procedure and to 232 the consistency check, REBOOK messages are not required to be 233 acknowledged. 235 Summarizing, the main features of REBOOK are 236 Soft state: Reservations not refreshed by keep-alive messages are 237 automatically removed. 239 Scalability: The computational cost for routing and connection 240 handling is constant with the number of active flows. The only 241 cost that grows linearly with the number of active flows is the 242 removal of expired session, but experimental data shows that this 243 is negligible. 245 Consistency checks: Routers can easily check (in constant time) if 246 the received packet is actually a valid REBOOK-related packet. 247 This makes it possible for routers to identify faults, errors and 248 route changes. 250 Safety: Each router uses only the information generated in a 251 previous phase by itself, this makes it possible to use efficient 252 cryptographic protection techniques. 254 2. REBOOK Description 256 In a REBOOK setup there is a _source node_ that wants to reserve 257 resources to send data to a _target node_ with a guaranteed quality 258 of service. Before beginning the streaming, the source node reserves 259 the required resources by sending REBOOK requests to the target node. 260 The intermediate REBOOK-capable routers will analyze the REBOOK 261 requests and assign resources to the newly opened connection. This 262 section describes the details of the interaction between the source 263 node, the target node and the intermediate routers. 265 2.1. Message transport and format 267 It is worth emphasizing that REBOOK is not a protocol, but an 268 algorithm for resource reservations that can be "embedded" in many 269 different protocol. Because of this, we do not specify format for 270 REBOOK requests or how they are transmitted over the network, leaving 271 the choice of those details to the application employing REBOOK. 272 This is similar to what it is done in other protocols like TFRC (TCP- 273 Friendly Rate Control [RFC5348]) that requests that the source node 274 will send some data (e.g., estimated RTT, timestamps, ...) to the 275 receiver and that the receiver will send back some feedback data 276 (e.g., loss probability), but it leaves open how those data are 277 embedded in the protocol employing TFRC. 279 About the way REBOOK requests are transported, we can observe that 280 there are two possible approaches 282 o Via a specific protocol, "parallel" to the one used to stream the 283 data. 285 o Piggy-backed to the data stream. 287 Both solutions are reasonable and the choice will be a matter of 288 convenience of the specific application. 290 2.2. Node behaviour 292 In this section we describe an overview of the behavior of the 293 different REBOOK nodes (source, target and routers). 295 2.2.1. Start-up 297 o Suppose that a source node needs to stream data to the target 298 using a guaranteed QoS. The node decides to reserve the required 299 resources using REBOOK. Toward such a goal, the node sends a 300 REBOOK RESV request (see Section 2.3) to the target node. 302 o The packet with the RESV request travels over the network, passing 303 through several routers. If a router is REBOOK-capable, it 304 reserves the requested resources (if available) and update its 305 internal tables by adding an entry for the new stream(see 306 Section 2.4 for details). If not enough resources are available, 307 the router can decide to reserve less than the required resource 308 amount and write this information in the request. 310 o In order to be able to recover later the information about the 311 registered stream, the router appends to the RESV packet a 312 _reference_ to the new entry. 314 Although the "reference" written by the router can be thought 315 as the memory address of the entry associated with the stream, 316 it is worth emphasizing that a reference is used only by the 317 router that wrote it, so that, to the other nodes the reference 318 appears as an opaque string of bits. This implies that the 319 reference is not constrained to be an actual address and that 320 the router can give it any meaning without compromising 321 interoperability. For example, the reference could be an 322 _index_ to the table, possibly extended with some CRC and 323 encrypted to check for packet validity and improve security 324 (see Section 2.4.6). 326 o The RESV request arrives to the target. The RESV packet now 327 contains the amount of resources reserved along the path and the 328 list of table references added by the intermediate REBOOK-capable. 329 The target sends back to the source the received packet with a 330 RESV_ACK request (see Section 2.3). Now the source knows the 331 amount of reserved resources and the reference list. 333 2.2.2. Keep-Alive 335 Periodically, starting right after receiving the RESV_ACK, the source 336 sends keep-alive KPALV requests to the target node. The KPALV 337 request carries the following data 339 o The amount of reserved resources 341 o The list of table references inserted by the routers 343 When a router receives a KPALV message, first it checks if it is a 344 valid KPALV request relative to an already opened stream. If the 345 check is positive 347 1. It updates the amount of reserved resources. 349 In order to understand why this is necessary, consider the 350 following case: source S wants to send data to target T; 351 suppose that the canonical required bandwidth is 3 Mbit/s, but 352 that transmission can still be done with good enough quality 353 as soon as the bandwidth is at least 512 kbit/s (for example, 354 the source could encode the data at a lower quality). Suppose 355 also that between S and T there are two routers A and B, the 356 latter with only 1 Mbit/s available. When A processes the 357 RESV request, it has enough resources and decide to reserve 3 358 Mbit/s to S; however, since B has not enough bandwidth it 359 reserves only 1 Mbit/s to S. Note that A is wasting 2 Mbit/s, 360 since S will never be able to use more than 1 Mbit/s, but A 361 reserved 3 Mbit/s to S. However, since the KPALV packet sent 362 by S will contain the amount of reserved resources, A can see 363 that only 1 Mbit/s will be used by S and will update 364 accordingly its tables. 366 2. It stores in the table entry associated with the stream the 367 reference written by the next router. See Section 2.4 for 368 details about how this value is used. 370 KPALV messages are expected to be received at regular intervals. If 371 KPALV packets are not received for a time exceeding a threshold 372 (possibly depending on the path RTT), the router will suppose the 373 session expired and will release the reserved resources. 375 Finally, observe that the target usually ignores the KPALV packets, 376 unless there is a change in the reservation. See Section 2.2.4 for 377 details. 379 2.2.3. Data transmission 381 In the simplest implementation of REBOOK, no special handling is 382 required for data packets. The routers will access to the routing 383 tables in the usual way. 385 However, in order to speed-up the access to the table, avoiding the 386 look-up procedure, the source can include in every transmitted data 387 packet the reference value inserted by the first router. (See 388 Section 2.4 for details about how this value is used.) Since this 389 value must be used by the routers, the router must know (i) that the 390 packet belongs to a REBOOK stream and (ii) where the reference is 391 stored. A possible solution, employing the IP Router Alert field 392 [RFC2113] is described in Section 3. 394 2.2.4. Reservation update 396 In some cases it could be necessary to update the resource reserved. 397 For example, in a video streaming application the user could decide 398 to receive a better quality (but more expensive) version of the 399 video, so the source needs to reserve more resources. Another case 400 where it is necessary to update the reservation is when some routers 401 in the path are not REBOOK capable, so that their service is of best- 402 effort type. If congestion at the non-REBOOK router happens, the 403 source detects it by using known congestion control procedures 404 (e.g.,TFRC [RFC5348]) and it can decide to update the reserved 405 bandwidth. Finally, a third case is when a router receives a request 406 that cannot satisfy and it can decide to reduce the amount of 407 resources assigned to another node in order to satisfy the new 408 request. 410 In all those cases, the reservation can be changed by using a KPALV 411 request with the new reservation. If the source wants to reduce the 412 allocated resources, it just generates the request with the new 413 allocation value; if an intermediate router wants to reduce the 414 reserved bandwidth, it will wait for the first KPALV packet to arrive 415 and it will update the reservation value in it. 417 When the target receives a KPALV packet with different resource 418 values, it sends to the source a PRL_ACK (see Section 2.3) with the 419 new values. 421 Finally, if the source desires to increase the reserved resources, it 422 can use the request UP_RESV (see Section 2.3). 424 2.2.5. Path change 425 2.2.6. Shutdown 427 When the transmission is concluded, the source can release the 428 reserved resources by sending a RL_RESV request. This will cause the 429 intermediate routers to release the allocated resources. 431 2.3. Commands 433 RESV Sent at the beginning of a session. When it leaves the source 434 it contains the amount of required resources (R_req) and the 435 minimum admissible amount of resources (R_min) and the current 436 amount of reserved resources (R_curr), initialized to R_req. The 437 request is modified by intermediate routers as follows 439 * If the router cannot allocate R_curr resources, it writes in 440 R_curr the reserved amount of resources. 442 * The router creates a new entry in its tables for the new stream 443 and append to the RESV request a "reference" to the new entry. 445 RESV_ACK Sent by the target to the source when the target receives 446 the RESV requests. Its payload stores the value of R_curr in the 447 received RESV request and the list of router references. 449 KPALV Keep-alive request sent by the source to the target. They 450 carry the values of R_min, R_req and R_curr, together with the 451 router references. They are used, beside for keeping the 452 connection "hot" to that the routers release the resources, for 453 updating the resource reservation. They are ignored by the target 454 node, unless the resource reservation has been changed. 456 PRL_ACK Sent by the target to the source when a KPALV with changed 457 reservation is received. Its payload stores the value of R_curr 458 in the received RESV request and the list of router references. 460 UP_RESV Sent by the source to increase the amount of reserved 461 resources. It is handled like a RESV request, with the difference 462 that the stream entry in the router tables must by already 463 present. 465 RL_RESV Sent by the source at the end of the session. The routers 466 will release the allocated resources and will remove the stream 467 entry from their tables. 469 2.4. Router behaviour 471 In this section we describe the expected behavior of a REBOOK-capable 472 router, with reference to a specific implementation. It is clear 473 that the implementation details are mostly a private matter of the 474 router and that they can be changed as long as the router behavior 475 "seen" by the rest of the network does not change. 477 In the reference implementation chosen here the router uses two 478 tables 480 o The usual _routing table_ mapping destinations to router ports 482 o A _stream table_ addressed via the reference that the router 483 writes in the RESV packet. Each entry of the table contains 484 information relative to the specific stream and it is expected to 485 contain at least 487 * The current values of R_min, R_req and R_curr 489 * The reference of the next router 491 * The session expiration time T_exp. If no KPALV packets are 492 received before T_exp, the session is considered expired and 493 the allocated resources released 495 * A reference to the routing table pointing to the entry 496 associated with the target address. 498 2.4.1. On reception of a RESV request 500 When the router receives a RESV request 502 o It creates a new entry in the stream table for the new stream. 503 Let REF be the reference to the new entry. It look-ups the 504 routing information required for the stream and set the routing 505 table reference in the stream table entry accordingly. 507 o It checks the amount of resources that it can allocate to the 508 stream and update the stream table accordingly. If the allocated 509 resources are less the R_curr value in the RESV request, update 510 the RESV value to the actual amount of allocated resources. 512 o It appends to the RESV request the value of REF and forward the 513 updated request to the next hop. 515 2.4.2. On reception of a data packet with the reference field 517 As explained in Section 2.2.3, the source can optionally include in 518 the data packet the reference belonging to the first router. In this 519 case, when the router receives a packet that is marked as a REBOOK 520 packet 522 o It checks for the packet validity. This is done both for security 523 and for detecting events like route changes and faults. The check 524 can be done in constant time by checking the REBOOK reference in 525 the packet, see Section 2.4.6 for details. If the check is 526 positive, continue, otherwise the REBOOK reference is invalidated 527 and the packet is handled as a normal one. 529 o By using the router reference field embedded in the packet, it 530 accesses the entry in the stream table. 532 o It copies the router reference stored in the table in the 533 corresponding data packet field. Note that in this way the next 534 REBOOK-capable router will find in the RRef field the reference 535 value that it wrote in the RESV packet during the setup phase. 537 o It finds the corresponding entry in the routing table and forward 538 the packet toward the right output port. 540 o Finally, note that the access to the table at constant cost allows 541 to implement new features, e.g., accounting and security controls. 543 Note that the operations above require a constant time, independent 544 on the number of entries in the stream table. 546 2.4.3. On reception of a KPALV request 548 When the router receives a KPALV 550 o It checks for the packet validity. This is done both for security 551 and for detecting events like route changes and faults. The check 552 can be done in constant time by checking the REBOOK reference in 553 the packet, see Section 2.4.6 for details. If the check is 554 positive, continue, otherwise discard the packet (GIUSTO?) 556 o It finds the corresponding entries in the stream table. 558 o It updates the expiring time T_exp of the session 560 o If the value of R_curr in the KPALV request is lower than the 561 corresponding value stored in the table, it updates the table (and 562 release the corresponding resources too) 564 o If the router lowered the resources assigned to the stream because 565 of some resource re-assignation, it update the R_curr value in the 566 KPALV request 568 o The (possibly updated) KPALV request is forwarded to the next hop 570 2.4.4. On reception of a UP_RESV request 572 The behavior is similar to the case of reception of a RESV request, 573 with the difference that the stream must already have an entry in the 574 stream table 576 2.4.5. On reception of a RL_RESV request 578 When the router receives a RL_RESV 580 o It checks its validity (see Section 2.4.6). If the check is 581 positive, continue, otherwise discard the packet (GIUSTO?) 583 o It deletes the entry associated to the stream from the stream 584 table and releases the associated resources. 586 2.4.6. Checking packet validity 588 For safety reasons, a router must check if the received REBOOK packet 589 is a valid one. The check can be done by exploiting some 590 redundancies in the REBOOK structure 592 o When a router receives for the first time a RESV request, it opens 593 a new entry in the stream table and initialize it with the data 594 stored in the request, including the FlowID, that is, the (source 595 address, target address) pair, where each address is, of course, a 596 (host address, port) pair. When a data packet or a REBOOK request 597 is received, the router can check that the FlowID of the received 598 request matches the FlowID stored in the stream table. 600 o If the router use only B <32 bits of the 32 bits of the reference, 601 it can use the remaining 32-B bits for the validity check. A 602 possible approach is to fill the unused 32-B bits with parity bits 603 and encrypting the result. The check for reference validity is 604 immediate and it is very difficult to forge a valid reference. 605 Note that since the reference value is an opaque 32-bit string for 606 the other nodes, this type of checks can be implemented privately 607 by the router without problems of interoperability. 609 o Another low-cost validity check supposes that the free entries in 610 the stream table are organized in a linked list. In this case the 611 router initializes the empty stream table by joining its entries 612 in random order, making unpredictable the order the entries will 613 be used by the router. Moreover, in order to avoid a fast reuse 614 of the same entry, released entries can be inserted at the end of 615 the free list, while allocated entries can be extracted from the 616 head. 617 In order to check the validity of the REBOOK packet, the router 618 can verify that the referenced entry is really used. 620 3. Using the IP Router Alert field 622 A possible solution to embed REBOOK information inside data packet is 623 to exploit the IP Router Alert field. This will require the 624 allocation of a suitable code-point in the IANA maintained registry. 625 A REBOOK value in the IP Router Alert field will signal to the router 626 that the 32-bit reference value has been stored between the next 627 level protocol header and the data payload. 629 4. Session Timeout 631 As already explained, because of the soft state nature of REBOOK, 632 sessions that are not refreshed by keep-alive messages are considered 633 expired and their resources released. An important issue is the 634 choice of the timeout interval: if it is too short, the source will 635 send many keep-alive packets, increasing the overhead; if it is too 636 long, the resources associated with a crashed session (i.e., a 637 session where the source crashed) can remain unavailable for a long 638 time (until the session expires), reducing the efficiency of the 639 router. Note that it is important that the source knows the session 640 timeout, in order to choose the keep-alive frequency. 642 Some possible solutions about the choice of the session timeout are 643 the following 645 Fixed The timeout value could be fixed by the protocol. This is 646 maybe the simplest solution and it has the advantage of a low 647 overhead, but maybe is too rigid. 649 RTT based The timeout could be fixed to a multiple of the round trip 650 time (RTT) between the source and the target. The source would 651 send keep-alive packet with a frequency that depends on the RTT 652 and the expiration time should be long enough to keep in account 653 the probability that a keep-alive packet gets lost. This overhead 654 of this solution is low. It is important that the difference 655 between the RTT estimated by the router and the RTT estimated by 656 the source is small. 658 Timeout as a resource With this approach the timeout is considered a 659 resource that can be negotiated by using the REBOOK mechanism (see 660 Section 5). Therefore, the source will send its timeout request 661 in the RESV packet and the routers will change the timeout value 662 in the RESV request according to their needs. Moreover, timeout 663 can be changed dynamically during the session by the usual REBOOK 664 procedure. The drawback of this approach is that it introduces 665 overhead in the RESV and KPALV packets. Note that with this 666 approach, the session timeout is the smallest among the timeouts 667 chosen by the routers. 669 5. What is a resource? 671 In this document we talked generically about "resources" to be 672 reserved, without describing in details what a resource is. 673 Typically one can expect bandwidth to be a negotiable resource, but 674 other types of resources are possible. For example, the source could 675 want to improve the latency by assigning to the stream a higher 676 priority, so that the router will store the packets in a high- 677 priority queue. Another example of possible resource is the session 678 timeout (see Section 4). Depending on the application using REBOOK, 679 it could prove useful to keep the set of resources extensible, maybe 680 by using a Type-Length-Value format, so that routers that do not 681 recognize some resources can skip them. 683 6. Security consideration 685 To be written 687 7. IANA considerations 689 To be written 691 8. References 693 8.1. References 695 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 696 February 1997. 698 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 699 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 700 Functional Specification", RFC 2205, September 1997. 702 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 703 Friendly Rate Control (TFRC): Protocol Specification", 704 RFC 5348, September 2008. 706 8.2. Informative References 708 [rebook] Montessoro, P. and D. Daniele, "REBOOK: A Deterministic, 709 Robust and Scalable Resource Booking Algorithm", J Netw 710 Syst Manage DOI 10.1007/s10922-010-9167-8, may 2010. 712 Authors' Addresses 714 Pierluca Montessoro 715 University of Udine 716 Via delle Scienze 208 717 Udine 33100 718 Italy 720 Phone: +39-0432-55-8286 721 EMail: montessoro@uniud.it 723 Riccardo Bernardini 724 University of Udine 725 Via delle Scienze 208 726 Udine 33100 727 Italy 729 Phone: +39-0432-55-8271 730 EMail: riccardo.bernardini@uniud.it