Internet DRAFT - draft-nortz-optimal-amt-relay-discovery
draft-nortz-optimal-amt-relay-discovery
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]
