tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7450

 
 
 

Automatic Multicast Tunneling

Part 2 of 4, p. 6 to 30
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 6 
4.  Protocol Overview

   This section provides an informative description of the protocol.  A
   normative description of the protocol and implementation requirements
   may be found in Section 5.

4.1.  General Architecture

   Isolated Site |    Unicast Network   |  Native Multicast
                 |      (Internet)      |
                 |                      |
                 |                      |
                 |   Group Membership   |
      +-------+ =========================> +-------+ Multicast +------+
      |Gateway|  |                      |  | Relay |<----//----|Source|
      +-------+ <========================= +-------+           +------+
                 |   Multicast Data     |
                 |                      |
                 |                      |

                     Figure 1: Basic AMT Architecture

   The AMT protocol employs a client-server model in which a "gateway"
   sends requests to receive specific multicast traffic to a "relay"
   that responds by delivering the requested multicast traffic back to
   the gateway.

   Gateways are generally deployed within networks that lack multicast
   support or lack connectivity to a multicast-enabled network
   containing multicast sources of interest.

   Relays are deployed within multicast-enabled networks that contain,
   or have connectivity to, multicast sources.

4.1.1.  Relationship to IGMP and MLD Protocols

   AMT relies on the Internet Group Management Protocol (IGMP) [RFC3376]
   and the Multicast Listener Discovery (MLD) protocol [RFC3810] to
   provide the functionality required to manage, communicate, and act on
   changes in multicast group membership.  A gateway or relay
   implementation does not necessarily require a fully functional,
   conforming implementation of IGMP or MLD to adhere to this

Top      Up      ToC       Page 7 
   specification, but the protocol description that appears in this
   document assumes that this is the case.  The minimum functional and
   behavioral requirements for the IGMP and MLD protocols are described
   in Sections 5.2.1 and 5.3.1.

               Gateway                          Relay

                 General _____         _____
     ___________  Query |     |       |     | Query  ___________
    |           |<------|     |       |     |<------|           |
    | Host-Mode |       | AMT |       | AMT |       |Router-Mode|
    | IGMP/MLD  |       |     |  UDP  |     |       | IGMP/MLD  |
    |___________|------>|     |<----->|     |------>|___________|
                 Report |     |       |     | Report
             Leave/Done |     |       |     | Leave/Done
                        |     |       |     |
    IP Multicast <------|     |       |     |<------ IP Multicast
                        |_____|       |_____|

          Figure 2: Multicast Reception State Managed by IGMP/MLD

   A gateway runs the host portion of the IGMP and MLD protocols to
   generate group membership updates that are sent via AMT messages to a
   relay.  A relay runs the router portion of the IGMP and MLD protocols
   to process the group membership updates to produce the required
   changes in multicast forwarding state.  A relay uses AMT messages to
   send incoming multicast IP datagrams to gateways according to their
   current group membership state.

   The primary function of AMT is to provide the handshaking,
   encapsulation, and decapsulation required to transport the IGMP and
   MLD messages and multicast IP datagrams between the gateways and
   relays.  The IGMP and MLD messages that are exchanged between
   gateways and relays are encapsulated as complete IP datagrams within
   AMT control messages.  Multicast IP datagrams are replicated and
   encapsulated in AMT data messages.  All AMT messages are sent via
   unicast UDP/IP.

4.1.2.  Gateways

   The downstream side of a gateway services one or more receivers --
   the gateway accepts group membership requests from receivers and
   forwards requested multicast traffic back to those receivers.  The
   gateway functionality may be directly implemented in the host
   requesting the multicast service or within an application running on
   a host.

Top      Up      ToC       Page 8 
   The upstream side of a gateway connects to relays.  A gateway sends
   encapsulated IGMP and MLD messages to a relay to indicate an interest
   in receiving specific multicast traffic.

4.1.2.1.  Architecture

   Each gateway possesses a logical pseudo-interface:

     join/leave ---+                   +----------+
                   |                   |          |
                   V      IGMPv3/MLDv2 |          |
              +---------+ General Query|          |   AMT
              |IGMP/MLD |<-------------|   AMT    | Messages +------+
              |Host-Mode|              | Gateway  |<-------->|UDP/IP|
              |Protocol |------------->|Pseudo-I/F|          +------+
              +---------+   IGMP/MLD   |          |             ^
                             Report    |          |             |
                           Leave/Done  |          |             V
    IP Multicast <---------------------|          |           +---+
                                       +----------+           |I/F|
                                                              +---+

                  Figure 3: AMT Gateway Pseudo-Interface

   The pseudo-interface is conceptually a network interface on which the
   gateway executes the host portion of the IPv4/IGMP (v2 or v3) and
   IPv6/MLD (v1 or v2) protocols.  The multicast reception state of the
   pseudo-interface is manipulated using the IGMP or MLD service
   interface.  The IGMP and MLD host protocols produce IP datagrams
   containing group membership messages that the gateway will send to
   the relay.  The IGMP and MLD protocols also supply the retransmission
   and timing behavior required for protocol robustness.

   All AMT encapsulation, decapsulation, and relay interaction are
   assumed to occur within the pseudo-interface.

   A gateway host or application may create separate interfaces for
   IPv4/IGMP and IPv6/MLD.  A gateway host or application may also
   require additional pseudo-interfaces for each source or domain-
   specific relay address.

   Within this document, the term "gateway" may be used as a generic
   reference to an entity executing the gateway protocol, a gateway
   pseudo-interface, or a gateway device that has one or more interfaces
   connected to a unicast internetwork and one or more AMT gateway
   pseudo-interfaces.

Top      Up      ToC       Page 9 
   The following diagram illustrates how an existing host IP stack
   implementation might be used to provide AMT gateway functionality to
   a multicast application:

           +-----------------------------------------------------+
           |Host                                                 |
           |    ______________________________________           |
           |   |                                      |          |
           |   |    ___________________________       |          |
           |   |   |                           |      |          |
           |   |   |                           v      |          |
           |   |   |        +-----------+  +--------------+      |
           |   |   |        |Application|  |  AMT Daemon  |      |
           |   |   |        +-----------+  +--------------+      |
           |   |   | join/leave |   ^ data        ^ AMT          |
           |   |   |            |   |             |              |
           |   |   |       +----|---|-------------|-+            |
           |   |   |       |  __|   |_________    | |            |
           |   |   |       | |                |   | |            |
           |   |   |       | |       Sockets  |   | |            |
           |   |   |       +-|------+-------+-|---|-+            |
           |   |   |       | | IGMP |  TCP  | |UDP| |            |
           |   |   |       +-|------+-------+-|---|-+            |
           |   |   |       | | ^       IP     |   | |            |
           |   |   |       | | |  ____________|   | |            |
           |   |   |       | | | |                | |            |
           |   |   |       +-|-|-|----------------|-+            |
           |   |   |         | | |                |              |
           |   |   | IP(IGMP)| | |IP(UDP(data))   |IP(UDP(AMT))  |
           |   |   |         v | |                v              |
           |   |   |     +-----------+          +---+            |
           |   |   |     |Virtual I/F|          |I/F|            |
           |   |   |     +-----------+          +---+            |
           |   |   |         |   ^                ^              |
           |   |   | IP(IGMP)|   |IP(UDP(data))   |              |
           |   |   |_________|   |IP(IGMP)        |              |
           |   |                 |                |              |
           |   |_________________|                |              |
           |                                      |              |
           +--------------------------------------|--------------+
                                                  v
                                              AMT Relay

            Figure 4: Virtual Interface Implementation Example

   In this example, the host IP stack uses a virtual network interface
   to interact with a gateway pseudo-interface implementation.

Top      Up      ToC       Page 10 
4.1.2.2.  Use Cases

   Use cases for gateway functionality include the following:

   IGMP/MLD Proxy
      An IGMP/MLD proxy that runs AMT on an upstream interface and
      router-mode IGMP/MLD on downstream interfaces to provide host
      access to multicast traffic via the IGMP and MLD protocols.

   Virtual Network Interface
      A virtual network interface or pseudo-network device driver that
      runs AMT on a physical network interface to provide socket-layer
      access to multicast traffic via the IGMP/MLD service interface
      provided by the host IP stack.

   Application
      An application or application component that implements and
      executes IGMP/MLD and AMT internally to gain access to multicast
      traffic.

4.1.3.  Relays

   The downstream side of a relay services gateways -- the relay accepts
   encapsulated IGMP and MLD group membership messages from gateways and
   encapsulates and forwards the requested multicast traffic back to
   those gateways.

   The upstream side of a relay communicates with a native multicast
   infrastructure -- the relay sends join and prune/leave requests
   towards multicast sources and accepts requested multicast traffic
   from those sources.

Top      Up      ToC       Page 11 
4.1.3.1.  Architecture

   Each relay possesses a logical pseudo-interface:

                                       +------------------------------+
                     +--------+        | Multicast Control Plane      |
                     |        |IGMP/MLD|                              |
                     |        | Query* | +------------+  +----------+ |
                     |        |<---//----|IGMPv3/MLDv2|  |Multicast | |
              AMT    |        |        | |Router-Mode |->|Routing   |<->
   +------+ Messages | AMT    |----//--->|Protocol    |  |Protocol  | |
   |UDP/IP|<-------->| Relay  |IGMP/MLD| +------------+  +----------+ |
   +------+          | Pseudo-| Report |      |               |       |
      ^              | I/F    | Leave/ +------|---------------|-------+
      |              |        |  Done         |               |
      |              |        |               v               |
      V              |        | IP        +-----------+       |
    +---+            |        | Multicast |Multicast  |<------+
    |I/F|            |        |<---//-----|Forwarding |
    +---+            +--------+           |Plane      |<--- IP Multicast
                                          +-----------+

    * Queries, if generated, are consumed by the pseudo-interface.

            Figure 5: AMT Relay Pseudo-Interface (Router-Based)

   The pseudo-interface is conceptually a network interface on which the
   relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2
   protocols.  Relays do not send unsolicited IGMPv3/MLDv2 query
   messages to gateways so relays must consume or discard any local
   queries normally generated by IGMPv3 or MLDv2.  Note that the
   protocol mandates the use of IGMPv3 and MLDv2 for query messages.
   The AMT protocol is primarily intended for use in SSM applications
   and relies on several values provided by IGMPv3/MLDv2 to control
   gateway behavior.

   A relay maintains group membership state for each gateway connected
   through the pseudo-interface as well as for the entire
   pseudo-interface (if multiple gateways are managed via a single
   interface).  Multicast packets received on upstream interfaces on the
   relay are routed to the pseudo-interface where they are replicated,
   encapsulated, and sent to interested gateways.  Changes in the
   pseudo-interface group membership state may trigger the transmission
   of multicast protocol requests upstream towards a given source or
   rendezvous point and cause changes in internal routing/forwarding
   state.

Top      Up      ToC       Page 12 
   The relay pseudo-interface is an architectural abstraction used to
   describe AMT protocol operation.  For the purposes of this document,
   the pseudo-interface is most easily viewed as an interface to a
   single gateway -- encapsulation, decapsulation, and other
   AMT-specific processing occurs "within" the pseudo-interface while
   forwarding and replication occur outside of it.

   An alternative view is to treat the pseudo-interface as a
   non-broadcast multi-access (NBMA) network interface whose link layer
   is the unicast-only network over which AMT messages are exchanged
   with gateways.  Individual gateways are conceptually treated as
   logical NBMA links on the interface.  In this architectural model,
   group membership tracking, replication, and forwarding functions
   occur in the pseudo-interface.

   This document does not specify any particular architectural solution
   -- a relay developer may choose to implement and distribute protocol
   functionality as required to take advantage of existing relay
   platform services and architecture.

   Within this document, the term "relay" may be used as a generic
   reference to an entity executing the relay protocol, a relay
   pseudo-interface, or a relay device that has one or more network
   interfaces with multicast connectivity to a native multicast
   infrastructure, zero or more interfaces connected to a unicast
   internetwork, and one or more relay pseudo-interfaces.

4.1.3.2.  Use Cases

   Use cases for relay functionality include the following:

   Multicast Router
      A multicast router that runs AMT on a downstream interface to
      provide gateway access to multicast traffic.  A "relay router"
      uses a multicast routing protocol (e.g., PIM-SM [RFC4601]) to
      construct a forwarding path for multicast traffic by sending join
      and prune messages to neighboring routers to join or leave
      multicast distribution trees for a given SSM source or ASM
      rendezvous point.

   IGMP/MLD Proxy Router
      An IGMP/MLD proxy that runs AMT on a downstream interface and
      host-mode IGMPv3/MLDv2 on an upstream interface.  This "relay
      proxy" sends group membership reports to a local, multicast-
      enabled router to join and leave specific SSM or ASM groups.

Top      Up      ToC       Page 13 
4.1.4.  Deployment

   The AMT protocol calls for a relay deployment model that uses anycast
   addressing [RFC1546] [RFC4291] to pair gateways with relays.

   Under this approach, one or more relays advertise a route for the
   same IP address prefix.  To find a relay with which to communicate, a
   gateway sends a message to an anycast IP address within that prefix.
   This message is routed to the topologically nearest relay that has
   advertised the prefix.  The relay that receives the message responds
   by sending its unicast address back to the gateway.  The gateway uses
   this address as the destination address for any messages it
   subsequently sends to the relay.

   The use of anycast addressing provides the following benefits:

   o  Relays may be deployed at multiple locations within a single
      multicast-enabled network.  Relays might be installed "near"
      gateways to reduce bandwidth requirements and latency and to limit
      the number of gateways that might be serviced by a single relay.

   o  Relays may be added or removed at any time, thereby allowing
      staged deployment, scaling, and hot-swapping -- the relay
      discovery process will always return the nearest operational
      relay.

   o  Relays may take themselves offline when they exhaust resources
      required to service additional gateways.  Existing gateway
      connections may be preserved, but new gateway requests would be
      routed to the next-nearest relay.

4.1.4.1.  Public versus Private

   Ideally, the AMT protocol would provide a universal solution for
   connecting receivers to multicast sources, so that any gateway could
   be used to access any globally advertised multicast source via
   publicly accessible, widely deployed relays.  Unfortunately, today's
   Internet does not yet allow this, because many relays will lack
   native multicast access to sources even though they may be globally
   accessible via unicast.

   In these cases, a provider may deploy relays within their own source
   network to allow for multicast distribution within that network.
   Gateways that use these relays must use a provider-specific relay
   discovery mechanism or a private anycast address to obtain access to
   these relays.

Top      Up      ToC       Page 14 
4.1.4.2.  Congestion Considerations

   AMT relies on UDP to provide best-effort delivery of multicast data
   to gateways.  Neither AMT nor UDP provides the congestion control
   mechanisms required to regulate the flow of data messages passing
   through a network.  While congestion remediation might be provided by
   multicast receiver applications via multicast group selection or
   upstream reporting mechanisms, there are no means by which to ensure
   that such mechanisms are employed.  To limit the possible congestion
   across a network or wider Internet, AMT service providers are
   expected to deploy AMT relays near the provider's network border and
   its interface with edge routers.  The provider must limit relay
   address advertisements to those edges to prevent distant gateways
   from being able to access a relay and potentially generate flows that
   consume or exceed the capacity of intervening links.

4.1.5.  Discovery

   To execute the gateway portion of the protocol, a gateway requires a
   unicast IP address of an operational relay.  This address may be
   obtained using a number of methods -- it may be statically assigned
   or dynamically chosen via some form of relay discovery process.

   As described in the previous section, the AMT protocol provides a
   relay discovery method that relies on anycast addressing.  Gateways
   are not required to use AMT relay discovery, but all relay
   implementations must support it.

   The AMT protocol uses the following terminology when describing the
   discovery process:

   Relay Discovery Address Prefix:
      The anycast address prefix used to route discovery messages to a
      relay.

   Relay Discovery Address:
      The anycast destination address used when sending discovery
      messages.

   Relay Address:
      The unicast IP address obtained as a result of the discovery
      process.

4.1.5.1.  Relay Discovery Address Selection

   The selection of an anycast Relay Discovery Address may be source
   dependent, as a relay located via relay discovery must have multicast
   connectivity to a desired source.

Top      Up      ToC       Page 15 
   Similarly, the selection of a unicast Relay Address may be source
   dependent, as a relay contacted by a gateway to supply multicast
   traffic must have native multicast connectivity to the traffic
   source.

   Methods that might be used to perform source-specific or
   group-specific relay selection are highly implementation dependent
   and are not further addressed by this document.  Possible approaches
   include the use of static lookup tables, DNS-based queries, or a
   provision of a service interface that accepts join requests on
   (S,G,relay-discovery-address) or (S,G,relay-address) tuples.

4.1.5.2.  Relay Discovery Address Prefix

   IANA has assigned IPv4 and IPv6 address prefixes for use in
   advertising and discovering publicly accessible relays.

   A Relay Discovery Address is constructed from an address prefix by
   setting the low-order octet of the prefix address to 1 (for both IPv4
   and IPv6).  All remaining addresses within each prefix are reserved
   for future use.

   Public relays must advertise a route to the address prefix (e.g., via
   BGP [RFC4271]) and configure an interface to respond to the Relay
   Discovery Address.

   The discovery address prefixes are described in Section 7.

4.2.  General Operation

4.2.1.  Message Sequences

   The AMT protocol defines the following messages for control and
   encapsulation.  These messages are exchanged as UDP/IP datagrams, one
   message per datagram.

   Relay Discovery:
      Sent by gateways to solicit a Relay Advertisement from any relay.
      Used to find a relay with which to communicate.

   Relay Advertisement:
      Sent by relays as a response to a Relay Discovery message.  Used
      to deliver a Relay Address to a gateway.

   Request:
      Sent by gateways to solicit a Membership Query message from a
      relay.

Top      Up      ToC       Page 16 
   Membership Query:
      Sent by relays as a response to a Request message.  Used to
      deliver an encapsulated IGMPv3 or MLDv2 query message to the
      gateway.

   Membership Update:
      Sent by gateways to deliver an encapsulated IGMP or MLD
      report/leave/done message to a relay.

   Multicast Data:
      Sent by relays to deliver an encapsulated IP multicast datagram or
      datagram fragment to a gateway.

   Teardown:
      Sent by gateways to stop the delivery of Multicast Data messages
      requested in an earlier Membership Update message.

   The following sections describe how these messages are exchanged to
   execute the protocol.

4.2.1.1.  Relay Discovery Sequence

                       Gateway               Relay
                       -------               -----
                          :                    :
                          |                    |
                      [1] |Relay Discovery     |
                          |------------------->|
                          |                    |
                          | Relay Advertisement| [2]
                          |<-------------------|
                      [3] |                    |
                          :                    :

                  Figure 6: AMT Relay Discovery Sequence

Top      Up      ToC       Page 17 
   The following sequence describes how the Relay Discovery and Relay
   Advertisement messages are used to find a relay with which to
   communicate:

   1.  The gateway sends a Relay Discovery message containing a random
       nonce to the Relay Discovery Address.  If the Relay Discovery
       Address is an anycast address, the message is routed to the
       topologically nearest network node that advertises that address.

   2.  The node receiving the Relay Discovery message sends a Relay
       Advertisement message back to the source of the Relay Discovery
       message.  The message carries a copy of the nonce contained in
       the Relay Discovery message and the unicast IP address of a
       relay.

   3.  When the gateway receives the Relay Advertisement message, it
       verifies that the nonce matches the one sent in the Relay
       Discovery message and, if it does, uses the Relay Address carried
       by the Relay Advertisement as the destination address for
       subsequent AMT messages.

   Note that the responder need not be a relay -- the responder may
   obtain a Relay Address by some other means and return the result in
   the Relay Advertisement (i.e., the responder is a load-balancer or
   broker).

4.2.1.2.  Membership Update Sequence

   There exists a significant difference between normal IGMP and MLD
   behavior and that required by AMT.  An IGMP/MLD router acting as a
   querier normally transmits query messages on a network interface to
   construct and refresh group membership state for the connected
   network.  These query messages are multicast to all IGMP/MLD-enabled
   hosts on the network.  Each host responds by multicasting report
   messages that describe their current multicast reception state.

   However, AMT does not allow relays to send unsolicited query messages
   to gateways, as the set of active gateways may be unknown to the
   relay and potentially quite large.  Instead, AMT requires each
   gateway to periodically send a message to a relay to solicit a query
   response.  A gateway accomplishes this by sending a Request message
   to a relay.  The relay responds by sending a Membership Query message
   back to the gateway.  The Membership Query message carries an
   encapsulated query that is processed by the IGMP or MLD protocol
   implementation on the gateway to produce a membership/listener
   report.  Each time the gateway receives a Membership Query message,
   it starts a timer whose expiration will trigger the start of a new
   Request->Membership Query message exchange.  This timer-driven

Top      Up      ToC       Page 18 
   sequence is used to mimic the transmission of a periodic query by an
   IGMP/MLD router.  This query cycle may continue indefinitely once
   started by sending the initial Request message.

   A membership update occurs when an IGMP or MLD report, leave, or done
   message is passed to the gateway pseudo-interface.  These messages
   may be produced as a result of the aforementioned query processing or
   as a result of receiver interaction with the IGMP/MLD service
   interface.  Each report is encapsulated and sent to the relay after
   the gateway has successfully established communication with the relay
   via a Request and Membership Query message exchange.  If a report is
   passed to the pseudo-interface before the gateway has received a
   Membership Query message from the relay, the gateway may discard the
   report or queue the report for delivery after a Membership Query is
   received.  Subsequent IGMP/MLD report/leave/done messages that are
   passed to the pseudo-interface are immediately encapsulated and
   transmitted to the relay.

Top      Up      ToC       Page 19 
           IGMP/MLD             Pseudo-I/F              Relay
           --------             ----------              -----
              :                     :                     :
              |                     |       Request       |
              |                    1|-------------------->|
              |                     |  Membership Query   |2
    Query     |                     |       Q(0,{})       |
    Timer     |         Start      3|<--------------------|
     (QT)<--------------------------|                     |
              |        Q(0,{})      |                     |
              |<--------------------|                     |
             4|         R({})       |  Membership Update  |
              |-------------------->|5       R({})        |
              |                     |====================>|6a
    Join(S,G) :                     :                     :
   ()-------->|7 R({G:ALLOW({S})})  |  Membership Update  |
              |-------------------->|8  R({G:ALLOW({S})}) |
              |                     |====================>|9a  Join(S,G)
              |                     |                     |---------->()
              :                     :                     :
              |         ------------|---------------------|------------
              |        |            |                     |            |
              |        |            |    Multicast Data   |  IP(S,G)   |
              |        |            |       IP(S,G)     10|<--------() |
              |        |  IP(S,G) 11|<====================|            |
              |        | ()<--------|                     |            |
              |        |            |                     |            |
              :         ------------:---------------------:------------
              |       Expired       |                     |
     (QT)-------------------------->|12      Request      |
              |                    1|-------------------->|
              |                     |  Membership Query   |2
              |                     |       Q(0,{})       |
              |        Start       3|<--------------------|
     (QT)<--------------------------|                     |
              |       Q(0,{})       |                     |
              |<--------------------|                     |
             4| R({G:INCLUDE({S})}) |  Membership Update  |
              |-------------------->|5 R({G:INCLUDE({S})})|
              |                     |====================>|6b
   Leave(S,G) :                     :                     :
   ()-------->|7 R({G:BLOCK({S})})  |  Membership Update  |
              |-------------------->|8  R({G:BLOCK({S})}) |
              |                     |====================>|9b Prune(S,G)
              |                     |                     |---------->()
              :                     :                     :

        Figure 7: Membership Update Sequence (IGMPv3/MLDv2 Example)

Top      Up      ToC       Page 20 
   The following sequence describes how the Request, Membership Query,
   and Membership Update messages are used to report current group
   membership state or changes in group membership state:

   1.   A gateway sends a Request message to the relay that contains a
        random nonce and a flag indicating whether the relay should
        return an IGMPv3 or MLDv2 General Query.

   2.   When the relay receives a Request message, it generates a
        message authentication code (MAC), typically, by computing a
        hash digest from the message source IP address, source UDP port,
        request nonce, and a private secret.  The relay then sends a
        Membership Query message to the gateway that contains the
        request nonce, the MAC, and an IGMPv3 or MLDv2 General Query.

   3.   When the gateway receives a Membership Query message, it
        verifies that the request nonce matches the one sent in the last
        Request, and if it does, the gateway saves the request nonce and
        MAC for use in sending subsequent Membership Update messages.
        The gateway starts a timer whose expiration will trigger the
        transmission of a new Request message and extracts the
        encapsulated General Query message for processing by the IGMP or
        MLD protocol.  The query timer duration is specified by the
        relay in the Querier's Query Interval Code (QQIC) field in the
        IGMPv3 or MLDv2 General Query.  The QQIC field is defined in
        Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]).

   4.   The gateway's IGMP or MLD protocol implementation processes the
        General Query to produce a current-state report.

   5.   When an IGMP or MLD report is passed to the pseudo-interface,
        the gateway encapsulates the report in a Membership Update
        message and sends it to the relay.  The request nonce and MAC
        fields in the Membership Update are assigned the values from the
        last Membership Query message received for the corresponding
        group membership protocol (IGMPv3 or MLDv2).

   6.   When the relay receives a Membership Update message, it computes
        a MAC from the message source IP address, source UDP port,
        request nonce, and a private secret.  The relay accepts the
        Membership Update message if the received MAC matches the
        computed MAC; otherwise, the message is ignored.  If the message
        is accepted, the relay may proceed to allocate, refresh, or
        modify tunnel state.  This includes making any group membership,

Top      Up      ToC       Page 21 
        routing, and forwarding state changes, and also issuing any
        upstream protocol requests required to satisfy the state change.
        The diagram illustrates two scenarios:

        A.  The gateway has not previously reported any group
            subscriptions and the report does not contain any group
            subscriptions, so the relay takes no action.

        B.  The gateway has previously reported a group subscription, so
            the current-state report lists all current subscriptions.
            The relay responds by refreshing tunnel or group state and
            resetting any related timers.

   7.   A receiver indicates to the gateway that it wishes to join
        (allow) or leave (block) specific multicast traffic.  This
        request is typically made using some form of IGMP/MLD service
        interface (as described in Section 2 of [RFC3376] and Section 3
        of [RFC3810]).  The IGMP/MLD protocol responds by generating an
        IGMP or MLD state-change message.

   8.   When an IGMP or MLD report/leave/done message is passed to the
        pseudo-interface, the gateway encapsulates the message in a
        Membership Update message and sends it to the relay.  The
        request nonce and MAC fields in the Membership Update are
        assigned the values from the last Membership Query message
        received for the corresponding group membership protocol (IGMP
        or MLD).

        The IGMP and MLD protocols may generate multiple messages to
        provide robustness against packet loss -- each of these must be
        encapsulated in a new Membership Update message and sent to the
        relay.  The Querier's Robustness Variable (QRV) field in the
        last IGMP/MLD query delivered to the IGMP/MLD protocol is
        typically used to specify the number of repetitions (i.e., the
        host adopts the QRV value as its own Robustness Variable value).
        The QRV field is defined in Section 4.1.6 of [RFC3376] and
        Section 5.1.8 of [RFC3810].

   9.   When the relay receives a Membership Update message, it again
        computes a MAC from the message source IP address, source UDP
        port, request nonce, and a private secret.  The relay accepts
        the Membership Update message if the received MAC matches the
        computed MAC; otherwise, the message is ignored.  If the message
        is accepted, the relay processes the encapsulated IGMP/MLD and
        allocates, modifies, or deletes tunnel state accordingly.  This
        includes making any group membership, routing, and forwarding

Top      Up      ToC       Page 22 
        state changes, and also issuing any upstream protocol requests
        required to satisfy the state change.  The diagram illustrates
        two scenarios:

        A.  The gateway wishes to add a group subscription.

        B.  The gateway wishes to delete a previously reported group
            subscription.

   10.  Multicast datagrams transmitted from a source travel through the
        native multicast infrastructure to the relay.  When the relay
        receives a multicast IP datagram that carries a source and
        destination address for which a gateway has expressed an
        interest in receiving (via the Membership Update message), it
        encapsulates the datagram into a Multicast Data message and
        sends it to the gateway using the source IP address and UDP port
        carried by the Membership Update message as the destination
        address.

   11.  When the gateway receives a Multicast Data message, it extracts
        the multicast packet from the message and passes it on to the
        appropriate receivers.

   12.  When the query timer expires, the gateway sends a new Request
        message to the relay to start a new membership update cycle.

   The MAC-based source-authentication mechanism described above
   provides a simple defense against malicious attempts to exhaust relay
   resources via source-address spoofing.  Flooding a relay with spoofed
   Request or Membership Update messages may consume computational
   resources and network bandwidth but will not result in the allocation
   of state, because the Request message is stateless and spoofed
   Membership Update messages will fail source authentication and be
   rejected by the relay.

   A relay will only allocate new tunnel state if the IGMP/MLD report
   carried by the Membership Update message creates one or more group
   subscriptions.

   A relay deallocates tunnel state after one of the following events:
   the gateway sends a Membership Update message containing a report
   that results in the deletion of all remaining group subscriptions,
   the IGMP/MLD state expires (due to lack of refresh by the gateway),
   or the relay receives a valid Teardown message from the gateway (see
   Section 4.2.1.3).

Top      Up      ToC       Page 23 
   A gateway that accepts or reports group subscriptions for both IPv4
   and IPv6 addresses will send separate Request and Membership Update
   messages for each protocol (IPv4/IGMP and IPv6/MLD).

4.2.1.3.  Teardown Sequence

   A gateway sends a Teardown message to a relay to request that it stop
   delivering Multicast Data messages to a tunnel endpoint created by an
   earlier Membership Update message.  This message is intended to be
   used following a gateway address change (see Section 4.2.2.1) to stop
   the transmission of undeliverable or duplicate Multicast Data
   messages.  Gateway support for the Teardown message is RECOMMENDED.
   Gateways are not required to send them and may instead rely on group
   membership to expire on the relay.

Top      Up      ToC       Page 24 
                      Gateway                  Relay
                      -------                  -----
                         :        Request        :
                     [1] |           N           |
                         |---------------------->|
                         |    Membership Query   | [2]
                         |    N,MAC,gADDR,gPORT  |
                         |<======================|
                     [3] |   Membership Update   |
                         |   ({G:INCLUDE({S})})  |
                         |======================>|
                         |                       |
    ---------------------:-----------------------:---------------------
   |                     |                       |                     |
   |                     |    *Multicast Data    |  *IP Packet(S,G)    |
   |                     |      gADDR,gPORT      |<-----------------() |
   |    *IP Packet(S,G)  |<======================|                     |
   | ()<-----------------|                       |                     |
   |                     |                       |                     |
    ---------------------:-----------------------:---------------------
                         ~                       ~
                         ~        Request        ~
                     [4] |           N'          |
                         |---------------------->|
                         |   Membership Query    | [5]
                         | N',MAC',gADDR',gPORT' |
                         |<======================|
                     [6] |                       |
                         |       Teardown        |
                         |   N,MAC,gADDR,gPORT   |
                         |---------------------->|
                         |                       | [7]
                         |   Membership Update   |
                         |  ({G:INCLUDE({S})})   |
                         |======================>|
                         |                       |
    ---------------------:-----------------------:---------------------
   |                     |                       |                     |
   |                     |    *Multicast Data    |  *IP Packet(S,G)    |
   |                     |     gADDR',gPORT'     |<-----------------() |
   |    *IP Packet (S,G) |<======================|                     |
   | ()<-----------------|                       |                     |
   |                     |                       |                     |
    ---------------------:-----------------------:---------------------
                         |                       |
                         :                       :

        Figure 8: Teardown Message Sequence (IGMPv3/MLDv2 Example)

Top      Up      ToC       Page 25 
   The following sequence describes how the Membership Query and
   Teardown messages are used to detect an address change and stop the
   delivery of Multicast Data messages to an address:

   1.  A gateway sends a Request message containing a random nonce to
       the relay.

   2.  The relay sends a Membership Query message to the gateway that
       contains the source IP address (gADDR) and source UDP port
       (gPORT) values from the Request message.  These values will be
       used to identify the tunnel should one be created by a subsequent
       Membership Update message.

   3.  When the gateway receives a Membership Query message that carries
       the gateway address fields, it compares the gateway IP address
       and UDP port number values with those received in the previous
       Membership Query (if any).  If these values do not match, this
       indicates that the Request message arrived at the relay carrying
       a different source address than the one sent previously.  At this
       point in the sequence, no change in source address or port has
       occurred.

   4.  The gateway sends a new Request message to the relay.  However,
       this Request message arrives at the relay carrying a different
       source address than that of the previous Request due to some
       change in network interface, address assignment, network
       topology, or NAT mapping.

   5.  The relay again responds by sending a Membership Query message to
       the gateway that contains the new source IP address (gADDR') and
       source UDP port (gPORT') values from the Request message.

   6.  When the gateway receives the Membership Query message, it
       compares the gateway address and port number values against those
       returned in the previous Membership Query message.

   7.  If the reported address or port has changed, the gateway sends a
       Teardown message to the relay that contains the request nonce,
       MAC, gateway IP address, and gateway port number returned in the
       earlier Membership Query message.  The gateway may send the
       Teardown message multiple times where the number of repetitions
       is governed by the Querier's Robustness Variable (QRV) value
       contained in the IGMPv3/MLDv2 General Query carried by the
       original Membership Query (see Section 4.1.6 of [RFC3376] and
       Section 5.1.8 of [RFC3810]).  The gateway continues to process
       the new Membership Query message as usual.

Top      Up      ToC       Page 26 
   8.  When the relay receives a Teardown message, it computes a MAC
       from the message source IP address, source UDP port, request
       nonce, and a private secret.  The relay accepts the Teardown
       message if the received MAC matches the computed MAC; otherwise,
       the message is ignored.  If the message is accepted, the relay
       makes any group membership, routing, and forwarding state changes
       required to stop the transmission of Multicast Data messages to
       that address.

4.2.1.4.  Timeout and Retransmission

   The AMT protocol does not establish any requirements regarding what
   actions a gateway should take if it fails to receive a response from
   a relay.  A gateway implementation may wait for an indefinite period
   of time to receive a response, may set a time limit on how long to
   wait for a response, may retransmit messages should the time limit be
   reached, may limit the number of retransmissions, or may simply
   report an error.

   For example, a gateway may retransmit a Request message if it fails
   to receive a Membership Query or expected Multicast Data messages
   within some time period.  If the gateway fails to receive any
   response to a Request after several retransmissions or within some
   maximum period of time, it may reenter the relay discovery phase in
   an attempt to find a new relay.  This topic is addressed in more
   detail in Section 5.2.

4.2.2.  Tunneling

   From the standpoint of a relay, an AMT "tunnel" is identified by the
   IP address and UDP port pair used as the destination address for
   sending encapsulated multicast IP datagrams to a gateway.  In this
   document, we refer to this address as the tunnel endpoint address.

   A gateway sends a Membership Update message to a relay to add or
   remove group subscriptions to a tunnel endpoint.  The tunnel endpoint
   is identified by the source IP address and source UDP port carried by
   the Membership Update message when it arrives at a relay (this
   address may differ from that carried by the message when it exited
   the gateway as a result of network address translation).

   The Membership Update messages sent by a single gateway host may
   originate from several source addresses or ports -- each unique
   combination represents a unique tunnel endpoint.  A single gateway
   host may legitimately create and accept traffic on multiple tunnel
   endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP
   and IPv6/MLD protocols.

Top      Up      ToC       Page 27 
   A tunnel is "created" when a gateway sends a Membership Update
   message containing an IGMP or MLD membership report that creates one
   or more group subscriptions when none currently existed for that
   tunnel endpoint address.

   A tunnel ceases to exist when all group subscriptions for a tunnel
   endpoint are deleted.  This may occur as a result of the following
   events:

   o  The gateway sends an IGMP or MLD report, leave, or done message to
      the relay that deletes the last group subscription linked to the
      tunnel endpoint.

   o  The gateway sends a Teardown message to the relay that causes it
      to delete any and all subscriptions bound to the tunnel endpoint.

   o  The relay stops receiving updates from the gateway until such time
      that per-group or per-tunnel timers expire, causing the relay to
      delete the subscriptions.

   The tunneling approach described above conceptually transforms a
   unicast-only internetwork into an NBMA link layer, over which
   multicast traffic may be delivered.  Each relay, plus the set of all
   gateways using the relay, together may be thought of as being on a
   separate logical NBMA link, where the "link layer" address is a UDP/
   IP address-port pair provided by the Membership Update message.

4.2.2.1.  Address Roaming

   As described above, each time a relay receives a Membership Update
   message from a new source address-port pair, the group subscriptions
   described by that message apply to the tunnel endpoint identified by
   that address.

   This can cause problems for a gateway if the address carried by the
   messages it sends to a relay changes unexpectedly.  These changes may
   cause the relay to transmit duplicate, undeliverable, or unrequested
   traffic back towards the gateway or an intermediate device.  This may
   create congestion and have negative consequences for the gateway, its
   network, or multicast receivers and in some cases may also produce a
   significant amount of ICMP traffic directed back towards the relay by
   a NAT, router, or gateway host.

Top      Up      ToC       Page 28 
   There are several scenarios in which the address carried by messages
   sent by a gateway may change without that gateway's knowledge -- for
   example, when:

   o  The message originates from a different interface on a gateway
      that possesses multiple interfaces.

   o  The DHCP assignment for a gateway interface changes.

   o  The gateway roams to a different wireless network.

   o  The address mapping applied by an intervening network-translation
      device (NAT) changes as a result of mapping expiration or routing
      changes in a multihomed network.

   In the case where the address change occurs between the transmission
   of a Request message and subsequent Membership Update messages, the
   relay will simply ignore any Membership Update messages from the new
   address because MAC authentication will fail (see Section 4.2.1.2).
   The relay may continue to transmit previously requested traffic, but
   no duplication will occur, i.e., the possibility for the delivery of
   duplicate traffic does not arise until a Request message is received
   from the new address.

   The protocol provides a method for a gateway to detect an address
   change and explicitly request that the relay stop sending traffic to
   a previous address.  This process involves the Membership Query and
   Teardown messages and is described in Section 4.2.1.3.

4.2.2.2.  Network Address Translation

   The messages sent by a gateway to a relay may be subject to network
   address translation (NAT) -- the source IP address and UDP port
   carried by an IP packet sent by the gateway may be modified multiple
   times before arriving at the relay.  In the most restrictive form of
   NAT, the NAT device will create a new mapping for each combination of
   source and destination IP address and UDP port.  In this case,
   bidirectional communication can only be conducted by sending outgoing
   packets to the source address and port carried by the last incoming
   packet.

Top      Up      ToC       Page 29 
            Membership Update                 Membership Update
            src: iADDR:iPORT                  src: eADDR:ePORT
            dst: rADDR:rPORT                  dst: rADDR:rPORT
                               +---------+
                               |   NAT   |
        +---------+           +-----------+          +---------+
        |         |---------->|           |--------->|         |
        | Gateway |           |  Mapping  |          |  Relay  |
        |         |<----------|           |<---------|         |
        +---------+           +-----------+          +---------+
                               |         |
                               +---------+
            Multicast Data                    Multicast Data
            src: rADDR:rPORT                  src: rADDR:rPORT
            dst: iADDR:iPORT                  dst: eADDR:ePORT

               Figure 9: Network Address Translation in AMT

   AMT provides automatic NAT traversal by using the source IP address
   and UDP port carried by the Membership Update message as received at
   the relay as the destination address for any Multicast Data messages
   the relay sends back as a result.

   The NAT mapping created by a Membership Update message will
   eventually expire unless it is refreshed by a passing message.  This
   refresh will occur each time the gateway performs the periodic update
   required to refresh group state within the relay (see
   Section 4.2.1.2).

4.2.2.3.  UDP Encapsulation

                Gateway                              Relay

           IP:IGMP                                       IP:IGMP
              |    AMT:IP:IGMP               AMT:IP:IGMP    |
              |         |                         |         |
              |         |   IP:UDP:AMT:IP:IGMP    |         |
    _______   |   ___   |   ______   |   ______   |   ___   |   _______
   |IGMP|IP|  v  |AMT|  v  |UDP|IP|  v  |IP|UDP|  v  |AMT|  v  |IP|IGMP|
   |    |  |     |   |     |   |  |     |  |   |     |   |     |  |    |
   |    |<------------------------------------------------------->|    |
   |____|  |     |   |     |   |  |     |  |   |     |   |     |  |____|
   |       |<--------------------------------------------------|       |
   |_______|  ^  |___|  ^  |___|__|  ^  |__|___|  ^  |___|  ^  |_______|
              |         |            |            |         |
             IP      AMT:IP    IP:UDP:AMT:IP    AMT:IP      IP

                       Figure 10: AMT Encapsulation

Top      Up      ToC       Page 30 
   The IGMP and MLD messages used in AMT are exchanged as complete IP
   datagrams.  These IP datagrams are encapsulated in AMT messages that
   are transmitted using UDP.  The same holds true for multicast traffic
   -- each multicast IP datagram or datagram fragment that arrives at
   the relay is encapsulated in an AMT message and transmitted to one or
   more gateways via UDP.

   The IP protocol of the encapsulated packets need not match the IP
   protocol used to send the AMT messages.  AMT messages sent via IPv4
   may carry IPv6/MLD packets, and AMT messages sent via IPv6 may carry
   IPv4/IGMP packets.

   The Checksum field contained in the UDP header of the messages
   requires special consideration.  Of primary concern is the cost of
   computing a checksum on each replicated multicast packet after it is
   encapsulated for delivery to a gateway.  Many routing/forwarding
   platforms do not possess the capability to compute checksums on
   UDP-encapsulated packets, as they may not have access to the entire
   datagram.

   To avoid placing an undue burden on the relay platform, the protocol
   specifically allows zero-valued UDP checksums on the Multicast Data
   messages.  This is not an issue in UDP over IPv4, as the UDP Checksum
   field may be set to zero.  However, this is a problem for UDP over
   IPv6, as that protocol requires a valid, non-zero checksum in UDP
   datagrams [RFC2460].  Messages sent over IPv6 with a UDP checksum of
   zero may fail to reach the gateway.  This is a well-known issue for
   UDP-based tunneling protocols and is described in [RFC6936].  A
   recommended solution is described in [RFC6935].

4.2.2.4.  UDP Fragmentation

   Naive encapsulation of multicast IP datagrams within AMT data
   messages may produce UDP datagrams that might require fragmentation
   if their size exceeds the MTU of the network path between the relay
   and a gateway.  Many multicast applications, especially those related
   to media streaming, are designed to deliver independent data samples
   in separate packets, without fragmentation, to ensure that some
   number of complete samples can be delivered even in the presence of
   packet loss.  To prevent or reduce undesirable fragmentation, the AMT
   protocol describes specific procedures for handling multicast
   datagrams whose encapsulation might exceed the Path MTU.  These
   procedures are described in Section 5.3.3.6.


Next RFC Part