Network Working Group K. Kim, Ed. Internet-Draft S. Yoo Expires: January 10, 2006 H. Lee Ajou University S. Daniel Park, Ed. SAMSUNG Electronics J. Lee NCA July 9, 2005 Simple Service Location Protocol (SSLP) for 6LoWPAN draft-daniel-6lowpan-sslp-00.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 January 10, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Simple Service Location Protocol (SSLP) provides a framework for Kim, et al. Expires January 10, 2006 [Page 1] Internet-Draft SSLP for 6LoWPAN July 2005 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. Simple Service Location Protocol(SSLP) Messages . . . . . . 8 5.1 Service Request Message . . . . . . . . . . . . . . . . . 9 5.2 Service Reply Message . . . . . . . . . . . . . . . . . . 10 5.3 Service Registration Message . . . . . . . . . . . . . . . 11 5.4 Service Acknowledgment Message . . . . . . . . . . . . . . 11 5.5 Service Deregistration Message . . . . . . . . . . . . . . 11 5.6 Directory Agent Advertisement Message . . . . . . . . . . 11 5.7 Service Agent Advertisement Message . . . . . . . . . . . 11 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1 Normative References . . . . . . . . . . . . . . . . . . 12 10.2 Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 15 Kim, et al. Expires January 10, 2006 [Page 2] Internet-Draft SSLP for 6LoWPAN July 2005 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 January 10, 2006 [Page 3] Internet-Draft SSLP for 6LoWPAN July 2005 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 January 10, 2006 [Page 4] Internet-Draft SSLP for 6LoWPAN July 2005 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. 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 multicasting 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 January 10, 2006 [Page 5] Internet-Draft SSLP for 6LoWPAN July 2005 instead of SAs if any DAs are known. The discovery of DAs and DA advertisements are TBD. 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 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 prefixed by an encapsulation header with one of the formats illustrated below. NOTE: All fields marked "reserved" or "rsv" SHALL be zero. Kim, et al. Expires January 10, 2006 [Page 6] Internet-Draft SSLP for 6LoWPAN July 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|prot_type|M| SSLP packet (or Final Destination Header) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Unfragmented encapsulation header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|rsv | prot_type |M|datagram_label | datagram_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: First fragment encapsulation header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| datagram_offset |datagram_label | datagram_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Subsequent fragment(s) encapsulation header format Fields are defined in [I-D.montenegro-lowpan-ipv6-over-802.15.4] as follows: LF specifies the relative position of the link fragment within the SSLP packet, as encoded by the following table. LF Position 00 Unfragmented (Figure 2) 01 First Fragment (Figure 3) 10 Last Fragment (Figure 4) 11 Interior Fragment (Figure 4) The value of prot_type for SSLP is assigned via IANA under the policy of "Specification Required" [RFC2434]. M bit is used to signal whether there is a "Final Destination" field as used for ad hoc or mesh routing. If set to 1, a "Final Destination" field precedes the SSLP packet. M bit is set to 1 when the unicast SSLP packet is transmitted. The datagram_label, datagram_offset, and datagram_size are used only when the packet is fragmented. These fields are specifically descripted in [I-D.montenegro-lowpan-ipv6-over-802.15.4]. Kim, et al. Expires January 10, 2006 [Page 7] Internet-Draft SSLP for 6LoWPAN July 2005 The "Final Destination" field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Hops Left | Address of final destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Final destination field format S bit SHALL be zero. [I-D.montenegro-lowpan-ipv6-over-802.15.4] describes that this field is used to signal the use of a short 16 bit address instead of the default IEEE extended 64 bit address format in their future revisions. The hops left SHALL be decremented by each forwarding node before sending this packet towards its next hop. The packet is discarded if Hops Left is decremented to zero. The address of final destination is the final destination's link- layer address. [I-D.montenegro-lowpan-ipv6-over-802.15.4] assumes that this field is 64 bits long, but a future revision may add support for short addresses (16 bits). 5. Simple Service Location Protocol(SSLP) Messages 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 Message Type Abbreviation Msg-ID Service Request SREQ 1 Service Reply SREP 2 Service Registration SREG 3 Service Deregistration SDER 4 Service Acknowledge SACK 5 DA Advertisement DADV 6 SA Advertisement SADV 7 SAs and UAs MUST support SREQ, SREP, and DADV. SAs MUST also support Kim, et al. Expires January 10, 2006 [Page 8] Internet-Draft SSLP for 6LoWPAN July 2005 SREG, SACK, and SADV. For UAs and SAs, to support for other messages is OPTIONAL. 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 | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | 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 field is omitted, length of field MUST be set to zero and all services matching are discovered independent of . The field consists of service type strings. Service Types SHOULD be defined by a "Service Template" [RFC2609], which provides expected attributes, values and protocol behavior. SREQ messages are broadcasted over 6LoWPAN. SAs MUST broadcast this message whether they have the services matching service-type or not. Kim, et al. Expires January 10, 2006 [Page 9] Internet-Draft SSLP for 6LoWPAN July 2005 In the absence of DAs, SREQ messages are broadcasted over 6LoWPAN. In this case, M bit is set to 0 in the encapsulation header. 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. In this case, M bit is set to 1 in the encapsulation header for a SREQ. DAs MUST issue SREP messages in response to SREQ messages whether they know the service location UAs inquire or not. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: SSLP service reply message header format For SREP messages, M bit MUST be set to 1 in encapsulation header. As [I-D.montenegro-lowpan-ipv6-over-802.15.4], final destination field is used when M bit is set to 1. 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 Location Type (LT) field has three different values as follows: Kim, et al. Expires January 10, 2006 [Page 10] Internet-Draft SSLP for 6LoWPAN July 2005 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 SREG messages are used only when DAs exist. SAs MUST register their services to DAs.(TBD) 5.4 Service Acknowledgment Message SACK messages are received in response to the SREG messages.(TBD) 5.5 Service Deregistration Message SDER messages are sent to DAs when SAs does not provide their services any more.(TBD) 5.6 Directory Agent Advertisement Message A DADV message is sent when a DA receives a SREQ message with service type of "service: directory-agent".(TBD) 5.7 Service Agent Advertisement Message A SADV message is sent when a SA receives a SREQ message with service type of "service: service-agent".(TBD) 6. 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. Kim, et al. Expires January 10, 2006 [Page 11] Internet-Draft SSLP for 6LoWPAN July 2005 7. 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]. 8. 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. 9. Acknowledgments Thanks to Prof. Byung-hee Roh, Sun-ho Kim, Mi-jung Lee, and Minho Lee for their useful discussions and supports for writing this document. 10. References 10.1 Normative References [I-D.kushalnagar-lowpan-goals-assumptions] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, Assumptions, Problem Statement and Goals", draft-kushalnagar-lowpan-goals-assumptions-00 (work in progress), February 2005. [I-D.montenegro-lowpan-ipv6-over-802.15.4] Montenegro, G., "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", draft-montenegro-lowpan-ipv6-over-802.15.4-02 (work in progress), February 2005. [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. Kim, et al. Expires January 10, 2006 [Page 12] Internet-Draft SSLP for 6LoWPAN July 2005 [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. 10.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. [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 Ajou University Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 443-749 KOREA Phone: +82-31-219-2433 Email: kkim86@ajou.ac.kr 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 Kim, et al. Expires January 10, 2006 [Page 13] Internet-Draft SSLP for 6LoWPAN July 2005 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 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 Kim, et al. Expires January 10, 2006 [Page 14] Internet-Draft SSLP for 6LoWPAN July 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kim, et al. Expires January 10, 2006 [Page 15]