idnits 2.17.1 draft-sturek-6lowapp-servicediscovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4944]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2009) is 5304 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lowapp D. Sturek 3 Internet-Draft Pacific Gas & Electric 4 Intended status: Informational October 15, 2009 6 Service Discovery for 6LowApp 7 draft-sturek-6lowapp-servicediscovery-00 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may contain material 13 from IETF Documents or IETF Contributions published or made publicly 14 available before November 10, 2008. The person(s) controlling the 15 copyright in some of this material may not have granted the IETF 16 Trust the right to allow modifications of such material outside the 17 IETF Standards Process. Without obtaining an adequate license from 18 the person(s) controlling the copyright in such materials, this 19 document may not be modified outside the IETF Standards Process, and 20 derivative works of it may not be created outside the IETF Standards 21 Process, except to format it for publication as an RFC or to 22 translate it into languages other than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 18, 2010. 42 Copyright Notice 44 Copyright (c) 2009 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents in effect on the date of 49 publication of this document (http://trustee.ietf.org/license-info). 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Abstract 55 IEEE 802.15.4 networked solutions employing [RFC4944] for 56 applications like Smart Grid Home Area Networking require unattended 57 service discovery which can be supported with small, single packet 58 (or few packet) exchanges. At the same time, it is desirable to mix 59 wired devices into the same network so interoperation of service 60 discovery between devices with differing operational characteristics 61 is desired. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2.1. Service Discovery Messaging . . . . . . . . . . . . . . . . 3 68 2.2. Service Discovery Semantics . . . . . . . . . . . . . . . . 4 69 2.3. Service Discovery Operations. . . . . . . . . . . . . . . . 4 70 3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 5 78 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 5 80 1. Introduction 82 Service Discovery for 6LowAPP envisions extending the Service 83 Location Protocol ([RFC2608]) for deployment on small packet size 84 devices. The focus for Service Discovery for 6LowAPP is around 85 extending SLP to permit tokenized exchange of XML strings. 87 A previous expired Internet Draft exists extending SLP for embedded 88 device. This prior Internet Draft was evaluated but did not include 89 full exchange of tokenized strings. 91 This internet-draft addresses requirements stated in 92 [I-D.bormann-6lowpan-6lowapp-problem]. 94 2. Description 96 The IETF Service Location Protocol ([RFC2608]) is a standards track 97 RFC deployed for internet applications. SLP enables definition of 98 service scopes, services and attributes. The discovery mechanism 99 utilizes User Agents (devices wishing to locate services), Service 100 Agents (devices supplying services) and Directory Agents (proxies 101 which can cache service information on behalf of Service Agents). 102 SLP utilizes text strings in the service request and response 103 messages. 105 2.1 Service Discovery Messaging 107 The specification of Service Discovery for 6LowAPP envisions the 108 following: 109 o Creation of a new RFC which preserves the core features of 110 SLP but replaces the message exchange with tokenized fields 112 The new RFC preserves the semantics of the following SLP messages: 113 o Service Request 114 o Service Reply 115 o Service Registration 116 o Service Acknowledgement 117 o Directory Agent Advertisement 118 o Service Agent Advertisement 120 The new RFC envisions extending the SLP messages to include the 121 following: 122 o (new command) Directory Agent Token Map Request 123 o (new command) Directory Agent Token Map Response 125 The new Internet Draft supports the following message semantics: 126 o Scope and Scope Lists 127 o Services and Service Lists 128 o Attributes and Attribute Lists 129 o (new message semantic) Token Map for Scope, Services and 130 Attributes 132 2.2 Service Discovery Semantics 134 The key architectural aspect of the proposed Internet Draft is a 135 mapping of the features and capabilities of the binary service 136 discovery protocol used in previous IEEE 802.15.4 deployments to the 137 features and capabilities of [RFC2608]. The similarities between the 138 ZigBee binary protocol and SLP ([RFC2608]) include: 139 o Held discovery information in Service Agents (self 140 describing data held in the individual devices) 141 o Unicast and Multicast discovery requests via Service Request 142 primitives 143 o Unicast discovery responses via Service Reply 144 o (Optional) Service Registration (Directory Agent support 145 for cached discovery information) 147 Here are the proposed architectural principles for the proposed 148 Internet Draft: 149 o Use the Directory Agent to cache (via an XML Schema 150 exchange) a mapping between Scope strings and a well known 151 token 152 o Use the Directory Agent to cache (via an XML Schema 153 exchange) a mapping between Service strings and a well known 154 token 155 o Use the Directory Agent to cache (via an XML Schema 156 exchange) a mapping between Attribute strings and well known 157 tokens 159 The above mapping works in an IEEE 802.15.4 network and, importantly, 160 interoperates with SLP with networked wired devices if the following 161 is performed operationally: 162 o Create a small set of well known Scope strings for the 163 deployment. This set can be extended via a schema exchange 164 but the management of the set of Scope strings is important 165 to maintain in a consistent manner 166 o Create a small set of well known Service strings and 167 Attribute strings. 168 o Host the exchange of XML strings and tokens in the same 169 Directory Agent supported by SLP. 170 o Support Service Discovery for 6LowAPP using a well known UDP 171 port enabling interoperation with SLP on TCP port 427 172 o Support a setup phase where the IEEE 802.15.4 devices 173 exchange well known XML strings (operationally defined) for 174 well known tokens. After the initial exchange of XML 175 strings for tokens, all requests and responses are via 176 tokens. 178 2.3 Service Discovery Operations 180 The following operations are proposed for the new Internet Draft: 181 o Identify a Directory Agent for each instance of the HAN. 182 Unlike RFC 2608 [RFC2608], the main role of the DA in the 183 proposed I-D is for storage of the mapping between well 184 known tokens and the SLP Scope, Service and Attribute 185 strings. 186 o Devices joining the network perform DA discovery then use 187 the new DA Token Map Request and populate their local tables 188 with the DA Token Map Response. 189 o Devices use the new I-D Service Request and Service Reply 190 where the tokens in the map replace the strings used in RFC 191 2608 [RFC2608]. For search functions, the portion of the 192 string operations needed to perform the service match must 193 be included in the proposed I-D messaging 195 The following operational aspects are desired for the proposed I-D: 196 o Outside of the initial download of the Token Map, the 197 operations proposed mirror the features currently deployed 198 in existing IEEE 802.15.4 deployments like ZigBee. The 199 intent is that we use Service Agents (SA) not the Directory 200 Agent (DA) but we have the flexibility to use the DA for 201 sleeping devices if we want 202 o Since the proposed I-D maps to SLP RFC 2608 [RFC2608], it 203 is envisaged that both can be supported in the same network 204 with a mechanism to communicate to the requesting device 205 which service discovery method is supported by a given 206 device. 208 Here are a couple of points to keep in mind with new I-D: 209 o The proposed I-D proposes to maintain the same types of SLP 210 messages but not retain the exact packet format. In 211 particular, the proposed I-D will reformulate the message 212 frames to remove some fields and to tokenize the rest 213 o The proposed I-D seeks to maintain a mapping to SLP RFC 2608 214 [RFC2608] to enable use of either service discovery method 215 in the same network (supported through the Token Map) 216 o The proposed I-D seeks to maintain the same unicast, 217 multicast and advertisement communication paradigm as RFC 218 2608 [RFC2608]. 220 3. Future Work 222 The outline of work presented in this I-D needs to be evaluated 223 against the requirements presented in the 6LowAPP charter and against 224 RFC 2608 [RFC2608]. If accepted, the next step is to create a 225 concrete protocol proposal. 227 4. Conclusions 229 [RFC2608] forms a good basis of design for service discovery. 230 However, the use of XML strings in the protocol are problematic for 231 IEEE 802.15.4 devices. This I-D seeks to extend the concepts of SLP 232 into a parallel binary service discovery protocol which enables 233 operations from a common Directory Agent. 235 5. Security Considerations 237 No new security issues have been identified in this draft. This I-D 238 envisions using the same security considerations employed in RFC 239 2608 [RFC2608]. 241 6. IANA Considerations 243 This draft envisions assignment of a dedicated port for 6LowAPP 244 Service Discovery. 246 7. Acknowledgments 248 8. References 249 8.1. Normative References 251 [I-D.bormann-6lowpan-6lowapp-problem] 252 Bormann, C., Sturek, D., and Z. Shelby, "6LowApp: Problem 253 Statement for 6LoWPAN and LLN Application Protocols", 254 draft-bormann-6lowpan-6lowapp-problem-01 (work in 255 progress), July 2009. 257 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 258 "Transmission of IPv6 Packets over IEEE 802.15.4 259 Networks", RFC 4944, September 2007. 261 [RFC2608] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service 262 Location Protocol, Version 2", RFC 2608, June 1999. 263 Protocol", RFC 5023, October 2007. 265 8.2. Informative References 267 Authors' Addresses 269 Don Sturek 270 Pacific Gas & Electric 271 77 Beale Street 272 San Francisco, CA 273 USA 275 Phone: +1-619-504-3615 276 Email: d.sturek@att.net