Somos: 5. Message Structure – Somos

The message structure consists of the Industry Standard IP and TCP Headers, the SMS Transport Header, preceded by a delimiter and encapsulated application data, or administrative data.

The SMS Transport Header includes a Message Code field which identifies the type of message: Session Control Messages (message codes 1, 5, 6), the Data Message (message code 19) and the Error Message (message code 9). These messages are illustrated in Table

5-1.

Table 5-1. Message Structure

IP Header

TCP Header

MD Flag and

Size

SMS Transport Header

message code (19)

Encapsulated Application Data

UPL Header

Current UPL SCP Message Data

TCP

message code(1)

Good Day Application Message

TCP

message code(5)

Good Night Application Message

TCP

message code(6)

Good Bye Application Message

TCP

message code(9)

Error Application Message

The IP Header and TCP Header are the standard formats defined by the TCP/IP Communication Protocol, which is presented in Section 4.6 and 4.5.
The Message Delimiter (MD) contains a flag and the message size, discussed in Section 4.4.
The SMS Transport Header is described in Section 4.3.
The UPL Header is described in Section 4.2 - The Encapsulated data includes a subset of the same UAL Header (renamed UPL Header) that is used on top of the X.25 protocol; however, it is encapsulated as data, and it precedes the current UPL data. This encapsulation enables the use of essentially current logic to process the UPL Header data and the UPL data.
The SMS/800 Application Messages are not described in this document.

5.1 SMS/800 Messages

There is no change to the SCP messages to support TCP/IP; however, the UNR-MSG, GNT and SSC messages are not used in the TCP/IP Implementation.

For the TCP/IP Implementation, the SCP messages are encapsulated as data.

5.2 UPL Header

The UAL Header is renamed the ‘UPL Header’ for the TCP/IP Implementation.The UPL Header is encapsulated as data, whereas it is part of the protocol in the X.25 implementation. Five fields from the X.25 UPL Header have been retained for TCP/IP. The fields are presented here along with the values used when the message is transported by the TCP/IP Protocol.

5.2.1 Confirmation Flag

Values are ‘0’ for none, and ‘3’ for Application-to-Application.

5.2.2 Correlation ID (renamed Message ID)

The Correlation ID is a 10-byte alphanumeric field. It uniquely identifies a message from a particular node.

The first byte contains one of the following values (see TA-STS-298):

‘S’: Node messages sent by SMS/800

‘M’: CMSD messages sent by SMS/800

‘N”: Node messages sent by SCP

‘C’: CMSD messages sent by SCP

The first byte is also used to identify the message class. If it has the same code of the receiving system, the message is a “Confirmation Response Message” of a command orig- inated from the receiving system. If the code is different from the receiving system, the message is a “General Message” (i.e., not a “Confirmation Response Message”) and the code identifies the sending system. The “Confirmation Response Message” is an applica- tion response message, which occurs when the request message required application-to- application confirmation (i.e., Confirmation Flag set to '3'). The next 9 bytes can contain any alphanumeric sequence of characters that will uniquely identify that message within that node. There are many different algorithms that can be used to generate the Correlation ID; however, the actual implementation will be left to the developers of each system.

Since the Correlation ID is used to uniquely identify the message, Correlation ID shall not be re-used on different messages.

R5-1

[1] The Correlation ID is generated by the party initiating a message that requests confirmation. Then the same Correlation ID should be used across the network by all parties responding to that message. A separate Correlation ID cannot be generated for a confirmation message.

NOTE: If an SCP sends a message that expects a response, and no response is received (with the same Correlation ID) within a certain amount of time, the send should be repeated until a response is received.

5.2.3 Source Node Name

R5-2

[2] The sending UPL must put the name of its node in the UPL header so that the receiving UPL may identify the sender.

The first byte of the source node name is reserved to indicate the entity that will originate the message. Its content is defined in Correlation ID section.

5.2.4 Destination Routing Code

The destination routing code is a 3-byte field. It is used by the receiving UPL to route the message to the proper application program.

5.2.5 Error Code Field

The error code is a 1-byte field used only when an error is detected in the UPL. If an error is detected, the value identifies the field in error: ‘C’-Confirmation Flag, ‘M’-Correlation ID, ‘O’-Source Node Name, or ‘D’-Destination Routing Code. Default is blank.

NOTE: To facilitate reconciliation, an error message should be returned in the same session in which it was received.

Table 5-2. UPL Header Fields

Field Number	Field Name	Field Length	Values when message is TCP/IP
1	Confirmation Flag	1 byte	‘0’-none, ‘3’-Application-to- Application
2	Correlation ID (formerly Message ID)	10 bytes	alphanumeric: first byte is: ‘S’:Node messages sent by SMS/800 ‘M’:CMSD messages sent by SMS/800 ‘N”:Node messages sent by SCP ‘C’:CMSD messages sent by SCP ; next 9-bytes uniquely identify the message within the node
3	Source Node Name	12 bytes	alphanumeric: sending node
4	Destination Routing Code (DRC)	3 bytes	used by the receiving UPL to route the message to the correct application program
5	Error Code	1 byte	values are C (confirmation flag), M (correlation ID), O (source node name), or D (DRC). Default is blank.

5.3 SMS Transport Header

This header is new. It precedes the encapsulated SCP application messages. The SMS Transport Header contains information needed by the NetPilot CCSOSMR software to interface with the DCMs and Queue Servers to support the TCP/IP Interface.

The ASN.1 encoding in Section 7 defines the message syntax used to describe the transfer syntax of the application messages exchanged between the SMS/800 and SCPs. Each application message will be prefixed with a header (sequence Y1T1iHdr) as defined by sequence Y1DcmMsg. The header is used to store data which informs the receiving node about the sender and type of application message. The remaining portion of the message syntax contains the application message data, if appropriate, corresponding to the particular type of application message. The message header is stripped off by the application layer so that only the message data portion of the message is passed to the proper user program layer.

Table 5-3 identifies the components of the SMS Transport Header:

Table 5-3. SMS Transport Header

Field Number	Field Name	Definition
1	Version Number	Integer
2	Priority	For future use
3	Message Tag	See below
4	Destination Node Name	See below
5	Source Node Name	See below
6	Error Code	0,1,2 or 3 (See below)
7	Message Code	Integer

5.3.1 Version Number

This field contains an INTEGER value representing the TCP/IP message header version number. The allowable value is 1.

5.3.2 Priority

This field contains an INTEGER that indicates the processing priority of a message. Allowable value is ‘00’. This is for future use.

5.3.3 Message Tag

This OCTET STRING field contains up to 11 octets and identifies a message from a particular node in case an error is returned. This Tag is assigned by the sending SCP. It is used to correlate messages for SMS transport protocol errors.

5.3.4 Destination Node Name

This OCTET STRING field can contain up to 50 octets, (recommended ASCII characters for readability). It identifies the name of the destination node. This name must uniquely identify a node within the network. The destination node name represents the receiver of a Y1DcmMsg (see Section 6).

5.3.5 Source Node Name

This OCTET STRING field can contain up to 50 octets(recommended ASCII characters for readability). The source node name identifies the sender of a Y1DcmMsg.

NOTE 1: this is the same as the “source node” in the UPL Header. The size difference (50 octets vs. 12 bytes) permits each SCP to use a naming convention of their choice, including the CLLI of their DCM and a process name.

Note 2: From a protocol point of view, the source name in the UPL Header and SMS Transport Header are two different fields. For example, four TCP sessions must have different SMS header source names, but the UPL may have the same CLLI code.

5.3.6 Error Code

This field contains an INTEGER value that represents the reason for the protocol error. Valid values are:

Error Code Description

0 No Error

1 Bad Source

2 Bad Destination

3 Bad Version

Note: Additional error codes may be added in future releases. Error codes reported and not identifiable (i.e., are not one of these codes) should be treated as “other” (mcommerror(9) in message header).

Section 5.1.2.5 provides a more detailed description of error processing procedures.

5.3.7 Message Code

This field contains an INTEGER value that represents the type of application message provided. There are two types of messages: Protocol Control Messages and Data Messages.

5.4 Message Delimiter (MD)

TCP views a data stream as a continuous stream of octets with no explicit boundaries for messages. For communicating SCPs, it is necessary to delimit all messages. For every message transmitted, the message data will be prefixed with a 4-octet flag (0x7e7e7e7e) plus a 4-octet unsigned binary number: the octet order is from highest to lowest, indicating the length in octets of the message data. The message prefix has a total length of 8 octets. Bit zero (0) is the most significant bit. All messages must be separated by these octets.

R5-3

[3]For every message transmitted via TCP/IP, the message data must be prefixed by a 4-octet flag (0x7e7e7e7e) plus a 4-octet unsigned binary number; the octet order is from highest to lowest, representing the length in octets of the message data. (See Table 1).

… Table 1. Message Data Format

Four Octet Flag

Four Octet Prefix

SMS Transport

Header

UPL Header and UPL Data

(Hex)7e7e7e7e

Message Length

Message Data

5.5 Transport Layer (TCP)

TCP is a reliable, connection-oriented communications protocol that processes packets to and from the IP. It provides a reliable end-to-end connection for each pair of communicating processes. TCP Reliable Delivery Service provides:

Connection-oriented service, which requires that the two application programs establish a logical connection with each other before communications can take place
Stream Orientation, with bits divided into bytes
Buffered Transfer, with sizes as small as a single byte, but usually large enough to fill a reasonably large Datagram before sending it across an internet, and with a push mechanism to force the processing of unfilled Datagrams
Unstructured Streams (no application boundaries)
Full duplex connection with piggybacking, which can send control information for one stream back to the source in datagrams carrying data in the opposite direction.

The TCP Header used (Table 4-4, below and next page) is the Industry Standard format and content.For additional information, see RFC 792, Transmission Control Protocol.

Table 5-4. TCP Header

Field	Bits	Definition
Source Port Number	16	Identifies the sending Application. This, plus IP Address, uniquely identifies a connection/socket.
Destination Port Number	16	Identifies the receiving Application. This, plus IP Address, uniquely identifies a connection/socket. It is provided by the application layer.
Sequence Number	32	Each byte is numbered. The initial # is chosen by the host for each connection.
Acknowledgment Number	32	Next sequence # the sender of the ACK expects to receive.
Header Length	4	# of 32-bit words. Default is 20 bytes
Reserved	6
KEY - URG	1	Urgent Pointer is valid
KEY - ACK	1	Acknowledgment number is valid. On when new connection is being established.
KEY - PSH	1	Receiver must pass data to application ASAP
KEY - RST	1	Reset the connection

Field	Bits	Definition
KEY - SYN	1	Synchronize sequence numbers to initiate a connection
KEY - FIN	1	Sender is finished sending data
Window Size	16	# of bytes, starting with the value in the ACK Number field, receiver is willing to accept
TCP Checksum	16	Size of TCP segment: TCP Header plus TCP Data
Urgent Pointer	16	Used to determine sequence number of last byte of urgent data
Options	var	End of Option List; No Operation; Maximum Segment Size; Window Scale Factor; Timestamp

Table 5-4. TCP Header

(Cont’d)

R5-4

[4] The SMS/800 must support the industry de facto standard transport layer protocol TCP/IP (RFC 793 “Transmission Control Protocol, September 1981” and RFC 791 “Internet Protocol, September 1981”) for inter-operability with other SCPs.

5.6 Internet Layer (IP)

The Internet Protocol (IP) determines the route for packet delivery. The TCP/IP network routes a packet according to the destination IP address attached to it by the IP protocol of the sending host. The IP protocol defines the basic unit of data transfer, the exact format of all data, and a set of rules that define how hosts and gateways should process packets, how and when error messages should be generated and the conditions under which packets can be discarded. SMS/800 will not support switched networks.

IP will serve as the network layer. IP is a connectionless, unreliable, packet delivery protocol. This protocol is termed unreliable because there is no guarantee of packet delivery. IP determines the route for the packet delivery.

A TCP/IP network routes a packet according to a destination IP address attached to it by the IP protocol on the sending host (e.g., SMS/800). The IP address is 32 bits in length and divided into four, 8-bit octets. The information in each octet represents a decimal number with each number separated by a period. This number correlates to one octet of the IP address and can have a value ranging from 0 to 255.A typical IP address is of the form “xxx.xx.xxx.xx“.

The Internet Header (IP) used is the Industry Standard format and content. For additional information, see RFC 791, Internet Protocol.

Table 5-5. IP Header

Field	Size in bits	Definition
Version	4	IP version in use
Header Length	4	# of 32-bit words in Header.Max is 60 bytes
Type of Service	8	min delay; max throughput; max reliability; min $cost
Total Length in bytes	16	Datagram size in bytes, or size of fragment
Identification	16	Host assigned unique # of Datagram
Flags	3x1	‘more fragments’ bit is on in all except last fragment
Fragment Offset	13	Position in datagram from the beginning of the unfragmented datagram. Enables re-assembly at final destination
Time To Live	8	Max # of routers the Datagram can pass through
Protocol	8	Identifies which protocol gave IP the data to send: 1=ICMP - network 2=IGMP - network 6=TCP - transport 17=UDP - transport
Header Checksum	16	calc of IP Header size only, not the data
Source IP Address	32	Source dotted-decimal notation, normally 4 numbers
Destination IP Address	32	Destination dotted-decimal notation, normally 4 numbers
options	var	Security & Handling Restrictions; Record Route; Timestamp; Loose Source Routing; Strict Source Routing

5.7 Network Access Layer (NAL)

NAL provides the interface to the communication network. It is comprised of the OSI Reference Model Physical layer and the Data Link layer. NAL processes network specific frames to and from the network. NAL relies on existing protocols and provides network services such as priority, security, and reliability. As depicted in Section 4, a high-speed, back-end LAN shows SCPs connecting either directly to the LAN, or via a router/bridge to the LAN. TCP/IP supports a number of physical layer protocols, including Ethernet, IEEE 802.5, FDDI, and others.