| Network Working Group | D. Segelstein |
| Internet-Draft | A. Flavel |
| Updates: 5357 (if approved) | D. Nortz |
| Intended status: Standards Track | AT&T Labs |
| Expires: January 01, 2012 | June 30, 2011 |
Using Domain Name Services to Enable an AMT Gateway to Discover the Optimal AMT Relay in a Multi-Network SSM Multicast Environment
draft-segelstein-mboned-amt-dns-00
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)” 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
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 January 01, 2012.
Copyright (c) 2011 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.
Implicit in the definition of a global anycast address for AMT Relays [I-D.ietf-mboned-auto-multicast] 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 the case 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 multicast, multi-network environment, where connectivity between networks may or may not be multicast-enabled.
In order to successfully provide multicast content to an AMT Gateway, the AMT Relay reached must have multicast connectivity to the source. In order 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.
The solution presented in this document has the following characteristics:
The implementation proposed can achieve the above characteristics for the following reasons:
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.
This document is meant to address issues solely related to SSM[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.
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.
At this point, the AMT Gateway generate a DNS query of the form "S1.amt.net" or "S1-amt.net" or "S1.net" (alternatives to be examined below) instead of seeking the AMT Relay by means of the global AMT Relay anycast address. This domain, "S1*.net", is defined so that authoritative DNS servers are resident on networks that have multicast connectivity to the network that hosts the source "S1". As an example of such a query, for a source IP address 12.123.221.123, the value of "S1" in the DNS query could be of the form "12123221123*.net. Alternatively, it could be of a more restrictive form that could eliminate some domain possibilities. Only two things are required for this solution to function correctly:
The query for "S1*.net" 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 either for the ".net" domain or the "S1*.net" domain. However, the local DNS server will be aware of and will query the ".net" authoritative DNS for the anycast address of the "S1*.net" authoritative DNS.
This option assumes that there is an organization responsible for an "amt.net" domain. Then that organization would maintain DNS servers that are aware of those DNS servers authoritative for "Sx.amt.net", where "x" specifies any multicast source reachable by an AMT Relay.
The ".net" DNS server redirects the local DNS query to the "amt.net" DNS server. In turn, the "amt.net" DNS servers redirects the DNS query to the appropriate DNS servers authoritative for the source being sought in the query. That will be a set of DNS servers reachable by an anycast address.
When the local DNS server queries that "S1.amt.net" DNS server, the query will naturally (via anycast) be routed to the nearest (in routing metric) DNS authoritative for source "S1".
This option assumes no "amt.net" domain. Then ".net" authoritative DNS servers must be aware of those DNS servers authoritative for "Sx-amt.net", where "x" again specifies any multicast source reachable by an AMT Relay. The "-amt" qualifier simply aids the lookup by the ".net" DNS of the DNS servers authoritative for the "S1" domain. Thus, the ".net" DNS server redirects the DNS query to the appropriate DNS servers authoritative for the source being sought in the query. That will be a set of DNS servers reachable by an anycast address.
When the local DNS server queries that "S1-amt.net" DNS server, the query will naturally (via anycast) be routed to the nearest (in routing metric) DNS authoritative for source "S1".
This option assumes no "-amt" to aid the lookup by the ".net" DNS of the DNS servers authoritative for "Sx". The ".net" DNS server simply looks up the DNS servers authoritative for "S1" and redirects the DNS query to those DNS servers. That will be a set of DNS servers reachable by an anycast address.
When the local DNS server queries that "S1.net" DNS server, the query will naturally (via anycast) be routed to the nearest (in routing metric) DNS authoritative for source "S1".
By virtue of the conditions set out in 3.1, above, the DNS authoritative for "S1*.net" 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 DNS authoritative for "S1*.net" 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, the DNS reached by this last query may safely respond with the address of an AMT Relay on its own network. That DNS may provide a response according to its own network's 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.
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 minor additional steps required to make their AMT Relays authoritative for that source, and hence available to AMT Gateways seeking content from that source. Further, if the ".amt.net" option of Section 3.2.1 is adopted, the authority for the "amt.net" domain is required to administer those DNS servers in accordance with this hierarchy.
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.
This document introduces no security considerations other than any already associated with DNS and SSM.
This memo makes no request of IANA.
The authors thank folks for review and comment.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.ietf-mboned-auto-multicast] | Thaler, D, Talwar, M, Aggarwal, A, Vicisano, L, Pusateri, T and T Morin, "Automatic IP Multicast Tunneling", Internet-Draft draft-ietf-mboned-auto-multicast-11, July 2011. |
| [SSM] | Source-Specific Multicast for IP, work in progress (expired Internet Draft)", November 2000. | , "