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]
