Simple Service Location Protocol (SSLP) for 6LoWPAN

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. [RFC4944] 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 uses the Tokenized XML strings to minimize the packet excange. 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.

Terminologies used in this document are defined in [RFC2608] as follows: 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. Translation Agent(TA): is newly defined in this document for interworking with SLPv2 in IP networks. TA is a process working on a device which has interfaces to both IP networks and 6LoWPAN. It translates SLPv2 messages into SSLP messages, and vice versa.

Syntax: Syntax for string based protocols follow the conventions defined for ABNF [RFC2234]. 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.

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 4) 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. 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. DA caches mapping of Service to XML Token. SACK includes the corresponding Token that DA has assign to the SREG service. These advertisements must be refreshed with the DA or they expire. UAs unicast SREQ to DAs 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. DADV message contains the XML token corresponding to SREQ service 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. +-----------+-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 maps the SSLP messages to SLP messages and vice versa. TA gets Service Request Messages from DA of SSLP and forwards to corresponding SLP messages . 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. Further work on TA TBD.

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: Ver field describes the version of SSLP being used. Msg-ID is the number representing a message type as shown below: Two more message types and there detail needs TBD 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.

| String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: SSLP service request message header format ]]> Addressing Mode (AM) field has three different values as follows: 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 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.

... < Service Location Entry N > \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: 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: 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: 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: If LT field has the value of 11, Service Location field is replaced by the URL Location field defined as follows.

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

| String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: 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. 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".

\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: 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.

The service type request (STREQ) allows a UA to find all the service types available on the network. | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: 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.

| String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: 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.

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. | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: 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.

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. SSLP Service Request will be tranformed to SLP Service Request message. TA receives Service Reply from SLP and then transforms that message to SSLP Service Reply Message.

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 versions.

TBD.

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