Improving SLP Efficiency and Extendability by Using Global Attributes and Preference Filters

1
Improving SLP Efficiency and Extendability by
Using Global Attributes and Preference Filters

• Weibin Zhao
• Henning Schulzrinne
• zwb,hgs_at_cs.columbia.edu
• Department of Computer Science
• Columbia University

2
Outline

• Background
• Service discovery
• Service Location Protocol (SLP)
• Two new mechanisms for SLP
• Global attributes
• Preference filters
• Implementation
• Conclusions

3
Service Discovery

• What is service discovery
• Service description framework
• Services advertise their properties
• Clients specify their queries
• Discovery
• A match of a client query with a service
  advertisement
• Service properties description ? service access
  point (URL)
• Why do we need service discovery
• Zero-configuration, plug and play
• Adapt to changes of service availability

4
Mechanisms and Systems

• Mechanisms
• Directory services
• Multicast
• Existing systems
• Jini Sun (Java)
• UPnP Microsoft (XML)
• SLP IETF (IP)
• Salutation Consortium (network independent)

5
Service Location Protocol (SLP)

• IETF standard for service discovery in IP networks

UA
UA
SA
multicast query
unicast query
unicast registration
SA
SA
DA
UA User Agent SA Service Agent DA
Directory Agent
6
Motivating Example

• Find all services that support SCTP
• SCTP Stream Control Transmission Protocol
• Current SLP needs
• Three steps
• Use a SrvTypeRqst to get a service type list
• Use a SrvRqst to query each service type
• Combine query results together
• N1 queries
• If there are N service types

7
Observation

• Current SLP
• Service type based discovery
• Service type printer
• Service properties color, speed, resolution,
  etc.
• ? Service URL
• New requirement
• Discovery across multiple or all service types

8
Solution Global Attributes

• Template
• Standardize attributes
• Service template for each service type
• Different service types have different attributes
• Local attributes specific to a service type
• printer-resolution
• Attribute template for all services
• Global attributes applicable to all service
  types
• transport-protocol (e.g., TCP, UDP, SCTP)

9
Attribute Namespace

• Why do we need namespace?
• An attribute in current SLP
• Name is unique only within its service type
• Being defined and used along with its service
  type
• When global attributes are used
• Possible name collisions between global and local
  attributes
• How to define namespace?
• Use service type as prefix
• nrsm-capacity, iptel-gw-capacity
• Use service- prefix for global attributes
• service-transport-protocol

10
Definition and Usage

• Definition attribute template
• Each template defines one or more attributes
• Being imported into service templates
• Usage in SrvRqst
• When local attributes are used
• Exact one service type is specified
• When only global attributes are used
• Multiple service types or a service type wildcard
  can be specified

11
Advantages

• Improve SLP efficiency
• Defined once, imported afterwards
• Consistent definition and usage
• Use one query to find services of multiple types
• Extend SLP functionality
• Current SLP
• Standardized service URL, service type, service
  scope
• Other attributes attribute list
• Standardize global attributes
• Service identifier unique persistent, identify
  a service
• Device identifier unique persistent, identify
  a device

12
Advanced Discovery

• Use service identifier to support
• URL changes
• Multi-protocol services
• serviceprinteripp//mpp.example.com
• serviceprinterlpr//mpp.example.com
• Use device identifier to support
• Multi-function device
• A scanning and printing device
• Use both to support
• Replicated service
• Same service identifier, different device
  identifiers

13
Motivating Example

• Find a printer with the minimum queue length
• Current SLP needs
• Find all printers and their queue length
  attribute
• Sort them based on the queue length attribute
• Choose the printer with the minimum queue length

14
Observation

• Current SLP
• Server does not process search results
• Return ALL matched URLs
• No specific order
• Client needs to select one among multiple choices
• New requirement
• Process search results
• Limit the number of results returned
• Sort the results
• Find the best match

15
Solution Preference Filters

• Search filters
• Compared with a specify value
• equal, greater than, less than
• Preference filters
• Compared with each other
• min, max, sort, selection

Search Filter
Preference Filter
Service Database
Matched Service
Preferred Service
16
Advantages

• Reduce the amount of data transferred to the
  client
• Useful for low bandwidth channel
• wireless
• Better support thin clients
• Filter search results at server

17
Design

• Basic preference filters
• Selection filters
• SLP selection extension
• Sort filters
• SLP sort extension
• Generic preference filters
• Compose basic filters
• A sequence of SLP selection and sort extensions

18
Selection Filters

• select(N)
• Assume M search results, if NltM, then return
  first N results, else return all M results
• Server indicates the number (i.e., M) of search
  results in its reply.
• Examples
• select(1)
• select(3)
• select(0)
• Obtain the number of search results without
  retrieving the results themselves

19
Sort Filters

• sort(sort-key-list)
• sort-key key-name type ordering
  ref-value
• type integer (i) or string (s)
• ordering increasing () or decreasing (-)
• reference value optional, for integer only
• sort based on the distance to the reference value
• Examples
• sort(loadi)
• sort(speedi12)
• sort(speedi-,loadi)
• sort (identifiers)

20
Generic Preference Filters

• Best match
• Minimum load
• sort(loadi),select(1)
• Maximum speed
• sort(speedi-),select(1)
• The speed closest to a reference value 12
• sort(speedi12),select(1)
• The minimum load among top three in terms of
  speed
• sort(speedi-),select(3),sort(loadi),select(1)

21
Implementation

• SrvRqst processing
• Global attributes
• Multiple service types or a service type wildcard
• Ignore service type information during the search
• Discard those search results that do not match
  any specified service types
• Preference filters
• Ignore the filter during the search
• Apply the filter to the search results

22
Conclusions

• Simple but useful mechanisms
• Extend SLP attributes from local to global
• Enable generic preference filtering on search
  results
• General applicability
• The rationale behind these mechanisms can be
  applied to other service discovery systems as
  well
• IETF standardization
• The draft on SLP selection and sort extension has
  been approved as an experimental RFC