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