OLSRv2 Backpressure Traffic Engineering Extension
draft-szwabe-manet-backpressure-olsrv2-02

Versions: 00 01 02                                                      
Internet Engineering Task Force                                A. Szwabe
Internet-Draft                                               P. Misiorek
Intended status: Experimental                           M. Urbanski, Ed.
Expires: November 3, 2011                Poznan University of Technology
                                                             E. Baccelli
                                                                   INRIA
                                                             May 2, 2011


           OLSRv2 Backpressure Traffic Engineering Extension
               draft-szwabe-manet-backpressure-olsrv2-02

Abstract

   This document specifies a traffic engineering extension for OLSRv2
   based on backpressure, which allows advanced traffic shaping by
   providing each MANET router with information about packet queue
   levels of its neighbors.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   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 November 3, 2011.

Copyright Notice

   Copyright (c) 2011 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



Szwabe, et al.          Expires November 3, 2011                [Page 1]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   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
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Parameters and Constants . . . . . . . . . . . . . . . . . . .  6
     5.1.  Protocol and Port Numbers  . . . . . . . . . . . . . . . .  6
     5.2.  Multicast Address  . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Message Intervals  . . . . . . . . . . . . . . . . . . . .  7
     5.4.  Message Validity Times . . . . . . . . . . . . . . . . . .  7
     5.5.  Jitter . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Information Bases  . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Local Information Base . . . . . . . . . . . . . . . . . .  8
     6.2.  Interface Information Base . . . . . . . . . . . . . . . .  8
     6.3.  Topology Information Base  . . . . . . . . . . . . . . . .  8
     6.4.  Received Message Information Base  . . . . . . . . . . . .  9
     6.5.  Flow Identification  . . . . . . . . . . . . . . . . . . .  9
     6.6.  Queue Information Base . . . . . . . . . . . . . . . . . . 10
       6.6.1.  Queue Levels Set . . . . . . . . . . . . . . . . . . . 10
       6.6.2.  Urgency Set  . . . . . . . . . . . . . . . . . . . . . 10
       6.6.3.  Updating the Data  . . . . . . . . . . . . . . . . . . 11
   7.  Signaling  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  QR Message . . . . . . . . . . . . . . . . . . . . . . . . 11
       7.1.1.  QR Message Generation  . . . . . . . . . . . . . . . . 11
       7.1.2.  QR Message TLVs  . . . . . . . . . . . . . . . . . . . 12
       7.1.3.  QR Message Transmission  . . . . . . . . . . . . . . . 13
       7.1.4.  QR Message Processing  . . . . . . . . . . . . . . . . 13
     7.2.  UR Message . . . . . . . . . . . . . . . . . . . . . . . . 14
       7.2.1.  UR Message Generation  . . . . . . . . . . . . . . . . 14
       7.2.2.  UR Message TLVs  . . . . . . . . . . . . . . . . . . . 16
       7.2.3.  UR Message Transmission  . . . . . . . . . . . . . . . 16
       7.2.4.  UR Message Processing  . . . . . . . . . . . . . . . . 17
   8.  Data Available for Schedulers  . . . . . . . . . . . . . . . . 17
   9.  Interoperability with other OLSRv2 Routers . . . . . . . . . . 19
   10. Values for Parameters and Constants  . . . . . . . . . . . . . 19
     10.1. Message Interval Parameters  . . . . . . . . . . . . . . . 19
     10.2. Message Validity Times Parameters  . . . . . . . . . . . . 19
     10.3. Hop Limit Parameter  . . . . . . . . . . . . . . . . . . . 20
     10.4. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 20
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20



Szwabe, et al.          Expires November 3, 2011                [Page 2]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


     12.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 20
     12.2. Message Types  . . . . . . . . . . . . . . . . . . . . . . 20
     12.3. Message-Type-specific TLV Type Registries  . . . . . . . . 21
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     14.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Appendix A.  Illustrations . . . . . . . . . . . . . . . . . . . . 23
     A.1.  QR Message Examples  . . . . . . . . . . . . . . . . . . . 23
     A.2.  UR Message Example . . . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27








































Szwabe, et al.          Expires November 3, 2011                [Page 3]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


1.  Introduction

   This document specifies a traffic engineering extension for OLSRv2
   [I-D.ietf-manet-olsrv2] based on backpressure, which can increase and
   balance end-to-end throughput by providing each MANET router with
   information about packet queue levels of its neighbors.  This
   document defines signaling and processing that is necessary, in
   addition to the signaling and processing defined in
   [I-D.ietf-manet-olsrv2], [RFC6130] and [RFC5444], to provide
   efficient traffic engineering in OLSRv2 with a backpressure-based
   scheme [SMN+10].


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].

   All terms introduced in [RFC5444], including "packet", "Packet
   Header", "message", "Message Header", "Message Body", "Message Type",
   "message sequence number", "hop limit", "hop count", "Address Block",
   "TLV Block", "TLV", "Message TLV", "Address Block TLV", "type" (of
   TLV), "type extension" (of TLV), "value" (of TLV), "address" and
   "address object" are to be interpreted as described there.

   All terms introduced in [RFC6130], including "interface", "MANET
   interface", "network address", "link", "symmetric link", "1-hop
   neighbor", "symmetric 1-hop neighbor", "symmetric 2-hop neighbor",
   "constant", "interface parameter", "router parameter", "Information
   Base", and "HELLO message" are to be interpreted as described there.

   All terms introduced in [I-D.ietf-manet-olsrv2] and
   [I-D.dearlove-olsrv2-metrics], including the terms "Router", "OLSRv2
   interface", "Originator address", "Message originator address",
   "Routing Set", "Routing Tuple" are to be interpreted as described
   therein.

   Additionally, this document uses the following terminology:

   Flow
             A particular packet sequence transmitted through the
             network.

   Flow Identifier
             A set of values which enable unambiguous identification of
             the Flow.




Szwabe, et al.          Expires November 3, 2011                [Page 4]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   Timeslot
             A definite continuously repeating time period when events
             may occur.  For example: "In a given Timeslot, 15 packets
             have been processed."

   Scheduler
             In this document, a scheduler is considered as a part of
             the system maintaining the traffic on the router.  A
             scheduler decides which Flow should be forwarded at a given
             time.

   Queue Level
             The number of units (e.g., packets or bytes) in a Flow
             Queue on a router.

   Backpressure
             The backpressure routing/scheduling policy is based on
             giving priority in forwarding to links and Flows that have
             higher backpressure, defined as the backlog differential
             (i.e., the difference between Queue Levels) at consecutive
             Routers.

   Basic OLSRv2 Router
             A OLSRv2 Router without Backpressure Extension.

   Backpressure Router
             A OLSRv2 Router featuring the Backpressure Extension.

   Backpressure Interface
             A OLSRv2 interface running the Backpressure Extension.

   Urgency
             Urgency is a queue-level-based scheduling weight used by a
             Backpressure Scheduler.  Unless otherwise specified,
             urgency is defined as a backlog differential (i.e., the
             difference between Queue Levels) at consecutive Routers.

   Router Urgency
             The maximum Urgency over all active Flows and all active
             connections on the router.

   Backpressure Scheduler
             Specific type of scheduler which provides integrated packet
             scheduling and forwarding according to the backpressure
             policy based on the information on scheduling weights
             (Urgencies).





Szwabe, et al.          Expires November 3, 2011                [Page 5]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   per-flow
             This term refers to resources which may be regarded as
             allocated to a Flow.


3.  Applicability

   The OLSRv2 extension specified in this document should be used
   together with an OLSRv2 multipath extension such as
   [I-D.multipath-olsrv2], in order to fully benefit from potential load
   balancing and throughput optimization.  However, the extension
   specified in this document can be used without any other OLSRv2
   extension, to increase end-to-end throughput.

   Routers which do not support the OLSRv2 extension specified in this
   document are interoperable with routers that do support the extension
   according to the present specification.


4.  Protocol Overview

   The OLSRv2 extension defined in the following sections provides
   traffic engineering capabilities to MANET routers, based on a
   backpressure scheme which can increase end-to-end throughput.  This
   document specifies data flow identification, as well as periodical
   signaling of Queue Report (QR) and Urgency Report (UR) messages using
   the format specified in [RFC5444], which enables a router to monitor
   the queue levels of its neighbors.

   QR and UR messages provide each node with the information enabling
   the backpressure max-weight scheduling.  Information carried by QR
   messages is necessary for each router to calculate its backpressure-
   based scheduling weights (i.e., its urgencies), whereas UR messages
   are used to inform each router on urgencies within its neighborhood.
   By using QR and UR messages routers may perform backpressure max-
   weight scheduling, which is theoretically proven as a distributed
   load-balancing solution maximizing overall network throughput, e.g.,
   enabling to avoid forwarding packets through a network bottleneck
   [SMN+10].


5.  Parameters and Constants

5.1.  Protocol and Port Numbers

   The backpressure extension of OLSRv2 specifies QR and UR messages,
   which are included in packets as defined in [RFC5444].  These packets
   may be sent either by using the "manet" protocol number or the



Szwabe, et al.          Expires November 3, 2011                [Page 6]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   "manet" UDP well-known port number, as specified in [RFC5498].

   QR, UR and TC [I-D.ietf-manet-olsrv2], HELLO [RFC6130] messages
   SHOULD be using the same transport protocol (either of IP or UDP) in
   order to make it possible to combine messages of all these protocols
   into a single [RFC5444] packet.

5.2.  Multicast Address

   The Backpressure Extension of OLSRv2 specifies QR and UR messages,
   which are included in packets as defined by [RFC5444].  These packets
   MAY be transmitted using the link local multicast address "LL-MANET-
   Routers", as specified in [RFC5498].

5.3.  Message Intervals

   This specification defines the following message intervals:

   QR_INTERVAL  - the maximum time between transmission of two
      consecutive QR messages

   UR_INTERVAL  - the maximum time between transmission of two
      consecutive UR messages

   Intervals defined in this document MUST comply to the following
   constraints:

   o  UR_INTERVAL > 0

   o  UR_INTERVAL < QR_INTERVAL

5.4.  Message Validity Times

   This specification defines the following Advertised Information
   Validity Times:

   UR_HOLD_TIME  - a validity time of UR message and a validity time of
      information carried by this message.

   QR_HOLD_TIME  - a validity time of QR message and a validity time of
      information carried by this message.

   BP_HOLD_TIME  - the maximum time without receiving a QR message or a
      UR message from a neighbor Router.

   Validity times defined in this document MUST apply to the following
   constrains:




Szwabe, et al.          Expires November 3, 2011                [Page 7]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   o  UR_HOLD_TIME > UR_INTERVAL

   o  QR_HOLD_TIME > QR_INTERVAL

   o  BP_HOLD_TIME > UR_INTERVAL or BP_HOLD_TIME > QR_INTERVAL

   o  In the case of high loss ratio of QR and UR messages, BP_HOLD_TIME
      should be made significantly greater than UR_INTERVAL or
      QR_INTERVAL interval.

5.5.  Jitter

   If jitter, as defined in [RFC5148], is used, the following jitter
   parameters are required to be defined:

   QR_MAXJITTER  - value of MAXJITTER used in [RFC5148] for periodically
      generated QR messages sent by this Router.

   UR_MAXJITTER  - value of MAXJITTER used in [RFC5148] for periodically
      generated UR messages sent by this Router.


6.  Information Bases

   The Information Bases defined here extend these specified in
   [RFC6130] and [I-D.ietf-manet-olsrv2] with both: information and its
   uses.  This organization of information serve purpose of describing
   the Backpressure Extension, and DOES NOT constrain in any way
   implementation of this extension.

6.1.  Local Information Base

   The Local Information Base is specified in [I-D.ietf-manet-olsrv2].
   Additionally information stored there is used for the Backpressure
   Extension signaling.

6.2.  Interface Information Base

   The Interface Information Base is specified in
   [I-D.ietf-manet-olsrv2].  Additionally information stored there is
   used for the Backpressure Extension signaling.

6.3.  Topology Information Base

   The Topology Information Base is specified in
   [I-D.ietf-manet-olsrv2].  Additionally information stored there is
   used for choosing on which interfaces QR and UR messages should be
   announced.



Szwabe, et al.          Expires November 3, 2011                [Page 8]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


6.4.  Received Message Information Base

   The Received Message Information Base defined by
   [I-D.ietf-manet-olsrv2] is extended by this specification by
   introducing also an information about QR and UR messages.  The
   Received Message Information Base structure is not modified by the
   Backpressure Extension.  The way the messages are processed in
   Information Base is defined in Section 7.

6.5.  Flow Identification

   In order to enable backpressure-based per-flow routing, unambiguous
   Flow identification is specified by this document.  For this purpose
   Flow Identifier MAY hold the following parameters set:

   o  Destination address

   o  Source address

   o  Internet Protocol Number of a protocol used in the transport layer

   o  If used, an additional transport protocol source and destination
      address (i.e. port addresses in TCP or UDP)

   This specification allows various combinations of these parameters to
   be used in order to identify a Flow.  Flow identification parameters
   MUST be the same across the MANET network.  Routers using different
   set of parameters to identify the Flow are treated as Basic OLSRv2
   Routers by Backpressure Routers.

   One of the following parameters subsets MUST be used:

   o  Destination address, Source address, Internet Protocol Number with
      source and port addresses (if used).

   o  Destination address, Source address.

   o  Only destination address

   Information about Flows is necessary from the perspective of the
   Scheduler which differentiate the traffic depending on its type.
   More detailed per-flow identification increases signaling overhead.
   As the countermeasure, the Urgency signaling (see Section 7.2) which
   significantly reduces amount of transmitted data is deployed.
   Overhead of Urgency signaling itself does not increase with
   complexity of Flow Identifier.

   For encoding of Flow Identifier special QR Message-specific TLVs are



Szwabe, et al.          Expires November 3, 2011                [Page 9]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   defined:

   o  PROTOCOL - Internet Protocol number used within transport layer.

   o  PORT - address used in transport layer, associated with a single
      address.

   More detailed information about formatting of Flow Identifier in QR
   Messages as specified in Section 7.1.2.

6.6.  Queue Information Base

   A Queue Information Base defined here stores information extracted
   from received QR and UR messages.  The Queue Information Base
   consists of the Queue Level Set, the Urgency Set.

6.6.1.  Queue Levels Set

   The Queue Level Set contains neighbor's Queue Levels reported by
   means of QR messages, as well as local Queue Levels of the
   Backpressure Router.  This set consists of Queue Level Tuples:

      (Q_addr, Q_fid, Q_level, Q_time)

   where:

   o  Q_addr is the originator address of the Backpressure Router
      sending the QR message;

   o  Q_fid is a Flow Identifier;

   o  Q_level is a Queue Level reported for this Flow by the
      Backpressure Router;

   o  Q_time is the Tuple expiration time, after which Tuple MUST be
      removed.

6.6.2.  Urgency Set

   The Urgency Set records Urgency values.  Urgency values are delivered
   by means of UR messages (in the case of Urgencies of neighboring
   Routers) or calculated using values from Queue Level Set (in the case
   of local Urgency, i.e., the maximum Urgency of queues stored in the
   local Router).  This set consists of Urgency Tuples:

      (U_addr, U_level, U_time)

   where:



Szwabe, et al.          Expires November 3, 2011               [Page 10]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   o  U_addr is the originator address of Backpressure Router associated
      with the Urgency value;

   o  U_level is an Urgency;

   o  U_time is a Tuple expiration time, after which Tuple MUST be
      removed.

6.6.3.  Updating the Data

   In order to maintain the Queue Information Base properly, the
   following actions MUST be taken:

   o  An entry MUST be removed after the time defined as the Tuple
      expiration time (Q_time or U_time respectively).

   o  A new entry corresponding to a pair Q_addr and Q_fid in Queue
      Level Tuple or U_addr and U_level in Urgency Tuple, which is
      already present in the Queue Information Base, MUST be
      overwritten.


7.  Signaling

   Messages defined by [RFC6130] and [I-D.ietf-manet-olsrv2] are used as
   specified there.  This extension does not involve modifications to
   these messages.

   The packet and message format used by the Backpressure Extension of
   OLSRv2 are defined in [RFC5444].  If not noted otherwise, options
   defined in [RFC5444] MAY be used.

   The QR and UR messages MUST follow specification of Message
   Processing and Forwarding defined in [I-D.ietf-manet-olsrv2].

7.1.  QR Message

7.1.1.  QR Message Generation

   QR messages are generated by a Router for each of its Backpressure
   interfaces, and MUST be sent proactively and MAY be sent in a
   combination of proactive and reactive techniques.

   proactive  - at a regular interval, known as QR_INTERVAL, which may
      be fixed or dynamic, and in case of fixed interval MAY be the same
      across the network.





Szwabe, et al.          Expires November 3, 2011               [Page 11]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   reactive  - in reaction to a change of queue states, limited to
      queues that changed.  In this case the maximum refresh time SHOULD
      be set, and minimal queue state change required to trigger QR
      message MUST be set (independently by each Router).

   A QR message MUST contain:

   o  A <msg-hop-limit> := QR_HOPLIMIT, which limits the QR messaging
      network-wide overhead.

   o  A message originator address, representing Router's originator
      address.  A <msg-orig-addr> element MUST be used for this purpose.

   A QR message MAY contain:

   o  Address blocks with associated PORT, PROTOCOL and QUEUE_LEVEL TLV
      as specified in Section 7.1.2, and as required for Flow
      Identification.

7.1.2.  QR Message TLVs

7.1.2.1.  Address Block TLVs

   In a QR message, a Router MAY include PROTOCOL Address Block TLV(s)
   as specified in Table 1.

   +----------+--------------+----------------------------------------+
   |   Type   | Value Length |                  Value                 |
   +----------+--------------+----------------------------------------+
   | PROTOCOL |    1 octet   | Associated with a whole address block. |
   +----------+--------------+----------------------------------------+

                     Table 1: PROTOCOL TLV definition

   In a QR message, a Router MAY include PORT Address Block TLV(s) as
   specified in Table 2.

   +------+----------+-------------------------------------------------+
   | Type |   Value  |                      Value                      |
   |      |  Length  |                                                 |
   +------+----------+-------------------------------------------------+
   | PORT | 2 octets |    Indicates that source or destination uses    |
   |      |          |     corresponding PORT value as port number.    |
   +------+----------+-------------------------------------------------+

                       Table 2: PORT TLV definition

   In a QR message, a Router MAY include QUEUE_LEVEL Address Block



Szwabe, et al.          Expires November 3, 2011               [Page 12]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   TLV(s) as specified in Table 3.

   +-------------+----------+------------------------------------------+
   |     Type    |   Value  |                   Value                  |
   |             |  Length  |                                          |
   +-------------+----------+------------------------------------------+
   | QUEUE_LEVEL |  up to 4 |     Queue Level expressed as unsigned    |
   |             |  octets  | integer filed (encoded with network byte |
   |             |          |                  order).                 |
   +-------------+----------+------------------------------------------+

                    Table 3: QUEUE_LEVEL TLV definition

   Relationship between PROTOCOL TLV, PORT TLV, QUEUE_LEVEL is based on
   structure of Flow Identifier, and MUST comply with following rules:

   o  One entity of Flow Identifier with associated QUEUE_LEVEL TLV MAY
      be presented as addr_block and tlv_block pair.

   o  PORT TLV MUST not be used if there is no PROTOCOL TLV associated
      with these addresses.

   o  If required by Flow Identifier, one per address PORT TLV MAY be
      used.

   o  To be considered a valid Flow Identifier all used fields (PORT
      TLV, PROTOCOL TLV, QUEUE_LEVEL TLV) MUST be assigned to two
      addresses (representing source and destination address).

7.1.3.  QR Message Transmission

   In order to exchange the Queue Level values between Routers, Router
   MUST generate QR Messages.  The messages MUST be transmitted
   according to QR_INTERVAL.  The scheduler assigned to the Router MUST
   provide sufficient information about Queue Levels of the Router.  The
   information about Queue Level of the sending Router MUST be the most
   recent available.  After each QR_INTERVAL, QR Message is generated
   and then broadcast to Router's neighbors.

   When a Router receives QR Message, an appropriate queue value is
   assigned to message originator as according to the corresponding
   entry in the Backpressure Information Base.

7.1.4.  QR Message Processing

   Each received (and not discarded) QR message, after initially being
   processed according to [RFC5444], should be analyzed by Router and
   used to update the Queue Information Base, according to the following



Szwabe, et al.          Expires November 3, 2011               [Page 13]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   rules:

   o  There must be only one, the most actual, Queue Level Tuple in
      Queue Level Set of Queue Information Base corresponding to QR
      message originator address and Flow Identifier.

   o  If there is no Queue Level Tuple in Queue Level Set corresponding
      to information in QR message, such Queue Level Tuple MUST be
      created.

   o  If QR message contains Flow Identifier that is differently defined
      than the one used by this Router (see Section 6.5), the QR message
      MUST be discarded.

7.2.  UR Message

7.2.1.  UR Message Generation

   UR messages are generated by a Router independently for each of
   Routers Backpressure interfaces.  UR messages SHOULD be sent
   proactively, at a regular interval, called UR_INTERVAL, which may be
   fixed or dynamic.

   A UR message MUST contain:

   o  A <msg-hop-limit> := UR_HOP_LIMIT.

   o  A message originator address, representing router's originator
      address.  A <msg-orig-addr> element MUST be used for this purpose.

   o  Routers Urgency value calculated from its Queue Information Base.
      Urgency value is calculated per interface, combining information
      from Routes Set from Topology Information Base and Queue
      Information Base.

   o  A unique identifier of the maximum Urgency holder together with
      its corresponding Urgency value.  The maximum Urgency holder is a
      Neighbor Backpressure Router with the highest Urgency value of
      neighboring Routers in MANET network connected to particular
      Backpressure Interface.  This information is acquired through
      combining Queue Information Base and Interface Information Base
      (of this particular Backpressure Interface).

   A UR message MAY contain:

   o  A unique identifier of the maximum Urgency holder together with
      its corresponding Urgency value.  This information is included in
      UR message if maximum Urgency holder urgency is greater or equal



Szwabe, et al.          Expires November 3, 2011               [Page 14]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


      to Interface Urgency.  The maximum Urgency holder is a Neighbor
      Backpressure Router with the highest Urgency value of neighboring
      Routers in MANET network connected to particular Backpressure
      Interface.  This information is acquired through combining Queue
      Information Base and Interface Information Base (of this
      particular Backpressure Interface).

   Both values of Backpressure interface's Urgency and Maximum Urgency
   Holder are interface-specific.  Thus UR messages are generated
   independently.

7.2.1.1.  Urgency calculation

   This section presents only the example of a method for calculation of
   Urgency value.  Implementation of the Backpressure Extension can use
   any other algorithm which will provide similar results.

   Interface Urgency Holder is set as follows:

   1.  Interface Urgency := 0;

   2.  For each Queue Tuple (i) from Queue Set where Q_addr is in
       Originator Tuple from Originator Set of Local Information Base as
       O_orig_addr.

       *  For each Routing Tuple from Routing Set where
          R_local_iface_addr = this interface.

          +  For each Queue Tuple (j) from Queue Set where Q_addr (j) =
             R_next_iface_addr and Q_fid (j) = Q_fid (i).

             -  If Interface Urgency < Q_value (j) - Q_value (i) then
                Interface Urgency := Q_value (j) - Q_value (i)

   Maximum Urgency Holder (H_addr, H_urgency) for Backpressure Interface
   is set as follows:

   1.  H_addr := Local interface address and H_urgency := Local
       interface Urgency

   2.  For each Urgency Tuple in Urgency Set of Queue Information Base:

       *  If there is Link Tuple in Link Set of Interface Information
          Base, for which:

          +  L_neighbor_iface_addr_list contains U_addr; AND





Szwabe, et al.          Expires November 3, 2011               [Page 15]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


          +  L_status = HEARD.

          and U_level > H_urgency then:

          +  H_addr := U_addr;

          +  H_urgency := U_level.

7.2.2.  UR Message TLVs

   This specification defines one Message TLV and one Address Block TLV,
   both specific for UR message.

7.2.2.1.  Message TLVs

   In a UR message, a Router MUST include one O_URGENCY TLV as specified
   in Table 4.

   +-----------+--------+----------------------------------------------+
   |    Name   |  Value |                  Description                 |
   |           | Length |                                              |
   +-----------+--------+----------------------------------------------+
   | O_URGENCY |  Up to |    Specifies the Urgency of the Originator   |
   |           |    4   |     Router. This value is represented as     |
   |           | octets |    unsigned integer in network byte order.   |
   +-----------+--------+----------------------------------------------+

                     Table 4: O_URGENCY TLV definition

7.2.2.2.  Address Block TLVs

   +---------+---------+-----------------------------------------------+
   |   Name  |  Value  |                  Description                  |
   |         |  Length |                                               |
   +---------+---------+-----------------------------------------------+
   | URGENCY | Up to 4 |   Specifies the Urgency of the Router. This   |
   |         |  octets |  value is represented as unsigned integer in  |
   |         |         |              network byte order.              |
   +---------+---------+-----------------------------------------------+

                      Table 5: URGENCY TLV definition

7.2.3.  UR Message Transmission

   In order to exchange Urgency values between Routers, each Router MUST
   generate UR Messages.  The messages MUST be transmitted according to
   UR_INTERVAL.  Each Router utilizes its own Queue Information Base
   which contains the most recent Urgency values among the defined



Szwabe, et al.          Expires November 3, 2011               [Page 16]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   (2-hop by default) neighborhood.  UR Message contains information
   about Urgency of the Router which sends the message as well as the
   information about the maximal Urgency (and its holder) in the sending
   Router neighborhood (which in particular case may be the Router own
   Urgency).  After each UR_INTERVAL, UR Message has been generated and
   broadcast to Router's neighbors.

   To determine the maximal Urgency in the neighborhood, the latest
   available information about Urgencies stored in Queue Information
   Base is used.

7.2.4.  UR Message Processing

   Each received (and not discarded) UR message, after initially being
   processed according to [RFC5444], is analyzed by the Router and used
   to update the Queue Information Base, with the following rules in
   mind:

   o  There must be only one Neighbor Tuple in Queue Information Base
      corresponding to the QR message originator address.

   o  If there is not Neighbor Tuple in Queue Information Base
      corresponding to the UR message originator address, such Neighbor
      Tuple MUST be created.


8.  Data Available for Schedulers

   The Backpressure Extension of OLSRv2 defines the minimal set of
   features required to use backpressure-based schedulers.  The network
   area taken into account when the backpressure is calculated, SHOULD
   NOT be considered as covering the full network.

   In a case, when the values of QR_HOPLIMIT are set to proposed default
   (1), the area where backpressure information is available is limited
   to 2-hop neighborhood of the Router.  Such range MAY be treated as an
   approximation of a collision domain of the Router.  A 1-hop
   neighborhood area is covered by QR messages containing neighbors'
   Queue Levels.  This area is extended to 2 hops, thanks to application
   of UR messages which contain information from the 2-hop neighborhood,
   in the form of the maximum backpressure weight together with its
   holders.

   An agent of the standard OLSRv2 protocol interacts with the IP layer
   through the Routing Set, consisting of the following information
   (corresponding to Routing Tuples of OLSRv2):





Szwabe, et al.          Expires November 3, 2011               [Page 17]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   o  Destination address

   o  Next-hop address

   o  Interface address

   o  Distance

   Backpressure Extension of OLSRv2 described in this document extends
   this data in order to enable the scheduler to utilize the
   backpressure weights.  Unlike the standard OLSRv2, data available for
   scheduler can be regarded as flow-oriented: each Flow has its own
   queues.  The routing possibilities MAY be determined for each Flow
   separately.

   The QR and UR messages are transmitted periodically in parallel with
   regular data traffic.  As a result, the Queue Level Set and Urgency
   Set (described in Section 6.6) are updated.  Based on this data the
   scheduler is able to construct the table consisting of the following
   elements:

   o  Flow Identifier (containing the destination Router address)

   o  Next-hop address

   o  Interface address

   o  Urgency

   o  Distance

   which may be presented as follows:

   +---+-------------+-------------+--------------+---------+----------+
   | # |     Flow    |   Next-hop  |   Interface  | Urgency | Distance |
   |   |  Identifier |   address   |    address   |         |          |
   +---+-------------+-------------+--------------+---------+----------+
   | 1 |     (X)     |     (A)     |     eth0     |    4    |     2    |
   | 2 |     (X)     |     (B)     |     eth0     |    10   |     3    |
   | 3 |     (X)     |     (C)     |     eth0     |    9    |     2    |
   | 4 |     (Y)     |     (C)     |     eth0     |    14   |     4    |
   | 5 |     ...     |     ...     |      ...     |   ...   |    ...   |
   +---+-------------+-------------+--------------+---------+----------+

              Table 6: The table of extended routing entries

   The Urgencies of the computing Router's Flows MAY be set on the basis
   of the Queue Level Set entries.  Following the classical backpressure



Szwabe, et al.          Expires November 3, 2011               [Page 18]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   approach the Urgency for a given Flow and a given next-hop MAY be
   calculated as the differences of the Flow queue levels on the
   computing Router and the next-hop Router.  Additionally, thanks to
   the Urgency Set entries the scheduler is able to use the information
   about the maximum value of Urgency in the neighborhood of the
   computing node.


9.  Interoperability with other OLSRv2 Routers

   An OLSRv2 router running the backpressure extension can interoperate
   with an OLSRv2 router that does not run this extension.  The
   Backpressure Extension provides functionalities considered as
   auxiliary.  Additional messages are implemented according to
   [RFC5444] specification.  Router which does not support the proposed
   OLSRv2 protocol extension may simply discard additional information.

   As for Backpressure Routers, the Router behavior for a case when
   there is no information about Queue Levels available from Basic
   OLSRv2 Routers is specified in Section 7.1.4.  Same rules apply to
   Backpressure Routers using different Flow identification (see
   Section 6.5).  The Backpressure Router can use following strategies
   to effectively use routes of Basic OLSRv2 Routers:

   o  Temporary assuming Basic OLSRv2 Router's Queue Levels, that will
      make it last candidate for sending to.

   o  Temporary assuming that Basic OLSRv2 Router's Queue Level is
      average of Neighbor Backpressure Routers Queue Level for
      particular Flow.


10.  Values for Parameters and Constants

10.1.  Message Interval Parameters

   o  QR_INTERVAL := 300 milliseconds

   o  UR_INTERVAL := QR_INTERVAL / 8

10.2.  Message Validity Times Parameters

   o  UR_HOLD_TIME := UR_INTERVAL x 3

   o  QR_HOLD_TIME := QR_INTERVAL x 3






Szwabe, et al.          Expires November 3, 2011               [Page 19]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


10.3.  Hop Limit Parameter

   o  QR_HOPLIMIT := 1

   o  UR_HOPLIMIT := QR_HOPLIMIT

10.4.  Jitter Time Parameters

   o  QR_MAXJITTER := QR_INTERVAL / 4

   o  UR_MAXJITTER := UR_INTERVAL / 4


11.  Security Considerations

   To be elaborated.


12.  IANA Considerations

   This specification defines two Message Types, which must be allocated
   from the "Message Types" registry of [RFC5444].

12.1.  Expert Review: Evaluation Guidelines

   For the registries where an Expert Review is required, the designated
   expert SHOULD take the same general recommendations into
   consideration as are specified by [RFC5444].

12.2.  Message Types

   This specification defines two Message Types, to be allocated from
   the 0-223 range of the "Message Types" namespace defined in
   [RFC5444], as specified in Table 7.

                    +------+-------------------------+
                    | Type |       Description       |
                    +------+-------------------------+
                    | TBD1 |   UR : Urgency report   |
                    | TBD2 | QR : Queue Level report |
                    +------+-------------------------+

                     Table 7: Message Type assignment








Szwabe, et al.          Expires November 3, 2011               [Page 20]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


12.3.  Message-Type-specific TLV Type Registries

   IANA is requested to create a registry for Message-Type-specific
   Message TLVs for UR messages, in accordance with Section 6.2.1 of
   [RFC5444], and with initial assignments and allocation policies as
   specified in Table 8.

   +-----------+---------+--------------------------+------------------+
   |    Name   |   Type  |        Description       |    Allocation    |
   |           |         |                          |      Policy      |
   +-----------+---------+--------------------------+------------------+
   | O_URGENCY |   128   |    Specifies Router's    |                  |
   |           |         |         Urgency.         |                  |
   |           | 129-223 |        Unassigned        |   Expert Review  |
   +-----------+---------+--------------------------+------------------+

              Table 8: UR Message-Type-specific Message TLVs

   IANA is requested to create a registry for Message-Type-specific
   Address block TLVs for UR messages, in accordance with Section 6.2.1
   of [RFC5444], and with initial assignments and allocation policies as
   specified in Table 9.

   +---------+---------+-------------------------------+---------------+
   |   Name  |   Type  |          Description          |   Allocation  |
   |         |         |                               |     Policy    |
   +---------+---------+-------------------------------+---------------+
   | URGENCY |   128   |      Specifies Urgency of     |               |
   |         |         |       associated Router.      |               |
   |         | 129-223 |           Unassigned          | Expert Review |
   +---------+---------+-------------------------------+---------------+

           Table 9: UR Message-Type-specific Address block TLVs

   IANA is requested to create a registry for Message-Type-specific
   Message TLVs for QR messages, in accordance with Section 6.2.1 of
   [RFC5444], and with initial assignments and allocation policies as
   specified in Table 10.

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               | 128-223 |  Unassigned |   Expert Review   |
               +---------+-------------+-------------------+

              Table 10: QR Message-Type-specific Message TLVs

   IANA is requested to create a registry for Message-Type-specific



Szwabe, et al.          Expires November 3, 2011               [Page 21]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   Address block TLVs for UR messages, in accordance with Section 6.2.1
   of [RFC5444], and with initial assignments and allocation policies as
   specified in Table 11.

   +-------------+---------+------------------------------+------------+
   |     Name    |   Type  |          Description         | Allocation |
   |             |         |                              |   Policy   |
   +-------------+---------+------------------------------+------------+
   |   PROTOCOL  |   128   |   Specifies Protocol Number  |            |
   |             |         | used on the transport layer. |            |
   | QUEUE_LEVEL |   129   |     Specifies Queue Level    |            |
   |             |         |            status.           |            |
   |     PORT    |   130   |  Specifies port address used |            |
   |             |         |    on the transport layer.   |            |
   |             | 131-223 |          Unassigned          |   Expert   |
   |             |         |                              |   Review   |
   +-------------+---------+------------------------------+------------+

           Table 11: QR Message-Type-specific Address block TLVs


13.  Acknowledgements

   This work was partly supported by the grant of Poznan University of
   Technology DS 45-083/10 and the European Commission OPNEX STREP (FP7-
   224218, http://opnex.eu).

   The authors also want to thank the following people for their
   contributions to this document:

   o  Adam Nowak, Poznan University of Technology, Poland,
      <Adam.Nowak@put.poznan.pl>

   o  Przemyslaw Walkowiak, Poznan University of Technology, Poland,
      <Przemyslaw.Walkowiak@put.poznan.pl>


14.  References

14.1.  Normative References

   [I-D.dearlove-olsrv2-metrics]
              Dearlove, C., Clausen, T., and P. Jacquet, "Link Metrics
              for OLSRv2", draft-dearlove-olsrv2-metrics-05 (work in
              progress), June 2010.

   [I-D.ietf-manet-olsrv2]
              Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized



Szwabe, et al.          Expires November 3, 2011               [Page 22]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


              Link State Routing Protocol version 2",
              draft-ietf-manet-olsrv2-11 (work in progress), April 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, February 2008.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
              Format", RFC 5444, February 2009.

   [RFC5498]  Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
              (MANET) Protocols", RFC 5498, March 2009.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, April 2011.

14.2.  Informative References

   [I-D.multipath-olsrv2]
              Szwabe, A., Nowak, A., Baccelli, E., Yi, J., and B.
              Parrein, "Multi-path for Optimized Link State Routing
              Protocol version 2", draft-szwabe-manet-multipath-olsrv2
              (work in progress), 2010.

   [SMN+10]   Szwabe, A., Misiorek, P., Nowak, A., and J. Marchwicki,
              "Implementation of Backpressure-Based Routing Integrated
              with Max-Weight Scheduling in a Wireless Multi-hop
              Network", Proc. of 3rd IEEE International Workshop on
              Wireless and Internet Services (WISe 2010), Denver, USA,
              pages 999-1004, 2010.


Appendix A.  Illustrations

A.1.  QR Message Examples

   This appendix illustrates QR message examples.  As QR message is a
   instance of [RFC5444] and its exact form depends on conveyed
   information formatted by the sender.  Because of that following
   examples show only possible form that specified information can be
   presented.

   First example of QR message conveys information about Queue Levels of



Szwabe, et al.          Expires November 3, 2011               [Page 23]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   two Flows.  The Backpressure Router uses complex Flow Identifier
   containing:

   o  Destination address

   o  Source address

   o  Internet Protocol Number of a protocol used in the transport layer

   o  If used, an additional transport protocol source and destination
      address (i.e. port addresses in TCP or UDP)

   This message contains two information about Flows:

   o  UDP (17) stream from IP 192.168.40.1:4563 to 192.168.40.67:8213

   o  ICMP (1) ping requests from 192.168.40.72 to 192.168.40.69


































Szwabe, et al.          Expires November 3, 2011               [Page 24]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      QR       |1 1 0 1|0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|    Message Sequence Number    |0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|1 0 0 0 0| Rsv |0 0 0 0 0 0 1 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Head (192.168.40.)               |    Mid (.1)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Mid (.67)   |0 0 0 0 0 0 0 0|0 0 0 1 0 0 0 1|   PORT TLV    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 1 0 1|Rsv|0 0 0 0 0 1 0 0|  VALUE = UDP SRC PORT (4563)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  VALUE = UDP DST PORT (8213)  |  PROTOCOL TLV |0 0 0 1 0 0|Rsv|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|  VALUE = 17   |QUEUE_LEVEL TLV|0 0 0 1 0 0|Rsv|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 1|              VALUE  = QUEUE LEVEL             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 0|1 0 0 0 0| Rsv |0 0 0 0 0 0 1 1|      Head     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Head (cont, 192.168.40.)      |  Mid (.72)    |   Mid (.69)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0|0 0 0 0 1 1 0 1|  PROTOCOL TLV |0 0 0 1 0 0|Rsv|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|   VALUE = 1   |QUEUE_LEVEL TLV|0 0 0 1 0 0|Rsv|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 0|              VALUE = QUEUE LEVEL              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | VALUE (cont)  |
     +-+-+-+-+-+-+-+-+

        Figure 1: QR Message example of two Flows with a full Flow
                                Identifier.

   Second example of QR message conveys information about Queue Levels
   of two Flows.  Origin Backpressure Router uses Flow Identifier
   containing only:

   o  Destination address

   o  Source address

   This message contains two information about Flows:



Szwabe, et al.          Expires November 3, 2011               [Page 25]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   o  IP packets from IP 192.168.40.1 to 192.168.40.67

   o  IP packets from 192.168.40.72 to 192.168.40.69


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      QR       |1 1 0 1|0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|    Message Sequence Number    |0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|1 0 0 0 0| Rsv |0 0 0 0 0 0 1 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Head (192.168.40.)               |    Mid (.1)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Mid (.67)   |0 0 0 0 0 0 0 0|0 0 0 1 0 0 1 0|QUEUE_LEVEL TLV|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 1 0 0|Rsv|0 0 0 0 0 1 0 0|     VALUE = QUEUE LEVEL       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           VALUE (cont)        |0 0 0 0 0 0 1 0|1 0 0 0 0| Rsv |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 1|              Head (192.168.40.)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mid (.72)    |   Mid (.69)   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |QUEUE_LEVEL TLV|0 0 0 1 0 0|Rsv|0 0 0 0 0 1 0 0|    VALUE      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           VALUE (cont) = QUEUE LEVEL          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 2: QR Message example of two Flows with a simplified Flow
                                Identifier.
















Szwabe, et al.          Expires November 3, 2011               [Page 26]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


A.2.  UR Message Example

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      UR       |1 1 0 1|0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |    Message Sequence Number    |0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 1 0| O_URGENCY TLV |0 0 0 1 0 0|Rsv|0 0 0 0 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 VALUE = ORIGIN URGENCY LEVEL                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 0 0 0 0| Rsv |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Mid (cont)           |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  URGENCY TLV  |0 0 0 1 0 0|Rsv|     VALUE = URGENCY LEVEL     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         VALUE (cont)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: QR Message Example of one Flow.


Authors' Addresses

   Andrzej Szwabe
   Poznan University of Technology
   5 M. Sklodowskiej-Curie Sq.
   60-965 Poznan
   Poland

   Phone: +48 61 665 3958
   Email: Andrzej.Szwabe@put.poznan.pl


   Pawel Misiorek
   Poznan University of Technology
   5 M. Sklodowskiej-Curie Sq.
   60-965 Poznan
   Poland

   Phone: +48 61 665 3958
   Email: Pawel.Misiorek@put.poznan.pl




Szwabe, et al.          Expires November 3, 2011               [Page 27]


Internet-Draft      Backpressure extension of OLSRv2            May 2011


   Maciej Urbanski (editor)
   Poznan University of Technology
   5 M. Sklodowskiej-Curie Sq.
   60-965 Poznan
   Poland

   Phone: +48 61 665 3958
   Email: Maciej.Urbanski@put.poznan.pl


   Emmanuel Baccelli
   INRIA

   Phone: +33-169-335-511
   Email: Emmanuel.Baccelli@inria.fr
   URI:   http://www.emmanuelbaccelli.org/



































Szwabe, et al.          Expires November 3, 2011               [Page 28]