Internet DRAFT - draft-westberg-rmd-od-phr

draft-westberg-rmd-od-phr







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]