OPC Unified Architecture Services/OPC U… · Web viewDraft Specification. Discovery. Version 1.00. November 8, 2007 Specification Type Industry Standard Specification Comments:

OPC Unified Architecture

Draft Specification

Discovery

Version 1.00

November 8, 2007

OPC Unified Architecture i Draft 1.00

Specification Type

Industry Standard Specification

Comments:

Title: OPC Unified ArchitectureDiscovery

Date: November 8, 2007

Version: Draft 1.00 Software MS-WordSource: document.doc

Author: OPC Foundation Status: Draft

OPC Unified Architecture ii Draft 1.00

CONTENTSPage

1 Scope......................................................................................................................................... 1

2 Reference Documents.............................................................................................................1

3 Terms, definitions, and conventions......................................................................................1

3.1 OPC UA Part 1 terms....................................................................................................13.2 OPC UA Part 2 terms....................................................................................................13.3 OPC UA Part 4 terms....................................................................................................23.4 OPC UA Discovery terms..............................................................................................2

3.4.1 DirectoryService................................................................................................23.4.2 DiscoveryServer................................................................................................23.4.3 LocalDiscoveryServer (LDS)...........................................................................23.4.4 WellKnownUrl....................................................................................................2

3.5 Abbreviations and symbols...........................................................................................24 The Discovery Process............................................................................................................2

4.1 Overview......................................................................................................................... 24.2 Simple Discovery...........................................................................................................34.3 Normal Discovery...........................................................................................................44.4 Hierarchical Discovery...................................................................................................44.5 Directory Service Discovery..........................................................................................5

5 Deployment and Configuration...............................................................................................6

5.1 Firewalls and Discovery................................................................................................65.2 Resolving References to Remote Servers..................................................................85.3 Security........................................................................................................................... 9

6 Local DiscoveryServer.............................................................................................................9

6.1 Overview......................................................................................................................... 96.2 Registration.................................................................................................................. 106.3 Discovery...................................................................................................................... 106.4 Dedicated Machines....................................................................................................106.5 Auditing......................................................................................................................... 11

7 DirectoryServices................................................................................................................... 11

7.1 UDDI.............................................................................................................................. 117.2 LDAP............................................................................................................................. 12

OPC Unified Architecture iii Draft 1.00

FIGURESFigure 1 – The Simple Discovery Process...................................................................................3

Figure 2 – The Normal Discovery Process...................................................................................4

Figure 4 – The Hierarchical Discovery Process..........................................................................5

Figure 5 – The UDDI or LDAP Discovery Process......................................................................5

Figure 6 – Discovering Servers Outside a Firewall.....................................................................6

Figure 7 – Discovering Servers Behind a Firewall......................................................................7

Figure 3 – Using a Discovery Server with a Firewall..................................................................8

Figure 8 – Following References to Remote Servers.................................................................9

Figure 9 – UDDI Registry Structure............................................................................................11

Figure 10 – Sample LDAP Hierarchy..........................................................................................12

OPC Unified Architecture iv Draft 1.00

TABLESTable 1 – WellKnownUrls for the Local DiscoveryServer.........................................................10

Table 2 – UDDI tModels...............................................................................................................11

Table 3 – LDAP Object Class Schema.......................................................................................12

OPC Unified Architecture 1 Draft 1.00

1 Scope

This document specifies describes how UA Clients and Servers interact with DiscoveryServer DiscoveryServer s when used in operate in different scenarios and describes how UA Clients and Servers should interact with them . It specifies the requirements for the LocalDiscoveryServer and It also defines how UA related information should be stored to discover UA applications when using in common Directory Service DirectoryService s.

2 Reference Documents

[UA Part 1] OPC UA Specification: Part 1 – Concepts

http://www.opcfoundation.org/UA/Part1/

[UA Part 2] OPC UA Specification: Part 2 – Security Model


[UA Part 3] OPC UA Specification: Part 3 – Address Space Model


[UA Part 4] OPC UA Specification: Part 4 – Services


[UA Part 5] OPC UA Specification: Part 5 – Information Model


[UA Part 6] OPC UA Specification: Part 6 – Mappings


[UA Part 7] OPC UA Specification: Part 7 – Profiles


3 Terms, definitions, and conventions

3.1 OPC UA Part 1 terms

The following terms defined in [UA Part 1] apply.

1) Certificate

2) Client

3) Communication Stack

4) Message

5) Profile

6) Server

7) Service

8) Service Set

9) Session



1) SecureChannel

2) PrivateKey









3) PublicKey

4) X.509 Certificate



1) ApplicationDescription

2) Endpoint Endpoint

3) EndpointDescription

4) HostName

5) ServerUri

6) FindServers

7) GetEndpoints

8) RegisterServer

9) ApplicationUri

10) ApplicationDescription

11) EndpointDescription

3.4 OPC UA Discovery terms

3.4.1 Directory Service

A DirectoryService is a software application — or a set of applications — that stores and organizes information about network resources. Applications on the network can discover resources by using APIs defined by the DirectoryService.

3.4.2 Discovery Server

A DiscoveryServer is a server that maintains a list of other Servers that are available on the network. A DiscoveryServer provides one discovery Endpoint discovery Endpoint for each transport Profile that it supports.

3.4.3 Local Discovery Server (LDS)

The LocalDiscoveryServer is a DiscoveryServer that maintains a list of all Servers available on the node machine that it runs on. A LocalDiscoveryServer has one discovery Endpoint discovery Endpoint for each transport Profile that it supports. Every node machine with a Server installed should have a LocalDiscoveryServer running.

3.4.4 Well Known URL Url

A WellKnownUrl is a predefined URL that can be used to find the LocalDiscoveryServer on a machine. A WellKnownUrl is an URL with a predefined address syntax. Clients may use WellKnownUrls to connect to Endpoints on a node without prior knowledge of the URL for the Endpoint .


3.5 Abbreviations and symbolsAPI Application Programming InterfaceUA Unified ArchitectureLDS Local Discovery Server Discovery ServerTLS Transport Layer SecurityDNS Distributed Name ServerUDDI Universal Description, Discovery and IntegrationLDAP Lightweight Directory Access Protocol

4 The Discovery Process

4.1 Overview

The discovery process allows the Clients to first find Servers on the network and then discover how to connect to them. Once a Client has this information it can save it and use it to connect directly to the Server again without going through the discovery process. If the Client finds that it cannot connect then that could mean the Server configuration has changed and the Client needs to go through the discovery process again.

Servers should must allow themselves to be discovered by Clients by implementing a discovery Endpoint discovery Endpoint and registering themselves with the LocalDiscoveryServer running on the same node machine .

The URL for a DiscoveryEndpoint discovery Endpoint must provide all of the information that the Client needs to connect to the Endpoint Endpoint . This implies that no security can be applied to the message service call itself , however, some implementations may use transport layer security where the secure protocol is identified in the URL (e.g. HTTPS).

A discovery Endpoint must provide the FindServers and GetEndpoints services defined in [UA Part 4] .

Clients use the FindServers service defined in [UA Part 4] to request a list of known Servers from the DiscoveryEndpoin t discovery Endpoin t of a DiscoveryServer. Clients the use the GetEndpoints service defined in [UA Part 4] to request a lists of supporte d th e metadata for th e Endpoin tsEndpoin ts from t hesupported by a Server from t he DiscoveryEndpoi nt discover y Endpoi nt belongin g o f t oa th e Server.

Servers use the RegisterServer service defined in [UA Part 4] to tell the LocalDiscoveryServer that they are available. Servers may call this service when they are installed, however, they must call this service when they start and continue to call it periodically as long as they are running and accepting client connections. Administrators must be able to disable Server registration because they may not want some Servers to be discoverable. By default, all Servers must be configured to call RegisterServer .

If a server Server goes offline and can no longer be accessed it then it must call RegisterServer service and tell the LocalDiscoveryServer that it is no longer available.

The are a number of common discovery scenarios which are described in the clauses below.

4.2 Simple Discovery

Clients do not need to use a Di di scoveryServer service if they have the URL for a discovery Endpoint discovery Endpoint provided by a Server. In this situation the Client connects directly to the Server and requests the EndpointDescriptions using the GetEndpoints service. The Client can then choose one of the endpoints Endpoints returned and use the information to call the OpenSecureChannel service and establish a secure communication channel. Once a secure communication channel exists the client Client calls CreateSession and may then access all other UA services.


The discovery process for this scenario is illustrated in Figure 1.

Figure 1 – The Simple Discovery Process

4.3 Normal Discovery

In many cases the Clients will not know what Servers exist but they do know what nodes machines might have UA Servers on them. In this situation the client will look for the LocalDiscoveryServer on the node machine using the WellKnownUrls for the LocalDiscoveryServer that it is configured to use.

If the Client finds a LocalDiscoveryServer it calls the FindServers service and optionally passes in list of ServerUris that it is interested in finding. The LocalDiscoveryServer will return a list of ApplicationDescriptions which contain the DiscoveryEndpoint discovery s Endpoints for each Server.

The Client would then call the GetEndpoints service for one of the Servers returned and request the EndpointDescriptions for that Server. The client Client will then be able to use that information to create secure communication channel with the Server.


Figure 2 – The Normal Discovery Process


Dedicated systems with exactly one server Server installed do not need to have a separate LocalDiscoveryServer application running. In this case, the Server could use the well known URLs for its own DiscoveryEndpoint discovery Endpoint s . This configuration would not change anything of the interactions from the perspective of the C c lient.

4.4 Gateway Discovery

Sometimes a Client will need to access Servers that are behind a firewall and the administrator of the Servers does not want anonymous Clients outside the firewall accessing the DiscoveryEndpoints directly. In this situation the server administrator would deploy a DiscoveryServer that would be configured with knowledge of the Servers that external Clients are allowed to access.

External Clients would be configured with the URL for the DiscoveryEndpoint of the gateway DiscoveryServer . C lients would then start the discovery process by calling the FindServers service and requesting the ApplicationDescriptions for all Servers known to the gateway . The gateway would substitute its own Endpoint for the DiscoveryUrls in all ApplicationDescriptions that it returns. As a result, the Client will be calling the gateway when it calls the GetEndpoints service instead of the underlying Server . The gateway acts as a proxy and fetches the EndpointDescriptions from the underlying Servers whenever a Client asks for them.

From the Client’s perspective there is no difference between its interactions with the gateway server and the interactions it would have with a LocalDiscoveryServer when it is allowed to connect directly to the servers.

The discovery process for this scenario is illustrated in Figure 3 .

Figure 3 – The Gateway Discovery Process

It is up to the implementer of the gateway DiscoveryServer to decide how it is configured with knowledge of the Servers that are available to external Clients .

4.5 Hierarchical Discovery

Sometimes a Client will have access to all of the servers Servers on a network but will not have any way to know what nodes machines are on a network. In this situation DiscoveryServers can be organized into hierarchies that allow Clients to discover the nodes machines on a network by using a DiscoveryServer that it knows about other DiscoveryServers on the network.


Each ApplicationDescription record returned by the FindServers service indicates whether the server application is a regular Server or a DiscoveryServer. If the server is a DiscoveryServer then the C c lient must call the FindServers service again to discover any Servers known by lower level DiscoveryServer.


Figure 4 – The Hierarchical Discovery Process

It is up to the implementer of the higher level DiscoveryServer to decide how it is configured with knowledge of the other DiscoveryServers on the network.

4.6 Directory Service Directory Service Discovery

Many organizations will deploy directory service DirectoryService s such as LDAP or UDDI to manage resources available on their network. A Client can use these services as a way to find Servers by using APIs specific to directory service DirectoryService to query for UA Servers or UA DiscoveryServers available on the network. The Client would then use the URLs for DiscoveryEndpoint discovery s Endpoints stored in the directory service DirectoryService to request the EndpointDescriptions necessary to connect to an individual servers.


The discovery process for this scenario is illustrated in Figure 5 .

Figure 5 – The UDDI or LDAP Discovery Process

5 Deployment and Configuration

5.1 Firewalls and Discovery

Many systems will have multiple networks that are isolated by firewalls. These firewalls will frequently hide the network addresses of the hosts behind them and unless the Administrator has specifically configured the firewall to allow external access. In some networks the Administrator will place machines with externally available Servers outside the firewall as shown in Figure 6.

Figure 6 – Discovering Servers Outside a Firewall


In this configuration Servers running on the publicly visible network will have the same network address from the perspective of all Clients which means the URLs returned by Discovery Server DiscoveryServer s are not affected by the location of the Client.

In other networks the Administrator will configure the firewall to allow access to selected Servers as shown in Figure 7.

Figure 7 – Discovering Servers Behind a Firewall

In this configuration the address of the Server that the Internet Client sees will be different from the address that the internal Client sees. This means the Server’s Discovery Endpoint discovery Endpoint would return incorrect URLs to the Internet Client (assuming it was configured to provide the internal URLs).

Administrators can correct this problem by configuring the Server to use multiple HostNames. A Server that has multiple HostNames must look at the EndpointUrl passed to the FindServers GetEndpoints or CreateSession services and return EndpointDescriptions with URLs that use the same H h ost n N ame. A Server with multiple HostNames must also return an ApplicationInstanceCertificate that specifies the HostName used in the URL it returns. An Administrator could may create a single Certificate with multiple HostNames or assign different Certificates for each HostName that the Server supports.

Administrators may also wish to set up a gateway Discovery Server DiscoveryServer that is configured with the Application Descriptions for Servers that are accessible to external Clients . This DiscoveryServer would have to substitute its own Endpoint for the DiscoveryUrls in all ApplicationDescriptions that it returns when a Client calls FindServers . This would tell the Client to call the DiscoveryServer back when it wishes to connect to the Server . The DiscoveryServer would then request the EndpointDescriptions from the actual Server as shown in as described in Clause 4.4 or a Directory Service as described in Clause 4.6 . Figure 3 . At this point the Client would have all the information it needs to establish a secure channel with the Server behind the firewall .


Figure 8 – Using a Discovery Server with a Firewall

In this example, t he DiscoveryServer outside of the firewall allows the Administrator to close off the Server’s discovery Endpoints to every Client other than the DiscoveryServer . The Administrator could eliminate that hole as well if it stored the EndpointDescriptions on the DiscoveryServer .

The DiscoveryServer could also be replaced with a DirectoryService that stores the ApplicationDescriptions and/or the EndpointDescription s for the Servers behind the f irewalls .

5.2 Resolving References to Remote Servers

5.2.1 Overview

The UA Address Space address space supports references between Nodes that exist in different Server address spaces. These references are specified with a NodeId that includes the URI of the Server which owns the Node. A Client that wishes to follow a reference to an external Node must map the ServerUri ApplicationUri onto an EndpointUrl that it can use. A Client can do this by using a DiscoveryServer that knows about the Server . The process of connecting to a Server containing a remote Node is illustrated in Figure 9


Figure 9 – Following References to Remote Servers

The Client can only find a remote Server if it has been configured with the locations of DiscoveryServer s on the network.

When configuring a Client to use a DiscoveryServer an Administrator may specify a set of ServerUris that are handled by that DiscoveryServer . If the DiscoveryServer does not specify any ServerUri s then the Client should treat it as a default DiscoveryServer that may know about all Server s .

The DiscoveryServer s know to the Client could be replaced by a DirectoryService or a reference to the discovery Endpoint of the remote Server . The latter example might be used in small networks with a few well known Servers .

5.3 Security

Clients must beware of rogue DiscoveryServers that might direct them to rogue Servers . Clients can use the SSL/TLS server certificate to verify that the DiscoveryServer is a server that they trust.

In any case, Clients must always verify that it trusts the Server Certificate and that the EndpointUrl matches the HostNames specified in the Certificate before it creates a Session with a Server . After it creates a Session it must look at the EndpointDescriptions returned by the Server and verify that it used the best security possible and that the Server’s Certificate matches the one that the Client used to connect.

. There are a number of mechanisms that will allow a Client to do this mapping. Well Known Servers

In some smaller systems the Client may already be aware of what Servers exist and where to find them. This means the Client can do the mapping.


5.3.1 Central Directory Service .

5.3.2 Some systems will have a central Directory Service which the Client is aware of. The Client would use the ServerUri in the Node to look up the location of the Server in the Directory Service .

[5.3.3] Server Provided Mapping

Large heterogeneous systems may not have a common Directory Service and cannot expect Clients to know of all of the Server . This means the Server should provide a mapping between a ServerUri and a Discovery Server that knows about the Server . This Discovery Server may be the Server itself or Directory Service .

The Server provides this mapping via the ServerLocationsArray its address space. This is a Variable which contains an array of ApplicationDescription structures (see [UA Part 4] ). Each element in the array corresponds to a element in the ServerArray Variable described in [UA Part 5] . If the Server does not know the mapping for a particular Server it sets the corresponding entry in the ServerLocationsArray to null.

6 Local Discovery Server DiscoveryServer

6.1 Overview

Each node machine with UA Servers installed should have a LocalDiscoveryServer installed. This is a DiscoveryServer that exposes one or more Endpoints Endpoints which support the FindServers and GetEndpoints services defined in [UA Part 4]. In addition, the LocalDiscoveryServer must provide at least one Endpoin tEndpoin t which implements the RegisterServer service.

The Endpoints Endpoints for the LocalDiscoveryServer use WellKnownUrls which a Client or Server can construct from the H h ostN n ame. These WellKnownUrls could change from system to system which means Client and Server applications . . For this reason, it is recommended that UA applications maintain a list of WellKnownUrls that they try in sequence much like the way Distributed Name Servers (DNS) are used today.

The WellKnownUrls are specified for each transport Profile defined in Table 1.

Table 1 – WellKnownUrls for the Local DiscoveryServer Well Known URLs

Profile URL NotesXML Web Services http://hostname/UADiscovery/ Must support UA Binary and UA XML Encodings.Native Binary opc.ua://hostname:4840 Does not support SSL/TLSXML Web Services http://hostname:52601/UADiscovery/ Must support UA Binary and UA XML Encodings.

Alternate if port 80 is not available for use by a UA application.

The Endpoints Endpoints for the LocalDiscoveryServer may require SSL/TLS. If this is the case the Client or Server must use its application instance certificate as the SSL/TLS client certificate.

6.2 Registration

The Endpoints Endpoints that implement the RegisterServer service must only be accessible to reject attempts to register Servers running on a different the same node machine . This ensures that invalid registrations cannot be created by unauthorized applications connecting via the network.

The Server must provide a ServerUri ApplicationUri when it registers. The LocalDiscoveryServer must replace any existing record associated with ServerUri ApplicationUri . The LocalDiscoveryServer may save the registration information in a persistent datastore that it reads whenever the LocalDiscoveryServer starts.

Randy Armstrong, 06/11/07,

Add a Mantis Issue regarding the IIS 5.1 bug that prevents the LDS from using this URL.


The LocalDiscoveryServer must validate any semaphore file provided by the Server before accepting the registration. If this file disappears the LocalDiscoveryServer must remove the registration from any persistent datastore.

If the Server indicates that it is offline then the LocalDiscoveryServer must not return it in any FindServers response, however, the it should not delete it from any persistent datastore.

6.3 Discovery

The Endpoints Endpoints that implement the FindServers and GetEndpoints services are usually accessible to any application on the network. The LocalDiscoveryServer may use the C c lient certificate supplied with the SSL/TLS connection to deny access to unauthorized applications.

The LocalDiscoveryServer must return an empty list whenever the GetEndpoints service is called because it is does not implement a SessionEndpoint.

The LocalDiscoveryServer checks the status of each registration before returning it in the FindServers response. The LocalDiscoveryServer does not return the Server is marked as offline or if the semaphore file is missing.

Clients must beware of rogue DiscoveryServers that might direct them to rogue Servers . Clients should use the SSL/TLS server certificate to verify that the DiscoveryServer is a server that they trust. When a Client connects to LocalDiscoveryServer is should only connect to Servers with Endpoints that refer to the same node.

Clients should always verify that it trusts the Server Certificate when it creates a Session . This is the final protection against rogue Servers that is always available even if the DiscoveryServers do not use SSL/TLS.

Dedicated Nodes Machines

Some nodes machines will never have more than one Server installed. If this is the case then that Server can also act as the LocalDiscoveryServer for the node machine by using the WellKnownUrls for its discovery Endpoint discovery Endpoint .

When the FindServers service is called the Server returns a single record describing itself. When the GetEndpoints service is called the Server returns its Endpoints Endpoints .

6.4 Auditing

LocalDiscoveryServers must have an audit log that tracks changes to its configuration. For example, each time a Server record is added, changed or removed this event must be logged . The structure of the audit events and the auditing framework is defined in [UA Part 4] .

7 Directory Service DirectoryService s

7.1 UDDI

UDDI registries contain b usinessEntities which provide one or more b usinessServices . The b usinessServices have one or more b indingTemplates . b indingTemplates specify a physical address and a Server Interface (called a t M odel). Figure 10 illustrates the relationships between the UDDI registry elements .


Figure 10 – UDDI Registry Structure

This specification defines standard tModels which must be referenced by businessServices that support UA. UA applications are stored in UDDI registries as businessServices associated with one or more the UA defined tModels. The standard UA tModels defined for UA are shown in Table 2.

Table 2 – UDDI tModels

Name domainKey uuidKeyServer uddi:server.ua.opcfoundation.org uddi:AA206B41-EC9E-49a4-B789-4478C74120B5Discovery ServerDiscoveryServer

uddi:discoveryserver.ua.opcfoundation.org uddi:AA206B42-EC9E-49a4-B789-4478C74120B5

The name of the businessService elements should be the same as the ServerName ApplicationName for the UA application. The serviceKey must be the ServerUri ApplicationUri . At least one bindingTemplate must be present and the accessPoint must be the URL of the DiscoveryEndpoint discovery Endpoint for the UA server identified by the serviceKey. Servers with multiple DiscoveryEndpoint discovery s Endpoints would have multiple bindingTemplates

A UDDI registry will generally only contain UA servers, however, there are situations where the administrators cannot know what S s ervers are available at any given time and will find it more convenient to place a DiscoveryServer in the registry instead.

7.2 LDAP

LDAP servers contain objects organized into hierarchies. Each object has an objectClass which specifies a number of attributes . Attributes have values which describe an object . Figure 11 illustrates a sample LDAP hierarchy which contains entries describing UA servers .


Figure 11 – Sample LDAP Hierarchy

UA applications are stored in LDAP servers as entries with the UA defined object c C lasses associated with them. The schema for the objectC c lasses defined for UA are shown in Table 3.

Table 3 – LDAP Object Class Schema

Name Name Type OIDServer OPCUA-Server Structural 1.2.840.113556.1.8000.2264.1.12.1

ServerUriApplicationUri

OPCUA-Server-ServerUriApplicationUri

Name 1.2.840.113556.1.8000.2264.1.12.1.1

ServerName OPCUA-Server-ServerName String (Required) 1.2.840.113556.1.8000.2264.1.12.1.2IsDiscoveryServer OPCUA-Server-IsDiscoveryServer Boolean (Required) 1.2.840.113556.1.8000.2264.1.12.1.3DiscoveryUrl OPCUA-Server-DiscoveryUrl String (Required) 1.2.840.113556.1.8000.2264.1.12.1.4

Administrators may extend the LDAP schema by adding new attributes.