idnits 2.17.1 draft-szwabe-manet-backpressure-olsrv2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o PORT TLV MUST not be used if there is no PROTOCOL TLV associated with these addresses. -- The document date (May 2, 2011) is 4736 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-dearlove-olsrv2-metrics-05 == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-11 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Szwabe 3 Internet-Draft P. Misiorek 4 Intended status: Experimental M. Urbanski, Ed. 5 Expires: November 3, 2011 Poznan University of Technology 6 E. Baccelli 7 INRIA 8 May 2, 2011 10 OLSRv2 Backpressure Traffic Engineering Extension 11 draft-szwabe-manet-backpressure-olsrv2-02 13 Abstract 15 This document specifies a traffic engineering extension for OLSRv2 16 based on backpressure, which allows advanced traffic shaping by 17 providing each MANET router with information about packet queue 18 levels of its neighbors. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. This document may not be modified, 24 and derivative works of it may not be created, and it may not be 25 published except as an Internet-Draft. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 3, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Parameters and Constants . . . . . . . . . . . . . . . . . . . 6 61 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 6 62 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 7 63 5.3. Message Intervals . . . . . . . . . . . . . . . . . . . . 7 64 5.4. Message Validity Times . . . . . . . . . . . . . . . . . . 7 65 5.5. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Local Information Base . . . . . . . . . . . . . . . . . . 8 68 6.2. Interface Information Base . . . . . . . . . . . . . . . . 8 69 6.3. Topology Information Base . . . . . . . . . . . . . . . . 8 70 6.4. Received Message Information Base . . . . . . . . . . . . 9 71 6.5. Flow Identification . . . . . . . . . . . . . . . . . . . 9 72 6.6. Queue Information Base . . . . . . . . . . . . . . . . . . 10 73 6.6.1. Queue Levels Set . . . . . . . . . . . . . . . . . . . 10 74 6.6.2. Urgency Set . . . . . . . . . . . . . . . . . . . . . 10 75 6.6.3. Updating the Data . . . . . . . . . . . . . . . . . . 11 76 7. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. QR Message . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1.1. QR Message Generation . . . . . . . . . . . . . . . . 11 79 7.1.2. QR Message TLVs . . . . . . . . . . . . . . . . . . . 12 80 7.1.3. QR Message Transmission . . . . . . . . . . . . . . . 13 81 7.1.4. QR Message Processing . . . . . . . . . . . . . . . . 13 82 7.2. UR Message . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7.2.1. UR Message Generation . . . . . . . . . . . . . . . . 14 84 7.2.2. UR Message TLVs . . . . . . . . . . . . . . . . . . . 16 85 7.2.3. UR Message Transmission . . . . . . . . . . . . . . . 16 86 7.2.4. UR Message Processing . . . . . . . . . . . . . . . . 17 87 8. Data Available for Schedulers . . . . . . . . . . . . . . . . 17 88 9. Interoperability with other OLSRv2 Routers . . . . . . . . . . 19 89 10. Values for Parameters and Constants . . . . . . . . . . . . . 19 90 10.1. Message Interval Parameters . . . . . . . . . . . . . . . 19 91 10.2. Message Validity Times Parameters . . . . . . . . . . . . 19 92 10.3. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 20 93 10.4. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 20 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 12.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 20 97 12.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 20 98 12.3. Message-Type-specific TLV Type Registries . . . . . . . . 21 99 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 102 14.2. Informative References . . . . . . . . . . . . . . . . . . 23 103 Appendix A. Illustrations . . . . . . . . . . . . . . . . . . . . 23 104 A.1. QR Message Examples . . . . . . . . . . . . . . . . . . . 23 105 A.2. UR Message Example . . . . . . . . . . . . . . . . . . . . 27 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 108 1. Introduction 110 This document specifies a traffic engineering extension for OLSRv2 111 [I-D.ietf-manet-olsrv2] based on backpressure, which can increase and 112 balance end-to-end throughput by providing each MANET router with 113 information about packet queue levels of its neighbors. This 114 document defines signaling and processing that is necessary, in 115 addition to the signaling and processing defined in 116 [I-D.ietf-manet-olsrv2], [RFC6130] and [RFC5444], to provide 117 efficient traffic engineering in OLSRv2 with a backpressure-based 118 scheme [SMN+10]. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 All terms introduced in [RFC5444], including "packet", "Packet 127 Header", "message", "Message Header", "Message Body", "Message Type", 128 "message sequence number", "hop limit", "hop count", "Address Block", 129 "TLV Block", "TLV", "Message TLV", "Address Block TLV", "type" (of 130 TLV), "type extension" (of TLV), "value" (of TLV), "address" and 131 "address object" are to be interpreted as described there. 133 All terms introduced in [RFC6130], including "interface", "MANET 134 interface", "network address", "link", "symmetric link", "1-hop 135 neighbor", "symmetric 1-hop neighbor", "symmetric 2-hop neighbor", 136 "constant", "interface parameter", "router parameter", "Information 137 Base", and "HELLO message" are to be interpreted as described there. 139 All terms introduced in [I-D.ietf-manet-olsrv2] and 140 [I-D.dearlove-olsrv2-metrics], including the terms "Router", "OLSRv2 141 interface", "Originator address", "Message originator address", 142 "Routing Set", "Routing Tuple" are to be interpreted as described 143 therein. 145 Additionally, this document uses the following terminology: 147 Flow 148 A particular packet sequence transmitted through the 149 network. 151 Flow Identifier 152 A set of values which enable unambiguous identification of 153 the Flow. 155 Timeslot 156 A definite continuously repeating time period when events 157 may occur. For example: "In a given Timeslot, 15 packets 158 have been processed." 160 Scheduler 161 In this document, a scheduler is considered as a part of 162 the system maintaining the traffic on the router. A 163 scheduler decides which Flow should be forwarded at a given 164 time. 166 Queue Level 167 The number of units (e.g., packets or bytes) in a Flow 168 Queue on a router. 170 Backpressure 171 The backpressure routing/scheduling policy is based on 172 giving priority in forwarding to links and Flows that have 173 higher backpressure, defined as the backlog differential 174 (i.e., the difference between Queue Levels) at consecutive 175 Routers. 177 Basic OLSRv2 Router 178 A OLSRv2 Router without Backpressure Extension. 180 Backpressure Router 181 A OLSRv2 Router featuring the Backpressure Extension. 183 Backpressure Interface 184 A OLSRv2 interface running the Backpressure Extension. 186 Urgency 187 Urgency is a queue-level-based scheduling weight used by a 188 Backpressure Scheduler. Unless otherwise specified, 189 urgency is defined as a backlog differential (i.e., the 190 difference between Queue Levels) at consecutive Routers. 192 Router Urgency 193 The maximum Urgency over all active Flows and all active 194 connections on the router. 196 Backpressure Scheduler 197 Specific type of scheduler which provides integrated packet 198 scheduling and forwarding according to the backpressure 199 policy based on the information on scheduling weights 200 (Urgencies). 202 per-flow 203 This term refers to resources which may be regarded as 204 allocated to a Flow. 206 3. Applicability 208 The OLSRv2 extension specified in this document should be used 209 together with an OLSRv2 multipath extension such as 210 [I-D.multipath-olsrv2], in order to fully benefit from potential load 211 balancing and throughput optimization. However, the extension 212 specified in this document can be used without any other OLSRv2 213 extension, to increase end-to-end throughput. 215 Routers which do not support the OLSRv2 extension specified in this 216 document are interoperable with routers that do support the extension 217 according to the present specification. 219 4. Protocol Overview 221 The OLSRv2 extension defined in the following sections provides 222 traffic engineering capabilities to MANET routers, based on a 223 backpressure scheme which can increase end-to-end throughput. This 224 document specifies data flow identification, as well as periodical 225 signaling of Queue Report (QR) and Urgency Report (UR) messages using 226 the format specified in [RFC5444], which enables a router to monitor 227 the queue levels of its neighbors. 229 QR and UR messages provide each node with the information enabling 230 the backpressure max-weight scheduling. Information carried by QR 231 messages is necessary for each router to calculate its backpressure- 232 based scheduling weights (i.e., its urgencies), whereas UR messages 233 are used to inform each router on urgencies within its neighborhood. 234 By using QR and UR messages routers may perform backpressure max- 235 weight scheduling, which is theoretically proven as a distributed 236 load-balancing solution maximizing overall network throughput, e.g., 237 enabling to avoid forwarding packets through a network bottleneck 238 [SMN+10]. 240 5. Parameters and Constants 242 5.1. Protocol and Port Numbers 244 The backpressure extension of OLSRv2 specifies QR and UR messages, 245 which are included in packets as defined in [RFC5444]. These packets 246 may be sent either by using the "manet" protocol number or the 247 "manet" UDP well-known port number, as specified in [RFC5498]. 249 QR, UR and TC [I-D.ietf-manet-olsrv2], HELLO [RFC6130] messages 250 SHOULD be using the same transport protocol (either of IP or UDP) in 251 order to make it possible to combine messages of all these protocols 252 into a single [RFC5444] packet. 254 5.2. Multicast Address 256 The Backpressure Extension of OLSRv2 specifies QR and UR messages, 257 which are included in packets as defined by [RFC5444]. These packets 258 MAY be transmitted using the link local multicast address "LL-MANET- 259 Routers", as specified in [RFC5498]. 261 5.3. Message Intervals 263 This specification defines the following message intervals: 265 QR_INTERVAL - the maximum time between transmission of two 266 consecutive QR messages 268 UR_INTERVAL - the maximum time between transmission of two 269 consecutive UR messages 271 Intervals defined in this document MUST comply to the following 272 constraints: 274 o UR_INTERVAL > 0 276 o UR_INTERVAL < QR_INTERVAL 278 5.4. Message Validity Times 280 This specification defines the following Advertised Information 281 Validity Times: 283 UR_HOLD_TIME - a validity time of UR message and a validity time of 284 information carried by this message. 286 QR_HOLD_TIME - a validity time of QR message and a validity time of 287 information carried by this message. 289 BP_HOLD_TIME - the maximum time without receiving a QR message or a 290 UR message from a neighbor Router. 292 Validity times defined in this document MUST apply to the following 293 constrains: 295 o UR_HOLD_TIME > UR_INTERVAL 297 o QR_HOLD_TIME > QR_INTERVAL 299 o BP_HOLD_TIME > UR_INTERVAL or BP_HOLD_TIME > QR_INTERVAL 301 o In the case of high loss ratio of QR and UR messages, BP_HOLD_TIME 302 should be made significantly greater than UR_INTERVAL or 303 QR_INTERVAL interval. 305 5.5. Jitter 307 If jitter, as defined in [RFC5148], is used, the following jitter 308 parameters are required to be defined: 310 QR_MAXJITTER - value of MAXJITTER used in [RFC5148] for periodically 311 generated QR messages sent by this Router. 313 UR_MAXJITTER - value of MAXJITTER used in [RFC5148] for periodically 314 generated UR messages sent by this Router. 316 6. Information Bases 318 The Information Bases defined here extend these specified in 319 [RFC6130] and [I-D.ietf-manet-olsrv2] with both: information and its 320 uses. This organization of information serve purpose of describing 321 the Backpressure Extension, and DOES NOT constrain in any way 322 implementation of this extension. 324 6.1. Local Information Base 326 The Local Information Base is specified in [I-D.ietf-manet-olsrv2]. 327 Additionally information stored there is used for the Backpressure 328 Extension signaling. 330 6.2. Interface Information Base 332 The Interface Information Base is specified in 333 [I-D.ietf-manet-olsrv2]. Additionally information stored there is 334 used for the Backpressure Extension signaling. 336 6.3. Topology Information Base 338 The Topology Information Base is specified in 339 [I-D.ietf-manet-olsrv2]. Additionally information stored there is 340 used for choosing on which interfaces QR and UR messages should be 341 announced. 343 6.4. Received Message Information Base 345 The Received Message Information Base defined by 346 [I-D.ietf-manet-olsrv2] is extended by this specification by 347 introducing also an information about QR and UR messages. The 348 Received Message Information Base structure is not modified by the 349 Backpressure Extension. The way the messages are processed in 350 Information Base is defined in Section 7. 352 6.5. Flow Identification 354 In order to enable backpressure-based per-flow routing, unambiguous 355 Flow identification is specified by this document. For this purpose 356 Flow Identifier MAY hold the following parameters set: 358 o Destination address 360 o Source address 362 o Internet Protocol Number of a protocol used in the transport layer 364 o If used, an additional transport protocol source and destination 365 address (i.e. port addresses in TCP or UDP) 367 This specification allows various combinations of these parameters to 368 be used in order to identify a Flow. Flow identification parameters 369 MUST be the same across the MANET network. Routers using different 370 set of parameters to identify the Flow are treated as Basic OLSRv2 371 Routers by Backpressure Routers. 373 One of the following parameters subsets MUST be used: 375 o Destination address, Source address, Internet Protocol Number with 376 source and port addresses (if used). 378 o Destination address, Source address. 380 o Only destination address 382 Information about Flows is necessary from the perspective of the 383 Scheduler which differentiate the traffic depending on its type. 384 More detailed per-flow identification increases signaling overhead. 385 As the countermeasure, the Urgency signaling (see Section 7.2) which 386 significantly reduces amount of transmitted data is deployed. 387 Overhead of Urgency signaling itself does not increase with 388 complexity of Flow Identifier. 390 For encoding of Flow Identifier special QR Message-specific TLVs are 391 defined: 393 o PROTOCOL - Internet Protocol number used within transport layer. 395 o PORT - address used in transport layer, associated with a single 396 address. 398 More detailed information about formatting of Flow Identifier in QR 399 Messages as specified in Section 7.1.2. 401 6.6. Queue Information Base 403 A Queue Information Base defined here stores information extracted 404 from received QR and UR messages. The Queue Information Base 405 consists of the Queue Level Set, the Urgency Set. 407 6.6.1. Queue Levels Set 409 The Queue Level Set contains neighbor's Queue Levels reported by 410 means of QR messages, as well as local Queue Levels of the 411 Backpressure Router. This set consists of Queue Level Tuples: 413 (Q_addr, Q_fid, Q_level, Q_time) 415 where: 417 o Q_addr is the originator address of the Backpressure Router 418 sending the QR message; 420 o Q_fid is a Flow Identifier; 422 o Q_level is a Queue Level reported for this Flow by the 423 Backpressure Router; 425 o Q_time is the Tuple expiration time, after which Tuple MUST be 426 removed. 428 6.6.2. Urgency Set 430 The Urgency Set records Urgency values. Urgency values are delivered 431 by means of UR messages (in the case of Urgencies of neighboring 432 Routers) or calculated using values from Queue Level Set (in the case 433 of local Urgency, i.e., the maximum Urgency of queues stored in the 434 local Router). This set consists of Urgency Tuples: 436 (U_addr, U_level, U_time) 438 where: 440 o U_addr is the originator address of Backpressure Router associated 441 with the Urgency value; 443 o U_level is an Urgency; 445 o U_time is a Tuple expiration time, after which Tuple MUST be 446 removed. 448 6.6.3. Updating the Data 450 In order to maintain the Queue Information Base properly, the 451 following actions MUST be taken: 453 o An entry MUST be removed after the time defined as the Tuple 454 expiration time (Q_time or U_time respectively). 456 o A new entry corresponding to a pair Q_addr and Q_fid in Queue 457 Level Tuple or U_addr and U_level in Urgency Tuple, which is 458 already present in the Queue Information Base, MUST be 459 overwritten. 461 7. Signaling 463 Messages defined by [RFC6130] and [I-D.ietf-manet-olsrv2] are used as 464 specified there. This extension does not involve modifications to 465 these messages. 467 The packet and message format used by the Backpressure Extension of 468 OLSRv2 are defined in [RFC5444]. If not noted otherwise, options 469 defined in [RFC5444] MAY be used. 471 The QR and UR messages MUST follow specification of Message 472 Processing and Forwarding defined in [I-D.ietf-manet-olsrv2]. 474 7.1. QR Message 476 7.1.1. QR Message Generation 478 QR messages are generated by a Router for each of its Backpressure 479 interfaces, and MUST be sent proactively and MAY be sent in a 480 combination of proactive and reactive techniques. 482 proactive - at a regular interval, known as QR_INTERVAL, which may 483 be fixed or dynamic, and in case of fixed interval MAY be the same 484 across the network. 486 reactive - in reaction to a change of queue states, limited to 487 queues that changed. In this case the maximum refresh time SHOULD 488 be set, and minimal queue state change required to trigger QR 489 message MUST be set (independently by each Router). 491 A QR message MUST contain: 493 o A := QR_HOPLIMIT, which limits the QR messaging 494 network-wide overhead. 496 o A message originator address, representing Router's originator 497 address. A element MUST be used for this purpose. 499 A QR message MAY contain: 501 o Address blocks with associated PORT, PROTOCOL and QUEUE_LEVEL TLV 502 as specified in Section 7.1.2, and as required for Flow 503 Identification. 505 7.1.2. QR Message TLVs 507 7.1.2.1. Address Block TLVs 509 In a QR message, a Router MAY include PROTOCOL Address Block TLV(s) 510 as specified in Table 1. 512 +----------+--------------+----------------------------------------+ 513 | Type | Value Length | Value | 514 +----------+--------------+----------------------------------------+ 515 | PROTOCOL | 1 octet | Associated with a whole address block. | 516 +----------+--------------+----------------------------------------+ 518 Table 1: PROTOCOL TLV definition 520 In a QR message, a Router MAY include PORT Address Block TLV(s) as 521 specified in Table 2. 523 +------+----------+-------------------------------------------------+ 524 | Type | Value | Value | 525 | | Length | | 526 +------+----------+-------------------------------------------------+ 527 | PORT | 2 octets | Indicates that source or destination uses | 528 | | | corresponding PORT value as port number. | 529 +------+----------+-------------------------------------------------+ 531 Table 2: PORT TLV definition 533 In a QR message, a Router MAY include QUEUE_LEVEL Address Block 534 TLV(s) as specified in Table 3. 536 +-------------+----------+------------------------------------------+ 537 | Type | Value | Value | 538 | | Length | | 539 +-------------+----------+------------------------------------------+ 540 | QUEUE_LEVEL | up to 4 | Queue Level expressed as unsigned | 541 | | octets | integer filed (encoded with network byte | 542 | | | order). | 543 +-------------+----------+------------------------------------------+ 545 Table 3: QUEUE_LEVEL TLV definition 547 Relationship between PROTOCOL TLV, PORT TLV, QUEUE_LEVEL is based on 548 structure of Flow Identifier, and MUST comply with following rules: 550 o One entity of Flow Identifier with associated QUEUE_LEVEL TLV MAY 551 be presented as addr_block and tlv_block pair. 553 o PORT TLV MUST not be used if there is no PROTOCOL TLV associated 554 with these addresses. 556 o If required by Flow Identifier, one per address PORT TLV MAY be 557 used. 559 o To be considered a valid Flow Identifier all used fields (PORT 560 TLV, PROTOCOL TLV, QUEUE_LEVEL TLV) MUST be assigned to two 561 addresses (representing source and destination address). 563 7.1.3. QR Message Transmission 565 In order to exchange the Queue Level values between Routers, Router 566 MUST generate QR Messages. The messages MUST be transmitted 567 according to QR_INTERVAL. The scheduler assigned to the Router MUST 568 provide sufficient information about Queue Levels of the Router. The 569 information about Queue Level of the sending Router MUST be the most 570 recent available. After each QR_INTERVAL, QR Message is generated 571 and then broadcast to Router's neighbors. 573 When a Router receives QR Message, an appropriate queue value is 574 assigned to message originator as according to the corresponding 575 entry in the Backpressure Information Base. 577 7.1.4. QR Message Processing 579 Each received (and not discarded) QR message, after initially being 580 processed according to [RFC5444], should be analyzed by Router and 581 used to update the Queue Information Base, according to the following 582 rules: 584 o There must be only one, the most actual, Queue Level Tuple in 585 Queue Level Set of Queue Information Base corresponding to QR 586 message originator address and Flow Identifier. 588 o If there is no Queue Level Tuple in Queue Level Set corresponding 589 to information in QR message, such Queue Level Tuple MUST be 590 created. 592 o If QR message contains Flow Identifier that is differently defined 593 than the one used by this Router (see Section 6.5), the QR message 594 MUST be discarded. 596 7.2. UR Message 598 7.2.1. UR Message Generation 600 UR messages are generated by a Router independently for each of 601 Routers Backpressure interfaces. UR messages SHOULD be sent 602 proactively, at a regular interval, called UR_INTERVAL, which may be 603 fixed or dynamic. 605 A UR message MUST contain: 607 o A := UR_HOP_LIMIT. 609 o A message originator address, representing router's originator 610 address. A element MUST be used for this purpose. 612 o Routers Urgency value calculated from its Queue Information Base. 613 Urgency value is calculated per interface, combining information 614 from Routes Set from Topology Information Base and Queue 615 Information Base. 617 o A unique identifier of the maximum Urgency holder together with 618 its corresponding Urgency value. The maximum Urgency holder is a 619 Neighbor Backpressure Router with the highest Urgency value of 620 neighboring Routers in MANET network connected to particular 621 Backpressure Interface. This information is acquired through 622 combining Queue Information Base and Interface Information Base 623 (of this particular Backpressure Interface). 625 A UR message MAY contain: 627 o A unique identifier of the maximum Urgency holder together with 628 its corresponding Urgency value. This information is included in 629 UR message if maximum Urgency holder urgency is greater or equal 630 to Interface Urgency. The maximum Urgency holder is a Neighbor 631 Backpressure Router with the highest Urgency value of neighboring 632 Routers in MANET network connected to particular Backpressure 633 Interface. This information is acquired through combining Queue 634 Information Base and Interface Information Base (of this 635 particular Backpressure Interface). 637 Both values of Backpressure interface's Urgency and Maximum Urgency 638 Holder are interface-specific. Thus UR messages are generated 639 independently. 641 7.2.1.1. Urgency calculation 643 This section presents only the example of a method for calculation of 644 Urgency value. Implementation of the Backpressure Extension can use 645 any other algorithm which will provide similar results. 647 Interface Urgency Holder is set as follows: 649 1. Interface Urgency := 0; 651 2. For each Queue Tuple (i) from Queue Set where Q_addr is in 652 Originator Tuple from Originator Set of Local Information Base as 653 O_orig_addr. 655 * For each Routing Tuple from Routing Set where 656 R_local_iface_addr = this interface. 658 + For each Queue Tuple (j) from Queue Set where Q_addr (j) = 659 R_next_iface_addr and Q_fid (j) = Q_fid (i). 661 - If Interface Urgency < Q_value (j) - Q_value (i) then 662 Interface Urgency := Q_value (j) - Q_value (i) 664 Maximum Urgency Holder (H_addr, H_urgency) for Backpressure Interface 665 is set as follows: 667 1. H_addr := Local interface address and H_urgency := Local 668 interface Urgency 670 2. For each Urgency Tuple in Urgency Set of Queue Information Base: 672 * If there is Link Tuple in Link Set of Interface Information 673 Base, for which: 675 + L_neighbor_iface_addr_list contains U_addr; AND 676 + L_status = HEARD. 678 and U_level > H_urgency then: 680 + H_addr := U_addr; 682 + H_urgency := U_level. 684 7.2.2. UR Message TLVs 686 This specification defines one Message TLV and one Address Block TLV, 687 both specific for UR message. 689 7.2.2.1. Message TLVs 691 In a UR message, a Router MUST include one O_URGENCY TLV as specified 692 in Table 4. 694 +-----------+--------+----------------------------------------------+ 695 | Name | Value | Description | 696 | | Length | | 697 +-----------+--------+----------------------------------------------+ 698 | O_URGENCY | Up to | Specifies the Urgency of the Originator | 699 | | 4 | Router. This value is represented as | 700 | | octets | unsigned integer in network byte order. | 701 +-----------+--------+----------------------------------------------+ 703 Table 4: O_URGENCY TLV definition 705 7.2.2.2. Address Block TLVs 707 +---------+---------+-----------------------------------------------+ 708 | Name | Value | Description | 709 | | Length | | 710 +---------+---------+-----------------------------------------------+ 711 | URGENCY | Up to 4 | Specifies the Urgency of the Router. This | 712 | | octets | value is represented as unsigned integer in | 713 | | | network byte order. | 714 +---------+---------+-----------------------------------------------+ 716 Table 5: URGENCY TLV definition 718 7.2.3. UR Message Transmission 720 In order to exchange Urgency values between Routers, each Router MUST 721 generate UR Messages. The messages MUST be transmitted according to 722 UR_INTERVAL. Each Router utilizes its own Queue Information Base 723 which contains the most recent Urgency values among the defined 724 (2-hop by default) neighborhood. UR Message contains information 725 about Urgency of the Router which sends the message as well as the 726 information about the maximal Urgency (and its holder) in the sending 727 Router neighborhood (which in particular case may be the Router own 728 Urgency). After each UR_INTERVAL, UR Message has been generated and 729 broadcast to Router's neighbors. 731 To determine the maximal Urgency in the neighborhood, the latest 732 available information about Urgencies stored in Queue Information 733 Base is used. 735 7.2.4. UR Message Processing 737 Each received (and not discarded) UR message, after initially being 738 processed according to [RFC5444], is analyzed by the Router and used 739 to update the Queue Information Base, with the following rules in 740 mind: 742 o There must be only one Neighbor Tuple in Queue Information Base 743 corresponding to the QR message originator address. 745 o If there is not Neighbor Tuple in Queue Information Base 746 corresponding to the UR message originator address, such Neighbor 747 Tuple MUST be created. 749 8. Data Available for Schedulers 751 The Backpressure Extension of OLSRv2 defines the minimal set of 752 features required to use backpressure-based schedulers. The network 753 area taken into account when the backpressure is calculated, SHOULD 754 NOT be considered as covering the full network. 756 In a case, when the values of QR_HOPLIMIT are set to proposed default 757 (1), the area where backpressure information is available is limited 758 to 2-hop neighborhood of the Router. Such range MAY be treated as an 759 approximation of a collision domain of the Router. A 1-hop 760 neighborhood area is covered by QR messages containing neighbors' 761 Queue Levels. This area is extended to 2 hops, thanks to application 762 of UR messages which contain information from the 2-hop neighborhood, 763 in the form of the maximum backpressure weight together with its 764 holders. 766 An agent of the standard OLSRv2 protocol interacts with the IP layer 767 through the Routing Set, consisting of the following information 768 (corresponding to Routing Tuples of OLSRv2): 770 o Destination address 772 o Next-hop address 774 o Interface address 776 o Distance 778 Backpressure Extension of OLSRv2 described in this document extends 779 this data in order to enable the scheduler to utilize the 780 backpressure weights. Unlike the standard OLSRv2, data available for 781 scheduler can be regarded as flow-oriented: each Flow has its own 782 queues. The routing possibilities MAY be determined for each Flow 783 separately. 785 The QR and UR messages are transmitted periodically in parallel with 786 regular data traffic. As a result, the Queue Level Set and Urgency 787 Set (described in Section 6.6) are updated. Based on this data the 788 scheduler is able to construct the table consisting of the following 789 elements: 791 o Flow Identifier (containing the destination Router address) 793 o Next-hop address 795 o Interface address 797 o Urgency 799 o Distance 801 which may be presented as follows: 803 +---+-------------+-------------+--------------+---------+----------+ 804 | # | Flow | Next-hop | Interface | Urgency | Distance | 805 | | Identifier | address | address | | | 806 +---+-------------+-------------+--------------+---------+----------+ 807 | 1 | (X) | (A) | eth0 | 4 | 2 | 808 | 2 | (X) | (B) | eth0 | 10 | 3 | 809 | 3 | (X) | (C) | eth0 | 9 | 2 | 810 | 4 | (Y) | (C) | eth0 | 14 | 4 | 811 | 5 | ... | ... | ... | ... | ... | 812 +---+-------------+-------------+--------------+---------+----------+ 814 Table 6: The table of extended routing entries 816 The Urgencies of the computing Router's Flows MAY be set on the basis 817 of the Queue Level Set entries. Following the classical backpressure 818 approach the Urgency for a given Flow and a given next-hop MAY be 819 calculated as the differences of the Flow queue levels on the 820 computing Router and the next-hop Router. Additionally, thanks to 821 the Urgency Set entries the scheduler is able to use the information 822 about the maximum value of Urgency in the neighborhood of the 823 computing node. 825 9. Interoperability with other OLSRv2 Routers 827 An OLSRv2 router running the backpressure extension can interoperate 828 with an OLSRv2 router that does not run this extension. The 829 Backpressure Extension provides functionalities considered as 830 auxiliary. Additional messages are implemented according to 831 [RFC5444] specification. Router which does not support the proposed 832 OLSRv2 protocol extension may simply discard additional information. 834 As for Backpressure Routers, the Router behavior for a case when 835 there is no information about Queue Levels available from Basic 836 OLSRv2 Routers is specified in Section 7.1.4. Same rules apply to 837 Backpressure Routers using different Flow identification (see 838 Section 6.5). The Backpressure Router can use following strategies 839 to effectively use routes of Basic OLSRv2 Routers: 841 o Temporary assuming Basic OLSRv2 Router's Queue Levels, that will 842 make it last candidate for sending to. 844 o Temporary assuming that Basic OLSRv2 Router's Queue Level is 845 average of Neighbor Backpressure Routers Queue Level for 846 particular Flow. 848 10. Values for Parameters and Constants 850 10.1. Message Interval Parameters 852 o QR_INTERVAL := 300 milliseconds 854 o UR_INTERVAL := QR_INTERVAL / 8 856 10.2. Message Validity Times Parameters 858 o UR_HOLD_TIME := UR_INTERVAL x 3 860 o QR_HOLD_TIME := QR_INTERVAL x 3 862 10.3. Hop Limit Parameter 864 o QR_HOPLIMIT := 1 866 o UR_HOPLIMIT := QR_HOPLIMIT 868 10.4. Jitter Time Parameters 870 o QR_MAXJITTER := QR_INTERVAL / 4 872 o UR_MAXJITTER := UR_INTERVAL / 4 874 11. Security Considerations 876 To be elaborated. 878 12. IANA Considerations 880 This specification defines two Message Types, which must be allocated 881 from the "Message Types" registry of [RFC5444]. 883 12.1. Expert Review: Evaluation Guidelines 885 For the registries where an Expert Review is required, the designated 886 expert SHOULD take the same general recommendations into 887 consideration as are specified by [RFC5444]. 889 12.2. Message Types 891 This specification defines two Message Types, to be allocated from 892 the 0-223 range of the "Message Types" namespace defined in 893 [RFC5444], as specified in Table 7. 895 +------+-------------------------+ 896 | Type | Description | 897 +------+-------------------------+ 898 | TBD1 | UR : Urgency report | 899 | TBD2 | QR : Queue Level report | 900 +------+-------------------------+ 902 Table 7: Message Type assignment 904 12.3. Message-Type-specific TLV Type Registries 906 IANA is requested to create a registry for Message-Type-specific 907 Message TLVs for UR messages, in accordance with Section 6.2.1 of 908 [RFC5444], and with initial assignments and allocation policies as 909 specified in Table 8. 911 +-----------+---------+--------------------------+------------------+ 912 | Name | Type | Description | Allocation | 913 | | | | Policy | 914 +-----------+---------+--------------------------+------------------+ 915 | O_URGENCY | 128 | Specifies Router's | | 916 | | | Urgency. | | 917 | | 129-223 | Unassigned | Expert Review | 918 +-----------+---------+--------------------------+------------------+ 920 Table 8: UR Message-Type-specific Message TLVs 922 IANA is requested to create a registry for Message-Type-specific 923 Address block TLVs for UR messages, in accordance with Section 6.2.1 924 of [RFC5444], and with initial assignments and allocation policies as 925 specified in Table 9. 927 +---------+---------+-------------------------------+---------------+ 928 | Name | Type | Description | Allocation | 929 | | | | Policy | 930 +---------+---------+-------------------------------+---------------+ 931 | URGENCY | 128 | Specifies Urgency of | | 932 | | | associated Router. | | 933 | | 129-223 | Unassigned | Expert Review | 934 +---------+---------+-------------------------------+---------------+ 936 Table 9: UR Message-Type-specific Address block TLVs 938 IANA is requested to create a registry for Message-Type-specific 939 Message TLVs for QR messages, in accordance with Section 6.2.1 of 940 [RFC5444], and with initial assignments and allocation policies as 941 specified in Table 10. 943 +---------+-------------+-------------------+ 944 | Type | Description | Allocation Policy | 945 +---------+-------------+-------------------+ 946 | 128-223 | Unassigned | Expert Review | 947 +---------+-------------+-------------------+ 949 Table 10: QR Message-Type-specific Message TLVs 951 IANA is requested to create a registry for Message-Type-specific 952 Address block TLVs for UR messages, in accordance with Section 6.2.1 953 of [RFC5444], and with initial assignments and allocation policies as 954 specified in Table 11. 956 +-------------+---------+------------------------------+------------+ 957 | Name | Type | Description | Allocation | 958 | | | | Policy | 959 +-------------+---------+------------------------------+------------+ 960 | PROTOCOL | 128 | Specifies Protocol Number | | 961 | | | used on the transport layer. | | 962 | QUEUE_LEVEL | 129 | Specifies Queue Level | | 963 | | | status. | | 964 | PORT | 130 | Specifies port address used | | 965 | | | on the transport layer. | | 966 | | 131-223 | Unassigned | Expert | 967 | | | | Review | 968 +-------------+---------+------------------------------+------------+ 970 Table 11: QR Message-Type-specific Address block TLVs 972 13. Acknowledgements 974 This work was partly supported by the grant of Poznan University of 975 Technology DS 45-083/10 and the European Commission OPNEX STREP (FP7- 976 224218, http://opnex.eu). 978 The authors also want to thank the following people for their 979 contributions to this document: 981 o Adam Nowak, Poznan University of Technology, Poland, 982 984 o Przemyslaw Walkowiak, Poznan University of Technology, Poland, 985 987 14. References 989 14.1. Normative References 991 [I-D.dearlove-olsrv2-metrics] 992 Dearlove, C., Clausen, T., and P. Jacquet, "Link Metrics 993 for OLSRv2", draft-dearlove-olsrv2-metrics-05 (work in 994 progress), June 2010. 996 [I-D.ietf-manet-olsrv2] 997 Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized 998 Link State Routing Protocol version 2", 999 draft-ietf-manet-olsrv2-11 (work in progress), April 2010. 1001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1002 Requirement Levels", BCP 14, RFC 2119, March 1997. 1004 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 1005 Considerations in Mobile Ad Hoc Networks (MANETs)", 1006 RFC 5148, February 2008. 1008 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 1009 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 1010 Format", RFC 5444, February 2009. 1012 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 1013 (MANET) Protocols", RFC 5498, March 2009. 1015 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 1016 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 1017 RFC 6130, April 2011. 1019 14.2. Informative References 1021 [I-D.multipath-olsrv2] 1022 Szwabe, A., Nowak, A., Baccelli, E., Yi, J., and B. 1023 Parrein, "Multi-path for Optimized Link State Routing 1024 Protocol version 2", draft-szwabe-manet-multipath-olsrv2 1025 (work in progress), 2010. 1027 [SMN+10] Szwabe, A., Misiorek, P., Nowak, A., and J. Marchwicki, 1028 "Implementation of Backpressure-Based Routing Integrated 1029 with Max-Weight Scheduling in a Wireless Multi-hop 1030 Network", Proc. of 3rd IEEE International Workshop on 1031 Wireless and Internet Services (WISe 2010), Denver, USA, 1032 pages 999-1004, 2010. 1034 Appendix A. Illustrations 1036 A.1. QR Message Examples 1038 This appendix illustrates QR message examples. As QR message is a 1039 instance of [RFC5444] and its exact form depends on conveyed 1040 information formatted by the sender. Because of that following 1041 examples show only possible form that specified information can be 1042 presented. 1044 First example of QR message conveys information about Queue Levels of 1045 two Flows. The Backpressure Router uses complex Flow Identifier 1046 containing: 1048 o Destination address 1050 o Source address 1052 o Internet Protocol Number of a protocol used in the transport layer 1054 o If used, an additional transport protocol source and destination 1055 address (i.e. port addresses in TCP or UDP) 1057 This message contains two information about Flows: 1059 o UDP (17) stream from IP 192.168.40.1:4563 to 192.168.40.67:8213 1061 o ICMP (1) ping requests from 192.168.40.72 to 192.168.40.69 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | 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| 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Originator Address | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 |0 0 0 0 0 0 0 1| Message Sequence Number |0 0 0 0 0 0 0 0| 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 |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| 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Head (192.168.40.) | Mid (.1) | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Mid (.67) |0 0 0 0 0 0 0 0|0 0 0 1 0 0 0 1| PORT TLV | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 |0 0 0 1 0 1|Rsv|0 0 0 0 0 1 0 0| VALUE = UDP SRC PORT (4563) | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | VALUE = UDP DST PORT (8213) | PROTOCOL TLV |0 0 0 1 0 0|Rsv| 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 |0 0 0 0 0 0 0 1| VALUE = 17 |QUEUE_LEVEL TLV|0 0 0 1 0 0|Rsv| 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 |0 0 0 0 0 0 1 1| VALUE = QUEUE LEVEL | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 |0 0 0 0 0 0 1 0|1 0 0 0 0| Rsv |0 0 0 0 0 0 1 1| Head | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Head (cont, 192.168.40.) | Mid (.72) | Mid (.69) | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 |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| 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 |0 0 0 0 0 0 0 1| VALUE = 1 |QUEUE_LEVEL TLV|0 0 0 1 0 0|Rsv| 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 |0 0 0 0 0 1 0 0| VALUE = QUEUE LEVEL | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | VALUE (cont) | 1096 +-+-+-+-+-+-+-+-+ 1098 Figure 1: QR Message example of two Flows with a full Flow 1099 Identifier. 1101 Second example of QR message conveys information about Queue Levels 1102 of two Flows. Origin Backpressure Router uses Flow Identifier 1103 containing only: 1105 o Destination address 1107 o Source address 1109 This message contains two information about Flows: 1111 o IP packets from IP 192.168.40.1 to 192.168.40.67 1113 o IP packets from 192.168.40.72 to 192.168.40.69 1115 0 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | 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| 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Originator Address | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 |0 0 0 0 0 0 0 1| Message Sequence Number |0 0 0 0 0 0 0 0| 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 |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| 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Head (192.168.40.) | Mid (.1) | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Mid (.67) |0 0 0 0 0 0 0 0|0 0 0 1 0 0 1 0|QUEUE_LEVEL TLV| 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 |0 0 0 1 0 0|Rsv|0 0 0 0 0 1 0 0| VALUE = QUEUE LEVEL | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | VALUE (cont) |0 0 0 0 0 0 1 0|1 0 0 0 0| Rsv | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 |0 0 0 0 0 0 1 1| Head (192.168.40.) | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Mid (.72) | Mid (.69) |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 |QUEUE_LEVEL TLV|0 0 0 1 0 0|Rsv|0 0 0 0 0 1 0 0| VALUE | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | VALUE (cont) = QUEUE LEVEL | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 Figure 2: QR Message example of two Flows with a simplified Flow 1144 Identifier. 1146 A.2. UR Message Example 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | 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| 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Originator Address | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Hop Limit | Message Sequence Number |0 0 0 0 0 0 0 0| 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 |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| 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | VALUE = ORIGIN URGENCY LEVEL | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 |0 0 0 0 0 0 0 1|0 0 0 0 0| Rsv | Mid | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Mid (cont) |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | URGENCY TLV |0 0 0 1 0 0|Rsv| VALUE = URGENCY LEVEL | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | VALUE (cont) | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 Figure 3: QR Message Example of one Flow. 1172 Authors' Addresses 1174 Andrzej Szwabe 1175 Poznan University of Technology 1176 5 M. Sklodowskiej-Curie Sq. 1177 60-965 Poznan 1178 Poland 1180 Phone: +48 61 665 3958 1181 Email: Andrzej.Szwabe@put.poznan.pl 1183 Pawel Misiorek 1184 Poznan University of Technology 1185 5 M. Sklodowskiej-Curie Sq. 1186 60-965 Poznan 1187 Poland 1189 Phone: +48 61 665 3958 1190 Email: Pawel.Misiorek@put.poznan.pl 1191 Maciej Urbanski (editor) 1192 Poznan University of Technology 1193 5 M. Sklodowskiej-Curie Sq. 1194 60-965 Poznan 1195 Poland 1197 Phone: +48 61 665 3958 1198 Email: Maciej.Urbanski@put.poznan.pl 1200 Emmanuel Baccelli 1201 INRIA 1203 Phone: +33-169-335-511 1204 Email: Emmanuel.Baccelli@inria.fr 1205 URI: http://www.emmanuelbaccelli.org/