idnits 2.17.1 draft-cao-lwig-dns-serv-simp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-coap' is defined on line 209, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Z. Cao 3 Internet-Draft F. Cao 4 Intended status: Informational China Mobile 5 Expires: September 6, 2012 YC. Ma 6 Hitachi (China) Research and 7 Development Corporation 8 H. Tian 9 China Academy of 10 Telecommunications Research 11 March 5, 2012 13 Lightweight Service Simplification via DNS 14 draft-cao-lwig-dns-serv-simp-00 16 Abstract 18 This memo discusses a lightweight service simplification method via 19 DNS. Instead of storing the information on the Web infrastructure, 20 the service provider can store them on the DNS servers. By 21 expressing these information in the DNS Resource Records, the 22 requester can get these information directly during the DNS name 23 resolution, without the need of accessing any web resource. This way 24 eliminates the overhead caused by TCP handshake and HTTP get/ 25 response, and can be served as a lightweight information provisioning 26 method. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 6, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 64 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. DNS Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 It is normal to provide information service via Web. But in some 76 scenarios where light-weight services are provided, information 77 provisioning via Web is not economic. Before accessing the first 78 HTTP request , the client needs to inquiry the DNS, and finish TCP 79 3-way handshake. If the client only needs to know some simple 80 information, e.g., the temperature or humidity, the overhead of 81 getting these information is considerable higher. 83 This memo discusses a lightweight information provision method via 84 DNS. Instead of storing the information on the Web infrastructure, 85 the service provider can store them on the DNS servers. By 86 expressing these information in the DNS Resource Records, the 87 requester can get these information directly during the DNS name 88 resolution, without the need to accessing any web resource. This way 89 eliminates the overhead caused by TCP handshake and HTTP get/ 90 response, and can be served as a lightweight information provisioning 91 method. 93 Note: this draft contains the initial idea of light-weight service 94 simplification. The authors would improve the description and design 95 considerations in later revisions. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2. Solution Overview 105 We give a simple example in this section. As shown in Figure 1, the 106 user would like to know the temperature of a certain location, 107 denoted by its FQDN "_temp.locA.example.com". It sends a DNS query 108 request to the local DNS server, the local DNS does not have the 109 cached information, and will contact the authorized DNS server which 110 is actually maintained by the information providers. 112 There are some considerations in this mechanism. 114 1. Information expression. How to organize the name space? The 115 provider should organize the content in a way that is compatible 116 with the DNS name space. That is, the specific information 117 semantic is encoded into the FQDN. In the example the 118 temperature is denoted as _temp.*. And the hierarchical name 119 space also contains the parent domain information which is 120 organized in a way that the provider organized its content on the 121 server. 123 2. Information storage. How to store the information on the DNS 124 server? DNS TXT RR [RFC1035] can be used to store the 125 information. The DNS TXT RR can be organized as TLV so that 126 different types of information can be stored in the DNS servers. 128 3. Information request and response. How the user access the 129 information. The user can use the DNS SRV [RFC2782] query to 130 access the stored information on the server. And the TXT RR will 131 be returned in the response message. 133 4. Information Update. The user could also send DNS update requests 134 to the authority DNS servers. The DNS dynamic updates [RFC2136] 135 can be used for information update. 137 User Local DNS Authority DNS Server 138 | SRV Query | | 139 | _temp.locA.example.com | recursive resolution | 140 |--------------------------->|-------------------------->| 141 | Query Result | Query Result | 142 |<---------------------------|<--------------------------| 143 | | | 145 Figure 1: An Example of Information Retrieval 147 If the user is a sensor and would update some resource records on the 148 DNS server, it should send DNS update messages per [RFC2136] to the 149 authority DNS server to update the corresponding resource records. 150 This process is depicted in Figure 2. 152 User Local DNS Authority DNS Server 153 | SRV Update | | 154 | _temp.locA.example.com | recursive resolution | 155 |--------------------------->|-------------------------->| 156 | Update Result | Update Result | 157 |<---------------------------|<--------------------------| 158 | | | 160 Figure 2: An Exmaple of Information Update 162 Note: All the above figures assumes that the local DNS has cached the 163 address of the authority DNS server. If that's not the case, the 164 local DNS resolver will consult the root servers for reference. This 165 also indicates that the cache behavior the upper layer domain names 166 will influence the information retrieval efficiency. 168 The CoAP can also be used by the sensors to update the resource 169 records on the DNS server. In such case, the DNS server should 170 implement CoAP agent. The CoAP agent should have the rights to 171 update the DNS record with some specific FQDN, for example, FQDNs 172 with "_temp" prefix. 174 3. DNS Considerations 176 In order to use the DNS resolution process for service 177 simplification, many aspects such as TTL, cache, authorized server 178 placement should be considered. 180 1. The TTL of DNS resource records. The TTL value of the DNS RR 181 stands for its lifetime, and hence influences the cache behavior 182 of the local DNS resolver. For high real-time requirement 183 applications, the TTL should be set to minimal value zero. For 184 time tolerant applications, the TTL could be set to values 185 greater than zero. For non-zero TTL values, the local DNS 186 funtionally acts as the information cache. 188 2. The placement of the authority DNS server. The authority DNS 189 server for a certain sub-domain should be controlled by the 190 information provider, such as the scenario mentioned in 191 [I-D.vanderstok-core-bc]. The granularity of the sub-domain 192 separation ought to be determined by the provider. Either it 193 could be an authority server controlling the *.example.com sub- 194 domain, or in a denser deployement, an authority server 195 controlling the *.locA.example.com. 197 4. IANA Considerations 199 None. 201 5. Security Considerations 203 The proposal in this document should be compatible with DNSSEC. 205 6. References 207 6.1. Normative References 209 [I-D.ietf-core-coap] 210 Frank, B., Bormann, C., Hartke, K., and Z. Shelby, 211 "Constrained Application Protocol (CoAP)", 212 draft-ietf-core-coap-08 (work in progress), October 2011. 214 [I-D.vanderstok-core-bc] 215 Stok, P. and K. Lynn, "CoAP Utilization for Building 216 Control", draft-vanderstok-core-bc-05 (work in progress), 217 October 2011. 219 [RFC1035] Mockapetris, P., "Domain names - implementation and 220 specification", STD 13, RFC 1035, November 1987. 222 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 223 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 224 RFC 2136, April 1997. 226 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 227 specifying the location of services (DNS SRV)", RFC 2782, 228 February 2000. 230 6.2. Informative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 Authors' Addresses 237 Zhen Cao 238 China Mobile 239 Xuanwumenxi Ave. No.32 240 China, Beijing 100053 241 China 243 Phone: 244 Email: zehn.cao@gmail.com, caozhen@chinamobile.com 246 Feng Cao 247 China Mobile 248 CA 249 USA 251 Phone: 252 Fax: 253 Email: fengcao@chinamobile.com 254 URI: 256 Yuanchen Ma 257 Hitachi (China) Research and Development Corporation 258 301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District 259 China, Beijing 100190 260 China 262 Phone: 263 Email: ycma@hitachi.cn 265 Hui Tian 266 China Academy of Telecommunications Research 267 Huayuanbeilu No.52 268 Beijing, 100191 269 China 271 Phone: 272 Fax: 273 Email: tianhui@mail.ritt.com.cn 274 URI: