idnits 2.17.1 draft-ietf-roll-admin-local-policy-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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 -- The document date (April 8, 2014) is 3663 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-6lo-lowpanz-04 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-08 == Outdated reference: A later version (-07) exists of draft-ietf-6man-multicast-scopes-04 == Outdated reference: A later version (-17) exists of draft-ietf-6lo-btle-00 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 roll P. van der Stok 3 Internet-Draft Consultant 4 Intended status: Informational R. Cragie 5 Expires: October 10, 2014 Gridmerge 6 April 8, 2014 8 MPL forwarder policy for multicast with admin-local scope 9 draft-ietf-roll-admin-local-policy-00 11 Abstract 13 The purpose of this document is to specify an automated policy for 14 the routing of MPL multicast messages with admin-local scope in a 15 border router. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 10, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 54 2. Network identifier . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4. BLUETOOTH Low Energy . . . . . . . . . . . . . . . . . . 5 59 3. MPL4 router . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. MPL interface parameters . . . . . . . . . . . . . . . . 5 61 3.2. Determination of MPL zone . . . . . . . . . . . . . . . . 5 62 4. Admin-Local policy . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Legal multicast messages . . . . . . . . . . . . . . . . 7 64 4.2. Forwarding legal packets . . . . . . . . . . . . . . . . 7 65 4.2.1. MPL message . . . . . . . . . . . . . . . . . . . . . 7 66 4.2.2. Multicast messages without MPL option . . . . . . . . 8 67 5. MPL domains and zones . . . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 10.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Multicast scopes are defined in [RFC4291]. The 80 [I-D.ietf-6man-multicast-scopes] extends the scope definition with 81 the text: 83 "Interface-Local, Link-Local, and Realm-Local scope boundaries are 84 automatically derived from physical connectivity or other, non- 85 multicast related configuration. Global scope has no boundary. The 86 boundaries of all other non-reserved scopes of Admin-Local or larger 87 are administratively configured." 89 The admin-local scope must therefore be administratively configured. 90 This draft describes an automated policy for the MPL forwarding of 91 multicast messages with admin-local scope within a border router. 93 The realm-local multicast address is currently used by MPL to 94 propagate the multicast message to all receivers and forwarders 95 within a mesh network. The multicast propagation is limited to a 96 mesh network with a common layer-2. For example, a LoWPAN is defined 97 by an IEEE 802.15.4 layer-2 mesh network, composed of all connected 98 nodes sharing the same PAN ID [RFC4944]. 100 The network concept differs between mesh network technologies. This 101 document maps a general network identifier to the specific network 102 identifier of existing mesh technologies. 104 In current and projected deployments, there is a requirement to 105 propagate a multicast message beyond the boundaries of the mesh 106 network it originated in independent of the mesh technology. 108 Consider the case where propagation over two mesh networks is 109 required. In one example, each mesh network has a border router and 110 the two border routers are connected with an Ethernet link. In 111 another example each mesh network is connected to its own network 112 interface connected to the same border router. In both cases, an 113 admin-local multicast message originating in one network needs to 114 propagate into the other mesh network. The boundary of the admin- 115 local scope is administratively configured. 117 This document describes an "MPL4 router" that forwards MPL messages 118 with a multicast address with admin-local scope to all interfaces 119 connected to links that connect to other MPL enabled interfaces. The 120 MPL4 router enables all its interfaces for MPL messages and allocates 121 an additional variable MPL_BLOCKED that permits(forbids) the 122 forwarding of MPL messages. 124 It is expected that the network of an organization, building, or 125 home, is connected to the Internet via the edge routers provided by 126 an ISP. The intention is that within the network of an organization, 127 building, or home, MPL messages with multicast addresses of admin- 128 local scope are freely forwarded but are never forwarded to edge 129 routers which do not enable their interfaces for MPL messages. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 1.2. Terminology and Acronyms 139 This document uses terminology defined in 140 [I-D.ietf-roll-trickle-mcast] and [I-D.ietf-6man-multicast-scopes]. 141 In addition, the following terms are used in this document: 143 o MPL4 message: an MPL DATA message with a destination multicast 144 address of scope 4. 146 o MPL4 router: automatically determines the zone in which MPL 147 messages with admin-local scope can be propagated. 149 o MPL4 zone: a convex zone of interconnected interfaces over which 150 MPL messages with admin-local scope propagate. [RFC4007]. 152 2. Network identifier 154 Links may have the concept of a channel, for example in wireless 155 networks such a channel is associated with a communication frequency. 156 Additionally, for some link technologies, several networks can 157 coexist using the same channel. For these link technologies, a 158 network identifier exists. The network identifier is determined by 159 the link technology specification. When no network identifier exists 160 for a given link, the network identifier has the value "undefined". 162 2.1. IEEE 802.15.4 164 IPv6 over IEEE 802.15.4 is described in [RFC4944]. A LoWPAN is 165 composed of the nodes connected by an IEEE 802.15.4 mesh sharing the 166 same PAN ID. The PAN ID identifies a network in the IEEE 802.15.4 167 mesh. Several networks with different PAN IDs can coexist on the 168 same channel [IEEE802.15.4]. The PAN ID of an interface is defined 169 when the interface is enabled. The value of the network identifier 170 of an IEEE 802.15.4 link is the value of the PAN ID. 172 2.2. IEEE 802.11 174 IP over IEEE 802.11 is described in [RFC5416]. The SSID identifies a 175 network in the IEEE 802.11 link. Several networks with different 176 SSIDs can coexist on the same channel [IEEE802.11]. The SSID of an 177 interface is defined when the interface is switched on. The value of 178 the network identifier of a IEEE 802.11 link is the value of the 179 SSID. 181 2.3. ITU-T G.9959 183 IPv6 over ITU-T G.9959 is specified in [I-D.ietf-6lo-lowpanz]. The 184 HomeID identifies a network of connected nodes [G.9959]. Several 185 HomeIDs can coexist within communication range, but nodes adhering to 186 a network with a given HomeID cannot communicate with nodes adhering 187 to a network with a different HomeID. The value of the network 188 identifier of a G.9959 link is the value of the HomeID. 190 2.4. BLUETOOTH Low Energy 192 IPv6 over BLUETOOTH Low Energy (BTLE) is specified in 193 [I-D.ietf-6lo-btle]. The medium is specified in [btle]. 195 BTLE does not know the concept of multiple networks in one channel. 196 The value of the network identifier of a BTLE link is "any". 198 3. MPL4 router 200 The concept of an MPL4 router serves to automatically determine the 201 zone in which MPL messages with an scope 4 multicast address can 202 propagate. The MPL4 router periodically executes an algorithm that 203 determines the presence of MPL interfaces on the links connected to 204 its interfaces. When no MPL interfaces are present on a given link, 205 the corresponding MPL interface is signalled as not being part of the 206 MPL zone. 208 3.1. MPL interface parameters 210 One parameter is associated with every MPL interface in the MPL4 211 router, and two parameters are associated with the behaviour of the 212 MPL4 router as a whole. 214 o MPL_BLOCKED: Boolean value that indicates whether the associated 215 interface belongs to the MPL zone. 217 o MPL_CHECK_INT: integer that indicates the time interval between 218 successive activations of the MPL4 router algorithm in seconds. 220 o MPL_TO: integer that indicates the interval in which MPL messages 221 are expected in seconds. 223 3.2. Determination of MPL zone 225 All interfaces of the MPL4 router MUST be associated with following 226 parameters coming from MPL protocol [I-D.ietf-roll-trickle-mcast]: 227 PROACTIVE_FORWARDING, DATA_MESSAGE_IMIN, DATA_MESSAGE_IMAX, 228 DATA_MESSAGE_K, DATA_MESSAGE_TIMER_EXPIRATIONS. At start-up of the 229 MPL4 router, the parameters associated with all interfaces are 230 assigned the following values: PROACTIVE_FORWARDING = true, 231 MPL_BLOCKED = false. All interfaces MUST subscribe to the multicast 232 addresses ALL_MPL_FORWARDERS scope 3 and scope 4. 234 The MPL4 router executes the following algorithm for each interface: 236 o With a frequency determined by the value of MPL_CHECK_INT, the 237 MPL4 router sends an MPL4 message on each interface with a header 238 that includes the MPL option and is sent to multicast address 239 ALL_MPL_FORWARDERS with scope 4. 241 o When within an interval determined by the value of MPL_TO no MPL 242 message is received, the value of MPL_BLOCKED is set to true. 244 o At reception of an MPL4 message with a multicast address with 245 scope 4, the value of MPL_BLOCKED of the receiving interface is 246 set to false. 248 This protocol leads to a state where for each interface MPL_BLOCKED 249 is set to false if and only if MPL enabled interfaces are connected 250 to the link associated with the interface. When an MPL message is 251 submitted to an MPL-enabled interface -called A- in the MPL router, 252 the TRICKLE algorithm is activated to send the MPL message. The MPL4 253 message with multicast address ALL_MPL_FORWARDERS scope 4 is accepted 254 by every interface connected to the link that has subscribed to 255 ALL_MPL_FORWARDERS with scope 4. On acceptance of the MPL4 message 256 by interface B, the MPL4 message is returned with Trickle over 257 interface B. Consequently, the MPL4 message is received by the 258 originating interface A, after which MPL_BLOCKED is set to false. 260 When a new node is connected to the link, it can immediately send an 261 MPL4 message, or can wait for the reception of an MPL4 message to 262 announce its intention to be part of the MPL zone. 264 TODO?: payload of message used for MPL parameter value negotiation. 266 4. Admin-Local policy 268 The section starts with specifying what multicast messages arriving 269 at an interface are legal. It continues with a description of 270 forwarding legal admin-local multicast messages over other MPL 271 interfaces. 273 The policy for forwarding admin-local multicast messages 274 automatically to a MPL interface is specified as function of the 275 state of the MPL interface and the multicast message. The state of 276 the multicast message is determined by the presence of the MPL option 277 and the destination multicast address. The state of the MPL 278 interface is determined by the subscribed multicast addresses, and 279 the values of the PROACTIVE_FORWARDING parameter and the MPL_BLOCKED 280 parameter of the MPL interface. 282 4.1. Legal multicast messages 284 Multicast messages can be created within the node by an application 285 or can arrive at an interface. 287 A multicast message created at a source (MPL seed) is legal when it 288 conforms to the properties described in section 9.1 of 289 [I-D.ietf-roll-trickle-mcast]. 291 A multicast message received at a given interface is legal when: 293 o The message carries an MPL option (MPL message) and the incoming 294 MPL interface is subscribed to the destination multicast address. 296 o The message does not carry an MPL option and the interface has 297 expressed interest to receive messages with the specified 298 multicast address via MLD [RFC3810] or via IGMP [RFC3376]. The 299 message was sent on according to PIM-DM [RFC3973] or according to 300 PIM-SM [RFC4601]. 302 Illegal multicast messages are discarded. 304 4.2. Forwarding legal packets 306 A legal multicast message received at a given interface is assigned 307 the network identifier of the interface of the incoming link . A 308 message that is created locally is assigned the network identifier 309 "any". 311 Two types of legal multicast messages are considered: (1) MPL 312 messages, and (2) multicast messages which do not carry the MPL 313 option. 315 4.2.1. MPL message 317 MPL messages are forwarded on MPL interfaces using the Trickle 318 parameter values assigned to the MPL interface according to the 319 following rules: 321 o Link-local (scope 2) MPL messages are not forwarded. 323 o Realm-local (scope 3) MPL messages are forwarded on all MPL 324 interfaces that are subscribed to the same multicast address and 325 have PROACTIVE-FORWARDING set to true, and the assigned network 326 identifier of the multicast message is identical to the network 327 identifier of the MPL interface, or the assigned network 328 identifier of the multicast message is "any". 330 o Admin-local (scope 4) MPL messages are forwarded on all MPL 331 interfaces that are subscribed to the same multicast address, have 332 PROACTIVE-FORWARDING set to true, and have MPL_BLOCKED set to 333 false. 335 o MPL messages with a multicast scope of 5 or higher are out of 336 scope for this specification. (TODO: decapsulation of MPL 337 option?) 339 4.2.2. Multicast messages without MPL option 341 Multicast messages without MPL option are forwarded on MPL interfaces 342 according to the following rules: 344 o Link-local (scope 2) messages or realm-local (scope 3) multicast 345 messages are not forwarded. 347 o Admin-local (scope 4) multicast messages are encapsulated with a 348 header carrying the MPL option and are forwarded on al MPL 349 interfaces that are subscribed to the multicast address, have 350 PROACTIVE_FORWARDING set to true, and have MPL_BLOCKED set to 351 false. 353 o Multicast messages with a multicast scope of 5 or higher follow 354 the Multicast forwarding rules as specified by PIM [RFC3973], 355 [RFC4601] according to group specifications enabled by MLD 356 [RFC3810] or IGMP [RFC3376]. 358 5. MPL domains and zones 360 An MPL domain is a scope zone in which MPL interfaces subscribe to 361 the same MPL Domain Address [I-D.ietf-roll-trickle-mcast]. In 362 accordance with [RFC4007] a zone boundary passes through a node. For 363 example, a small LLN node usually has one MPL mesh interface which is 364 enabled to the ALL_MPL_FORWARDERS multicast address with a scope 365 value of 3 (realm-local) [I-D.ietf-6man-multicast-scopes]. The node 366 interface belongs to the zone and the corresponding zone boundary 367 does not pass through this node. In the border router with MPL 368 interfaces enabled to the multicast address ALL_MPL_FORWARDERS with 369 scope value 3, the zone includes usually this single interface and 370 excludes all other interfaces. A notable exception is provided by a 371 node where MPL interfaces of the same technology share the same 372 network identifier. These interfaces belong to the same zone. 374 In an MPL4 router, every MPL interface subscribes to the admin_local 375 ALL_MPL_FORWARDERS multicast address next to the realm-local 376 ALL_MPL_FORWARDERS address. 378 Every interface that belongs to an MPL domain that extends over 379 border routers MUST subscribe the admin-local ALL_MPL_FORWARDERS 380 address. 382 The zone corresponding with the MPL multicast address 383 ALL_MPL_FORWARDERS with scope 4 (Admin-local) applies to border 384 routers with multiple interfaces, of which at least one interface is 385 MPL enabled and is subscribed to multicast address ALL_MPL_FORWARDERS 386 with scope 4. In a border router, all MPL enabled interfaces which 387 subscribe to the ALL_MPL_FORWARDERS address with scope 4 and for 388 which MPL_BLOCKED is false belong to the same zone. 390 6. Security Considerations 392 Refer to the security considerations of 393 [I-D.ietf-roll-trickle-mcast]. 395 7. IANA Considerations 397 No considerations for IANA are formulated in this document. 399 8. Acknowledgements 401 This document reflects discussions and remarks from several 402 individuals including (in alphabetical order): Esko Dijk, Matthew 403 Gillmore, and Michael Richardson. 405 9. Change log 407 Changes from personal version to WG version. 409 o Aligned terminology with MPL terminology 410 [I-D.ietf-roll-trickle-mcast] 412 o Text on MPL4 router included 414 10. References 416 10.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 422 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 424 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 425 Architecture", RFC 4291, February 2006. 427 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 428 "Transmission of IPv6 Packets over IEEE 802.15.4 429 Networks", RFC 4944, September 2007. 431 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 432 Thyagarajan, "Internet Group Management Protocol, Version 433 3", RFC 3376, October 2002. 435 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 436 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 437 March 2005. 439 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and 440 Provisioning of Wireless Access Points (CAPWAP) Protocol 441 Binding for IEEE 802.11", RFC 5416, March 2009. 443 [I-D.ietf-6lo-lowpanz] 444 Brandt, A. and J. Buron, "Transmission of IPv6 packets 445 over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-04 446 (work in progress), March 2014. 448 [I-D.ietf-roll-trickle-mcast] 449 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 450 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 451 mcast-08 (work in progress), March 2014. 453 [I-D.ietf-6man-multicast-scopes] 454 Droms, R., "IPv6 Multicast Address Scopes", draft-ietf- 455 6man-multicast-scopes-04 (work in progress), March 2014. 457 [I-D.ietf-6lo-btle] 458 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 459 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 460 over BLUETOOTH Low Energy", draft-ietf-6lo-btle-00 (work 461 in progress), November 2013. 463 [IEEE802.15.4] 464 "IEEE 802.15.4 - Standard for Local and metropolitan area 465 networks -- Part 15.4: Low-Rate Wireless Personal Area 466 Networks", . 468 [IEEE802.11] 469 "IEEE 802.11 - Telecommunications and information exchange 470 between systems Local and metropolitan area networks -- 471 Part 11: Wireless LAN Medium Access Control (MAC) and 472 Physical Layer (PHY) Specifications", . 475 [G.9959] "ITU-T G.9959 Short range narrow-band digital 476 radiocommunication transceivers - PHY and MAC layer 477 specifications", . 479 [btle] "BLUETOOTH Specification Version 4.0", . 482 10.2. Informative References 484 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 485 Independent Multicast - Dense Mode (PIM-DM): Protocol 486 Specification (Revised)", RFC 3973, January 2005. 488 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 489 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 490 Protocol Specification (Revised)", RFC 4601, August 2006. 492 Authors' Addresses 494 Peter van der Stok 495 Consultant 497 Email: consultancy@vanderstok.org 499 Robert Cragie 500 Gridmerge 502 Email: robert.cragie@gridmerge.com