RFC 3049

TN3270E Service Location and Session Balancing

📅 published January 2001, from ietf

RFC 3049: TN3270E Service Location and Session Balancing 💅✨

Okay bestie, let's get into this one 🫶 RFC 3049 is a Standards Track doc from the Network Working Group, dated January 2001. The authors are J. Naugle and K. Kasthurirangan from IBM, plus G. Ledford from Zephyr Development. The title block doesn't list anything it obsoletes or updates, so this one's standing on its own 🌸

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it wants your discussion and suggestions for improvements 💖 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 🧚

This doc is all about using Service Location Protocol (SLP) and session balancing with a TN3270E emulator, in a client/server setup where the server is a TN3270E server 🖥️

App developers can find TN3270E services and load balance across them (those are 3270 host sessions) using this SLP support. It's giving very useful energy 🔥

Table of Contents 🗂️

   1. Introduction and Terminology .................................  2
      1.1 Terminology ..............................................  2
   2. An Overview of RFC 2165 ......................................  3
      2.1 SLP Agents ...............................................  3
      2.2 Service Agents ...........................................  3
      2.3 User Agents ..............................................  4
   3. TN3270E Server Environment and Load ..........................  4
      3.1 TnN3270E Server Load .....................................  4
   4. TN3270E Client Configuration .................................  6
      4.1 SLP Scope ................................................  6
      4.2 DA-Discovery Time-Out ....................................  6
      4.3 SA-Discovery Time-Out ....................................  7
   5. TN3270E Client Implementation Information ....................  7
      5.1 Overview .................................................  7
      5.2 How to Obtain List of TN3270E Servers Supporting SLP .....  8
      5.3 TN3270E Sample Client Flow ...............................  9
         5.3.1 Open the SLP connection .............................  9
         5.3.2 Query the list of TN3270E servers ...................  9
         5.3.3 Forward Looking Example using SLPv2 ................. 10
         5.3.4 Determine loading of each TN3270E server ............ 10
      5.4 Recommendations .......................................... 11
   6. Sample Trace Flow of SLP and Session Balancing ............... 11
   7. Service Templates and Service Registration ................... 12
      7.1 The TN3270E Service Type Template ........................ 12
      7.2 The Server Service Template .............................. 16
      7.3 Template Contact Information ............................. 17
      7.4 Security Considerations .................................. 17
      7.5 Sample TN3270 Service Registration Message ............... 18
      7.6 Sample Server Service Registration Message ............... 19
   8. References ................................................... 19
   9. Authors' Addresses ........................................... 20
   10. Full Copyright Statement .................................... 21

1. Introduction and Terminology 🌟

This doc gives you the info on using Service Location Protocol to find TN3270E servers on a network and balance sessions across them ✨ The implementation follows the standards track RFC 2165, Service Location Protocol [1]. It also includes some examples using Service Location Protocol version 2, so it's future-proofed 🔮 Service Location Protocol version 2 is documented in RFC 2608 [4] and RFC 2609 [2].

1.1 Terminology 📚

Here's the key-word situation, and it matters a lot 👑 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

Here are some terms you'll see a lot:

Session Balance means the TN3270E client uses server load info to set up a TN3270E connection to whichever TN3270E server has the least load at that moment 💅 The goal is to spread TN3270E sessions across more than one server so that no single server gets overloaded. "Load balance" is the broader term about server load in general, but this doc is laser-focused on connecting sessions to the least loaded servers 🎯

SNA Gateway is a Systems Network Architecture (SNA) gateway that lets several LAN-attached workstations reach SNA hosts through one or more physical connections to one or more hosts 🌈 It acts as a protocol converter between LAN workstations and a WAN host line. It typically supports the SNA protocols LU 0, 1, 2, 3, and dependent LU 6.2 (APPC). SNA gateways usually include TN3270E server capability too 🖥️

LU Pool: The Logical Units (LUs) defined in the gateway can be dedicated to one workstation, or pooled among several workstations 🫧 Pooling lets workstations share common LUs, which makes the LUs more efficient and cuts down on configuration and startup work at the host. When a client connects to the gateway, the gateway grabs an LU from the pool to set up a session. When the session ends, the LU goes back in the pool for other workstations to use 🔁

Commserver Service Type Template: The Commserver service type is an SNA Gateway server, as defined above in this terminology section 💜 The template describing this service type's attributes is in section 7.2.

2. An overview of RFC 2165

Hold up, RFC 2165, Service Location Protocol (SLP) [1], is what gives clients an automatic way to discover services inside an administrative domain 🔍 Those services have attributes, and a client can pick a service based on them. The basic design uses three agent types: User Agents (UA's), Service Agents (SA's), and Directory Agents (DA's) 🎀

2.1 SLP Agents 🕵️‍♀️

User Agents query Service Agents or Directory Agents. They acquire or request service info based on the attributes and service the user app needs 💖

Service Agents represent a specific service and advertise its info 📣

Directory Agents act as a central collection point for service registration info. Service Agents register with them, and "user agents" in "intranets" later request that info from them 🗂️

2.2 Service Agents 🛎️

The service registers itself with its service agent so the SA can start advertising the info across the network. Registration means the service gives the SA all its relevant configuration info, plus attribute tag/value list pairs specific to that service ✨ The service template is an abstract schema that applies to the service type. The TN3270E service template (shown later) contains the URL, which is the server's address with the port that should be used to connect to it. The URL also has the service type, which here is TN3270. The template holds every other attribute tied to this service too 🌸

2.3 User Agents 🦋

The User Agent working for the TN3270E client gets service info from the Service Agent(s) or a Directory Agent 💅 Based on that info and the attributes it needs, the TN3270E client (or user) decides whether to connect to a particular server. Using the advertisements from various TN3270E servers, the client checks the load attribute and can choose to connect to the least loaded server 🎯 If that server becomes unavailable by the time the client connects, it can try the next server on its list, which is the second least loaded server whose advertisement the client/user agent retrieved 🔄

3. TN3270E Server Environment and Load 🖥️

TN3270E Servers are everywhere in today's networked world 🌍 SLP gives emulator clients a way to discover TN3270E servers on the network and balance sessions among them. The TN3270E servers could be spread across different SNA gateways that use different connection methods to hosts 🧚

LU pools make life easier for administrators, who can give users access to hosts. Admins can add users to LU pools that have pre-configured LUs with specific attributes, like LU types and model types 💜

These LU pools typically include LUs from several gateways. As pool members make TN3270E session connections, they connect to different TN3270E servers with different load factors, which is how session balancing happens 🫶 LU pools aren't required for SLP or session balancing, though. A TN3270E client can get a session by using SLP and session balancing to find the least loaded server on the network ✨ And if the emulator doesn't care which device types a pool supports, or can assume a given pool supports only certain device types, it can use a wild card * when asking for LUPOOL in a service request 🌈

3.1 TN3270E Server Load 💖

okay bestie, a TN3270E server that shares load info SHOULD count the sessions that are available and not in current use as part of its total load 🧮. There can be other factors too, like a server that isn't dedicated only to SNA traffic and is also handling stuff like file services and print services, etc. 💅 Standardizing how each server calculates its own load is out of scope for this doc. Different vendors' servers might weigh what they think matters, and those methods can change over time 🦋.

If a TN3270E server lives in a network with other TN server implementations that use SLP for session balancing, its load could be adjusted to make up for differences in how load gets calculated ✨.

One way to help TN3270E server admins deal with those differences is to let them modify the load calculation on the TN3270E server 🎀. That's an element of control: the admin uses an integral number between 0 and 100 (100 being the highest) to change the load. This load measurement acts as an extra factor on the server's actual load calculation, so the admin can bias the likelihood of that server being picked by a TN3270E client up or down 🌈.

Load MUST be defined as one of the attributes for the TN3270E server 👑. The Load attribute is how clients figure out which server to connect to. If a UA only provides a Service Type in an Attribute Request, the reply includes all attributes and all values for that Service Type, and Load gets included too. Attribute Requests MAY include a select clause, so you could get back just the load info. For more on Attribute Requests, check out Service Location Protocol [1] 🧚.

An application could send a Service Request to locate a TN3270E server. Then an app built for least-load location of a TN3270E service could send a bunch of Attribute Requests to grab the load measurement of each server specified with a URL 💜. It would use a select clause like the one below to get only the load info:

URL = service:tn3270://9.37.51.254:23 Attribute filter = LOAD

The attribute LOAD comes back along with its value. The app can then send other Attribute Request calls for each URL 🫶.

The app would then select the least loaded server as a connection target. If it tries to connect to a server and that connection fails, it could then try to connect to the next least-loaded server 🔥.

4. TN3270E Client Configuration ✨

4.1 SLP Scope 🌸

Scope is a parameter that controls and manages which clients can access which servers on a network 🔒. It's the same as the Service Location Protocol scope defined in RFC 2165 [1]. Controlling scope is necessary for two reasons:

As your network, the number of clients, and the number of servers grow, it becomes necessary to partition access to those servers by the growing number of clients in order to reduce overall traffic on the network. It also lets administrators organize users and servers into administrative groups 💕.

The meaning of scope values is defined by the administrator of the network. These values can represent any entity 🍓. Commonly, they fall along departmental, geographical, or organizational lines.

Each TN3270E server can be assigned to a single scope or multiple scopes. TN3270E clients using these servers can be configured for a single specific scope. If TN3270E clients are not configured with a scope, they MUST use the scope "default" 🎀.

SLP Service Agents and Directory Agents (DA) need to reside in the network that supports the TN3270E server with configured scopes.

Attribute information for Service Types pertaining to a specific scope can be obtained from Directory Agents (DA). The DA won't return a result unless the requested scope matches 🙈.

For more information on SLP scope, refer to Service Location Protocol [1].

4.2 DA Discovery time-out ⏰

The DA Discovery time-out value controls how long the SLP API must wait to discover Directory Agents (DAs) in the network. The discovery request is a multicast, and the amount of time needed to gather all DA responses might vary depending on many factors. If there are no DAs in the network, this time-out value can be set to zero to indicate that no DA discovery is to be done. The time-out is expressed in milliseconds. Time-out intervals and default values should be handled as described in RFC 2165 [1] 🦋.

4.3 SA Multicast time-out 📡

The SA Multicast time-out value controls how long the SLP API must wait to discover services, attributes, or service types in a network without at least one DA that supports the scope of the request. In this situation, the requests are multicast, and the User Agent waits the time-out value to gather the multiple responses that come back. The time-out is expressed in milliseconds. Time-out intervals and default values should be handled as described in RFC 2165 [1] 💜.

5. TN3270E Client Implementation Information 💻

5.1 Overview 🌟

A TN3270E client that implements TN3270E SLP session balancing does not need to configure an IP Host Address or TCP Port for the TN3270E server it wants to connect to. Instead, the IP Host Address and TCP Port of the least loaded TN3270E server are discovered using the SLP session balancing described in this document 🧠.

The discovery of the least loaded TN3270E server is done entirely outside of and before the TN3270E telnet negotiation. Once the IP Host address and TCP Port of the least loaded TN3270E server are discovered, the TN3270E client can start normal TN3270E telnet negotiation 🚀.

The TN3270E client MUST allow for configuration of the following parameters. These SLP-specific configuration items are covered by configuration parameters in the SLP API [5] 👑.

Enable SLP Session Balancing

This configuration parameter indicates whether or not SLP session balancing is enabled. If it is enabled, the following three configuration parameters MUST also be configurable. If this parameter is disabled, SLP session balancing is not supported and normal TN3270E telnet negotiation is performed.

Scope Name

The scope name is a text string that specifies a group of TN3270E servers. It can be used to identify groups of TN3270E servers in a departmental or geographic setting. For example, if the scope name is Building-D, then the SLP session balancing would search all TN3270E servers in the Building-D scope to find the least loaded TN3270E server 🏢.

If the scope name is blank, then the scope name is not used. This is referred to as unscoped. It should be noted, as in section 4.1 above, that any reference to unscoped services applies to Service Location Protocol version 1 only [1]. Service Location Protocol version 2 doesn't allow unscoped services but does allow the use of default scope [4]. In this case, all TN3270E servers, with or without scope names, can be used to satisfy the request for least loaded TN3270E servers. To cut down on network overhead, it is recommended that either all servers be scoped or no servers be scoped. Refer back to section 4.1 for more discussion of scope 🫠.

DA Discovery Time Out Value

This value is specified in milliseconds and is fully described in section 4.2 of this document ⏱️.

SA Multicast Time Out Value

This value is specified in milliseconds and is fully described in section 4.3 of this document ⏱️.

5.2 How to obtain the list of TN3270E servers supporting SLP 🍬

A TN3270E client that implements SLP session balancing uses API calls to obtain the list of TN3270E servers supporting SLP session balancing.

The following Service Location Version 2 API [5] calls could be used with TN3270E SLP session balancing:

  • SLPOpen - returns an SLPHandle handle to be used
  • SLPFindSrvs - issues the query for services
  • SLPFindAttrs - returns service attributes matching the attribute ids for the indicated service URL or service type
  • SLPClose - frees all resources associated with the handle

5.3 TN3270E Sample Client Flow 🧁

5.3.1 Open the SLP connection 🔓

The TN3270E client must first open a handle with the SLP User Agent. For Service Location Protocol version 2, the SLPOpen API call [5] is used. The SA multicast time out and DA discovery time out values would be passed as parameters to the SLPOpen API call 💅.

5.3.2 Query the list of TN3270E servers 🔍

The TN3270E client then queries for the list of TN3270E servers supporting SLP. This is done by using the Service Request API call ✨.

The request string contains information that determines which type of TN3270E servers this client wants to connect to. The request string can contain the scope name, pool name, session type, and 3270 screen size 🌈.

The SLPv1 query string has the following format:

TN3270/<scope name>/LUPOOL/ == <pool name><TAB><device type>

The <scope name> is the name of the scope that is configured for the TN3270E client. If the scope is blank or null (unscoped request), then the scope is not inserted into the request string.

The <pool name> is a 1 to 8 character upper case string that indicates the name of the pool the TN3270E client wants to connect to. For SLP session balancing, the same pool name must be configured on different TN3270E servers 🍓.

The <TAB> is the '/t' tab character, which is hexadecimal 0x09. The <TAB> is a literal and is used as a separator.

The <device type> can be any of the following:

    3270DSC for TN3270E device type IBM-3287-1
    3270002 for TN3270E device types IBM-3278-2 and IBM-3278-2-E
    3270003 for TN3270E device types IBM-3278-3 and IBM-3278-3-E
    3270004 for TN3270E device types IBM-3278-4 and IBM-3278-4-E
    3270005 for TN3270E device types IBM-3278-5 and IBM-3278-5-E
    * for TN3270E device type IBM-DYNAMIC

Example:

For a TN3270E client searching for TN3270E servers in the ENGINEERING scope, for a model 2 screen size and LUPOOL name pool2, the following SLPv1 request string would be constructed 🧚:

"TN3270/ENGINEERING/LUPOOL/ == POOL2<TAB>3270002"
Note: The " characters before and after the string are not part of the request string, so don't type them in 🙈.

5.3.3 Forward Looking Example for SLPv2 🔮

For SLPv2, the scope and service type are no longer part of the query string. These are now separate fields in the message. The service type name is required to have the "service:" prepended. The service type field would look like "service:TN3270", and the scope field would be a comma separated list of scopes. A scope name is always required in SLPv2. If no other name is known, the scope name "DEFAULT" is used. The example below uses the same parameters as the one in section 5.3.2 above 💖.

Example: Service Type: service:TN3270 Scope string: ENGINEERING. The query string would have the following format:

(LUPOOL=<POOL2> <32700002>)

In SLPv2 queries, all whitespace is compressed to a single space character during matching, so the identity of the separator character does not matter. The tab character could be added for readability, but it will not affect the outcome of the query 🎀.

5.3.4. Determine loading of each TN3270E server ✨

okay so you can ask for the service:tn3270e attributes and ask for LOAD 🔥 the servers will hand back all their loads. say you get back 35, 88, 78. 💅 then you send a service request for all the tn3270E servers with LOAD<40, and boom, you're getting the least busy ones 🧚 even if the load changes between your attribute reply and your request, you still get the best the network has to offer 🫶

once you've got your server, the TN3270E client uses that TN3270E server's IP Host address to kick off normal Telnet TN3270E negotiation 🦋

5.4. Recommendations

bestie, the TN3270E client SHOULD display the IP hostname and TCP Port it's using for the TN3270E connection 👀 that way the user always knows which TN3270E server they're actually connected to. ✨ for example, the IP host address could sit right in the window system status bar 🌸

the TN3270E client SHOULD also display the resource name the TN3270E server sends back once the connection and TN3270E negotiation are done 💖 this tells the user which LU resource name in the LUPOOL their session landed on. 🎀 for example, the resource name could go in the Windows status bar, or even in the 3270 OIA line 💅

⚠️ if the client has picked its least loaded server but the connection to that server fails for some reason, the connection should be closed, and then the client should try to connect to the other TN3270E servers in the list of least loaded servers. no drama, just move on 💜

for example, a TN3270E server might turn away a connection to a specific pool if that pool is full, or if the device type doesn't match what's available in the pool 🙈 if that happens, an attempt to other least loaded TN3270E servers SHOULD be performed. 🫶

6. Sample Trace Flow of SLP and Session Balancing 🧚

this sample trace flow is provided for informational purposes only 📝 it's just here to show you what a session looks like from start to finish ✨

SLP API: Service Request: TN3270//LUPOOL == POOL2 3270002/

SLP API: Service Reply: service:tn3270://206.109.45.139:23

SLP API: Service Reply: service:tn3270://206.109.45.140:23

Connecting to 206.109.45.139:23...

TerminalType=NVT

Connection established

Recv <- DO TN3270E

Send -> WILL TN3270E

TerminalType=TN3270E

Recv <- SEND DEVICE_TYPE
Send -> DEVICE_TYPE REQUEST IBM-3278-2-E CONNECT POOL2

Recv <- DEVICE_TYPE IS IBM-3278-2-E CONNECT TN8003

Send -> FUNCTIONS REQUEST BIND_IMAGE SYSREQ

Recv <- FUNCTIONS IS BIND_IMAGE SYSREQ

7. Service Templates and Service Registration 💖

okay so the Service Location Protocol uses the service: URL scheme name to define URLs called service: URLs 🌈 these give clients the configuration info they need to set up a 3270 session through the TN3270E server 🎀 and SLP lets service: URLs get registered and discovered, which is so iconic 👑

Service Registration 📋 these registrations contain a service: URL and any attributes that go with that service 💜 the service registration info for the server is shown below.

Service Templates 📝 templates are documents that formally define the attributes a service has, the ones a client might want to use 🦋 for more on service templates, check out Service Templates and service: Schemes. [2] the server service template and the TN3270 service templates are shown below ✨

7.1. The TN3270E Service Type Template

the service:tn3270: template below follows the grammar from "Service Templates and service: Schemes" 💅 for the full breakdown of the syntax, go to [2] 🫶

Name of submitters: Jim Naugle <jnaugle@us.ibm.com>
                    Gregg Ledford <gledford@zephyrcorp.com>
                    K. Kasthurirangan <kasthuri@us.ibm.com>
Language of service template: en

Security Considerations 🔐 bestie, this one's serious. SLP can help clients discover the security services a TN3270E server supports. 😭 if security services are important or required, using SLP authentication and protected scopes in Service Location Protocol version 1 is recommended [1]. the template also uses well known ciphersuite names [3] 💀

Template text:

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

template-type=tn3270e

template-version=1.0

template-description=
 The tn3270 service provides 3270 gateway access to an SNA network
 via the TN3270 protocol.  The attributes reflect the types of 3270
 devices, LU Pools, and load information available on the server.

template-url-syntax=
# service:tn3270://<hostname>:<port>
# <hostname>
# <port>

load=integer
# This is the load balancing quantity to use in determining the
# least loaded TN3270E server to attach to for the service.  The
#range of valid values is an integral 0 to 100 with 0 indicating the
#lowest possible load and 100 the highest

LUPool=string X M L
# This attribute takes on one or more values as defined below.
# The <TAB> char.  0x09 is literal and will be used as a separator.
#
#
#   <pool name> = <name> / <name> "<TAB>" <dev type>
#   <name>      = 1*ALPHANUM
#                 "3270DSC"
#
#
#
#
# Identifies the LU pool names of LU pools available for use on this
# service with the associated device types supported in each pool.
# Each value is a record where the first token is the pool name of
# the pool and the second token is a device type supported in that
# pool.  A pool name without a device type indicates that LUs of
# unknown type are included in the pool.  Records associated with a
# given pool name are repeated for each supported device type.  A
# given pool is included in a registration request if any PU profile
# that contributes at least one LU to the pool is active on the
# server.  The range of valid dev_types are:
#
# dev_type    Meaning
#
# 3270002     Lu Type 2 Model 2
#
# 3270003     Lu Type 2 Model 3
#
# 3270004     Lu Type 2 Model 4
#
# 3270005     Lu Type 2 Model 5
#
# 3270DSC     Printer LU
#

BIND=keyword
# The server supports the SNA bind image TN3270E function.

DATA=keyword
# The non-SNA 3270 data stream is supported by server.

RESPONSES=keyword
# The server supports SNA response mode.

SCS=keyword
# The server supports SNA 3270 SCS data stream.

SYSREQ=keyword
# The SYSREQ keyboard key is supported on server.

RFC1576=keyword
# RFC1576 options supported.

RFC1646=keyword
# RFC1646 options supported.

RFC2355=keyword
# RFC2355 options supported.

security=string M
# This is the security technique supported on the server.
# The defined values are:
NONE
SSLV3

Ciphersuites=string M
# Cipher specifications supported by this server.
# Additional values will be defined in future templates.
NULL_NULL,
NULL_MD5,
NULL_SHA,
RC4_MD5_EXPORT,
RC4_MD5_US,
RC4_SHA_US,
RC2_MD5_EXPORT,
DES_SHA_EXPORT,
TRIPLE_DES_SHA_US

platform=string X
# This is the network operating system platform underlying the
# advertising service.  The defined values are:
#
# IW          Server uses IntranetWare or NetWare operating system
#
# NT          Server uses the Microsoft NT operating system
#
# OS2         Server uses the OS2 operating system
#
# AIX         Server uses the AIX operating system
#
IW,NT,OS2,AIX

protocol=string X
#   This is the protocol(s) supported by the server providing this
#   service.  The defined values are:
#
# IP          Server supports client connections over IP (TCP/IP or
#             UDP/IP)
#
# IPX         Server supports client connections over IPX (SPX/IPX)
#
IP,IPX

server name=string
# This is the name of the server that was configured during
# installation.

release=string X
# This is the version and release level of the server advertising
# services.  Its format is vv.rr.mm where "vv" is the major version
# number, "rr" is the minor version number, and "mm" is the
# modification level.  All numbers are padded on the left with zeroes
# to two characters.
# Example: version 3, release 0, mod level 0 is "03.00.00"

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

7.2. Server Service Type Template

the service:commserver: template below also follows the grammar from "Service Templates and service: Schemes" 🌸 for the detailed syntax explanation, head to [2] 💖

Name of submitters: Jim Naugle <jnaugle@us.ibm.com>
                    Gregg Ledford <gledford@zephyrcorp.com>
                    K. Kasthurirangan <kasthuri@us.ibm.com>
Language of service template: en

Security Considerations 🛡️ SLP can help clients discover security services the TN3270E server supports. if security services are important or required, using SLP authentication and protected scopes [1] is recommended. 🫶

Template text:

-------------------template begins below this line------------------

template-type=commserver

template-version=1.0

template-description=
 The server service type is registered whenever the communications
 software is loaded on the server.  It describes generic attributes of
 the server.  These attributes are also repeated on the other service
 types provided.

template-url-syntax=
 # service:commserver://<hostname>:<port>
 # <hostname>
 # <port>

platform=string X
 # This is the network operating system platform underlying the
 # advertising service.  The defined values are:
 #
 # IW          Server uses Novell IntranetWare or NetWare operating
 #             system
 # NT          Server uses the Microsoft NT operating system
 #
 # OS2         Server uses the OS2 operating system
 #
 # AIX         Server uses the AIX operating system
 #
 IW,NT,OS2,AIX

protocol=string X
 #   This is the protocol(s) supported by the server providing this
 #   service.  The defined values are:
 #
 # IP          Server supports client connections over IP (TCP/IP or
 #             UDP/IP)
 #
 # IPX         Server supports client connections over IPX (SPX/IPX)
 #
 IP,IPX

server name=string
 # This is the name of the server that was configured during
 # installation.

release=string X
 # This is the version and release level of the commserver
 # advertising services.  Its format is vv.rr.mm where "vv" is the
 # major version number, "rr" is the minor version number, and "mm"
 # is the modification level.  All numbers are padded on the left with
 # zeroes to two characters.
 #
 # Example: version 3, release 0, mod level 0 is "03.00.00"

---------------------template ends above this line---------------------

7.3. Template Contact Information

the people to contact about these templates are:

Jim Naugle <jnaugle@us.ibm.com>
Kasthuri Kasthurirangan <kasthuri@us.ibm.com>
Gregg Ledford <gledford@zephyrcorp.com>

7.4 Security Considerations ✨

Okay bestie, security time 🔐 Service type templates are basically the cheat sheet that tells everyone how to read the info SLP hands back. So if somebody messes with those templates or sneaks in fake ones 😱, services might register themselves wrong, or clients might get totally confused about what they're looking at. Not it. 💀

The service: URLs are the big deal here, because they spell out the service access point and protocol for each service type 📍 Those URLs can get passed around, and a sneaky one could point you to a location you never wanted to go to. Anyway, SLP [1] has an authentication mechanism so registered service: URLs can get signed, and clients can check those signatures 🔏 Iconic behavior.

SLP can also help clients find the security services that a TN3270E server supports 🛡️ If security services matter a lot or are required, using SLP authentication and protected scopes [1] is recommended. Protect your scopes, periodt 💅

7.5 Sample TN3270 Service Registration Message 🎀

Here's what a TN3270 service registration message looks like. Notice all the attributes lined up like a fit check 👗

URL: service:tn3270://<addr-spec>:<port-number> Attributes:

[(SCOPE=<string>),]

(RELEASE=03.00.00),

(PLATFORM=IW),

(PROTOCOL=IP),

(SERVERNAME=<string>),

(LOAD=<integer 0 to 100>),

[(LUPOOL=pool-name0/tANY,

pool-name1/tdevice_type1,

pool-name2/tdevice-type2, ...

pool-namen/tdevice-typen)]

BIND,

DATA,

RESPONSES,

SCS,

SYSREQ,

(SECURITY=NONE),

RFC1576,

RFC1646,

RFC2355

7.6 Sample Server Service Registration Message 🌸

And now the server version, which is a lot more minimal, lowkey iconic 🦋

URL:service:commserver://<addr-spec>:<port-number>

Attributes:  [(SCOPE=<string>),]

(RELEASE=03.00.00),

(PLATFORM=IW),

(PROTOCOL=IP),

(SERVERNAME=<string>)

8. References 📚

[1] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan, "Service Location Protocol", RFC 2165, July 1997.

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

[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

[4] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol Version 2", RFC 2608, June 1999.

[5] Kempf, J. and E. Guttman, "An API for Service Location", RFC 2614, June 1999.

[6] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

9. Authors' Addresses 💌

Jim Naugle
IBM
P.O. Box 12195
Research Triangle Park, N.C. 27709-2195
USA

Phone:  (919) 254-8789
EMail:  jnaugle@us.ibm.com


Kasthuri Kasthurirangan
IBM
P.O. Box 12195
Research Triangle Park, N.C. 27709-2195
USA

Phone: (919) 254-5721
EMail: kasthuri@us.ibm.com


Gregg Ledford
Zephyr Development Corporation
8 Greenway Plaza Suite 1400
Houston, Texas 77046
USA

Phone: (713) 623-0089
EMail:  gledford@zephyrcorp.com

Copyright (C) The Internet Society (2001). 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 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.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from