| roll | P. van der Stok |
| Internet-Draft | Consultant |
| Intended status: Informational | R. Cragie |
| Expires: April 25, 2015 | Gridmerge |
| October 22, 2014 |
MPL forwarder policy for multicast with admin-local scope
draft-ietf-roll-admin-local-policy-01
The purpose of this document is to specify an automated policy for the routing of MPL multicast messages with admin-local scope in a border router.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Multicast scopes are defined in [RFC4291]. The [RFC7346] extends the scope definition with the text:
"Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically derived from physical connectivity or other, non-multicast related configuration. Global scope has no boundary. The boundaries of all other non-reserved scopes of Admin-Local or larger are administratively configured."
The admin-local scope must therefore be administratively configured. This draft describes an automated policy for the MPL forwarding of multicast messages with admin-local scope within a border router. This wish is in line with the autonomous networking ideas presented in [I-D.irtf-nmrg-an-gap-analysis].
The realm-local multicast address is currently used by MPL to propagate the multicast message to all receivers and forwarders within a mesh network. The multicast propagation is limited to a mesh network with a common layer-2. For example, a LoWPAN is defined by an IEEE 802.15.4 layer-2 mesh network, composed of all connected nodes sharing the same PAN ID [RFC4944].
The network concept differs between mesh network technologies. This document maps a general network identifier to the specific network identifier of existing mesh technologies.
In current and projected deployments, there is a requirement to propagate a multicast message beyond the boundaries of the mesh network it originated in independent of the mesh technology.
Consider the case where propagation over two mesh networks is required. In one example, each mesh network has a border router and the two border routers are connected with an Ethernet link. In another example each mesh network is connected to its own network interface connected to the same border router. In both cases, an admin-local multicast message originating in one network needs to propagate into the other mesh network. The boundary of the admin-local scope is administratively configured.
This document describes an "MPL4 router" that forwards MPL messages with a multicast address with admin-local scope to all interfaces connected to links that connect to other MPL enabled interfaces. The MPL4 router enables all its interfaces for MPL messages and allocates an additional variable MPL_BLOCKED that permits(forbids) the forwarding of MPL messages.
It is expected that the network of an organization, building, or home, is connected to the Internet via the edge routers provided by an ISP. The intention is that within the network of an organization, building, or home, MPL messages with multicast addresses of admin-local scope are freely forwarded but are never forwarded to edge routers which MUST not enable their interfaces for MPL messages.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document uses terminology defined in [I-D.ietf-roll-trickle-mcast] and [RFC7346]. In addition, the following terms are used in this document:
Links may have the concept of a channel, for example in wireless networks such a channel is associated with a communication frequency. Additionally, for some link technologies, several networks can coexist using the same channel. For these link technologies, a network identifier exists. The network identifier is determined by the link technology specification. When no network identifier exists for a given link, the network identifier has the value "undefined".
IPv6 over IEEE 802.15.4 is described in [RFC4944]. A LoWPAN is composed of the nodes connected by an IEEE 802.15.4 mesh sharing the same PAN ID. The PAN ID identifies a network in the IEEE 802.15.4 mesh. Several networks with different PAN IDs can coexist on the same channel [IEEE802.15.4]. The PAN ID of an interface is defined when the interface is enabled. The value of the network identifier of an IEEE 802.15.4 link is the value of the PAN ID.
IP over IEEE 802.11 is described in [RFC5416]. The SSID identifies a network in the IEEE 802.11 link. Several networks with different SSIDs can coexist on the same channel [IEEE802.11]. The SSID of an interface is defined when the interface is switched on. The value of the network identifier of a IEEE 802.11 link is the value of the SSID.
IPv6 over ITU-T G.9959 is specified in [I-D.ietf-6lo-lowpanz]. The HomeID identifies a network of connected nodes [G.9959]. Several HomeIDs can coexist within communication range, but nodes adhering to a network with a given HomeID cannot communicate with nodes adhering to a network with a different HomeID. The value of the network identifier of a G.9959 link is the value of the HomeID.
IPv6 over BLUETOOTH Low Energy (BTLE) is specified in [I-D.ietf-6lo-btle]. The medium is specified in [btle].
BTLE does not know the concept of multiple networks in one channel. The value of the network identifier of a BTLE link is "any".
The concept of an MPL4 router serves to automatically determine the zone in which MPL messages with an scope 4 multicast address can propagate. The MPL4 router periodically executes an algorithm that determines the presence of MPL interfaces on the links connected to its interfaces. When no MPL interfaces are present on a given link, the corresponding MPL interface is signalled as not being part of the MPL zone.
One parameter is associated with every MPL interface in the MPL4 router, and two parameters are associated with the behaviour of the MPL4 router as a whole.
All interfaces of the MPL4 router MUST be associated with following parameters coming from MPL protocol [I-D.ietf-roll-trickle-mcast]: PROACTIVE_FORWARDING, DATA_MESSAGE_IMIN, DATA_MESSAGE_IMAX, DATA_MESSAGE_K, DATA_MESSAGE_TIMER_EXPIRATIONS. At start-up of the MPL4 router, the parameters associated with all interfaces are assigned the following values: PROACTIVE_FORWARDING = true, MPL_BLOCKED = false. All interfaces MUST subscribe to the multicast addresses ALL_MPL_FORWARDERS scope 3 and scope 4.
The MPL4 router executes the following algorithm for each interface:
This protocol leads to a state where for each interface MPL_BLOCKED is set to false if and only if MPL enabled interfaces are connected to the link associated with the interface. When an MPL message is submitted to an MPL-enabled interface -called A- in the MPL router, the TRICKLE algorithm is activated to send the MPL message. The MPL4 message with multicast address ALL_MPL_FORWARDERS scope 4 is accepted by every interface connected to the link that has subscribed to ALL_MPL_FORWARDERS with scope 4. On acceptance of the MPL4 message by an interface -called B-, the MPL4 message is returned with Trickle over interface B. Consequently, the MPL4 message is received by the originating interface A, after which MPL_BLOCKED is set to false.
When a new node is connected to the link, it can immediately send an MPL4 message, or can wait for the reception of an MPL4 message to announce its intention to be part of the MPL zone.
The section starts with specifying what multicast messages arriving at an interface are legal. It continues with a description of forwarding legal admin-local multicast messages over other MPL interfaces.
The policy for forwarding admin-local multicast messages automatically to a MPL interface is specified as function of the state of the MPL interface and the multicast message. The state of the multicast message is determined by the presence of the MPL option and the destination multicast address. The state of the MPL interface is determined by the subscribed multicast addresses, and the values of the PROACTIVE_FORWARDING parameter and the MPL_BLOCKED parameter of the MPL interface.
Multicast messages can be created within the node by an application or can arrive at an interface.
A multicast message created at a source (MPL seed) is legal when it conforms to the properties described in section 9.1 of [I-D.ietf-roll-trickle-mcast].
A multicast message received at a given interface is legal when:
Illegal multicast messages are discarded.
A legal multicast message received at a given interface is assigned the network identifier of the interface of the incoming link . A message that is created within the node is assigned the network identifier "any".
Two types of legal multicast messages are considered: (1) MPL messages, and (2) multicast messages which do not carry the MPL option.
MPL messages are forwarded on MPL interfaces using the Trickle parameter values assigned to the MPL interface according to the following rules:
Multicast messages without MPL option are forwarded on MPL interfaces according to the following rules:
An MPL domain is a scope zone in which MPL interfaces subscribe to the same MPL Domain Address [I-D.ietf-roll-trickle-mcast]. In accordance with [RFC4007] a zone boundary passes through a node. For example, a small LLN node usually has one MPL mesh interface which is enabled to the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (realm-local) [RFC7346]. The node interface belongs to the zone and the corresponding zone boundary does not pass through this node. In the border router with MPL interfaces enabled to the multicast address ALL_MPL_FORWARDERS with scope value 3, the zone includes usually this single interface and excludes all other interfaces. A notable exception is provided by a node where MPL interfaces of the same technology share the same network identifier. These interfaces belong to the same zone.
In an MPL4 router, every MPL interface subscribes to the admin_local ALL_MPL_FORWARDERS multicast address next to the realm-local ALL_MPL_FORWARDERS address.
Every interface that belongs to an MPL domain that extends over border routers MUST be subscribed to the admin-local ALL_MPL_FORWARDERS address.
The zone corresponding with the MPL multicast address ALL_MPL_FORWARDERS with scope 4 (Admin-local) applies to border routers with multiple interfaces, of which at least one interface is MPL enabled and is subscribed to multicast address ALL_MPL_FORWARDERS with scope 4. In a border router, all MPL enabled interfaces which subscribe to the ALL_MPL_FORWARDERS address with scope 4 and for which MPL_BLOCKED is false belong to the same zone.
Three parameters are created in this draft. Their values are related to the trickle timer intervals.
MPL_TO = DATA_MESSAGE_IMAX times 2. Which leaves the time to receive the second response message.
MPL_CHECK_INT = 5 minutes. Which means that a reaction to network malfunctioning happens within 5 minutes.
MPL_BLOCKED = true. Which means that the interface must have received MPL-enabled messages to include the interface to the zone.
Refer to the security considerations of [I-D.ietf-roll-trickle-mcast].
MPL enabled interfaces MUST subscribe to the ALL_MPL_FORWARDERS address with scope 3 and scope 4. In the latter case the nodes may become flooded by multicast messages with as destination ALL_MPL_FORWARDERS address with scope 4 coming from outside the zone corresponding with the connected mesh networks. Therefore, Multicast messages with address ALL_MPL_FORWADERS scope 4 and scope 3 cannot be forwarded from sources out of the zone corresponding with the scope 4 address.
The enabling of the interfaces for a given set of multicast addresses and the setting of the MPL parameter values must be done in a secure way, such that they cannot be set or modified by unauthorized nodes. That means a setting of the parameters with secured means, or initializing the parameter values in the factory without possibilities for change afterwards.
No considerations for IANA are formulated in this document.
This document reflects discussions and remarks from several individuals including (in alphabetical order): Esko Dijk, Matthew Gillmore, Michael Richardson, and Pascal Thubert.
Version 00 - version 01
Changes from personal version to WG version-00.
| [RFC3973] | Adams, A., Nicholas, J. and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. |
| [RFC4601] | Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. |
| [I-D.irtf-nmrg-an-gap-analysis] | Behringer, M., Carpenter, B. and S. Jiang, "Gap Analysis for Autonomic Networking", Internet-Draft draft-irtf-nmrg-an-gap-analysis-00, April 2014. |
| [I-D.ietf-6lo-lowpanz] | Brandt, A. and J. Buron, "Transmission of IPv6 packets over ITU-T G.9959 Networks", Internet-Draft draft-ietf-6lo-lowpanz-02, February 2014. |
| [I-D.ietf-6lo-btle] | Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z. and C. Gomez, "Transmission of IPv6 Packets over BLUETOOTH Low Energy", Internet-Draft draft-ietf-6lo-btle-00, November 2013. |