Internet Draft RMD On DemAnd PHR February 2002 Internet Engineering Task Force L. Westberg INTERNET-DRAFT M. Jacobsson Expires August 2002 G. Karagiannis M. de Kogel S. Oosthoek D. Partain V. Rexhepi P. Wallentin Ericsson February 2002 Resource Management in Diffserv On DemAnd (RODA) PHR draft-westberg-rmd-od-phr-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Westberg, et al. Expires August 2002 [Page 1] Internet Draft RMD On DemAnd PHR February 2002 Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The purpose of this draft is to present the Resource Management in Diffserv (RMD) On DemAnd (RODA) Per Hop Reservation (PHR) protocol. The RODA PHR protocol is used on a per-hop basis in a Differentiated Services (Diffserv) domain and extends the Diffserv Per Hop Behavior (PHB) with resource provisioning and control. 1. Introduction The current definition of Diffserv [RFC2475] does not contain a simple and scalable solution to the problem of resource provisioning and control. The Resource Management in Diffserv (RMD) On DemAnd (RODA) Per Hop Reservation (PHR) protocol presented in this document operates in an edge-to-edge Diffserv domain extending the Per Hop Behavior (PHB) functionality with resource provisioning and control. The RODA PHR is a unicast edge-to-edge protocol that is applied in a Diffserv domain and aims at extreme simplicity and low cost of implementation along with good scaling properties. The RODA PHR protocol operates on a hop-by-hop basis on all nodes, both edge and interior, located in an edge-to-edge Diffserv domain. This PHR protocol can be applied in Diffserv domains that use either IPv4 [RFC791] or IPv6 [RFC2460]. The Resource Management in Diffserv (RMD) Framework document [RMD- frame] specifies how a PHR can interoperate with a Per Domain Reservation (PDR) protocol. A PDR scheme represents the resource reservation in the Diffserv domain, and it is implemented only at the boundary of the domain (in the edge nodes). 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Furthermore, all new terms used in this draft are defined in [RMD- frame]. Westberg, et al. Expires August 2002 [Page 2] Internet Draft RMD On DemAnd PHR February 2002 3. RODA PHR functionality The RODA PHR protocol performs the following functions: * The RODA PHR installs and maintains one reservation state per PHB, i.e., per DSCP, in all the nodes located in the communication path from the ingress node up to the egress node. This state represents the number of currently reserved resource units that are signalled by the PHR protocol for the admitted incoming flows. Thus, the ingress node generates a PHR signalling message for each incoming flow, which signals only the resource units requested by this particular flow. These resource units, if reserved, are added to the currently reserved resources per PHB and therefore they will become a part of the per-PHB reservation state. The per-PHB reservation states can be created and maintained by combination of the reservation soft state and explicit release principles. When the reservation soft state principle is used, a finite lifetime is set for the length of the reservation. These reservations are then maintained by sending periodic PHR refresh messages. The length of the refresh period MUST be the same throughout the Diffserv domain and SHOULD be configurable. If this reservation state does not receive a PHR refresh message within a refresh period, reserved resources associated with this PHR message will be released automatically. The reserved resources for a particular flow can also be explicitly released from a PHB reservation state by means of PHR release message. Use of explicit release enables the instantaneous release of the resources regardless of the length of the refresh period. This allows a longer refresh period, which will also reduce the number of periodic refresh messages. Furthermore, each node has to maintain a threshold per PHB that specifies the maximum number of reservable resource units. This threshold could, for example, be statically configured. * Detection and notification of severe congestion. Severe congestion can be considered as an undesirable state which may occur as a result of a route change or a link failure. Typically, routing algorithms are able to adapt and change their routing decisions to reflect changes in the topology and traffic volume. In such situations the re-routed traffic will have to follow a new path. Nodes Westberg, et al. Expires August 2002 [Page 3] Internet Draft RMD On DemAnd PHR February 2002 located on this new path may become overloaded, since they suddenly might need to support more traffic than their capacity. All nodes MUST be able to identify a severe congestion situation. The RODA PHR protocol provides the means of informing other nodes of the congestion situation on a hop-by-hop basis. * Stores a pre-configured threshold value on maximal allowable resource units per PHB. * Adaptation to load sharing. Load sharing allows interior nodes to take advantage of multiple routes to the same destination by sending via some or all of these available routes. The PHR protocol has to adapt to load sharing once it is used. * Transport of transparent PDR messages. The PHR protocol may encapsulate and transport PDR messages sent from an ingress node to an egress node. 4. RODA PHR protocol operation There are two main RODA PHR protocol operations: * normal operation, which refers to the situation when no performance degradation problems are occurring in the network. * fault handling, which refers to the situations when there are performance degradation problems in the network, such as route or link failures. These situations may result in severe congestion occurrence or loss of PHR messages. 4.1. RODA PHR Protocol Messages In RODA, three PHR protocol messages are specified: the "PHR_Resource_Request", the "PHR_Refresh_Update" and the "PHR_Resource_Release". All pass through the same nodes as the actual traffic will pass through. Westberg, et al. Expires August 2002 [Page 4] Internet Draft RMD On DemAnd PHR February 2002 4.1.1. PHR_Resource_Request The "PHR_Resource_Request" is used to initiate or update the PHB reservation state on all nodes located on the communication path between the ingress and egress nodes according to an external QoS Request. This state represents the number of currently reserved resource units that are signalled by the "PHR_Resource_Request" for the admitted incoming flows. Thus, the ingress node generates for each new incoming flow a "PHR_Resource_Request" message, which signals only the resource units requested by this particular flow. These resource units, if reserved, are added to the currently reserved resources per PHB and therefore they will become a part of the per PHB reservation state. Furthermore, the "PHR_Resource_Request" message does not refresh any existing soft state reservation. 4.1.2. PHR_Refresh_Update The "PHR_Refresh_Update" is used to refresh the PHB reservation soft state on all nodes located on the communication path between the ingress and egress nodes according to a resource reservation request that was successfully processed by the PHR functionality during a previous refresh period. Note that when the reservation soft state principle is used, a finite lifetime is set for the length of the reservation. These reservations are then maintained by sending periodic "PHR_Refresh_Update" messages. The length of the refresh period MUST be the same throughout the Diffserv domain and SHOULD be configurable. If this reservation state does not receive a "PHR_Refresh_Update" message within a refresh period, reserved resources associated with this PHR message will be automatically released. 4.1.3. PHR_Release_Request The "PHR_Release_Request" is used to explicitly release reserved resources for a particular flow from a PHB reservation state. Any node that receives a "PHR_Resource_Release" signalling message must identify the DSCP and release the requested resources associated with it. This can be achieved by subtracting the amount of PHR requested resources, included in the "Requested Resources" field, from the total reserved amount of resources stored in the PHB reservation state. The usage of "PHR_Release_Request" enables the instantaneous release of the resources independently of the length of the refresh Westberg, et al. Expires August 2002 [Page 5] Internet Draft RMD On DemAnd PHR February 2002 period. This allows a longer refresh period, which will also reduce the number of periodic "PHR_Refresh_Update" messages. 4.2. RODA PHR Normal operation All nodes SHOULD process the "PHR_Refresh_Update" message with a higher priority than the "PHR_Resource_Request" message. The detailed RODA PHR message format is described in Section 5 below. Any node that receives a RODA PHR message (a "PHR_Resource_Request" or a "PHR_Refresh_Update" message) MUST identify the DSCP of these signalling messages and, if possible, reserve the requested units of resources contained in the "Requested Resources" field of these signalling messages. If this can be accomplished then the node reserves the requested resources by adding the requested on-demand units of resources to the total amount of reserved units associated with that DSCP. Otherwise, these messages are marked, which means setting the "M" bit to "1". Moreover, in this case the node SHOULD include the number of previous interior nodes that successfully reserved the resources which were signalled by this "PHR_Resource_Request" into this "PHR_Resource_Request". This number is identified by the TTL (Time- To-Live) value included in the IP header of the received "PHR_Resource_Request" message. Note that each time that an IP packet passes a node, its TTL value is decreased by one. Moreover, if the TTL value of the packets becomes zero, then the packet is released. Thus, if the ingress node is able to initialize the TTL value included in the IP header of any "PHR_Resource_Request" message sent towards the egress node then any interior node will be able to find out how many nodes before it, processed this PHR message. The node will copy the TTL value included in the IP header of the received "PHR_Resource_Request" message into the "PDR encapsulated data" field. Moreover, the node MUST set the "T" field value to "1". This PHR message will be sent towards the egress node. Any "M" marked (the "M" bit is 1) "PHR_Resource_Request" messages that arrives in an interior node are not processed and are forwarded untouched. Any "PHR_Refresh_Update" message, whether it is marked or not, is always processed, but marked bits are not changed. When a node receives a "PHR_Release_Request" message it MUST identify Westberg, et al. Expires August 2002 [Page 6] Internet Draft RMD On DemAnd PHR February 2002 the DSCP and estimate the refresh period where it last signalled the resource usage (where it last processed a "PHR_Refresh_Update"). This MAY be done by, for example (see [MaPo01]), giving the opportunity to an ingress node to calculate the time lag, say T_lag, between the last sent "PHR_Refresh_Update" message and the "PHR_Release_Request" message. The value of this time lag (T_lag), is first normalized to the length of the refresh period, say T_period. In other words the ratio between this time lag, T_lag, and the length of the refresh period, T_period, is calculated. This ratio is then introduced into the "Delta T" field of the "PHR_Release_Request". When a node receives this "PHR_Release_Request" message it will have to store its arrival time. Then it will calculate the time difference, say Tdiff, between this arrival time and the start of the current refresh period, T_period. Furthermore, this node will have to derive the value of the time lag, T_lag, from the "Delta T" field. This can be found by multiplying the value included in the "Delta T" field with the length of the refresh period, T_period. If the derived time lag, T_lag, is smaller than the calculated time difference, T_diff,, then this node MUST decrease the PHB reservation state with the number of resource units indicated in the "Requested Resources" field of the "PHR_Release_Request" message, but not below zero. 4.3. Fault handling operation When a node detects this situation it MUST inform the egress node by setting the "S" field of any received PHR message to "1" and sending this message towards the egress node. In the situation that this cannot be done, operational management solutions, such as Simple Network Management Protocol (SNMP) notifications SHOULD be used. Moreover, when an interior node detects this situation, it SHOULD notify the egress node by using DSCP remarking of user data packets that are passing through the node. Proportionally to the detected overload, the interior node will remark a number of user data packets which are passing through a severe congested interior node and are associated to a certain PHB, into a domain specific DSCP (see [RFC2474]). [RMD-frame] describes a severe congestion handling procedure which uses the DSCP remarked packets and solves the severe congestion situation. Any "S" marked (the "S" bit is 1) "PHR_Resource_Request" messages that arrives in an interior node are not processed and are forwarded Westberg, et al. Expires August 2002 [Page 7] Internet Draft RMD On DemAnd PHR February 2002 untouched. Any "PHR_Refresh_Update" message, whether it is marked or not, is always processed, but marked bits are not changed. 5. PHR message formats The PHR protocol information is carried in: * an IP header Options field, as defined in the [RFC791], when IPv4 is used * an option field encoded into the Hop-by-Hop Options Extended Header, as defined in [RFC2460], when IPv6 is used We denote this IP Option field as the RODA PHR option. Westberg, et al. Expires August 2002 [Page 8] Internet Draft RMD On DemAnd PHR February 2002 5.1. Message Format in IPv4 The RODA PHR protocol messages used in IPv4 Diffserv domains are represented by the combination of the DSCP field and the contents of an IPv4 option header field [RFC791]. This IPv4 option header field has the following format. Note that the contents of the PDR (per- domain reservation) encapsulated data are simply opaque data to the PHR and are not processed by the PHR. Please see [RMD-frame] for a description of PDR functionality. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length |P-LEN| P-ID |S|M| C |T| U | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Resources | Delta T | Shared % | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . PDR encapsulated data . . Variable length field used to . . encapsulate PDR messages . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PHR Option field in the IPv4 Option header field Option Type 8-bit identifier of the type of option. The semantics of this field are specified in [RFC791]. Option Length 8-bit field. This is specified in [RFC791] and represents the length of the Option-Data field of this option, in octets. The option data field consists of all fields included in the option field of the IPv4 header and are placed after the "Option Length" field. P-LEN 3-bit field. This specifies the length in (PHR length) octets of the specific PHR information data included in the "Option-Data" field. This information does not include the encapsulated PDR information. The value 0 specifies that this IP option field contains only PDR data and no PHR data. The PDR data MUST begin on the next 32-bit word boundary after the P-LEN field (after the first "unused" field). In this case, the sender MUST set the "S", "M", "C", and "unused" fields to 0. The P-ID MUST have the value 1. Westberg, et al. Expires August 2002 [Page 9] Internet Draft RMD On DemAnd PHR February 2002 If a receiver receives a packet with a P-LEN value of 0, it MUST ignore the values in the "S", "M", "C", and "unused" fields. P-ID (PHR type) 4-bit field. This specifies the PHR type. For the RODA PHR, the value MUST be 1. S 1-bit field. The sender MUST set the "S" (Severe field to 0. This field is set to 1 Congestion) by an interior or edge node when a severe congestion situation occurs. M 1-bit field. The sender MUST set the "M" (Marked) field to 0. This field is set to 1 by an interior or edge node when the node cannot satisfy the "Requested Resources" value. C 3-bit field. This field specifies the (Message type) type of the PHR message. C Description ------------------------------- 0 Reserved 1 "PHR_Resource_Request" 2 "PHR_Refresh_Update" 3 "PHR_Release_Request" 4-7 Unused T 1-bit field. The ingress node (i.e., sender) MUST set (TTL active) the "T" field to 0. This field MAY be set to "1" by a node when the node will have to include the TTL value from the header of the IP packet into the "PDR encapsulated data" field. U A 3-bit field that is currently unused. Reserved for future PHR extensions. Requested 16-bit field. This field specifies the requested Resources number of units of resources to be reserved by a node. The unit is not necessarily a simple bandwidth value. It may be defined in terms of any resource unit (e.g., effective bandwidth) to support statistical multiplexing at message level. Westberg, et al. Expires August 2002 [Page 10] Internet Draft RMD On DemAnd PHR February 2002 Delta T 8 bit field. The value of this field MAY be set by any ingress node into (only) "PHR_Resource_Release" messages. It specifies a percentage that represents the ratio between a time lag, say T_lag, and the length of the refresh period, say T_period. Where, T_lag represents the difference between the departure time of the previous sent "PHR_Refresh_Update" message and the departure time of the "PHR_Resource_Release" message. T_period represents the length of the refresh period. This information MAY be used by any node during an explicit release procedure. Shared % 8 bit field. This value MAY be used to specify if a (Shared load sharing situation occurred on a communication path percentage) or not. The ingress node sets this value to 100. If load sharing occurred in a node then the node will divide the shared percentage value to the number of equal cost paths. PDR PDR encapsulated information data. encapsulated This field is only processed by the data edge nodes. 5.2. Message Format in IPv6 The PHR protocol messages used in IPv6 Diffserv domains are represented by the combination of the DSCP field and the contents of an option field of a IPv6 Hop-by-Hop header option [RFC2460]. This IPv6 option field has the following format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P-LEN|P-ID |S|M| C |T| U | Requested Resources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | Delta T | Shared % | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . PDR encapsulated data . . Variable length field used to . . encapsulate PDR messages . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: PHR Option field in the IPv6 Hop-by-Hop Header Option Westberg, et al. Expires August 2002 [Page 11] Internet Draft RMD On DemAnd PHR February 2002 Next Header 8-bit selector. This is specified in [RFC2460] and identifies the type of header immediately following the Hop-by-Hop Options header. Hdr Ext Len 8-bit field. This is specified in [RFC2460] and represents the length of the Hop-by-Hop Options header in 8-octet units, not including the first 8 octets. Option Type 8-bit identifier of the type of option. The semantics of this field are specified in [RFC2460]. Opt Data Len 8-bit field. This is specified in [RFC2460] and represents the length in octets of the Option Data field of this option. The option data field consists of all fields included in the Hop-by-Hop header option and placed after the "Opt Data Len" field. P-LEN 3-bit field. The semantics of this field (PHR length) are identical to the field in the IPv4 option. Just as for IPv4, the value 0 specifies that this IP option field contains only PDR data and no PHR data. The PDR data MUST begin on the next 32-bit word boundary after the P-LEN field (after the first "Requested Resources" field). In this case, the sender MUST set the "S", "M", "C", "unused", and "Requested Resources" fields to 0. The P-ID MUST have the value 1. If a receiver receives a packet with a P-LEN value of 0, it MUST ignore the values in the "S", "M", "C", and "unused" fields. U A 3-bit field that is currently unused. Reserved for future PHR extensions. UNUSED A 16-bit field that is currently unused. Reserved for future PHR extensions. PDR a variable length field that contain PDR encapsulated encapsulated information data. This field data is only processed by the edge nodes. The "Requested Resources", "P-LEN", "P-ID", "S", "M" and "C", "T", Westberg, et al. Expires August 2002 [Page 12] Internet Draft RMD On DemAnd PHR February 2002 "Delta T" and "Shared %" fields in Figure 2 are identical to those shown in Figure 1. 6. Adaptation for load sharing Due to load sharing (see e.g., [RFC2676]), a node may cycle between different routes in order to balance the load. This will imply that the traffic (user) data will not follow exactly the same paths as the PHR messages used to reserve or refresh the transport resources used by this traffic (user) data. As such, interior nodes MUST be able to observe when a load sharing situation occurs. It is recommended that interior and edge nodes SHOULD forward the PHR messages in such a way that they will follow the same forwarding path as the traffic (user) data associated with these PHR messages. When this cannot be done, we propose use of the same solutions as the multi-path route solutions proposed in Section 1.4.6 of [RFC3175]. These are: * the data may be tunneled from the ingress to egress node using technologies such as IP-in-IP, GRE (Generic Routing Encapsulation), MPLS (Multiple Label Protocol Switching) label-switched paths, and so on. * measurement could be used to determine what proportion of traffic for a given reservation travels along each of the load sharing paths, thereby verifying that there is sufficient bandwidth for the reservation. * by reserving the total capacity of the route down each load sharing path. In case a network domain is using a routing protocol which is applying an equal cost load sharing principle, any interior node SHOULD be able to know the number, e.g., "N", of multiple equal cost paths that the routing protocol will use to provide the load sharing principle. Subsequently, for each arrived PHR message which is affected by the load sharing principle, the interior node SHOULD be able to create "N" number of PHR messages of identical type as the original one. Each of these generated PHR messages SHOULD contain in its "Requested Resources" field a value equal to the requested resources value which was included in the "Requested Resources" field of the original PHR message divided by the number of equal cost paths, i.e., "N". Moreover, each of these generated PHR messages Westberg, et al. Expires August 2002 [Page 13] Internet Draft RMD On DemAnd PHR February 2002 SHOULD also contain in its "Shared %" field a new value that is calculated by dividing the shared percentage value, included in the "Shared %" field of the original PHR message, by the number of equal cost paths, i.e., "N". 7. Tunneling When PHR messages are tunneled within the RMD Diffserv domain, the tunneling messages MUST include the PHR option field. 8. Security considerations The general security and tunneling considerations stated in Section 6 of [RFC2475] and [RMD-frame] also apply to this PHR. In addition, unlike Differentiated Services PHBs, the RODA PHR allows the edge nodes to reserve bandwidth or other QoS parameters dynamically. This flexibility makes it more vulnerable to erroneous reservations and sabotage. In order to keep functioning properly, the edge nodes MUST be certain that any flow reserving bandwidth in the network is authorized to do this and only up to that flow's agreed upon limit. If the edge node detects erroneous or malicious behavior, it MUST police that flow to the agreed upon limits or reject it entirely. Because of the soft state principle used, the PHR can recover relatively easily from incorrect reservations. Thus it is quite safe to deploy the RODA PHR in a well-controlled network with trustworthy edge nodes. In order to prevent abuse of the QoS capabilities of the core network, the ingress nodes SHOULD filter any PHR or PDR related header information coming from the outside before sending it through the core network. Whether this information needs to be preserved and later re-inserted or if it should be discarded from the packet or if the entire packet should be discarded is an open issue. 9. References [MaPo01] Marquetant, A., Pop, O., Szabo, R., Dinnyes, G., Turanyi, Z., "Novel enhancements to load control Westberg, et al. Expires August 2002 [Page 14] Internet Draft RMD On DemAnd PHR February 2002 a soft state, lightweight admission control protocol", QofIS'2000 - 2nd International Workshop on Quality of future Internet Services, September 2001. [RMD-frame] Karagiannis, G., Rexhepi, V., Westberg, L., Partain, D., Oosthoek, S., Jacobsson, M., Szabo, R., Wallentin, P., "Resource Management in Diffserv Framework", Internet draft, February 2002 (work in progress). [RFC791] DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION, "Internet Protocol", IETF RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", IETF RFC 2205, 1997. [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", IETF RFC 2460, December 1998. [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W., "An Architecture for Differentiated Services", IETF RFC 2475, December 1998. [RFC2676] Apostolopoulos, G., Willians, D., Kamat, S., Guerin, R., Orda, A., Przygienda, T., "QoS Routing Mechanisms and OSPF Extensions", IETF Experimental RFC 2676, August 1999. [RFC2859] Fang, W., Seddigh, N., Nandy, B., "A Time Sliding Window Three Colour Marker (TSWTCM)", IETF Experimental RFC 2859, June 2000. [RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., Westberg, et al. Expires August 2002 [Page 15] Internet Draft RMD On DemAnd PHR February 2002 "Aggregation of RSVP for IPv4 and IPv6 Reservations", IETF RFC 3175, 2001. 10. Acknowledgments Thanks to Robert Szabo and Geert Heijenk for reviewing this draft and providing useful input. 11. Authors' Addresses Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden EMail: Lars.Westberg@era.ericsson.se Martin Jacobsson Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Martin.Jacobsson@eln.ericsson.se Georgios Karagiannis Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Georgios.Karagiannis@eln.ericsson.se Simon Oosthoek Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Simon.Oosthoek@eln.ericsson.se David Partain Westberg, et al. Expires August 2002 [Page 16] Internet Draft RMD On DemAnd PHR February 2002 Ericsson Radio Systems AB P.O. Box 1248 SE-581 12 Linkoping Sweden EMail: David.Partain@ericsson.com Vlora Rexhepi Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Vlora.Rexhepi@eln.ericsson.se Pontus Wallentin Ericsson Radio Systems AB P.O. Box 1248 SE-581 12 Linkoping Sweden EMail: Pontus.Wallentin@era.ericsson.se Marcel de Kogel Ericsson EuroLab Netherlands B.V. 5121 ML Rijen The Netherlands EMail: Marcel.de.Kogel@eln.ericsson.se Table of Contents 1 Introduction .................................................... 2 2 Terminology ..................................................... 2 3 RODA PHR functionality .......................................... 3 4 RODA PHR protocol operation ..................................... 4 4.1 RODA PHR Protocol Messages .................................... 4 4.1.1 PHR_Resource_Request ........................................ 5 4.1.2 PHR_Refresh_Update .......................................... 5 4.1.3 PHR_Release_Request ......................................... 5 4.2 RODA PHR Normal operation ..................................... 6 4.3 Fault handling operation ...................................... 7 5 PHR message formats ............................................. 8 Westberg, et al. Expires August 2002 [Page 17] Internet Draft RMD On DemAnd PHR February 2002 5.1 Message Format in IPv4 ........................................ 9 5.2 Message Format in IPv6 ........................................ 11 6 Adaptation for load sharing ..................................... 13 7 Tunneling ....................................................... 14 8 Security considerations ......................................... 14 9 References ...................................................... 14 10 Acknowledgments ................................................ 16 11 Authors' Addresses ............................................. 16 Westberg, et al. Expires August 2002 [Page 18]