Internet DRAFT - draft-adamson-elasticmcast

draft-adamson-elasticmcast







Network Working Group                                         B. Adamson
Internet-Draft                                 Naval Research Laboratory
Intended status: Experimental                                 C. Danilov
Expires: May 09, 2014                                 Boeing Corporation
                                                               J. Macker
                                               Naval Research Laboratory
                                                       November 05, 2013


                   Elastic Multicast Routing Protocol
                     draft-adamson-elasticmcast-00

Abstract

   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.

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 May 09, 2014.





Adamson, et al.           Expires May 09, 2014                  [Page 1]

Internet-Draft              Elastic Multicast              November 2013


Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   5
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Control Message Formats . . . . . . . . . . . . . . . . . . .   6
     5.1.  Elastic Multicast Acknowledgment (EM-ACK) . . . . . . . .   7
     5.2.  Elastic Multicast Advertisement (EM-ADV)  . . . . . . . .   7
   6.  Detailed Protocol Operation . . . . . . . . . . . . . . . . .   8
     6.1.  Elastic Multicast Timers  . . . . . . . . . . . . . . . .  11
   7.  SMF Relay Set Algorithm Considerations  . . . . . . . . . . .  11
   8.  IGMP and MLD Considerations . . . . . . . . . . . . . . . . .  12
   9.  Border Gateway Considerations . . . . . . . . . . . . . . . .  13
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     13.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   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,



Adamson, et al.           Expires May 09, 2014                  [Page 2]

Internet-Draft              Elastic Multicast              November 2013


   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.



Adamson, et al.           Expires May 09, 2014                  [Page 3]

Internet-Draft              Elastic Multicast              November 2013


   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.

2.  Terminology

   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        |



Adamson, et al.           Expires May 09, 2014                  [Page 4]

Internet-Draft              Elastic Multicast              November 2013


            | NHDP         | Neighborhood Discovery Protocol |
            | DPD          | Duplicate Packet Detection      |
            | FIB          | Forwarding Information Base     |
            | TLV          | type-length-value encoding      |
            +--------------+---------------------------------+


3.  Applicability Statement

   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]

   and Single Source Multicast (SSM) [RFC4607] models of multicast group
   membership.

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

4.  Overview

   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



Adamson, et al.           Expires May 09, 2014                  [Page 5]

Internet-Draft              Elastic Multicast              November 2013


   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.

5.  Control Message Formats

   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.




Adamson, et al.           Expires May 09, 2014                  [Page 6]

Internet-Draft              Elastic Multicast              November 2013


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

5.1.  Elastic Multicast Acknowledgment (EM-ACK)

   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:

   o  router-id: A unique, addressable identifier for the intended
      "upstream" router.  For example, in a broadcast wireless medium it
      can be the source Ethernet address of the original data multicast
      packet that is acknowledged.

   o  source-addr: The source IP address of the multicast packet being
      acknowledged

   o  group-addr: The destination IP multicast address of the packet
      being acknowledged

   A standard MANET packet building block [RFC5444] message format for
   the EM-ACK message will be specified in a future revision of this
   document.

5.2.  Elastic Multicast Advertisement (EM-ADV)

   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.



Adamson, et al.           Expires May 09, 2014                  [Page 7]

Internet-Draft              Elastic Multicast              November 2013


   Each EM-ADV message consists of a list of active multicast flow
   descriptions, each with the following fields:

   o  group-addr: IP multicast group destination address of active flow
      being advertised

   o  Source address: IP source address of flow

   o  Protocol: IP protocol id of flow

   o  Traffic class: IPv4 TOS / IPv6 traffic class of flow

   o  Token bucket parameters: bucket depth and rate

   o  Tagger identifier (Tagger-ID): address of router originating this
      flow description

   o  Duplicate packet detection identifier (DPD-ID): DPD-ID of packet
      triggering this flow description

   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.

6.  Detailed Protocol Operation

   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.





Adamson, et al.           Expires May 09, 2014                  [Page 8]

Internet-Draft              Elastic Multicast              November 2013


   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



Adamson, et al.           Expires May 09, 2014                  [Page 9]

Internet-Draft              Elastic Multicast              November 2013


   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 (Section 8).

   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



Adamson, et al.           Expires May 09, 2014                 [Page 10]

Internet-Draft              Elastic Multicast              November 2013


   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.

6.1.  Elastic Multicast Timers

   _TBD - describe the timers that control EM-ACK transmission and per-
   flow high rate forwarding activation / deactivation._

7.  SMF Relay Set Algorithm Considerations

   SMF has the ability to select only some of the nodes to participate
   in the forwarding mechanism, such that in relatively dense areas, if



Adamson, et al.           Expires May 09, 2014                 [Page 11]

Internet-Draft              Elastic Multicast              November 2013


   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.

8.  IGMP and MLD Considerations

   The Elastic Multicast nodes act as regular multicast routers for
   local hosts subscribing to multicast groups.  A local host can be:

   1.  an application residing on the same network node as the router,

   2.  a device attached directly to one of the non-MANET router
       interfaces, or

   3.  a separate neighboring host in the wireless network that does not
       have multicast routing capability but rather relies on the
       Elastic Multicast routers to forward their data appropriately.

   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
   IGMP [RFC3376] and MLD [RFC3810], respectively.  For the case #3,
   standard IGMP or MLD operation is not sufficient for operation on



Adamson, et al.           Expires May 09, 2014                 [Page 12]

Internet-Draft              Elastic Multicast              November 2013


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

9.  Border Gateway Considerations

   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.

10.  Security Considerations

   _(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)_

11.  IANA Considerations




Adamson, et al.           Expires May 09, 2014                 [Page 13]

Internet-Draft              Elastic Multicast              November 2013


   _(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.)_

12.  Acknowledgments

   _(TBD)_

      Some core contributors/authors in alphabetical order:

      Tom Henderson, et al

   The RFC text was produced using Marshall Rose's xml2rfc tool and Bill
   Fenner's XMLmind add-ons.

13.  References

13.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2644]  Senie, D., "Changing the Default for Directed Broadcasts
              in Routers", BCP 34, RFC 2644, August 1999.

   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
              Values In the Internet Protocol and Related Headers", BCP
              37, RFC 2780, March 2000.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol (OLSR)", RFC 3626, October 2003.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.



Adamson, et al.           Expires May 09, 2014                 [Page 14]

Internet-Draft              Elastic Multicast              November 2013


   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
              Format", RFC 5444, February 2009.

   [RFC5614]  Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET)
              Extension of OSPF Using Connected Dominating Set (CDS)
              Flooding", RFC 5614, August 2009.

   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
              March 2010.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, April 2011.

   [RFC6621]  Macker, J., "Simplified Multicast Forwarding", RFC 6621,
              May 2012.

13.2.  Informative References

   [CDHM07]   Chakeres, I., Danilov, C., and T. Henderson, "Connecting
              MANET Multicast", IEEE MILCOM 2007 Proceedings , 2007.

   [CH2012]   Danilov, C., Henderson, T., Brewer, O., Kim, J., Macker,
              J., and B. Adamson, "Elastic Multicast for Tactical
              Networks", IEEE MILCOM 2012 , October 2012.

   [DHS08]    Danilov, C., Henderson, T., and T. Spagnolo, "MANET
              Multicast with Multiple Gateways", IEEE MILCOM 2008
              Proceedings , 2008.

   [GM99]     Garcia-Luna-Aceves, JJ. and E. Madruga, "The core-assisted
              mesh protocol", Selected Areas in Communications, IEEE
              Journal on Volume 17, Issue 8, August 1999.

   [JLMV02]   Jacquet, P., Laouiti, V., Minet, P., and L. Viennot,
              "Performance of multipoint relaying in ad hoc mobile
              routing protocols", Networking , 2002.





Adamson, et al.           Expires May 09, 2014                 [Page 15]

Internet-Draft              Elastic Multicast              November 2013


   [MDC04]    Macker, J., Dean, J., and W. Chao, "Simplified Multicast
              Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004
              Proceedings , 2004.

   [MDDA07]   Macker, J., Downard, I., Dean, J., and R. Adamson,
              "Evaluation of distributed cover set algorithms in mobile
              ad hoc network for simplified multicast forwarding", ACM
              SIGMOBILE Mobile Computing and Communications Review
              Volume 11 , Issue 3, July 2007.

   [MGL04]    Mohapatra, P., Gui, C., and J. Li, "Group Communications
              in Mobile Ad hoc Networks", IEEE Computer Vol. 37, No. 2,
              February 2004.

   [RFC2501]  Corson, M. and J. Macker, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501, January 1999.

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

Authors' Addresses

   Brian Adamson
   Naval Research Laboratory
   Washington, DC  20375
   USA

   Email: brian.adamson@nrl.navy.mil


   Claudiu Danilov
   Boeing Corporation
   Seattle, WA
   USA

   Email: Claudiu.B.Danilov@boeing.com









Adamson, et al.           Expires May 09, 2014                 [Page 16]

Internet-Draft              Elastic Multicast              November 2013


   Joseph Macker
   Naval Research Laboratory
   Washington, DC  20375
   USA

   Email: joseph.macker@nrl.navy.mil













































Adamson, et al.           Expires May 09, 2014                 [Page 17]