Internet DRAFT - draft-tlmc

draft-tlmc



 



INTERNET-DRAFT                                        Fredrik Danerklint
Intended Status: Internet Best Current Practice             (F redan AB)
Expires: September 27, 2012                               March 26, 2012


                          The Last Mile Cache 
                             draft-tlmc-00


Abstract

   The Last Mile Cache is a solution of how to cache content closer to
   the end user.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2012 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
 


Fredrik Danerklint     Expires September 27, 2012               [Page 1]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


   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.



Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Last Mile Cache  . . . . . . . . . . . . . . . . . . . . .  3
     2.1 What's needed to done before starting to use TLMC  . . . . .  5
     2.2 The Databases  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3 Content Provider . . . . . . . . . . . . . . . . . . . . . .  9
     2.4 Internet Service Provider  . . . . . . . . . . . . . . . . . 10
     2.5 Logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     2.7 The weakest link . . . . . . . . . . . . . . . . . . . . . . 12
   3  Security Considerations . . . . . . . . . . . . . . . . . . . . 13
   4  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
   5  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1  Normative References  . . . . . . . . . . . . . . . . . . . 13
     5.2  Informative References  . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

























 


Fredrik Danerklint     Expires September 27, 2012               [Page 2]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


1  Introduction

   The Last Mile Cache [TLMC] tries to cache content much closer to end
   user. This solution is a two part. First the content providers and
   the second part, Internet Service Providers [ISP]. It also has some
   kind of fail over to the content provider if the cache server at the
   ISP is not available. 


1.1  Terminology

   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].


2.  The Last Mile Cache

   The Last Mile Cache [TLMC] is a two part solution. First we are
   looking it from the end user perspective to see what is happening
   when using TLMC and to understand the hole idea.

   When a end user is issuing a request for http://mirrors.example.org
   it has to ask the domain name system [DNS] which ip address it has so
   it can connect to it. In our case we want it to have the ip address
   of the cache server at the end user's ISP (we call this ISP for
   example.com). To have this the following is happening.

   When the DNS for mirrors.example.org gets the DNS request for that
   host and it is from a ip address within the ISP example.com it will
   answer with a CNAME type with the ISP's domain for handling TLMC
   append to it (The ISP example.com is using tlmc.example.com as that
   domain). The answer will then look like this:

   'mirrors.example.org IN CNAME mirrors.example.org.tlmc.example.com'. 

   We now have to ask our ISP DNS for that host. The ISP's DNS now has
   two choices. Either it will give back the ip address of the nearest
   cache server for the end user to connect to OR it will answer with a
   CNAME if the ISP knows that the cache server(s) is down.

   If the DNS at the ISP provide a CNAME back we simply cannot use
   'mirrors.example.org' as answer since then we will create a lookup
   loop. What we need is something that can be different from
   'mirrors.example.org' but still unique to the content provider
   (example.org) to know where the answer should go (hopefully as close
   to the end user / cache server as possible).

 


Fredrik Danerklint     Expires September 27, 2012               [Page 3]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


   To solve this, the ISP MUST append the answer, without it's own TLMC
   domain, with the UN/LOCODE of the location where the DNS is placed. 

   If the ISP DNS was placed in Karlskrona, Sweden, it would have looked
   like this:

   'mirrors.example.org.tlmc.example.com IN CNAME
   kaa.k.se.mirrors.example.org'

   This method is also the same for the cache server at the ISP to load
   content from the content providers to the end user. It MUST append
   the DNS request with the UN/LOCODE of the location where the cache
   server is placed, like this:

   http://kaa.k.se.mirrors.example.org/

   Still the name for that request MUST be http://mirrors.example.org/.

   When the content provider gets a DNS request for
   '*.mirrors.example.org' it MUST NOT return a CNAME record pointing it
   back to ISP where the request came from. Instead it SHOULD return a
   record to the closest server to serve the content from.


























 


Fredrik Danerklint     Expires September 27, 2012               [Page 4]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


2.1 What's needed to done before starting to use TLMC

   Before we can start using TLMC we need to provide two things. First
   what hosts (or website if you prefer that) that can be cached and
   second, the ip address ranges from the ISP so we know when to serve
   the content from the local cache server at the ISP. 

   To be able to achieve this we need some kind of a database. The
   database itself will pretty much look like a Internet Routing
   Registry [IRR]. For example, RIPE:s database of routing registry,
   ripe.db.route.gz and ripe.db.route6.gz, is such examples.

   The content provider needs to make sure that their DNS can handle
   this type of DNS request that they gets and the ISP also needs a DNS
   to handle their request as well a cache server. 

   Both parts also needs to know their UN/LOCODE location of their
   servers.

   This is what's REQUIRED for each part.


 2.1.1 UN/LOCODE, United Nations Code for Trade and Transport Locations.

   When specifying the UN/LOCODE, the syntax is like this:

   LOCODE without the ISO 3166-1 country code.[SubDiv].ISO 3166-1
   country code. The field SubDiv is OPTIONAL.

   Example of the city of Karlskrona, Sweden would be like this:

   kaa.k.se

   Another example, Bellingshausen, Antarctica, would be:

   bhn.aq 












 


Fredrik Danerklint     Expires September 27, 2012               [Page 5]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


2.2 The Databases

   There are going to be two databases. One for the hosts (called tlmc-
   hosts.db) and one for the ip address ranges (called-prefixes.db) from
   the ISP:s around the world. This way it will be easier to build local
   filter if that is necessary. An ISP SHOULD use the following example
   in their DNS to know if a request should be handle via the local
   cache server or sent upstream to the content provider:

   #grep hostname tlmc-hosts.db | gawk '{ print $2 }' >local-dns-filter


 2.2.1 Database for the hosts

   Each host contains up to four records, 'hostname', 'log','period' and
   'pgp'. Each host entry has been verified in that sense that a e-mail
   has been sent to the hostmaster of the domain (in our case that would
   be 'example.org') that contains a verification code to be submitted
   before a record is made into the database of hosts. This procedure is
   also done during a change request for an already host entry in the
   database.

   If you have more than one host for your domain, you'll need one
   record for each host that you are willing to be cached.


  2.2.1.1 hostname

   This entry describe which host that can be cached for your domain.
   'hostname: mirrors.example.org' is a valid one. REQUIRED.


  2.2.1.2 log

   This entry describe to which e-mail address the logfile for that host
   should be sent. 'log: tlmclogs@example.org' is a valid one. REQUIRED.












 


Fredrik Danerklint     Expires September 27, 2012               [Page 6]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


  2.2.1.3 period

   This entry is OPTIONAL and describe under which period the logfile
   for this host SHOULD be sent to above e-mail address. Content
   provider should be a were that an ISP might not honor this entry.

   The period can contain:

   '1h' for every 1 hour
   '1d' for every 1 day
   '1w' for every 1 week
   '1m' for every 1 month 

   The first number of each period can be '1-24' for hour, '1-31' for
   day, '1-52' for week and '1-12' for month.

   If the period entry does not exist the REQUIRED period SHALL be 1
   month and the ISP MUST follow that. If the period is longer than 1
   month then the ISP MUST follow that instead.

   'period: 1h' is a valid example of a period.


  2.2.1.4 pgp

   This entry is OPTIONAL and contains the public key signature of the
   e-mail address specified in the 'log' entry. It means that the above
   logfile should be sent as an encrypted PGP e-mail to the above e-mail
   address.

   However, for this to work correctly, the ISP needs as well to publish
   their PGP key in the databases of 'tlmc-prefixes.db'.

   'pgp: 0x12345678' is a valid example of a public PGP signature key
   with the keyid of 0x12345678.













 


Fredrik Danerklint     Expires September 27, 2012               [Page 7]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


 2.2.2 Database for the prefixes

   Each prefix contains up to three records, 'prefix' or 'prefix6',
   'cname', 'from' and 'pgp'. For you as an ISP to be able to add an
   entry to the database your prefix MUST first be in of the many
   routing databases that exists today. Not only that but it is also
   REQUIRED that the syntax for that prefix is correct. The verification
   is the same as 2.2.1 with the exception that it sends the e-mail to
   the hostmaster of the reverse address prefix which MUST exist in
   either the 'in-addr.arpa' or 'ip6.arpa' domain.


  2.2.2.1 prefix or prefix6

   This holds the prefix from where the ISP customers, end users, are
   coming from. You should aggregate your prefixes as much as possible.
   Aggregation is OPTIONAL. REQUIRED.

  2.2.2.2 cname

   Which domain name the content provider should use when a request
   comes from this prefix. REQUIRED.

  2.2.2.3 from

   The e-mail address the ISP using when sending logfiles. REQUIRED.

  2.2.2.4 pgp

   This holds the pgp key that the ISP would use if the content provider
   also has a pgp key. OPTIONAL.

  2.2.2.5 Example entry for the prefix database

   'prefix: 192.0.2.0/24'
   'cname: tlmc.example.com'
   'from: tlmc@example.com'

   'prefix6: 2001:db8::/32'
   'cname: tlmc.example.com'
   'from: tlmc@example.com'
   'pgp: 0x12345678' 






 


Fredrik Danerklint     Expires September 27, 2012               [Page 8]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


2.3 Content Provider


   For a content provider to be able to use TLMC they need to have a DNS
   that can answer the question received in '2. The Last Mile Cache' as
   described there and register the hosts in the database. Also make
   sure that your webserver add headers to allow the cache servers to
   actually cache your content. 

   A content provider should be aware that it might take more than 24
   hours for the ISP:s around the world to download the new database of
   'tlmc-hosts.db' before you SHOULD start using TLMC.




































 


Fredrik Danerklint     Expires September 27, 2012               [Page 9]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


2.4 Internet Service Provider

   An ISP need first to install a cache server somewhere in their
   network. They don't need to add all their prefixes to the databases
   directly from start, they can start with a smaller subset if they
   want. However, please remember that it is not the ip addresses for
   the applications that's needed to be in the database. It is from
   which ip address the DNS request origins from. If you allow your
   customers to have their own DNS, include their prefixes as well.
   Otherwise it's only the ISP's own DNS ip addresses that's needed to
   be in the database.

   There is an working example with PowerDNS as the DNS and a special
   backend to be able to answer your customer with your cache server(s)
   ip address, at https://tlmc.fredan.se/. You only have to run this on
   the delegated domain (tlmc.example.org).

   If you are using Apache Traffic Server [ATS] as the cache server,
   this is what's needed in the configuration:

   From the file 'remap_config':

   regex_map http://(.*)/ http://kaa.k.se.$0/

   You MUST replace "kaa.k.se" with your UN/LOCODE of where the cache
   server is placed.






















 


Fredrik Danerklint     Expires September 27, 2012              [Page 10]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


2.5 Logfiles

   The content of the sent logfiles SHALL be like this:

   <UN/LOCODE of the cache server> <timestamp> <http status code> <URL>

   The timestamp MUST be in Unix seconds with the timezone in UTC.

   Since there is no ip addresses in the logfile the ISP MUST send one
   logfile for the content served with ip4 addresses and one for ip6
   addresses to the content provider. Also each logfile SHALL be named
   with the 'cname' as specified in the 'tlmc-prefixes.db' database.

   In our example this is what the logfile should have been named:

   'mirrors.example.org.tlmc.example.com.ip4.log' 
   for content served to end users with ip4 addresses and

   'mirrors.example.org.tlmc.example.com.ip6.log' 
   for content served to end users with ip6 addresses.




























 


Fredrik Danerklint     Expires September 27, 2012              [Page 11]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


2.7 The weakest link

   The weakest link with TLMC is the local DNS at the ISP. Redundancy
   with multiplies DNS is RECOMMENDED.












































 


Fredrik Danerklint     Expires September 27, 2012              [Page 12]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


3  Security Considerations

   Since the content transported over TLMC is unencrypted from the
   content provider to the end user, you should encrypt the file(s) that
   you don't want anybody to be able to look at without a 'key'. TLMC
   SHALL NOT handle of how to distribute your 'key'.


4  IANA Considerations

   <IANA considerations text>


5  References

5.1  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [UN/LOCODE] "United Nations Code for Trade and Transport Locations",
              <http://www.unece.org/cefact/locode/welcome.html>.

5.2  Informative References

   [DNS]      Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [PGP]      Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [ATS] "Apache Traffic Server", <http://trafficserver.apache.org/>.

   [IRR] "Internet Routing Registry", <http://www.irr.net/>.

   [UNIX TIME] "Number of seconds elapsed since midnight Coordinated
              Universal Time (UTC) of Thursday, January 1, 1970",
              <http://en.wikipedia.org/wiki/Unix_time>.










 


Fredrik Danerklint     Expires September 27, 2012              [Page 13]

INTERNET DRAFT            The Last Mile Cache             March 26, 2012


Authors' Addresses


   Fredrik Danerklint
   Kungsmarksvagen 33A
   S-37144 Karlskrona
   SWEDEN

   EMail: fredan-tlmc@fredan.se










































Fredrik Danerklint     Expires September 27, 2012              [Page 14]