INTERNET DRAFT Weibin Zhao draft-zhao-slp-attr-00.txt Henning Schulzrinne March 25, 2002 Columbia University Expires: September 25, 2002 Defining and Using Global Service Attributes in SLP Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes a mechanism for extending the functionality of the Service Location Protocol (SLP) via defining and using global service attributes. A global service attribute is service type independent. It is used for describing a common service property or for a service management purpose. Its name begins with the "service-" prefix. It is defined using an attribute template, and can be imported into any service template. We give examples of three global service attributes: service-id, service-transport-protocol, and service-replication-id. We also show how to use global service attributes to support replicated server groups, multiple access protocols, multiple transport protocols, and URL changes. Zhao/Schulzrinne Expires: September 25, 2002 [Page 1] Internet Draft SLP Global Service Attributes March 25, 2002 1. Introduction The Service Location Protocol (SLP [1]) provides a flexible framework for service discovery in IP networks. A service in SLP is described using four components: service URL, service type, service scope list, and service attribute list. The service type indicates the main category the service belongs to; a corresponding service template defines the service type's attributes. In SLP, service attributes are local as they are defined and used in the context of a particular service type. Global service attributes that are service type independent are not supported in current SLPv2. A global service attribute is used for describing a common service property which has a well-defined consistent meaning across all service types, or for a service management purpose. In a sense, service URL, service type, and service scope list can be viewed as global service attributes. As SLP evolves, it needs to support new global service attributes, such as service id [7], service transport protocol, and service replication id, in order to meet new discovery requirements and optimize existing discovery operations. In general, enabling good extensibility in SLP is important for it to be enhanced continuously. Currently the functionality of SLP can be extended along two dimensions: using new SLP extensions ([2],[3],[4],[5],[6]) and messages ([5]) which adds more functions to the basic SLP framework, and using new service templates which extends the usage of SLP to more applications. Using new global service attributes opens up a new dimension for extending SLP, which is orthogonal to the existing two approaches. One way to support global service attributes in SLP is to define new SLP message components, similar to the use of service URL, service type and service scope list, which will change the existing SLP message format and lead to poor compatibility. Since any information can be fit into the service attribute list in SLP, a better way to support global service attributes is to refine the service attribute list to accommodate both global service attributes (service type independent) and local service attributes (service type specific). To distinguish between global and local service attributes, the "service-" prefix is reserved. A global service attribute name MUST begin with "service-", and any service type specific attribute name SHALL NOT begin with "service-". A global service attribute is defined using an attribute template (see section 2). Any service using a global service attribute needs to import the attribute's definition into its service template (similar to C include and Java import mechanism). Defining a global service attribute once and using it consistently in all types of Zhao/Schulzrinne Expires: September 25, 2002 [Page 2] Internet Draft SLP Global Service Attributes March 25, 2002 services is advantageous in that it avoids defining the same service attribute repeatedly in every service template, and the SLP functionality can be extended if a special function is associated with a new global service attribute. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted according to RFC 2119 [8]. 2. Global Service Attribute and Attribute Template A global service attribute MUST be defined using an attribute template. Normally each global service attribute uses a separately attribute template. If several global service attributes SHOULD be used together, they MAY be defined in one attribute template. All attribute templates MUST be defined in English. An attribute template file has a naming convention based on the first attribute name that it defines (see section 2.2). 2.1. The Syntax of Attribute Template An attribute template is a simplified version of the service type template (RFC 2609 [9]). It is defined using the following ABNF [10]: attr-template = version attr-defs version = "# attribute-template-version" version-no term version-no = version-no from section 3.1 of RFC 2609 term = term from section 3.1 of RFC 2609 attr-defs = 1*(attr-def) attr-def = attr-def from section 3.1 of RFC 2609 2.2. Attribute Template File Name An attribute template file has a naming convention (similar to the service type template file) defined using the following ABNF: attr-tem-fname = attribute-name "." version-no attribute-name = id from section 3.1 of RFC 2609 version-no = version-no from section 3.1 of RFC 2609 For example, if a global service attribute "service-attribute-x" is defined as the first attribute in an attribute template, and the version number is 1.0, then the attribute template file name will be "service-attribute-x.1.0". 2.3. Importing Global Service Attributes A service using a global service attribute needs to import the Zhao/Schulzrinne Expires: September 25, 2002 [Page 3] Internet Draft SLP Global Service Attributes March 25, 2002 attribute's definition. To support this, the ABNF of service type template defined in RFC 2609 needs to be extended as follows: attr-defs = *( attr-def / keydef / import-line ) import-line = "import" attr-tem-fname attr-tem-fname = attr-tem-fname from section 2.2 of this document 3. Examples of Defining Global Service Attributes 3.1. The "service-id" Attribute Template Name of submitters: Weibin Zhao Henning Schulzrinne Security Considerations: Same as RFC 2609. Attribute Template Text: ------------------attribute template begins here------------------- # attribute-template-version = 1.0 service-id = string # This attribute uniquely identifies a service instance. It # is persistent. Different services may use different service-id # formats, such as URN or URL. -------------------attribute template ends here-------------------- 3.2. The "service-transport-protocol" Attribute Template Name of submitters: Weibin Zhao Henning Schulzrinne Security Considerations: Same as RFC 2609. Attribute Template Text: ------------------attribute template begins here------------------- # attribute-template-version = 1.0 service-transport-protocol = string M # This attribute describes the transport protocols supported # by a service location. A service location may support multiple # transport protocols. Zhao/Schulzrinne Expires: September 25, 2002 [Page 4] Internet Draft SLP Global Service Attributes March 25, 2002 udp,tcp,sctp -------------------attribute template ends here-------------------- 3.3. The "service-replication-id" Attribute Template Name of submitters: Weibin Zhao Henning Schulzrinne Security Considerations: Same as RFC 2609. Attribute Template Text: ------------------attribute template begins here------------------- # attribute-template-version = 1.0 service-replication-id = string # This attribute uniquely identifies a replicated server group # for a service. All servers having the same # service-replication-id are content-equivalent, i.e., they are # replicated to provide the same content of service. This # attribute is persistent. Different services may use different # service-replication-id formats, such as URN or URL. -------------------attribute template ends here-------------------- 4. Examples of Using Global Service Attributes Erik Guttman's draft on the serviceid: URI scheme [7] describes a proposal for supporting replicated server groups, multiple access protocols, multiple transport protocols, and URL changes. This proposal has two main components: replacing current service URL with a service URI which is a pure identifier, and moving all information including the service URL into the service attribute list. Using this proposal, a service having multiple URLs (indicating multiple locations or multiple interfaces) only needs to send one advertisement. But this proposal significantly complicates the service attribute list when multiple URLs for the same service have different attributes. In the worst case, these URLs may have totally different attributes except they share the same serviceid URI. In this section, we describe how to use the global service attributes defined in section 3 (service-id, service-transport-protocol, and service-replication-id) to support the four goals outlined in [7]. Our approach keeps a good compatibility with current SLP by still using URL to identify a service. Zhao/Schulzrinne Expires: September 25, 2002 [Page 5] Internet Draft SLP Global Service Attributes March 25, 2002 4.1. Identifying a logically single service available at multiple locations A logically single service available at multiple locations (or a replicated server group) advertises each location (URL) separately. Each URL has a separate "service-id" (meaning that each URL is a separate service instance), but all URLs have the same "service- replication-id" (meaning that they provide the same content of service). 4.2. Identifying a single service that is accessible through multiple protocols A single service that is accessible through multiple protocols advertises each access protocol (URL) separately, but all URLs have the same "service-id" (meaning that they represent the same service instance). 4.3. Indicating supported transport protocols A service location (URL) uses the "service-transport-protocol" attribute to indicate its supported transport protocols. 4.4. Discovering the current location of a particular service For a service, its URL(s) may be changed, but its "service-id" and "service-replication-id" are persistent. A UA can discover a service again by using a search filter of "(service-id="")" even if the service's URL has changed. 5. Summary Defining and using global service attributes is a general approach for extending the functionality of SLP. When it needs to support a new common service property or a new service management requirement, it is convenient to define a new global service attribute to serve the purpose. This approach is fully compatible with current SLP. 6. Security Considerations The security considerations for RFC 2609 apply to this document. 7. Acknowledgments Erik Guttman's draft on the serviceid: URI scheme [7] motivated this document directly. Jim Mayer and Mark Bakke gave good suggestions. The authors also benefit from the discussions in the SLP mailing list. Zhao/Schulzrinne Expires: September 25, 2002 [Page 6] Internet Draft SLP Global Service Attributes March 25, 2002 8. References [1] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location protocol, version 2", RFC 2608, June 1999. [2] E. Guttman, "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001. [3] E. Guttman, "Vendor Extensions for Service Location Protocol, Version 2", RFC 3224, January 2002. [4] J. Kempf and J. Goldschmidt, "Notification and Subscription for SLP", RFC 3082, March 2001. [5] W. Zhao, H. Schulzrinne and E. Guttman, "Mesh-enhanced Service Location Protocol", Internet Draft, November 2001. [6] W. Zhao, H. Schulzrinne, C. Bisdikian and W. Jerome, "Selection ans Sort Extension for SLP", Internet Draft, February 2002. [7] E. Guttman, "The serviceid: URI Scheme for Service Location", Internet Draft, January 2002. [8] S. Bradner, "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. [9] E. Guttman, C. Perkins and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June, 1999. [10] D. Crocker and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 9. Authors' Addresses Weibin Zhao Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003 Email: {zwb,hgs}@cs.columbia.edu 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it Zhao/Schulzrinne Expires: September 25, 2002 [Page 7] Internet Draft SLP Global Service Attributes March 25, 2002 or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Zhao/Schulzrinne Expires: September 25, 2002 [Page 8]