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

Versions: 00 01 02

Network Working Group                                        K. Kim, Ed.
Internet-Draft                                picosNet Corp./ Ajou Univ.
Intended status: Standards Track                                  S. Yoo
Expires: December 17, 2007                                        H. Lee
                                                         Ajou University
                                                     S. Daniel Park, Ed.
                                                     SAMSUNG Electronics
                                                                  J. Lee
                                                                     NCA
                                                           June 17, 2007


          Simple Service Location Protocol (SSLP) for 6LoWPAN
                    draft-daniel-6lowpan-sslp-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 December 19, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The Simple Service Location Protocol (SSLP) provides a framework for





Kim, et al.             Expires December 17, 2007               [Page 1]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


   the discovery and selection of the services working on 6LoWPAN.  The
   protocol has a simple structure that is easy to be implemented on
   6LoWPAN devices that are characterized by short range, low bit rate
   and low power.  The protocol also offers a mechanism for
   interoperability with the IP networks under SLP.  It enables
   communication between 6LoWPAN and other IP networks.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1  Notation Conventions . . . . . . . . . . . . . . . . . . .   4
   3.   Protocol Overview  . . . . . . . . . . . . . . . . . . . . .   5
   4.   Transmission and Fragmentation Mechanism for SSLP packets
        in 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.   Required Simple Service Location Protocol(SSLP) Messages . .   9
     5.1  Service Request Message  . . . . . . . . . . . . . . . . .  10
     5.2  Service Reply Message  . . . . . . . . . . . . . . . . . .  11
     5.3  Service Registration Message . . . . . . . . . . . . . . .  12
     5.4  Service Acknowledgment Message . . . . . . . . . . . . . .  13
     5.5  Directory Agent Advertisement Message  . . . . . . . . . .  13
     5.6  Service Agent Advertisement Message  . . . . . . . . . . .  14
   6.   Optional SSLP Messages . . . . . . . . . . . . . . . . . . .  14
     6.1  Service Type Request Message  . . . . . . . . . . . . . ..  14
     6.2  Service Type Reply Message  . . . . . . . . . . . . . . ..  15
     6.3  Service Deregistration Message . . . . . . . . . . . . . .  16
   7.   Interoperability . . . . . . . . . . . . . . . . . . . . . .  16
   8.   IANA Consideration . . . . . . . . . . . . . . . . . . . . .  16
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  16
   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  17
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  17
     11.1   Normative References . . . . . . . . . . . . . . . . . .  17
     11.2   Informative References . . . . . . . . . . . . . . . . .  17
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  18
        Intellectual Property and Copyright Statements . . . . . . .  19
















Kim, et al.             Expires December 17, 2007               [Page 2]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


1.  Introduction

   6LoWPAN stands for IPv6 layer over low-power wireless personal area
   networks (LoWPAN) which consist of devices that conform to the IEEE
   802.15.4-2003 standard [ieee802.15.4].  IEEE 802.15.4 devices are
   used to provide services like home security, fire alarm, medical
   sensing/monitoring, heating control, and building automation, etc.
   When clients want to use services without configuration, a service
   discovery mechanism is needed.

   In IP networks, the Service Location Protocol(SLP) is used for access
   to information about the existence, location, and configuration of
   networked services [RFC2608].  SLP is well operating in IP networks,
   but there are several issues to be solved [I-D.kushalnagar-lowpan-
   goals-assumptions] to apply it to 6LoWPAN.  The limited packet size
   of 6LoWPANs is one of them; Given that in the worst case the maximum
   size available for transmitting IP packets over IEEE 802.15.4 frame
   is 81 octets, and that the IPv6 header is 40 octets long, (without
   optional headers), this leaves only 41 octets for upper-layer
   protocols, like UDP and TCP.  UDP uses 8 octets in the header,
   thereby leaving 33 octets for data, like SLP, over UDP.  However, the
   SLP message could easily be greater than this remaining octets, and
   it should be transmitted as multiple packets, causing traffic
   overheads to 6LoWPAN.

   [I-D.montenegro-lowpan-ipv6-over-802.15.4] introduces the adaption
   layer of fragmentation and reassembly  for IPv6 packets, while
   providing a header compression scheme for reducing the size of the
   IPv6 header.  Also,  it expects that 6LoWPAN uses mesh routing for
   the multi-hop forwarding of IPv6 packets at sub-IP layer.  This makes
   it difficult to use SLP directly, requiring to define a simple
   service discovery protcol to discover, control, and maintain services
   provided by devices in 6LoWPAN.

   This document defines the Simple Service Location Protocol(SSLP)
   which provides a framework for the discovery and selection of network
   services in 6LoWPAN.  SSLP is simple and lightweight to be
   transmitted efficiently in 6LoWPAN.  SSLP in 6LoWPAN could also
   interwork with SLPv2[RFC2608] in external IP networks.  That is,
   clients can discover and control services in 6LoWPAN regardless of
   whether they are located inside the 6LoWPAN or not.

2.  Terminology

   Terminologies used in this document are defined in [RFC2608] as
   follows:





Kim, et al.             Expires December 17, 2007               [Page 3]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


      User Agent (UA)
         A process working on the user's behalf to establish contact
         with some service.  The UA retrieves service information from
         the Service Agents or Directory Agents.

      Service Agent (SA)
         A process working on the behalf of one or more services to
         advertise the services.

      Directory Agent (DA)
         A process which collects service advertisements.

      Service Type
         Each type of service has a unique Service Type string.

      Naming Authority
         The agency or group which catalogs given Service Types and
         Attributes.  The default Naming Authority is IANA.

      Scope
         A set of services, typically making up a logical administrative
         group.

      URL
         A Universal Resource Locator [RFC2396].


   Translation Agent(TA) is newly defined in this document for
   interworking with SLPv2 in IP networks.

      Translation Agent(TA)
         A process is working on a device which has interfaces to both
         IP networks and 6LoWPAN.  TA translates SLPv2 messages into
         SSLP messages, and vice versa.


2.1  Notation Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

      Syntax
         Syntax for string based protocols follow the conventions
         defined for ABNF [RFC2234].






Kim, et al.             Expires December 17, 2007               [Page 4]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


      Strings
         All strings are encoded using the UTF-8 [RFC3629]
         transformation of the Unicode character set and are NOT null
         terminated when transmitted.  Strings are preceded by a two
         byte length field.

      <string-list>
         A comma delimited list of strings with the following syntax:

         string-list = string / string `,' string-list


   In format diagrams, any field ending with a \ indicates a variable
   length field, given by a prior length field in the protocol.

3.  Protocol Overview

   The Simple Service Location Protocol (SSLP) supports the same
   framework as SLP in which client applications are modeled as 'User
   Agents' (UAs), and services are advertised by 'Service Agents' (SAs).
   The 'Directory Agent' (DA) functions as a cache of the information
   about services registered by SAs and informs UAs of the existence of
   services.  Besides, SSLP introduces 'Translation Agents' which
   perform the translation of messages (which are defined in Section 5)
   for the interoperability with SLPv2.

   The role of UA, SA, and DA in SSLP is not quite different from the
   ones in SLP.  The UA issues a 'Service Request' (SREQ) on behalf of
   the client application, specifying the characteristics of the service
   which the client requires.  The UA will receive a 'Service Reply'
   (SREP) specifying the location of all services in the 6LoWPAN which
   satisfy the request.

   SSLP allows both the two-party and three-party service discovery
   mechanisms.  In the two-party discovery, the UA directly issues SREQ
   to SAs.  This mechanism is useful for a small-sized 6LoWPAN because
   it doesn't require the configuration of DAs.  In this case, the UA
   broadcasts (or multicasts if possible) a SREQ to the entire 6LoWPAN
   to which it belongs using the link layer broadcasting scheme.  The
   use of multicasting for service request is TBD if a multicasting
   mechanism is supported in the 6LoWPAN in the future.

   In the three-party discovery, one or more DAs are employed in order
   to reduce the broadcasting overheads of service requests especially
   for a large 6LoWPAN.  SAs send a 'Service Registration' (SREG)
   containing all the services they advertise to DAs and receive
   'Service Acknowledgement' (SACK) in reply.  These advertisements must
   be refreshed with the DA or they expire.  UAs unicast SREQ to DAs



Kim, et al.             Expires December 17, 2007               [Page 5]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


   instead of SAs if any DAs are known.  UAs and SAs MAY discover DAs in
   two ways. One, they broadcast a (SREQ) message for the DA service
   when they start up. Two, the DA sends unsilicited DA advetisment
   message periodially, which is listened by UAs and SAs. In both the
   cases the UAs and SAs receive DA Advertisement (DADV) message.

   Services are grouped together using 'scopes'.  These are strings
   which identify services by location, administrative grouping,
   proximity in a network topology or some other category.

   +--------+-SSLP message-> +-----------+-SLPv2 message-> +--------+
   |UA,SA,DA|                |Translation|                 |UA,SA,DA|
   |of SSLP |                |   Agent   |                 |of SLPv2|
   +--------+ <-SSLP message-+-----------+ <-SLPv2 message-+--------+
           Figure 1: The operation of Translation Agent(TA)

   The 'Translation Agent' (TA) must work on a machine which reaches
   both a IP network and a 6LoWPAN.  If a TA receives either a SLP
   message from a IP network or a SSLP message from a 6LoWPAN, it should
   perform certain translation operation to make the messages
   recognizable to the agents in the other network.  This operation is
   essentially needed for SSLP to be interoperable with SLP and vice
   versa.  With the TA, a UA can discover and control services in
   6LoWPAN regardless of whether they are located inside the 6LoWPAN or
   not.

4.  Transmission and Fragmentation Mechanism for SSLP packets in 6LoWPAN

   All SSLP packets transported over IEEE 802.15.4 are prefixed by an
   encapsulation header stack defined in [I-D.montenegro-lowpan-ipv6-
   over-802.15.4].  Also, all SSLP packets are transmitted and
   fragmented    by the mechanism discussed in [I-D.montenegro-lowpan-
   ipv6-over-802.15.4].  This section summarizes the transmission and
   fragmentation mechanism of [I-D.montenegro-lowpan-ipv6-over-802.15.4]
   for SSLP packets.

   SSLP packets are preceded by an encapsulation header stack. Each
   header in the header stack contains a header type followed zero or
   more header fields. Whereas in an IPv6 header the stack would
   contain, in order, addressing, hop-by-hop options, routing,
   fragmentation, destination options, and finally payload [RFC2460];
   in a LoWPAN header the analogous header sequence is mesh (L2)
   addressing, hop-by-hop options (including L2 broadcast/multicast),
   fragmentation, and finally payload.







Kim, et al.             Expires December 17, 2007               [Page 6]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


   When more than one LoWPAN headers are used in the same packet, they
   MUST appear in the following order:

      Mesh Addressing Header
      Broadcast Header
      Fragmentation Header

   All protocol datagrams (e.g., IPv6, compressed IPv6 headers, etc)
   SHALL be preceded by one of the valid LoWPAN encapsulation headers as
   defined in [I-D.montenegro-lowpan-ipv6-over-802.15.4].

   The definition of headers, other than mesh addressing and
   fragmentation, in LoWPAN consists of a dispatch value, the
   definition of the header fields that follow, and their ordering
   constraints relative to all other headers.

   If an entire payload datagram fits within a single 802.15.4 frame, it
   is unfragmented and has the following format:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3  4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1| Dispatch  | SSLP packet (or type-specific  header)        \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 2: Unfragmented encapsulation header format


   The dispatch type is defined by a zero-bit as the first bit and a
   one-bit as the second bit.

   Dispatch field is a 6-bit selector. It Identifies the type of header
   immediately following the Dispatch Header. The type-specific header
   for the Dispatch type, and payload follow the Dispatch field.

   The dispatch value may be treated as an unstructured namespace.
   The dispatch-type patterns as defined in [I-D.montenegro-lowpan-ipv6-
   over-802.15.4] are:

          Pattern    Header Type

          00xxxxxx    NALP        - Not a LoWPAN frame
          01000001    IPv6        - uncompressed IPv6 Addresses
          01000010    LOWPAN_HC1  - LOWPAN_HC1 compressed IPv6
            ...       reserved    - Reserved for future use
          01010000    LOWPAN_BC0  - LOWPAN_BC0 broadcast
            ...       reserved    - Reserved for future use
          01111111    ESC         - Additional Dispatch byte follows



Kim, et al.             Expires December 17, 2007               [Page 7]


Internet-Draft              SSLP for 6LoWPAN                   June 2007

   The value of dispatch_type for SSLP is assigned via IANA under the
   policy of "Specification Required" [RFC2434].

   If the datagram does not fit within a single IEEE 802.15.4 frame, it
   SHALL be broken into link fragments.  The first link fragment SHALL
   contain the first fragment header (defined by one-bit as the first
   two bits and a zero-bit as the third bit) shown in figure 3.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 0 0 0|    datagram_size    |        datagram_tag           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 3: First fragment encapsulation header format


   The second and subsequent link fragments (up to and including the
   last) SHALL contain a fragmentation header that conforms to the
   format shown below.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 0 0|    datagram_size    |        datagram_tag           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |datagram_offset|
   +-+-+-+-+-+-+-+-+
       Figure 4: Subsequent fragment(s) encapsulation header format


   The datagram_label, datagram_offset, and datagram_size are specifi-
   cally descripted in [I-D.montenegro-lowpan-ipv6-over-802.15.4].

   In case mesh routing is being used, a Mesh Addressing Header precedes
   the SSLP packet. The Mesh Address Header is defined in
   [I-D.montenegro-lowpan-ipv6-over-802.15.4] as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 0|O|F|HopsLft| Originator Address, Final Dest. Address       \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 5: Final destination field format

   The 1-bit field O SHALL be zero if the Originator Address is an
   IEEE extended 64-bit address (EUI-64), or 1 if it is short 16-bit
   address.



Kim, et al.             Expires December 17, 2007               [Page 8]


Internet-Draft              SSLP for 6LoWPAN                   June 2007

   The field F SHALL be zero if the Final Destination Address is an
   IEEE extended 64-bit address (EUI-64), or 1 if it is short 16-bit
   address.

   The HopsLft SHALL be decremented by each forwarding node before
   sending this packet towards its next hop. The packet is discarded if
   HopsLft is decremented to zero.

   The Originator Address is the Originatos's link-layer address.
   Whereas, Final Dest. Address is the link-layer address of the
   Final Destination.

5.  Required Simple Service Location Protocol(SSLP) Messages

   The minimum required implementation of SSLP consists of a UA, SA
   or both. The use of DA in itself is optional but in case a DA is
   deployed it MUST support all the SSLP messages.

   SAs and UAs MUST support SREQ, SREP, and DADV.  SAs MUST also support
   SREG, SACK, and SADV.  For UAs and SAs, to support the other messages
   is OPTIONAL.

   All SSLP messages begin with the following header:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Ver  |   Msg-ID  |O|F|  rsv  |        Sequence number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 6: SSLP general header format

   Ver field describes the version of SSLP being used.

   Msg-ID is the number representing a message type as shown below:

       Message Type       Abbreviation    Msg-ID

       Service Request         SREQ        1
       Service Reply           SREP        2
       Service Registration    SREG        3
       Service Acknowledge     SACK        4
       DA Advertisement        DADV        5
       SA Advertisement        SADV        6
       Service Type Request    STREQ       7
       Service Type Reply      STREP       8
       Service Deregistration  SDER        9





Kim, et al.             Expires December 17, 2007               [Page 9]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


   O and F bit are compatible with the flag field in SLPv2 and defined
   in [RFC2608].  OVERFLOW is set when a message's length exceeds what
   can fit into a datagram.  FRESH is set on every new SREG.

   The sequence number is set to a unique value for each unique SREQ
   message.  If the request message is retransmitted, the same sequence
   number is used.  Replies set the sequence number to the same value as
   the sequence number in the SREQ message.  This field is compatible
   with XID field in SLPv2.

5.1  Service Request Message

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Simple Service Location header (Msg-ID = SREQ = 1)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AM|              Source Address (16/64/128 bit)               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    length of <service-type>   |     <service-type> String     \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length of <scope-list>    |      <scope-list> String      \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 7: SSLP service request message header format

   Addressing Mode (AM) field has three different values as follows:

       Value   Meaning

       01      16 bit short address is used as Source Address field
       10      64 bit extended address is used as Source Address field
       11      128 bit IPv6 address is used as Source Address field

   If <scope-list> field is omitted, length of <scope-list> field MUST
   be set to zero and all services matching <service-type> are
   discovered independent of <scope-list>.

   The <service-type> field consists of service type strings.  Service
   Types SHOULD be defined by a "Service Template" [RFC2609], which
   provides expected attributes, values and protocol behavior.

   In the absence of DAs, SREQ messages are broadcasted over 6LoWPAN.
   SAs MUST broadcast this message whether they have matching service or
   not.

   In the presence of one or more DAs, UAs unicast SREQ messages to
   them. DAs MUST issue SREP messages in response to SREQ messages
   whether they know the service location UAs inquire or not.


Kim, et al.             Expires December 17, 2007              [Page 10]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


5.2  Service Reply Message

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Simple Service Location header (Msg-ID = SREP = 2)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Error Code         |  Service Location Entry count |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  <Service Location Entry 1>  ...  <Service Location Entry N>  \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 8: SSLP service reply message header format


   A nonzero value in Error Code field indicates an error. In case of a
   nonzero value of Error Code, the rest of the message MAY be ignored.
   Moreover, errors are only returned against unicast requests.

   Error Code field has different values as follows:

       Value   Meaning

        1      PARSING_ERROR: The message does not obey the SSLP syntax.
        2      SCOPE_ERROR: The scope field in SSLP message did not
               match to the scope supported by DA or SA.
        3      INTERNAL_ERROR: The DA or SA is not working properly
        4      MSG_NOT_SUPPORTED: The DA or SA gets an optional message
               not being supported
        5      ILLEGAL_REGISTRATION: The SREG has problems
        6      DA_BUSY: UA or SA should retry

   SREP message contains zero or more service location entries.  If no
   matching service locations are present in SAs or DAs, the SREP
   message with zero service location entries is returned in response to
   a unicast SREQ message.  However, a SREP message with zero service
   location entries MUST NOT be sent in response to a broadcast SREQ
   message.

   The service location entry is defined as follows.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Lifetime            |LT |     Service Location      \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 9: Service location entry format



Kim, et al.             Expires December 17, 2007              [Page 11]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


   A service location entry may not be cached longer than the Lifetime
   seconds mentioned in the Lifetime field of Service location entry.

   Location Type (LT) field has three different values as follows:

      Value   Meaning

       01      16 bit short address is used as Service Location field
       10      64 bit extended address is used as Service Location field
       11      URL Location field is used as Service Location field

   If LT field has the value of 11, Service Location field is replaced
   by the URL Location field defined as follows.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          length of URL        |      URL (variable length)    \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 10: URL location field format


5.3  Service Registration Message

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Simple Service Location header (Msg-ID = SREG = 3)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Service Location Entry                    \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    length of <service-type>   |     <service-type> String     \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length of <scope-list>    |      <scope-list> String      \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 11: SSLP service registeration message header format

   In the presence of DAs, SAs MUST register their services with DAs
   by using SREG messages. The SAs MUST register the services
   consistently with all the DAs, based on configuration scope.

   Service Location Entry field contains the address or URL of the SA
   which is registering the service. SAs should reregister the service
   before the Lifetime in Service Location Entry field expires.

   The <service-type> contains the type of the service which is
   available at the location mentioned in Service Location Entry field.


Kim, et al.             Expires December 17, 2007              [Page 12]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


   If <scope-list> field is omitted, length of <scope-list> field MUST
   be set to zero and all services matching <service-type> are
   discovered independent of <scope-list>.


5.4  Service Acknowledgment Message

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Simple Service Location header (Msg-ID = SACK = 4)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Error Code         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 12: SSLP service acknowledgement message header format

   Service Acknowledgement Messages (SACK) messages are received in
   response to the SREG messages. The values of Error Code are same as
   defined in section 5.2.


5.5  Directory Agent Advertisement Message

                           1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Simple Service Location header (Msg-ID = DADV = 5)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Error Code         |    Service Location Entry     \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length of <scope-list>    |      <scope-list> String      \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 13: SSLP directory agent advertisement header format

   A DADV message is sent in two cases. First, when a DA receives a SREQ
   message with service type of "service: directory-agent". Second, to
   send an unsolicited advertising message by the DA.

   The Error Code is set to zero when the DA broadcsts an unsolicited
   advetisement message. If the DADV is unicast (in response to SREQ
   message with "service:directory agent") the DA returns the same
   errors a SREP would.

   The <scope-list> includes the scope provided by the DA. The
   <scope-list> of DA MUST not be NULL.




Kim, et al.             Expires December 17, 2007              [Page 13]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


   DAs MUST send unsolicited periodically. SAs MUST listen for DADVs.
   UAs MAY do this. In case UAs do not listen to the DADVs, they must
   discover the DAs by sending SREQ message with service type of
   "service: directory-agent".


5.6  Service Agent Advertisement Message


                           1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Simple Service Location header (Msg-ID = SADV = 6)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Service Location Entry count  |<Service Location Entry 1...N> \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length of <scope-list>    |      <scope-list> String      \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 14: SSLP service agent advertisement header format

   A SADV message is sent when a SA receives a SREQ message with service
   type of "service: service-agent" or when SAs send unsolicited
   advertisment messages in the absence of DAs. SAs MUST not generate
   Service Agent Advertisement (SADV) messages if they have been
   configured to use specific DA(s).

   The Service Location Entry Count is set to 1 while responding to
   a SERQ with service type of "service: directory-agent". The Service
   Location Entry is filled as "service:directory-agent://<adr of SA>.
   In case of unsolited DADV, all the services provided by the SA are
   listed in the Service Location Entry preceded by the Service Location
   Entry count.


6.  Optional Simple Service Location Protocol(SSLP) Messages


   6.1 Service Type Request

    The service type request (STREQ) allows a UA to find all the service
    types available on the network.









Kim, et al.             Expires December 17, 2007              [Page 14]


Internet-Draft              SSLP for 6LoWPAN                   June 2007



                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Simple Service Location header (Msg-ID = STREQ = 7)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AM|              Source Address (16/64/128 bit)               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length of <scope-list>    |      <scope-list> String      \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 15: SSLP service type message header format

   In the presence of one or more DAs, UAs unicast STREQ messages to
   them.  DAs MUST issue Service Type Reply (STREP) messages in
   response to STREQ messages.

   In the absence of DAs, STREQ messages are broadcasted over 6LoWPAN
   and SAs respond with STREP messages.


6.2 Service Type Reply

                           1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Simple Service Location header (Msg-ID = STREP = 8)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Error Code         |    Service Location Entry     \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length of <stype-list>    |      <stype-list> String      \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 16: SSLP service type reply header format

   The Service Location Entry is included in STREQ to reduce the
   communication overhead when there is no DA. Without Service Location
   Entry the UA ahs to maks two broadcasts. First, it shall broadcast
   STREQ to find all the service types in the network. Second, UA shall
   broadcast SREQ to discover the SAs which can provide a specific
   service type. However, in the presence of Service Location Entry a
   unicast SREQ can be made after knowing all the service types.

   The service type list <stype-list> is a <string-list> field which
   contains the list of available service types with an SA or a DA.






Kim, et al.             Expires December 17, 2007              [Page 15]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


6.3  Service Deregistration Message

   The DA deletes a service registration when the Lifetime for the
   service expires. In case an SA terminates the service provisioning
   before its Lifetime is expired, it SHOULD deregister with the DA. SA
   MUST derigister the services with the same scope list which was used
   for service registration.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Simple Service Location header (Msg-ID = SDER = 9)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Service Location Entry                    \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    length of <service-type>   |     <service-type> String     \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length of <scope-list>    |      <scope-list> String      \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 17: SSLP service deregisteration message header format

   SDER messages are sent to DAs when SAs do not provide their
   services any more. These messages help eliminating any stale
   entries in the DAs.

7.  Interoperability

   SSLP interoperates with SLPv2 via Translation Agent (TA).  A TA MUST
   be capable of the translation between SLPv2 and SSLP.  In other
   words, TA translates SLPv2 messages into SSLP messages, and vice
   versa.  Future revisions will define the operation of a TA in detail.

8.  IANA Consideration

   The prot_type field is defined in [I-D.montenegro-lowpan-ipv6-over-
   802.15.4].  The assignment of prot_type value for SSLP is to be
   coordinated via IANA under the policy of "Specification Required"
   [RFC2434].

9.  Security Considerations

   The security considerations of the [RFC3111] are applicable to this
   document.  Especially, Translation Agent (TA) MUST be secured for
   processing SSLP/SLP messages translation and specific considerations
   will be carefully studied in the next version.





Kim, et al.             Expires December 17, 2007              [Page 16]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


10.  Acknowledgments

   Thanks to Prof. Byung-hee Roh, Shafique Ahmad Chaudhry, Sun-ho Kim,
   Mi-jung Lee, and Minho Lee for their useful discussions and supports
   for writing this document.

11.  References

11.1  Normative References

   [I-D.ietf-6lowpan-format]
              N., Kushalnagar., Montenegro, G., Hui, J., and D. Culler,
              "6LoWPAN: Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", draft-ietf-6lowpan-format (work in progress),
              April 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2165]  Veizades, J., Guttman, E., Perkins, C., and S. Kaplan,
              "Service Location Protocol", RFC 2165, June 1997.

   [RFC2608]  Guttman, E., Perkins, C., Veizades, J., and M. Day,
              "Service Location Protocol, Version 2", RFC 2608,
              June 1999.

   [RFC2609]  Guttman, E., Perkins, C., and J. Kempf, "Service Templates
              and Service: Schemes", RFC 2609, June 1999.

   [RFC3111]  Guttman, E., "Service Location Protocol Modifications for
              IPv6", RFC 3111, May 2001.

   [ieee802.15.4]
              IEEE Compure Society, "IEEE Std. 802.15.4-2003", IEEE Std.
              802.15.4-2003, October 2003.

11.2  Informative References

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [I-D.ietf-6lowpan-problem]
              N., Kushalnagar., Montenegro, G., and C. Schumacher,
              "6LoWPAN: Overview, Assumptions, Problem Statement and
               Goals", draft-ietf-6lowpan-problem (work in progress),
               February 2007.

Kim, et al.             Expires December 17, 2007              [Page 17]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.


Authors' Addresses

   Ki-Hyung Kim, Editor
   picosNet Corp/Ajou Univ
   Wonchun-dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  443-749
   KOREA

   Phone: +82-31-219-2433
   Email: kkim86@picosnet.com


   Seung Wha Yoo
   Ajou University
   Wonchun-dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  443-749
   KOREA

   Phone: +82-31-219-1603
   Email: swyoo@ajou.ac.kr



   Hyang Tack Lee
   Ajou University
   Wonchun-dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  443-749
   KOREA

   Phone: +82-31-219-1891
   Email: hlee@ajou.ac.kr


   Soohong Daniel Park, Editor
   Mobile Platform Laboratory, SAMSUNG Electronics
   416 Maetan-3dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  442-742
   KOREA

   Phone: +82 31 200 4508
   Email: soohong.park@samsung.com


Kim, et al.             Expires December 17, 2007              [Page 18]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


   Jae Ho Lee
   National Computerization Agency
   NCA Bldg, 77, Mugyo-dong, Chung-ku
   Seoul,   100-775
   KOREA

   Phone: +82 2 2131 0250
   Email: ljh@nca.or.kr

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



























Kim, et al.             Expires December 17, 2007              [Page 19]


Internet-Draft              SSLP for 6LoWPAN                   June 2007


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).























Kim, et al.             Expires December 17, 2007              [Page 20]

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