idnits 2.17.1 draft-ietf-roll-protocols-survey-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1025. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1036. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1049. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Expected the document's filename to be given on the first page, but didn't find any Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 515 has weird spacing: '... fail fai...' == Line 516 has weird spacing: '... fail fai...' == Line 517 has weird spacing: '... fail pas...' == Line 518 has weird spacing: '... pass fai...' == Line 519 has weird spacing: '... pass fai...' == (2 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 17, 2008) is 5670 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-low' is mentioned on line 520, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-manet-dymo-14 == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-07 == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-07 == Outdated reference: A later version (-11) exists of draft-ietf-roll-home-routing-reqs-03 == Outdated reference: A later version (-06) exists of draft-ietf-roll-indus-routing-reqs-01 == Outdated reference: A later version (-05) exists of draft-ietf-roll-urban-routing-reqs-01 -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group P. Levis 3 Internet-Draft Stanford University 4 Intended status: Informational A. Tavakoli 5 Expires: April 20, 2009 S. Dawson-Haggerty 6 UC Berkeley 7 October 17, 2008 9 Overview of Existing Routing Protocols for Low Power and Lossy Networks 10 draft-ietf-roll-protocols-survey-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 20, 2009. 37 Abstract 39 Networks of low power wireless devices introduce novel IP routing 40 issues. Low-power wireless devices, such as sensors, actuators and 41 smart objects, have difficult constraints: very limited memory, 42 little processing power, and long sleep periods. As most of these 43 devices are battery-powered, energy efficiency is critically 44 important. Wireless link qualities can vary significantly over time, 45 requiring protocols to make agile decisions yet minimize topology 46 change energy costs. Routing over such low power and lossy networks 47 has novel requirements that existing protocols may not address. This 48 document provides a brief survey of the strengths and weaknesses of 49 existing protocols with respect to this class of networks. From this 50 survey it examines whether existing protocols as described in RFCs 51 and mature drafts could be used without modification in these 52 networks, or whether further work is necessary. 54 Requirements Language 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [RFC2119]. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Suitability Summary . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Formal Definitions . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Table Scalability . . . . . . . . . . . . . . . . . . . . 6 68 4.3. Loss Response . . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. Control Cost . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.5. Link and Node Cost . . . . . . . . . . . . . . . . . . . . 9 71 5. Routing Protocol Taxonomy . . . . . . . . . . . . . . . . . . 9 72 6. Link State Protocols . . . . . . . . . . . . . . . . . . . . . 12 73 6.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.2. OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6.3. TBRPF . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. Distance Vector protocols . . . . . . . . . . . . . . . . . . 13 77 7.1. RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.2. Ad-hoc On Demand Vector Routing (AODV) . . . . . . . . . . 14 79 7.3. DYMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 7.4. DSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 8. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 15 82 8.1. IPv6 Neighbor Discovery . . . . . . . . . . . . . . . . . 15 83 8.2. MANET-NHDP . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 87 12. Annex A - Routing protocol scalability analysis . . . . . . . 16 88 13. Annex B - Logarithmic scaling of control cost . . . . . . . . 19 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 14.1. Normative References . . . . . . . . . . . . . . . . . . . 20 91 14.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 93 Intellectual Property and Copyright Statements . . . . . . . . . . 23 95 1. Terminology 97 AODV: Ad-hoc On Demand Vector Routing 99 DSR: Dynamic Source Routing 101 DYMO: Dynamic Mobile On-Demand 103 LLN: Low power and Lossy Network 105 LSA: Link State Advertisement 107 LSDB: Link State Database 109 MANET: Mobile Ad-hoc Networks 111 MAC: Medium Access Control 113 MPLS: Multiprotocol Label Switching 115 MPR: Multipoint Relays 117 MTU: Maximum Transmission Unit 119 OLSR: Optimized Link State Routing 121 ROLL: Routing in Low power and Lossy Networks 123 TDMA: Time Division Multiple Access 125 2. Introduction 127 Wireless is increasingly important to computer networking. As 128 Moore's Law has reduced computer prices and form factors, networking 129 includes not only servers and desktops, but laptops, palmtops, and 130 cellphones. As computing device costs and sizes have shrunk, small 131 wireless sensors, actuators, and smart objects have emerged as an 132 important next step in inter-networking. The sheer number of the 133 low-power networked devices means that they cannot depend on human 134 intervention (e.g., adjusting position) for good networking: they 135 must have routing protocols that enable them to self-organize into 136 multihop networks. 138 Energy is a fundamental challenge in these devices. Convenience and 139 ease of use requires they be wireless and therefore battery powered. 140 Correspondingly, low power operation is a key concern for this class 141 of networked device. Cost points and energy limitations cause these 142 devices to have very limited resources: a few kB of RAM and a few MHz 143 of CPU is typical. As energy efficiency does not improve with 144 Moore's Law, these limitations are not temporary. This trend towards 145 smaller, lower power, and more numerous devices has led to new low- 146 power wireless link layers to support them. In practice, wireless 147 networks observe much higher loss rates than wired ones do, and low- 148 power wireless is no exception. Furthermore, many of these networks 149 will include powered as well as energy constrained nodes. 150 Nevertheless, for cost and scaling reasons, many of these powered 151 devices will still have limited resources. 153 These low power and lossy networks introduce constraints and 154 requirements that other networks typically do not possess 155 ([I-D.ietf-roll-home-routing-reqs] and 156 [I-D.ietf-roll-indus-routing-reqs]). As they were not designed with 157 these requirements in mind, existing protocols may or may not work 158 well in LLNs. The first step to reaching consensus on a routing 159 protocol for LLNs is to decide which of these two is true. If an 160 existing protocol can meet LLN requirements without any changes, then 161 barring extenuating circumstances, it behooves us to use an existing 162 standard. However, if no current protocol can meet LLN's 163 requirements, then further work will be needed to define and 164 standardize with a protocol that can. Whether or not such a protocol 165 involves modifications to an existing protocol or a new protocol 166 entirely is outside the scope of this document: this document simply 167 seeks to answer the question: do LLNs require a new protocol 168 specification document at all? 170 3. Methodology 172 To answer the question of LLNs require new protocol specification 173 work, this document examines existing routing protocols and how well 174 they can be applied to low power and lossy networks. It provides a 175 set of criteria with which to compare the costs and benefits of 176 different protocol designs and examines existing protocols in terms 177 of these criteria. 179 The five criteria this document uses are derived from a set of drafts 180 that describe the requirements of a few major LLN application 181 scenarios. The five criteria, presented in Section 3, are neither 182 exhaustive nor complete. Instead, they are one specific subset of 183 high-level requirements shared across all of the application 184 requirement drafts. Because every application requirement draft 185 specifies these criteria, then a protocol which does not meet one of 186 them cannot be used without modifications or extensions. However, 187 because these criteria represent a subset of the intersection of the 188 application requirements, any given application domain may impose 189 additional requirements which a particular protocol may not meet. 190 For this reason, these criteria are "necessary but not sufficient." 191 A protocol that does not meet the criteria cannot be used as 192 specified, but it is possible that a protocol meets the criteria yet 193 is not able to meet the requirements of a particular application 194 domain. Nevertheless, a protocol that meets all of the criteria 195 would be very promising, and deserve a closer look and consideration 196 in light of LLN application domains. 198 This document considers "existing routing protocols" to be protocols 199 that are specified in RFCs or, in the cases of DYMO 200 [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very 201 mature draft which will most likely become an RFC. This document 202 does not seek to answer the question of whether there is any protocol 203 anywhere which could meet LLN application requirements. Rather, it 204 seeks to answer whether protocols, as specified in current IETF 205 standards documents, can meet such requirements. If an existing 206 protocol specification can be used unchanged, then writing additional 207 protocol specifications is unnecessary. For example, there are many 208 academic papers and experimental protocol implementations available; 209 while one or more of these may meet LLN requirements, if they are not 210 specified in an RFC then a working group will need to write a new RFC 211 for them to be a standard. The question this document seeks to 212 answer is not whether proposed, evaluated, theoretical or 213 hypothetical protocol designs can satisfy LLN requirements: the 214 question is whether existing IETF standards can. 216 Whether a protocol meets these criteria was judged by thinking 217 through each specification and considering the best implementation 218 possible. The judgement is based on what a specification allows, 219 rather than any particular implementation of that specification. For 220 example, while many DYMO implementations use hopcount as a routing 221 metric, the DYMO specification allows a hop to add more than one to 222 the routing metric, so DYMO as a specification can support some links 223 or nodes being more costly than others. 225 4. Suitability Summary 227 In this section, we present five important requirements for routing 228 in low power and lossy networks, and evaluate protocols against them. 229 This evaluation attempts to take a complicated and interrelated set 230 of design decisions and trade-offs and condense them to a simple 231 "pass", "fail", or "?". As with any simplification, there is a risk 232 of removing some necessary nuance. However, we believe that being 233 forced to take a position on whether or not these protocols are 234 acceptable according to binary criterion will be constructive. 236 We derive these criteria from existing documents that describe ROLL 237 network application requirements. These metrics do not encompass all 238 application requirements. Instead, they are a common set of routing 239 protocol requirements that most applications domains share. 240 Considering this very general and common set of requirements sets a 241 minimal bar for a protocol to be generally applicable. If a protocol 242 cannot meet even these minimalist criteria, then it cannot be used in 243 several major ROLL application domains and so is unlikely to be a 244 good candidate for further analysis and examination. Satisfying 245 these minimal criteria is necessary but not sufficient: they do not 246 represent the complete intersection of application requirements and 247 applications introduce additional, more stringent requirements. But 248 this simplified view provides a first cut of the applicability of 249 existing protocols, and those that do satisfy them might be 250 reasonable candidates for further study. 252 The five criteria are "table scalability", "loss response", "control 253 cost", "link cost", and "node cost". For each of these, the value 254 "pass" indicates that a given protocol has satisfactory performance 255 according to the metric. The value "fail" indicates that the 256 protocol does not have acceptable performance according to the 257 metric, and that the RFC defining the protocol does not, as written, 258 contain sufficient flexibility to alter the protocol to do so. 259 Finally, "?" indicates that an implementation could exhibit 260 satisfactory performance while following the RFC, but that the 261 implementation descisions necessary to do so are not specified and 262 may require some exploration. In other words, a "fail" means a 263 protocol would have to be modified so it is not compliant with its 264 RFC in order to meet the criterion, while a "?" means a protocol 265 would require a supplementary document further constraining and 266 specifying how a protocol should behave. 268 4.1. Formal Definitions 270 To provide precise definitions of these metrics, we use formal big-O 271 notation, where N refers to the number of nodes in the network, D 272 refers to the number of unique destinations, and L refers to the size 273 of a node's local, single-hop neighborhood (the network density). We 274 explain the derivation of each metric from application requirements 275 in its corresponding section. 277 4.2. Table Scalability 279 Scalability support for large networks of sensors is highlighted as a 280 key requirement by all three application requirements documents. 281 Network sizes range from a minimum of 250 nodes in the home routing 282 requirements [I-D.ietf-roll-home-routing-reqs] to very large networks 283 of "tens of thousands to millions" of devices noted of the urban 284 requirements [I-D.ietf-roll-urban-routing-reqs]. Networks are 285 expected to have similar size in industrial settings, the 286 requirements draft states that depths of up to 20 hops are to be 287 expected [I-D.ietf-roll-indus-routing-reqs]. Given that network 288 information maintained at each node is stored in routing and neighbor 289 tables, along with the constrained memory of nodes, necessitates 290 bounds on the size of these tables. 292 This metric examines whether routing tables scale within reasonable 293 memory resources of low-power nodes. According to this metric, 294 routing protocols that scale linearly with the size of the network or 295 a node's neighborhood fail. Scaling with the size of the network 296 prevents networks from growing to reasonable size, while scaling with 297 the network density precludes dense deployments. However, as many 298 low-power and lossy networks behave principally as data collection 299 networks and principally communicate through routers to data 300 collection points in the larger Internet, scaling with the number of 301 such collection points is reasonable. Protocols whose state scales 302 with the number of destinations pass. 304 More precisely, routing table size scaling with O(N) or O(L) fails. 305 A table that scales O(D) (assuming no N or L) passes. 307 4.3. Loss Response 309 In low power and lossy networks, links routinely come and go due to 310 being close to the SINR threshold. It is important that link churn 311 not trigger unnecessary responses by the routing protocol. This 312 point is stressed in all the application requirement documents, 313 pointing to the need to localize response to link failures with no 314 triggering of global network re-optimization, whether for reducing 315 traffic or for maintaining low route convergence times 316 ([I-D.ietf-roll-home-routing-reqs], 317 [I-D.ietf-roll-urban-routing-reqs], and 318 [I-D.ietf-roll-indus-routing-reqs]). The industrial routing 319 requirements draft states that protocols must be able to "recompute 320 paths based on underlying link characteristics which may change 321 dynamically", as well as reoptimize when the device set changes to 322 maintain service requirements. The protocol should also "always be 323 in the process of optimizing the system in response to changing link 324 statistics." Protocols with these properties should take care not to 325 require global updates. 327 A protocol which requires many link changes to propagate across the 328 entire network fails. Protocols which constrain the scope of 329 information propagation to only when they affect routes to active 330 destinations, or to local neighborhoods, pass. Protocols which allow 331 proactively path maintenance pass if the choice of which paths to 332 maintain is user-specified. 334 More precisely, loss responses that require O(N) transmissions fail, 335 while responses that can rely on O(1) local broadcasts or O(D) route 336 updates pass. 338 4.4. Control Cost 340 Battery-operated devices are a critical component of all three 341 application spectrums, and as such special emphasis is placed on 342 minimizing power consumption to achieve long battery lifetime, 343 [I-D.ietf-roll-home-routing-reqs], with multi-year deployments being 344 a common case [I-D.ietf-roll-indus-routing-reqs]. In terms of 345 routing structure, any proposed L2N routing protocol ought to support 346 the autonomous organization and configuration of the network at the 347 lowest possible energy cost [I-D.ietf-roll-urban-routing-reqs]. 349 All routing protocols must transmit additional data to detect 350 neighbors, build routes, transmit routing tables, or otherwise 351 conduct routing. As low-power wireless networks can have very low 352 data rates, protocols which require a minimum control packet rate can 353 have unbounded control overhead. This is particularly true for 354 event-driven networks, which only report data when certain conditions 355 are met. Regions of a network which never meet the condition can be 356 forced to send significant control traffic even when there is no data 357 to send. For these use cases, hard-coded timing constants are 358 unacceptable, because they imply a prior knowledge of the expected 359 data rate. 361 Of course, protocols require the ability to send at least a very 362 small amount of control traffic, in order to discover a topology. 363 But this bootstrapping discovery and maintenance traffic should be 364 small: communicating once an hour is far more reasonable than 365 communicating once a second. So while control traffic should be 366 bounded by data traffic, it requires some leeway to bootstrap and 367 maintain a long-lived yet idle network. 369 In the case of control traffic, the communication rate (sum of 370 transmissions and receptions at a node) is a better measure than the 371 transmission rate (since energy is consumed for both transmissions 372 and receptions). Controlling the transmission rate is insufficient, 373 as it would mean that the energy cost (sum of transmission and 374 receptions) of control traffic could grow with O(L). 376 A protocol fails the control cost criterion if its per-node control 377 traffic (transmissions plus receptions) rate is not bounded by the 378 data rate plus a small constant. For example, a protocol using a 379 beacon rate only passes if it can be turned arbitrarily low, in order 380 to match the data rate. Furthermore, packet losses necessitate that 381 the control traffic may scale within a O(log(L)) factor of the data 382 rate. Meaning, if R is the data rate and e is the small constant, 383 then a protocol's control traffic must be on the order of O(R log(L) 384 + e) to pass this criteria. The details of why O(log(L)) is 385 necessary are in Annex B. 387 4.5. Link and Node Cost 389 These two metrics specify how a protocol chooses routes for data 390 packets to take through the network. Classical routing algorithms 391 typically acknowledge the differing costs of paths and may use a 392 shortest path algorithm to find paths. This is a requirement for low 393 power networks, as links must be evaluated as part of an objective 394 function across various metric types, such as minimizing latency and 395 maximizing reliability [I-D.ietf-roll-indus-routing-reqs]. 397 However, in low power networks it is also desirable to account for 398 the cost of routing through particular routers. Applications require 399 node or parameter constrained routing, which takes into account node 400 properties and attributes such as power, memory, and battery life 401 that dictate a router's willingness or ability to route other 402 packets. Home routing requirements note that devices will vary in 403 their duty cycle, and that routing protocols should prefer nodes with 404 permanent power [I-D.ietf-roll-home-routing-reqs]. The urban 405 requirements note that routing protocols may wish to take advantage 406 of differing data processing and managment capabilities among network 407 devices [I-D.ietf-roll-urban-routing-reqs]. Finally, industrial 408 requirements cite differing lifetime requirements as an important 409 factor to account for [I-D.ietf-roll-indus-routing-reqs]. Node cost 410 refers to the ability for a protocol to incorporate router properties 411 into routing metrics and use node attributes for constraint-based 412 routing. 414 A "pass" indicates that the protocol contains a mechanism allowing 415 these considerations to be considered when choosing routes. 417 5. Routing Protocol Taxonomy 419 Routing protocols broadly fall into two classes: link-state and 420 distance-vector. 422 A router running a link-state protocol first establishes adjacency 423 with its neighbors and then reliably floods the local topology 424 information in the form of a Link State Advertisement packet. The 425 collection of LSAs constitutes the Link State Database (LSDB) that 426 represents the network topology, and routers synchronize their LSDBs. 428 Thus each node in the network has a complete view of the network 429 topology. Each router uses the LSDB to compute a routing table where 430 each entry (reachable IP destination address) points to the next hop 431 along the shortest path according to some metric. Link state 432 protocols (such as OSPF and IS-IS) support the concept of area 433 (called "level" for IS-IS) whereby all the routers in the same area 434 share the same view (they have the same LSDB) and areas are 435 interconnected by border routers according to specific rules that 436 advertise IP prefix reachability between areas. 438 A distance vector protocol exchanges routing information rather than 439 topological information. A router running a distance vector protocol 440 exchanges information with its "neighbors" with which it has link 441 layer connectivity. Tunneling and similar mechanisms can virtualize 442 link layer connectivity to allow neighbors that are multiple layer 2 443 hops away. Rather than a map of the network topology from which each 444 router can calculate routes, a distance vector protocol node has 445 information on what routes its neighbors have. Each node's set of 446 available routes is the union of its neighbors routes plus a route to 447 itself. In a distance vector protocol, nodes may only advertise 448 routes which are in use, enabling on-demand discovery. In comparison 449 to link state protocols, distance vector protocols have the advantage 450 of only requiring neighbor routing information, but also have 451 corresponding limitations which protocols must address, such as 452 routing loops, count to infinity, split horizon, and slow convergence 453 times. Furthermore, routing constraints are difficult to enforce 454 with distance vector protocols. 456 Neighbor discovery is a critical component of any routing protocol. 457 It enables a protocol to learn about which other nodes are nearby and 458 which it can use as the next hop for routes. As neighbor discovery 459 is a key component of many protocols, several general protocols and 460 protocol mechanisms have been designed to support it. A protocol's 461 neighbor set is defined by how many "hops" away the set reaches. For 462 example, the 1-hop neighbor set of a node is all nodes it can 463 directly communicate with at the link layer, while the 2-hop neighbor 464 set is its own 1-hop neighbor set and the 1-hop neighbor sets of all 465 of its 1-hop neighbors. 467 Because nodes often have very limited resources for storing routing 468 state, protocols cannot assume that they can store complete neighbor 469 information. For example, a node with 4kB of RAM cannot store full 470 neighbor state when it has 1000 other nodes nearby. This means that 471 ROLL protocols must have mechanisms to decide which of many possible 472 neighbors they monitor as routable next hops. For elements such as 473 2-hop neighborhoods, these decisions can have a significant impact on 474 the topology that other nodes observe, and therefore may require 475 intelligent logic to prevent effects such as network partitions. 477 Protocols Today 479 Wired networks draw from both approaches. OSPF or IS-IS, for 480 example, are link-state protocols, while RIP is a distance-vector 481 protocol. 483 MANETs similarly draw from both approaches. OLSR is a link-state 484 protocol, while AODV and DYMO are distance vector protocols. The 485 general consensus in core networks is to use link state routing 486 protocols as IGPs for a number of reasons: in many cases having a 487 complete network topology view is required to adequately compute the 488 shortest path according to some metrics. For some applications such 489 as MPLS Traffic Engineering it is even required to have the knowledge 490 of the Traffic Engineering Database for constraint based routing. 492 Furthermore link state protocols typically have superior convergence 493 speeds (ability to find an alternate path in case of network element 494 failure), are easier to debug and troubleshoot, and introduce less 495 control packet overhead than distance vector protocols. In contrast, 496 distance vector protocols are simpler, require less computation, and 497 have smaller storage requirements. Most of these tradeoffs are 498 similar in wireless networks, with one exception. Because wireless 499 links can suffer from significant temporal variation, link state 500 protocols can have higher traffic loads as topology changes must 501 propagate globally, while in a distance vector protocol a node can 502 make local routing decisions with no effect on the global routing 503 topology. One major protocol, DSR, does not easily fit into one of 504 these two classes. Although it is a distance vector protocol, DSR 505 has several properties that make it differ from most other protocols 506 in this class. We examine these differences in our discussion of 507 DSR. 509 The next two sections summarize several well established routing 510 protocols. This table shows, based on the criteria described above, 511 whether these protocols meet ROLL criteria. Annex A contains the 512 reasoning behind each value in the table. 514 Protocol Table Loss Control Link Cost Node Cost 515 OSPF fail fail fail pass fail 516 OLSRv2 fail fail fail pass pass 517 TBRPF fail pass fail pass ? 518 RIP pass fail pass ? fail 519 AODV pass fail pass fail fail 520 DYMO[-low] pass fail pass ? fail 521 DSR fail pass pass fail fail 523 6. Link State Protocols 525 6.1. OSPF 527 OSPF (specified in [RFC2328] for IPv4 and in [RFC2740] for IPv6)) is 528 a link state protocol designed for routing within an Internet 529 Autonomous System (AS). OSPF provides the ability to divide a 530 network into areas, which can establish a routing hierarchy. The 531 topology within an area is hidden from other areas and IP prefix 532 reachability across areas (inter-area routing) is provided using 533 summary LSAs. The hierarchy implies that there is a top-level 534 routing area (the backbone area) which connects other areas. Areas 535 may be connected to the back-bone area through a virtual link. OSPF 536 maintains routing adjacencies by sending hello messages. OSPF 537 calculates the shortest path to a node using link metrics (that may 538 reflect the link bandwidth, propagation delay, ...). OSPF Traffic 539 Engineering (OSPF-TE, [RFC3630]) extends OSPF to include information 540 on reservable, unreserved, and available bandwidth. 542 6.2. OLSR 544 Optimized Link State Routing (OLSR) (see [RFC3626] and 545 [I-D.ietf-manet-olsrv2]) is a link state routing protocol for 546 wireless mesh networks. OLSR nodes flood route discovery packets 547 throughout the entire network, such that each node has a map of the 548 mesh topology. Because link variations can lead to heavy flooding 549 traffic when using a link state approach, OLSR establishes a topology 550 for minimizing this communication. Each node maintains a set of 551 nodes called its Multipoint Relays (MPR), which is a subset of the 552 one-hop neighbors whose connectivity covers the two-hop neighborhood. 553 Each node that is an MPR maintains a set called its MPR selectors, 554 which are nodes that have chosen it to be an MPR. 556 OLSR uses these two sets to apply three optimizations. First, only 557 MPRs generate link state information. Second, nodes can use MPRs to 558 limit the set of nodes that forward link state packets. Third, an 559 MPR, rather than advertise all of its links, can advertise only links 560 to its MPR selectors. Together, these three optimizations can 561 greatly reduce the control traffic in dense networks, as the number 562 of MPRs should not increase significantly as a network becomes 563 denser. 565 OLSR selects routes based on hop counts, and assumes an underlying 566 protocol that determines whether a link exists between two nodes. 567 OLSR's constrained flooding allows it to quickly adapt to and 568 propagate topology changes. 570 OLSR is closely related to clustering algorithms in the wireless 571 sensor networking literature, in which cluster heads are elected such 572 that routing occurs over links between cluster heads and all other 573 nodes are leafs that communicate to a cluster head. 575 6.3. TBRPF 577 Topology Dissemination Based on Reverse Path Forwarding (see 578 [RFC3684]) is another proactive link state protocol. TBRPF computes 579 a source tree, which provides routes to all reachable nodes. It 580 reduces control packet overhead by having nodes only transmit a 581 subset of their source tree as well as by using differential updates. 583 The major difference between TBRPF and OLSR is the routing data that 584 nodes advertise and who chooses to aggregate information. In OLSR, 585 nodes select neighbors to be MPRs and advertise their link state for 586 them; in TBRPF, nodes elect themselves to advertise relevant link 587 state based on whether it acts as a next hop. 589 7. Distance Vector protocols 591 7.1. RIP 593 The Routing Information Protocol (RIP) (defined in [RFC2453]) 594 predates OSPF. As it is a distance vector protocol, routing loops 595 can occur and considerable work has been done to accelerate 596 convergence since the initial RIP protocols were introduced. RIP 597 measures route cost in terms of hops, and detects routing loops by 598 observing a route cost approach infinity where "infinity" is referred 599 to as a maximum number of hops. RIP is typically not appropriate for 600 situations where routes need to be chosen based on real-time 601 parameters such as measured delay, reliability, or load or when the 602 network topology needs to be known for route computation. 604 "Triggered RIP" (defined in [RFC2091]) was originally designed to 605 support "on-demand" circuits. The aim of triggered RIP is to avoid 606 systematically sending the routing database on regular intervals. 608 Instead, triggered RIP sends the database when there is a routing 609 update or a next hop adjacency change: once neighbors have exchanged 610 their routing database, only incremental updates need to be sent. 611 Because incremental updates cannot depend on periodic traffic to 612 overcome loses, triggered RIP uses acknowledgment based mechanisms 613 for reliable delivery. 615 7.2. Ad-hoc On Demand Vector Routing (AODV) 617 AODV (specified in [RFC3561]) is a distance vector protocol intended 618 for mobile ad-hoc networks. When one AODV node requires a route to 619 another, it floods a request in the network to discover a route. A 620 depth-scoped flooding process avoids discovery from expanding to the 621 most distant regions of the network that are in the opposite 622 direction of the destination. AODV chooses routes that have the 623 minimum hop count. 625 If an AODV route request reaches a node that has a route to the 626 destination (this includes the destination itself), that node sends a 627 reply along the reverse route. All nodes along the reverse route can 628 cache the route. When routes break due to topology changes, AODV 629 floods error messages and issues a new request. Because AODV is on- 630 demand it only maintains routes for active nodes. When a link 631 breaks, AODV issues a Route Error (RERR) and a new route request 632 message (RREQ), with a higher sequence number so nodes do not respond 633 from their route caches. These packets can flood the entire network, 634 giving loss response a fail. 636 7.3. DYMO 638 Dynamic Mobile On-Demand routing (DYMO) ([I-D.ietf-manet-dymo]) is an 639 evolution of AODV. The basic functionality is the same, but it has 640 different packet formats, handling rules, and supports path 641 accumulation. Path accumulation allows a single DYMO route request 642 to generate routes to all nodes along the route to that destination. 643 Like AODV, DYMO uses hop counts as its routing metric, but links may 644 have a cost >= 1, allowing DYMO to represent link costs. Like AODV, 645 on link breaks DYMO issues a new route request message (RREQ), with a 646 higher sequence number so nodes do not respond from their route 647 caches. Correspondingly, a route request can flood the entire 648 network. 650 7.4. DSR 652 Dynamic Source Routing ([RFC4728]) is a distance vector protocol, but 653 a DSR packet source explicitly specifies the route for each packet. 654 Because the route is determined at a single place -- the source -- 655 DSR does not require sequence numbers or other mechanisms to prevent 656 routing loops, as there is no problem of inconsistent routing tables. 657 Unlike AODV and DYMO, by pushing state into packet headers, DSR does 658 not require per-destination routing state. Instead, a node 659 originating packets only needs to store a spanning tree of the part 660 of the network it is communicating with. 662 8. Neighbor Discovery 664 A limit on maintained routing state (light footprint) prevents ROLL 665 protocols from assuming they know all 1-hop, 2-hop, or N-hop 666 neighbors. For this reason, while protocols such as MANET-NHDP 667 ([I-D.ietf-manet-nhdp]) and IPv6's neighbor discovery ([RFC4861]) 668 provide basic mechanisms for discovering link-layer neighbors, not 669 all of their features are relevant. This section describes these two 670 protocols, their capabilities, and how ROLL protocols could leverage 671 them. 673 8.1. IPv6 Neighbor Discovery 675 IPv6 neighbor discovery provides mechanisms for nodes to discover 676 single-hop neighbors as well as routers that can forward packets past 677 the local neighborhood. There is an implicit assumption that the 678 delegation of whether a node is a router or not is static (e.g., 679 based on a wired topology). The fact that all routers must respond 680 to a Router Solicitation requires that the number of routers with a 681 1-hop neighborhood is small, or there will be a reply implosion. 682 Furthermore, IPv6 neighbor discovery's support of address 683 autoconfiguration assumes address provisioning, in that addresses 684 reflect the underlying communication topology. IPv6 neighbor 685 discovery does not consider asymmetric links. Nevertheless, it may 686 be possible to extend and adapt IPv6's mechanisms to wireless in 687 order to avoid response storms and implosions. 689 8.2. MANET-NHDP 691 The MANET Neighborhood Discovery Protocol (MANET-NHDP) provides 692 mechanisms for discovering a node's symmetric 2-hop neighborhood. It 693 maintains information on discovered links, their interfaces, status, 694 and neighbor sets. MANET-NHDP advertises a node's local link state; 695 by listening to all of its 1-hop neighbor's advertisements, a node 696 can compute its 2-hop neighborhood. MANET-NHDP link state 697 advertisements can include a link quality metric. MANET-NHDP's node 698 information base includes all interface addresses of each 1-hop 699 neighbor: for low-power nodes, this state requirement can be 700 difficult to support. 702 9. Security Considerations 704 This document presents, considers, and raises no security 705 considerations. 707 10. IANA Considerations 709 This document includes no request to IANA. 711 11. Acknowledgements 713 12. Annex A - Routing protocol scalability analysis 715 This aim of this Annex is to provide the details for the analysis 716 routing scalability analysis. 718 "OSPF" 720 OSPF floods link state through a network. Each router must receive 721 this complete link set. OSPF fails the table size criterion because 722 it requires each router to discover each link in the network, for a 723 total routing table size which is O(N * L). This also causes it to 724 fail the control cost criterion, since this information must be 725 propagated. Furthermore, changes in the link set require re-flooding 726 the network link state even if the changed links were not being used. 727 Since link state changes in wireless networks are often uncorrelated 728 with data traffic and are instead caused by external (environmental) 729 factors, this causes OSPF to fail both the control cost and loss 730 response criteria. OSPF routers can impose policies on the use of 731 links and can consider link properties (Type of Service), as the cost 732 associated with an edge is configurable by the system administrator 733 [RFC2328], so receive a pass for link cost. However, there is no way 734 to associate metrics with routers (as costs are only applied to 735 outgoing interfaces, i.e. edges) when computing paths, and so fails 736 the node cost criteria. While [RFC3630] discusses paths that take 737 into account node attributes, it specifically states that no known 738 algorithm or mechanism currently exists for incoporating this into 739 the OSPF RFC. 741 "OLSRv2" 743 OLSRv2 is a proactive link state protocol, flooding this information 744 through a set of multipoint relays (MPRs). Routing state includes 745 1-hop neighbor information for each node in the network, 1-hop and 746 2-hop information for neighbors (for MPR selection), and a routing 747 table (consisting of destination, and next hop), resulting in state 748 proportional to network size and density (O(N*L + L^2)), and failing 749 the table scalability criteria. 751 Unacceptable control traffic overhead arises from flooding and 752 maintenance. HELLO messages are periodically broadcast local beacon 753 messages, but TC messages spread topology information throughout the 754 network (using MPRs). As such, control traffic is proportional to 755 O(N^2). MPRs reduce this load to O(N^2 / L). As the number of MPRs 756 is inversely proportional to the density of the network and L is 757 bounded by N, this means control traffic is at best proportional to 758 O(N), and fails the control cost metric. 760 Furthermore, changes in the link set require immediately re-flooding 761 the network link state even if those links were not being used by 762 routing, which fails the loss response metric. 764 OLSR allows for specification of link quality, and also provides a 765 'Willingness' metric to symbolize node cost, giving it a pass for 766 both those metrics. 768 "TBRPF" 770 As a link state protocol where each node maintains a database of the 771 entire network topology, TBRPF's routing table size scales with 772 network size and density, leading to table sizes which are O(N * L) 773 when a node receives disjoint link sets from its neighbors. This 774 causes the protocol to fail the table size criteria. The protocol's 775 use of differential updates should allow both fast response time and 776 incremental changes once the distributed database of links has been 777 established. Differential updates are only used to reduce response 778 time to changing network conditions, not to reduce the amount of 779 topology information sent, since each node will periodically send 780 their piece of the topology. As a result, TBRPF fails the control 781 overhead criteria. However, its differential updates triggered by 782 link failure do not immediately cause a global re-flooding of state 783 (but only to affected routers) [RFC3684], leading to a pass for loss 784 response. 786 TBRPF has a flexible neighbor management layer which enables it to 787 incorporate various types of link metrics into its routing decision 788 by enabling a USE_METRIC flag [RFC3684]. As a result, it receives a 789 pass for link cost. It also provides a mechanism whereby routers can 790 maintain multiple link metrics to a single neighbor, some of which 791 can be advertised by the neighbor router [RFC3684]. Although the RFC 792 does not specify a policy for using these values, developing one 793 could allow TBRPF to satisfy this requirement, leading to a ? for the 794 node cost requirement. 796 "RIP" 798 RIP is a distance vector protocol: all routers maintain a route to 799 all other routers. Routing table size is therefore O(N). However, 800 if destinations are known apriori, table size can be reduced to O(D), 801 resulting in a pass for table scalability. While standard RIP 802 requires each node broadcast a beacon per period, and that updates 803 must be propagated by affected nodes, triggered RIP only sends 804 updates when network conditions change in response to the data path, 805 so RIP passes the control cost metric. Loss triggers updates, only 806 propagating if part of a best route, but even if the route is not 807 actively being used, resulting in a fail for loss response. The rate 808 of triggered updates is throttled, and these are only differential 809 updates, yet this still doesn't account for other control traffic (or 810 tie it to data rate) or prevent the triggered updates from being 811 flooded along non-active paths. [RFC2453] 813 RIP receives a ? for link cost because while current implementations 814 focus on hop count and that is the metric used in [RFC2453], the RFC 815 also mentions that more complex metrics such as differences in 816 bandwidth and reliability could be used. However, the RFC also 817 states that real-time metrics such as link-quality would create 818 instability and the concept of node cost only appears as metrics 819 assigned to external networks. While RIP has the concept of a 820 network cost, it is insufficient to describe node properties and so 821 RIP fails the node cost criterion.. 823 "AODV" 825 AODV table size is a function of the number of communicating pairs in 826 the network, scaling with O(D). This is acceptable and so AODV 827 passes the table size criteria. As an on-demand protocol, AODV does 828 not generate any traffic until data is sent, and so control traffic 829 is correlated with the data and so it receives a pass for control 830 traffic. When a broken link is detected, AODV will use a precursor 831 list maintained for each destination to inform downstream routers 832 (with a RERR) of the topology change. However, the RERR message is 833 forwarded by all nodes that have a route that uses the broken link, 834 even if the route is not currently active, leading to a fail for loss 835 response [RFC3561]. 837 AODV fails the link cost metric because the only metric used is hop 838 count, and this is hardcoded in the route table entry, according to 839 the RFC [RFC3561]. It fails the node cost requirement because there 840 is no way for a router to indicate its [lack of] willingness to route 841 while still adhering to the RFC. 843 "DYMO/DYMO-low" 844 The design of DYMO shares much with AODV, with some changes to remove 845 precursor lists and compact various messages. It still passes the 846 table size criteria because it only maintains routes requested by 847 RREQ messages, resulting in O(D) table size. Control traffic (RREQ, 848 RREP, and RREQ) are still driven by data, and hence DYMO passes the 849 control cost criterion. However, RERR messages are forwarded by any 850 nodes that have a route using the link, even if inactive, leading to 851 a fail of the loss reponse criteria [I-D.ietf-manet-dymo]. 853 While DYMO does indicate that the metric used for a link can vary 854 from 1-65535, it specifically refers to this as distance, which is 855 incremented by at least one at each hop [I-D.ietf-manet-dymo], 856 leading to a ? in link cost. While additional routing information 857 can be added DYMO messages, there is no mention of node cost, leading 858 to a fail in node cost. 860 "DSR" 862 DSR performs on-demand route discovery, and source routing of 863 packets. It maintains a source route for all destinations, and also 864 a blacklist of all unidirectional neighbor links [RFC4728], leading 865 to a total table size of O(D + L), failing the table size criterion. 866 Control traffic is completely data driven, and so DSR receives a pass 867 for this criteria. Finally, a transmission failure only prompts an 868 unreachable destination to be sent to the source of the message, 869 passing the loss response criteria. 871 DSR fails the link cost criterion because its source routes are 872 advertised only in terms of hops, such that all advertised links are 873 considered equivalent. DSR also fails the node cost criterion 874 because a node has no way of indicating its willingness to serve as a 875 router and forward messages. 877 13. Annex B - Logarithmic scaling of control cost 879 To satisfy the control cost criterion, a protocol's control traffic 880 communication rate must be bounded by the data rate, plus a small 881 constant. That is, if there is a data rate R, the control rate must 882 O(R + e), where e is a very small constant (epsilon). Furthermore, 883 the control rate may grow logarithmically with the size of the local 884 neighborhood L. Note that this is a bound: it represents the most 885 traffic a protocol may send, and good protocols may send much less. 886 So the control rate is bounded by O(R log(L)) + e. 888 The logarithmic factor comes from the fundamental limits of any 889 protocol that maintains a communication rate. For example, consider 890 e, the small constant rate of communication traffic allowed. Since 891 this rate is communication, to maintain O(e), then only one in L 892 nodes may transmit per time interval defined by e: that one node has 893 a transmission, and all other nodes have a reception, which prevents 894 them from transmitting. However, wireless networks are lossy. 895 Suppose that the network has a 10% packet loss rate. Then if L=10, 896 the expectation is that one of the nodes will drop the packet. Not 897 hearing a transmission, it will think it can transmit. This will 898 lead to 2 transmissions. If L=100, then one node will not hear the 899 first two transmissions, and there will be 3. The number of 900 transmissions, and the communication rate, will grow with O(log(L)). 902 This logarithmic bound can be prevented through explicit coordination 903 (e.g., leader election), but such approaches assumes state and 904 control traffic to elect leaders. As a logarithmic factor in terms 905 of density is not a large stumbling or major limitation, allowing the 906 much greater protocol flexibility it enables is worth its small cost. 908 14. References 910 14.1. Normative References 912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 913 Requirement Levels", BCP 14, RFC 2119, March 1997. 915 14.2. Informative References 917 [I-D.ietf-manet-dymo] 918 Chakeres, I. and C. Perkins, "Dynamic MANET On-demand 919 (DYMO) Routing", draft-ietf-manet-dymo-14 (work in 920 progress), June 2008. 922 [I-D.ietf-manet-nhdp] 923 Clausen, T., Dearlove, C., and J. Dean, "MANET 924 Neighborhood Discovery Protocol (NHDP)", 925 draft-ietf-manet-nhdp-07 (work in progress), July 2008. 927 [I-D.ietf-manet-olsrv2] 928 Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized 929 Link State Routing Protocol version 2", 930 draft-ietf-manet-olsrv2-07 (work in progress), July 2008. 932 [I-D.ietf-roll-home-routing-reqs] 933 Brandt, A., Buron, J., and G. Porcu, "Home Automation 934 Routing Requirement in Low Power and Lossy Networks", 935 draft-ietf-roll-home-routing-reqs-03 (work in progress), 936 September 2008. 938 [I-D.ietf-roll-indus-routing-reqs] 939 Networks, D., Thubert, P., Dwars, S., and T. Phinney, 940 "Industrial Routing Requirements in Low Power and Lossy 941 Networks", draft-ietf-roll-indus-routing-reqs-01 (work in 942 progress), July 2008. 944 [I-D.ietf-roll-urban-routing-reqs] 945 Dohler, M., Watteyne, T., Winter, T., Jacquenet, C., 946 Madhusudan, G., Chegaray, G., and D. Barthel, "Urban WSNs 947 Routing Requirements in Low Power and Lossy Networks", 948 draft-ietf-roll-urban-routing-reqs-01 (work in progress), 949 July 2008. 951 [RFC2091] Meyer, G. and S. Sherry, "Triggered Extensions to RIP to 952 Support Demand Circuits", RFC 2091, January 1997. 954 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 956 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 957 November 1998. 959 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 960 RFC 2740, December 1999. 962 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 963 Demand Distance Vector (AODV) Routing", RFC 3561, 964 July 2003. 966 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 967 Protocol (OLSR)", RFC 3626, October 2003. 969 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 970 (TE) Extensions to OSPF Version 2", RFC 3630, 971 September 2003. 973 [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology 974 Dissemination Based on Reverse-Path Forwarding (TBRPF)", 975 RFC 3684, February 2004. 977 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 978 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 979 IPv4", RFC 4728, February 2007. 981 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 982 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 983 September 2007. 985 Authors' Addresses 987 Philip Levis 988 Stanford University 989 358 Gates Hall, Stanford University 990 Stanford, CA 94305-9030 991 USA 993 Email: pal@cs.stanford.edu 995 Arsalan Tavakoli 996 UC Berkeley 997 Soda Hall, UC Berkeley 998 Berkeley, CA 94707 999 USA 1001 Email: arsalan@eecs.berkeley.edu 1003 Stephen Dawson-Haggerty 1004 UC Berkeley 1005 Soda Hall, UC Berkeley 1006 Berkeley, CA 94707 1007 USA 1009 Email: stevedh@cs.berkeley.edu 1011 Full Copyright Statement 1013 Copyright (C) The IETF Trust (2008). 1015 This document is subject to the rights, licenses and restrictions 1016 contained in BCP 78, and except as set forth therein, the authors 1017 retain all their rights. 1019 This document and the information contained herein are provided on an 1020 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1021 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1022 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1023 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1024 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1025 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1027 Intellectual Property 1029 The IETF takes no position regarding the validity or scope of any 1030 Intellectual Property Rights or other rights that might be claimed to 1031 pertain to the implementation or use of the technology described in 1032 this document or the extent to which any license under such rights 1033 might or might not be available; nor does it represent that it has 1034 made any independent effort to identify any such rights. Information 1035 on the procedures with respect to rights in RFC documents can be 1036 found in BCP 78 and BCP 79. 1038 Copies of IPR disclosures made to the IETF Secretariat and any 1039 assurances of licenses to be made available, or the result of an 1040 attempt made to obtain a general license or permission for the use of 1041 such proprietary rights by implementers or users of this 1042 specification can be obtained from the IETF on-line IPR repository at 1043 http://www.ietf.org/ipr. 1045 The IETF invites any interested party to bring to its attention any 1046 copyrights, patents or patent applications, or other proprietary 1047 rights that may cover technology that may be required to implement 1048 this standard. Please address the information to the IETF at 1049 ietf-ipr@ietf.org.