OCS Communication Protocol, Ocp

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Kontr - Checked Datum - Date Rev

1(50)

Dokansv/Godk - Doc respons/Approved File

Nr - No.

Ericsson Utvecklings AB 2001

5/00

2 01

-CA

L 11

9 04

01 U

en A

OCS COMMUNICATION PROTOCOL, OCP

Abstract

This document describes the OCP protocol and the internal OCITS protocolwhich supports OCP.

Application

This document is a base for implementation of the OCP protocol.

UAB/S/GD Jan Lambert

Internal InformationINTERWORK DESCRIPTION

B

UAB/S/GD TDI

2001-03-09

2/155 19-ANZ 221 02 Uen

2(50)Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Kontr - Checked Datum - Date RevDokansv/Godk - Doc respons/Approved File

Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

Contents

1 GENERAL 31.1 OCP 31.2 STCOM 31.3 TCP/IP 4

2 CONNECTION MANAGER 52.1 CONNECTION MANAGER: PHASES 52.2 CONNECTION MANAGER: CP-RP MESSAGES 82.3 CONNECTION MANAGER: CP-RP TYPES 11

3 RP MANAGER 133.1 RP MANAGER: PHASES 133.2 RP MANAGER: CP-RP MESSAGES 143.3 RP MANAGER: CP-RP TYPES 17

4 OCP CONNECTION 184.1 OCP CONNECTION: PHASES 184.2 OCP CONNECTION: CP-RP MESSAGES 234.3 OCP CONNECTION: CP-RP TYPES 304.4 OCP CONNECTION: RP-AP MESSAGES 304.5 OCP CONNECTION: RP-AP TYPES 324.6 OCP CONNECTION: CP STATE MACHINE 344.7 OCP CONNECTION: RP STATE MACHINE 364.8 OCP CONNECTION: AP STATE MACHINE 384.9 GENERAL DESCRIPTION OF USED STATES 40

5 REFERENCES 41

6 REVISION HISTORY 42



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

1 GENERAL

1.1 OCP AND OCITS

This document describes the OCP protocol and internal OCITS protocolmarked with grey in Figure 1.1.

Figure 1.1 OCP and OCITS Protocols

The remote host can be any type of host. In this document the remote hostis called AP.

The OCP protocol isnot a symmetrical protocol.

1.2 STCOM

Communication within a STCOM peer to peer relation is synchronous, therequesting user must receive a confirmation before a new request can besent.

The OCITS protocol between CP and RP is implemented as three logicallinks provided by STCOM:

a Logical Link 0, Connection Managerb Logical Link 1, RP Managerc Logical Link 2, OCP Connection

1.2.1 Logical Link 0: Connection Manager

1.2.1.1 Start

When the connection manager on logical link 0 is started, one connectionmanager individual shall be created. The created individual is given theidentity = 1. There can only exist one individual of the connection manager.

OCITSImplementation

OCPImplementation

OCITS Protocol

Service Access Point Service Access Point

OCP User OCP User

STCOMImplementation

TCP/IPImplementation

OCP Protocol

TCP/IPImpl.

STCOMImpl.STCOM Protocol TCP/IP Protocol

RPCP, local host AP, remote side

OCITS OCP

Impl. Impl.



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

1.2.1.2 Message

The connection manager peer handles creation and deletion of OCITSconnection peers.

1.2.2 Logical Link 1: RP Manager

1.2.2.1 Start

When the OCITS connection on logical link 1 is started, it shall be set to aninitial state with no individuals created. OCITS connection individuals canonly be created and deleted by the connection manager individual.

1.2.2.2 Message

An OCITS connection peer handles transport of RP management trafficbetween the CP and the RP.

1.2.3 Logical Link 2: OCITS Connection

1.2.3.1 Start

When the OCITS connection on logical link 2 is started, it shall be set to aninitial state with no individuals created. OCITS connection individuals canonly be created and deleted by the connection manager individual.

1.2.3.2 Message

An OCITS connection peer handles transport of OCITS traffic between theCP and the RP.

1.3 TCP/IP

The OCP protocol between RP and AP utilizes TCP/IP as transport service.



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

2 CONNECTION MANAGER

2.1 CONNECTION MANAGER: PHASES

2.1.1 Create Connection on RP

2.1.1.1 Short description

Create connection is requested by a CP application to create an OCITSconnection individual on the RP.

2.1.1.2 Normal flow

It is guaranteed that the individual has been created after aCreate Connec-tion-Confirmation on RPwith no fault code.

2.1.1.3 Alternative flow

-

2.1.1.4 Supervision

The time fromCreate Connection on RP has been sent untilCreateConnection Confirmation on RPis received is time supervised. If the timesupervision expires, noConnection is created.

Figure 2.1 Create connection on RP

Create Connection on RP

Create Connection Confirm on RP

CP: Connection Manager RP: Connection Manager AP: Connection Manager

time supervised



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

2.1.2 Delete Connection on RP


Delete connection is requested by a CP application to delete an OCITSconnection individual on the RP.

2.1.2.2 Normal flow

It is guaranteed that the individual has been deleted after aDelete Connec-tion-Confirmation on RPwith no fault code.


-

2.1.2.4 Supervision

The time fromDelete Connection on RPhas been sent untilDelete Connec-tion Confirmation on RPis received is time supervised. If the time supervi-sion expires, theConnection is considered deleted anyway.

Figure 2.2 Delete connection on RP

RP: Connection Manager

Delete Connection on RP

Delete Connection Confirm on RP

CP: Connection Manager AP: Connection Manager

time supervised



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

2.1.3 Create Connection on CP


Create connection is requested by an RP application to create an OCITSconnection individual on the CP.

2.1.3.2 Normal flow

It is guaranteed that the individual has been created after aCreate Connec-tion-Confirmation on CPwith no fault code.


-

2.1.3.4 Supervision

The time fromCreate Connection on CPhas been sent untilCreateConnection Confirmation on CPis received is time supervised. If the timesupervision expires, noConnection is created.

Figure 2.3 Create connection on CP

Create Connection on CP

Create Connection Confirm on CP

CP: Connection Manager RP: Connection Manager AP: Connection Manager

time supervised



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

2.2 CONNECTION MANAGER: CP-RP MESSAGES

The first column (#1) refers to the user data as the CP sees it. The secondcolumn (#2) refers to the user data as the RP sees it.

The CP registers DR0, DR1, DR2, and DR3 are used by the STCOMprotocol and are described in [1].

The network byte order for the OCITS protocol is little endian, that is, thelow-order byte is stored at the starting address.

Figure 2.4 Little endian byte order

2.2.1 Create Connection on RP

Type Declarations specific to the message:

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (1)

1 Zero

DR5 2 CP individual

3

DR6 4 Communication service

5 Logical link

Logical link 8 bit Number of the logical link on which theconnection to be created, will run on

low-order byte

high-order byte

little endian byte order: address A

address A+1

address A



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

2.2.2 Create Connection Confirm on RP


2.2.3 Delete Connection on RP

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (2)

1 Zero

DR5 2 RP individual

3

DR6 4 Error code

5

DR7 6 CP individual

7

Error code 16 bit 0 = No fault5 = Maximum number of connectionsestablished8 = Protocol fault.

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (3)

1 Zero

DR5 2 RP individual

3



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

2.2.4 Delete Connection Confirm on RP


2.2.5 Create Connection on CP

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (4)

1 Zero

DR5 2 CP individual

3

DR6 4 Error code

5

Error code 16 bit 0 = No fault1 = RP individual not found

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (8)

1 Zero

DR5 2 RP individual

3



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

2.2.6 Create Connection Confirm on CP


2.3 CONNECTION MANAGER: CP-RP TYPES

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (9)

1 Zero

DR5 2 CP individual

3

DR6 4 Error code

5

DR7 6 RP individual

7

Error code 16 bit 0 = No fault5 = Maximum number of connectionsestablished

Parameter Type Description

Primitive 8 bit 1 = Create connection on RP2 = Create connection confirm on RP3 = Delete connection on RP4 = Delete connection confirm on RP8 = Create connection on CP9 = Create connection confirm on CP

Communica-tion service

8 bit Type of service to start1 = OCP Connection2 = RP Manager

CP individual 16 bit Identity of created OCP Connection indi-vidual in CP.



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

RP individual 16 bit Identity of created OCP Connection indi-vidual in RP.

Logical link 8 bit Logical link number:0 = Connection Manager1 = RP Manager2 = OCP Connection




Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

3 RP MANAGER

3.1 RP MANAGER: PHASES

3.1.1 Start RP Manager


Start RP manager is requested by a CP application to set the STOC defini-tion data.

3.1.1.2 Normal flow

It is guaranteed that the STOC definition data has been set after aModulesStarted has been received with no fault code.

It is guaranteed that the STOC has started the TCP/IP stack successfullyafter aCommunication Open has been received.


-

3.1.1.4 Supervision

The time fromUpdate Parametershas been sent untilModules Startedisreceived is time supervised. If the time supervision expires, no STOC defi-nition data has been set.

The time fromUpdate Parametershas been sent untilCommunicationOpenis received is time supervised. If the time supervision expires, theSTOC TCP/IP stack has not been started.

Figure 3.1 Start RP manager

CP: RP Manager RP: RP Manager AP: RP Manager

Update Parameters

Modules Startedtime supervised

Create Connection on RP, chapter

Communication Open



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

3.2 RP MANAGER: CP-RP MESSAGES





3.2.1 Update Parameters

: :

: :

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (0)

1 Number of parameters

DR5 2 Device pointer

3 Parameter type

DR6 4 Parameter value byte 0

Parameter value last byte

Parameter type

Parameter value byte 0

Parameter value last byte

low-order byte

high-order byte


address A+1

address A



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

Parameter type: IP address

Parameter type: Gateway IP address

Parameter type: Netmask

Parameter type: Listening port. The port for incoming connections. Thepresently used port number in OCP is 14.000

n Parameter type (0)

n+1 IP address, byte 0





n+1 Gateway IP address, byte 0





n+1 Netmask, byte 0

n+2 Netmask, byte 1

n+3 Netmask, byte 2

n+5 Netmask, byte 3


n+1 Port, byte 0

n+2 Port, byte 1



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

3.2.2 Modules Started

3.2.3 Communication Open

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (1)

1 Result code

DR5 2 Ethernet address byte 0

3 Ethernet address byte 1





#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (2)



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

3.3 RP MANAGER: CP-RP TYPES


Primitive 8 bit 0 = Update parameters1 = Modules started2 = Communication open

Parametertype

8 bit 0 = IP address, 4 bytes5 = Netmask, 4 bytes10 = Port, 2 bytes

Result code 8 bit 0 = Modules successfully started2 = TCP/IP failed to set the IP address

Devicepointer

8 bit Pointer to the communication device. Onlyfor local printout purposes



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4 OCP CONNECTION

4.1 OCP CONNECTION: PHASES

4.1.1 Active Open


Active open is requested by a CP application to setup a connection to aprocess in a remote system. Two types of active connection are possible.With data reception flow control, or without. Flow control means that aReceave Ready message must be sent before data can be received.

4.1.1.2 Normal flow

-


-

4.1.1.4 Supervision

The time fromActive Open Requesthas been sent untilActive OpenConfirm is received is time supervised. If the time supervision expires, noOCP Connectionis created and anERRORINDis returned to the OCP user.

Figure 4.1 Active open

CP: OCITS Connection RP: OCITS Connection

ACTIVEOPENCONF

Active Open Request

Active Open Confirmation

ACTIVEOPENREQ

connect()

time supervised

Create Connection on RP, chapter 2.1.1

socket(), bind(), listen()

AP: OCP Connection

connect()

accept()

OCP user OCP user

accept()



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.1.2 Passive Open


Passive open is requested by a CP application to make itself available formultiple connections from processes on remote systems.

4.1.2.2 Normal flow

-


-

4.1.2.4 Supervision

The time fromAccept Indicationhas been sent untilAccept Confirmationis received is time supervised. If the time supervision expires, noOCPConnection is created.

Figure 4.2 Passive open


Create Connection on CP, chapter 2.1.3

connect(), tcp-port=14000

Accept Indication

ACCEPTIND

ACCEPTINDR

Accept Confirm

recv(OCP-Accept Confirm)

BINDLISTEN

BINDLISTENR

time supervised

AP: OCP Connection

connect()

send(OCP-Accept Indication)

socket(), bind(), listen()

OCP user OCP user

time supervised

(once at startup)

accept()

connect()



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.1.3 Send Data


Send data is requested by a CP application to send data to the remote hoston a connection. Send order can be accompanied by an order to reply withacknowledgement (AF=1).

For IPN/APZVM the AF is always set for data transfer with buffer.

4.1.3.2 Normal flow

-


-

4.1.3.4 Supervision

-

Figure 4.3 Send data

Figure 4.4 Send data with acknowledge


SENDDDATAREQR

SENDDDATAREQ,

Send Request AF=0

send(OCP-Send Request)

AP: OCP Connection

recv()

OCP user OCP user

recv()


SENDDDATAREQ,

Send Request. AF=1

send(OCP-Send Request)

AP: OCP Connection

recv()

OCP user OCP user

recv()

SENDDDATAREQR

Send Request Ack



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.1.4 Receive Data with flow control


Receive data is requested by a CP application to receive data from theremote host.

4.1.4.2 Normal flow

A Receive Indicationmessage must be received before anotherReceiveReadymessage can be sent over the same connection.

Buffer pointer must be fetched in the following two cases: 1) SignalRECEIVEREADY is sent without buffer pointer, and 2) Bufferless modeis used and more than 32 bytes arrive from the net.

TheReceive Readymessage must be sent by the CP application until aReceive Indicationmessage with the close bit is received.

If the AP side wants to close the connection, it issues a close() call. The RPsends aReceive Indicationwith the close flag set to the CP application. TheReceive Indicationcan both contain data and have the close flag set.


-

4.1.4.4 Supervision

-

Figure 4.5 Receive data


RECEIVEIND

RECEIVEREADY

Receive Ready

Receive Indication

AP: OCP Connection

send()

send(OCP-Receive Indication)

OCP user OCP user

send()



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

Figure 4.6 Receive data with buffer pointer request. Only used inIPN/APZVM

Figure 4.7 Receive close flag.

RECEIVEREADY

RECEIVEIND

send()


send()

Receive Ready

Buffer Pointer Request

Receive Indication

GETRECBUFF

GETRECBUFFACKBuffer Pointer Confirmation

OCP user CP: OCITS Connection RP: OCITS Connection AP: OCP Connection OCP user

close()

close()

RECEIVEREADY

Receive Ready

RECEIVEIND, CF=1

Receive Indication, CF=1 close()




Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.1.5 Receive Data without flow control


Data Indication is received by a CP application on the initiative of a remoteOCP user.

4.1.5.2 Normal flow

Receive Indicationmessages are received over a connection at the pace ofthe AP side sending them.

If the AP side wants to close the connection, it issues a close() call. The RPsends aReceive Indicationwith the close flag set to the CP application. TheReceive Indicationcan both contain data and have the close flag set.


-

4.1.5.4 Supervision

-

Figure 4.8 Receive data without flow control


RECEIVEIND

Receive Indication

AP: OCP Connection

send()


OCP user OCP user

send()



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

Figure 4.9 Receive data with buffer pointer request. Only used inIPN/APZVM

Figure 4.10 Receive close flag.

RECEIVEIND

send()


send()Buffer Pointer Request

Receive Indication

GETRECBUFF

GETRECBUFFACKBuffer Pointer Confirmation


close()

close()

RECEIVEIND, CF=1

Receive Indication, CF=1 close()




Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.1.6 Close


Close is requested by a CP application to disconnect the transport connec-tion to the remote host. All pending data on the OCP connection isdiscarded.

4.1.6.2 Normal flow

A Close Requestcan be sent as reply toReceive Indicationwith close flagset. It can also be sent on own initiative.


-

4.1.6.4 Supervision

The time fromClose Requesthas been sent untilClose Request Acknowl-edgeis received is time supervised. Up to two minutes is reasonable time.If the time supervision expires theOCP Connection is removed and anERRORIND is returned to the OCP user.

Figure 4.11 Close


ABORTREQR

ABORTREQ

Close Request

Close Request Acknowledge

time supervised close()

Delete Connection on RP, chapter 2.1.2

AP: OCP Connection

close()

close()

OCP user OCP user



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.2 OCP CONNECTION: OCITS MESSAGES





4.2.1 Active open request

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (1)

1 BLI Version (0)

DR5 2 AP IP address

3

DR6 4

5

DR7 6 AP port

7

low-order byte

high-order byte


address A+1

address A



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.2.2 Active open request, no inbound flow control

4.2.3 Active Open Confirm


#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (20)

1 BLI Version (0)

DR5 2 AP IP address

3

DR6 4

5

DR7 6 AP port

7

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (2)

1 Zero

DR5 2 Error code

3

DR6 4 Zero

5

Error code 16 bit 0 = No faultAny error code as defined in reference 2 inthe interval from 100 upto 136 in H0.

Zero



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.2.4 Accept Indication

4.2.5 Accept Confirmation


#1 #2 B7 B6 B5 B4 B3 B2 B1 B0


1 Zero

DR5 2 OCP port

3

DR6 4 AP IP address

5

DR7 6

7

DR8 8 AP port

9

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0


1 BLI Version (0)

DR5 2 Error code

3

Error code 16 bit 0 = No fault1 = User not found2-up = User defined error code

Zero



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.2.6 Accept Confirmation, no inbound flow control


#1 #2 B7 B6 B5 B4 B3 B2 B1 B0


1 BLI Version (0)

DR5 2 Error code

3


Zero



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.2.7 Send Request

AF = Acknowledgement flag

4.2.8 Send Request Ack

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (6)

1 Zero

DR5 2 Zero

3

DR6 4 Zero AF Zero

5 Zero

DR7.. 6.. Bufferless parameter data

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (7)

1 Zero



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.2.9 Receive Ready

This format applies to IPNA/APVZM.

This format applies to STOC.

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (8)

1 Zero

DR5 2 Buffer pointer

3

DR6 4

5

DR7 6 Start index in buffer

7

DR8 8 Buffer size

9

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (8)

1 Zero



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.2.10 Receive Indication


#1 #2 B7 B6 B5 B4 B3 B2 B1 B0

DR4 0 Primitive (9)

1 Zero

DR5 2 Error code

3

DR6 4 Zero

5

DR7 6 Zero CF Zero

7 Zero

DR8.. 8.. Bufferless parameter data

Error code 16 bit 0 = No faultAny error code as defined in reference 2 inthe interval from 100 upto 136 in H0.



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.2.11 Buffer Pointer Request

This primitive is only used in IPN/APZVM

4.2.12 Buffer Pointer Confirmation

This primitive is only used in IPN/APZVM


#1 #2 B7 B6 B5 B4 B3 B2 B1 B0


1 Zero

DR5 2 Buffer length

3

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0


1 Zero

DR5 2 Error code

3

DR6 4 Buffer pointer

5

DR7 6

7

DR8 8 Start index in buffer

9

DR9 10 Buffer size

11

Error code 16 bit 0 = No fault6 = Unable to deliver buffer pointer7= Unable to deliver buffer pointer now.Try again after some delay.



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.2.13 Close Request

4.2.14 Close Request Acknowledge


#1 #2 B7 B6 B5 B4 B3 B2 B1 B0


1 Zero

#1 #2 B7 B6 B5 B4 B3 B2 B1 B0


1 Zero

DR5 2 Error code

3

DR6 4 Zero

5

Error code 16 bit 0 = No faultAt the present, no other error code is possi-ble.



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.3 OCP CONNECTION:OCITS TYPES


Primitive 8 bit 1 = Active open request2 = Active open confirm6 = Send request7 = Send request acknowledge8 = Receive ready9 = Receive indication10 = Close request11 = Close request acknowledge14 = Accept indication15 = Accept confirmation20 = Active open request, no flow control21 = Buffer pointer request22 = Buffer pointer confirmation23 = Accept confirmation, no inbound flowcontrol

CF 1 bit 1 = Close flag

AF 1 bit 1 = Acknowledgement requested

BLI 1 bit Bufferless data indicator.Only used in IPN/APZVM

Error code 16 bit

Version 4 bit Protocol version, current version is 0.

APIP address

32 bit

AP port 16 bit

CPIP address

32 bit

OCP port 16 bit Application identity on OCP level

Bufferlessparameterdata

8 bit First 32 bytes of user data, loaded inparameters



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.4 OCP CONNECTION: OCP MESSAGES

The following messages are sent over the network. The messages are sentwith the socketssend() call and are received with the socketsrecv()call.

The first column (#1) refers to the user data as the external node and the RPlooks at it.

The network byte order for the OCP protocol header is big endian, that is,the most significant byte is stored at the starting address. Data buffers arebyte oriented with the least significant byte (lowest index) coming first.

Figure 4.13 Big endian byte order

high-order byte

low-order byte

big endian byte order: address A

address A+1

address A



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.4.1 OCP-Send Request, data from CP to external

When CP sends data towards external node, this format is used.

4.4.2 OCP-Receive Indication, data from external to CP

When external node sends data towards CP is this format used.

#1 B7 B6 B5 B4 B3 B2 B1 B0

0 OCP message size

1

2 Primitive (6)

3 Zero

4.. OCP data buffer

#1 B7 B6 B5 B4 B3 B2 B1 B0

0 OCP message size

1

2 Primitive (9)

3 Zero

4.. OCP data buffer



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.4.3 OCP-Accept Indication

This is the connect message sent from external node towards CP aftersocket connect towards port 14000 has been performed by external..

4.4.4 OCP-Accept Confirm

This is reply from CP to external of connect message above.


#1 B7 B6 B5 B4 B3 B2 B1 B0

0 OCP message size

1

2 Primitive (14)

3 Zero Version (0)

4 CP application id

5

#1 B7 B6 B5 B4 B3 B2 B1 B0

0 OCP message size

1

2 Primitive (15)

3 Zero

4 Error code

5




Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.4.5 OCP-Prepare Reconnect

CP prepares connection move before CP side switch. All open connectionsreceive this message. After this message, no more messages are sent fromCP on that socket.

4.4.6 OCP-Prepare Reconnect Confirmation

For each connection that the external node wants to move and reconnect,this message is sent as reply to the previous message.

External node allocates all connections a unique identifier to be able to idet-nify them at reconnection.

All connections that do not receive this reply message after timeout arecleared in CP and not subject to re-connections after side switch.

#1 B7 B6 B5 B4 B3 B2 B1 B0

0 OCP message size

1

2 Primitive (25)

3 Zero Version (0)

#1 B7 B6 B5 B4 B3 B2 B1 B0

0 OCP message size

1

2 Primitive (26)

3 Zero

4 Connection identifier

5

6 Reconnect port

7

8 Reconnect IP address

9

10

11



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.4.7 OCP-Reconnect

After CP side switch all confirmed connections from the prepare phase arereconnected at given IP and port after which this message is sent in orderfor the external node to identify the connection and re-accociate it with theold socket..

4.4.8 OCP-Reconnect Confirmation

This reply message confirms for CP that a connection is re-connected.

All connections who do not receive this message after timeout are cleared.

#1 B7 B6 B5 B4 B3 B2 B1 B0

0 OCP message size

1

2 Primitive (27)

3 Zero Version (0)

4 Connection identifier

5

#1 B7 B6 B5 B4 B3 B2 B1 B0

0 OCP message size

1

2 Primitive (28)

3 Zero



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.5 OCP CONNECTION: RP-EXTERNAL TYPES


Primitive 8 bit 6 = OCP-Send request9 = OCP-Receive indication14 = OCP-Accept indication15 = OCP-Accept confirmation25 = OCP-Prepare Reconnect26 = OCP-Prepare Reconnect Confirmation27 = OCP-Reconnect28 = OCP-Reconnect Confirmation

OCP mes-sage size

16 bit The size of the OCP message starting fromposition 4 to the last position

OCP databuffer

buffer Start of data buffer. Max number of bytesthat can be sent is 65450.

CP applica-tion id

16 bit Identity of CP application to connect to

Version 4 bit Protocol version, current version is 0.

Reconnect IPaddress

32 bit IP address to re-connect to after nodeswitch

Reconnectport

16 bit Port to re-connect to after node switch

Connectionidentifier

16 bit Identifier of connection in the external node



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.6 OCITS CONNECTION: CP STATE MACHINE

4.6.1 State Diagram

Figure 4.14 CP state machine for OCITS connection

PEER

OPEN

CLOSE

ACCEPT

RECEIVE

1,2

11

13 17

14

21,22

9 3,7

4,5,6

Initial state Final state

18

8,10



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.6.2Transitions

Table 4.1 State transitions for OCITS Connection in CP

Nr Source state Event trigger Activities Target state

1 Initial state RP:<Create connection on CP> RP:<Create connection confirm on CP> PEER

2 Initial state CP:<ACTIVEOPENREQ> RP:<Create connection on RP> PEER

3 PEER RP:<Create connection confirm on RP> RP:<Active open request> ACCEPT

4 PEER Timeout expired onRP:<Create connection confirm on RP>

CP:<ERRORIND> Final state

5 PEER RP:<Delete connection confirm on RP> CP:<ABORTREQR> Final state

6 PEER Timeout expired onRP:<Delete connection confirm on RP>

CP:<ERRORIND> Final state

7 PEER RP:<Accept indication> CP:<ACCEPTIND> ACCEPT

8 ACCEPT RP:<Active open confirmation> CP:<ACTIVEOPENCONF> OPEN

9 ACCEPT Timeout expired onRP:<Active open confirmation>

RP:<Delete connection on RP>CP:<ERRORIND>

PEER

10 ACCEPT CP:<ACCEPTINDR> RP:<Accept confirm> OPEN

11 OPEN CP:<SENDDATAREQ> RP:<Send request>CP:<SENDDATAREQR>

OPEN

13 OPEN CP:<RECEIVEREADY> RP:<Receive ready> RECEIVE

14 OPEN CP:<ABORTREQ> RP:<Close request> CLOSE

17 RECEIVE RP:<Receive indication, CF=0> CP:<RECEIVEIND> OPEN

18 RECEIVE RP:<Receive indication, CF=1> CP:<RECEIVEIND> CLOSE

21 CLOSE RP:<Close request acknowledge> RP:<Delete connection on RP> PEER

22 CLOSE Timeout expired onRP:<Close request acknowledge>

RP:<Delete connection on RP>CP:<ERRORIND>

PEER



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.7 OCITS CONNECTION: RP STATE MACHINE

4.7.1 State Diagram

Figure 4.15 RP state machine for OCITS connection

PEER

OPEN

PEER_TO_PEER

RECEIVE

2

9

11 14,16

7

3

Initial state

ACCEPT

Final state

1 5

8

4

12 6



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.7.2 Transitions

Table 4.2 State transitions for OCITS Connection in RP


1 Initial state CP:<Create connection on RP> CP:<Create connection confirm on RP> PEER_TO_PEER

2 Initial state AP:<connect()> AP:<accept()>CP:<Create connection on CP>

PEER

3 PEER CP:<Create connection confirm on CP> - PEER_TO_PEER

4 PEER Timeout expired onCP:<Create connection confirm on CP>

Final state

5 PEER_TO_PEER CP:<Delete connection on RP> CP:<Delete connection confirm on RP> Final state

6 PEER_TO_PEER CP:<Active open request> AP:<connect()>CP:<Active open confirmation>

OPEN

7 PEER_TO_PEER AP:<OCP-Accept indication> CP:<Accept indication> ACCEPT

8 ACCEPT CP:<Accept confirmation> AP:<OCP-Accept confirmation> OPEN

9 OPEN CP:<Send request> AP:<OCP-Send request> OPEN

11 OPEN CP:<Receive ready> - RECEIVE

12 OPEN CP:<Close request> AP:<close()>CP:<Close request acknowledge>

PEER_TO_PEER

14 RECEIVE AP:<OCP-Receive indication> CP:<Receive indication, CF=0> OPEN

16 RECEIVE AP:<close()> CP:<Receive indication, CF=1> OPEN



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.8 OCITS CONNECTION: AP STATE MACHINE

4.8.1 State Diagram

Figure 4.16 AP state machine for OCP connection

ACCEPT

OPEN

1,2

7

3,4

Initial state Final state

10

9 11

13

5,6

RECEIVE



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.8.2 Transitions

Table 4.3 State transitions for OCITS Connection in AP


1 Initial state RP:<connect()> AP:<connect()> ACCEPT

2 Initial state AP:<connect()> RP:<connect()>RP:<OCP-Accept indication>

ACCEPT

3 ACCEPT AP:<accept()> RP:<accept()> OPEN

4 ACCEPT RP:<OCP-Accept confirmation> AP:<connect(), status=ok> OPEN

5 ACCEPT Timeout expired onRP:<OCP-Accept confirmation>

AP:<connect(), status=timeout> Final state

6 ACCEPT RP:<close()> AP:<connect(), status=peer_close> Final state

7 OPEN AP:<send()> RP:<OCP-Receive indication> OPEN

9 OPEN AP:<recv()> RECEIVE

10 OPEN RP:<close()> AP:<close()> Final state

11 RECEIVE RP:<OCP-Send request> AP:<recv(), status=ok> OPEN

13 RECEIVE RP:<close()> AP:<recv(), status=peer_close> Final state



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

4.9 GENERAL DESCRIPTION OF USED STATES

Table 4.4 General description of used states

State Description

Initial state No individual on RP

PEER Peer to peer connection in progress

PEER_TO_PEER CP and RP has established a peer-to-peer relation

ACCEPT Accept in progress

OPEN Open and idle

SEND Send in progress

RECEIVE Receive in progress

Final state No individual on RP



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

5 REFERENCES

[1] 1/155 19-ANZ 221 02 Uen, STCOM Interwork Description

[2] 3/155 19-ANZ 221 02 Uen, CP AP CommunicationTransport Service - OCITS



Nr - No.


2/155 19-ANZ 221 02 Uen

B2001-03-09

5/00

2 01

-CA

L 11

9 04

01 U

en A

6 REVISION HISTORY

-

Documents

OCS Communication Protocol, Ocp