6lowapp D. Sturek Internet-Draft Pacific Gas & Electric Intended status: Informational October 15, 2009 Service Discovery for 6LowApp draft-sturek-6lowapp-servicediscovery-00 Status of this Memo This Internet-Draft is submitted to IETF 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 April 18, 2010. Sturek Expires April 18, 2010 [Page 1] Internet-Draft Service Discovery for 6LowApp October 2009 Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract IEEE 802.15.4 networked solutions employing [RFC4944] for applications like Smart Grid Home Area Networking require unattended service discovery which can be supported with small, single packet (or few packet) exchanges. At the same time, it is desirable to mix wired devices into the same network so interoperation of service discovery between devices with differing operational characteristics is desired. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Service Discovery Messaging . . . . . . . . . . . . . . . . 3 2.2. Service Discovery Semantics . . . . . . . . . . . . . . . . 4 2.3. Service Discovery Operations. . . . . . . . . . . . . . . . 4 3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Sturek Expires April 18, 2010 [Page 2] Internet-Draft Service Discovery for 6LowApp October 2009 1. Introduction Service Discovery for 6LowAPP envisions extending the Service Location Protocol ([RFC2608]) for deployment on small packet size devices. The focus for Service Discovery for 6LowAPP is around extending SLP to permit tokenized exchange of XML strings. A previous expired Internet Draft exists extending SLP for embedded device. This prior Internet Draft was evaluated but did not include full exchange of tokenized strings. This internet-draft addresses requirements stated in [I-D.bormann-6lowpan-6lowapp-problem]. 2. Description The IETF Service Location Protocol ([RFC2608]) is a standards track RFC deployed for internet applications. SLP enables definition of service scopes, services and attributes. The discovery mechanism utilizes User Agents (devices wishing to locate services), Service Agents (devices supplying services) and Directory Agents (proxies which can cache service information on behalf of Service Agents). SLP utilizes text strings in the service request and response messages. 2.1 Service Discovery Messaging The specification of Service Discovery for 6LowAPP envisions the following: o Creation of a new RFC which preserves the core features of SLP but replaces the message exchange with tokenized fields The new RFC preserves the semantics of the following SLP messages: o Service Request o Service Reply o Service Registration o Service Acknowledgement o Directory Agent Advertisement o Service Agent Advertisement The new RFC envisions extending the SLP messages to include the following: o (new command) Directory Agent Token Map Request o (new command) Directory Agent Token Map Response The new Internet Draft supports the following message semantics: o Scope and Scope Lists o Services and Service Lists o Attributes and Attribute Lists o (new message semantic) Token Map for Scope, Services and Attributes Sturek Expires April 18, 2010 [Page 3] Internet-Draft Service Discovery for 6LowApp October 2009 2.2 Service Discovery Semantics The key architectural aspect of the proposed Internet Draft is a mapping of the features and capabilities of the binary service discovery protocol used in previous IEEE 802.15.4 deployments to the features and capabilities of [RFC2608]. The similarities between the ZigBee binary protocol and SLP ([RFC2608]) include: o Held discovery information in Service Agents (self describing data held in the individual devices) o Unicast and Multicast discovery requests via Service Request primitives o Unicast discovery responses via Service Reply o (Optional) Service Registration (Directory Agent support for cached discovery information) Here are the proposed architectural principles for the proposed Internet Draft: o Use the Directory Agent to cache (via an XML Schema exchange) a mapping between Scope strings and a well known token o Use the Directory Agent to cache (via an XML Schema exchange) a mapping between Service strings and a well known token o Use the Directory Agent to cache (via an XML Schema exchange) a mapping between Attribute strings and well known tokens The above mapping works in an IEEE 802.15.4 network and, importantly, interoperates with SLP with networked wired devices if the following is performed operationally: o Create a small set of well known Scope strings for the deployment. This set can be extended via a schema exchange but the management of the set of Scope strings is important to maintain in a consistent manner o Create a small set of well known Service strings and Attribute strings. o Host the exchange of XML strings and tokens in the same Directory Agent supported by SLP. o Support Service Discovery for 6LowAPP using a well known UDP port enabling interoperation with SLP on TCP port 427 o Support a setup phase where the IEEE 802.15.4 devices exchange well known XML strings (operationally defined) for well known tokens. After the initial exchange of XML strings for tokens, all requests and responses are via tokens. Sturek Expires April 18, 2010 [Page 4] Internet-Draft Service Discovery for 6LowApp October 2009 2.3 Service Discovery Operations The following operations are proposed for the new Internet Draft: o Identify a Directory Agent for each instance of the HAN. Unlike RFC 2608 [RFC2608], the main role of the DA in the proposed I-D is for storage of the mapping between well known tokens and the SLP Scope, Service and Attribute strings. o Devices joining the network perform DA discovery then use the new DA Token Map Request and populate their local tables with the DA Token Map Response. o Devices use the new I-D Service Request and Service Reply where the tokens in the map replace the strings used in RFC 2608 [RFC2608]. For search functions, the portion of the string operations needed to perform the service match must be included in the proposed I-D messaging The following operational aspects are desired for the proposed I-D: o Outside of the initial download of the Token Map, the operations proposed mirror the features currently deployed in existing IEEE 802.15.4 deployments like ZigBee. The intent is that we use Service Agents (SA) not the Directory Agent (DA) but we have the flexibility to use the DA for sleeping devices if we want o Since the proposed I-D maps to SLP RFC 2608 [RFC2608], it is envisaged that both can be supported in the same network with a mechanism to communicate to the requesting device which service discovery method is supported by a given device. Here are a couple of points to keep in mind with new I-D: o The proposed I-D proposes to maintain the same types of SLP messages but not retain the exact packet format. In particular, the proposed I-D will reformulate the message frames to remove some fields and to tokenize the rest o The proposed I-D seeks to maintain a mapping to SLP RFC 2608 [RFC2608] to enable use of either service discovery method in the same network (supported through the Token Map) o The proposed I-D seeks to maintain the same unicast, multicast and advertisement communication paradigm as RFC 2608 [RFC2608]. Sturek Expires April 18, 2010 [Page 5] Internet-Draft Service Discovery for 6LowApp October 2009 3. Future Work The outline of work presented in this I-D needs to be evaluated against the requirements presented in the 6LowAPP charter and against RFC 2608 [RFC2608]. If accepted, the next step is to create a concrete protocol proposal. 4. Conclusions [RFC2608] forms a good basis of design for service discovery. However, the use of XML strings in the protocol are problematic for IEEE 802.15.4 devices. This I-D seeks to extend the concepts of SLP into a parallel binary service discovery protocol which enables operations from a common Directory Agent. 5. Security Considerations No new security issues have been identified in this draft. This I-D envisions using the same security considerations employed in RFC 2608 [RFC2608]. 6. IANA Considerations This draft envisions assignment of a dedicated port for 6LowAPP Service Discovery. 7. Acknowledgments 8. References Sturek Expires April 18, 2010 [Page 6] Internet-Draft Service Discovery for 6LowApp October 2009 8.1. Normative References [I-D.bormann-6lowpan-6lowapp-problem] Bormann, C., Sturek, D., and Z. Shelby, "6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols", draft-bormann-6lowpan-6lowapp-problem-01 (work in progress), July 2009. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC2608] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service Location Protocol, Version 2", RFC 2608, June 1999. Protocol", RFC 5023, October 2007. 8.2. Informative References Authors' Addresses Don Sturek Pacific Gas & Electric 77 Beale Street San Francisco, CA USA Phone: +1-619-504-3615 Email: d.sturek@att.net