RFC 7450
Automatic Multicast Tunneling
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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)
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,
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
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).
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.
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)
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.
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.
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.
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.
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
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 page on part 3)
