idnits 2.17.1 draft-ietf-roll-trickle-mcast-02.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 784 has weird spacing: '... act chg ...' -- The document date (October 19, 2012) is 4206 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) -- Looks like a reference, but probably isn't: '1' on line 668 -- Looks like a reference, but probably isn't: '65535' on line 668 == Unused Reference: 'RFC2328' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 828, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-06 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). 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: April 22, 2013 Silicon Labs 6 October 19, 2012 8 Multicast Protocol for Low power and Lossy Networks (MPL) 9 draft-ietf-roll-trickle-mcast-02 11 Abstract 13 This document specifies the Multicast Protocol for Low power and 14 Lossy Networks (MPL) that provides IPv6 multicast forwarding in 15 constrained networks. MPL avoids the need to construct or maintain 16 any multicast forwarding topology, disseminating messages to all MPL 17 forwarders in an MPL domain. MPL uses the Trickle algorithm to drive 18 packet transmissions for both control and data-plane packets. 19 Specific Trickle parameter configurations allow MPL to trade between 20 dissemination latency and transmission efficiency. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 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 April 22, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. MPL Option . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. ICMPv6 MPL Message . . . . . . . . . . . . . . . . . . . . 8 62 4.2.1. MPL Window . . . . . . . . . . . . . . . . . . . . . . 9 63 5. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . . . 11 64 5.1. Multicast Packet Dissemination . . . . . . . . . . . . . . 11 65 5.1.1. Trickle Parameters and Variables . . . . . . . . . . . 12 66 5.1.2. Proactive Propagation . . . . . . . . . . . . . . . . 12 67 5.1.3. Reactive Propagation . . . . . . . . . . . . . . . . . 13 68 5.2. Sliding Windows . . . . . . . . . . . . . . . . . . . . . 13 69 5.3. Transmission of MPL Multicast Packets . . . . . . . . . . 15 70 5.4. Reception of MPL Multicast Packets . . . . . . . . . . . . 16 71 5.5. Transmission of ICMPv6 MPL Messages . . . . . . . . . . . 16 72 5.6. Reception of ICMPv6 MPL Messages . . . . . . . . . . . . . 17 73 6. MPL Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 82 1. Introduction 84 Low power and Lossy Networks typically operate with strict resource 85 constraints in communication, computation, memory, and energy. Such 86 resource constraints may preclude the use of existing IPv6 multicast 87 topology and forwarding mechanisms. Traditional IP multicast 88 forwarding typically relies on topology maintenance mechanisms to 89 forward multicast messages to all subscribers of a multicast group. 90 However, maintaining such topologies in LLNs is costly and may not be 91 feasible given the available resources. 93 Memory constraints may limit devices to maintaining links/routes to 94 one or a few neighbors. For this reason, the Routing Protocol for 95 LLNs (RPL) specifies both storing and non-storing modes [RFC6550]. 96 The latter allows RPL routers to maintain only one or a few default 97 routes towards a LLN Border Router (LBR) and use source routing to 98 forward packets away from the LBR. For the same reasons, a LLN 99 device may not be able to maintain a multicast forwarding topology 100 when operating with limited memory. 102 Furthermore, the dynamic properties of wireless networks can make the 103 cost of maintaining a multicast forwarding topology prohibitively 104 expensive. In wireless environments, topology maintenance may 105 involve selecting a connected dominating set used to forward 106 multicast messages to all nodes in an administrative domain. 107 However, existing mechanisms often require two-hop topology 108 information and the cost of maintaining such information grows 109 polynomially with network density. 111 This document specifies the Multicast Protocol for Low power and 112 Lossy Networks (MPL), which provides IPv6 multicast forwarding in 113 constrained networks. MPL avoids the need to construct or maintain 114 any multicast forwarding topology, disseminating multicast messages 115 to all MPL forwarders in an MPL domain. By using the Trickle 116 algorithm [RFC6206], MPL requires only small, constant state for each 117 MPL device that initiates disseminations. The Trickle algorithm also 118 allows MPL to be density-aware, allowing the communication rate to 119 scale logarithmically with density. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 The following terms are used throughout this document: 129 MPL forwarder An IPv6 router that subscribes to the MPL 130 multicast group and participates in disseminating 131 MPL multicast packets. 133 MPL multicast scope The multicast scope that MPL uses when forwarding 134 MPL multicast packets. In other words, the 135 multicast scope of the IPv6 Destination Address 136 of an MPL multicast packet. 138 MPL domain A connected set of MPL forwarders that define the 139 extent of the MPL dissemination process. As a 140 form of flood, all MPL forwarders in an MPL 141 domain will receive MPL multicast packets. The 142 MPL domain MUST be composed of at least one MPL 143 multicast scope and MAY be composed of multiple 144 MPL multicast scopes. 146 MPL seed A MPL forwarder that begins the dissemination 147 process for an MPL multicast packet. The MPL 148 seed may be different than the source of the 149 original multicast packet. 151 MPL seed identifier An identifier that uniquely identifies an MPL 152 forwarder within its MPL domain. 154 original multicast packet An IPv6 multicast packet that is 155 disseminated using MPL. 157 MPL multicast packet An IPv6 multicast packet that contains an MPL 158 Hop-by-Hop Option. When either source or 159 destinations are beyond the MPL multicast scope, 160 the MPL multicast packet is an IPv6-in-IPv6 161 packet that contains an MPL Hop-by-Hop Option in 162 the outer IPv6 header and encapsulates an 163 original multicast packet. When both source and 164 destinations are within the MPL multicast scope, 165 the MPL Hop-by-Hop Option may be included 166 directly within the original multicast packet. 168 3. Overview 170 MPL delivers IPv6 multicast packets by disseminating them to all MPL 171 forwarders within an MPL domain. MPL dissemination is a form of 172 flood. An MPL forwarder may broadcast/multicast an MPL multicast 173 packet out of the same physical interface on which it was received. 174 Using link-layer broadcast/multicast allows MPL to forward multicast 175 packets without explicitly identifying next-hop destinations. An MPL 176 forwarder may also broadcast/multicast MPL multicast packets out 177 other interfaces to disseminate the message across different links. 178 MPL does not build or maintain a multicast forwarding topology to 179 forward multicast packets. 181 Any MPL forwarder may initiate the dissemination process by serving 182 as an MPL seed for an original multicast packet. The MPL seed may or 183 may not be the same device as the source of the original multicast 184 packet. When the original multicast packet's source is outside the 185 LLN, the MPL seed may be the ingress router. Even if an original 186 multicast packet source is within the LLN, the source may first 187 forward the multicast packet to the MPL seed using IPv6-in-IPv6 188 tunneling. Because MPL state requirements grows with the number of 189 active MPL seeds, limiting the number of MPL seeds reduces the amount 190 of state that MPL forwarders must maintain. 192 Because MPL typically broadcasts/multicasts MPL packets out of the 193 same interface on which they were received, MPL forwarders are likely 194 to receive an MPL multicast packet more than once. The MPL seed tags 195 each original multicast packet with an MPL seed identifier and a 196 sequence number. The sequence number provides a total ordering of 197 MPL multicast packets disseminated by the MPL seed. 199 MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include 200 MPL-specific information along with the original multicast packet. 201 Each IPv6 multicast packet that MPL disseminates includes the MPL 202 Option. Because the original multicast packet's source and the MPL 203 seed may not be the same device, the MPL Option may be added to the 204 original multicast packet en-route. To allow Path MTU discovery to 205 work properly, MPL encapsulates the original multicast packet in 206 another IPv6 header that includes the MPL Option. 208 Upon receiving a new MPL multicast packet for forwarding, the MPL 209 forwarder may proactively transmit the MPL multicast packet packet a 210 limited number of times and then falls back into an optional reactive 211 mode. In maintenance mode, an MPL forwarder buffers recently 212 received MPL multicast packets and advertises a summary of recently 213 received MPL multicast packets from time to time, allowing 214 neighboring MPL forwarders to determine if they have any new 215 multicast packets to offer or receive. 217 MPL forwarders schedule their packet (control and data) transmissions 218 using the Trickle algorithm [RFC6206]. Trickle's adaptive 219 transmission interval allows MPL to quickly disseminate messages when 220 there are new MPL multicast packets, but reduces transmission 221 overhead as the dissemination process completes. Trickle's 222 suppression mechanism and transmission time selection allow MPL's 223 communication rate to scale logarithmically with density. 225 4. Message Formats 227 4.1. MPL Option 229 The MPL Option is carried in an IPv6 Hop-by-Hop Options header, 230 immediately following the IPv6 header. The MPL Option has the 231 following format: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Option Type | Opt Data Len | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | S |M| rsv | sequence | seed-id (optional) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Option Type XX (to be confirmed by IANA). 243 Opt Data Len Length of the Option Data field in octets. MUST 244 be set to either 2 or 4. 246 S 2-bit unsigned integer. Identifies the length of 247 seed-id. 0 indicates that the seed-id is 0 and 248 not included in the MPL Option. 1 indicates that 249 the seed-id is a 16-bit unsigned integer. 2 250 indicates that the seed-id is a 64-bit unsigned 251 integer. 3 indicates that the seed-id is a 128- 252 bit unsigned integer. 254 M 1-bit flag. 0 indicates that the value in 255 sequence is not the greatest sequence number that 256 was received from the MPL seed. 258 rsv 5-bit reserved field. MUST be set to zero and 259 incoming MPL multicast packets in which they are 260 not zero MUST be dropped. 262 sequence 8-bit unsigned integer. Identifies relative 263 ordering of MPL multicast packets from the source 264 identified by seed-id. 266 seed-id Uniquely identifies the MPL seed that initiated 267 dissemination of the MPL multicast packet. The 268 size of seed-id is indicated by the S field. 270 The Option Data of the Trickle Multicast option MUST NOT change as 271 the MPL multicast packet is forwarded. Nodes that do not understand 272 the Trickle Multicast option MUST discard the packet. Thus, 273 according to [RFC2460] the three high order bits of the Option Type 274 must be set to '010'. The Option Data length is variable. 276 The seed-id uniquely identifies an MPL seed within the MPL domain. 277 When seed-id is 128 bits (S=3), the MPL seed MAY use an IPv6 address 278 assigned to one of its interfaces that is unique within the MPL 279 domain. Managing MPL seed identifiers is not within scope of this 280 document. 282 The sequence field establishes a total ordering of MPL multicast 283 packets from the same MPL seed. The MPL seed MUST increment the 284 sequence field's value on each new MPL multicast packet that it 285 disseminates. Implementations MUST follow the Serial Number 286 Arithmetic as defined in [RFC1982] when incrementing a sequence value 287 or comparing two sequence values. 289 Future updates to this specification may define additional fields 290 following the seed-id field. 292 4.2. ICMPv6 MPL Message 294 The MPL forwarder uses ICMPv6 MPL messages to advertise information 295 about recently received MPL multicast packets. The ICMPv6 MPL 296 message has the following format: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type | Code | Checksum | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | 304 . MPL Window[1..n] . 305 . . 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 IP Fields: 310 Source Address A link-local address assigned to the sending 311 interface. 313 Destination Address The link-local all-nodes MPL forwarders multicast 314 address (FF02::TBD). 316 Hop Limit 255 318 ICMPv6 Fields: 320 Type XX (to be confirmed by IANA). 322 Code 0 324 Checksum The ICMP checksum. See [RFC4443]. 326 MPL Window[1..n] List of one or more MPL Windows (defined in 327 Section 4.2.1). 329 An MPL forwarder transmits an ICMPv6 MPL message to advertise 330 information about buffered MPL multicast packets. More explicitly, 331 the ICMPv6 MPL message encodes the sliding window state (described in 332 Section 5.2) that the MPL forwarder maintains for each MPL seed. The 333 advertisement serves to indicate to neighboring MPL forwarders 334 regarding newer messages that it may send or the neighboring MPL 335 forwarders have yet to receive. 337 4.2.1. MPL Window 339 An MPL Window encodes the sliding window state (described in 340 Section 5.2 that the MPL forwarder maintains for an MPL seed. Each 341 MPL Window has the following format: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | w-min | w-len | S | seed-id (0, 2 or 16 octets) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | | 349 . buffered-mpl-packets (0 to 8 octets) . 350 . . 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 w-min 8-bit unsigned integer. Indicates the first 354 sequence number associated with the first bit in 355 buffered-mpl-packets. 357 w-len 6-bit unsigned integer. Indicates the size of 358 the sliding window and the number of valid bits 359 in buffered-mpl-packets. The sliding window's 360 upper bound is the sum of w-min and w-len. 362 S 2-bit unsigned integer. Identifies the length of 363 seed-id. 0 indicates that the seed-id value is 0 364 and not included in the MPL Option. 1 indicates 365 that the seed-id value is a 16-bit unsigned 366 integer. 2 indicates that the seed-id value is a 367 128-bit unsigned integer. 3 is reserved. 369 seed-id Indicates the MPL seed associated with this 370 sliding window. 372 buffered-mpl-packets Variable-length bit vector. Identifies the 373 sequence numbers of MPL multicast packets that 374 the MPL forwarder has buffered. The sequence 375 number is determined by w-min + i, where i is the 376 offset within buffered-mpl-packets. 378 The MPL Window does not have any octet alignment requirement. 380 5. MPL Forwarder Behavior 382 An MPL forwarder implementation needs to manage sliding windows for 383 each active MPL seed. The sliding window allows the MPL forwarder to 384 determine what multicast packets to accept and what multicast packets 385 are buffered. An MPL forwarder must also manage MPL packet 386 transmissions. 388 5.1. Multicast Packet Dissemination 390 MPL uses the Trickle algorithm to control packet transmissions when 391 disseminating MPL multicast packets [RFC6206]. MPL provides two 392 propagation mechanisms for disseminating MPL multicast packets. 394 1. With proactive propagation, an MPL forwarder transmits buffered 395 MPL multicast packets using the Trickle algorithm. This method 396 is called proactive propagation since an MPL forwarder actively 397 transmits MPL multicast packets without discovering that a 398 neighboring MPL forwarder has yet to receive the message. 400 2. With reactive propagation, an MPL forwarder transmits ICMPv6 MPL 401 messages using the Trickle algorithm. An MPL forwarder only 402 transmits buffered MPL multicast packets upon discovering that 403 neighboring devices have not yet to receive the corresponding MPL 404 multicast packets. 406 When receiving a new multicast packet, an MPL forwarder first 407 utilizes proactive propagation to forward the MPL multicast packet. 408 Proactive propagation reduces dissemination latency since it does not 409 require discovering that neighboring devices have not yet received 410 the MPL multicast packet. MPL forwarders utilize proactive 411 propagation for newly received MPL multicast packets since they can 412 assume that some neighboring MPL forwarders have yet to receive the 413 MPL multicast packet. After a limited number of MPL multicast packet 414 transmissions, the MPL forwarder may terminate proactive propagation 415 for the MPL multicast packet. 417 An MPL forwarder may optionally use reactive propagation to continue 418 the dissemination process with lower communication overhead. With 419 reactive propagation, neighboring MPL forwarders use ICMPv6 MPL 420 messages to discover new MPL multicast messages that have not yet 421 been received. When discovering that a neighboring MPL forwarder has 422 not yet received a new MPL multicast packet, the MPL forwarder 423 enables proactive propagation again. 425 5.1.1. Trickle Parameters and Variables 427 As specified in RFC 6206 [RFC6206], a Trickle timer runs for a 428 defined interval and has three configuration parameters: the minimum 429 interval size Imin, the maximum interval size Imax, and a redundancy 430 constant k. 432 MPL defines a fourth configuration parameter, TimerExpirations, which 433 indicates the number of Trickle timer expiration events that occur 434 before terminating the Trickle algorithm. 436 Each MPL forwarder maintains a separate Trickle parameter set for the 437 proactive and reactive propagation methods. TimerExpirations MUST be 438 greater than 0 for proactive propagation. TimerExpirations MAY be 439 set to 0 for reactive propagation, which effectively disables 440 reactive propagation. 442 As specified in RFC 6206 [RFC6206], a Trickle timer has three 443 variables: the current interval size I, a time within the current 444 interval t, and a counter c. 446 MPL defines a fourth variable, e, which counts the number of Trickle 447 timer expiration events since the Trickle timer was last reset. 449 5.1.2. Proactive Propagation 451 With proactive propagation, the MPL forwarder transmits buffered MPL 452 multicast packets using the Trickle algorithm. Each buffered MPL 453 multicast packet that is proactively being disseminated with 454 proactive propagation has an associated Trickle timer. Adhering to 455 Section 5 of RFC 6206 [RFC6206], this document defines the following: 457 o This document defines a "consistent" transmission for proactive 458 propagation as receiving an MPL multicast packet that has the same 459 MPL seed identifier and sequence number as a buffered MPL packet. 461 o This document defines an "inconsistent" transmission for proactive 462 propagation as receiving an MPL multicast packet that has the same 463 MPL seed identifier, the M flag set, and has a sequence number 464 less than the buffered MPL multicast packet's sequence number. 466 o This document does not define any external "events". 468 o This document defines both MPL multicast packets and ICMPv6 MPL 469 multicast packets as Trickle messages. These messages are defined 470 in the sections below. 472 o The actions outside the Trickle algorithm that the protocol takes 473 involve managing sliding window state, and is specified in 474 Section 5.2. 476 5.1.3. Reactive Propagation 478 With reactive propagation, the MPL forwarder transmits ICMPv6 MPL 479 messages using the Trickle algorithm. A MPL forwarder maintains a 480 single Trickle timer for reactive propagation with each MPL domain. 481 When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not 482 execute the Trickle algorithm for reactive propagation and reactive 483 propagation is disabled. Adhering to Section 5 of RFC 6206 484 [RFC6206], this document defines the following: 486 o This document defines a "consistent" transmission for reactive 487 propagation as receiving an ICMPv6 MPL message that indicates 488 neither the receiving nor transmitting node has new MPL multicast 489 packets to offer. 491 o This document defines an "inconsistent" transmission for reactive 492 propagation as receiving an ICMPv6 MPL message that indicates 493 either the receiving or transmitting node has at least one new MPL 494 multicast packet to offer. 496 o This document defines an "event" for reactive propagation as 497 updating any sliding window (i.e. changing the value of WindowMin, 498 WindowMax, or the set of buffered MPL multicast packets) in 499 response to receiving an MPL multicast packet. 501 o This document defines both MPL multicast packets and ICMPv6 MPL 502 multicast packets as Trickle messages. These messages are defined 503 in the sections below. 505 o The actions outside the Trickle algorithm that the protocol takes 506 involve managing sliding window state, and is specified in 507 Section 5.2. 509 5.2. Sliding Windows 511 Every MPL forwarder MUST maintain a sliding window of sequence 512 numbers for each MPL seed of recently received MPL packets. The 513 sliding window performs two functions: 515 1. Indicate what MPL multicast packets the MPL forwarder should 516 accept. 518 2. Indicate what MPL multicast packets are buffered and may be 519 transmitted to neighboring MPL forwarders. 521 Each sliding window logically consists of: 523 1. A lower-bound sequence number, WindowMin, that represents the 524 sequence number of the oldest MPL multicast packet the MPL 525 forwarder is willing to receive or has buffered. An MPL 526 forwarder MUST ignore any MPL multicast packet that has sequence 527 value less than than WindowMin. 529 2. An upper-bound sequence value, WindowMax, that represents the 530 sequence number of the next MPL multicast packet that the MPL 531 forwarder expects to receive. An MPL forwarder MUST accept any 532 MPL multicast packet that has sequence number greater than or 533 equal to WindowMax. 535 3. A list of MPL multicast packets, BufferedPackets, buffered by the 536 MPL forwarder. Each entry in BufferedPackets MUST have a 537 sequence number in the range [WindowMin, WindowMax). 539 4. A timer, HoldTimer, that indicates the minimum lifetime of the 540 sliding window. The MPL forwarder MUST NOT free a sliding window 541 before HoldTimer expires. 543 When receiving an MPL multicast packet, if no existing sliding window 544 exists for the MPL seed, the MPL forwarder MUST create a new sliding 545 window before accepting the MPL multicast packet. The MPL forwarder 546 may reclaim memory resources by freeing a sliding window for another 547 MPL seed if its HoldTimer has expired. If, for any reason, the MPL 548 forwarder cannot create a new sliding window, it MUST discard the 549 packet. 551 If a sliding window exists for the MPL seed, the MPL forwarder MUST 552 ignore the MPL multicast packet if the packet's sequence number is 553 less than WindowMin or appears in BufferedPackets. Otherwise, the 554 MPL forwarder MUST accept the packet and determine whether or not to 555 forward the packet and/or pass the packet to the next higher layer. 557 When accepting an MPL multicast packet, the MPL forwarder MUST update 558 the sliding window based on the packet's sequence number. If the 559 sequence number is not less than WindowMax, the MPL forwarder MUST 560 set WindowMax to 1 greater than the packet's sequence number. If 561 WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL forwarder MUST 562 increment WindowMin such that WindowMax - WindowMin <= 563 MPL_MAX_WINDOW_SIZE. At the same time, the MPL forwarder MUST free 564 any entries in BufferedPackets that have a sequence number less than 565 WindowMin. 567 If the MPL forwarder has available memory resources, it MUST buffer 568 the MPL multicast packet for proactive propagation. If not enough 569 memory resources are available to buffer the packet, the MPL 570 forwarder MUST increment WindowMin and free entries in 571 BufferedPackets that have a sequence number less than WindowMin until 572 enough memory resources are available. Incrementing WindowMin will 573 ensure that the MPL forwarder does not accept previously received 574 packets. 576 An MPL forwarder MAY reclaim memory resources from sliding windows 577 for other MPL seeds. If a sliding window for another MPL seed is 578 actively disseminating messages and has more than one entry in its 579 BufferedPackets, the MPL forwarder may free entries for that MPL seed 580 by incrementing WindowMin as described above. 582 If the MPL forwarder cannot free enough memory resources to buffer 583 the MPL multicast packet, the MPL forwarder MUST set WindowMin to 1 584 greater than the packet's sequence number. 586 When memory resources are available, an MPL forwarder SHOULD buffer a 587 MPL multicast packet until the proactive propagation completes (i.e. 588 the Trickle algorithm stops execution) and MAY buffer for longer. 589 After proactive propagation completes, the MPL forwarder may advance 590 WindowMin to the packet's sequence number to reclaim memory 591 resources. When the MPL forwarder no longer buffers any packets, it 592 MAY set WindowMin equal to WindowMax. When setting WindowMin equal 593 to WindowMax, the MPL forwarder MUST initialize HoldTimer to 594 WINDOW_HOLD_TIME and start HoldTimer. After HoldTimer expires, the 595 MPL forwarder MAY free the sliding window to reclaim memory 596 resources. 598 5.3. Transmission of MPL Multicast Packets 600 The MPL forwarder manages buffered MPL multicast packet transmissions 601 using the Trickle algorithm. When adding a packet to 602 BufferedPackets, the MPL forwarder MUST create a Trickle timer for 603 the packet and start execution of the Trickle algorithm. 605 After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL 606 forwarder MUST stop executing the Trickle algorithm. When a buffered 607 MPL multicast packet does not have an active Trickle timer, the MPL 608 forwarder MAY free the buffered packet by advancing WindowMin to 1 609 greater than the packet's sequence number. 611 Each interface that supports MPL is configured with exactly one MPL 612 multicast scope. The MPL multicast scope MUST be site-local or 613 smaller and defaults to link-local. A scope larger than link-local 614 MAY be used only when that scope corresponds exactly to the MPL 615 domain. 617 An MPL domain may therefore be composed of one or more MPL multicast 618 scopes. For example, the MPL domain may be composed of a single MPL 619 multicast scope when using a site-local scope. Alternatively, the 620 MPL domain may be composed of multiple MPL multicast scopes when 621 using a link-local scope. 623 IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an 624 original multicast packet whose source or destination address is 625 outside the MPL multicast scope. IPv6-in-IPv6 encapsulation is 626 necessary to support Path MTU discovery when the MPL forwarder is not 627 the source of the original multicast packet. IPv6-in-IPv6 628 encapsulation also allows an MPL forwarder to remove the MPL Option 629 when forwarding the original multicast packet over a link that does 630 not support MPL. The destination address scope for the outer IPv6 631 header MUST be the MPL multicast scope. 633 When an MPL domain is composed of multiple MPL multicast scopes (e.g. 634 when the MPL multicast scope is link-local), an MPL forwarder MUST 635 decapsulate and encapsulate the original multicast packet when 636 crossing between different MPL multicast scopes. In doing so, the 637 MPL forwarder MUST duplicate the MPL Option, unmodified, in the new 638 outer IPv6 header. 640 The IPv6 destination address of the MPL multicast packet is the all- 641 MPL-forwarders multicast address (TBD). The scope of the IPv6 642 destination address is set to the MPL multicast scope. 644 5.4. Reception of MPL Multicast Packets 646 Upon receiving an MPL multicast packet, the MPL forwarder first 647 determines whether or not to accept and buffer the MPL multicast 648 packet based on its MPL seed and sequence value, as specified in 649 Section 5.2. 651 If the MPL forwarder accepts the MPL multicast packet, the MPL 652 forwarder determines whether or not to deliver the original multicast 653 packet to the next higher layer. For example, if the MPL multicast 654 packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the 655 outer IPv6 header, which also removes MPL Option. 657 5.5. Transmission of ICMPv6 MPL Messages 659 The MPL forwarder generates and transmits a new ICMPv6 MPL message 660 whenever Trickle requests a transmission. The MPL forwarder includes 661 an encoding of each sliding window in the ICMPv6 MPL message. 663 Each sliding window is encoded using an MPL Window entry, defined in 664 Section 5.2. The MPL forwarder sets the MPL Window fields as 665 follows: 667 S If the MPL seed identifier is 0, set S to 0. If the MPL seed 668 identifier is within the range [1, 65535], set S to 2. Otherwise, 669 set S to 3. 671 w-min Set to the lower bound of the sliding window (i.e. 672 WindowMin). 674 w-len Set to the length of the window (i.e. WindowMax - WindowMin). 676 seed-id If S is non-zero, set to the MPL seed identifier. 678 buffered-mpl-packets Set each bit that represents a sequence number 679 of a packet in BufferedPackets to 1. Set all other bits to 0. 680 The i'th bit in buffered-mpl-packets represents a sequence number 681 of w-min + i. 683 5.6. Reception of ICMPv6 MPL Messages 685 An MPL forwarder processes each ICMPv6 MPL message that it receives 686 to determine if it has any new MPL multicast packets to receive or 687 offer. 689 An MPL forwarder determines if a new MPL multicast packet has not 690 been received from a neighboring node if any of the following 691 conditions hold true: 693 1. The ICMPv6 MPL message includes an MPL Window for an MPL seed 694 that does not have a corresponding sliding window entry on the 695 MPL forwarder. 697 2. The neighbor has a packet in its BufferedPackets that has 698 sequence value greater than or equal to WindowMax (i.e. w-min + 699 w-len >= WindowMax). 701 3. The neighbor has a packet in its BufferedPackets that has 702 sequence number within range of the sliding window but is not 703 included in BufferedPackets (i.e. the i'th bit in buffered-mpl- 704 packets is set to 1, where the sequence number is w-min + i). 706 When an MPL forwarder determines that it has not yet received a new 707 MPL multicast packet buffered by a neighboring device, the MPL 708 forwarder resets the Trickle timer associated with reactive 709 propagation. 711 An MPL forwarder determines if an entry in BufferedPackets has not 712 been received by a neighboring MPL forwarder if any of the following 713 conditions hold true: 715 1. The ICMPv6 MPL message does not include an MPL Window for the 716 packet's MPL seed. 718 2. The packet's sequence number is greater than or equal to the 719 neighbor's WindowMax value (i.e. the packet's sequence number is 720 greater than or equal to w-min + w-len). 722 3. The packet's sequence number is within the range of the 723 neighbor's sliding window [WindowMin, WindowMax), but not 724 included in the neighbor's BufferedPacket (i.e. the packet's 725 sequence number is greater than or equal to w-min, strictly less 726 than w-min + w-len, and the corresponding bit in buffered-mpl- 727 packets is set to 0. 729 When an MPL forwarder determines that it has at least one buffered 730 MPL multicast packet that has not yet been received by a neighbor, 731 the MPL forwarder resets the Trickle timer associated with reactive 732 propagation. Additionally, for each buffered MPL multicast packet 733 that should be transferred, the MPL forwarder MUST reset the Trickle 734 timer and reset e to 0 for proactive propagation. If the Trickle 735 timer for proactive propagation has already stopped execution, the 736 MPL forwarder MUST initialize a new Trickle timer and start execution 737 of the Trickle algorithm. 739 6. MPL Parameters 741 An MPL forwarder maintains two sets of Trickle parameters for the 742 proactive and reactive methods. The Trickle parameters are listed 743 below: 745 PROACTIVE_IMIN The minimum Trickle timer interval, as defined in 746 [RFC6206] for proactive propagation. 748 PROACTIVE_IMAX The maximum Trickle timer interval, as defined in 749 [RFC6206] for proactive propagation. 751 PROACTIVE_K The redundancy constant, as defined in [RFC6206] for 752 proactive propagation. 754 PROACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations 755 that occur before terminating the Trickle algorithm. MUST be set 756 to a value greater than 0. 758 REACTIVE_IMIN The minimum Trickle timer interval, as defined in 759 [RFC6206] for reactive propagation. 761 REACTIVE_IMAX The maximum Trickle timer interval, as defined in 762 [RFC6206] for reactive propagation. 764 REACTIVE_K The redundancy constant, as defined in [RFC6206] for 765 reactive propagation. 767 REACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations 768 that occur before terminating the Trickle algorithm. MAY be set 769 to 0, which disables reactive propagation. 771 WINDOW_HOLD_TIME The minimum lifetime for sliding window state. 773 7. Acknowledgements 775 The authors would like to acknowledge the helpful comments of Robert 776 Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Joseph Reddy, 777 Dario Tedeschi, and Peter van der Stok, which greatly improved the 778 document. 780 8. IANA Considerations 782 The Trickle Multicast option requires an IPv6 Option Number. 784 HEX act chg rest 785 --- --- --- ----- 786 C 01 0 TBD 788 The first two bits indicate that the IPv6 node MUST discard the 789 packet if it doesn't recognize the option type, and the third bit 790 indicates that the Option Data MUST NOT change en-route. 792 9. Security Considerations 794 TODO. 796 10. References 798 10.1. Normative References 800 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 801 August 1996. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, March 1997. 806 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 808 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 809 (IPv6) Specification", RFC 2460, December 1998. 811 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 812 IPv6 Specification", RFC 2473, December 1998. 814 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 815 Message Protocol (ICMPv6) for the Internet Protocol 816 Version 6 (IPv6) Specification", RFC 4443, March 2006. 818 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 819 "The Trickle Algorithm", RFC 6206, March 2011. 821 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 822 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 823 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 824 Lossy Networks", RFC 6550, March 2012. 826 10.2. Informative References 828 [I-D.ietf-roll-terminology] 829 Vasseur, J., "Terminology in Low power And Lossy 830 Networks", draft-ietf-roll-terminology-06 (work in 831 progress), September 2011. 833 Authors' Addresses 835 Jonathan W. Hui 836 Cisco 837 170 West Tasman Drive 838 San Jose, California 95134 839 USA 841 Phone: +408 424 1547 842 Email: jonhui@cisco.com 844 Richard Kelsey 845 Silicon Labs 846 25 Thomson Place 847 Boston, Massachusetts 02210 848 USA 850 Phone: +617 951 1225 851 Email: richard.kelsey@silabs.com