MPL forwarder policy for multicast with admin-local scope
draft-vanderstok-roll-admin-local-policy-00

Abstract

The purpose of this document is to specify a policy for the routing of mmulticast messages with admin-local scope.

Status of This Memo

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 August 18, 2014.

Copyright Notice

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.

Table of Contents

• 1. Introduction
• 1.1. Terminology
• 1.2. Required Reading
• 2. Network identifier
• 2.1. IEEE 802.15.4
• 2.2. IEEE 802.11
• 2.3. ITU-T G.9959
• 2.4. BLUETOOTH Low Energy
• 3. Admin-Local policy
• 3.1. Legal incoming packets
• 3.2. Forwarding legal packets
• 3.2.1. Packet with MPL option
• 3.2.2. Packet without MPL option
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

Multicast scopes are defined in [RFC4291]. The [I-D.ietf-6man-multicast-scopes] 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 with value 4 must be administratively configured. This draft shows how the policy that specifies the admin-local scope can be automated.

Scope 3 multicast address is currently used by MPL to distribute the multicast message to all receivers and forwarders within a mesh network. The multicast distribution is limited to a mesh network with a common layer-2. For example, the LoWPAN is defined by the IEEE 802.15.4 layer-2 mesh network, composed of all connected nodes sharing the same PANID [RFC4944].

In current and projected deployments, the multicast message needs to be distributed outside the single mesh over a multi-link network. For example, distribution is wanted over two meshes with an edge router each, where the two edge routers are connected with an ethernet link. Another example of a multi-link network is: one edge router with two interfaces where each interface is connected to a different mesh. A message with a scope 4 multicast address can be distributed over this multi-link networks. The boundary of the scope 4 is administratively configured.

The purpose of this document is to specify an automated policy for the admin-local scope. This draft specifies conditions under which multicast packets arriving over a given interface of a router are forwarded over other interfaces of the same router. The concept of mesh network is mapped to various lowpan networks.

1.1. Terminology

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].

Additionally, this document uses terminology [I-D.ietf-roll-trickle-mcast].

1.2. Required Reading

Admin-local multicast scope is defined in [I-D.ietf-6man-multicast-scopes]. MPL is described in [I-D.ietf-roll-trickle-mcast]

2. Network identifier

Links have the concept of channel associated with a communication frequency. 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".

2.1. IEEE 802.15.4

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 PANID. The PANID identifies a network in the IEEE 802.15.4 mesh. Several networks with different PANIDs can coexist on the same channel [IEEE802.15.4]. The PANID of an interface is defined when the interface is switched on. The value of the network identifier of a IEEE 802.15.4 link is the value of the PANID.

2.2. IEEE 802.11

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.

2.3. ITU-T G.9959

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.

2.4. BLUETOOTH Low Energy

IPv6 over BLUETOOTH low energy (btle) is specified in [I-D.ietf-6lo-btle]. The medium is specified in [btle].

BTLE does know the concept of multiple networks in one channel.

3. Admin-Local policy

The section starts with specifying what multicast packets arriving over a link are legal. It continues with the forwarding of the legal packets over the interfaces for packets with multicast destination addresses with Admin -local scope 4.

The admin-local policy is specified as function of the state of a destination link and the multicast packet. The state of the packet is determined by the presence of the MPL option and the destination Multicast address. The state of the interface is determined by the subscribed multicast addresses and the value of the PROACTIVE_FORWARDING parameter of the interface.

3.1. Legal incoming packets

A packet created in a source (seed) is legal when it conforms to the conditions described in section 9.1 of [I-D.ietf-roll-trickle-mcast].

A packet received over a given link with a multicast destination address, is legal when:

• The packet carries the MPL option and the incoming interface is subscribed to the destination multicast address.
• The packet does not carry the MPL option and the interface has expressed interest to receive packets with the specified multicast address via MLD [RFC3810] or via IGMP [RFC3376]. Packet was sent on according to PIM-DM [RFC3973] or according to PIM-SM [RFC4601]. The packet forwarded with unicast has been decapsulated.

Illegal packets are discarded.

3.2. Forwarding legal packets

A legal packet that arrived over a link is associated with a network identifier with a value copied from the network identifier of the interface of the incoming link . A packet that is created locally has a network identifier with value "any".

Two types of legal packets are considered: (1) packets which carry the MPL option, and (2) packets which do NOT carry the MPL option.

3.2.1. Packet with MPL option

The packet is forwarded over the link of an interface according to the Trickle algorithm, when:

• The packet with a multicast address with scope 2 (link-local) is not forwarded.
• Packet with a multicast scope of 5 or higher is out of scope.
• The packet with MPL option and a Multicast address MC4 with a scope value of 4, is transmitted over all interfaces that are subscribed to the same multicast address MC4, and have PROACTIVE_FORWARDING set to true.
• The packet with MPL option and a Multicast address MC3 with a scope value of 3, is transmitted over all interfaces that are subscribed to the same multicast address MC3, have PROACTIVE_FORWARDING set to true, and the network identifier of the packet is identical to the network-identifier of the interface, or the network identifier of the packet is "any".

3.2.2. Packet without MPL option

The legal packet without MPL option is handled according to the following rules:

• The packet with a multicast address with scope 2 (link-local) or scope 3( Realm-local) is not forwarded.
• Packet with a multicast scope of 5 or higher is out of scope.
• The packet with a multicast address MC4 with scope 4 is encapsulated with a header carrying the MPL option, and is forwarded according to the Trickle algorithm, over all interfaces that are subscribed to multicast address MC4, and have PROACTIVE_FORWARDING set to true.

4. Security Considerations

Refer to the security considerations of [I-D.ietf-roll-trickle-mcast].

5. IANA Considerations

No considerations for IANA are formulated in this document.

6. Acknowledgements

This document reflects discussions and remarks from several individuals including (in alphabetical order):

7. References

7.1. Normative References

7.2. Informative References

Author's Address