[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/