Network Working Group J. Lee Internet Draft ETRI Intended status: Informational W. Lim Expires: March 2015 ETRI W. Chun HUFS September 17, 2014 Scalable Domain-based Routing Scheme draft-lee-icnrg-domainbasedrouting-02.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 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. 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 March 17, 2015. Lee Expires March 17, 2015 [Page 1] Internet-Draft Scalable Domain-based Routing September 2014 Copyright Notice Copyright (c) 2014 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. Abstract Moving the focus from nodes to information objects raises scalability issues because the number of addressable information objects is huge compared to the number of nodes, so scalable routing is an important challenge issue of ICN. There are two types of naming scheme which have been proposed in the ICN literatures: hierarchical and flat. To guarantee clean separation of identifier from locator and scalability of routing, we chose flat name and designed domain-based routing. A significant requisite to be considered when flat name is used is an efficient name-resolution system (NRS). Bloomfilter-based NRS [BF NRS] is our proposal to this issue. Once a name is resolved into locator(s), discovery and delivery steps are carried out based on the routing scheme of locator. For scalability in routing of locator, network is projected into hierarchically-organized domain structure. A domain is a group of nodes or other domains. This composition could be physical or logical. Each domain has its own identifier, and the concatenation of domain IDs from top level domain to a certain domain which a node belongs to plays the role of "locator" for that node. Each domain has one or more domain gateways. All traffic from/to the domain should pass through any of domain gateways. Routing information based on this type of locators is exchanged among domain gateways by using modified link-state routing protocol which can suppress LSA explosion [LSR]. Thanks to this hierarchical domain structure, locators are highly aggregatable (which means scalable routing), and any node in heterogeneous network can communicate each other. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document ........................... 4 Lee Expires March 17, 2015 [Page 2] Internet-Draft Scalable Domain-based Routing September 2014 3. Terminologies ............................................... 4 4. Domain-based Routing Scheme ................................. 5 4.1. Network as Hierarchically-organized Domain Structure ... 5 4.2. Name Resolution System (NRS) ........................... 6 4.3. Scalable Domain-Based Routing .......................... 6 4.3.1. LSA filtering to prevent LSA flooding ............. 7 4.4. Name based Forwarding .................................. 7 4.5. In-network Caching ..................................... 8 4.6. Mobility Management .................................... 8 4.7. Inner-domain Communication ............................. 8 4.8. Security ............................................... 8 4.9. Transport Service ...................................... 8 4.10. Operations ............................................ 9 4.10.1. Presenting ....................................... 9 4.10.2. Name Resolution & Discovery ...................... 9 4.10.3. Delivery ........................................ 11 4.10.4. Mobility Management ............................. 11 5. Comparison with other ICN approaches [ICN survey] .......... 12 6. Example scenario ........................................... 13 6.1. Locator-based Routing : routing tables ................ 14 6.2. Server Discovery (path discovery) ..................... 14 6.3. Name-based Forwarding (Name-based delivery) ........... 15 7. Security Considerations .................................... 16 8. IANA Considerations ........................................ 16 9. References ................................................. 16 9.1. Informative References ................................ 16 1. Introduction Moving the focus from nodes to information objects raises scalability issues. Currently, the Internet is addressing on the order of 10^9 nodes, whereas the number of addressable ICN objects is expected to be several orders of magnitude higher [ICNRG charter]. Therefore, scalable routing scheme is an important challenge issue of ICN. ICN routing locates a data object based on its name which is initially provided by a requestor. ICN routing may comprise 3 steps: a name resolution step, a discovery step, and a delivery step. Depending on how these steps are combined, ICN routing schemes can be categorized as Route-By-Name Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid Routing (HR) [2]. To keep the advantage of separating identifier from locator we chose flat name scheme, which means LBNR is used as routing scheme. If LBNR is used a Name Resolution System (NRS) is required. An efficiency of NRS is a significant requisite in LBNR scheme because every name Lee Expires March 17, 2015 [Page 3] Internet-Draft Scalable Domain-based Routing September 2014 should be resolved through the NRS. Bloomfilter-based NRS [9] is our answer to this issue. Once the locator for the name is obtained, discovery and delivery steps may depend on the routing scheme of locator. For scalability in routing scheme of locator, we projected networks into hierarchically-organized domain structure. A domain is a group of nodes of other domains, and this group could be physical or logical. Each domain has its own identifier, and the concatenation of these IDs from top level domain to a certain domain which a node belongs to plays the role of "locator" for that node. Each domain could have one or more domain gateways. All traffic from/to the domain should pass through any of its domain gateway. Routing information based on the locator is exchanged among domain gateways which belong to different domains by running modified link- state routing protocol. It suppresses LSA storm by using LSA- filtering rule between parent and child domain. Thanks to this hierarchical domain structure, locators are highly aggregatable, and routing operates regardless of the underlying network protocol. 2. Conventions used in this document 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]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. 3. Terminologies o Domain: a logical/physical group of nodes (requestor, contents server, or other "domain") which have similar characteristics (E.g. network protocol, geographical region, same type of contents, similar category of contents etc.). o Locator: locator is a concatenation of IDs of hierarchically organized domains. Lee Expires March 17, 2015 [Page 4] Internet-Draft Scalable Domain-based Routing September 2014 o Domain Gateway: a kind of border gateway for a domain. The domain gateway forwards request message or NDO data, and runs routing protocol carrying routing information based on the locator. 4. Domain-based Routing Scheme 4.1. Network as Hierarchically-organized Domain Structure domain ID: A +---------------------------------------+ | +-----+ +-----+ | | | +-------+ 1 | | | | | | | | tier-0 | ++----+ +-----+ | locator: A | / | \ | | / | \ | | / | \ | +/----|-----------------\---------------+ / | \ / | domain ID: B \ +---------|----------------------------+ | | | | +----++ +-----+ | | | 2 +----------------+ 3 | | | | +---------+ | | | tier-1 | +-----+ | +-----+ | locator: A:B | +-+----+ | | | | | | | | | | +-+----+ | | / | \ | | / | \ | | / | \ | +--------------/-----|--------\--------+ / +----+ \ / | domain ID: C \ +----|-----------------+ | | | | +--+--+ +-----+ | | | 4 +----+ 5 | | tier-2 | | | | | | locator: A:B:C | +-----+ +-----+ | | | +----------------------+ Figure 1 Hierarchical domain structure Lee Expires March 17, 2015 [Page 5] Internet-Draft Scalable Domain-based Routing September 2014 In our scheme network is projected as a set of domains, and each of which may be further decomposed into smaller domains recursively. Each domain has its own ID and the concatenation of consecutive domain IDs can play the role of "locator". Figure 1 shows an example of domain structure. For example, locator for node 3 is A:B, and locator for node 5 is A:B:C. All traffic to and from a domain should pass through a domain gateway. Node 2, 4 in this figure are domain gateways. 4.2. Name Resolution System (NRS) If flat name scheme is used, efficient name resolution system is very important. In Name resolution step a requestor queries current locator of a name to the NRS. For fast processing hashing technique (like bloom filter) could be used to implement NRS. We also proposes Bloom filter based NRS [BF NRS]. 4.3. Scalable Domain-Based Routing Generally speaking, routing means the process of selecting best paths in a network along which to send network traffic. In other words, routing is the process of building network topology database and computing routing table based on that network topology. In our domain based structure, we build network topology graph by link-state routing protocol. However, not like existing link-state routing protocol, vertex of our network topology graph could be an actual communication entity or "a domain". This means each domain gateway which belongs to different domain in different tier has different topology graph. The higher tier a domain gateway belongs to, more abstracted topology graph it would have. domain ID: A +---------------------------------------+ | | | +-----+ +-----+ | | | +-------+ 1 | | | | | | | | tier-0 | +-----+ +-----+ | locator: A | | | | | | +---------------------------------------+ Figure 2 Domain gateway 1's view for whole network topology o Contents server as a domain gateway Lee Expires March 17, 2015 [Page 6] Internet-Draft Scalable Domain-based Routing September 2014 Usually a contents server maintains many NDOs (i.e. entities with name), and therefore the contents server could be considered as another "domain gateway", which means it also joins routing procedure. But it does not need to maintain forwarding cache for NDOs (i.e. contents server already knows where NDOs are!). 4.3.1. LSA filtering to prevent LSA flooding Each domain gateway runs modified link-state routing protocol. Each LSA transfers "locator" information instead of IP prefix. Thus, locators appears in destination field of routing table. To suppress LSA storm each domain gateway forwards LSAs to the other domain gateways according to the following filtering rules: o LSAs in tier N domain are forwarded to all domain gateways in same tier domain. o LSAs in tier N-1 are injected to tier N gateways. o LSAs in tier N+1 are filtered, LSA which has aggregated locator is injected to tier N instead. (E.g. see Figure 6, [GW #2] delivers LSA which includes 0x0B:0x0C to [GW #1], locator for domain 0x0E (0x0B:0x0C:0x0E) is not flooded into [GW #1]). This results in topology reduction effect. Therefore, each domain gateway would have topology graph which is as reduced as possible in its current position (tier). 4.4. Name based Forwarding Under the principle of separating identifier from locator, header of each request message and data packet include name information only. Therefore, each domain gateway should know where to forward packets to reach the NDO. The domain gateways can get this information from "forwarding cache". Forwarding cache for certain name is built during discovery step. Forwarding cache includes following information. o Destination name: name of NDO, or name of requestor o Next-hop address: address of next-hop domain gateway. It can be any type of address (e.g. IPv4 address, IPv6 address, Ethernet address, ...) o Next-hop protocol id: protocol for next-hop gateway (e.g. IPv4, IPv6, Ethernet, ...) Lee Expires March 17, 2015 [Page 7] Internet-Draft Scalable Domain-based Routing September 2014 o Output interface Each domain gateway maintains routing table based on "locator". When the domain gateway receives packets destined for certain "name", it queries NRS to get current "locator" of NDO mapped with the "name". With this "locator" the domain gateway looks up its routing table to find routing table entry matching "locator". If matching one is found, forwarding cache for "name" is built by merging "name" and "forwarding information" part of the routing table entry. o The forwarding cache is built reactively, and maintained by lifetime timer. o Usually many forwarding cache can be shared by many request from many other requestor. 4.5. In-network Caching Under our structure, NDO can be cached on any domain gateway, or it could even be cached any node in the domain managed by the domain gateway. Once the NDO is cached on any node, the node adds its "locator" to the name of NDO through NRS. Afterwards, during discovery step cached NDO which has closer locator could be used. 4.6. Mobility Management Mobility support can be implemented very easily because all messages and data packets don't include any location-related information (e.g. locator). Usually if any domain gateway detects transmission failure, it restarts discovery step, then several forwarding caches on the path will be up-to date. There is almost nothing that end nodes should do. 4.7. Inner-domain Communication TBD. 4.8. Security TBD. 4.9. Transport Service TBD. Lee Expires March 17, 2015 [Page 8] Internet-Draft Scalable Domain-based Routing September 2014 4.10. Operations 4.10.1. Presenting The first thing to do that every node (e.g. requestor, contents server...) attaches network is to update (or add newly) its current location. This is done by the domain gateway of domain which the nodes belongs to. +---------+ +-------------+ +----+ +----------------+ +--------+ |requestor| | domain gw | |NRS | | domain gw | |contents| | | |for requestor| | | |for contents svr| | svr | +---------+ +-------------+ +----+ +----------------+ +--------+ | | | | | | 1.0 | | | | |-------------> | | | 2.0 | | | 1.1 | |<--------------| | |---------->| 2.1 | | | | |<-----------| | | | | | | | | | | | Figure 3 Presenting current location o 1.0 - presence message: deliver {requestor's name} to the domain gateway o 1.1 - update message: domain gateway sends update including {requestor's name, its locator} to NRS o 2.0 - presence message: deliver {name of NDO} to the domain gateway o 2.1 - update message: domain gateway sends update including {name of NDO, its locator} to NRS 4.10.2. Name Resolution & Discovery When a requestor issues request for a NDO on the network, name resolution and discovery procedure is carried out by domain gateways. During this procedure, forwarding cache entry for NDO includes followings: o NDO's ID o Next hop information (found in the routing table entry) Lee Expires March 17, 2015 [Page 9] Internet-Draft Scalable Domain-based Routing September 2014 Forwarding cache entry for the requestor includes followings: o Requestor's ID o Previous hop information (found in the packet header) +----+ |NRS | +----+ +---------+ +-------------+ | +----------------+ +-------+ |requestor| | domain gw | | | domain gw | |contens| | | |for requestor| .. ...| .. |for contents svr| | svr | +---------+ +-------------+ | +----------------+ +-------+ | | | | | | 1.0 | | | | |-------------> | 1.1 | | | | |------------>| | | | | 1.2 | | | | |<------------| | | | | | | | | |----+ | | | | | |1.3 | | | | |<---+ | | | | | | 1.4 | | | |------------------------->| | | | | |----+ | | | | | |1.5 | | | | |<---+ | | | | | 1.6 | | | | |-------------->| | | | | 1.7 | | | | 1.8 |<--------------| | 1.9 |<-------------------------| | |<--------------| | | | | | | | | Figure 4 Discovery procedure o 1.0 - request message: request message including {name of NDO} o 1.1 - lookup message: request {locator} for {name of NDO} o 1.2 - reply message: deliver {locator(s)} for {name of NDO} o 1.3 - build bi-directional forwarding cache Lee Expires March 17, 2015 [Page 10] Internet-Draft Scalable Domain-based Routing September 2014 o 1.4 - forward request message: this request message includes {locator for requested NDO} to avoid unnecessary name resolution. (While this request message is being forwarded to the domain gateway for contents server, domain gateways on the path build bi- directional forwarding caches) o 1.5 - build bi-directional forwarding cache o 1.6 - deliver request message to the contents server o 1.7 ~ 1.9 - delivery step, deliver NDO data to the requester 4.10.3. Delivery After discovery step, forwarding caches are ready on path to the NDO, and on path to the requestor. Forwarding caches to the NDO may be reused by other request from other requestors who want same NDO. Forwarding caches to the requestor are used to deliver NDO. See 1.7 ~ 1.9 in Figure 4. 4.10.4. Mobility Management TBD. Lee Expires March 17, 2015 [Page 11] Internet-Draft Scalable Domain-based Routing September 2014 5. Comparison with other ICN approaches [ICN survey] +-------------------------------------------------------------------+ | | PSIRP | NetInf | Domain-based | | | | | Routing | +-------------------------------------------------------------------| |Namespace structure | flat with | flat with | flat no | | | structure | structure | structure | +-------------------------------------------------------------------| |Human-readable names | no | no | no | +-------------------------------------------------------------------| |NDO granularity | Objects | Objects | Objects | +-------------------------------------------------------------------| |Routing aggregation | scope | publisher | Domain | | | /explicit | | | +-------------------------------------------------------------------| |Routing of NDO request| NRS | Hybrid NRS &| NRS | | | | name based | | +-------------------------------------------------------------------| |Routing of NDO | Source | Reverse | Reverse | | |routing using |request path/|request path | | | BF | direct IP | | +-------------------------------------------------------------------| |API | Publish | Synchronous | IPlug/Dsocket | | | /Subscribe | get | | +-------------------------------------------------------------------| |Transport | IP/PSIRP | Many | Many | | | | including IP| including IP | +-------------------------------------------------------------------+ Figure 5 Comparison with other ICN approaches Figure 5 shows summary of different ICN approaches. PSIRP and NetInf are using flat name like ours, however our approach uses flat name without any structure for strict separation of name from location. Names for all of them are non-human readable. Routing is aggregated by the domain in our approach. All of them are using NRS for routing of NDO request. To route NDO to the requestor NetInf and our approach are using reverse request path. Regarding transport method, NetInf and our approach can support any protocol including IP, which means they support communication between nodes in heterogeneous network. Lee Expires March 17, 2015 [Page 12] Internet-Draft Scalable Domain-based Routing September 2014 6. Example scenario +-----------------------------------------------------------------+ | | | (Domain Id: 0x0A, IPv4) | | +------[GW #0]----------------------+ | | | | | | | | | | | | | | | | | | | | | | | +--------------------------+ | | | | | (Domain Id:0x0B, IPv4) | | | +-------------------[GW #1]--------------------------------+ | | | ^^^^^^^^ | <------------------------> | | | | | NRS |----- +------< requestor A (Id: 0xFF) > | | | | ^^^^^^^^ | <------------------------> | | | | | | | | | +--------------------------------+ | | | | | | | | | |(Domain Id:0x0C, IPv6)| | | | | | +----------------[GW #2]-+ (Domain Id:0x0D, Ethernet)| | | | | | | | +------------------[GW #3]| | | | | | | | server3 | | | | | | | server1 | | | +========+ | | | | | | | +=============+ | | | | | | | | | | | | | StarWars | | | | | +--------+ | | | | | | | (0xEE) | | | | | | | | | | | | | | | | | | +========+ | | | | | | | | +---+ | | | | | | | | | +=============+ | | | <-------------> | | | | | | | | | < requestor B > | | | | | |(Domain Id:0x0E, IPv4) | | < (Id: 0xAF) > | | | | | | +-----------[GW #4]-+ | | <-------------> | | | | | | | server2 | | | | | | | | | | | +==========+ | | | +-----------------------+ | | | | | | | | | | | | | | | | | | +--+ | | | | | | | | +==========+ | | | | | | | +-------------------+ | | | | | +------------------------+ | | | +----------------------------------------------------------+ | +-----------------------------------------------------------------+ Figure 6 Sample Domain Architecture Lee Expires March 17, 2015 [Page 13] Internet-Draft Scalable Domain-based Routing September 2014 6.1. Routing tables +---------------------+--------------------+--------+ | Destination | nexthop | out if | +---------------------+--------------------+--------+ | 0x0B:0x0C | GW #2's address | if1 | +---------------------+--------------------+--------+ | 0x0B:0x0D | GW #3's address | if1 | +---------------------+--------------------+--------+ | 0x0B | - | if1 | +---------------------+--------------------+--------+ | 0x0A | GW #0's address | if0 | +---------------------+--------------------+--------+ Figure 7 Example of Routing Table (GW #1) +---------------------+--------------------+--------+ | Destination | nexthop | out if | +---------------------+--------------------+--------+ | 0x0B:0x0C:0x0E | GW #4's address | if1 | +---------------------+--------------------+--------+ | 0x0B:0x0D | GW #3's address | if0 | +---------------------+--------------------+--------+ | 0x0B:0x0C | - | if1 | +---------------------+--------------------+--------+ | 0x0B | GW #1's address | if0 | +---------------------+--------------------+--------+ | 0x0A | GW #1's address | if0 | +---------------------+--------------------+--------+ Figure 8 Example of Routing Table (GW #2) +---------------------+--------------------+--------+ | Destination | nexthop | out if | +---------------------+--------------------+--------+ | 0x0B:0x0C | GW #2's address | if0 | +---------------------+--------------------+--------+ | 0x0B:0x0D | - | if1 | +---------------------+--------------------+--------+ | 0x0B | GW #1's address | if0 | +---------------------+--------------------+--------+ | 0x0A | GW #1's address | if0 | +---------------------+--------------------+--------+ Figure 9 Example of Routing Table (GW #3) 6.2. Server Discovery (path discovery) When a requestor gets locator for a specific NDO from NRS, it build a path discovery message and forwards to the default domain gateway (in Lee Expires March 17, 2015 [Page 14] Internet-Draft Scalable Domain-based Routing September 2014 this example, "requestor A" send path discovery message to GW #1). The path discovery message includes followings: +------------------------------------------------------------------+ | Network header | +------------------------------------------------------------------+ | Requestor's ID | +------------------------------------------------------------------+ | NDO's ID | +------------------------------------------------------------------+ | NDO's current locator | +------------------------------------------------------------------+ If a domain gateway receives path discovery message, it looks up its forwarding cache table firstly. If there is no forwarding cache entry for the NDO's ID, the domain gateway builds new forwarding cache entry. The domain gateway searches its routing table by using "locator (included in the path discovery message)" as key, then it builds forwarding cache entry for the NDO's ID and requestor's ID. Forwarding cache entry for NDO includes followings: o NDO's ID o Next hop information (found in the routing table entry) Forwarding cache entry for the requestor includes followings: o Requestor's ID o Previous hop information (found in the network header) After building the forwarding cache, the path discovery message is forwarded to the next hop domain gateway (network header is changed according to the next-hop information of forwarding cache), and repeat this procedure until it reaches domain which includes the NDO. Forwarding caches are managed in the manner of timer-based way. 6.3. Name-based Forwarding When the contents server which has requested NDO receives path discovery message, it sends NDO data by using following message format: Lee Expires March 17, 2015 [Page 15] Internet-Draft Scalable Domain-based Routing September 2014 +------------------------------------------------------------------+ | Network header | +------------------------------------------------------------------+ | Requestor's ID | +------------------------------------------------------------------+ | NDO data | +------------------------------------------------------------------+ Network header would be changed according to the next hop information of forwarding cache. 7. Security Considerations TBD. 8. IANA Considerations TBD. 9. References 9.1. Informative References [ICNRG charter] http://irtf.org/icnrg [ICN Challenges] D.Kutscher, "ICN Research Channelges", internet- draft, July 2013 [aRoute] Ahmed, Reaz, Md Faizul Bari, Shihabur Rahman Chowdhury, Md Golam Rabbani, Raouf Boutaba, and Bertrand Mathieu. "aRoute: A Name Based Routing Scheme for Information Centric Networks." In IEEE International Conference on Computer Communications (INFOCOM) Mini-Conference, 2013. [ICN survey] Ahlgren, Bengt, Christian Dannewitz, Claudio Imbrenda, Dirk Kutscher, and Borje Ohlman. "A Survey of Information-Centric Networking." Communications Magazine, IEEE 50, no. 7 (2012): 26-36. [Id net] http://www.idnet.re.kr/ [BF NRS] J. Hong, "Bloom Filter-based Flat Name Resolution System for ICN", http://www.ietf.org/internet-drafts/draft-hong-icnrg- bloomfilterbasedname-resolution-00.txt Lee Expires March 17, 2015 [Page 16] Internet-Draft Scalable Domain-based Routing September 2014 [LSR] W. Lim, "Design of Scalable Link-State Routing Protocol for Efficient Inter-Domain Routing" in IEEE Communication letter (is being under examination) Authors' Addresses Joo-Chul Lee ETRI 161 Gajeong-dong, Yuseong-gu, Daejon Phone: Email: rune@etri.re.kr Wan-Seon Lim ETRI 161 Gajeong-dong, Yuseong-gu, Daejon Phone: Email: wslim@etri.re.kr Woo-Jik Chun HanKuk University of Foreign Studies 81, Oedae-ro, Mohyeon-myeon, Cheoin-gu,Yongin-si, Gyeonggi-do, 449- 791, Korea Phone: Email: woojikchun@gmail.com Lee Expires March 17, 2015 [Page 17]