| Network Working Group | B. Adamson |
| Internet-Draft | Naval Research Laboratory |
| Intended status: Experimental | C. Danilov |
| Expires: May 08, 2014 | Boeing Corporation |
| J. Macker | |
| Naval Research Laboratory | |
| November 04, 2013 |
Elastic Multicast Routing Protocol
draft-adamson-elasticmcast-00
This document describes an Internet Protocol (IP) multicast routing protocol suitable for dynamic network environments including mobile wireless. To handle high dynamics, this routing mechanism uses redundant forwarding, based upon the Simplified Multicast Forwarding (SMF) approach of [RFC6621], while converging to regular multicast distribution trees where or when the network becomes relatively stable. The rationale is that intermittent connectivity directly affects the ability of routers to synchronize on their view of the network, thus making it difficult to converge on efficient distribution trees, while network wide broadcast may be prohibitively expensive for relatively sparse groups. A hybrid approach, called Elastic Multicast, is specified which dynamically switches between limited scope broadcast and tree path forwarding independently at each node. The trees created during stable periods and portions of the network are pruned from the SMF efficient flooding mesh.
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 May 08, 2014.
Copyright (c) 2013 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.
IP Multicast is an efficient way to distribute data to multiple receivers in networks. And, in wireless networks, the often broadcast nature of the communication media makes this even more advantageous and often important, given capacity limits. In relatively stable networks, multicast forwarding trees can be formed by protocols such as Protocol Independent Multicast (PIM) Dense Mode (DM)[RFC3973] or PIM Sparse Mode (SM)[RFC4601] to route and replicate packets from a source to multiple destinations, thus reducing the overhead of multiple point-to-point forwarding paths run in parallel, one for each receiver of the multicast traffic. Building and maintaining multicast distribution trees requires some coordination between the network routers in order to avoid loops and to make sure that the dissemination paths are valid. In highly dynamic environments, the cost of maintaining the distribution trees can become prohibitive and the routers may be unable to synchronize their view of the network, leading to dropped traffic or transmission over invalid paths (TBD-reference?). Additionally, these existing IP multicast routing protocols do not provide for the case in wireless networks where a received packet must be retransmitted via the same interface as which it was received to reach adjacent hosts or routers that were not in reception range of the previous-hop transmitter. This is a fundamental difference from wired network connectivity.
A practical solution that proves very effective in relatively small networks with dense groups is Simplified Multicast Forwarding (SMF) [RFC6621] which can efficiently flood IP multicast traffic to the entire network, regardless of group membership. The SMF approach can provide efficient flooding when a subset of well-connected nodes that form a Connected Dominating Set (CDS) is selected to broadcast the data and relay it to the entire network. The SMF specification describes distributed relay set selection algorithms that can from CDS with local (2-hop neighborhood) information that can be collected via the Neighborhood Discovery Protocol (NHDP) of [RFC6130]. SMF utilizes Duplicate Packet Detection (DPD) forwarding that can be applied to the wireless interface case as needed instead of the typical reverse path forwarding checks used by other IP multicast routing protocols. The approach specified herein, called Elastic Multicast[CH2012], builds off the group forwarding mesh established by SMF with distributed relay set selection and dynamically prunes the mesh as any network stability permits. This hybrid approach allows for highly efficient, group-based multicast datagram distribution when and where the network is relatively stable and provides for SMF-based flooding in times and network portions where unstable connectivity and high dynamics occur. The pruning is implemented more as a "grafting" process in that acknowledgments from neighboring forwarders keep relevant portions of the SMF forwarding mesh active. In dynamic environments, a richer portion of the forwarding mesh is kept active as the acknowledgments are
Starting with the SMF mesh and driven by IP multicast datagram transmissions, the Elastic Multicast protocol forms multicast distribution trees whenever possible to minimize overhead of flooding to unnecessary parts of the topology and adaptively re-expands the forwarding base to additional redundant nodes when needed, when and where these trees become unstable. The data-driven aspect is based on active presence of IP multicast traffic flows among the routers where the flows are timed out due to lack of transmission activity. This mechanism of automatically expanding the forwarding base and then reducing it when not needed is based on acknowledgements in response to detected IP multicast traffic activity. The acknowledgements are aggregated and repeated at the intermediate forwarding nodes for active multicast traffic flows. The pruned SMF forwarding state is periodically timed out for active flows and flooding is reinstated. Thus, at a low duty cycle, active traffic flows are flooded (efficiently per the configured SMF algorithm) throughout the SMF domain to excite routers for Elastic Multicast acknowledgments. An OPTIONAL mechanism is described where periodic data traffic flooding may be economized by use of a control plane message that is periodically hop-by-hop disseminated throughout the network to advertise the aggregate set of active, but unacknowledged, IP multicast flows instead of the actual user traffic. The default flooding behavior of Elastic Multicast traffic is configurable on a per-flow (protocol, source, destination, traffic class) basis.
Elastic Multicast routing trades off pure efficiency in favor of robust datagram delivery in these types of network environments. However, it should be noted that in wireless network systems, the impact of Layer 2 Media Access Control (MAC) mechanisms and radio broadcast contention can extend multiple hops and, in limited scope wireless networks, SMF flooding with CDS relay sets is not necessarily much less efficient than group-specific forwarding in many cases, particularly in dynamic topologies. Since Elastic Multicast builds upon this SMF basis, it is expected to perform similarly and provide additional utility for cases of sparse group membership and stable connectivity.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The terms introduced in [RFC5444], including "packet", "message", "TLV Block", "TLV", and "address" are to be interpreted as described therein.
The following abbreviations are used throughout this document:
| Abbreviation | Definition |
|---|---|
| MANET | Mobile Ad hoc Network |
| SMF | Simplified Multicast Forwarding |
| CDS | Connected Dominating Set |
| NHDP | Neighborhood Discovery Protocol |
| DPD | Duplicate Packet Detection |
| FIB | Forwarding Information Base |
| TLV | type-length-value encoding |
Within dynamic wireless routing topologies, maintaining traditional forwarding trees to support a multicast routing protocol is often not as effective as in wired networks due to the reduced reliability and increased dynamics of mesh topologies [MGL04] [GM99].
The SMF [RFC6621] specification provides for efficient forwarding of non-group-specific, IP multicast datagrams in wireless networks. This specification extends upon SMF to dynamically establish group-specific forwarding trees that are pared down from the base flooding mesh when and where network conditions of stability permit.
Elastic Multicast is compatible with different relay set selection algorithms and forwarding heuristics as described in the SMF specification[RFC6621] appendices. Elastic Multicast is also compatible with both the Any Source Multicast (ASM) [RFC1112][RFC4607] models of multicast group membership.
and Single Source Multicast (SSM)
Elastic Multicast deployments are able to connect and interoperate with existing standard multicast protocols operating within more conventional Internet infrastructures. To this end, a multicast border router or proxy mechanism MUST be used when deployed alongside more fixed-infrastructure IP multicast routing such as the PIM variants [RFC3973] and [RFC4601].
This document does not presently support forwarding of packets with directed broadcast addresses as a destination [RFC2644].
The Elastic Multicast protocol extends upon the SMF specification by providing for controlled forwarding of group-specific multicast traffic flows. Multicast flows are identified by the source address, group destination address, and optionally, protocol, port, and/or traffic class information. By default, newly detected flows are flooded per SMF to the entire network, but with a preset token bucket limited traffic shaping. Elastic multicast acknowledgment messages (EM-ACK) for flows of interest sent in response to the initially flooded traffic keep relevant portions of the SMF mesh "active" where token bucket limitations are lifted and other portions of the SMF mesh are "deactivated" providing only low rate forwarding until EM-ACK activity potentially reactivates it. As a more efficient alternative to gratuitous forwarding of the user data traffic, an Elastic Multicast advertisement message (EM-ADV) is specified that can allow for a "bundled" listing of active flow descriptions that is flooded within the routing area. The use of EM-ADV messages or low duty cycle flooding of the user traffic SHOULD be configurable on a per-flow basis. Initial forwarding/flooding of user traffic may be preferable depending upon the application and network use case.
Elastic Multicast monitors group membership of local hosts (collocated applications, directly attached hosts/devices, or neighboring non-routing hosts) to determine its transmission of EM-ACK messages and forwarding behaviors. When a local host is joined to a group, the Elastic Multicast router relieves any token bucket restrictions for the given group and provides periodic EM-ACK to neighboring routers upon receipt of applicable multicast traffic (or equivalent EM-ADV messages).
An Elastic Multicast router responds to IGMP joins and leaves issued by directly connected hosts. Based on such joins and leaves from connected hosts, an Elastic Multicast router may subscribe to different multicast groups. A router will be a subscriber for a multicast group as long as it has at least one directly connected host that joins that group.
The Elastic Multicast protocol may be deployed in a stand-alone MANET, or can be interfaced with PIM-DM enabled networks through Elastic Multicast gateways.
There is one principal and one optional control message used by the Elastic Multicast protocol. The first message is the Elastic Multicast Acknowledgment (EM-ACK) that is sent in response to received, non-duplicative, multicast user traffic from neighboring "upstream" routers. This message is directed to the given "upstream" router, informing it to make the flow "active" with respect to forwarding and similarly signal (via EM-ACK messages) its neighboring "upstream" routers that the flow is actively subscribed. The second, optional message is the Elastic Multicast Advertisement (EM-ADV) message that can be used as a surrogate instead of forwarding user traffic for unacknowledged flows. Multiple flow descriptions can be "bundled" into individual EM-ADV messages that can reduce the flooding overhead of advertising active multicast flows.
For both of these message types, standard MANET packet building block [RFC5444] formats will be defined. Note, as such, these messages may be sent independently or possibly opportunistically piggy-backed with other MANET link-local protocol messages such as NHDP [RFC6130].
The principal control message used in the Elastic Multicast protocol is acknowledgment message (EM-ACK) that is used to convey subscription interest in active multicast groups among routers in response to detected (transmitted) multicast traffic or the equivalent advertisement (EM-ADV) as described below. The EM-ACK message is directed to the specific neighboring router from which the local router received non-duplicative packets for groups of interest (i.e. joined by locally associate applications or hosts, or which are active due to directed EM-ACK messages received from other neighboring routers). Each EM-ACK message contains the following fields:
[RFC5444] message format for the EM-ACK message will be specified in a future revision of this document.
A standard MANET packet building block
The Elastic Multicast Advertisement (EM-ADV) message provides an alternative means to convey the set of active, but unacknowledged, traffic flows of which the router is aware. Information regarding multiple flows can be bundled into a single EM-ADV message, thus reducing the overhead of advertising active traffic flows for which EM-ACK responses might be generated. Note that the use of EM-ADV message should be optional and configurable on a per-flow basis as, for some use cases, it may be preferable to flood the user traffic directly instead. The concept of using the EM-ADV message to proactively establish Elastic Multicast routing state prior to traffic transmission is being explored and may be described in a future revision of this draft.
Each EM-ADV message consists of a list of active multicast flow descriptions, each with the following fields:
The Tagger-ID and DPD-ID fields are set by the originator of the given flow description. The Tagger-ID is a unique router identifier of the Elastic Multicast router originating the EM-ADV flow description and the DPD-ID is the duplicate packet detection identifier for the packet that triggered the EM-ADV flow description generation. A standard MANET packet building block [RFC5444] message format for the EM-ADV message will be specified in a future revision of this document. Additionally, provisions for "gateway address" and/or "wildcard" address descriptors may be provided to potentially facilitate border gateway and routing area group membership collection in future revisions.
Elastic Multicast works as an extension of SMF. Building on the distributed relay set selection and robust, efficient flooding, the goal of Elastic Multicast is to keep multicast forwarding active only for the subset of SMF relays needed to reach multicast group subscribers. The mechanism described here provides for this relay set pruning in stable parts of the network while still relying on the SMF flooding behavior in the highly dynamic parts of the network where it is hard or impossible to determine which nodes are on the critical path to the destination(s). By eliminating from the set of forwarding nodes those that do not move multicast traffic closer to the subscriber destinations, the number of retransmissions, and consequently the total overhead of the protocol will decrease.
By default, the SMF protocol does not maintain or use group membership information. In its simplest form, called classic flooding (CF), all SMF-enabled nodes rebroadcast all multicast packets, with the end result that all connected nodes get all multicast data. Duplicate Packet Detection (DPD), based on a unique packet identifiers and/or a hash of the packet content, is used to make sure that the same packet is not broadcasted more than once by a node, thus eliminating forwarding loops. In order to reduce overhead, SMF can use inputs from an external protocol, such as OSPF-MDR [RFC5614], OLSR [RFC3626], or NHDP [RFC6130] to enable forwarding by a selected Connected Dominating Set (CDS) of relays through which the entire MANET can be reached. This mechanism works well in relatively dense networks, significantly reducing the number of retransmissions. However, it still propagates multicast data throughout the entire MANET to all nodes, regardless of whether they subscribe to the specific multicast groups or not. Elastic Multicast works to leverage the distributed nature and robustness of SMF, but allow for improved efficiency by attempting to minimize the set of nodes forwarding traffic where it can for specific multicast groups.
To achieve this, Elastic Multicast treats low and high data rate flows of multicast traffic differently. Low data rate flows are flooded throughout the MANET area per SMF as usual. High data rate flows are limited to low data rate forwarding unless Elastic Multicast acknowledgment (EM-ACK) messages are received to "activate" high data rate forwarding of the given flow. Consistent acknowledgment under stable topology conditions to a consistent subset of the SMF relays serves to prune the SMF mesh towards a more efficient distribution tree for the flow while more dynamic acknowledgements to a varied (with topology changes) set of forwarders under less stable topologies serves to activate a larger, more redundant portion of the SMF mesh. The threshold that differentiates low and high data rate flows can be configurable. But, for an example, let's consider that a low data rate threshold is set at 1 packet per second. Thus, flows of less than 1 packet per second are disseminated throughout the entire MANET, while the protocol attempts to prune the distribution only to subscriber nodes for flows of more than 1 packet per second.
Elastic Multicast routers only maintain a local, temporary subscription for the multicast groups for which they are supposed to rebroadcast data packets, and do not maintain any information about the global network topology or global node membership, thus sharing the scalability benefits and most of the simplicity of SMF. However, routers that use Elastic Multicast need to be aware of the multicast groups to which locally attached devices subscribe. The standard protocols used in practice today for multicast join and leave operation are IGMP [RFC3376] and MLD [RFC3810]. The Elastic Multicast protocol does not change the functionality of the IGMP or MLD joins and leaves; it simply uses them to maintain the local membership of the attached devices or collocated processes. The considerations for IGMP and MLD operation are described further in IGMP [igmpConsiderations].
Elastic Multicast routers maintain a traffic shaping token bucket for each multicast data flow they observe. A multicast data flow is defined as a <sourceAddress:groupAddress> pair, although other parameters such as protocol, source/destination ports, or traffic class value may also be considered. The token bucket limits the rate at which multicast data for a certain flow is broadcasted throughout the network, in effect acting as a low rate enforcer per flow for SMF network broadcast. The bucket depth allows for some initial limited, gratuitous flooding of traffic for new flows and for bursty, but low average rate, traffic sources. When a flow is active, because of received local group membership or forwarding acknowledgments from adjacent Elastic Multicast routers, the token bucket enforcement is relaxed until the group membership is dropped and/or the acknowledgment activity for the flow has timed out.
The Elastic Multicast group-specific behavior is initiated by IP multicast group membership (e.g. IGMP join messages) by locally attached subscribers. For example, suppose an Elastic Multicast router becomes subscribed to a certain group as a result of one of its attached devices joining that group. Upon receiving a non-duplicative multicast data packet addressed to the subscribed group, the router sends an Elastic Multicast Acknowledgement (EM-ACK) to the upstream router from which it received the multicast packet. The EM-ACK contains the source IP and the destination group of the original multicast packet. We call an upstream router that receives such a EM-ACK for a flow a forwarding router for that flow. A forwarding router disables the token bucket for a preconfigured period of time, and for that time sends unicast EM-ACKs upstream when it receives multicast packets for that flow. The difference between a forwarding router for a flow and a subscribing router for a multicast group due to some of its locally attached devices joining that group is that the forwarding router only sends EM-ACKs for the flows for which it is receiving EM-ACKs, while the end subscribing router sends EM-ACKs for all flows addressed to that group, regardless of source of the flows. Note, in the case of Single Source Multicast (SSM), the group identifier includes the source address and thus MAY coincide with the flow identifier.
In a static network, trees of temporary multicast forwarders for higher rate traffic is formed from the sources to the subscribers of the groups through the mechanism described above. Forwarding routers send EM-ACKs either periodically or after a certain number of packets for that flow was received, whichever occurs first, in order to refresh the forwarding state at upstream routers. If a forwarding router does not receive EM-ACKs for a multicast flow during a certain timeout, it simply re-enables the rate-limiting token bucket and no longer participates in the high rate forwarding or sending EM-ACKs upstream for that flow. It continues, however, to forward data at the lower rate, as limited by the token bucket. Other than EM-ACKs, no other control messages need to be used in the Elastic Multicast mechanism. However, the optional EM-ADV message MAY be used as a surrogate for low rate forwarding and a single EM-ADV can represent multiple traffic flows with a single message. Elastic Multicast routers use EM-ADV messaging should have its use configurable on a per-flow basis.
When the network topology becomes dynamic, or in parts of the network that become dynamic, more routers will become high load forwarders, as they receive EM-ACKs from downstream routers. Note that downstream routers send unicast EM-ACKs to the upstream router form which they received multicast data. If a forwarder router moves out of range, the next closest router will still forward data at a lower rate and will become activated when an EM-ACK is received. This mechanism expands the forwarding base and add redundancy in the dynamic parts of the network where more routers will be forwarding at a high rate, duplicating traffic, while in the stable parts of the network the protocol will form single paths or trees.
The Elastic Multicast protocol is similar to PIM Dense Mode (PIM-DM), in that it does not maintain topology information, it functions completely decentralized, and defaults in sending multicast data to all nodes in the network at a low rate. However, we believe that Elastic Multicast is more suitable to dynamic networks than PIM-DM mainly because Elastic Multicast routers do not depend on a unicast routing protocol for checking reverse paths in order to avoid loops, nor maintain point-to-point relationships with their neighbors. This allows them to broadcast multicast data, instead of streaming it point-to-point to downstream routers, and because of this the end to end packet delivery is less likely to be affected when network connectivity changes.
TBD - describe the timers that control EM-ACK transmission and per-flow high rate forwarding activation / deactivation.
SMF has the ability to select only some of the nodes to participate in the forwarding mechanism, such that in relatively dense areas, if only a subset of the nodes act as relays, the data forwarded still reaches all nodes in the MANET. Such a subset of forwarder nodes is called a Connected Dominant Set (CDS). Several CDS selection algorithms are currently implemented, and in particular SMF has been proven to perform well with the source-based multipoint relay (S-MPR) and essential connected dominating set (ECDS) algorithms described in [RFC6621].
For CF and ECDS operation where the SMF forwarding rules are simple, the Elastic Multicast operation is straightforward where EM-ACK messages are directed to the previous hop forwarder whenever a non-duplicative multicast packet is received for a flow and its activation is due to be refreshed due to timeout. Other SMF relay set forwarding rules may require special consideration. For example, the forwarding rules of the S-MPR algorithm necessitate slightly different handling. In the case of S-MPR, the EM-ACK message should be sent to the upstream router only when the received packet is non-duplicative and received from an MPR selector for the local router. It is expected that different relay set selection algorithms and selection criteria (e.g. metrics) will have impact on the utility of Elastic Multicast traffic for different application purposes. It is also expected that augmented relay set selection algorithms for efficient multi-interface operation will also impact the requirements for EM-ACK generation for correct protocol operation, but it is anticipated that Elastic Multicast can be adapted to these changes. Further experimentation and analysis should be conducted to determine the tradeoffs for network deployment and operations.
The Elastic Multicast nodes act as regular multicast routers for local hosts subscribing to multicast groups. A local host can be:
IGMP [RFC3376] and MLD [RFC3810], respectively. For the case #3, standard IGMP or MLD operation is not sufficient for operation on MANET interfaces since adjacencies on wireless interfaces are incongruent for different routers due to radio propagation. An alternative form of IGMP/MLD query and response might be implemented where all routers send queries without observing the Querier Election provisions and MANET hosts would select (e.g., based on querier address or link quality) the router to which to direct their responses (i.e., address the reply to a specific router). This issue needs further study and may be addressed in a later version of this draft or other documents.
In the case #1, the Elastic Multicast router may directly receive group membership join and leave notifications via operating system or implementation-specific mechanisms. In the case #2, the Elastic Multicast router should perform IGMP or MLD query functions per are
In any case, once an Elastic Multicast router has determined local host subscription(s), it will provide EM-ACK messages for subscribed groups and perform multicast forwarding per this specification.
Elastic Multicast can be compatible with other multicast routing protocols (e.g. PIM) if border gateway provisions are met. Given the similarities to PIM-DM, this allows a relatively straight forward interconnection with PIM-DM domains. Elastic Multicast gateways can forward multicast traffic received from their PIM-DM neighbors towards the MANET and send PIM join and leave messages to the upstream PIM routers based on the subscription of other routers in the MANET. Similarly, on the egress side Elastic Multicast gateways can act as subscribers to groups for which they receive PIM join messages from their downstream PIM routers. In the case where the Elastic Multicast routing area is a stub network, the adjacent gateway routing protocol membership information can be used to manage Elastic Multicast behavior in the same manner as host group membership for traffic that egresses the Elastic Multicast area. Group membership subscription needs to be aggregated from within the Elastic Multicast area and provided to the gateway router so that appropriate multicast traffic from external networks will be routed to the Elastic Multicast area. An approach to do this is described in [CDHM07]. Additionally, an extended approach that allows for multiple gateways is describe in [DHS08]. Further consider of border gateway operation, including cases where the Elastic Multicast area is a transit domain, may be addressed in future revisions of this draft.
(TBD - We can refer to the SMF Security Considerations as applicable, the PacketBB-Sec document, etc. Some security for the EM-ACK messages should be provided via PacketBB-Sec)
(TBD - Call out any IANA assignments that need to be made. Most notably this will be the Elastic Multicast message types in the PacketBB message type namespace, a registry for any Elastic Multicast message TLVs, and those specific TLVs.)
(TBD)
The RFC text was produced using Marshall Rose's xml2rfc tool and Bill Fenner's XMLmind add-ons.