Internet Engineering Task Force P. Montessoro Internet-Draft R. Bernardini Expires: December 24, 2012 UniUD June 22, 2012 REBOOK: a Network Resource Booking Algorithm draft-montessoro-rebook-00 Abstract This document describes REBOOK, a resource reservation algorithm for deterministic and fast dynamic resource allocation and release. Based on a stateful approach, it handles faults and network errors, and recovers from route changes and unexpected flows shutdown. The distributed scheme used to store flows information have guaranteed constant complexity. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 24, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Montessoro & Bernardini Expires December 24, 2012 [Page 1] Internet-Draft REBOOK June 2012 described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. REBOOK Description . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Message transport and format . . . . . . . . . . . . . . . 6 2.2. Node behaviour . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Start-up . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . 8 2.2.3. Data transmission . . . . . . . . . . . . . . . . . . 9 2.2.4. Reservation update . . . . . . . . . . . . . . . . . . 9 2.2.5. Path change . . . . . . . . . . . . . . . . . . . . . 9 2.2.6. Shutdown . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Router behaviour . . . . . . . . . . . . . . . . . . . . . 11 2.4.1. On reception of a RESV request . . . . . . . . . . . . 11 2.4.2. On reception of a data packet with the reference field . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.3. On reception of a KPALV request . . . . . . . . . . . 12 2.4.4. On reception of a UP_RESV request . . . . . . . . . . 13 2.4.5. On reception of a RL_RESV request . . . . . . . . . . 13 2.4.6. Checking packet validity . . . . . . . . . . . . . . . 13 3. Using the IP Router Alert field . . . . . . . . . . . . . . . 14 4. Session Timeout . . . . . . . . . . . . . . . . . . . . . . . 14 5. What is a resource? . . . . . . . . . . . . . . . . . . . . . 15 6. Security consideration . . . . . . . . . . . . . . . . . . . . 15 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. References . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Montessoro & Bernardini Expires December 24, 2012 [Page 2] Internet-Draft REBOOK June 2012 1. Introduction A large number of applications prefer UDP as a transport protocol. Among others, teleconferencing, streaming applications, real-time communications, and networked multiplayer games; more generally, applications whose information value and perceived quality strictly relies on network delay, and also multi-cast services. Dynamics of network load can impact negatively on multimedia applications; however, UDP doesn't offer any native congestion control mechanism and therefore it cannot guarantee Quality of Service (QoS). In addition, congestion is often caused by these applications' high bandwidth requirements. On the other side, TCP provides a congestion control mechanism based on message loss only, without any explicit knowledge about the traffic load in intermediate network nodes along the communication path. Therefore, both UDP and TCP sources need to be enhanced with a congestion control algorithm not only aimed at reducing loss rate and improving bandwidth utilization, but also at improving fairness towards competing connections while satisfying related QoS requirements. UDP flows should become TCP-friendly whereas UDP and TCP flows should both become aware of network load in order to adjust their transmission rate before losing packets. In the last years, several methods have been introduced for QoS control mechanisms, mainly based on adapting the sender's transmission rate in accordance with the network congestion state (see Sect. 2), but typically with such approaches no QoS guarantees can be made effectively. The proposed algorithm, that we call REBOOK, allows a control protocol to prevent congestion by reserving enough resources for supporting a dynamically changing QoS level in advance, therefore it would be the most straightforward approach to manage the problem. It must be outlined that REBOOK is not dependent on TCP/IP protocols, as it can be used in any other packet switching network. Obviously, in the following the Internet and the TCP/IP protocol suite will be used as reference environment for its description. REBOOK requires a hosting protocol to carry the algorithm's messages. They can be handled by a dedicated signalling protocol, like RSVP [RFC2205] or a new ad hoc protocol, or it can be embedded in a data transport protocol, like TCP using the options field. REBOOK is designed to handle virtually every transport-layer connection or application-layer flows, not necessarily in real-time or QoS only. In principle, except for very short flows the network may benefit from the preventive declaration (and the consequent Montessoro & Bernardini Expires December 24, 2012 [Page 3] Internet-Draft REBOOK June 2012 resource booking) of the amount of traffic that each connection is going to generate: if the application knows the amount of granted resources in advance, it can modulate the data transmission rate to prevent packet loss. REBOOK implementation will bring to a sender-oriented protocol, unlike RSVP which is receiver oriented. The node initiating a connection is responsible for resource reservation request, based on the amount and type of data to be transmitted, application constraints and, possibly, SLA (Service Level Agreement) parameters. While the connection is active the amount of granted resources may be reduced to allow the activation of new flows in an almost-congested network or may be increased if switching nodes become less loaded. These events are acknowledged by the sender that will consequently adapt its transmission rate. RSVP is receiver-oriented mainly because it is designed to support single-cast and multi-cast flows as well. REBOOK does not rely on any special network feature: it works even if only part of the network is REBOOK-aware as the resource reservation is effective even if part of a flow traverses unaware routers. There are no special requirements to routing, which can be asymmetrical (transmitting and receiving flows can follow different paths), except, obviously, its stability: in normal conditions data packets and control messages must follow the same route for the duration of the connection. Anyhow, if unexpected events occur, REBOOK identifies route changes and recovers from errors and faults in the network. REBOOK does not rely on special hardware in routers either. Its status storage scheme allows direct access to table entries without any hardware look-up feature, simply using conventional memory architecture. This makes its implementation faster and cheaper than today's typical solutions provided by hardware hashing. Finally, REBOOK does not require any improvement in the switching fabric. No additional memory for queues and buffers nor different packet handling. On the contrary, the router architecture will drive the resource granting phase, depending on available resources left after previous reservations. It is worth observing that REBOOK is not another virtual circuit technique; it is an add-on to conventional routers to improve performance and features. For example, it does not require any interaction with the routing protocols; it can work along routes traversing several Autonomous Systems and routers using different routing protocols; it does not require to be supported by all the routers along the path nor for the supporting routers to be contiguous; it does need neither hierarchy nor partitioning. In Montessoro & Bernardini Expires December 24, 2012 [Page 4] Internet-Draft REBOOK June 2012 respect of existing virtual circuit techniques, the novelty consists in making each router autonomous in handling its REBOOK data structures and the effects that routing dynamics have on them, without any routing-aware signalling protocol. All these features overcome most of the difficulties that limit a wide deployment of MPLS or ATM, for example. Moreover, in case of routing instability or faults, REBOOK can fail in enhancing router performance, but packets are still forwarded in a best-effort, lookup-driven mode. REBOOK is scalable since its computational cost is constant, regardless of the number of active flows, yielding a solution to per- flow resource reservation and packet handling, without the need of aggregations. Moreover, it is intrinsically secure since each router uses only the information generated in a previous phase by itself, allowing any form of fast and secure symmetrical cryptography without the need of a key exchange. REBOOK is based on a distributed linked data structure in the sense that it makes use of pointers to memory locations or indexes to table entries containing information stored in the routers that are very likely to be accessed in the future. Unlike conventional linked data structures, pointers are not stored within the router they address, but in the end nodes, in the packets, and in adjacent routers. When a packet is received by a router, the pointer to the table entry to be used for its processing is found in the packet itself and look-up procedures are avoided. To keep the pointers consistent in a dynamic environment, where route changes may send packets to routers different than the ones the pointers refer to, a specific integrity check is adopted. It makes REBOOK completely autonomous in identifying faults, errors and route changes. The overhead introduced by this integrity check is a critical issue. Thanks to careful design of the distributed linked data structure, experimental data demonstrate that this overhead is overcome by the speedup provided by the look-up-free access to table entries. REBOOK is a soft state algorithm. Reservations no longer refreshed by keep-alive messages (due to errors, route changes or end node faults) are removed by a low priority table cleanup task active in the routers. This is the only part of the algorithm whose cost is linear in the number of active flows, instead of constant. However, the experimental results in [rebook] report 100 ms CPU time to handle a 10,000,000 flows RR table, and in current implementation this procedure is activated every 15 s. Thanks to this procedure and to the consistency check, REBOOK messages are not required to be acknowledged. Summarizing, the main features of REBOOK are Montessoro & Bernardini Expires December 24, 2012 [Page 5] Internet-Draft REBOOK June 2012 Soft state: Reservations not refreshed by keep-alive messages are automatically removed. Scalability: The computational cost for routing and connection handling is constant with the number of active flows. The only cost that grows linearly with the number of active flows is the removal of expired session, but experimental data shows that this is negligible. Consistency checks: Routers can easily check (in constant time) if the received packet is actually a valid REBOOK-related packet. This makes it possible for routers to identify faults, errors and route changes. Safety: Each router uses only the information generated in a previous phase by itself, this makes it possible to use efficient cryptographic protection techniques. 2. REBOOK Description In a REBOOK setup there is a _source node_ that wants to reserve resources to send data to a _target node_ with a guaranteed quality of service. Before beginning the streaming, the source node reserves the required resources by sending REBOOK requests to the target node. The intermediate REBOOK-capable routers will analyze the REBOOK requests and assign resources to the newly opened connection. This section describes the details of the interaction between the source node, the target node and the intermediate routers. 2.1. Message transport and format It is worth emphasizing that REBOOK is not a protocol, but an algorithm for resource reservations that can be "embedded" in many different protocol. Because of this, we do not specify format for REBOOK requests or how they are transmitted over the network, leaving the choice of those details to the application employing REBOOK. This is similar to what it is done in other protocols like TFRC (TCP- Friendly Rate Control [RFC5348]) that requests that the source node will send some data (e.g., estimated RTT, timestamps, ...) to the receiver and that the receiver will send back some feedback data (e.g., loss probability), but it leaves open how those data are embedded in the protocol employing TFRC. About the way REBOOK requests are transported, we can observe that there are two possible approaches o Via a specific protocol, "parallel" to the one used to stream the data. Montessoro & Bernardini Expires December 24, 2012 [Page 6] Internet-Draft REBOOK June 2012 o Piggy-backed to the data stream. Both solutions are reasonable and the choice will be a matter of convenience of the specific application. 2.2. Node behaviour In this section we describe an overview of the behavior of the different REBOOK nodes (source, target and routers). 2.2.1. Start-up o Suppose that a source node needs to stream data to the target using a guaranteed QoS. The node decides to reserve the required resources using REBOOK. Toward such a goal, the node sends a REBOOK RESV request (see Section 2.3) to the target node. o The packet with the RESV request travels over the network, passing through several routers. If a router is REBOOK-capable, it reserves the requested resources (if available) and update its internal tables by adding an entry for the new stream(see Section 2.4 for details). If not enough resources are available, the router can decide to reserve less than the required resource amount and write this information in the request. o In order to be able to recover later the information about the registered stream, the router appends to the RESV packet a _reference_ to the new entry. Although the "reference" written by the router can be thought as the memory address of the entry associated with the stream, it is worth emphasizing that a reference is used only by the router that wrote it, so that, to the other nodes the reference appears as an opaque string of bits. This implies that the reference is not constrained to be an actual address and that the router can give it any meaning without compromising interoperability. For example, the reference could be an _index_ to the table, possibly extended with some CRC and encrypted to check for packet validity and improve security (see Section 2.4.6). o The RESV request arrives to the target. The RESV packet now contains the amount of resources reserved along the path and the list of table references added by the intermediate REBOOK-capable. The target sends back to the source the received packet with a RESV_ACK request (see Section 2.3). Now the source knows the amount of reserved resources and the reference list. Montessoro & Bernardini Expires December 24, 2012 [Page 7] Internet-Draft REBOOK June 2012 2.2.2. Keep-Alive Periodically, starting right after receiving the RESV_ACK, the source sends keep-alive KPALV requests to the target node. The KPALV request carries the following data o The amount of reserved resources o The list of table references inserted by the routers When a router receives a KPALV message, first it checks if it is a valid KPALV request relative to an already opened stream. If the check is positive 1. It updates the amount of reserved resources. In order to understand why this is necessary, consider the following case: source S wants to send data to target T; suppose that the canonical required bandwidth is 3 Mbit/s, but that transmission can still be done with good enough quality as soon as the bandwidth is at least 512 kbit/s (for example, the source could encode the data at a lower quality). Suppose also that between S and T there are two routers A and B, the latter with only 1 Mbit/s available. When A processes the RESV request, it has enough resources and decide to reserve 3 Mbit/s to S; however, since B has not enough bandwidth it reserves only 1 Mbit/s to S. Note that A is wasting 2 Mbit/s, since S will never be able to use more than 1 Mbit/s, but A reserved 3 Mbit/s to S. However, since the KPALV packet sent by S will contain the amount of reserved resources, A can see that only 1 Mbit/s will be used by S and will update accordingly its tables. 2. It stores in the table entry associated with the stream the reference written by the next router. See Section 2.4 for details about how this value is used. KPALV messages are expected to be received at regular intervals. If KPALV packets are not received for a time exceeding a threshold (possibly depending on the path RTT), the router will suppose the session expired and will release the reserved resources. Finally, observe that the target usually ignores the KPALV packets, unless there is a change in the reservation. See Section 2.2.4 for details. Montessoro & Bernardini Expires December 24, 2012 [Page 8] Internet-Draft REBOOK June 2012 2.2.3. Data transmission In the simplest implementation of REBOOK, no special handling is required for data packets. The routers will access to the routing tables in the usual way. However, in order to speed-up the access to the table, avoiding the look-up procedure, the source can include in every transmitted data packet the reference value inserted by the first router. (See Section 2.4 for details about how this value is used.) Since this value must be used by the routers, the router must know (i) that the packet belongs to a REBOOK stream and (ii) where the reference is stored. A possible solution, employing the IP Router Alert field [RFC2113] is described in Section 3. 2.2.4. Reservation update In some cases it could be necessary to update the resource reserved. For example, in a video streaming application the user could decide to receive a better quality (but more expensive) version of the video, so the source needs to reserve more resources. Another case where it is necessary to update the reservation is when some routers in the path are not REBOOK capable, so that their service is of best- effort type. If congestion at the non-REBOOK router happens, the source detects it by using known congestion control procedures (e.g.,TFRC [RFC5348]) and it can decide to update the reserved bandwidth. Finally, a third case is when a router receives a request that cannot satisfy and it can decide to reduce the amount of resources assigned to another node in order to satisfy the new request. In all those cases, the reservation can be changed by using a KPALV request with the new reservation. If the source wants to reduce the allocated resources, it just generates the request with the new allocation value; if an intermediate router wants to reduce the reserved bandwidth, it will wait for the first KPALV packet to arrive and it will update the reservation value in it. When the target receives a KPALV packet with different resource values, it sends to the source a PRL_ACK (see Section 2.3) with the new values. Finally, if the source desires to increase the reserved resources, it can use the request UP_RESV (see Section 2.3). 2.2.5. Path change Montessoro & Bernardini Expires December 24, 2012 [Page 9] Internet-Draft REBOOK June 2012 2.2.6. Shutdown When the transmission is concluded, the source can release the reserved resources by sending a RL_RESV request. This will cause the intermediate routers to release the allocated resources. 2.3. Commands RESV Sent at the beginning of a session. When it leaves the source it contains the amount of required resources (R_req) and the minimum admissible amount of resources (R_min) and the current amount of reserved resources (R_curr), initialized to R_req. The request is modified by intermediate routers as follows * If the router cannot allocate R_curr resources, it writes in R_curr the reserved amount of resources. * The router creates a new entry in its tables for the new stream and append to the RESV request a "reference" to the new entry. RESV_ACK Sent by the target to the source when the target receives the RESV requests. Its payload stores the value of R_curr in the received RESV request and the list of router references. KPALV Keep-alive request sent by the source to the target. They carry the values of R_min, R_req and R_curr, together with the router references. They are used, beside for keeping the connection "hot" to that the routers release the resources, for updating the resource reservation. They are ignored by the target node, unless the resource reservation has been changed. PRL_ACK Sent by the target to the source when a KPALV with changed reservation is received. Its payload stores the value of R_curr in the received RESV request and the list of router references. UP_RESV Sent by the source to increase the amount of reserved resources. It is handled like a RESV request, with the difference that the stream entry in the router tables must by already present. RL_RESV Sent by the source at the end of the session. The routers will release the allocated resources and will remove the stream entry from their tables. Montessoro & Bernardini Expires December 24, 2012 [Page 10] Internet-Draft REBOOK June 2012 2.4. Router behaviour In this section we describe the expected behavior of a REBOOK-capable router, with reference to a specific implementation. It is clear that the implementation details are mostly a private matter of the router and that they can be changed as long as the router behavior "seen" by the rest of the network does not change. In the reference implementation chosen here the router uses two tables o The usual _routing table_ mapping destinations to router ports o A _stream table_ addressed via the reference that the router writes in the RESV packet. Each entry of the table contains information relative to the specific stream and it is expected to contain at least * The current values of R_min, R_req and R_curr * The reference of the next router * The session expiration time T_exp. If no KPALV packets are received before T_exp, the session is considered expired and the allocated resources released * A reference to the routing table pointing to the entry associated with the target address. 2.4.1. On reception of a RESV request When the router receives a RESV request o It creates a new entry in the stream table for the new stream. Let REF be the reference to the new entry. It look-ups the routing information required for the stream and set the routing table reference in the stream table entry accordingly. o It checks the amount of resources that it can allocate to the stream and update the stream table accordingly. If the allocated resources are less the R_curr value in the RESV request, update the RESV value to the actual amount of allocated resources. o It appends to the RESV request the value of REF and forward the updated request to the next hop. Montessoro & Bernardini Expires December 24, 2012 [Page 11] Internet-Draft REBOOK June 2012 2.4.2. On reception of a data packet with the reference field As explained in Section 2.2.3, the source can optionally include in the data packet the reference belonging to the first router. In this case, when the router receives a packet that is marked as a REBOOK packet o It checks for the packet validity. This is done both for security and for detecting events like route changes and faults. The check can be done in constant time by checking the REBOOK reference in the packet, see Section 2.4.6 for details. If the check is positive, continue, otherwise the REBOOK reference is invalidated and the packet is handled as a normal one. o By using the router reference field embedded in the packet, it accesses the entry in the stream table. o It copies the router reference stored in the table in the corresponding data packet field. Note that in this way the next REBOOK-capable router will find in the RRef field the reference value that it wrote in the RESV packet during the setup phase. o It finds the corresponding entry in the routing table and forward the packet toward the right output port. o Finally, note that the access to the table at constant cost allows to implement new features, e.g., accounting and security controls. Note that the operations above require a constant time, independent on the number of entries in the stream table. 2.4.3. On reception of a KPALV request When the router receives a KPALV o It checks for the packet validity. This is done both for security and for detecting events like route changes and faults. The check can be done in constant time by checking the REBOOK reference in the packet, see Section 2.4.6 for details. If the check is positive, continue, otherwise discard the packet (GIUSTO?) o It finds the corresponding entries in the stream table. o It updates the expiring time T_exp of the session o If the value of R_curr in the KPALV request is lower than the corresponding value stored in the table, it updates the table (and release the corresponding resources too) Montessoro & Bernardini Expires December 24, 2012 [Page 12] Internet-Draft REBOOK June 2012 o If the router lowered the resources assigned to the stream because of some resource re-assignation, it update the R_curr value in the KPALV request o The (possibly updated) KPALV request is forwarded to the next hop 2.4.4. On reception of a UP_RESV request The behavior is similar to the case of reception of a RESV request, with the difference that the stream must already have an entry in the stream table 2.4.5. On reception of a RL_RESV request When the router receives a RL_RESV o It checks its validity (see Section 2.4.6). If the check is positive, continue, otherwise discard the packet (GIUSTO?) o It deletes the entry associated to the stream from the stream table and releases the associated resources. 2.4.6. Checking packet validity For safety reasons, a router must check if the received REBOOK packet is a valid one. The check can be done by exploiting some redundancies in the REBOOK structure o When a router receives for the first time a RESV request, it opens a new entry in the stream table and initialize it with the data stored in the request, including the FlowID, that is, the (source address, target address) pair, where each address is, of course, a (host address, port) pair. When a data packet or a REBOOK request is received, the router can check that the FlowID of the received request matches the FlowID stored in the stream table. o If the router use only B <32 bits of the 32 bits of the reference, it can use the remaining 32-B bits for the validity check. A possible approach is to fill the unused 32-B bits with parity bits and encrypting the result. The check for reference validity is immediate and it is very difficult to forge a valid reference. Note that since the reference value is an opaque 32-bit string for the other nodes, this type of checks can be implemented privately by the router without problems of interoperability. o Another low-cost validity check supposes that the free entries in the stream table are organized in a linked list. In this case the router initializes the empty stream table by joining its entries Montessoro & Bernardini Expires December 24, 2012 [Page 13] Internet-Draft REBOOK June 2012 in random order, making unpredictable the order the entries will be used by the router. Moreover, in order to avoid a fast reuse of the same entry, released entries can be inserted at the end of the free list, while allocated entries can be extracted from the head. In order to check the validity of the REBOOK packet, the router can verify that the referenced entry is really used. 3. Using the IP Router Alert field A possible solution to embed REBOOK information inside data packet is to exploit the IP Router Alert field. This will require the allocation of a suitable code-point in the IANA maintained registry. A REBOOK value in the IP Router Alert field will signal to the router that the 32-bit reference value has been stored between the next level protocol header and the data payload. 4. Session Timeout As already explained, because of the soft state nature of REBOOK, sessions that are not refreshed by keep-alive messages are considered expired and their resources released. An important issue is the choice of the timeout interval: if it is too short, the source will send many keep-alive packets, increasing the overhead; if it is too long, the resources associated with a crashed session (i.e., a session where the source crashed) can remain unavailable for a long time (until the session expires), reducing the efficiency of the router. Note that it is important that the source knows the session timeout, in order to choose the keep-alive frequency. Some possible solutions about the choice of the session timeout are the following Fixed The timeout value could be fixed by the protocol. This is maybe the simplest solution and it has the advantage of a low overhead, but maybe is too rigid. RTT based The timeout could be fixed to a multiple of the round trip time (RTT) between the source and the target. The source would send keep-alive packet with a frequency that depends on the RTT and the expiration time should be long enough to keep in account the probability that a keep-alive packet gets lost. This overhead of this solution is low. It is important that the difference between the RTT estimated by the router and the RTT estimated by the source is small. Montessoro & Bernardini Expires December 24, 2012 [Page 14] Internet-Draft REBOOK June 2012 Timeout as a resource With this approach the timeout is considered a resource that can be negotiated by using the REBOOK mechanism (see Section 5). Therefore, the source will send its timeout request in the RESV packet and the routers will change the timeout value in the RESV request according to their needs. Moreover, timeout can be changed dynamically during the session by the usual REBOOK procedure. The drawback of this approach is that it introduces overhead in the RESV and KPALV packets. Note that with this approach, the session timeout is the smallest among the timeouts chosen by the routers. 5. What is a resource? In this document we talked generically about "resources" to be reserved, without describing in details what a resource is. Typically one can expect bandwidth to be a negotiable resource, but other types of resources are possible. For example, the source could want to improve the latency by assigning to the stream a higher priority, so that the router will store the packets in a high- priority queue. Another example of possible resource is the session timeout (see Section 4). Depending on the application using REBOOK, it could prove useful to keep the set of resources extensible, maybe by using a Type-Length-Value format, so that routers that do not recognize some resources can skip them. 6. Security consideration To be written 7. IANA considerations To be written 8. References 8.1. References [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. Montessoro & Bernardini Expires December 24, 2012 [Page 15] Internet-Draft REBOOK June 2012 8.2. Informative References [rebook] Montessoro, P. and D. Daniele, "REBOOK: A Deterministic, Robust and Scalable Resource Booking Algorithm", J Netw Syst Manage DOI 10.1007/s10922-010-9167-8, may 2010. Authors' Addresses Pierluca Montessoro University of Udine Via delle Scienze 208 Udine 33100 Italy Phone: +39-0432-55-8286 EMail: montessoro@uniud.it Riccardo Bernardini University of Udine Via delle Scienze 208 Udine 33100 Italy Phone: +39-0432-55-8271 EMail: riccardo.bernardini@uniud.it Montessoro & Bernardini Expires December 24, 2012 [Page 16]