idnits 2.17.1 draft-ietf-roll-trickle-mcast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 515 has weird spacing: '... act chg ...' -- The document date (April 11, 2011) is 4763 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'M' is mentioned on line 501, but not defined == Unused Reference: 'I-D.ietf-roll-rpl' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 564, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-levis-roll-trickle (ref. 'I-D.levis-roll-trickle') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-05 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL J. Hui 3 Internet-Draft Cisco 4 Intended status: Standards Track R. Kelsey 5 Expires: October 13, 2011 Ember Corporation 6 April 11, 2011 8 Multicast Forwarding Using Trickle 9 draft-ietf-roll-trickle-mcast-00 11 Abstract 13 Low power and Lossy Networks (LLNs) are typically composed of 14 resource constrained nodes communicating over links that have dynamic 15 characteristics. Memory constraints coupled with temporal variations 16 in link connectivity makes the use of topology maintenance to support 17 IPv6 multicast challenging. This document describes the use of 18 Trickle to efficiently forward multicast messages without the need 19 for topology maintenance. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 13, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Trickle Multicast Parameters . . . . . . . . . . . . . . . . . 7 60 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.1. Trickle Multicast Option . . . . . . . . . . . . . . . . . 9 62 5.2. Trickle ICMPv6 Message . . . . . . . . . . . . . . . . . . 10 63 5.2.1. Sequence List . . . . . . . . . . . . . . . . . . . . 11 64 6. Trickle Multicast Forwarder Behavior . . . . . . . . . . . . . 12 65 6.1. Managing Sliding Windows . . . . . . . . . . . . . . . . . 12 66 6.2. Trickle Timers . . . . . . . . . . . . . . . . . . . . . . 12 67 6.3. Trickle Multicast Option Processing . . . . . . . . . . . 13 68 6.4. Trickle ICMP Processing . . . . . . . . . . . . . . . . . 13 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 The resource constraints of Low power and Lossy Networks (LLNs) may 80 preclude the use of existing IPv6 multicast forwarding mechanisms. 81 Such networks are typically constrained in resources (limited channel 82 capacity, processing power, energy capacity, memory). In particular 83 memory constraints may limit nodes to maintaining state for only a 84 small subset of neighbors. Limited channel and energy capacity 85 require protocols to remain efficient and robust even in dense 86 topologies. 88 Traditional IP multicast forwarding typically relies on topology 89 maintenance mechanisms to efficiently forward multicast messages to 90 the intended destinations. In some cases, topology maintenance 91 involves maintaining multicast trees to reach all subscribers of a 92 multicast group. Maintaining such topologies is difficult especially 93 when memory constraints are such that nodes can only maintain a 94 default route. Dynamic properties of wireless networks can make 95 control traffic prohibitively expensive. In wireless environments, 96 topology maintenance may involve selecting a connected dominating set 97 used to forward multicast messages to all nodes in an administrative 98 domain. However, existing mechanisms often require two-hop topology 99 information, which is more state than a LLN node may be able to 100 handle. 102 This document describes the use of Trickle for IPv6 multicast 103 forwarding in LLNs. Trickle provides a mechanism for controlled, 104 density-aware flooding without the need to maintain a forwarding 105 topology [I-D.levis-roll-trickle]. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Terminology 115 Trickle Multicast Message A IPv6 multicast datagram that includes a 116 Trickle Multicast option in the IPv6 Hop-by-Hop 117 Options header. 119 Trickle Multicast Forwarder A IPv6 router that can process a Trickle 120 Multicast option and follows the forwarding rules 121 specified in this document. 123 Trickle Multicast Domain An administrative domain that defines the 124 scope of Trickle dissemination. All routers 125 within a Trickle Multicast Domain participate in 126 the same dissemination process. 128 Seed The router that starts the dissemination process 129 for a Trickle multicast message. The Seed may be 130 different than the node identified by the IPv6 131 Source address of the multicast message. 133 3. Overview 135 Trickle multicast forwarding implements a controlled, density-aware 136 flood to disseminate a IPv6 multicast message to all nodes within a 137 Trickle Multicast Domain. The basic process is similar to 138 traditional flooding - nodes forward newly received multicast 139 messages using link-layer broadcasts. Nodes maintain state of 140 recently received multicast messages to detect duplicates and ensure 141 that each node receives at most one copy of each multicast message. 143 Each Trickle multicast message carries a Trickle Multicast option 144 that includes a SeedID and Sequence value. The SeedID uniquely 145 identifies the Seed that initiated the message's dissemination 146 process within the Trickle Multicast Domain. Note that the Seed does 147 not have to be the same node as the message's source. It is possible 148 to tunnel a multicast message to a Seed node and start the 149 dissemination process from a different node within the Trickle 150 Multicast Domain. 152 The Sequence value establishes a total ordering of multicast messages 153 disseminated by SeedID. Nodes maintain a sliding window of recently 154 received multicast messages for each SeedID. The sliding window 155 establishes what messages can be received and ensure at most one copy 156 of each multicast message is received. Messages with sequence values 157 lower than the lower bound of the window MUST be ignored. Messages 158 with sequence values stored within the sliding window MUST be 159 ignored. All other messages MUST be received, advancing the sliding 160 window if necessary. Larger sequence values always take precedence. 161 The sliding window can be of variable size, trading memory 162 requirements for reliability of disseminating multiple messages 163 simultaneously. 165 Trickle's density-aware properties come from its suppression 166 mechanism. When suppression is enabled, nodes periodically advertise 167 a summary of recently received multicast messages. These 168 advertisements allow nodes to determine if they have any additional 169 multicasts to offer to neighboring nodes. A multicast message is 170 only retransmitted upon receiving positive indication that a neighbor 171 has not yet received that multicast message. 173 Nodes suppress advertisement transmissions and multicast 174 retransmissions after recently receiving "consistent" advertisements. 175 A node determines that a neighbor's advertisement is "consistent" 176 when neither node has new multicast messages to offer to the other. 177 The suppression reduces the number of redundant transmissions and is 178 what allows Trickle to maintain low channel utilization in dense 179 environments. However, suppression trades low control overhead for 180 longer propagation times. When using suppression, Trickle's 181 propagation times often have a long-tail distribution. 183 Trickle provides an adaptive timer, called the Trickle timer. When 184 receiving an "inconsistent" advertisement, nodes reset the Trickle 185 timer period to a small period so that dissemination happens quickly. 186 The Trickle timer period doubles when the period expires and no 187 "inconsistent" advertisements have been received, reducing control 188 overhead when the network is in a consistent state. 190 This document does allow configurations that disable the suppression 191 mechanism, reducing Trickle Multicast Forwarding to simple flooding. 192 This can be done by setting the suppression threshold for received 193 "consistent" advertisements to infinity. In this mode, Trickle 194 advertisements are not sent since consistency checks are not 195 performed. Instead, nodes simply retransmit multicast messages they 196 are trying to forward. 198 4. Trickle Multicast Parameters 200 All Trickle multicast forwarders within a Trickle multicast domain 201 MUST be configured with two sets of configurations (one for each 202 value of the M flag). Each configuration has five parameters: 204 Imin The minimum Trickle timer interval as defined in 205 [I-D.levis-roll-trickle]. 207 Imax The maximum Trickle timer interval as defined in 208 [I-D.levis-roll-trickle]. 210 k The redundancy constant as defined in 211 [I-D.levis-roll-trickle]. 213 Tactive The duration that a multicast forwarder can 214 attempt to forward a multicast message. 215 Specified in units of Imax. 217 Tdwell The duration that a multicast forwarder must 218 maintain sliding window state for SeedID after 219 receiving the last multicast message from SeedID. 220 Specified in units of Imax. 222 Tactive specifies the time duration that a node may retransmit a 223 multicast message in attempt to forward it to neighboring nodes. 224 Larger values of Tactive increases the number of retransmissions and 225 overall dissemination reliability. 227 Tdwell specifies the time duration for maintaining sliding window 228 state to ensure that a multicast message from SeedID is received at 229 most once. Larger values of Tdwell decreases the likelihood that a 230 node will receive a multicast message more than once. 232 The specific values are left out of scope of this document as they 233 are dependent on link-specific properties. How those parameters are 234 configured are also left out of scope. 236 The Trickle multicast parameters allow both aggressive and 237 conservative multicast forwarding strategies. For example, an 238 aggressive strategy may specify each multicast forwarder to 239 retransmit any newly received message 3 times on a short fixed period 240 and maintain state for 12 retransmission periods to avoid receiving 241 duplicate messages. This aggressive policy can be specified using a 242 Trickle parameter set of Imin = Imax = 100ms, k = infinity, Tactive = 243 3, and Tdwell = 12. Setting k to infinity disables the Trickle 244 suppression mechanism. 246 A conservative multicast forwarding strategy utilizes Trickle 247 suppression and a larger Imax value to minimize redundant 248 transmissions. One such conservative policy is a Trickle parameter 249 set of Imin = 100ms, Imax = 30min, k = 1, Tactive = 3, and Tdwell = 250 12. 252 5. Message Formats 254 5.1. Trickle Multicast Option 256 The Trickle Multicast option is carried in an IPv6 Hop-by-Hop Options 257 header, immediately following the IPv6 header. The Trickle Multicast 258 option has the following format: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Option Type | Opt Data Len | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | SeedID (optional) |M| Sequence | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Option Type XX (to be confirmed by IANA). 270 Opt Data Len Length of the Option Data field in octets. MUST 271 be set to either 2 or 4. 273 SeedID Uniquely identifies a Trickle multicast seed that 274 initiated the dissemination process. The SeedID 275 field is optional and only appears when Opt Data 276 Len is set to 4. When Opt Data Len is set to 2, 277 the SeedID is equivalent to the IPv6 Source 278 address. 280 M Mode flag. Identifies one of two Trickle 281 parameters to use when forwarding this multicast 282 message. 284 Sequence Identifies relative ordering of multicast 285 messages from the source identified by SeedID. 287 The Option Data of the Trickle Multicast option MUST NOT change en- 288 route. Nodes that do not understand the Trickle Multicast option 289 MUST skip over this option and continue processing the header. Thus, 290 according to [RFC2460] the three high order bits of the Option Type 291 must be equal set to zero. The Option Data length is variable. 293 The SeedID uniquely identifies a Trickle multicast seed within the 294 Trickle multicast domain. The SeedID field may either be an IPv6 295 address assigned to the seed node or a managed 16-bit value. In 296 either case, the SeedID MUST be unique within the Trickle multicast 297 domain. Managing the SeedID namespace is left out of scope. 299 The M flag identifies one of two Trickle parameters to use when 300 forwarding the message. This capability allows a Trickle Multicast 301 Domain to support two different Trickle parameter sets that make 302 different propagation time vs. control overhead trade-offs. 304 Sequence establishes a relative ordering of multicast messages from 305 the same SeedID. The source MUST increment the Sequence value when 306 sourcing a new Trickle multicast message. Implementations MUST 307 follow the Serial Number Arithmetic as defined in [RFC1982]. 309 5.2. Trickle ICMPv6 Message 311 The Trickle ICMP message is used to advertise metadata for recently 312 received Trickle multicast messages. The Trickle ICMP message has 313 the following format: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Code | Checksum | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 . Sequence List[1..n] . 322 . . 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 IP Fields: 327 Source Address A link-local address assigned to the sending 328 interface. 330 Destination Address The link-local all-nodes (FF02::1) or link-local 331 all-routers (FF02::2) multicast address. 333 Hop Limit 255 335 ICMP Fields: 337 Type XX (to be confirmed by IANA). 339 Code 0 341 Checksum The ICMP checksum. See [RFC4443]. 343 Sequence List[1..n] List of zero, one, or more Sequence Lists 344 (defined in Section 5.2.1). 346 The Trickle ICMP message advertises sliding windows maintained by the 347 multicast forwarder. The advertisement serves to notify neighbors of 348 newer messages that it can propagate or has yet to receive. Only 349 entries for messages where Tactive has not expired are included in 350 the ICMP message. The sliding windows are encoded using a Sequence 351 List, defined in Section 5.2.1. 353 5.2.1. Sequence List 355 A Sequence List contains a list of Sequence values for a SeedID. 356 Each Sequence List has the following format: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |S|M| rsv | SeqLen | SeedID (2 or 16 octets) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 . Sequence[1..SeqLen] . 365 . . 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 S Indicates length of SeedID. When set to 0, 369 SeedID is 16 octets. When set to 1, SeedID is 2 370 octets. 372 M Indicates one of two Trickle parameter sets used 373 for disseminating multicast messages. 375 SeqLen Number of 2-octet Sequence entries. 377 SeedID Copied from a recently received Trickle Multicast 378 option. 380 Sequence[1..SeqLen] List of recently received Sequence values from 381 SeedID. Note that the Sequence value is only 15 382 bits and the highest order bit MUST be set to 0. 384 6. Trickle Multicast Forwarder Behavior 386 A Trickle Multicast Forwarder implementation needs to manage sliding 387 windows and Trickle timers. These mechanisms are used to determine 388 when received messages should be accepted, when ICMP messages are 389 transmitted, and when multicast messages are retransmitted. 391 6.1. Managing Sliding Windows 393 Every Trickle multicast forwarder MUST maintain a sliding window of 394 Sequence values for each SeedID that generated recently received 395 multicast messages. 397 When receiving a Trickle multicast message, if no existing sliding 398 window exists for the SeedID, a new sliding window MUST be created 399 before accepting the message. If memory constraints are such that a 400 new sliding window cannot be created, then the message must be 401 ignored. 403 If a sliding window exists for the SeedID, the message must be 404 ignored if the message's Sequence value falls below the lower bound 405 of the window or appears in the list of stored Sequence values within 406 the window. All other messages MUST be received. 408 When receiving a message, the sliding window MUST be updated with the 409 message's Sequence value. If the Sequence value is larger than the 410 upper bound of the window, the new message establishes the new upper 411 bound. 413 Memory constraints may limit the total number of Sequence values that 414 can be stored. An entry may be reclaimed before the dwell time 415 expires if it serves as the lower bound of the window and the window 416 has more than one entry. Note that entries can be reclaimed from 417 sliding windows for other SeedIDs. 419 When only one entry for a sliding window remains, that entry MUST NOT 420 be reclaimed until its dwell timer expires. Maintaining the largest 421 sequence value received from a SeedID ensures that earlier messages 422 are received at most once. 424 6.2. Trickle Timers 426 A Trickle multicast forwarder maintains two Trickle timers 427 parameterized on the S flag. The Trickle timer is maintained as 428 described in [I-D.levis-roll-trickle]. 430 When suppression is enabled (i.e. k is finite), a Trickle 431 transmission event consists of transmitting a Trickle ICMP message. 433 If an "inconsistent" advertisement was received during that period, 434 multicast messages that caused the inconsistency are also 435 retransmitted. 437 When suppression is disabled (i.e. k is infinite), a Trickle 438 transmission event consists of transmitting multicast messages that 439 have been received within the Tactive time window. 441 This document defines receiving a "consistent" transmission as 442 receiving a Trickle ICMP message that indicates neither the receiving 443 nor transmitting node has new multicast messages to offer. 445 This document defines receiving an "inconsistent" transmission as 446 receiving a Trickle ICMP message that indicates either receiving or 447 transmitting node has a new multicast message to offer. An 448 "inconsistent" transmission also includes receiving a new multicast 449 message. 451 6.3. Trickle Multicast Option Processing 453 All IPv6 datagrams containing a Trickle Multicast option MUST have a 454 multicast IPv6 Destination address. If the IPv6 Destination is not a 455 multicast address, the multicast forwarder MUST drop the datagram. 457 A multicast forwarder MUST drop the multicast message if it cannot 458 ensure that the message has never been received before. This occurs 459 when the Sequence value is below the lower bound of the sliding 460 window for SeedID or when an entry already exists for the Sequence 461 value. 463 If no sliding window state for SeedID exists, the multicast forwarder 464 MUST allocate a new sliding window for the SeedID before accepting 465 the message. If a sliding window cannot be allocated, the forwarder 466 MUST drop the message. 468 Upon accepting the message, the forwarder MUST enter the sequence 469 value in the sliding window and decrement the IPv6 Hop Limit. If the 470 IPv6 Hop Limit is non-zero, the forwarder MUST buffer the message for 471 retransmission for the duration specified by Tactive. 473 6.4. Trickle ICMP Processing 475 Processing a Trickle ICMP message involves determining if either the 476 receiver or transmitter has new multicast messages to offer. 478 The transmitter has new multicast messages to offer if any (SeedID, 479 Sequence) pair falls within an existing sliding window for SeedID but 480 does not have an associated entry. 482 The transmitter has new multicast messages to offer if the (SeedID, 483 Sequence) pair is great than the upper bound of an existing sliding 484 window for SeedID. 486 The receiver has new multicast messages to offer if any buffered 487 messages are not listed in the Trickle ICMP message and the Trickle 488 ICMP message contains a (SeedID, Sequence) pair for a prior multicast 489 message. 491 The receiver has a new multicast message to offer if any buffered 492 messages does not have an associated SeedID entry in the Trickle ICMP 493 message. 495 If neither receiver nor transmitter has new multicast messages to 496 offer, the multicast forwarder logs a consistent event by 497 incrementing c, as described in [I-D.levis-roll-trickle]. 499 If either receiver or transmitter has new multicast messages to 500 offer, the multicast forwarder logs an inconsistent event by 501 resetting Trickle timer T[M], as described in 502 [I-D.levis-roll-trickle]. All new messages that the receiver can 503 offer MUST be scheduled for transmission at the next transmission 504 event. Note that these transmissions may be suppressed if the 505 transmission event is suppressed. 507 7. Acknowledgements 509 TODO. 511 8. IANA Considerations 513 The Trickle Multicast option requires an IPv6 Option Number. 515 HEX act chg rest 516 --- --- --- ----- 517 C 00 0 01100 519 The first two bits indicate that the IPv6 node may skip over this 520 option and continue processing the header if it doesn't recognize the 521 option type, and the third bit indicates that the Option Data MUST 522 NOT change en-route. 524 9. Security Considerations 526 TODO. 528 10. References 530 10.1. Normative References 532 [I-D.ietf-roll-rpl] 533 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 534 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 535 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 536 Lossy Networks", draft-ietf-roll-rpl-19 (work in 537 progress), March 2011. 539 [I-D.levis-roll-trickle] 540 Levis, P. and T. Clausen, "The Trickle Algorithm", 541 draft-levis-roll-trickle-00 (work in progress), 542 February 2010. 544 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 545 August 1996. 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 552 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 553 (IPv6) Specification", RFC 2460, December 1998. 555 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 556 IPv6 Specification", RFC 2473, December 1998. 558 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 559 Message Protocol (ICMPv6) for the Internet Protocol 560 Version 6 (IPv6) Specification", RFC 4443, March 2006. 562 10.2. Informative References 564 [I-D.ietf-roll-terminology] 565 Vasseur, J., "Terminology in Low power And Lossy 566 Networks", draft-ietf-roll-terminology-05 (work in 567 progress), March 2011. 569 Authors' Addresses 571 Jonathan W. Hui 572 Cisco 573 170 West Tasman Drive 574 San Jose, California 95134 575 USA 577 Phone: +408 424 1547 578 Email: jonhui@cisco.com 580 Richard Kelsey 581 Ember Corporation 582 47 Farnsworth Street 583 Boston, Massachusetts 02210 584 USA 586 Phone: +617 951 1225 587 Email: kelsey@ember.com