[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/