Service Location Protocol (SLP)

Service Location Protocol (SLP) enables a client to dynamically locate a TN3270 and TN5250 service, and to attach to the least-loaded server, making it unnecessary for you to know the destination address and port of any specific service. Host On-Demand 3270 and 5250 sessions can use SLP to automatically discover TN3270 and TN5250 telnet servers in a network. The Host On-Demand client then uses load information returned from the server to connect through the server carrying the least session load at the time the connection is attempted.

For additional important information on SLP and session balancing, refer to RFC 2165 Service Location Protocol at http://www.ietf.org/rfc/rfc2165.txt, and draft RFC TN3270E Service Location and Session Balancing at http://www.ietf.org/internet-drafts/draft-ietf-tn3270e-service-loc-06.txt.

If Enable Security (SSL) on the Security tab is set to Yes, a connection can be established only to servers that support Secure Sockets Layer Version 3 security.

SLP Administration
Directory agent support
SLP limitations
Server support and limitations
Tuning the network
SLP requirements to run on a token ring

SLP Administration

A client or User Agent (UA) attempts to discover the location of a service by multicasting a service request to the service location general multicast address 224.0.1.22. Service Agents (SAs) that satisfy the UA request and that are listening to this address send a service response. Directory Agents (DAs) will respond on behalf of the SAs when a network contains directory agents.

See RFC 2165 Service Location Protocol for an explanation of UA, DA, and SA terminology, and for a description of the SLP network.

Directory agent support

Host On-Demand supports a network that includes DA, as well as SAs, processing of the service requests. SAs register the services and attributes of these services with a DA.

Clients can learn where the DAs are and unicast service requests to a DA, instead of multicasting to the service-specific multicast address.

DA support is relevant in a large installation that needs to reduce network traffic.

Attributes

Host On-Demand is the user agent and sends the SLP service request according to the session type you are starting. For example, if you have enabled SLP and are connecting a 3270 Display or Printer session, the requested service will be tn3270.

The Host On-Demand service types that can be requested are tn3270 or tn5250. The service requests can be delimited by these attributes:

: SCOPE; LOAD; SECURITY; LUPOOL; AS400NAME

SCOPE
SCOPE is a collection of services that make up a logical group. Host On-Demand includes SCOPE in a service request when a value is specified in the Scope field in the Connection > SLP window during session configuration. If Scope is not included, only unscoped servers respond.

LOAD
LOAD is a value returned by the server on an attribute request. It is an integer number between 0 and 100. Load calculations vary among different server types and may return inconsistent values. Host On-Demand balances the sessions by connecting to the server that returns the lowest value for the load attribute. Servers can be adjusted to compensate for differences in load balancing calculations. Administrators should refer to the server documentation for additional information.

SECURITY
Host On-Demand includes SECURITY in the service request if Enable Security (SSL) is set to Yes on the Security tab during session configuration. When SSL is enabled, the value of the SECURITY attribute is SSLV3. When SSL is not enabled, the value of the SECURITY attribute is NONE. Only servers that support the requested level of security will respond to the level of service request.

LUPOOL
LUPOOL is included in the service request if LU Name or Pool is specified on the Connection tab during session configuration. Only pool names are valid for SLP.

AS400NAME
AS400NAME is included in the service request if SLP AS/400 Name is specified on the Connection tab during session configuration. If an SLP AS/400 name is specified, the connection is established to that AS/400; otherwise, the connection is made to the AS/400 configured as the default at the server.

SLP limitations

When SLP is enabled, you can use only pool names. LU names cannot be used.
The environment used for SLP must support multicast. Broadcast is not supported.
Directory Agent Discovery timeout and Service Agent Multicast timeout are not separately configurable.

Browser limitations:

SLP is not supported on Linux with Netscape.
A session may fail to connect because Telnet Service or Directory Agents cannot be found. A limitation of the Netscape browser may restrict the Time to Live (TTL) range of the SLP packets to 1 instead of the standard setting of 32 for site-wide coverage. This limits the number of routers that the SLP discovery packets can be passed through before the packets are dropped. This is caused by a limitation of the JVM that is shipped with the Netscape browser. Use another browser that supports TTL settings of 32.

Server support and limitations

Supported servers

IntraNetWare for SAA 3.0 (or later)
Communications Server for Windows NT 6.0 (or later)

It is recommended that all SLP servers in the network be defined as scoped. The following fixes must be applied to get responses from both scoped and unscoped servers when no value or the default is entered for the scope: NetWare for SAA 3.0 JR12403 and CSNT 6.0 JR13234.

Server limitations

Communications Server for Windows NT 6.0 does not support Telnet 5250 Enhanced; therefore, you can connect only 5250 display sessions, and they do not support the Workstation ID. 5250 printer sessions cannot be connected.

IntraNetWare for SAA 3.0 does not support Telnet 5250 display or printer sessions or SSL.

IntraNetWare for SAA 4.0 does not support Telnet 5250 Enhanced; therefore, you can connect only 5250 display sessions, and they do not support the Workstation ID. 5250 printer sessions cannot be connected through this server.

Tuning the network

Refer to load and session balancing in the Server documentation for more specific information on tuning the network.

Refer to draft RFC TN3270E Service Location and Session Balancing for additional information on load.

Refer to RFC 2165 Service Location Protocol for information on scalability issues regarding how scope is used and how a DA can be used in a network.