Response to VESA Home Network RFI: Network Protocol, Network Management,
and Device Directory services, Version 1.0, dated February 18, 1997
June 19, 1997
Prepaired by: Robert A. Pasoce
801-763-8216
10702 North 5250 Weat
Highland, UT 84003
The Salutation Consortium is pleased to respond to the VESA Home Network RFI.
BACKGROUND
The Salutation Consortium (www.salutation.org) is a non-profit corporation with member
organizations in the United States, Europe, and Japan. Member companies include APTi, Axis
Communications, Brother, Canon, Casio, Cisco, Eastman Kodak, Fuji Xerox, Fujitsu, Hewlett
Packard, Hitachi, Integrated Systems, IBM, Iwatsu, Justsystem, Kobe Steel, Konica, Lexmark,
Matsushita, Microware Systems, Minolta, Mita, Mitsubishi, Murata (Muratec), Novell, Oki Data,
Ricoh, Rios Systems, Sanyo, Seiko Epson, Sharp, Sun Microsystems, Toshiba, and Xerox. The
Salutation Consortium has published an open specification that enables an application to
locate a particular resource on a network through a broadcast query. The specification is
independent of network transport, hardware platform, and operating system software and
supports standard Internet and other message formats.
Canon, Fuji Xerox, IBM Japan, Mita, Muratec, and Ricoh exhibited Salutation-enabled products at the Consortium booth at Business Show '97, May 13-16 at the Tokyo Big Sight convention center. These new products support the Salutation vision of a company intranet that automatically detects new peripherals as they get attached, either directly or through remote ports, and makes their functional capabilities available for use. The new products include both hardware models and software applications. Many of them integrate closely with Lotus Notes in a corporate intranet environment.
NATURE OF THIS RESPONSE
The Salutation Architecture was created to solve the problems of service discovery and utilization among a broad set of appliances and equipment and in an environment of widespread connectivity and mobility.
The architecture provides a standard method for applications, services and devices to
describe their capabilities, to advertise their capabilities to other applications, services and
devices, to find out the capabilities of other applications, services and devices, to search
applications, services or devices for a particular capability, and to request and establish
interoperable sessions with other applications, services or devices to utilize their
capabilities.
Given the diverse nature of target appliances and equipment in an environment of
widespread connectivity, the architecture is processor, operating system, and
communication protocol independent, and allows for scaleable implementations, even in
very low-price devices.
As such, the Salutation Architecture is not applicable to the Network Protocol component
described in the VESA Home Network RFI. The Architecture does address Network
Management issues and Device Directory Service requirements. This response will focus on the
latter two components.
It should be noted that the Salutation Architecture's network, operating system, directory, and
processor independence is key to the target market of the VESA Home Network RFI.
Firstly, this independence provides manufactures of consumer electronics equipment and home
controllers the ability to select components for their devices via normal business process rather
than through the dictates of an architecture or standard. The dictates of Microsoft's AtWork was
one of the major causes of its lack of acceptance.
Secondarily, this independence allows the Salutation Architecture to play a significant role both
in home networks and in upstream content provider networks that will be vying for market share
in this domain. For example, several in-home transport mechanisms and communication
protocols may co-exist in the enironment, with Salutation able to bridge to all. And in the
business climate where the large corporate content providers -- the telephone, media, software
and hardware companies -- view this domain as a place predominantly for their products,
services, and protocols, an architecture capable of determining the characteristics of the products
and services within these often closed environments is key.
Finally, Salutation does not require a central directory structure, yet it can be used as a compliment to a directory centric environment. This again provides manufactures with cost/performance trade-off that are lessened with a dictated directory approach.
SALUTATION ARCHITECTURE OVERVIEW
A brief overview of the Salutation Architecture is given. Full details of the architecture are provided on the Salutation Consortium's Web Site (http://www.salutation.org/ordrspec.htm) and are available to anyone, royalty free.
The Salutation Architecture defines an entity called the Salutation Manager (SLM) that functions as a service broker for applications, services and applications called Network Entity. The SLM allows Network Entities to discover and utilize the capabilities of other Network Entities.
A Network Entity may be a service provider which is called a Server. The Server registers its capability with an SLM. A Network Entity may be a service user which is called a Client. The Client discovers Servers and requests to use them through an SLM. A Network Entity may serve as both a Client and a Server.
The SLM communicates with other SLMs to perform its role as a service broker. The SLM-to-SLM communications protocol is defined by the architecture and called the Salutation Manager Protocol.
The Salutation Manager Protocol uses Sun Microsystems' Open Networking Computing Remote Procedure Call version 2 protocol, referred to as RPC hereafter.
The Salutation Manager Protocol requires that the underlying transport protocol support multiple reliable bi-directional communications.
Each SLM has a universally unique identifier, SLM-ID. SLM-ID is a 16-octet-long opaque OCTET STRING used by Clients, Servers, and SLMs to uniquely identify a particular SLM in a transport independent way.
The SLM provides a transport-independent interface, called the SLM Transport Interface (SLM-TI), to transport-dependent entities, called Transport Managers (TM). The Transport Manager is introduced to make the SLM transport-independent. The SLM and TM(s) together perform the service broker role. The SLM-TI will be defined in a future release of this architecture.
An SLM works with one or more TMs. Each TM discovers other remote SLMs connected to the transport it supports. For each discovered remote SLM, the TM finds the SLM-ID of the remote SLM, registers the SLM-ID with the local SLM, and maintains the association between the transport address and the SLM-ID of the remote SLM.
The TM discovers other remote SLMs in a number of ways such as the following:
TM has a static table of the transport address of remote SLMs. The format and structure of the table is outside the scope of this architecture.
TM broadcasts a query to find other remote SLMs over the transport using the protocol defined by this architecture. (This method is possible only if the transport supports a broadcast mechanism.)
If there is a central server containing the directory of Salutation equipment, TM may inquire the transport address of other SLMs there. The protocol between the TM and such directory is outside this architecture's scope.
The application specifies the type of transport and the transport address of a remote SLM through the SLM-API.
Each piece of Equipment has, at most, one SLM. When there is no local SLM, Clients/Servers may use a remote SLM, an SLM in another piece of Equipment, through RPC. It is up to the implementation of each SLM whether or not it provides the RPC interface to remote applications.
Network Entities may be subdivided by meaningful functionality called Functional Units. In
principle, the architecture defines one meaningful function (from the Client's viewpoint) as one
Functional Unit (FU). For example, a function that rasterizes document data to image data may
be defined as [Rasterize] FU, while a function that prints document data is defined as [Print} FU
which includes both the rasterizing function and the image printing function.
The architecture provides abstract definitions of Functional Units. Abstraction of Functional
Units are used for Server functions, as well as certain Client functions. A set of Attributes is
defined for each abstraction of a Functional Unit. Each Attribute describes an aspect of the
capability of the Functional Unit. For example, the [Print] Functional Unit has attributes such as
whether double-sided print or various paper sizes are supported, the number of sorters, and so on.
In this architecture names of Functional Units are customarily enclosed in square brackets [ ].
Some examples of Functional Units are:
[Print]
[Fax Data]
[Address Book]
The architecture defines a syntax and semantics for describing the attributes of each Functional Unit abstraction.
Personality Protocol
Commands and responses are exchanged between a Client and a Functional Unit when the Client actually uses services provided by the Functional Unit. Such commands and responses are called Messages.
Messages have a defined format and are exchanged under a defined protocol. Such definition of message exchange format and protocol is called the Personality Protocol.
A Functional Unit may support more than one Personality Protocol. There are three kinds of Personality Protocols.
Salutation Personality Protocol
The Salutation Architecture defines a Personality Protocol called the Salutation Personality Protocol for selected Functional Units. Message format and exchange protocol are defined by the Salutation Architecture. Some Salutation Personality Protocol commands, parameters, and protocols are common across Functional Unit types under a common framework. All Messages under the Salutation Personality Protocol are carried by the Salutation Manager Protocol.
If a Personality Protocol defined outside of the Salutation Architecture is used, but within the Salutation Manager Protocol framework, the Personality Protocol is called an Emulated Personality Protocol. All Messages under an Emulated Personality Protocol are still carried by the Salutation Manager Protocol.
If a Personality Protocol defined outside of the Salutation Architecture is used natively (not within the Salutation Manager Protocol framework), the Personality Protocol is called a Native Personality Protocol. Messages are exchanged between client and server applications directly, without the involvement of the SLM. Messages are NOT carried by the Salutation Manager Protocol under a Native Personality Protocol.
Note: Although the Salutation Manager Protocol is not used with the Native Personality Protocol, the Salutation Manager Protocol may be used by the client to find or query the service prior to requesting the service. However, it is subject to the type of underlying transport and the native protocol as to whether the exchange of messages under a Native Personality Protocol and the use of Salutation Manager Protocol may actually coexist.
Under the Salutation or Emulated Personality Protocol, application Messages go through SLMs, however the SLM never inspects the contents or semantics of Messages.
When a Client wants to use a service provided by a Functional Unit under a Salutation or an Emulated Personality Protocol, it requests an SLM to establish a Service Session between the Client and the Functional Unit. The Client specifies a Personality Protocol to be used in the Service Session in the request. Depending whether or not the target Functional Unit is associated with the same SLM as the Client, the Service Session is established either within the SLM or across two SLMs.
A Service Session may also be established between two Functional Units.
There may be zero or more Clients and zero or more Functional Units associated with an SLM.
Some of the Clients and Functional Units are in the same equipment as the SLM, while others are
not. Also, Client or Functional Units may have more than one concurrent independent Service
Session.
RESPONSE TO SPECIFIC QUESTIONS IN THE VESA HOME NETWORK RFI
Section 4.1 Network Protocol
The Salutation Architecture is designed to be independent of underlying network protocols. It is
applicable to any single or multiple protocols that may exist within a given environment. It is
adaptable to spanning bridges or gateways that may be encountered. For example, if the home
access provider's network is different form the in-home protocol, Salutation protocols are easily
gated, one to the other. Or if two separate protocol exist with in the home, Salutation provides a
single API to application, service, network management and directory components for discovery
and service requests. Salutation's Transport Management provides bridging to the specific
networks.
Section 4.2 Network Management
Although Salutation Architecture is not a complete Network Manager, it provides important
mechanisms to drive such a process. For example, the architecture defines:
Mechanism for defining objects (Functional Unit definition)
Mechanisms for finding instances of objects (Search Capability)
Mechanism for determining object location (SLM-ID Exchange)
Mechanism for determining the detailed characteristics of an object (Query Capability)
Mechanism for determining object availability (Availability Check)
Mechanism for object fault detection (Client Functionsl Unit)
Mechanism for object utilization (Service Request)
Regarding the specific questions of Section 4.2:
What is the taxonomy of a candidate network management system?
The basic object definition in the Salutation Architecture is called a Functional Unit (FU) each
functional unit is described in abstraction as a set of attributes associated with the FU. For
example, a Print FU has attributes of print density, source drawers, staple, collate, rotate, color,
supported print data streams, etc.
A device may contain multiple FU's. For example, a fax machine may contain a Print, Document
Store and Fax Data Send FU.
In principal, the architecture abstracts on meaningful service as on FU. An example for the Home
Network environment is an Audio FU. The FU might be defined with attributes of mono/stereo,
volume, midi capable, analog/digital capable, and acceptable data formats. The Audio FU may be
combined with a Video FU to define a TV, with a keyboard FU to define a phone, or with a
Tuner FU to define a radio receiver.
How are resources partitioned on the network?
Each networked attached entity contains a Salutation Manager (SLM). The devices FU's are
registered with the local SLM. Each SLM manages the resources register there in.
Who are shared resources partitioned?
Shared resources are managed through local registration and un-registration with the local
Salutation manager and through the Architecture's Availability Check.
How is a device represented in an existing device directory?
The SLM contains its own directory of registry of the local FU's. It is conceivable that a Central
SLM can be assigned the task of querying all SLMs and locally registering the found devices and
their FU's.
Can device identification be easily mapped to new directory services?
Yes. As an example, bridging between SLM and Novell's NDS has been demonstrated.
What is the resource modeling mechanism?
The Functional Unit abstraction provide the resource model. A single resource may be
represented by multiple FU's.
How are resources defined?
Through defining the attributes of contained FU's and assembling these descriptions into a
Service Description Record. I.E., a Fax Machine is represented by the combination of Print,
Document Store and Fax Dada Send FUs.
Who are resources instantiated?
Resources are instantiated through the local SLM.
Who does the instantiation of the resource relate to the taxonomy of the network?
As the base unit for the taxonomy and resource instantiation is the FU, the relationship is
identical.
How are default values of configurable resources determined?
There is a scheme for defining a unique SLM-ID for each instance of an SLM in the network.
There are also default attribute values defined for each FU.
How are values of configurable resources set?
Each entity registers the current FU attribute values with the local SLM. If a re-configuration
occurs, the FU is re-registered specifying the new attribute values.
How are values of configurable resources retrieved?
Using the Architecture's Capabilities Exchange.
Network performance monitoring questions.
Salutation does not provide network performance monitoring.
Fault detection and isolation questions.
Salutation does not provide network fault detection and isolation. However, Salutation can be
used for fault detection of networked entities and isolate the fault down to the FU.
How are values of resources protected from being set or retrieved from unauthorized
sources?
The Architecture defines Credential (identifies a particular user) , and Verifier (authenticates the
credential parameter) parameters to address the user identification and authentication
requirements.
User interface questions.
Salutation Architecture does not specify a user interface. Our members feel that UI
characteristics are market differentiators for their products and resist standardization in this area.
Section 4.2 Device and Application Directory
The Salutation Architecture dose not provide a global directory, However, the notion of using
Salutation in a global service location strategy has been discussed. Two alternatives are
presented here.
Define a Central SLM. The function of the Central SLM is to extract FU definitions from all
other SLMs in the network and register the findings with the Central SLM directory. All
directory queries would be made to the Central SLM.
Build a SLM to Brand 'x' Directory bridge. The bridge code would use the local SLM to
extract FU definition form all other SLMs in the network and register the findings with the Brand
'x' Directory. All director queries would be made to the Brand 'x' Directory.
There is value in supporting the SLM level of directory. It allows vendors of home automation
equipment to bring unique solutions to market. Some may wish to rely on the SLM capabilities
exchange to provide directory functionality; others may bridge SLM to a Brand 'x' Directory
solution housed in a home controller, home PC, or gateway. Tying all solutions to a single
directory definition/implementation will limit the functionality and performance characteristics
of vendor implementations.
The Salutation Architecture is independent of the underlying protocol so it may be used across
the various networks found in a home. For legacy product, a port-of-entry, containing an SLM
and mechanism for registering legacy equipment is visualized.
Regarding the specific questions of Section 4.2:
Note that each instance of the SLM contains a Functional Unit registry, -- a directory -- which
maintains information about the registered FU's. The following questions are answered relative
to this SLM Directory.
Is the structure of the directory hierarchical of flat?
Flat
Is the directory centralized or distributed?
Distributed. Each SLM contains a directory for the locally defined and registered FU's.
Are names of objects in the directory variable of fixed-length?
Entries in the SLM directory are defined by the Saltuaiton Archtiecture for each FU type. Hoever,
the architecture is extensable, allowing manufactures to 'add' attribute values defining product
specific functionality.
How is information about legacy devices represented in the directory?
A product called a Port-of-Entry is envisioned. This product would use legacy environment
functionality to determining the characteristics and capabilities of legacy product and then
register that information as FU's in the SLM directory. A Port-of-Entry is as automated as the
legacy equipment allows. It may be necessary to manually input the capabilities of the legacy
equipment.
What devices are named?
All devices may be named. The Salutation Consortium's Technical Committee has a process for
FU definition.
What is the cost of accessing the directory? Does it support lightweight query and update
mechanisms?
SLM Capability queries consist of a single API call. There are 16 APIs in total.
slmRegisterCapability()
slmUnregisterCapability()
slmSearchCapability()
slmQueryCapability()
slmOpenService()
fnOpenService()
slmTransferData()
fnReceiveData()
slmCloseService()
fnCloseService()
slmStartAvailabilityCheck()
fnNotifyFUUnavailability()
slmCancelAvailabilityCheck()
slmGetVersion()
slmGetLocalSLMID()
slmGetSLMIDbyAddr()
What query mechanisms are available for efficiently searching the directory for relevant
information?
The Salutation Capability query provides four different techniques:
Retrieve information about all FU's registered at a given SLM
Retrieve information about a specific type of FU registered at a given SLM
Retrieve information about an FU type matching specific FU attributes registered at a given
SLM
Find all FU's within a domain which match specific FU attributes.
Is the directory access mechanism independent of how and where the directory is stored?
Yes, the Capability Exchange techniques may be responded to locally or remotely.
What objects are represented in the directory?
Functional Units.
What information about these objects is stored in the directory?
Functional Unit attributes.
Is the directory schema independent of directory access mechanism used?
No. The SLM directory represents local FU's and their attributes.
How do home devices and application directories export information to access networks or
incorporate information available in external directories?
Bridges would be established which access SLM directories through SLM APIs and populate the
'other' directory through its scheme.