Network Working Group C. Deleuze
Internet-Draft L. Gautier
Expires: May 21, 2001 ActiVia Networks
M. Hallgren
Teleglobe France
November 20, 2000
A DNS Based Mapping Peering System for Peering CDNs
draft-deleuze-cdnp-dnsmap-peer-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 21, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Discussion List & Archives
This document and related documents are discussed on the cdn mailing
list. To join the list, send mail to cdn-request@ops.ietf.org. To
contribute to the discussion, send mail to cdn@ops.ietf.org. The
archives are at ftp://ops.ietf.org/pub/lists/cdn.*.
Abstract
There is an increasing interest in interconnecting Content Delivery
Networks (CDNs) via peering systems. This memo proposes a DNS-based
solution for peering request mapping systems. This solution uses
Deleuze, et. al. Expires May 21, 2001 [Page 1]
Internet-Draft CDNP DNS mapping November 2000
delivery-aware domain names under the current DNS. It describes an
architecture for peering delivery-aware CDNs. This affects the
methods used to interconnect multiple CDNs.
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3. Mapping System . . . . . . . . . . . . . . . . . . . . . . 5
4. Mapping Peering System . . . . . . . . . . . . . . . . . . 6
4.1 Basic Peering Mechanism . . . . . . . . . . . . . . . . . 6
4.2 Delivery-Aware Peering Mechanism . . . . . . . . . . . . . 7
4.3 External Naming Issues . . . . . . . . . . . . . . . . . . 8
5. Delivery Awareness Criteria . . . . . . . . . . . . . . . 10
5.1 Criteria Examples . . . . . . . . . . . . . . . . . . . . 10
5.1.1 Publisher criteria . . . . . . . . . . . . . . . . . . . . 10
5.1.1.1 Delivery Service . . . . . . . . . . . . . . . . . . . . . 10
5.1.1.2 Delivery Cost . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1.3 Delivery Delay . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1.4 Delivery Footprint . . . . . . . . . . . . . . . . . . . . 11
5.1.2 Delivery Criteria . . . . . . . . . . . . . . . . . . . . 11
5.2 Default Delivery Names . . . . . . . . . . . . . . . . . . 11
5.2.1 Delivery Name Key . . . . . . . . . . . . . . . . . . . . 12
5.2.2 Delivery Name Example . . . . . . . . . . . . . . . . . . 13
5.2.2.1 Publisher Delivery Name . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . 19
Deleuze, et. al. Expires May 21, 2001 [Page 2]
Internet-Draft CDNP DNS mapping November 2000
1. Conventions
This memo assumes that the reader is familiar with DNS concepts [1]
and specifications [2]. Following practice in the CDNP mailing
list, we use the term "DNS name" rather than "domain name". "tld"
stands for "top level domain".
"Delivery-aware" is used here to indicate that there are multiple
possibilities to deliver content depending on a variety of criteria.
For example, consider the footprint criteria, the content must be
delivered only to a subset of peered CDN surrogates.
"DNS-MS" stands for DNS-based Mapping System.
"PMT" stands for "Peering Mapping Table", i.e. the set of DNS
records involved in the DNS-MS peering process.
"PMT Manager" stands for the peering mechanism that builds the PMT
(either an administrator or a protocol).
Deleuze, et. al. Expires May 21, 2001 [Page 3]
Internet-Draft CDNP DNS mapping November 2000
2. Introduction
The Domain Name System (DNS) was designed primarily to identify
network resources. Today, many CDNs use the current DNS to map a
request to the suitable surrogate [4].
During the DNS mapping process only the DNS names are visible to the
DNS mapping system. A problem occurs when a CDN wants to publish
content on a specific delivery area. This area can be a subset of
CDN servers running a specific application, or servers that cover
only a part of the total CDN footprint. To make this delivery
information available to the mapping process, it has to be coded in
the DNS name space.
The need for delivery awareness can easily be shown with this
example:
A Microsoft Windows Media Stream is published with an URI such as:
"mms://foo.bar.com/file.foo". This URI is interpreted at the user
agent and is not visible for the mapping system. The only part of
the URI that can be used for request mapping is the DNS name.
Hence, all relevant information for the mapping decision has to be
encoded in the DNS name.
Since only DNS names are visible during the DNS-based peering,
information about a desired footprint, delivery area or similar
information has to be integrated in the DNS name. To peer with a
limited zone inside a CDN, this zone has to be defined between the
peering partners and encoded in the DNS name. For example, this is
already used by CNN with its "www.cnn.com" and "europe.cnn.com" DNS
names.
This memo addresses specifically the issues raised in the context of
CDN peering. The scope of this work is limited to DNS-based
peering, but does not restrict the mapping mechanisms inside each
individual CDN. For the purpose of this document we consider the
internal mapping mechanisms of CDNs as black boxes (e.g., a CDN can
use URI-based mapping internally).
This memo presents a solution for delivery aware mapping. At the
core of this solution is the use of the delivery-aware naming at the
DNS level. Consult [5] for a description of object coding in the DNS
name space. The present memo proposes a more general approach
towards DNS-based request mapping using delivery-aware DNS names.
Deleuze, et. al. Expires May 21, 2001 [Page 4]
Internet-Draft CDNP DNS mapping November 2000
3. Mapping System
The component of a CDN that maps user requests to an appropriate
surrogate is called the "mapping system". Similarly to the routing
of IP datagrams, it actually contains two distinct processes:
o "forwarding" is the process that uses the "routing table" to
determine the next hop to the appropriate surrogate.
o "routing" is the process that builds the routing table according
to various metrics and policies.
In this memo, only the "forwarding" part is addressed.
Conceptually, mapping systems can make use of three (possibly
combined) categories of mechanisms (see [5] for details):
o DNS-based
o transport-layer
o application-layer (URI-based)
DNS-based mapping is always available whatever the content (it does
not require usage of proxies or application level redirection
mechanisms). The interpretation of an URI is hierarchical: first,
the DNS name is resolved, then a protocol is chosen according to the
scheme and a connection is established; URI pathname and arguments
are made available to the server which processes them. Hence,
DNS-based mapping can always be used as the first step of a general
URI based mapping mechanism.
Other motivations for the use of DNS-based mapping are the
following:
o Independence of the application-level protocols: The DNS-based
mapping acts before these protocols so that they are not aware of
the mapping.
o Compatibility with whatever URI utilization: The DNS-based
mapping does not rely on URI analysis, so URI can be used
exclusively on user agents, encrypted over the network or used
many times after the mapping (as HTTP1.1 [3] recommends).
Deleuze, et. al. Expires May 21, 2001 [Page 5]
Internet-Draft CDNP DNS mapping November 2000
4. Mapping Peering System
In the case of peering CDNs, mapping systems must be tied together
by mapping CPGs (content peering gateways) to form a hierarchical
mapping peering system [6]. Each CDN has only one mapping system.
A parent mapping system is a mapping system, authoritative or not,
which decides that a child mapping system can handle the user
request or can delegate the mapping to a lower mapping system in the
hierarchy, in order to find the best suitable surrogate among each
peering CDN surrogates.
The first step of the URI mapping mechanism is the DNS-based mapping
as explained above. It is handled by a DNS based Mapping System
(DNS-MS).
The most common mechanisms used for DNS redirection are based on NS
and CNAME records [5]. The DNS-MS described below is based on CNAME
records, but can be adapted to one using NS records, with the known
drawbacks described in [5]. The set of CNAME records involved in
the DNS-MS peering process is defined as the peering mapping table
(PMT). This table contains one CNAME record per entry. The PMT is
built by the Peering Mapping Table Manager (PMT Manager). This
entity can be a DNS-MS administrator which manually updates the
table, or a peering protocol (not addressed here) that performs this
task automatically.
4.1 Basic Peering Mechanism
Here, each DNS-MS is described by only one DNS name. Therefore, the
peering mechanism is not delivery-aware. For the sake of clarity,
the unique DNS name of a DNS-MS "X" can be seen as:
"<X_unique_subdomain>.X_domain.tld".
When a parent DNS-MS decides to delegate the current resolution of a
name "<parent_unique_subdomain>.parent_domain.tld" to a child
DNS-MS, it replies to the user's DNS server the only CNAME record
with the new DNS name "<child_unique_subdomain>.child_domain.tld".
The user's DNS server then queries the child DNS-MS to resolve this
new DNS name.
The PMT manager makes the association (i.e. adds the CNAME entry in
the PMT) between "<parent_unique_subdomain>.parent_domain.tld" and
"<child_unique_subdomain>.child_domain.tld". This association does
not depend on any content or delivery criteria. If the child CDN is
not able to distribute the content, the association is suppressed
and the peered content distribution is stopped. Since the parent
has a unique delivery name, the PMT contains one unique entry per
peer DNS-MS.
Deleuze, et. al. Expires May 21, 2001 [Page 6]
Internet-Draft CDNP DNS mapping November 2000
4.2 Delivery-Aware Peering Mechanism
The CDN peering architecture [6] defines one mapping tree for each
publisher URI. The aggregation of the mapping trees whose URIs use
the same publisher DNS name defines a global delivery tree.
Each DNS-MS defines its internal delivery trees with the delivery
criteria as presented in Section 5. An internal delivery tree is
defined by a delivery name. This delivery name is a DNS name
"<delivery_x>.domain.tld" under the DNS authority of the CDN. This
is the name used by the DNS-MS. Other DNS names of the internal
delivery tree (used by the internal mapping system) are not exported
outside the DNS-MS.
As seen before, the basic mechanism implies that each CDN has only
one internal delivery tree. All internal delivery trees, one per
CDN, build one unique global delivery tree that covers all peering
CDNs . Also, parent DNS-MSs have only one CNAME record pointing to
the delivery name of the child DNS-MS they are peering with.
The delivery-aware mechanism implies that each CDN has one or more
internal delivery trees. When multiple CDNs are tied together, all
internal delivery trees build several global delivery trees. In
order to peer with a given child DNS-MS, the parent DNS-MS uses one
CNAME record for each of its internal delivery trees.
The general DNS-MS peering architecture is defined as follows. The
publisher delegates one of its DNS names to the authoritative DNS-MS
via a publisher delivery name. Then, the authoritative DNS-MS links
this delivery name to one delivery name in each child DNS-MS. This
procedure is repeated recursively between peered DNS-MSs.
Therefore, the peering process is defined as follows. When a parent
DNS-MS decides to delegate the current resolution of a delivery name
"<delivery_x>.parent_domain.tld" to a child DNS-MS, the parent
replies to the user's DNS server a CNAME record with the new
delivery name "<delivery_y>.child_domain.tld". The user's DNS
server then queries the child DNS-MS to resolve this new delivery
name.
The PMT manager make the association between
"<delivery_x>.parent_domain.tld" and "<delivery_y>.child_domain.tld".
This association must be done accordingly to criteria as presented
in Section 5. The PMT contains one set of CNAME records per parent
DNS-MS delivery name. A set contains one CNAME record per peer
DNS-MS for the delivery name. Note that the PMT manager can change
the PMT depending on network measurements or surrogate feedback.
Deleuze, et. al. Expires May 21, 2001 [Page 7]
Internet-Draft CDNP DNS mapping November 2000
Several parent internal delivery trees may be linked to one child
internal delivery tree, which becomes a multiplexed delivery tree.
However, this kind of internal delivery tree cannot be
demultiplexed. For example, if a multiplexed internal delivery tree
is composed of HTTP and RTSP delivery, it is not possible to
redirect HTTP related DNS requests to one child and RTSP requests to
another child (or to another tree in the same child). Therefore,
the more internal delivery trees in a CDN, the more it is able to
peer with other CDNs in a delivery aware way.
4.3 External Naming Issues
In our model, a CDN can provide several delivery services (through
distinct delivery trees) that are selected through an appropriate
DNS name. This memo described how to use those names for CDN
peering. Each peering CDN knows how to address the delivery trees of
its peering CDNs. Those names are used only between pairs of
peering CDNs and are neither visible to users nor to publishers.
This section discusses the special case of "peering" between the
origin server of the publisher and the authoritative mapping system.
The publisher delivery name must match the delivery tree
corresponding to the service the publisher bought from the CDN.
Let's take the example of the European 'Foo' company, which has a
web site in English with parts of it in French. This example is
based on footprints, but any other criteria can be used. "Foo"
wants the English parts of its web site to be CDN-delivered
throughout Europe, and the French parts only in France. Thus, it is
necessary that the English parts are associated to a delivery tree
providing a European footprint and the French parts are associated
to another delivery tree providing a French footprint.
Since delivery trees are selected by a DNS name, the parts of the
web site need to be identified in the DNS name, e.g. www.foo.com for
English parts and www1.foo.com for French parts.
This may be achieved by URI rewriting:
Static rewriting: It requires the reorganization of the "Foo" web
site.
Dynamic rewriting: It is performed on the fly, as a document is
fetched from the origin server.
Note that in this context, URI rewriting does not raise the problems
described in [5] (Section 4.2.2.3):
1. Rewriting is not client dependent.
Deleuze, et. al. Expires May 21, 2001 [Page 8]
Internet-Draft CDNP DNS mapping November 2000
2. The new DNS name points to a delivery tree, which will then be
DNS-based mapped, not a surrogate.
3. Rewritten content can be cached in surrogates.
The impact on the distribution system of such a scheme is not
addressed here.
Deleuze, et. al. Expires May 21, 2001 [Page 9]
Internet-Draft CDNP DNS mapping November 2000
5. Delivery Awareness Criteria
In the delivery-aware peering mechanism, the PMT manager make use of
a variety of delivery criteria for create/remove/update the CNAME
records of the PMT.
A set of delivery criteria is associated with each parent and child
delivery name. A set of publisher criteria is also associated to
the publisher delivery names. Therefore, the PMT manager can
decide, on the basis of the criteria sets, which CNAME entry to
create/remove/update in the PMT.
As mentioned above, the publisher may have to modify its delivery
names, in order to match the delivery services needs, possibly using
a URI rewriting system. In addition, the PMT manager has to create
new delivery names (and corresponding internal delivery trees) to
match the need of the publisher or of a peer DNS-MS.
Note that it is not mandatory to have one delivery name for each
possible combination of criteria. Note also that some of these
criteria may not be used in the delivery-aware DNS mapping process
described above. However, they can be used in other mapping
processes.
5.1 Criteria Examples
5.1.1 Publisher criteria
The following lists are not exhaustive and might grow. In this
section, these criteria are presented from a publisher point of
view. The DNS-MS point of view is also mentioned when the publisher
and delivery criteria differs.
5.1.1.1 Delivery Service
A publisher may need to deliver different kind of services or
sub-services:
o web pages
* static web pages
* dynamically generated web pages (asp, cgi-bin, ...)
* web embedded objects (like images)
o standard encoded streams
o proprietary encoded streams, which can be derived for each
Deleuze, et. al. Expires May 21, 2001 [Page 10]
Internet-Draft CDNP DNS mapping November 2000
encoding
5.1.1.2 Delivery Cost
The publisher may specify a maximum cost for the delivery. The
DNS-MS may specify a cost for the usage of its infrastructure. The
definition of these cost criteria depends on business models that
are not addressed here.
5.1.1.3 Delivery Delay
Some contents or type of contents may need to be delivered within a
delay bound. For example, this criterion can exclude the use of
satellite links.
5.1.1.4 Delivery Footprint
Contents may require delivery to specific geographical zones:
o World
o Continents
o Countries
o States/regions
o Cities
o Districts
o Internet Point of Presence (PoP)
or any combination of those.
5.1.2 Delivery Criteria
Each publisher criteria is also a delivery criteria. In addition,
varieties of metrics based on network measurements, DNS-MS feedback
or surrogate feedback are added. These metrics are discussed in [5].
5.2 Default Delivery Names
One or more delivery criteria must be encoded in a delivery name to
define it uniquely. E.g., the web and RTSP service types can be
encoded as follows:
o www.domain.tld for static html pages
Deleuze, et. al. Expires May 21, 2001 [Page 11]
Internet-Draft CDNP DNS mapping November 2000
o rtsp.domain.tld for RTSP compatible stream content
or with a unique identifier (which may be a hash key)
o one.domain.tld
o two.domain.tld
This section gives some recommendations to create delivery names but
does not intend to impose a unique delivery name space.
The delivery trees start with the delivery names of the publisher.
Hence, one publisher delivery name has to be defined for each
delivery tree required either by the publisher or by the global DNS
mapping system. As seen before, the publisher delivery names can be
created with URI rewriting systems. Since the publisher delivery
names may be visible to the users, they should be expressed with
understandable names.
5.2.1 Delivery Name Key
The publisher delivery name should be composed of a delivery key
followed by the publisher domain or subdomain referred as
"domain.tld". The delivery key is composed of one or more DNS
labels. The publisher may choose the delivery key.
The recommended delivery key is composed of only one DNS label:
<delivery-key> ::= <text-part> [ <id-part> ]
<text-part> ::= <letter> | <letter> <text-part>
<id-part> ::= <digit> | <digit> <id-part>
<letter> ::= any one of the 52 alphabetic characters A through Z in upper
case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
Note that while upper and lower case letters are allowed in delivery
key, no significance is attached to the case. This is, two delivery
keys with the same spelling but different case are to be treated as
if identical.
Since delivery keys are DNS labels, they must be 63 characters or
less. Moreover, since CNAME records are appended during DNS
resolution, it is wise to choose short delivery names in order to
fit the whole answer in a single UDP DNS message. If this is not
the case, the requests would be be restarted with TCP, impacting
Deleuze, et. al. Expires May 21, 2001 [Page 12]
Internet-Draft CDNP DNS mapping November 2000
performance.
The text label represents one or more delivery services. The
following are defined, others may be used:
o "www" for web pages
o "ftp" for ftp delivery service
o "rtsp" for standard stream delivery
o "mms" for Microsoft Windows Media delivery
The key label is used to differentiate delivery keys having the same
text label. If only one delivery key uses a text label, it does not
contain a key label. When several delivery keys use the same text
label, the most used (from a user point of view) do not contain a
key label. Hence, the web service may have a "www" delivery key and
the associated "www.domain.tld" delivery name which is already
commonly used.
Other delivery keys having the same text label must have a delivery
key numbered incrementally and consecutively from 1.
5.2.2 Delivery Name Example
A publisher "domain.com" has three delivery requirements, R1 to R3:
o R1 criteria:
* service: dynamically generated web (HTML and images)
* footprint: World
o R2 criteria:
* service: dynamically generated web (HTML and images)
* footprint: France and Germany
o R3 criteria:
* service: RTSP streaming
* footprint: France and Germany
Deleuze, et. al. Expires May 21, 2001 [Page 13]
Internet-Draft CDNP DNS mapping November 2000
5.2.2.1 Publisher Delivery Name
The publisher delivery names would be the following.
R1 and R2 have the same delivery service: www. The publisher
delivery names have to be identified with key labels. As R1 is the
primary requirement of the publisher, the delivery key has no
key-label field. It is "www.domain.com". Contrary, R2 needs a key
label to be differentiated from R1. It is "www1.domain.com".
R2 and R3 have the same delivery footprint, but different delivery
service. Thus, R3 is differentiated from R2 by the delivery service.
The naming is then: "rtsp.domain.com".
Deleuze, et. al. Expires May 21, 2001 [Page 14]
Internet-Draft CDNP DNS mapping November 2000
6. Security Considerations
Specific security issues will be considered later. However, the
architecture will use and adopt existing DNS security standards [7].
Deleuze, et. al. Expires May 21, 2001 [Page 15]
Internet-Draft CDNP DNS mapping November 2000
7. Acknowledgements
Deleuze, et. al. Expires May 21, 2001 [Page 16]
Internet-Draft CDNP DNS mapping November 2000
References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
1034, November 1987.
[2] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987.
[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[4] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering",
Internet draft, draft-day-cdnp-model-03.txt (work in progress),
November 2000.
[5] Cain, B., Douglis, F., Green, M., Hofmann, M., Nair, R. and D.
Potter, "Known CDN Request Mapping Mechanisms", Internet draft,
draft-cain-cdnp-known-req-map-00.txt (work in progress),
November 2000.
[6] Green, M., Cain, B. and G. Tomlinson, "CDN Peering
Architectural Overview", Internet draft,
draft-green-cdnp-gen-arch-01.txt (work in progress), October
2000.
[7] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
Authors' Addresses
Christophe L. Deleuze
ActiVia Networks
Space Antipolis 5
Parc de Sophia Antipolis
2323 Chemin St Bernard
06225 Vallauris, Cedex
FRANCE
Phone: +33 4 97 23 46 66
EMail: Christophe.Deleuze@activia.net
URI: http://www.activia.net/
Deleuze, et. al. Expires May 21, 2001 [Page 17]
Internet-Draft CDNP DNS mapping November 2000
Laurent G. Gautier
ActiVia Networks
Space Antipolis 5
Parc de Sophia Antipolis
2323 Chemin St Bernard
06225 Vallauris, Cedex
FRANCE
Phone: +33 4 97 23 46 46
EMail: Laurent.Gautier@activia.net
URI: http://www.activia.net/
Michael Hallgren
Teleglobe France
Washington Plaza
44, rue Washington
75408 PARIS,
FRANCE
Phone: +33 1 56 59 87 44
EMail: michael.hallgren@teleglobe.com
URI: http://www.teleglobe.com/
Deleuze, et. al. Expires May 21, 2001 [Page 18]
Internet-Draft CDNP DNS mapping November 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Deleuze, et. al. Expires May 21, 2001 [Page 19]