One document matched: draft-zhao-slp-attr-01.txt

Differences from draft-zhao-slp-attr-00.txt

INTERNET DRAFT                                            Weibin Zhao
draft-zhao-slp-attr-01.txt                        Henning Schulzrinne
June 14, 2002                                     Columbia University
Expires: December 14, 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 how to define and use global service
   attributes in the Service Location Protocol (SLP). A global service
   attribute is service type independent. Its name begins with the
   "service-" prefix. A global service attribute is defined using an
   attribute template, and can be imported into any service template. We
   show how to use global service attributes to query services across
   multiple service types, and to support multi-protocol services,
   multi-function devices, URL changes, and replicated server groups.






Zhao/Schulzrinne            Expires: December 14, 2002          [Page 1]

Internet Draft       SLP Global Service Attributes         June 14, 2002


1. Introduction

   The Service Location Protocol (SLP [1]) provides a flexible framework
   for service discovery in IP networks. Currently, SLP only supports
   local service attributes in that any service attribute is defined and
   used in the context of a particular service type. In contrast, we
   refer to service attributes that are service type independent as
   global service attributes. In this document, we describe how to
   define and use global service attributes in SLP.

   A global service attribute is used for describing a common service
   property across all service types or for a service management
   purpose. In a sense, service URL and service scope list can be viewed
   as global service attributes. Other examples of global service
   attributes include service identifier [2], service transport
   protocol, and service replication name.

   Since a global attribute is defined without any service type context,
   and can be used in a Service Request (SrvRqst) with any service type,
   if it has the same name as a local attribute, then there will be a
   confusion on which is which. Therefore, a separate namespace is
   needed for global service attributes: any global service attribute
   name MUST begin with the "service-" prefix.

   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 [3].

2. The Definition of Global Service Attributes

   A global service attribute is defined using an attribute template.
   Normally each global service attribute is defined using a separate
   attribute template, but if several global service attributes are
   always used together, they MAY be defined in the same attribute
   template. Any service that uses a global service attribute needs to
   import the attribute's definition into its service template (similar
   to C include and Java import mechanism). This way, we can avoid
   defining the same attribute repeatedly in multiple service templates,
   and ensure a consistent definition of the attribute.

2.1. Attribute Template Syntax

   An attribute template is a simplified version of the service type
   template (RFC 2609 [4]). It is defined using the following ABNF [5]:

   attr-template = version attr-defs
   version       = "# attribute-template-version" version-no term
   version-no    = version-no from section 3.1 of RFC 2609



Zhao/Schulzrinne            Expires: December 14, 2002          [Page 2]

Internet Draft       SLP Global Service Attributes         June 14, 2002


   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 [4]) defined using the following ABNF.

   attr-tem-fname = attribute-name "." version-no "." langtag
   attribute-name = id from section 3.1 of RFC 2609
   version-no     = version-no from section 3.1 of RFC 2609
   langtag        = langtag from section 3.1 of RFC 2609

   The file name of an attribute template is derived from the first
   attribute name it defines. For example, if a global service attribute
   "service-attr-x" is the first attribute in an attribute template, the
   version number is 1.0, and the language tag is "en", then the
   attribute template file name is "service-attr-x.1.0.en".

2.3. Importing Global Service Attributes

   In order to support importing global service attributes, the ABNF of
   the service type template defined in RFC 2609 [4] 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

2.4. Examples of Attribute Templates

2.4.1. The "service-identifier" Attribute Template

   ------------------attribute template begins here-------------------

   # attribute-template-version = 1.0

   service-identifier = string
      # It uniquely and persistently identifies a service instance.

   -------------------attribute template ends here--------------------

2.4.2. The "service-transport-protocol" Attribute Template

   ------------------attribute template begins here-------------------

   # attribute-template-version = 1.0



Zhao/Schulzrinne            Expires: December 14, 2002          [Page 3]

Internet Draft       SLP Global Service Attributes         June 14, 2002


   service-transport-protocol = string M
      # It specifies the transport protocols supported by a service
      # location.
   udp,tcp,sctp

   -------------------attribute template ends here--------------------

2.4.3. The "service-replication-name" Attribute Template

   ------------------attribute template begins here-------------------

   # attribute-template-version = 1.0

   service-replication-name = string
      # It uniquely identifies a replicated server group for a service.

   -------------------attribute template ends here--------------------

3. The Use of Global Service Attributes

   A global service attribute can be used in any place where a local
   service attribute is appropriate, such as the attribute predicate in
   a SrvRqst, the attribute list in a Service Registration (SrvReg) or
   Attribute Reply (AttrRply), and the attribute tag in a Service
   Deregistration (SrvDeReg) or Attribute Request (AttrRqst).

3.1. Performing Service Queries across Multiple Service Types

   In a SrvRqst, when both local and global service attributes are used,
   exactly one service type MUST be specified. But when only global
   service attributes are used, multiple service types or a service type
   wildcard can be specified. A service type wildcard is defined as an
   empty service type string; the length of the service type string is
   zero. By using global service attributes, and multiple service types
   or a service type wildcard in a SrvRqst, we can more efficiently
   perform service queries across multiple or all service types.

   For example, to find all services that support the Stream Control
   Transmission Protocol (SCTP [6]), we can use a single SrvRqst that
   has a service type wildcard, and a predicate of "service-transport-
   protocol=sctp". In contrast, current SLP needs three steps to
   accomplish this discovery requirement: (1) use a Service Type Request
   (SrvTypeRqst) to obtain a list of service types, (2) use a separate
   SrvRqst to query services of each service type that support SCTP, and
   (3) combine the query results together.






Zhao/Schulzrinne            Expires: December 14, 2002          [Page 4]

Internet Draft       SLP Global Service Attributes         June 14, 2002


3.2. Supporting Multi-Protocol Services

   A service may support multiple access protocols, having a separate
   URL for each access protocol. For example, a multi-protocol printer
   that supports IPP [7] and LPR access protocols may have two URLs as
   follows: service:printer:ipp://mpp.example.com and
   service:printer:lpr://mpp.example.com. A multi-protocol service
   advertises each of its access protocols separately, but all
   advertisements use the same service identifier to indicate that they
   belong to the same service instance. A UA can discover all
   advertisements of a multi-protocol service by specifying the service
   identifier and the service type (or a service type wildcard) in a
   SrvRqst.

3.3. Supporting Multi-Function Devices

   A device may provide multiple types of services, such as scanning and
   printing services. A multi-function device advertises each service
   type separately, but all advertisements use the same service
   identifier to indicate that they belong to the same service instance.
   A UA can discover all advertisements of a multi-function device by
   specifying the device's service identifier and a service type
   wildcard (or all the service types the device supports) in a SrvRqst.

3.4. Supporting URL Changes

   A service may change its URL. Once this happens, a UA cannot find the
   same service again by using its old URL; but the UA can find the same
   service again by using its service identifier.

3.5. Supporting Replicated Server Groups

   A service may be provisioned by a group of replicated servers; each
   server has a separate URL, and a separate service identifier. A
   replicated server group advertises each server separately, but all
   advertisements use the same service replication name to indicate that
   they belong to the same server group. A UA can discover all
   advertisements of a replicated server group by specifying the service
   replication name and the service type (or a service type wildcard) in
   a SrvRqst.

4. Security Considerations

   The security considerations for RFC 2609 apply to this document.

5. Acknowledgments

   Erik Guttman's draft on the serviceid: URI scheme [2] motivated this



Zhao/Schulzrinne            Expires: December 14, 2002          [Page 5]

Internet Draft       SLP Global Service Attributes         June 14, 2002


   document directly. Jim Mayer, Mark Bakke and Ira McDonald gave good
   suggestions. The authors also benefit from the discussions in the SLP
   mailing list.

6. References

   [1] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location
       protocol, version 2", RFC 2608, June 1999.

   [2] E. Guttman, "The serviceid: URI Scheme for Service Location",
       Internet Draft, January 2002.

   [3] S. Bradner, "Key words for use in RFCs to indicate requirement
       levels", BCP 14, RFC 2119, March 1997.

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

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

   [6] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
       T. Taylor, I. Rytina, M. Kalla, L. Zhang and V. Paxson,
       "Stream Control Transmission Protocol", RFC 2960, October 2000.

   [7] R. Herriot, S. Butler, P. Moore, R. Turner and J. Wenn,
       "Internet Printing Protocol/1.1: Encoding and Transport",
       RFC 2910, September 2000.

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

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



Zhao/Schulzrinne            Expires: December 14, 2002          [Page 6]

Internet Draft       SLP Global Service Attributes         June 14, 2002


   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: December 14, 2002          [Page 7]