MBONED Working Group Doug Nortz Internet Draft Robert Sayko Intended status: RFC David Segelstein Expires: May 2, 2016 Percy Tarapore AT&T November 2, 2015 Optimal AMT Relay Discovery via DNS in Multi-Network SSM Multicast Environment draft-nortz-optimal-amt-relay-discovery-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 2, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November Nortz, et al Expires May 2, 2016 [Page 1] IETF I-D Optimal AMT Relay Discovery via DNS July 2015 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract One of the obstacles to implementing AMT Multicast in a multi- network environment is the difficulty an AMT Gateway may have in finding an AMT Relay that is optimal. Optimal in this context means that the AMT Relay has multicast connectivity to the Source, and its location minimizes the unicast (tunneled) portion of the path to the Gateway. Blind use of the global anycast address specified for AMT Relays in "Automatic IP Multicast Without Explicit Tunnels (AMT)" (RFC 7450) could result in reaching an AMT Relay that does not have multicast connectivity to the source, which would yield a failure to obtain the multicast content; or it could result in reaching an AMT Relay that is otherwise less than optimal. This document proposes a method for implementing standard DNS procedures so that an AMT Gateway using normal DNS queries can virtually always find the optimal AMT Relay for a given Source.. Table of Contents 1. Overview and Rationale.........................................3 2. Assumptions....................................................4 3. Proposed Procedure for Finding an AMT Relay....................5 3.1. The AMT Gateway Forms a DNS Query to Find the AMT Relay...5 3.2. The Query to the Local DNS................................5 3.3. ".arpa" DNS Redirects Query to the DNS Authoritative for "a" ...............................................................6 3.4. The "a" Authoritative DNS Redirects Query to the "AMT" DNS6 3.5. "AMT" DNS Returns IP Address of Its Own Network's AMT Relay ...............................................................6 3.6. The Result of the Procedure...............................7 3.7. Possible Inefficiencies...................................7 4. Security Considerations........................................7 5. IANA Considerations............................................7 6. References.....................................................7 7. Acknowledgments................................................7 Nortz, et al Expires May 2, 2016 [Page 2] IETF I-D Optimal AMT Relay Discovery via DNS July 2015 1. Overview and Rationale Implicit in the definition of a global anycast address for AMT Relays is the assumption that an AMT Gateway will succeed in obtaining multicast content simply by finding the closest (in routing distance) AMT Relay. Consideration of a moderately complex multi-network architecture reveals that this is not necessarily a valid assumption. An environment in which all networks are multicast-enabled and have multicast-capable interconnections would be well-suited to globally anycast-addressed AMT Relays. In that environment, the nearest AMT Relay to any given AMT Gateway will be optimal and successful in delivering multicast content. However, in general, connections among networks will not ubiquitously be multicast-capable, and that is likely to be true for some time. In that case, reaching the nearest AMT Relay is not guaranteed to be successful. Accordingly, this document addresses the problem of finding an optimal AMT Relay in an SSM multi-network environment, where connectivity between networks may or may not be multicast-enabled. To successfully provide multicast content to an AMT Gateway, the AMT Relay reached must have multicast connectivity to the source. For it to be optimal, it must maximize the portion of the path that is multicast, and minimize the portion that requires a unicast tunnel. Further, the network reached should retain some flexibility so that its own policies may be invoked in the allocation of usage of its resources. It may, for example, seek to consider network load when directing the AMT Gateway to a specific AMT Relay. In addition, the discovery procedure should minimize the risk of exposure to the possibility of a malicious party that could advertise an anycast AMT address and attract AMT Gateway messages. This could have the potential of disabling multicast for those end-users whose Gateways reach that malicious destination. This document further examines the case of two (or more) network operators that want to cooperate in the offering of multicast content to their customers using multicast sources and AMT Relays in either or both of their networks. The solution presented in this document has the following characteristics: o It requires very little or no change to existing technologies. o It naturally results in finding the optimal AMT Relay in most cases. Nortz, et al Expires May 2, 2016 [Page 3] IETF I-D Optimal AMT Relay Discovery via DNS July 2015 o It allows AMT Gateways to use existing protocols and procedures. o It simplifies and minimizes administration and management of resources. o It allows flexibility in network allocation of resources. o It avoids exposure to malicious actors. o It supports the ability of network operators to coordinate access to multicast sources and AMT Relays in multiple networks. The implementation proposed can achieve the above characteristics for the following reasons: o AMT Gateways require only a single, simple DNS query to find the optimal AMT Relay. o AMT Relays can use the same DNS query to find the optimal AMT Relay to which it can build an AMT tunnel for access to a source in another network. o This implementation requires no changes to existing DNS procedures, and only requires DNS servers in relevant authoritative domains to be administered to incorporate awareness of source networks to which they have multicast connectivity, and to respond appropriately to DNS queries for optimal AMT Relays. o It builds efficiency into the procedure itself, and thus does not require a centralized intelligence to direct the AMT Relay discovery process. 2. Assumptions This document will not address the manner in which the application discovers the Multicast Source, and generally assumes there is one source per content provider. However, a method similar to that proposed here for finding the optimal AMT Relay may in fact be used to find the optimal source in a multi-source environment. In addition, a similar approach can be used for AMT Relays to find AMT Relays in other networks with which they can establish tunnels to obtain content across network boundaries that are not multicast enabled. That method is not explicitly described here. This document is meant to address issues solely related to SSM. It does not propose to make any changes to the way SSM works as a transport, or the way DNS works to resolve names to IP addresses, and therefore will not go into any detail on the inner working of SSM or DNS. Nortz, et al Expires May 2, 2016 [Page 4] IETF I-D Optimal AMT Relay Discovery via DNS July 2015 3. Proposed Procedure for Finding an AMT Relay Once a multicast-enabled application obtains an address for desired content, e.g., (S1,G1), it generates an IGMP message to join that stream. An AMT Gateway client (stand-alone or one incorporated into the application) will determine whether native multicast is available, and if not will invoke AMT Gateway functions to attempt to find an AMT Relay. Only two things are required for this solution to function correctly: 1) Each network that has one or more AMT Relays with multicast connectivity to a given source, and that wishes to serve content from that source, must have a DNS server that is authoritative for that source domain, and 2) That all such DNS servers be reachable by the same anycast address. 3.1. The AMT Gateway Forms a DNS Query to Find the AMT Relay Instead of seeking the AMT Relay by means of the global AMT Relay anycast address, the AMT Gateway generates a DNS query of the form "amt.ReverseS1.in-addr.arpa". The query to that domain will naturally result in eventual redirection of the DNS query to a DNS server authoritative for the source "S1" via AMT. As an example of such a query, for a source IP address "a.b.c.d", the value of "ReverseS1" in the DNS query would be of the form "d.c.b.a". Typically, the value of "a" will identify the network that hosts the Source. The functionality described here would work perfectly well without the prefix "amt" as shown, but including it will allow a simple in- addr.arpa IP to domain name lookup assuming the operator of the network owning the source desires to create a domain for the source IP. It also simplifies DNS entries for the authoritative DNS for S1. 3.2. The Query to the Local DNS The query for "amt.ReverseS1.in-addr.arpa" will initially be directed to the local DNS server defined for the end-user, which will in most cases be local to the end-user's access network. In general, the local DNS will not be authoritative for the domain being queried. However, the local DNS server will be aware of and Nortz, et al Expires May 2, 2016 [Page 5] IETF I-D Optimal AMT Relay Discovery via DNS July 2015 will query the ".arpa" authoritative DNS for the address of the "amt.ReverseS1" authoritative DNS. 3.3. ".arpa" DNS Redirects Query to the DNS Authoritative for "a" The ".arpa" authoritative DNS server will be aware of the DNS server authoritative for the network associated with "a". It thus redirects the local DNS query to that authoritative DNS server. 3.4. The "a" Authoritative DNS Redirects Query to the "AMT" DNS In turn, the "a" authoritative DNS server redirects the DNS query to the appropriate DNS servers authoritative for the source being sought in the query. Given the appearance of the term "amt" in the query, the DNS record for that entry will have been configured to point to an AMT-specific DNS. That will be a set of DNS servers reachable by an anycast address, and that anycast address is the one supported by DNS servers in each network that seeks to provide access to the source content via AMT. The fact that this is an anycast address will ensure that the "AMT" DNS server reached by the recursive query will be the one closest to the local DNS. 3.5. "AMT" DNS Returns IP Address of Its Own Network's AMT Relay By virtue of the conditions set out above, the "AMT" DNS that is reached will be resident on a network that has multicast connectivity to the source "S1". This may be because the source is on that same network, or it may be because that network has multicast interconnection to the network on which the source is located. Because the "AMT" DNS was reached by anycast, that network is assured to be nearest (in routing metric) to the DNS local to the AMT Gateway. As a result of the above, that DNS server may safely respond with the address of an AMT Relay on its own network. That response may be determined according to that network administration's own policies and capabilities. For example, the response may be an anycast address that would route to the closest among several possible AMT Relays. Alternatively, it may respond with a CNAME, which can be resolved by an intelligent DNS server that takes into account network load in deciding to which AMT Relay to direct the AMT Gateway. Or it may respond with the unicast address of a specific AMT Relay. Nortz, et al Expires May 2, 2016 [Page 6] IETF I-D Optimal AMT Relay Discovery via DNS July 2015 3.6. The Result of the Procedure The procedure detailed above results in reaching an AMT Relay that has multicast connectivity to the desired source. In addition, the AMT Relay will be in the multicast-capable network closest to the end-user's local DNS server, which is in most cases local to the end-user. This minimizes the inter-network unicast path between the AMT Relay and the AMT Gateway. The reached network can, however, implement its own policies with regard to selecting a particular AMT Relay for that query, thus allowing flexibility in network administration. The end-user's AMT Gateway will thus have reached the optimal AMT Relay within the constraints of also taking into account the policies of the reached network provider. Administration of the DNS hierarchy is minimally affected. However, only those network providers that wish to carry multicast traffic for a given source need to undertake the additional steps required to make their AMT DNSs authoritative for that source, and hence available to AMT Gateways seeking content from that source. 3.7. Possible Inefficiencies In the case that an end-user's application or browser is assigned a DNS server that is not local, the anycast routing will yield a false "nearest" network DNS. The content will still be served via multicast, but the AMT Relay found will not be optimal. 4. Security Considerations This document introduces no security considerations other than any already associated with DNS and SSM. 5. IANA Considerations 6. References [SSM] Holbrook, H., and Cain, B. "Source-Specific Multicast for IP," Internet Draft, November 2000. [AMT] Automatic IP Multicast Without Explicit Tunnels (AMT), draft- ietf-mboned-auto-multicast-10 7. Acknowledgments Nortz, et al Expires May 2, 2016 [Page 7] IETF I-D Optimal AMT Relay Discovery via DNS July 2015 Authors' Addresses Doug Nortz AT&T Phone: 1-732-420-1739 Email: dnortz@att.com Robert Sayko AT&T Phone: 1-732-420-3292 Email: rs1983@att.com David Segelstein AT&T Phone: 1-732-420-1742 Email: dsegelstein@att.com Percy Tarapore AT&T Phone: 1-732-420-4172 Email: tarapore@att.com Nortz, et al Expires May 2, 2016 [Page 8]