ICCP Association Info Exchange v2_00

8/18/2019 ICCP Association Info Exchange v2_00

1/9

Association Information Exchange Form

Version 2.0 – 7/15/1999

The attached ICCP Association Information Exchange Form has beencreated to facilitate ICCP associations between ICCP nodes. ICCP node

administrators should fill out this form using their own setup information.

Thus the form will contain information supplied by company-A to company-

B detailing the parameters needed during company-B’s ICCP association

configuration. Note that similar information needs to be supplied by

company-B to company-A.

The fields are marked as Mandatory, Recommended, or Optional.

Mandatory fields are required in order to create an association.

Recommended fields should generally be filled in if applicable. For

example, an OSI NSAP is only required if using an OSI stack. Optional

fields can be filled in for instance to help with troubleshooting if connection

or data transmission errors occur.

1


2/9

ICCP Association Information Exchange Form Version 2.0 – 7/15/1999

Date:

Company-A:

Contact for Company-A:

Company-B:

Contact for Company-B:

General Notes:

Table 1: Company-wide / Server independent information1. ICCP vendor and platform

The name of the Company-A’s ICCP vendor, vendor

software version, as well what operating system and

hardware platform used for the ICCP servers.

M

2. Number of possible ICCP servers:

This is the total number of ICCP servers that may be

available to a remote client to associate with. Include

backup servers if they have unique addresses. This

number should equal the number of copies of Table 2

included in this form. Typically 1 - 10.

R

3. Company A’s domain name:

The domain name which company-B will use to access

data on Company-A’s ICCP node. Recommended to

be the 4 character ISN node name of Company-B.

M

2


3/9


4/9


12. OSI routing Company A’s router:domain of

If you are using ISN style NSAP’s , this 4 byte number

is part of the company-B’s router configuration and

consists of a 2 byte Domain ID and a 2 byte Area ID.

If you are using OSI, but not using ISN style NSAP’s

then enter the full hex string. If you are using TCP/IP,then leave this blank.

R

13. IP address of the WAN port on Company A’s router.

If you are using TCP/IP, this field is either an fully

qualified domain name or a 12 integer number

delimited with periods.

R

14. Transport Layer Ack Time:

This field indicates a maximum time in seconds that

can elapse between receipt of a TPDU by Transport

from the network layer and the transmission of the

corresponding acknowledgment. Typically 5 seconds.

O

15. Transport Layer Retransmission Time:

This field indicates the maximum time in seconds

Transport will wait for an acknowledgment before

retransmitting a TPDU. Typically 10 seconds.

O

16. Transport Layer Window Time:

This field indicates a maximum time in seconds that

Transport will wait before retransmitting up-to-date

window information. Typically 10 seconds.

O

17. Number of Retries:

This field indicates the maximum number of attempts

to retransmit a TPDU before issuing a DisconnectRequest. Typically 6.

O

18. Maximum MMS PDU size.

Size in bytes of the maximum MMS protocol data unit.

Typically 8k bytes or more.

O

4


5/9


Table 2: ICCP Server specific information

(This table should be duplicated for each ICCP server installed)

1. Server name:

The name by which company-A refers to this server.

This field is not electronically transmitted during anyICCP transactions, but is only here to facilitate verbal

communication between Company A and Company B.

O

2. Server number:

“1” if this is the primary server, “2” if this is the first

backup, etc.

R

3. IP network address:

If you are using TCP/IP, this optional field is the IP

address for this ICCP server if TCP/IP can be used as

the network transport.

R

4. AP Title:

Object identifier representing the Application Process

Title given to this application. The standardized

format of the AP Title is found in Appendix B.

M

5. AP Invoke ID

A long integer used to identify an invocation instance

of the application process. Typically not specified.

O

6. AE Qualifier

A long integer (32 bit signed) is used to qualify the

application entity.

O

7. AE Invoke ID

Used to identify an invocation instance of the

application entity. Typically not specified.

O

8. Presentation Selector (PSEL)

2 or 4 byte number used to select the correct instance

of the presentation layer (e.g. 00 09 or 00 00 00 09).

M

9. Session Selector (SSEL)


of the session layer (e.g. 00 09 or 00 00 00 09).

M

10. Transport Selector (TSEL)


of the session layer (e.g. 00 09 or 00 00 00 09).

M

11. Complete NSAP

An number that represents the OSI network address for

Company A’s ICCP node. The NSAP can be up to 20

bytes long. For ISN nodes, the first 7 bytes should be

(in hex): 39 840f 80 113826. For a more detailed

discussion of NSAP’s see Appendix A.

R

5


6/9


Appendix A: Explaination of ISN Style NSAP’s

ISN Style NSAP have the following form (in hex):

39 840f 80 113826 0000 rrrr aaaa dddddddddddd nn

The first byte contains the Authority Format ID (AFI) where 39 is for ISOThe next two bytes contain Initial Domain ID (IDI) where 840F is for USA

The next byte contains the Domain Format ID (DFI) where 80 is for GOSIP style format

The next three bytes contain the organization ID where 113826 is for NERC

The next two bytes is a reserved field and should be set to 0000

rrrr = Routing Domain ID (Contact NERC for this value)

aaaa = Area (Contact NERC for this value)

dddddddddddd = Station ID (see below)

nn = NSEL (see below)

ISN Style Station ID Addressing Standard

The next to last 6 bytes of the NSAP contain the Station ID. The Station ID format is:Bytes 1-4 ASCII code in hex of the registered SiteID of the ISN (or other ICCP)

Node with padded underscore(s) as needed.

Byte 5 ASCII code in hex of the node number on which the server is running.

For example, if the node number is equal to ‘1’ then byte 5 should contain

hex 31.

Byte 6 ASCII code in hex indicating the application specification of the Protocol:

Hex 49 for ICCP

Examples:

SC__1I 53 43 5F 5F 31 49

ECAR1I 45 43 41 52 31 49ECAR2I 45 43 41 52 32 49

ASCII to Hex and Conversion Table for Station ID’s :

ASCII Hex ASCII Hex ASCII Hex ASCII Hex

_ 5F 9 39 I 49 R 52

1 31 A 41 J 4A S 53

2 32 B 42 K 4B T 54

3 33 C 43 L 4C U 55

4 34 D 44 M 4D V 56

5 35 E 45 N 4E W 57

6 36 F 46 O 4F X 58

7 37 G 47 P 50 Y 59

8 38 H 48 Q 51 Z 5A

Note: NSAP’s are always specified in hex while the AP Title standard in Appendix B

consists of a set of decimal numbers. Use this table to translate your site id into hex for

the station ID portion of your NSAP’s.

6


7/9


The Network Selector or NSEL is the last byte of the NSAP and is used to select the

correct instance of the Network layer. Some DECnet/OSI systems will automatically

assign this a value (20 hex for Phase IV NSP transport, 21 hex for OSI transport TP4).

Other OSI stacks do not impose this requirement. The recommended value for systems on

which it is not automatically assigned is 01.

7


8/9


Appendix B: Mandatory AP Title Standard

The AP Title is used by some ISO applications to determine what application is calling

since NSAP’s, TSEL’s, SSEL’s and PSEL’s of the caller may not passed to applications

upon association. The AP Title consists of 9 16 bit decimal numbers:

Field Name 1 2 3

Field format One single 16 bit

decimal integer)

One 16 bit

decimal integer

Seven 16 bit decimal integers

Required value

in decimal

2

(joint-iso-ccitt)

16 (country

based naming

hierarchy)

3826 XXXX XXXX XXXX XXXX YYYY

0073

(3826 is the abbreviated NERC org ID used

to specify ISN applications), XXXX XXXX

XXXX XXXX is for the registered ISN node

ID in decimal (one 16 bit decimal number for

each ASCII character in the site ID including

padding underscores), YYYY is the for thenode number (one 16 bit decimal number),

the last 16 bit number is an application

specification where decimal 0073 indicates

ICCP.)

For example, an ICCP application at MAIN1 would have an AP Title of:

0002 0016 3826 0077 0065 0073 0078 0049 0073

Note: Some ICCP vendors do not provide a user interface for setting AP Titles. In this

case the user may be required to manually edit a Directory Information Base ASCII file.

ASCII to Hex and Decimal Conversion Table:

ASCII Dec ASCII Dec ASCII Dec ASCII Dec

_ 95 9 57 I 73 R 82

1 49 A 65 J 74 S 83

2 50 B 66 K 75 T 84

3 51 C 67 L 76 U 85

4 52 D 68 M 77 V 86

5 53 E 69 N 78 W 87

6 54 F 70 O 79 X 88

7 55 G 71 P 80 Y 898 56 H 72 Q 81 Z 90

Note: Only use this ASCII conversion table to calculate the AP Title.

8


9/9


Revision history:

Version Date Comments

1/16/98 Added transport layer parameters

Added AP Title and NSAP appendices

1/23/98 Fixed IP addressing and association

parameter errorsChanged AP Title standard

2/24/98 Added ICCP vendor information

5/20/98 Added more instructions to help user

fill out forms.

5/26/98 Added cover page

Added M,R,O column

9/25/98 Moved rows (formerly labeled 2.3 –

2.8 now labeled 1.3 – 1.8). Deleted

row (formerly labeled 1.5)

12/1/98 In table 2, changed fields 4, 8, 9, and

10 from “Recommended” to

“Mandatory”

1/19/99 Fixed typographical errors

5/13/99 Moved Association type and initiator

from Table 2 to Table 1. Updated

version number and date in header/

footer. [kbp]

7/15/1999

Version 2.0

Made AP Titles mandatory per

Appendix B. Removed John

Gillerman as document owner.

Upgraded document to Version 2.0.

9

ICCP Association Info Exchange v2_00

Documents

Transcript of ICCP Association Info Exchange v2_00