draft-ietf-mboned-driad-amt-discovery-06.txt   draft-ietf-mboned-driad-amt-discovery-07.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) May 06, 2019 Updates: 7450 (if approved) June 13, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: November 7, 2019 Expires: December 15, 2019
DNS Reverse IP AMT Discovery DNS Reverse IP AMT Discovery
draft-ietf-mboned-driad-amt-discovery-06 draft-ietf-mboned-driad-amt-discovery-07
Abstract Abstract
This document updates RFC 7450 (Automatic Multicast Tunneling, or This document updates RFC 7450 (Automatic Multicast Tunneling, or
AMT) by extending the relay discovery process to use a new DNS AMT) by extending the relay discovery process to use a new DNS
resource record named AMTRELAY when discovering AMT relays for resource record named AMTRELAY when discovering AMT relays for
source-specific multicast channels. The reverse IP DNS zone for a source-specific multicast channels. The reverse IP DNS zone for a
multicast sender's IP address is configured to use AMTRELAY resource multicast sender's IP address is configured to use AMTRELAY resource
records to advertise a set of AMT relays that can receive and forward records to advertise a set of AMT relays that can receive and forward
multicast traffic from that sender over an AMT tunnel. multicast traffic from that sender over an AMT tunnel.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 7, 2019. This Internet-Draft will expire on December 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 44 skipping to change at page 6, line 44
gateway, and conditions match the requirements outlined in gateway, and conditions match the requirements outlined in
Section 2.4. Section 2.4.
Some detailed example use cases are provided in Section 3, and other Some detailed example use cases are provided in Section 3, and other
applicable example topologies appear in Section 3.3 of [RFC8313], applicable example topologies appear in Section 3.3 of [RFC8313],
Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313].
2.2. Signaling and Discovery 2.2. Signaling and Discovery
This section describes a typical example of the end-to-end process This section describes a typical example of the end-to-end process
for signaling a receiver's join of a SSM channel that relies on an for signaling a receiver's join of an SSM channel that relies on an
AMTRELAY RR. AMTRELAY RR.
The example in Figure 2 contains 2 multicast-enabled networks that The example in Figure 2 contains 2 multicast-enabled networks that
are both connected to the internet with non-multicast-capable links, are both connected to the internet with non-multicast-capable links,
and which have no direct association with each other. and which have no direct association with each other.
A content provider operates a sender, which is a source of multicast A content provider operates a sender, which is a source of multicast
traffic inside a multicast-capable network. traffic inside a multicast-capable network.
An end user who is a customer of the content provider has a An end user who is a customer of the content provider has a
multicast-capable internet service provider, which operates a multicast-capable internet service provider, which operates a
receiving network that uses an AMT gateway. The AMT gateway is receiving network that uses an AMT gateway. The AMT gateway is
DRIAD-capable. DRIAD-capable.
The content provider provides the user with a receiving application The content provider provides the user with a receiving application
that tries to subscribe to at least one (S,G). This receiving that tries to subscribe to at least one (S,G). This receiving
application could for example be a file transfer system using FLUTE application could for example be a file transfer system using FLUTE
[RFC6726] or a live video stream using RTP [RFC3550], or any other [RFC6726] or a live video stream using RTP [RFC3550], or any other
application that might subscribe to a SSM channel. application that might subscribe to an SSM channel.
+---------------+ +---------------+
| Sender | | Sender |
| | | 198.51.100.15 | | | | 198.51.100.15 |
| | +---------------+ | | +---------------+
|Data| | |Data| |
|Flow| Multicast | |Flow| Multicast |
\| |/ Network | \| |/ Network |
\ / | 5: Propagate RPF for Join(S,G) \ / | 5: Propagate RPF for Join(S,G)
\ / +---------------+ \ / +---------------+
skipping to change at page 9, line 6 skipping to change at page 9, line 6
2.3. Happy Eyeballs 2.3. Happy Eyeballs
2.3.1. Overview 2.3.1. Overview
Often, multiple choices of relay will exist for a gateway using DRIAD Often, multiple choices of relay will exist for a gateway using DRIAD
for relay discovery. It is RECOMMENDED that DRIAD-capable gateways for relay discovery. It is RECOMMENDED that DRIAD-capable gateways
implement a Happy Eyeballs [RFC8305] algorithm to support connecting implement a Happy Eyeballs [RFC8305] algorithm to support connecting
to multiple relays in parallel. to multiple relays in parallel.
The parallel discovery logic of a Happy Eyeballs algorithm serves to The parallel discovery logic of a Happy Eyeballs algorithm serves to
reduce join latency for the initial join of a SSM channel. This reduce join latency for the initial join of an SSM channel. This
section and Section 2.4.2 taken together provide guidance on use of a section and Section 2.4.2 taken together provide guidance on use of a
Happy Eyeballs algorithm for the case of establishing AMT Happy Eyeballs algorithm for the case of establishing AMT
connections. connections.
2.3.2. Connection Definition 2.3.2. Connection Definition
Section 5 of [RFC8305] non-normatively describes success at a Section 5 of [RFC8305] non-normatively describes success at a
connection attempt as "generally when the TCP handshake completes". connection attempt as "generally when the TCP handshake completes".
There is no normative definition of a connection in the AMT There is no normative definition of a connection in the AMT
skipping to change at page 11, line 48 skipping to change at page 11, line 48
addresses from Section 7 of [RFC7450] to route discovery traffic addresses from Section 7 of [RFC7450] to route discovery traffic
to the relay most appropriate to the receiver's gateway. to the relay most appropriate to the receiver's gateway.
Accordingly, the gateway SHOULD by default discover a relay with Accordingly, the gateway SHOULD by default discover a relay with
the well-known AMT anycast addresses as the second preference the well-known AMT anycast addresses as the second preference
after DNS-SD when searching for a local relay. after DNS-SD when searching for a local relay.
o Let Sender Manage Relay Provisioning o Let Sender Manage Relay Provisioning
A related motivating example in the sending-side network is A related motivating example in the sending-side network is
provided by considering a sender which needs to instruct the provided by considering a sender that needs to instruct the
gateways on how to select between connecting to Figure 6 or gateways on how to select between connecting to Figure 6 or
Figure 7 (from Section 3.2), in order to manage load and failover Figure 7 (from Section 3.2), in order to manage load and failover
scenarios in a manner that operates well with the sender's scenarios in a manner that operates well with the sender's
provisioning strategy for horizontal scaling of AMT relays. provisioning strategy for horizontal scaling of AMT relays.
In this example about the sending-side network, the precedence In this example about the sending-side network, the precedence
field described in Section 4.2.1 is a critical method of control field described in Section 4.2.1 is a critical method of control
so that senders can provide the appropriate guidance to gateways so that senders can provide the appropriate guidance to gateways
during the discovery process. during the discovery process.
skipping to change at page 14, line 16 skipping to change at page 14, line 16
guidelines to operators and implementors working with AMT systems guidelines to operators and implementors working with AMT systems
that can use DRIAD as part of the relay discovery process. that can use DRIAD as part of the relay discovery process.
2.5.2. Updates to Restarting Events 2.5.2. Updates to Restarting Events
Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a
gateway to start or restart the discovery procedure. gateway to start or restart the discovery procedure.
This document provides some updates and recommendations regarding the This document provides some updates and recommendations regarding the
handling of these and similar events. The first 5 events are copied handling of these and similar events. The first 5 events are copied
here and numbered for easier reference, and the following events are here and numbered for easier reference, and the remaining 4 events
newly added for consideration in this document: are newly added for consideration in this document:
1. When a gateway pseudo-interface is started (enabled). 1. When a gateway pseudo-interface is started (enabled).
2. When the gateway wishes to report a group subscription when none 2. When the gateway wishes to report a group subscription when none
currently exist. currently exist.
3. Before sending the next Request message in a membership update 3. Before sending the next Request message in a membership update
cycle. cycle.
4. After the gateway fails to receive a response to a Request 4. After the gateway fails to receive a response to a Request
message. message.
5. After the gateway receives a Membership Query message with the L 5. After the gateway receives a Membership Query message with the L
flag set to 1. flag set to 1.
6. When the gateway wishes to report a (S,G) subscription with a 6. When the gateway wishes to report an (S,G) subscription with a
source address that does not currently have other group source address that does not currently have other group
subscriptions. subscriptions.
7. When there is a network change detected, for example when a 7. When there is a network change detected, for example when a
gateway is operating inside an end user device or application, gateway is operating inside an end user device or application,
and the device joins a different network, or when the domain and the device joins a different network, or when the domain
portion of a DNS-SD domain name changes in response to a DHCP portion of a DNS-SD domain name changes in response to a DHCP
message or administrative configuration. message or administrative configuration.
8. When congestion or substantial loss is detected in the stream of 8. When congestion or substantial loss is detected in the stream of
skipping to change at page 15, line 13 skipping to change at page 15, line 13
strictly required to always force a restart of the discovery process. strictly required to always force a restart of the discovery process.
Note that during event #1, a gateway may use DNS-SD, but does not Note that during event #1, a gateway may use DNS-SD, but does not
have sufficient information to use DRIAD, since no source is known. have sufficient information to use DRIAD, since no source is known.
2.5.3. Tunnel Stability 2.5.3. Tunnel Stability
In general, subscribers to active traffic flows that are being In general, subscribers to active traffic flows that are being
forwarded by an AMT gateway are less likely to experience a forwarded by an AMT gateway are less likely to experience a
degradation in service (for example, from missing or duplicated degradation in service (for example, from missing or duplicated
packets) when the gateway continues using the same relay, as long the packets) when the gateway continues using the same relay, as long as
relay is not overloaded and the network conditions remain stable. the relay is not overloaded and the network conditions remain stable.
Therefore, gateways SHOULD avoid performing a full restart of the Therefore, gateways SHOULD avoid performing a full restart of the
discovery process during routine cases of event #3 (sending a new discovery process during routine cases of event #3 (sending a new
Request message), since it occurs frequently in normal operation. Request message), since it occurs frequently in normal operation.
However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for
more information about exceptional cases when it may be appropriate more information about exceptional cases when it may be appropriate
to use event #3. to use event #3.
2.5.4. Traffic Health 2.5.4. Traffic Health
skipping to change at page 18, line 7 skipping to change at page 18, line 7
a disruption in the forwarded traffic by sending such Relay Discovery a disruption in the forwarded traffic by sending such Relay Discovery
messages regularly. When a relay is under load or has started a messages regularly. When a relay is under load or has started a
graceful shutdown, it may respond with a different relay address, graceful shutdown, it may respond with a different relay address,
which the gateway can use to connect to a different relay. This kind which the gateway can use to connect to a different relay. This kind
of coordinated handoff will likely result in a smaller disruption to of coordinated handoff will likely result in a smaller disruption to
the traffic than if the relay simply stops responding to Request the traffic than if the relay simply stops responding to Request
messages, and stops forwarding traffic. messages, and stops forwarding traffic.
This style of Relay Discovery message (one sent to the unicast This style of Relay Discovery message (one sent to the unicast
address of a relay that's already forwarding traffic to this gateway) address of a relay that's already forwarding traffic to this gateway)
should not be considered a full restart of the relay discovery SHOULD NOT be considered a full restart of the relay discovery
process. It is recommended for gateways to support the L flag, but process. It is recommended for gateways to support the L flag, but
for gateways that do not support the L flag, sending this message for gateways that do not support the L flag, sending this message
during event #3 may help mitigate service degradation when relays during event #3 may help mitigate service degradation when relays
become unstable. become unstable.
2.5.7. Independent Discovery Per Traffic Source 2.5.7. Independent Discovery Per Traffic Source
Relays discovered via the AMTRELAY RR are source-specific relay Relays discovered via the AMTRELAY RR are source-specific relay
addresses, and may use different pseudo-interfaces from each other addresses, and may use different pseudo-interfaces from each other
and from relays discovered via DNS-SD or a non-source-specific and from relays discovered via DNS-SD or a non-source-specific
skipping to change at page 29, line 28 skipping to change at page 29, line 28
that don't follow UDP congestion control principles, or deliberate that don't follow UDP congestion control principles, or deliberate
attack. attack.
7. Acknowledgements 7. Acknowledgements
This specification was inspired by the previous work of Doug Nortz, This specification was inspired by the previous work of Doug Nortz,
Robert Sayko, David Segelstein, and Percy Tarapore, presented in the Robert Sayko, David Segelstein, and Percy Tarapore, presented in the
MBONED working group at IETF 93. MBONED working group at IETF 93.
Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, and Ben Kaduk for Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, and Bill
their very helpful comments. Atwood for their very helpful comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
 End of changes. 13 change blocks. 
16 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/